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 13:02:11 +0200

On 07.07.2011, at 11:23, 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?

I guess the obvious answer would be "There shouldn't be devices that don't have 
a section" :). Not sure how to not break old -M with this though :(. I'd guess 
the best would be to have a special VMSTATE that means "broken old version 
doesn't send a section" which we can set for special -M?

That would of course not help with RHEL :).


Alex




reply via email to

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