Description of problem: libvirt assigns random MAC address to tap devices/vnet interfaces. Version-Release number of selected component (if applicable): kernel-2.6.18-164.el5 libvirt-0.6.3-20.1.el5_4 How reproducible: 100% Steps to Reproduce: 1.Using Bridged Networking or default virtual networking/NAT forwarding,create a KVM VM. 2.The vnet interface/tap device created for the VM is assigned a random MAC address. Actual results: libvirt assigns random MAC address to tap devices Expected results: libvirt should assign MAC address in the upper range(starting with FE:xx) to tap devices Additional info: 1.A bridge acquires the lowest MAC address of all the ports connected to it.So,the bridge may acquire a new MAC address every time a VM's created or destroyed. 2.When this change in the MAC address of the bridge happens,the KVM host may become unreachable for a few minutes when bridged networking is used and the KVM host's NIC is added to the bridge.So,libvirt should assign MAC address in the upper range to tap devices to prevent the MAC address of the bridge from changing every time a VM is created or destroyed. These commands have been run on a 5.4 KVM host with bridged networking (bridge br0)with a single Ethernet interface(eth0) added to br0,br0 gets the MAC address of eth0. Before creating a VM ----------------------------- [root@dhcp243-202 ~]# brctl show bridge name bridge id STP enabled interfaces br0 8000.0023aea499cd no eth0 [root@dhcp243-202 ~]#ifconfig br0 Link encap:Ethernet HWaddr E4:1F:13:2E:99:08 inet addr:10.11.243.202 Bcast:10.11.243.255 Mask:255.255.254.0 inet6 addr: fe80::223:aeff:fea4:99cd/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9939793 errors:0 dropped:0 overruns:0 frame:0 TX packets:1152537 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3256428730 (3.0 GiB) TX bytes:91632907 (87.3 MiB) eth0 Link encap:Ethernet HWaddr E4:1F:13:2E:99:08 inet6 addr: fe80::223:aeff:fea4:99cd/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9787163 errors:0 dropped:0 overruns:0 frame:0 TX packets:1120849 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3364668232 (3.1 GiB) TX bytes:94237619 (89.8 MiB) Interrupt:185 Memory:dbde0000-dbdf0000 After creating a VM ------------------------------ [root@dhcp243-202 ~]# brctl show bridge name bridge id STP enabled interfaces br0 8000.0023aea499cd no vnet1 eth0 br0 Link encap:Ethernet HWaddr CE:C7:92:CF:12:D8 inet addr:10.11.243.202 Bcast:10.11.243.255 Mask:255.255.254.0 inet6 addr: fe80::223:aeff:fea4:99cd/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9946280 errors:0 dropped:0 overruns:0 frame:0 TX packets:1152768 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3257838529 (3.0 GiB) TX bytes:91669261 (87.4 MiB) eth0 Link encap:Ethernet HWaddr E4:1F:13:2E:99:08 inet6 addr: fe80::223:aeff:fea4:99cd/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9793654 errors:0 dropped:0 overruns:0 frame:0 TX packets:1121154 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3366192351 (3.1 GiB) TX bytes:94286827 (89.9 MiB) Interrupt:185 Memory:dbde0000-dbdf0000 vnet1 Link encap:Ethernet HWaddr CE:C7:92:CF:12:D8 inet6 addr: fe80::f0cd:5aff:fe91:a1fa/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:72 errors:0 dropped:0 overruns:0 frame:0 TX packets:4263 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:11406 (11.1 KiB) TX bytes:957510 (935.0 KiB)
Created attachment 403334 [details] proposed patch to fix tap interfaces mac addr Hi, I'm proposing this patch to libvirt so it will fix the MAC address to always start with FE:xx:... This will prevent the bridge to change its address when the interface joins in the bridge. fbl
Changing 'Description of problem' to: libvirt uses the MAC address assigned to tap devices/vnet interfaces by the TAP/TUN driver. Changing 'Actual results' to: libvirt uses the MAC address assigned to tap devices/vnet interfaces by the TAP/TUN driver. Changing 'Expected results' to: libvirt should ignore the MAC address assigned to tap devices/vnet interfaces by the TAP/TUN driver and assign MAC address in the upper range(starting with FE:xx) to tap devices.
> may become unreachable for a few minutes Are we clear what actually causes this? Is it because bridge has STP=no?
*** Bug 583139 has been marked as a duplicate of this bug. ***
It looks that it can be the cause for a bug reported by me: #611838
Confirmed, this is the cause for bug #611838 After applying the patch from bug #583139 I don't have any more lost connections to the host.
*** Bug 611838 has been marked as a duplicate of this bug. ***
Fix posted upstream https://www.redhat.com/archives/libvir-list/2010-July/msg00450.html
Created attachment 433370 [details] Set stable MAC address based on configured guest MAC addr + high byte set to 0xFE This updated patch uses the MAC address from the guest XML config, with the high byte set to 0xFE. This should prevent the bridge from choosing the TAP MAC over a physical interface MAC, but also gives stable/predictable MAC addresses for the host side TAP device which might be useful.
is there a release eta for the errata package, or alternatively, can the libvirt-0.6.3-35.el5 package be downloaded from somewhere for testing?
> is there a release eta for the errata package, or alternatively, can the > libvirt-0.6.3-35.el5 package be downloaded from somewhere for testing? The fix has already been released in a z-stream errata, see bug 617243 (which is a z-stream clone of this bug).
Fixed in libvirt-0.8.2-1.el5
Verify this bug with libvirt-0.8.2-7.el5 on RHEL5u6-Server X86_64 KVM, and PASSED. Here is my steps: 1. Define a guest with the following mac address. <interface type='bridge'> <mac address='54:52:00:5f:13:5d'/> <source bridge='br0'/> <target dev='vnet0'/> </interface> 2. Start/Destroy guest for several times, bridge mac address is not changed, so host is always keep reachable. Before start guest: # brctl show; ifconfig br0; ifconfig eth0 bridge name bridge id STP enabled interfaces br0 8000.6cf049270c06 no eth0 virbr0 8000.000000000000 yes br0 Link encap:Ethernet HWaddr 6C:F0:49:27:0C:06 inet addr:10.66.92.198 Bcast:10.66.93.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2965341 errors:0 dropped:0 overruns:0 frame:0 TX packets:716135 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4364180849 (4.0 GiB) TX bytes:143366584 (136.7 MiB) eth0 Link encap:Ethernet HWaddr 6C:F0:49:27:0C:06 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2984358 errors:0 dropped:695 overruns:0 frame:0 TX packets:774102 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4408494160 (4.1 GiB) TX bytes:147512158 (140.6 MiB) Interrupt:169 Memory:fc300000-fc320000 Start guest: # virsh start rhel5u5; brctl show; ifconfig br0; ifconfig vnet0 Domain rhel5u5 started bridge name bridge id STP enabled interfaces br0 8000.6cf049270c06 no vnet0 eth0 virbr0 8000.000000000000 yes br0 Link encap:Ethernet HWaddr 6C:F0:49:27:0C:06 inet addr:10.66.92.198 Bcast:10.66.93.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2966275 errors:0 dropped:0 overruns:0 frame:0 TX packets:716686 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:4364300238 (4.0 GiB) TX bytes:143427939 (136.7 MiB) vnet0 Link encap:Ethernet HWaddr FE:52:00:5F:13:5D UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Now libvirt assign MAC address in the upper range (starting with FE:xx) to tap devices to prevent the MAC address of the bridge from changing every time a VM is started or destroyed. So this bug is fixed.
Verified on RHEL5u6-Server-x86_64-kvm and it passed: kernel-2.6.18-228.el5 libvirt-0.8.2-9.el5 kvm-83-199.el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2011-0060.html