Bug 571991
Summary: | QEMU driver should not use the MAC address assigned to tap devices/vnet interfaces by the TAP/TUN driver. | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Nandini Chandra <nachandr> | ||||||
Component: | libvirt | Assignee: | Daniel Veillard <veillard> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | urgent | ||||||||
Version: | 5.5.z | CC: | acathrow, apevec, a.rogge, berrange, bhughes, bugzilla, dallan, dyasny, fleitner, james.brown, jdenemar, jialiu, jplans, llim, olaf, rainer.traut, tao, virt-maint, xen-maint, xhu | ||||||
Target Milestone: | rc | Keywords: | ZStream | ||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | libvirt-0.8.2-1.el5 | Doc Type: | Bug Fix | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | |||||||||
: | 582842 616517 652605 (view as bug list) | Environment: | |||||||
Last Closed: | 2011-01-13 22:55:13 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 617243, 652605 | ||||||||
Attachments: |
|
Description
Nandini Chandra
2010-03-09 22:47:54 UTC
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 |