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

[Anthony Liguori <anthony@codemonkey.ws>]

On 07/06/2011 06:32 PM, Alexander Graf wrote:
>
> 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?

Not all devices currently implement VMSTATE.

Regards,

Anthony Liguori

>
>
> Alex
>
>