Created attachment 388285 [details] MAC of default gateway changes on every power on Description of problem: Every time I power up my Windows 7 virtual machine under KVM, Windows detects a new network, sets a new network name, and asks me to tell if it's home/corporate/public. Version-Release number of selected component (if applicable): libvirt-python-0.6.3-20.1.el5_4 libvirt-0.6.3-20.1.el5_4 kmod-kvm-83-105.el5_4.13 kvm-qemu-img-83-105.el5_4.13 etherboot-zroms-kvm-5.4.4-10.el5 kvm-83-105.el5_4.13 kvm-tools-83-105.el5_4.13 virt-manager-0.6.1-8.el5 How reproducible: Every time you power on/off/on the machine. Never happens if you simply reboot. Steps to Reproduce: Create a VM using virt-manager, fully virtualized, x86_64, kvm, default virtual network (NAT). Install Windows 7. Boot machine. Actual results: On first boot you will be asked for the type of network for "Network 1". Shutdown the machine, power on again, and you will be asked the same question for "Network 2". Shutdown, power on, and you will get "Network 3". And that repeats as many times as you shutdown/power on. Expected results: Network name should never change. This is a problem because end-users or less technical users will be asked why the network configuration keeps changing. Imagine you define that it's a home network, and you want to keep it like that. It does not make sense you need to re-confirm every time you power up the machine. Additional info: My investigation shows me that Windows creates a new network every time it sees something changing on the lower network level. In this particular case, I verified that the MAC address of the default gateway changes every time you power on/off the VM. Nothing else changes (PCI bus ID, or IP address, even if DHCP, they remain the same every time I power on the machine). Screen shots and config files follow.
Created attachment 388286 [details] VM config file
# virsh net-dumpxml default <network> <name>default</name> <uuid>ffb69b99-77c4-4f3c-a3fd-525e55b24e7e</uuid> <forward mode='nat'/> <bridge name='virbr0' stp='on' forwardDelay='0' /> <ip address='192.168.122.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.122.2' end='192.168.122.254' /> </dhcp> </ip> </network>
About Windows: The service that identifies the network in Windows is the NLA - Network Location Awareness (http://msdn.microsoft.com/en-us/library/ms739931%28VS.85%29.aspx). This service has existed since Windows Vista. Workarounds: - Disable the NLA service. - Disable the Network Location Wizard: http://technet.microsoft.com/en-us/library/cc733147%28WS.10%29.aspx
Quick observation. I notice that every time I start a VM, both virbr0 and vnet0 change MAC. If I remove/create the virbr0 and vnet0 interfaces manually using brctl commands, this does not happen, i.e. the MAC remains the same even if I remove and re-add the interface. So, it sounds to me like somewhere in kvm or libvirt code they're instructing the system to create the interfaces with a different MAC.
Small note. Even if the workarounds suggested on comment 3 really work, I don't think that is the correct functionality. On a real world environment nobody changes the company's router on a regular basis, so it is good to have this feature always on, so you can be sure your network is just fine as it should. On the other hand, imagine a developer, or even a sysadmin, who needs to create and destroy VMs many times during the course of his work to test new stuff. He can't be asked to remember to disable that feature every time he builds a new VM. (My personal opinion).
*** Bug 581110 has been marked as a duplicate of this bug. ***
This problem is much harder to fix than it first appears. The virtual network capability in libvirt is built using a bridge device, which is not connected to any physical ethernet devices. When a guest is started, its TAP device is added to the bridge. Guest access to the LAN is done by setting up ip forwarding + NAT from the bridge to the LAN devices. The bridge device has an IP address so that the guest can talk to the host OS and lets the host offer DHCP services to the guest. Thus the bridge device is the default router for the guest. In Linux, a bridge device's MAC address *must* match the MAC address of one of the network interfaces enslaved in the bridge. If it doesn't match, then no traffic will ever flow. Thus it is impossible to give the bridge device a fixed MAC address. The bridge device will inherit the MAC address of the first guest to be booted. If that guest shuts down, the bridge device will inherit the MAC address of one of the other remaining guests that are still running. So clearly the MAC address is changing over time & not stable. In this virtual network scenario, there is no interface which is permanently attached to the bridge, so no stable MAC address is possible. A normal bridging scenario doesn't suffer from this problem because it always has a physical NIC enslaved, as well as the guests. The only option i see is to attempt to create a dummy interface on the host which is used for nothing, except to be permanently enslaved in the bridge. This is not something we want to rush into changing because this may have other consequences we're not aware of yet
Ok, I think you got me confused. In my tests I have this Window VM which has a fixed MAC in eth0 on the configuration. Every time I boot the system, virbr0 gets a new, different, MAC. In my tests all I need to do is: - power on the VM (get a MAC) - power off (MAC zeroes) - power on the _same_ VM (get a _new_ MAC) For what I understand, this is not the behavior you described. When you say "The bridge device will inherit the MAC address of the first guest to be booted", I understood the MAC of virbr0 would be the same as eth0 on the host. Am I wrong? In any case, even if I am wrong, and the virbr0 MAC will be different from eth0 MAC on the host, what happens here is that every time I boot the guest virbr0 gets a new MAC. If, following your line of thought, the virbr0 MAC is attached to what goes on the guest, isn't it possible to allow a configuration option on the guest to say "use fixed MAC address for the bridge interface"? Thanks.
virbr0 will get the MAC of the first interface that is attached. eth0 is *never* attached to virbr0 since that is a physical host interface. Only guest TAP devices are attached. The TAP devices in the host get a random MAC address, but even if we made the MAC address of the guest TAP device match the guest NIC MAC address this wouldn't help if you have >1 guest VM attached to virbr0.
Sorry if I was confusing. Every mention on eth0 on my comment was related to first ethernet interface of GUEST, not the host. So you say that a fixed MAC on the TAP won't help >1 guest. I understand. Wouldn't it be possible to, let's say, if virbr0 is attached to a TAP device with fixed MAC, and new host does not require fixed MAC, assign host to old virbr0, but in case new host requires fixed MAC, create interface virbr1, and so on?
This is unlikely to be fixed for 5.6, this is not handled by the rebase and there is no patch upstream for this, Daniel
*** Bug 626678 has been marked as a duplicate of this bug. ***
There is now a patch posted upstream (but not yet pushed) for this. The backport will not be trivial, however, as bridge_driver.c has been significantly refactored. Intro: https://www.redhat.com/archives/libvir-list/2011-February/msg00222.html There is some more discussion on this thread, but here are the two most important items: Prerequisite: https://www.redhat.com/archives/libvir-list/2011-February/msg00223.html V2 of the "meat" patch: https://www.redhat.com/archives/libvir-list/2011-February/msg00304.html Also, Bug 609463 is tracking this issue for RHEL 6.