2016-11-14 08:36:13 |
Mehdi Abaakouk |
bug |
|
|
added bug |
2016-11-14 09:13:45 |
Mehdi Abaakouk |
bug task added |
|
cloud-archive |
|
2016-11-14 10:24:09 |
Mehdi Abaakouk |
attachment added |
|
2.3-trusty-machine-fix https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1641532/+attachment/4777159/+files/2.3-trusty-machine-fix |
|
2016-11-14 12:11:53 |
Christian Ehrhardt |
qemu (Ubuntu): status |
New |
Confirmed |
|
2016-11-14 12:11:55 |
Christian Ehrhardt |
qemu (Ubuntu): importance |
Undecided |
Critical |
|
2016-11-14 12:12:06 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Server Team |
2016-11-14 12:13:33 |
Christian Ehrhardt |
summary |
Unknown ramblock "/rom@etc/acpi/rsdp", cannot accept migration |
machine-types trusty and utopic are not unique (depend on the qemu version) |
|
2016-11-14 12:35:57 |
Christian Ehrhardt |
bug |
|
|
added subscriber ChristianEhrhardt |
2017-01-10 15:46:43 |
Christian Ehrhardt |
bug |
|
|
added subscriber James Page |
2017-01-10 15:46:50 |
Christian Ehrhardt |
bug |
|
|
added subscriber Jon Grimm |
2017-01-10 15:48:29 |
Christian Ehrhardt |
bug |
|
|
added subscriber cargonza |
2017-01-10 15:52:51 |
Christian Ehrhardt |
bug |
|
|
added subscriber Mark Baker |
2017-01-17 10:41:02 |
Christian Ehrhardt |
bug task added |
|
qemu-kvm (Ubuntu) |
|
2017-01-17 10:41:19 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Zesty |
|
2017-01-17 10:41:19 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Zesty) |
|
2017-01-17 10:41:19 |
Christian Ehrhardt |
bug task added |
|
qemu-kvm (Ubuntu Zesty) |
|
2017-01-17 10:41:19 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Yakkety |
|
2017-01-17 10:41:19 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Yakkety) |
|
2017-01-17 10:41:19 |
Christian Ehrhardt |
bug task added |
|
qemu-kvm (Ubuntu Yakkety) |
|
2017-01-17 10:41:19 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Xenial |
|
2017-01-17 10:41:19 |
Christian Ehrhardt |
bug task added |
|
qemu (Ubuntu Xenial) |
|
2017-01-17 10:41:19 |
Christian Ehrhardt |
bug task added |
|
qemu-kvm (Ubuntu Xenial) |
|
2017-01-17 10:41:39 |
Christian Ehrhardt |
bug task deleted |
qemu-kvm (Ubuntu) |
|
|
2017-01-17 10:41:53 |
Christian Ehrhardt |
bug task deleted |
qemu-kvm (Ubuntu Xenial) |
|
|
2017-01-17 10:41:58 |
Christian Ehrhardt |
bug task deleted |
qemu-kvm (Ubuntu Yakkety) |
|
|
2017-01-17 10:42:02 |
Christian Ehrhardt |
bug task deleted |
qemu-kvm (Ubuntu Zesty) |
|
|
2017-01-17 10:42:07 |
Christian Ehrhardt |
qemu (Ubuntu Xenial): status |
New |
Confirmed |
|
2017-01-17 10:42:10 |
Christian Ehrhardt |
qemu (Ubuntu Yakkety): status |
New |
Confirmed |
|
2017-01-17 10:42:12 |
Christian Ehrhardt |
qemu (Ubuntu Zesty): status |
Confirmed |
In Progress |
|
2017-01-17 10:42:16 |
Christian Ehrhardt |
qemu (Ubuntu Yakkety): importance |
Undecided |
High |
|
2017-01-17 10:42:17 |
Christian Ehrhardt |
qemu (Ubuntu Xenial): importance |
Undecided |
High |
|
2017-01-25 15:38:04 |
Corey Bryant |
nominated for series |
|
cloud-archive/liberty |
|
2017-01-25 15:38:04 |
Corey Bryant |
bug task added |
|
cloud-archive/liberty |
|
2017-01-25 15:38:17 |
Corey Bryant |
cloud-archive: status |
New |
Confirmed |
|
2017-01-25 15:38:29 |
Corey Bryant |
cloud-archive/liberty: status |
New |
In Progress |
|
2017-01-25 15:38:31 |
Corey Bryant |
cloud-archive/liberty: importance |
Undecided |
Critical |
|
2017-01-30 07:18:19 |
Christian Ehrhardt |
qemu (Ubuntu Yakkety): status |
Confirmed |
In Progress |
|
2017-01-30 07:18:22 |
Christian Ehrhardt |
qemu (Ubuntu Xenial): status |
Confirmed |
In Progress |
|
2017-02-13 10:57:53 |
Launchpad Janitor |
qemu (Ubuntu Zesty): status |
In Progress |
Fix Released |
|
2017-02-13 10:57:53 |
Launchpad Janitor |
cve linked |
|
2016-5403 |
|
2017-02-13 10:57:53 |
Launchpad Janitor |
cve linked |
|
2016-6351 |
|
2017-02-13 10:57:53 |
Launchpad Janitor |
cve linked |
|
2016-6490 |
|
2017-02-13 14:19:19 |
Christian Ehrhardt |
attachment added |
|
logs of the full path testing https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1641532/+attachment/4818217/+files/full-path-testing-as-part-of-merge.tgz |
|
2017-02-13 14:42:10 |
Christian Ehrhardt |
description |
Hi,
I'm currently live-migrating many VMs from an old server to a new one, and some VM can't be live migrated.
The source host is trusty with qemu-system-x86 1:2.3+dfsg-5ubuntu9.4~cloud2
The destination host is xenial with qemu-system-x86 1:2.5+dfsg-5ubuntu10.6
When the issue occurs, the destination host raises an error [1] and stop the migration process.
The only difference I see between VMs where live migration works and those were it doesn't work is a different machine type.
* migration works when VM have been created with pc-i440fx-vivid
* migration doesn't work when VM have been created with pc-i440fx-utopic
[1] the qemu error report by libvirt on the destination host
2016-11-14 08:25:40.774+0000: starting up libvirt version: 1.3.1, package: 1ubuntu10.5 (Stefan Bader <stefan.bader@canonical.com> Thu, 06 Oct 2016 13:07:20 +0200), qemu version: 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.6), hostname: n7.tetaneutral.net
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/bin/kvm-spice -name a81e7133-9601-4432-86dd-a2401dcad8c2 -S -machine pc-i440fx-utopic,accel=kvm,usb=off -cpu Nehalem -m 256 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid a81e7133-9601-4432-86dd-a2401dcad8c2 -smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2015.1.2,serial=fe2641d2-543a-4d65-b75f-6337bf4b8744,uuid=a81e7133-9601-4432-86dd-a2401dcad8c2' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-a81e7133-9601-4432-86dd-a2401dcad8c2/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive 'file=rbd:disks/a81e7133-9601-4432-86dd-a2401dcad8c2_disk.config:id=openstack-service:key=XXXXXXXXXXXX==:auth_supported=cephx\;none:mon_host=192.168.99.251\:6789\;192.168.99.252\:6789\;192.168.99.253\:6789,format=raw,if=none,id=drive-ide0-1-1,readonly=on,cache=none,aio=native' -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -drive 'file=rbd:disks/volume-a82bb407-5ccb-4b0e-ba68-a0de1cd58cc3:id=openstack-service:key=XXXXXXXXXXXXXXXXXX:auth_supported=cephx\;none:mon_host=192.168.99.251\:6789\;192.168.99.252\:6789\;192.168.99.253\:6789,format=raw,if=none,id=drive-virtio-disk0,serial=a82bb407-5ccb-4b0e-ba68-a0de1cd58cc3,cache=none,aio=native' -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=43,id=hostnet0,vhost=on,vhostfd=45 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:37:fb:ba,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/a81e7133-9601-4432-86dd-a2401dcad8c2/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -spice port=5916,addr=0.0.0.0,disable-ticketing,seamless-migration=on -k en-us -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 -incoming defer -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on
2016-11-14T08:25:44.216364Z qemu-system-x86_64: Unknown ramblock "/rom@etc/acpi/rsdp", cannot accept migration
2016-11-14T08:25:44.216394Z qemu-system-x86_64: error while loading state for instance 0x0 of device 'ram'
2016-11-14T08:25:44.216509Z qemu-system-x86_64: load of migration failed: Invalid argument
Cheers, |
[Impact]
* Guests that were created with the Trusty (or Utopic) machine type are
not unique. Due to that on migrations between the qemu versions of
multiple Ubuntu releases migrations fail
* Many migrations work just by luck, one that fails is the Utopic Type on
Cloud-Archive Liberty to Xenial.
* The further one migrates that old guest the more breakage this
accumulates. E.g. a Trusty guest (qemu 2.0) migrated to Xenial
(thinks it is qemu 2.5 type) and from there migrating to Yakkety
(which expects it to be a 2.6 type).
* The fix is minimal and makes the types definition stable across
releases as they were intended
[Test Case]
* Spawn a Guest of Type Utopic (the easiest still supported is Trusty +
Cloud Archive Liberty). And then migrate it to Xenial. Without the
patch migration fail, with the patches it works as both now agree
what the guest definition means. Please do note that both ends of the
migrations have to be fixed to get it working.
* Similar a Guest of type Trusty can with the fixes applied be migrated
X->Y->Z and back to X, while without the fix any backward way (and
probably a future forward way) will fail.
* Note: This is complex and there are many potential combinations - the
testslogs attached have various permutations of those.
It has shown that not only the Utopic type issue that was reported
gets fixed, but several backward migrations as well.
[Regression Potential]
* While it fixes the cases that we know, and as testing showed also
several cases that we didn't know before there are two things we can
not avoid.
1. People have to restart the source guests so that the new fixed
definition will take effect.
But Trusty guests that were already migrated to a Host that has
the error will have to be restarted before they can be migrated
further.
Note: no one has to restart guests on Trusty without Cloud
Archive; there the Trusty type is ok - it is a 2.0 which after
the fix Xenial/Yakkety agree.
2. Restarting the guests after the fix will "downgrade" the virtual
hardware. One can think of the machine types as the HW-revision of
the virtual HW. A Guest that was created as e.g. Trusty these days
on Xenial as incorrectly "too new" virtual HW, restarting the
guest will fix that - but as part of that new attributes that it
incorrectly gained when migrating/moving to the new host will be
taken away (to match the definition the guest had when it was
started)
This is actually a fix, but might appear as a regression to
somebody without knowing what was going on.
Also anybody that "wants" the new HW can just upgrade the machine
type to get it, which is actually recommended anyway [1].
[Other Info]
* This is a complex issue, please catch me (cpaelzer) on IRC if you
need/want to go into detail.
Or for Cloud Archive questions coreycb.
[1]: https://wiki.ubuntu.com/QemuKVMMigration#Upgrade_machine_type
--- original description ---
Hi,
I'm currently live-migrating many VMs from an old server to a new one, and some VM can't be live migrated.
The source host is trusty with qemu-system-x86 1:2.3+dfsg-5ubuntu9.4~cloud2
The destination host is xenial with qemu-system-x86 1:2.5+dfsg-5ubuntu10.6
When the issue occurs, the destination host raises an error [1] and stop the migration process.
The only difference I see between VMs where live migration works and those were it doesn't work is a different machine type.
* migration works when VM have been created with pc-i440fx-vivid
* migration doesn't work when VM have been created with pc-i440fx-utopic
[1] the qemu error report by libvirt on the destination host
2016-11-14 08:25:40.774+0000: starting up libvirt version: 1.3.1, package: 1ubuntu10.5 (Stefan Bader <stefan.bader@canonical.com> Thu, 06 Oct 2016 13:07:20 +0200), qemu version: 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.6), hostname: n7.tetaneutral.net
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/bin/kvm-spice -name a81e7133-9601-4432-86dd-a2401dcad8c2 -S -machine pc-i440fx-utopic,accel=kvm,usb=off -cpu Nehalem -m 256 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid a81e7133-9601-4432-86dd-a2401dcad8c2 -smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2015.1.2,serial=fe2641d2-543a-4d65-b75f-6337bf4b8744,uuid=a81e7133-9601-4432-86dd-a2401dcad8c2' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-a81e7133-9601-4432-86dd-a2401dcad8c2/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive 'file=rbd:disks/a81e7133-9601-4432-86dd-a2401dcad8c2_disk.config:id=openstack-service:key=XXXXXXXXXXXX==:auth_supported=cephx\;none:mon_host=192.168.99.251\:6789\;192.168.99.252\:6789\;192.168.99.253\:6789,format=raw,if=none,id=drive-ide0-1-1,readonly=on,cache=none,aio=native' -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -drive 'file=rbd:disks/volume-a82bb407-5ccb-4b0e-ba68-a0de1cd58cc3:id=openstack-service:key=XXXXXXXXXXXXXXXXXX:auth_supported=cephx\;none:mon_host=192.168.99.251\:6789\;192.168.99.252\:6789\;192.168.99.253\:6789,format=raw,if=none,id=drive-virtio-disk0,serial=a82bb407-5ccb-4b0e-ba68-a0de1cd58cc3,cache=none,aio=native' -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=43,id=hostnet0,vhost=on,vhostfd=45 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:37:fb:ba,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/a81e7133-9601-4432-86dd-a2401dcad8c2/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -spice port=5916,addr=0.0.0.0,disable-ticketing,seamless-migration=on -k en-us -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 -incoming defer -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on
2016-11-14T08:25:44.216364Z qemu-system-x86_64: Unknown ramblock "/rom@etc/acpi/rsdp", cannot accept migration
2016-11-14T08:25:44.216394Z qemu-system-x86_64: error while loading state for instance 0x0 of device 'ram'
2016-11-14T08:25:44.216509Z qemu-system-x86_64: load of migration failed: Invalid argument
Cheers, |
|
2017-02-13 14:43:21 |
Christian Ehrhardt |
description |
[Impact]
* Guests that were created with the Trusty (or Utopic) machine type are
not unique. Due to that on migrations between the qemu versions of
multiple Ubuntu releases migrations fail
* Many migrations work just by luck, one that fails is the Utopic Type on
Cloud-Archive Liberty to Xenial.
* The further one migrates that old guest the more breakage this
accumulates. E.g. a Trusty guest (qemu 2.0) migrated to Xenial
(thinks it is qemu 2.5 type) and from there migrating to Yakkety
(which expects it to be a 2.6 type).
* The fix is minimal and makes the types definition stable across
releases as they were intended
[Test Case]
* Spawn a Guest of Type Utopic (the easiest still supported is Trusty +
Cloud Archive Liberty). And then migrate it to Xenial. Without the
patch migration fail, with the patches it works as both now agree
what the guest definition means. Please do note that both ends of the
migrations have to be fixed to get it working.
* Similar a Guest of type Trusty can with the fixes applied be migrated
X->Y->Z and back to X, while without the fix any backward way (and
probably a future forward way) will fail.
* Note: This is complex and there are many potential combinations - the
testslogs attached have various permutations of those.
It has shown that not only the Utopic type issue that was reported
gets fixed, but several backward migrations as well.
[Regression Potential]
* While it fixes the cases that we know, and as testing showed also
several cases that we didn't know before there are two things we can
not avoid.
1. People have to restart the source guests so that the new fixed
definition will take effect.
But Trusty guests that were already migrated to a Host that has
the error will have to be restarted before they can be migrated
further.
Note: no one has to restart guests on Trusty without Cloud
Archive; there the Trusty type is ok - it is a 2.0 which after
the fix Xenial/Yakkety agree.
2. Restarting the guests after the fix will "downgrade" the virtual
hardware. One can think of the machine types as the HW-revision of
the virtual HW. A Guest that was created as e.g. Trusty these days
on Xenial as incorrectly "too new" virtual HW, restarting the
guest will fix that - but as part of that new attributes that it
incorrectly gained when migrating/moving to the new host will be
taken away (to match the definition the guest had when it was
started)
This is actually a fix, but might appear as a regression to
somebody without knowing what was going on.
Also anybody that "wants" the new HW can just upgrade the machine
type to get it, which is actually recommended anyway [1].
[Other Info]
* This is a complex issue, please catch me (cpaelzer) on IRC if you
need/want to go into detail.
Or for Cloud Archive questions coreycb.
[1]: https://wiki.ubuntu.com/QemuKVMMigration#Upgrade_machine_type
--- original description ---
Hi,
I'm currently live-migrating many VMs from an old server to a new one, and some VM can't be live migrated.
The source host is trusty with qemu-system-x86 1:2.3+dfsg-5ubuntu9.4~cloud2
The destination host is xenial with qemu-system-x86 1:2.5+dfsg-5ubuntu10.6
When the issue occurs, the destination host raises an error [1] and stop the migration process.
The only difference I see between VMs where live migration works and those were it doesn't work is a different machine type.
* migration works when VM have been created with pc-i440fx-vivid
* migration doesn't work when VM have been created with pc-i440fx-utopic
[1] the qemu error report by libvirt on the destination host
2016-11-14 08:25:40.774+0000: starting up libvirt version: 1.3.1, package: 1ubuntu10.5 (Stefan Bader <stefan.bader@canonical.com> Thu, 06 Oct 2016 13:07:20 +0200), qemu version: 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.6), hostname: n7.tetaneutral.net
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/bin/kvm-spice -name a81e7133-9601-4432-86dd-a2401dcad8c2 -S -machine pc-i440fx-utopic,accel=kvm,usb=off -cpu Nehalem -m 256 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid a81e7133-9601-4432-86dd-a2401dcad8c2 -smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2015.1.2,serial=fe2641d2-543a-4d65-b75f-6337bf4b8744,uuid=a81e7133-9601-4432-86dd-a2401dcad8c2' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-a81e7133-9601-4432-86dd-a2401dcad8c2/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive 'file=rbd:disks/a81e7133-9601-4432-86dd-a2401dcad8c2_disk.config:id=openstack-service:key=XXXXXXXXXXXX==:auth_supported=cephx\;none:mon_host=192.168.99.251\:6789\;192.168.99.252\:6789\;192.168.99.253\:6789,format=raw,if=none,id=drive-ide0-1-1,readonly=on,cache=none,aio=native' -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -drive 'file=rbd:disks/volume-a82bb407-5ccb-4b0e-ba68-a0de1cd58cc3:id=openstack-service:key=XXXXXXXXXXXXXXXXXX:auth_supported=cephx\;none:mon_host=192.168.99.251\:6789\;192.168.99.252\:6789\;192.168.99.253\:6789,format=raw,if=none,id=drive-virtio-disk0,serial=a82bb407-5ccb-4b0e-ba68-a0de1cd58cc3,cache=none,aio=native' -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=43,id=hostnet0,vhost=on,vhostfd=45 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:37:fb:ba,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/a81e7133-9601-4432-86dd-a2401dcad8c2/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -spice port=5916,addr=0.0.0.0,disable-ticketing,seamless-migration=on -k en-us -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 -incoming defer -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on
2016-11-14T08:25:44.216364Z qemu-system-x86_64: Unknown ramblock "/rom@etc/acpi/rsdp", cannot accept migration
2016-11-14T08:25:44.216394Z qemu-system-x86_64: error while loading state for instance 0x0 of device 'ram'
2016-11-14T08:25:44.216509Z qemu-system-x86_64: load of migration failed: Invalid argument
Cheers, |
[Impact]
* Guests that were created with the Trusty (or Utopic) machine type are
not unique. Due to that on migrations between the qemu versions of
multiple Ubuntu releases migrations fail
* Many migrations work just by luck, one that fails is the Utopic Type on
Cloud-Archive Liberty to Xenial.
* The further one migrates that old guest the more breakage this
accumulates. E.g. a Trusty guest (qemu 2.0) migrated to Xenial
(thinks it is qemu 2.5 type) and from there migrating to Yakkety
(which expects it to be a 2.6 type).
* The fix is minimal and makes the types definition stable across
releases as they were intended
[Test Case]
* Spawn a Guest of Type Utopic (the easiest still supported is Trusty +
Cloud Archive Liberty). And then migrate it to Xenial. Without the
patch migration fail, with the patches it works as both now agree
what the guest definition means. Please do note that both ends of the
migrations have to be fixed to get it working.
* Similar a Guest of type Trusty can with the fixes applied be migrated
X->Y->Z and back to X, while without the fix any backward way (and
probably a future forward way) will fail.
* Note: This is complex and there are many potential combinations - the
testlogs (comment #15) attached have various permutations of those.
It has shown that not only the Utopic type issue that was reported
gets fixed, but several backward migrations as well.
[Regression Potential]
* While it fixes the cases that we know, and as testing showed also
several cases that we didn't know before there are two things we can
not avoid.
1. People have to restart the source guests so that the new fixed
definition will take effect.
But Trusty guests that were already migrated to a Host that has
the error will have to be restarted before they can be migrated
further.
Note: no one has to restart guests on Trusty without Cloud
Archive; there the Trusty type is ok - it is a 2.0 which after
the fix Xenial/Yakkety agree.
2. Restarting the guests after the fix will "downgrade" the virtual
hardware. One can think of the machine types as the HW-revision of
the virtual HW. A Guest that was created as e.g. Trusty these days
on Xenial as incorrectly "too new" virtual HW, restarting the
guest will fix that - but as part of that new attributes that it
incorrectly gained when migrating/moving to the new host will be
taken away (to match the definition the guest had when it was
started)
This is actually a fix, but might appear as a regression to
somebody without knowing what was going on.
Also anybody that "wants" the new HW can just upgrade the machine
type to get it, which is actually recommended anyway [1].
[Other Info]
* This is a complex issue, please catch me (cpaelzer) on IRC if you
need/want to go into detail.
Or for Cloud Archive questions coreycb.
[1]: https://wiki.ubuntu.com/QemuKVMMigration#Upgrade_machine_type
--- original description ---
Hi,
I'm currently live-migrating many VMs from an old server to a new one, and some VM can't be live migrated.
The source host is trusty with qemu-system-x86 1:2.3+dfsg-5ubuntu9.4~cloud2
The destination host is xenial with qemu-system-x86 1:2.5+dfsg-5ubuntu10.6
When the issue occurs, the destination host raises an error [1] and stop the migration process.
The only difference I see between VMs where live migration works and those were it doesn't work is a different machine type.
* migration works when VM have been created with pc-i440fx-vivid
* migration doesn't work when VM have been created with pc-i440fx-utopic
[1] the qemu error report by libvirt on the destination host
2016-11-14 08:25:40.774+0000: starting up libvirt version: 1.3.1, package: 1ubuntu10.5 (Stefan Bader <stefan.bader@canonical.com> Thu, 06 Oct 2016 13:07:20 +0200), qemu version: 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.6), hostname: n7.tetaneutral.net
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/bin/kvm-spice -name a81e7133-9601-4432-86dd-a2401dcad8c2 -S -machine pc-i440fx-utopic,accel=kvm,usb=off -cpu Nehalem -m 256 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid a81e7133-9601-4432-86dd-a2401dcad8c2 -smbios 'type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=2015.1.2,serial=fe2641d2-543a-4d65-b75f-6337bf4b8744,uuid=a81e7133-9601-4432-86dd-a2401dcad8c2' -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-a81e7133-9601-4432-86dd-a2401dcad8c2/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive 'file=rbd:disks/a81e7133-9601-4432-86dd-a2401dcad8c2_disk.config:id=openstack-service:key=XXXXXXXXXXXX==:auth_supported=cephx\;none:mon_host=192.168.99.251\:6789\;192.168.99.252\:6789\;192.168.99.253\:6789,format=raw,if=none,id=drive-ide0-1-1,readonly=on,cache=none,aio=native' -device ide-cd,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1 -drive 'file=rbd:disks/volume-a82bb407-5ccb-4b0e-ba68-a0de1cd58cc3:id=openstack-service:key=XXXXXXXXXXXXXXXXXX:auth_supported=cephx\;none:mon_host=192.168.99.251\:6789\;192.168.99.252\:6789\;192.168.99.253\:6789,format=raw,if=none,id=drive-virtio-disk0,serial=a82bb407-5ccb-4b0e-ba68-a0de1cd58cc3,cache=none,aio=native' -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=43,id=hostnet0,vhost=on,vhostfd=45 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:37:fb:ba,bus=pci.0,addr=0x3 -chardev file,id=charserial0,path=/var/lib/nova/instances/a81e7133-9601-4432-86dd-a2401dcad8c2/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -spice port=5916,addr=0.0.0.0,disable-ticketing,seamless-migration=on -k en-us -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16,bus=pci.0,addr=0x2 -incoming defer -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on
2016-11-14T08:25:44.216364Z qemu-system-x86_64: Unknown ramblock "/rom@etc/acpi/rsdp", cannot accept migration
2016-11-14T08:25:44.216394Z qemu-system-x86_64: error while loading state for instance 0x0 of device 'ram'
2016-11-14T08:25:44.216509Z qemu-system-x86_64: load of migration failed: Invalid argument
Cheers, |
|
2017-02-13 21:59:50 |
James Page |
cloud-archive: status |
Confirmed |
Fix Committed |
|
2017-02-15 14:35:10 |
Chris J Arges |
qemu (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
2017-02-15 14:35:15 |
Chris J Arges |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
2017-02-15 14:35:23 |
Chris J Arges |
bug |
|
|
added subscriber SRU Verification |
2017-02-15 14:35:31 |
Chris J Arges |
tags |
|
verification-needed |
|
2017-02-15 14:36:42 |
Chris J Arges |
qemu (Ubuntu Yakkety): status |
In Progress |
Fix Committed |
|
2017-02-20 08:03:26 |
Christian Ehrhardt |
tags |
verification-needed |
verification-done verification-done-xenial verification-done-yakkety |
|
2017-02-22 20:37:57 |
Launchpad Janitor |
qemu (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
2017-02-22 20:38:08 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
2017-02-22 20:39:22 |
Launchpad Janitor |
qemu (Ubuntu Yakkety): status |
Fix Committed |
Fix Released |
|
2017-02-23 19:46:00 |
James Page |
cloud-archive/liberty: status |
In Progress |
Fix Committed |
|
2017-02-23 19:46:01 |
James Page |
tags |
verification-done verification-done-xenial verification-done-yakkety |
verification-done verification-done-xenial verification-done-yakkety verification-liberty-needed |
|
2017-03-01 11:40:09 |
Christian Ehrhardt |
tags |
verification-done verification-done-xenial verification-done-yakkety verification-liberty-needed |
verification-done verification-done-xenial verification-done-yakkety verification-liberty-done |
|
2017-03-01 12:02:05 |
James Page |
cloud-archive/liberty: status |
Fix Committed |
Fix Released |
|
2017-03-01 21:38:05 |
Corey Bryant |
cloud-archive: status |
Fix Committed |
Fix Released |
|