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: Alexander Graf
Subject: Re: [Qemu-devel] migration: new sections and backward compatibility.
Date: Thu, 7 Jul 2011 01:32:45 +0200

On 06.07.2011, at 22:01, Anthony Liguori wrote:

> 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.

Can't we just implicitly fail migration whenever there's a device in the tree 
that doesn't have VMSTATE?


Alex




reply via email to

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