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? Alex
