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: Thu, 07 Jul 2011 10:37:49 -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/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?

Regards,

Anthony Liguori






reply via email to

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