dockur
The guest Windows can connect the host, but NOT machine in the LAN.
Operating system
Arch Linux
Description
- The host CAN ping the container via the assigned IP 10.42.0.10.
- The container CAN ping the host IP 10.42.0.1, hostvlan IP, as well as any other LAN IPs without problem, e.g.,
docker exec -it LTSC ping 10.42.0.100, therefore the configuration of docker's and host's macvlan should be of no problem. - The guest Windows can ping the host IP 10.42.0.1, and the hostvlan
- The guest Windows can access internet
- The guest Windows CANNOT ping or access other LAN IPs.
I tried Windows 10 and Windows 7, the same issue occurred in both, so it's no likely an issue from Windows.
Any idea what is the potential cause of this issue?
Docker compose
docker network create -d macvlan --subnet=10.42.0.0/24 --gateway=10.42.0.1 --ip-range=10.42.0.8/29 -o macvlan_mode=bridge -o parent=br1 dockervlan0
ip link add hostvlan link br1 type macvlan mode bridge
ip addr add 10.42.0.14/32 dev hostvlan
ip link set hostvlan up
ip r add 10.42.0.10/32 dev hostvlan
args=(
-it --rm --name LTSC
--device=/dev/kvm
--device=/dev/net/tun
--cap-add NET_ADMIN
-v /media/data/VM/docker_ltsc:/storage
-v /media/data/VM/Win10_LTSC_x64_2508.iso:/boot.iso
-e VERSION=10l
-e CPU_CORES=3
-e RAM_SIZE=12G
-e DISK_SIZE=64G
-e USERNAME=user
-e REGION=en-US
-e KEYBOARD=en-US
--network dockervlan0
--ip 10.42.0.10
--stop-timeout 120
dockurr/windows
)
docker run "${args[@]}"
Docker log
❯ Starting Windows for Docker v5.00...
❯ For support visit https://github.com/dockur/windows
❯ CPU: Intel Core i5 1235U | RAM: 29/32 GB | DISK: 433 GB (btrfs) | KERNEL: 6.1.152-1-lts-waydroid...
❯ Warning: you are using the BTRFS filesystem for /storage, this might introduce issues with Windows Setup!
❯ Booting Windows using QEMU v10.0.3...
BdsDxe: loading Boot0004 "Windows Boot Manager" from HD(1,GPT,20EFCB39-A182-42BC-AE4D-165D040ADAAF,0x800,0x40000)/\EFI\Microsoft\Boot\bootmgfw.efi
BdsDxe: starting Boot0004 "Windows Boot Manager" from HD(1,GPT,20EFCB39-A182-42BC-AE4D-165D040ADAAF,0x800,0x40000)/\EFI\Microsoft\Boot\bootmgfw.efi
❯ Windows started successfully, visit http://127.0.0.1:8006/ to view the screen...
Screenshots (optional)
No response
You configured the macvlan a bit differently than described in the README, as I dont know what effect macvlan_mode=bridge will have.
In any case, I would suggest to add these additional parameters: https://github.com/dockur/windows?tab=readme-ov-file#how-can-windows-acquire-an-ip-address-from-my-router
You will loose the ability to ping the host (and the host will not be able to ping the VM), but at least you will be able to ping other LAN IP's that way.
You configured the macvlan a bit differently than described in the README, as I dont know what effect
macvlan_mode=bridgewill have.In any case, I would suggest to add these additional parameters: https://github.com/dockur/windows?tab=readme-ov-file#how-can-windows-acquire-an-ip-address-from-my-router
You will loose the ability to ping the host (and the host will not be able to ping the VM), but at least you will be able to ping other LAN IP's that way.
macvlan_mode=bridge is the default option for macvlan driver https://docs.docker.com/engine/network/drivers/macvlan/#options, you can omit this option but it implies macvlan_mode=bridge anyway. So this option is irrelevant to this issue.
As I indicated in my first post, under my current settings, the container itself communicates perfectly with any LAN machines, including the host, without any obstacles. The LAN machines, including the host, can do vice versa. The problem is that the Windows VM inside the container is unable to connect to LAN machines except the host, and LAN machines except the host cannot connect to the Windows VM.
It is a rather strange problem that I cannot understand the root cause of. Anyway, thanks for your suggestion, though it's unlikely to help in my case.
I am 100 percent sure that my suggestion will solve your problem.
The reason why you currently cannot connect to the other machines is because only the container itself is in the macvlan network but the VM is not (it is behind a NAT tunnel). If you enable that DHCP mode then there will be no tunnel anymore (and performance will be better too).
I am 100 percent sure that my suggestion will solve your problem.
The reason why you currently cannot connect to the other machines is because only the container itself is in the macvlan network but the VM is not (it is behind a NAT tunnel). If you enable that DHCP mode then there will be no tunnel anymore (and performance will be better too).
Thanks for further clarification. Though the solution is not viable for me , I actually tried that approach before I was posting this issue, it was a dead end. The problem is the host machine is the gateway of the local network. The DHCP server is running on the host. When enabling DHCP way for the container, the container itself somehow received an IP (probably not from DHCP server, but assigned by Docker using the lowest IP from the ip-range), the VM can't talk to the DHCP server which happens to be on the host machine.
ip a inside container when using DHCP mode:
root@f7ae437aae25:/# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host proto kernel_lo
valid_lft forever preferred_lft forever
2: qemu@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 500
link/ether 02:61:29:d5:45:8e brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::61:29ff:fed5:458e/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
27: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 06:2d:5c:c6:b7:1e brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.42.0.8/24 brd 10.42.0.255 scope global eth0
valid_lft forever preferred_lft forever
Yes, this is also described in the README. By default you cannot communicate with the host from within the VM, but if you add a second macvlan network as described in the linked article, you will be able to reach the host from the VM.
This has been probably asked but why can't the Windows VM simply talk to the host LAN network by using the host network in docker manager? That's how literally every other Docker app works, however, this container seems to have a hardcoded DHCP service using a valid IP address of 20.20.20.21.
Taking the macvlan route seems to be peak overengineering. Any thoughts on the idea above @kroese ?
@iassis Because it is a virtual machine. It cannot share the same IP as the host (as that would be conflicting, two machines on one network having the same IP), so it cannot use host networking for that reason. All the other containers that support host networking do not have this problem because they do not run a full machine.
@iassis Because it is a virtual machine. It cannot share the same IP as the host (as that would be conflicting, two machines on one network having the same IP), so it cannot use host networking for that reason. All the other containers that support host networking do not have this problem because they do not run a full machine.
Sure, the same IP address wouldn't fly as there would be a conflict and the VM wouldn't ever be available to the network as the ARP frame wouldn't ever go through the container "virtual pipe" since the host would simply answer to the packet as itself (rightfully so). We're all in the same page with that.
I vaguely remember that VMware and XenServer used to virtualize the MAC address of the VM, present it to the host and the host would have it forwarded to the network as a dedicated host, which triggered ~~poor soul me~~ network engineering teams to lift MAC address count restrictions to the switch/router ports as you'd see an additional MAC per each VM popping out of that host port. Sure, I get it that a container isn't a proper hypervisor but wouldn't there be any "vSwitch" equivalent to forward the actual VM L2 frame through the Docker host down to the network?
The way it is currently setup is that you can have the VM access a NFS/SMB share across the LAN through the macvlan vNIC bridge but you can't really access anything being shared by the VM. Perhaps this could be associated with #28 due to similar symptom, however, I've literally given up using the Windows VM container because I couldn't get any packet through into the VM even all the necessary routing from the LAN devices.
Sorry if I'm being confusing, let me know if it makes sense or if I'm just oblivious as to how the containerization packet forwarding logic works - granted my previous virtualization days more than a decade ago.
If you enable the DHCP mode (see the FAQ) it uses macvtap instead of macvlan, and it will be a "dedicated host" with its own IP address and MAC address (not shared with the container). It basicly bypasses the container and communicates directly with the network card. All other computers in the LAN will be able to see it and connect to it. This is exactly as how you describe that VMware and XenServer work, and it provides the best performance with zero restrictions.
If you only enable macvlan for the container, but not DHCP mode (macvtap) then the VM will still use NAT tunneling, so it keeps all the limitations coming with that. So it doesn't make much sense to just enable macvlan for this container. Either use it in the default (bridge) setup, with tunneling. Or use it in the macvtap mode, without tunneling.
The only reason why I included instructions on how to put it in macvlan mode in the readme file, is because it is an intermediate step necessary to get macvtap working later on.