[Qemu-devel] migration: new sections and backward compatibility.

[Qemu-devel] migration: new sections and backward compatibility.

[Gerd Hoffmann]

   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

Re: [Qemu-devel] migration: new sections and backward compatibility.

[Anthony Liguori]

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

Re: [Qemu-devel] migration: new sections and backward compatibility.

[Gerd Hoffmann]

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.

[Anthony Liguori]

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.

[Gerd Hoffmann]

   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.

[Markus Armbruster]

Anthony Liguori <anthony@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?

Re: [Qemu-devel] migration: new sections and backward compatibility.

[Alexander Graf]

On 07.07.2011, at 11:23, Markus Armbruster wrote:

> Anthony Liguori <anthony@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?

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.

[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).

> 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.

[Kevin Wolf]

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.

[Paolo Bonzini]

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.

[Gerd Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

   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

[-- Attachment #2: 0001-move-code.patch --]
[-- Type: text/plain, Size: 3112 bytes --]

>From adf3fd9f870c5ce5566223e1edfb033c81bd01e4 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann <kraxel@redhat.com>
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


[-- Attachment #3: 0002-usb-hid-make-migration-support-conditional.patch --]
[-- Type: text/plain, Size: 3490 bytes --]

>From 8d918be8c56adc099fe4a12e01c5fdfa735df349 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann <kraxel@redhat.com>
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) {
+            vmstate_register(&dev->qdev, -1, &vmstate_usb_kbd, dev);
+        } else {
+            vmstate_register(&dev->qdev, -1, &vmstate_usb_ptr, dev);
+        }
+    } else {
+        /* disable remote-wakeup */
+        usb_desc_set_string(dev, STR_SERIALNUMBER, "1");
+    }
+
     /* Force poll routine to be run and grab input the first time.  */
     s->changed = 1;
     return 0;
@@ -956,13 +968,17 @@ void usb_hid_datain_cb(USBDevice *dev, void *opaque, void (*datain)(void *))
     s->datain = datain;
 }
 
+static struct Property hid_props[] = {
+    DEFINE_PROP_UINT32("migration", USBHIDState, migration, 1),
+    DEFINE_PROP_END_OF_LIST(),
+};
+
 static struct USBDeviceInfo hid_info[] = {
     {
         .product_desc   = "QEMU USB Tablet",
         .qdev.name      = "usb-tablet",
         .usbdevice_name = "tablet",
         .qdev.size      = sizeof(USBHIDState),
-        .qdev.vmsd      = &vmstate_usb_ptr,
         .usb_desc       = &desc_tablet,
         .init           = usb_tablet_initfn,
         .handle_packet  = usb_generic_handle_packet,
@@ -970,12 +986,12 @@ static struct USBDeviceInfo hid_info[] = {
         .handle_control = usb_hid_handle_control,
         .handle_data    = usb_hid_handle_data,
         .handle_destroy = usb_hid_handle_destroy,
+        .qdev.props     = hid_props,
     },{
         .product_desc   = "QEMU USB Mouse",
         .qdev.name      = "usb-mouse",
         .usbdevice_name = "mouse",
         .qdev.size      = sizeof(USBHIDState),
-        .qdev.vmsd      = &vmstate_usb_ptr,
         .usb_desc       = &desc_mouse,
         .init           = usb_mouse_initfn,
         .handle_packet  = usb_generic_handle_packet,
@@ -983,12 +999,12 @@ static struct USBDeviceInfo hid_info[] = {
         .handle_control = usb_hid_handle_control,
         .handle_data    = usb_hid_handle_data,
         .handle_destroy = usb_hid_handle_destroy,
+        .qdev.props     = hid_props,
     },{
         .product_desc   = "QEMU USB Keyboard",
         .qdev.name      = "usb-kbd",
         .usbdevice_name = "keyboard",
         .qdev.size      = sizeof(USBHIDState),
-        .qdev.vmsd      = &vmstate_usb_kbd,
         .usb_desc       = &desc_keyboard,
         .init           = usb_keyboard_initfn,
         .handle_packet  = usb_generic_handle_packet,
@@ -996,6 +1012,7 @@ static struct USBDeviceInfo hid_info[] = {
         .handle_control = usb_hid_handle_control,
         .handle_data    = usb_hid_handle_data,
         .handle_destroy = usb_hid_handle_destroy,
+        .qdev.props     = hid_props,
     },{
         /* end of list */
     }
-- 
1.7.1

Re: [Qemu-devel] migration: new sections and backward compatibility.

[Anthony Liguori]

On 07/07/2011 04:23 AM, Markus Armbruster wrote:
> Anthony Liguori<anthony@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?

Regards,

Anthony Liguori

>

Re: [Qemu-devel] migration: new sections and backward compatibility.

[Markus Armbruster]

Anthony Liguori <anthony@codemonkey.ws> writes:

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

Re: [Qemu-devel] migration: new sections and backward compatibility.

[Avi Kivity]

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.

[Anthony Liguori]

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.

[Alexander Graf]

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.

[Gerd Hoffmann]

   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.

[Avi Kivity]

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.

[Jes Sorensen]

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.

[Peter Maydell]

On 8 July 2011 14:02, Jes Sorensen <Jes.Sorensen@redhat.com> 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.

[Gerd Hoffmann]

On 07/08/11 16:43, Peter Maydell wrote:
> On 8 July 2011 14:02, Jes Sorensen<Jes.Sorensen@redhat.com>  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.

[Anthony Liguori]

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