[Bug 579892] Re: libvirt should not use the MAC address assigned to tap devices/vnet interfaces by the TAP/TUN driver

Serge Hallyn 579892 at bugs.launchpad.net
Tue Mar 1 17:57:04 UTC 2011


@Marcelo,

regarding comment #11:  it sure sounds like a good workaround.  Have you
been using it, and can you verify that it works for you?

** Description changed:

  On Ubuntu 10.04 I have problems using libvirt with a bridge because the
  TUN devices get random mac addresses and thus, change the bridge device
  mac address, which takes the lower mac addres of all devices attached to
  the bridge. The main and most critical problem is that, sometimes, we
  lose network connectivity for several seconds (usually 10-20 seconds) on
  the libvirt host and all its guests when a guest is powered off.
  
  Searching for similar problems I found my problem described at
  https://bugzilla.redhat.com/show_bug.cgi?id=571991
  
- Impact: Random loss of network connectivity on guest power on/off.
+ =====================================================
+ SRU Justification:
  
- Fix: This bug was fixed upstream and in maverick, using the same patch
-      (modulo porting0 which is added by the debdiff attached here.  It
-      forces libvirt to ensure that the bridge mac address is lower than
-      that of any of its devices.
+ 1. Impact: Random loss of network connectivity on guest power on/off.
  
- Patch: debdiff is attached
+ 2. Fix: This bug was fixed upstream and in maverick, using the same patch
+      (modulo porting0 which is added by the debdiff attached here.  It
+      forces libvirt to ensure that the bridge mac address is lower than
+      that of any of its devices.
  
- Instructions: Power bridged guests on/off in libvirt, while continuously
-       checking network connectivity to existing guests.
+ 3. Patch: debdiff is attached, and a bzr tree is linked.
  
- Regression: The patch itself should definately be safe, since it is
-       ported from the fix in the redhat bug.
+ 4. Instructions: Power bridged guests on/off in libvirt, while continuously
+       checking network connectivity to existing guests.
+ 
+ 5. Regression: The patch itself should definately be safe, since it is
+       ported from the fix in the redhat bug.
+ =====================================================

** Tags added: verification-needed

** Description changed:

  On Ubuntu 10.04 I have problems using libvirt with a bridge because the
  TUN devices get random mac addresses and thus, change the bridge device
  mac address, which takes the lower mac addres of all devices attached to
  the bridge. The main and most critical problem is that, sometimes, we
  lose network connectivity for several seconds (usually 10-20 seconds) on
  the libvirt host and all its guests when a guest is powered off.
  
  Searching for similar problems I found my problem described at
  https://bugzilla.redhat.com/show_bug.cgi?id=571991
  
  =====================================================
  SRU Justification:
  
  1. Impact: Random loss of network connectivity on guest power on/off.
  
  2. Fix: This bug was fixed upstream and in maverick, using the same patch
       (modulo porting0 which is added by the debdiff attached here.  It
       forces libvirt to ensure that the bridge mac address is lower than
       that of any of its devices.
  
- 3. Patch: debdiff is attached, and a bzr tree is linked.
+ 3. Patch: debdiff is attached.
  
  4. Instructions: Power bridged guests on/off in libvirt, while continuously
        checking network connectivity to existing guests.
  
  5. Regression: The patch itself should definately be safe, since it is
        ported from the fix in the redhat bug.
  =====================================================

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to libvirt in ubuntu.
https://bugs.launchpad.net/bugs/579892

Title:
   libvirt should not use the MAC address assigned to tap devices/vnet
  interfaces by the TAP/TUN driver



More information about the Ubuntu-server-bugs mailing list