[Feature]: Separated/Dedicated interfaces for VNC & VM

[EHRETic]

Is there no existing feature request for this?

• [X] I have searched the existing feature requests

Is your proposal related to a problem?

Not a problem

Describe the solution you'd like.

Hi there,

First, lovely concept, I use it to test a few things and I find it amazing :-)

I have a question/probably a feature request for multiple interfaces : is it possible to have a macvlan IP in network macvlan_A and the Windows docker to have an interface (IP with DHCP or fixed) in a macvlan_B

What I plan : secure the VNC on port 8006 behind a reverse proxy on a subnet dedicated to containers and have my Windows server on my normal LAN.

Both macvlan A & B are available on the host with multiple VLANs/docker networks.

Thanks in advance for your answer!

Describe alternatives you've considered.

For now on, I use 2 different IPs in the same subnet, but I can't secure VNC on my LAN because it is not behind my firewall/reverse proxy.

Additional context

No response

[kroese]

This is already exactly how it works when you enable DHCP=Y. The VNC port will be reachable under the macvlan IP of the container, and Windows itself will only be reachable under another interface and IP. This is a macvtap interface. They do not have to be on the same subnet at all.

So instead of a macvlan A and macvlan B, it currently works as macvlan A and macvtap B.

That aside, if the only reason is that you want to secure the VNC port, it makes more sense to just add nginx authentication on port 8006 (see https://github.com/dockur/windows/issues/301#issuecomment-2018610554 ). That way it even works with bridge networking, without any need for macvlan or macvtap.

[EHRETic]

So instead of a macvlan A and macvlan B, it currently works as macvlan A and macvtap B.

This is what I'm using currently, but that would more compare to something like macvlan A & macvtap A no? (as macvtap is bridged to macvlan if I understood correctly)

What I would like to be able to do is:

• macvlan A interface vlan123 with IP 192.168.123.X (/24)
• macvlan B interface vlan234 with IP 192.168.234.Y (/24)

2 completely different subnets linked to 2 different macvlan interfaces.

(don't worry, I can live without, but that could be a nice addition)

[kroese]

The macvlan and the macvtap are completely seperated, as far as I remember. The macvtap is not bridged over macvlan, it becomes a new and directly attached client on the network.

The macvtap just asks the DHCP server for an IP and this can be on a totally different subnet as where the container itself (macvlan) is running, as far as I remember.

You can even set a static IP for your Windows VM inside the Control Panel, and do not use a DHCP server at all. Therefore the name DHCP is a bit misleading for this mode, because it can be used with a static configuration also.

Did you already try different subnets or did you just assume it wouldnt work?

To support multiple network interfaces would make the already complicated network code, even more complicated. So unless it would provide a significant advantage in some way, I would rather not get myself into that :)

[EHRETic]

Hi,

I just tried and I soon as I change my macvlan, the VM interface is also switched to the same subnet (confirmed by DHCP) This confirms my theory of macvtap is bridged to the macvlan interface (but remains a separate one)

Would be a nice addition, but if I'm the only one requesting it... well... 😊

[kroese]

Okay, I understand what you mean then and I agree it would be a nice addition.

I will see if I can add dual macvlan in the future, but it wont be anytime soon.

[EHRETic]

I will see if I can add dual macvlan in the future, but it wont be anytime soon.

I would scale it straight to "multiple" ! 😊

[EHRETic]

Hi @kroese 😊

Was the idea abandonned or will it be integrated in a future version? I didn't found anything in releases notes...

PS: I don't see any link "releases" at the right bar of https://github.com/dockur/windows/ repository :

But it is available at macos one... any chance to add it again?

[kroese]

You can just visit the releases page by adding/releases to the URL:

https://github.com/dockur/windows/releases

I don't want to link to it for this project, because its a bit useless in this case. Normally the "Releases" page is used to ship binaries, but as this is a container they are shipped in the "Packages" section.

And to distribute the source its also a bit useless, because you can just download old code by selecting the corresponding tag-name. And secondly the Dockerfile are not really suitable to be re-build from source years later, because that would require strict version-pinning in the Dockerfile so that all dependancies keep the same version, which is also not the case right now.

[EHRETic]

Hi,

I think I missed how to configure 2 interfaces somehow... and as I need to rebuild some VMs from scratch to use thin provisioned disks, I'll take the opportunity to configure them with KVM + Windows interfaces.

Any advice to modify the following configuration? (for now, the IP is for the KVM and VM uses DHCP option, but both are on the same network)

Thanks! 😊

Config:

services:
  windows:
    image: dockurr/windows
    container_name: srv-test
    
    restart: unless-stopped

    environment:
      VERSION: '${VERSION}'
      RAM_SIZE: '${RAM_SIZE}'
      CPU_CORES: '${CPU_CORES}'
      DISK_SIZE: '${DISK_SIZE}'
      DHCP: '${DHCP}'

    volumes:
      - system:/storage
      - data:/storage2
    
    devices:
      - /dev/kvm
      - /dev/vhost-net

    device_cgroup_rules:
      - 'c *:* rwm'
    
    cap_add:
      - NET_ADMIN
    
    stop_grace_period: 2m
    
    networks:
      default:
        ipv4_address: 192.168.X.X

volumes:
  system:
  data:

networks:
  default:
    external: true
    name: my_lan