[Bug 1848497] Re: virtio-balloon change breaks migration from qemu prior to 4.0
Launchpad Bug Tracker
1848497 at bugs.launchpad.net
Mon Dec 2 11:02:22 UTC 2019
This bug was fixed in the package qemu - 1:4.0+dfsg-0ubuntu9.2
qemu (1:4.0+dfsg-0ubuntu9.2) eoan; urgency=medium
fix a potential hang when qemu or qemu-img where accessing http backed
disks via libcurl (LP: #1848556)
fix migration issue from qemu <4.0 when using virtio-balloon (LP: #1848497)
-- Christian Ehrhardt <christian.ehrhardt at canonical.com> Mon, 21 Oct
2019 14:51:45 +0200
** Changed in: qemu (Ubuntu Eoan)
Status: Fix Committed => Fix Released
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to Ubuntu Cloud Archive.
virtio-balloon change breaks migration from qemu prior to 4.0
Status in Ubuntu Cloud Archive:
Status in qemu package in Ubuntu:
Status in qemu source package in Eoan:
Status in qemu source package in Focal:
* Due to a bug in qemu in 4.0 the config size for virtio-baloon changed.
* This breaks migration from pre 4.0 qemu because the PCI BAR size is
* Upstream has realized this and fixed it in 4.1, this backports the fix
to qemu 4.0 in Ubuntu Eoan
* Take a pre-eoan (pre qemu 4.0) guest and check that your setup can
migrate it back and forth with a eoan/qemu-4.0 target.
Note: (always) use a versioned machine type like pc-i44fx-disco (also
the default if you use disco as source).
Then add a virt-baloon device to the guest on pre-4.0 and migrate it
Unfixed the following error will show up:
get_pci_config_device: Bad config data: i=0x10 read: a1 device: 1 cmask: ff wmask: c0 w1cmask:0
* Unfixed -> Fixed qemu 4.0 migrations should work as well. While the
other way around it could (size didn't change), but there are no
guarantees (no logic in the target).
* Messing with machine types is always dangerous, as in case of a mistake
things get even more complex. But in this case things seemed rather
straight forward. Pre 4.0 code all behaves the same, only 4.0 gets the
new attribute set and later code has logic to handle dynamic sizes.
That way I think we are safe of machine-type regressions.
* For the change in behavior, it changes pre 4.0 migrations, which atm
are broken if a virt-baloon device is present. There is nothing to
break more int hat use case, and if such a device isn't present it
shouldn't change anything. Therefore IMHO safe again.
Related but not the same as bug 1838569 which had two error signatures.
The first being covered there and the second handled here.
Quote from https://bugs.launchpad.net/cloud-archive/+bug/1838569/comments/4
Daniel 'f0o' Preussker (dpreussker) wrote 1 hour ago: #4
With recent release of OpenStack Train this issue reappears...
Upgrading from Stein to Train will require all VMs to be hard-rebooted
to be migrated as a final step because Live Migration fails with:
Oct 17 10:28:43 h2.1.openstack.r0cket.net libvirtd: Unable to read from monitor: Connection reset by peer
Oct 17 10:28:43 h2.1.openstack.r0cket.net libvirtd: internal error: qemu unexpectedly closed the monitor: 2019-10-17T10:28:42.981201Z qemu-system-x86_64: get_pci_config_device: Bad config data: i=0x10 read: a1 device: 1 cmask: ff wmask: c0 w1cmask:0
2019-10-17T10:28:42.981250Z qemu-system-x86_64: Failed to load PCIDevice:config
2019-10-17T10:28:42.981263Z qemu-system-x86_64: Failed to load virtio-balloon:virtio
2019-10-17T10:28:42.981272Z qemu-system-x86_64: error while loading state for instance 0x0 of device '0000:00:05.0/virtio-balloon'
2019-10-17T10:28:42.981391Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2532609 kHz) and host (2532608 kHz), and TSC scaling unavailable
2019-10-17T10:28:42.983157Z qemu-system-x86_64: warning: TSC frequency mismatch between VM (2532609 kHz) and host (2532608 kHz), and TSC scaling unavailable
2019-10-17T10:28:42.983672Z qemu-system-x86_64: load of migration failed: Invalid argument
Dr. David Alan Gilbert (dgilbert-h) wrote 1 hour ago: #5
Dnaiel: That's a different problem; 'Bad config data: i=0x10 read: a1 device: 1 cmask: ff wmask: c0 w1cmask:0'; so should probably be a separate bug.
I'd bet on this being the one fixed by
And that is a fix that only is in qemu 4.1 and would be an open bug
for Ubuntu and Cloud Archive
To manage notifications about this bug go to:
More information about the Ubuntu-openstack-bugs