[Bug 1656480] Re: QEMU Does not Send L2 Broadcasts After Live Migration

Andy Whitcroft apw at canonical.com
Wed Jan 25 12:27:42 UTC 2017


Hello Dmitrii, or anyone else affected,

Accepted qemu into xenial-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/qemu/1:2.5+dfsg-
5ubuntu10.8 in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

** Changed in: qemu (Ubuntu Xenial)
       Status: In Progress => Fix Committed

** Tags added: verification-needed

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1656480

Title:
  QEMU Does not Send L2 Broadcasts After Live Migration

Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Xenial:
  Fix Committed

Bug description:
  [Impact]
  L2 broadcasts are sent out in order to update MAC tables of the switches in the same broadcast domain. If this is not done after live migration there may be a temporary downtime period for clients trying to connect to services residing on a migrated VM due to the fact that switches will still forward frames to the old destination. It will also lead to varying behaviors depending on the operating system or software installed in the guest OS with regards to network activity: there may be cases when VM's network activity will force the MAC table update across the L2 network but this is not guaranteed.

  [Test case]
  Steps are provided in the bug description.

  [Regression Potential]
  Small: the change is trivial and is present both in the upstream QEMU and the newer ubuntu releases. This is also not a heavily changing code path in the upstream.

  --

  In short:
  1) Get two Xenial hosts (instead, could be two lxd containers with QEMU inside or two VMs with nested virtualization enabled - doesn't matter);
  1) Create a libvirt domain that uses QEMU (can be a bare instance, even without a disk, with a NIC without an IP address since we are testing L2 broadcasts);
  2) Launch an instance;
  3) Start listening for RARP packets on the destination host's bridge (QEMU uses a RARP L3 header and a broadcast L2 header which is easy to filter as no other software sends RARPs nowadays);
  3) Do virsh migrate --live domain desturi;
  4) Observe that no RARP packets are sent.

  The expected result (QEMU actually sends 5 of those, grep for
  SELF_ANNOUNCE_ROUNDS == 5 in the sources):

  sudo tcpdump -e -i br0 rarp
  tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
  listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
  18:19:32.460765 52:54:00:25:49:b7 (oui Unknown) > Broadcast, ethertype Reverse ARP (0x8035), length 60: Reverse Request who-is 52:54:00:25:49:b7 (oui Unknown) tell 52:54:00:25:49:b7 (oui Unknown), length 46
  18:19:32.504609 52:54:00:25:49:b7 (oui Unknown) > Broadcast, ethertype Reverse ARP (0x8035), length 60: Reverse Request who-is 52:54:00:25:49:b7 (oui Unknown) tell 52:54:00:25:49:b7 (oui Unknown), length

  ---
  lsb_release -r
  Release:	16.04

  dpkg --status qemu-kvm | grep Version
  Version: 1:2.5+dfsg-5ubuntu10.6
  --

  Fortunately, there is already a fix for this:
  https://lists.gnu.org/archive/html/qemu-devel/2016-07/msg04645.html

  http://git.qemu.org/?p=qemu.git;a=commitdiff;h=ca1ee3d6b546e841a1b9db413eb8fa09f13a061b;hp=14e60aaece20a1cfc059a69f6491b0899f9257a8

  The issue was introduced in fefe2a78abde932e0f340b21bded2c86def1d242:
  http://git.qemu.org/?p=qemu.git;a=commitdiff;h=fefe2a78abde932e0f340b21bded2c86def1d242

  $ apt-get source qemu

  # we are looking at qemu_2.5+dfsg debian branch
  $ ls qemu*dsc
  qemu_2.5+dfsg-5ubuntu10.6.dsc

  $ git remote show origin | grep Fetch
    Fetch URL: git://anonscm.debian.org/pkg-qemu/qemu.git

  $ git checkout debian/qemu_2.5+dfsg-5
  HEAD is now at aa4dbf2... Uploading version 2.5+dfsg-5 to unstable

  The commit that introduced the issue is present in qemu_2.5+dfsg-5.
  $ git merge-base --is-ancestor fefe2a78abde932e0f340b21bded2c86def1d242 HEAD ; echo $?
  0

  There are no patches for it:

  grep -RiP 'QEMU_NET_PACKET_FLAG_RAW' qemu-2.5+dfsg/debian/patches/ ; echo $?
  1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1656480/+subscriptions




More information about the Ubuntu-sponsors mailing list