Re: [Qemu-devel] migration: new sections and backward compatibility.
Hi, Well, in case of usb hid devices breaking the guest isn't that a big issue for at least some guests because they manage to reset the device and continue nevertheless ... In a situation like this, I think our responsibility is to let the user know that there could be a problem, and provide the ability to the user to force the migration. So for instance, you could have a "(qemu) migrate_ignore_section usb" command or something like that. Isn't that a bit overkill? But we shouldn't enable things that may sometimes work by default. I certainly agree on that for the future, thats why there is the patch series which starts tagging devices without migration support. This is about bug compatibility with old qemu versions though. They used to migrate usb devices without saving any state, with surprisingly few issues. cheers, Gerd
Re: [Qemu-devel] migration: new sections and backward compatibility.
On 07/11/2011 05:32 PM, Kevin Wolf wrote: 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? No, the best would be to have a serious migration format, based for example on ASN.1 which Michael Tsirkin was playing with. We cannot keep bolting more and more stuff on top of the current protocol, especially since adding a new protocol is not that hard (old machine types can keep the old protocol). And even more so with the old format being ambiguous. We haven't decided yet what to do with subsections of structs, have we? I hope to test this week the prototype I sent. Paolo
Re: [Qemu-devel] migration: new sections and backward compatibility.
Am 07.07.2011 17:23, schrieb Paolo Bonzini: > On 07/07/2011 01:02 PM, Alexander Graf wrote: >> 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? > > No, the best would be to have a serious migration format, based for > example on ASN.1 which Michael Tsirkin was playing with. We cannot keep > bolting more and more stuff on top of the current protocol, especially > since adding a new protocol is not that hard (old machine types can keep > the old protocol). And even more so with the old format being ambiguous. We haven't decided yet what to do with subsections of structs, have we? Kevin
Re: [Qemu-devel] migration: new sections and backward compatibility.
On 07/08/11 16:43, Peter Maydell wrote: On 8 July 2011 14:02, Jes Sorensen wrote: It seems reasonable to me to introduce a situation where devices have to explicitly marked as migration compatible and fail if there are devices in the system which are not. To ask a dumb question: does "migration" here mean only "migration" or also "vmsave/vmload" ? Both. cheers, Gerd
Re: [Qemu-devel] migration: new sections and backward compatibility.
On 8 July 2011 14:02, Jes Sorensen wrote: > It seems reasonable to me to introduce a situation where devices have to > explicitly marked as migration compatible and fail if there are devices > in the system which are not. To ask a dumb question: does "migration" here mean only "migration" or also "vmsave/vmload" ? -- PMM
Re: [Qemu-devel] migration: new sections and backward compatibility.
On 07/07/11 09:30, Avi Kivity wrote: > On 07/07/2011 10:14 AM, Gerd Hoffmann wrote: >>> Can't we just implicitly fail migration whenever there's a device in >>> the tree that doesn't have VMSTATE? >> >> >> There are cases where the device doesn't need to save state, so that >> alone doesn't cut it. > > It should then say so by having an empty VMSTATE descriptor. It seems reasonable to me to introduce a situation where devices have to explicitly marked as migration compatible and fail if there are devices in the system which are not. Even for the case like USB devices where migration might simply force a replug of the devices. Cheers, Jes
Re: [Qemu-devel] migration: new sections and backward compatibility.
Anthony Liguori writes: > On 07/07/2011 04:23 AM, Markus Armbruster wrote: >> Anthony Liguori 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.
Re: [Qemu-devel] migration: new sections and backward compatibility.
On 07/07/2011 02:19 AM, Gerd Hoffmann wrote: On 07/06/11 19:13, Anthony Liguori wrote: 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? Well, in case of usb hid devices breaking the guest isn't that a big issue for at least some guests because they manage to reset the device and continue nevertheless ... In a situation like this, I think our responsibility is to let the user know that there could be a problem, and provide the ability to the user to force the migration. So for instance, you could have a "(qemu) migrate_ignore_section usb" command or something like that. But we shouldn't enable things that may sometimes work by default. Regards, Anthony Liguori I think this is a case-by-case thing. In some cases we want break migration because critical state is missing. In other cases we might want allow it nevertheless. cheers, Gerd
Re: [Qemu-devel] migration: new sections and backward compatibility.
On 07/06/2011 06:32 PM, Alexander Graf wrote: 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? Not all devices currently implement VMSTATE. Regards, Anthony Liguori Alex
Re: [Qemu-devel] migration: new sections and backward compatibility.
On 07/07/2011 01:02 PM, Alexander Graf wrote: 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? No, the best would be to have a serious migration format, based for example on ASN.1 which Michael Tsirkin was playing with. We cannot keep bolting more and more stuff on top of the current protocol, especially since adding a new protocol is not that hard (old machine types can keep the old protocol). That would of course not help with RHEL:). At least for RHEL6 we can live with adding a few hacks here and there. Paolo
Re: [Qemu-devel] migration: new sections and backward compatibility.
Hi,
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?
Experimental patch for usb attached (actually two, the first is pure
code motion though so the second with the actual changes becomes more
readable).
That makes migration support switchable using a property, so we can use
compatibility properties to disable sending the section to an older version.
That requires usb-hid.c call vmstate_register manually. Not that nice.
We could move the needed() callback from VMStateSubsection to
VMStateDescription, so it is possible to send complete sections
conditionally.
Comments?
cheers,
Gerd
>From adf3fd9f870c5ce5566223e1edfb033c81bd01e4 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann
Date: Thu, 7 Jul 2011 15:49:54 +0200
Subject: [PATCH 1/2] move code
---
hw/usb-hid.c | 86 +-
1 files changed, 43 insertions(+), 43 deletions(-)
diff --git a/hw/usb-hid.c b/hw/usb-hid.c
index d711b5c..f30c96b 100644
--- a/hw/usb-hid.c
+++ b/hw/usb-hid.c
@@ -854,49 +854,6 @@ static void usb_hid_handle_destroy(USBDevice *dev)
}
}
-static int usb_hid_initfn(USBDevice *dev, int kind)
-{
-USBHIDState *s = DO_UPCAST(USBHIDState, dev, dev);
-
-usb_desc_init(dev);
-s->kind = kind;
-
-if (s->kind == USB_MOUSE) {
-s->ptr.eh_entry = qemu_add_mouse_event_handler(usb_pointer_event, s,
- 0, "QEMU USB Mouse");
-} else if (s->kind == USB_TABLET) {
-s->ptr.eh_entry = qemu_add_mouse_event_handler(usb_pointer_event, s,
- 1, "QEMU USB Tablet");
-}
-
-/* Force poll routine to be run and grab input the first time. */
-s->changed = 1;
-return 0;
-}
-
-static int usb_tablet_initfn(USBDevice *dev)
-{
-return usb_hid_initfn(dev, USB_TABLET);
-}
-
-static int usb_mouse_initfn(USBDevice *dev)
-{
-return usb_hid_initfn(dev, USB_MOUSE);
-}
-
-static int usb_keyboard_initfn(USBDevice *dev)
-{
-return usb_hid_initfn(dev, USB_KEYBOARD);
-}
-
-void usb_hid_datain_cb(USBDevice *dev, void *opaque, void (*datain)(void *))
-{
-USBHIDState *s = (USBHIDState *)dev;
-
-s->datain_opaque = opaque;
-s->datain = datain;
-}
-
static int usb_hid_post_load(void *opaque, int version_id)
{
USBHIDState *s = opaque;
@@ -956,6 +913,49 @@ static const VMStateDescription vmstate_usb_kbd = {
}
};
+static int usb_hid_initfn(USBDevice *dev, int kind)
+{
+USBHIDState *s = DO_UPCAST(USBHIDState, dev, dev);
+
+usb_desc_init(dev);
+s->kind = kind;
+
+if (s->kind == USB_MOUSE) {
+s->ptr.eh_entry = qemu_add_mouse_event_handler(usb_pointer_event, s,
+ 0, "QEMU USB Mouse");
+} else if (s->kind == USB_TABLET) {
+s->ptr.eh_entry = qemu_add_mouse_event_handler(usb_pointer_event, s,
+ 1, "QEMU USB Tablet");
+}
+
+/* Force poll routine to be run and grab input the first time. */
+s->changed = 1;
+return 0;
+}
+
+static int usb_tablet_initfn(USBDevice *dev)
+{
+return usb_hid_initfn(dev, USB_TABLET);
+}
+
+static int usb_mouse_initfn(USBDevice *dev)
+{
+return usb_hid_initfn(dev, USB_MOUSE);
+}
+
+static int usb_keyboard_initfn(USBDevice *dev)
+{
+return usb_hid_initfn(dev, USB_KEYBOARD);
+}
+
+void usb_hid_datain_cb(USBDevice *dev, void *opaque, void (*datain)(void *))
+{
+USBHIDState *s = (USBHIDState *)dev;
+
+s->datain_opaque = opaque;
+s->datain = datain;
+}
+
static struct USBDeviceInfo hid_info[] = {
{
.product_desc = "QEMU USB Tablet",
--
1.7.1
>From 8d918be8c56adc099fe4a12e01c5fdfa735df349 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann
Date: Thu, 7 Jul 2011 15:51:40 +0200
Subject: [PATCH 2/2] usb-hid: make migration support conditional
---
hw/usb-hid.c | 23 ---
1 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/hw/usb-hid.c b/hw/usb-hid.c
index f30c96b..81dff27 100644
--- a/hw/usb-hid.c
+++ b/hw/usb-hid.c
@@ -80,6 +80,7 @@ typedef struct USBHIDState {
int32_t protocol;
uint8_t idle;
int64_t next_idle_clock;
+uint32_t migration;
int changed;
void *datain_opaque;
void (*datain)(void *);
@@ -928,6 +929,17 @@ static int usb_hid_initfn(USBDevice *dev, int kind)
1, "QEMU USB Tablet");
}
+if (s->migration) {
+if (s->kind == USB_KEYBOARD) {
+
Re: [Qemu-devel] migration: new sections and backward compatibility.
On 07/07/2011 04:23 AM, Markus Armbruster wrote: Anthony Liguori 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
Re: [Qemu-devel] migration: new sections and backward compatibility.
On 07.07.2011, at 11:23, Markus Armbruster wrote: > Anthony Liguori 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
Re: [Qemu-devel] migration: new sections and backward compatibility.
Anthony Liguori 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?
Re: [Qemu-devel] migration: new sections and backward compatibility.
On 07/07/2011 10:14 AM, Gerd Hoffmann wrote: Can't we just implicitly fail migration whenever there's a device in the tree that doesn't have VMSTATE? There are cases where the device doesn't need to save state, so that alone doesn't cut it. It should then say so by having an empty VMSTATE descriptor. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] migration: new sections and backward compatibility.
On 07/06/11 19:13, Anthony Liguori wrote: 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? Well, in case of usb hid devices breaking the guest isn't that a big issue for at least some guests because they manage to reset the device and continue nevertheless ... I think this is a case-by-case thing. In some cases we want break migration because critical state is missing. In other cases we might want allow it nevertheless. cheers, Gerd
Re: [Qemu-devel] migration: new sections and backward compatibility.
Hi, 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? There are cases where the device doesn't need to save state, so that alone doesn't cut it. cheers, Gerd
Re: [Qemu-devel] migration: new sections and backward compatibility.
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
Re: [Qemu-devel] migration: new sections and backward compatibility.
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. Regards, Anthony Liguori
Re: [Qemu-devel] migration: new sections and backward compatibility.
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? -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] migration: new sections and backward compatibility.
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. Regards, Anthony Liguori
[Qemu-devel] migration: new sections and backward compatibility.
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. Comments? cheers, Gerd
