Anthony Liguori <anth...@codemonkey.ws> writes: > On 07/07/2011 04:23 AM, Markus Armbruster wrote: >> Anthony Liguori<anth...@codemonkey.ws> 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.
