qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] migration: new sections and backward compatibility.


From: Anthony Liguori
Subject: Re: [Qemu-devel] migration: new sections and backward compatibility.
Date: Wed, 06 Jul 2011 15:01:58 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10

On 07/06/2011 12:28 PM, Avi Kivity wrote:
On 07/06/2011 07:04 PM, Gerd Hoffmann wrote:
Hi folks,

We'll need to figure a sane way to handle migration to older versions
with new sections, i.e. devices which used to not save state before do
now.

We already have one case in tree: usb. qemu 0.14 saves state for
usb-hid devices and the usb-hub, whereas qemu 0.13 and older don't.
You can't migrate a vm with a usb-tablet from 0.14 to 0.13 because of
that even if you use -M pc-0.13.

More cases are lurking. AHCI doesn't support migration today but
probably will some day. Markus mentioned that scsi-disk will face that
issue too. And that list probably isn't complete.

Subsections don't help here as there is no toplevel section in the
first place.

Ideas anyone? Maybe allow test functions like we have for subsections
for toplevel sections too, so we have a way to skip the section
altogether on savevm?

We probably also want a way to fail the migration in case the target
machine doesn't support migration for $device, especially for $device
== ahci to avoid data loss. For the usb-tablet it isn't that
problematic, in the best case the guest just resets the device and
goes on, in the worst case the mouse is dead.


How did AHCI get in without migration? It's relatively new, is it not?

We don't have a hard policy about not merging devices that don't support migration.

Since migration must be supported forever, I'd rather see a device get some solid testing before it starts doing live migration. That said, we should probably do this consciously by explicitly marking the device non-migrateable.

Regards,

Anthony Liguori






reply via email to

[Prev in Thread] Current Thread [Next in Thread]