On Wed, May 15, 2013 at 06:53:47PM -0500, Anthony Liguori wrote:
Hi,
On behalf of the QEMU Team, I'd like to announce the availability of the
third release candidate for the QEMU 1.5 release. This release is meant
for testing purposes and should not be used in a production environment.
http://wiki.qemu.org/download/qemu-1.5.0-rc2.tar.bz2
You can help improve the quality of the QEMU 1.5 release by testing this
release and reporting bugs on Launchpad:
Sorry to chime in on this so late in the cycle, but I just noticed what
seems to be a pretty serious problem with migration to/from 1.4. This is
the failure for 1.4 -> 1.5-rc2
(qemu) migrate unix:/tmp/migrate.sock
Unknown savevm section or instance '0000:00:03.0/virtio-net' 0
Configuration:
source: v14/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -L v14-bios -M
pc-i440fx-1.4 -m 512M -kernel boot/vmlinuz-x86_64 -initrd
boot/test-initramfs-x86_64.img.gz -vga std -append seed=1234 -drive
file=disk1.img,if=virtio -drive file=disk2.img,if=virtio -net
nic,model=virtio -net user -monitor unix:/tmp/vm-hmp.sock,server,nowait
-qmp unix:/tmp/vm-qmp.sock,server,nowait -vnc :100
target: v15rc2/x86_64-softmmu/qemu-system-x86_64 -enable-kvm -L temp-bios
-M pc-i440fx-1.4 -m 512M -kernel boot/vmlinuz-x86_64 -initrd
boot/test-initramfs-x86_64.img.gz -vga std -append seed=1234 -drive
file=disk1.img,if=virtio -drive file=disk2.img,if=virtio -net
nic,model=virtio -net user -incoming unix:/tmp/migrate.sock -monitor
unix:/tmp/vm-hmp-incoming.sock,server,nowait -qmp
unix:/tmp/vm-qmp-incoming.sock,server,nowait -vnc :101
QEMU 1.4.0 monitor - type 'help' for more information
This seems to have been introduced with the virtio refactoring:
commit e37da3945fa2fde161e1b217f937fc318c4b7639
Author: KONRAD Frederic <address@hidden>
Date: Thu Apr 11 16:29:58 2013 +0200
virtio-net-pci: switch to the new API.
Here the virtio-net-pci is modified for the new API. The device
virtio-net-pci extends virtio-pci. It creates and connects a
virtio-net-device during the init. The properties are not changed.
Signed-off-by: KONRAD Frederic <address@hidden>
Tested-by: Cornelia Huck <address@hidden>
Message-id: address@hidden
Signed-off-by: Anthony Liguori <address@hidden>
And if we roll that back, we have similar failures for virtio-blk, and most
likely the other virtio devices touched by the refactoring.
The issue seems to be a change the way section id strings are generated in
vmstate_register(). In v1.4.x we had:
se->instance_id: 0, se->idstr: 0000:00:03.0/virtio-net
In v1.5.0-rc2 we have:
se->instance_id: 0, se->idstr: virtio-net
This seems to be due to the fact that these devices now sit on a
TYPE_VIRTIO_BUS that has no implementation of TYPE_BUS's get_dev_path()
interface, which is what savevm uses to calculate the id prefix for
se->idstr.
Prior to the refactoring, the device sat on a TYPE_PCI_BUS which used
pcibus_get_dev_path() to calculate this.
I'm not sure what the best fix is for this. I looking at implementing
get_dev_path() for TYPE_VIRTIO_BUS, but to maintain migration
compatibility we'd end up baking in PCI-specific stuff which from what
I gather is exactly what we were trying to avoid there.
I think adding a compat string property to TYPE_VIRTIO_DEVICE and having
that get set somewhere like virtio_bus_plug_device() is a better
approach, but vmstate_register() gets call during TYPE_VIRTIO_DEVICE
init which I think happens before then.
Still looking at it but if someone more familiar with this code has
some ideas or wants to whip up a patch please jump right in.