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

[Markus Armbruster]

Anthony Liguori <address@hidden> writes:

> On 07/07/2011 04:23 AM, Markus Armbruster wrote:
>> Anthony Liguori<address@hidden>  writes:
>>
>>> On 07/06/2011 11:04 AM, 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.
>>>
>>> Because if you did migrate, you would actively break the guest during
>>> migration.  So why is this a problem?
>>>
>>> This comes up a lot.  We shouldn't enable migration if we know the
>>> guest is going to break during migration.  That's a feature, not a
>>> bug.
>>
>> Not so fast :)
>>
>> I agree that throwing away unrecognized migration data is unsafe, and
>> should not be done.  Now let me present my little problem.
>>
>> I'm working on making migration preserve "tray status": open/closed,
>> locked/unlocked.
>>
>> For ide-cd, I can stick a subsection "ide_drive/tray_state" into section
>> "ide_drive".  Needed only if the tray is open or locked.  This gives
>> users a chance to migrate to older versions, and is perfectly safe.
>>
>> scsi-cd doesn't have a section, yet.  What now?
>
> Is that because 'scsi-cd' doesn't need a section or because it hasn't
> been implemented yet?

According to Juan, because it was assumed that qemu_aio_flush() gets us
into a clean, resumable state.