[Qemu-devel] new->old version migration

[Qemu-devel] new->old version migration

[Michael S. Tsirkin]

New thread stated intentionally, the original patch is Message-ID:
<349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.shah@redhat.com>

On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote:
> Add a compat property for older machine types.  When this is used (via
> -M pc-0.13, for example), the new flow control mechanisms will not be
> used.  This is done to keep migration from a machine started with older
> type on a pc-0.14+ qemu to an older machine working.
> 
> The property is named 'flow_control' and defaults to on.
> 
> Reported-by: Alex Williamson <alex.williamson@redhat.com>
> Signed-off-by: Amit Shah <amit.shah@redhat.com>

So, I think there are two things that need to be agreed on:

- Can we commit to support migration from new qemu version to an old one?
  We haven't in the past but downstreams do want this,
  so it makes sense to have the infrastructure upstream.

- The infrastructure/command line option for such support.
  We have the -M flags to describe the machine that
  we are running, but that abstracts away guest-visible machine,
  which the migration format is not.
  Also, same qemu could migrate to any older version.
  So I think we would have to add a flag (call it -V for now)
  to savevm/migrate commands to specify the format to be used.
  Naturally some machines would be incompatible with
  specific -V values, that's nothing new.

Pls comment.

-- 
MST

[Qemu-devel] Re: new->old version migration

[Alex Williamson]

On Mon, 2011-02-07 at 18:07 +0200, Michael S. Tsirkin wrote:
> New thread stated intentionally, the original patch is Message-ID:
> <349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.shah@redhat.com>
> 
> On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote:
> > Add a compat property for older machine types.  When this is used (via
> > -M pc-0.13, for example), the new flow control mechanisms will not be
> > used.  This is done to keep migration from a machine started with older
> > type on a pc-0.14+ qemu to an older machine working.
> > 
> > The property is named 'flow_control' and defaults to on.
> > 
> > Reported-by: Alex Williamson <alex.williamson@redhat.com>
> > Signed-off-by: Amit Shah <amit.shah@redhat.com>
> 
> So, I think there are two things that need to be agreed on:
> 
> - Can we commit to support migration from new qemu version to an old one?
>   We haven't in the past but downstreams do want this,
>   so it makes sense to have the infrastructure upstream.

I think lack of testing is the primary thing preventing this.  We can
catch things like this in code review, but it's hard to commit to
support it if we can't reliably catch problems.  This one, we did catch,
and I think it's useful to put Amit's fix upstream, even if other
devices end up having issues.

> - The infrastructure/command line option for such support.
>   We have the -M flags to describe the machine that
>   we are running, but that abstracts away guest-visible machine,
>   which the migration format is not.
>   Also, same qemu could migrate to any older version.
>   So I think we would have to add a flag (call it -V for now)
>   to savevm/migrate commands to specify the format to be used.
>   Naturally some machines would be incompatible with
>   specific -V values, that's nothing new.

This seems unnecessarily complicated.  It makes sense to me that we
should track both the guest visible machine and the migration data
format with the same option.  In fact, I can't think of a good reason
for these ever being different and how we'd support it if they were.
There's plenty wrong with the migration data format, but that's a longer
term discussion, and I think this is appropriate given what we have
today.

Alex

[Qemu-devel] Re: new->old version migration

[Michael S. Tsirkin]

On Mon, Feb 07, 2011 at 09:40:14AM -0700, Alex Williamson wrote:
> On Mon, 2011-02-07 at 18:07 +0200, Michael S. Tsirkin wrote:
> > New thread stated intentionally, the original patch is Message-ID:
> > <349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.shah@redhat.com>
> > 
> > On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote:
> > > Add a compat property for older machine types.  When this is used (via
> > > -M pc-0.13, for example), the new flow control mechanisms will not be
> > > used.  This is done to keep migration from a machine started with older
> > > type on a pc-0.14+ qemu to an older machine working.
> > > 
> > > The property is named 'flow_control' and defaults to on.
> > > 
> > > Reported-by: Alex Williamson <alex.williamson@redhat.com>
> > > Signed-off-by: Amit Shah <amit.shah@redhat.com>
> > 
> > So, I think there are two things that need to be agreed on:
> > 
> > - Can we commit to support migration from new qemu version to an old one?
> >   We haven't in the past but downstreams do want this,
> >   so it makes sense to have the infrastructure upstream.
> 
> I think lack of testing is the primary thing preventing this.  We can
> catch things like this in code review, but it's hard to commit to
> support it if we can't reliably catch problems.  This one, we did catch,
> and I think it's useful to put Amit's fix upstream, even if other
> devices end up having issues.

It's not just testing.  Look at the specific example. The requirement
for new->old migration makes us keep broken code without flow control
around.  This will only increase with time and the mess here
is not limited to vmstate, unlike the old->new format which
generally makes us do conversion at load time, so it's contained.

> > - The infrastructure/command line option for such support.
> >   We have the -M flags to describe the machine that
> >   we are running, but that abstracts away guest-visible machine,
> >   which the migration format is not.
> >   Also, same qemu could migrate to any older version.
> >   So I think we would have to add a flag (call it -V for now)
> >   to savevm/migrate commands to specify the format to be used.
> >   Naturally some machines would be incompatible with
> >   specific -V values, that's nothing new.
> 
> This seems unnecessarily complicated.  It makes sense to me that we
> should track both the guest visible machine and the migration data
> format with the same option.  In fact, I can't think of a good reason
> for these ever being different and how we'd support it if they were.
> There's plenty wrong with the migration data format, but that's a longer
> term discussion, and I think this is appropriate given what we have
> today.
> 
> Alex
> 

Take the specific example. 0.13 has trouble under stress, it loses data.
-M 0.13 is needed if you created the guest under 0.14, to make upgrading
hypervisors seamless.

This patch would force disabling flow control which
is not needed if both version being migrated between
are 0.14.


-- 
MST

[Qemu-devel] Re: new->old version migration

[Anthony Liguori]

On 02/07/2011 10:51 AM, Michael S. Tsirkin wrote:
> On Mon, Feb 07, 2011 at 09:40:14AM -0700, Alex Williamson wrote:
>    
>> On Mon, 2011-02-07 at 18:07 +0200, Michael S. Tsirkin wrote:
>>      
>>> New thread stated intentionally, the original patch is Message-ID:
>>> <349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.shah@redhat.com>
>>>
>>> On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote:
>>>        
>>>> Add a compat property for older machine types.  When this is used (via
>>>> -M pc-0.13, for example), the new flow control mechanisms will not be
>>>> used.  This is done to keep migration from a machine started with older
>>>> type on a pc-0.14+ qemu to an older machine working.
>>>>
>>>> The property is named 'flow_control' and defaults to on.
>>>>
>>>> Reported-by: Alex Williamson<alex.williamson@redhat.com>
>>>> Signed-off-by: Amit Shah<amit.shah@redhat.com>
>>>>          
>>> So, I think there are two things that need to be agreed on:
>>>
>>> - Can we commit to support migration from new qemu version to an old one?
>>>    We haven't in the past but downstreams do want this,
>>>    so it makes sense to have the infrastructure upstream.
>>>        
>> I think lack of testing is the primary thing preventing this.  We can
>> catch things like this in code review, but it's hard to commit to
>> support it if we can't reliably catch problems.  This one, we did catch,
>> and I think it's useful to put Amit's fix upstream, even if other
>> devices end up having issues.
>>      
> It's not just testing.  Look at the specific example. The requirement
> for new->old migration makes us keep broken code without flow control
> around.  This will only increase with time and the mess here
> is not limited to vmstate, unlike the old->new format which
> generally makes us do conversion at load time, so it's contained.
>    

I haven't looked closely at the specific example but subsections allow 
us to migrate a state only when it's value is not what the old version 
defaults to.  This is the only way we can have our cake and eat it too.  
Anything less compromises integrity.

Regards,

Anthony Liguori

>    
>>> - The infrastructure/command line option for such support.
>>>    We have the -M flags to describe the machine that
>>>    we are running, but that abstracts away guest-visible machine,
>>>    which the migration format is not.
>>>    Also, same qemu could migrate to any older version.
>>>    So I think we would have to add a flag (call it -V for now)
>>>    to savevm/migrate commands to specify the format to be used.
>>>    Naturally some machines would be incompatible with
>>>    specific -V values, that's nothing new.
>>>        
>> This seems unnecessarily complicated.  It makes sense to me that we
>> should track both the guest visible machine and the migration data
>> format with the same option.  In fact, I can't think of a good reason
>> for these ever being different and how we'd support it if they were.
>> There's plenty wrong with the migration data format, but that's a longer
>> term discussion, and I think this is appropriate given what we have
>> today.
>>
>> Alex
>>
>>      
> Take the specific example. 0.13 has trouble under stress, it loses data.
> -M 0.13 is needed if you created the guest under 0.14, to make upgrading
> hypervisors seamless.
>
> This patch would force disabling flow control which
> is not needed if both version being migrated between
> are 0.14.
>
>
>    

[Qemu-devel] Re: new->old version migration

[Anthony Liguori]

On 02/07/2011 10:07 AM, Michael S. Tsirkin wrote:
> New thread stated intentionally, the original patch is Message-ID:
> <349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.shah@redhat.com>
>
> On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote:
>    
>> Add a compat property for older machine types.  When this is used (via
>> -M pc-0.13, for example), the new flow control mechanisms will not be
>> used.  This is done to keep migration from a machine started with older
>> type on a pc-0.14+ qemu to an older machine working.
>>
>> The property is named 'flow_control' and defaults to on.
>>
>> Reported-by: Alex Williamson<alex.williamson@redhat.com>
>> Signed-off-by: Amit Shah<amit.shah@redhat.com>
>>      
> So, I think there are two things that need to be agreed on:
>
> - Can we commit to support migration from new qemu version to an old one?
>    We haven't in the past but downstreams do want this,
>    so it makes sense to have the infrastructure upstream.
>    

Only within a stable release series and only when it's possible without 
sacrificing integrity.  I know some downstreams disagree with this but I 
don't think this is a business we want to get into.

Regards,

Anthony Liguori

> - The infrastructure/command line option for such support.
>    We have the -M flags to describe the machine that
>    we are running, but that abstracts away guest-visible machine,
>    which the migration format is not.
>    Also, same qemu could migrate to any older version.
>    So I think we would have to add a flag (call it -V for now)
>    to savevm/migrate commands to specify the format to be used.
>    Naturally some machines would be incompatible with
>    specific -V values, that's nothing new.
>
> Pls comment.
>
>    

[Qemu-devel] Re: new->old version migration

[Michael S. Tsirkin]

On Mon, Feb 07, 2011 at 01:33:57PM -0600, Anthony Liguori wrote:
> On 02/07/2011 10:07 AM, Michael S. Tsirkin wrote:
> >New thread stated intentionally, the original patch is Message-ID:
> ><349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.shah@redhat.com>
> >
> >On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote:
> >>Add a compat property for older machine types.  When this is used (via
> >>-M pc-0.13, for example), the new flow control mechanisms will not be
> >>used.  This is done to keep migration from a machine started with older
> >>type on a pc-0.14+ qemu to an older machine working.
> >>
> >>The property is named 'flow_control' and defaults to on.
> >>
> >>Reported-by: Alex Williamson<alex.williamson@redhat.com>
> >>Signed-off-by: Amit Shah<amit.shah@redhat.com>
> >So, I think there are two things that need to be agreed on:
> >
> >- Can we commit to support migration from new qemu version to an old one?
> >   We haven't in the past but downstreams do want this,
> >   so it makes sense to have the infrastructure upstream.
> 
> Only within a stable release series and only when it's possible
> without sacrificing integrity.  I know some downstreams disagree
> with this but I don't think this is a business we want to get into.
> 
> Regards,
> 
> Anthony Liguori
> >- The infrastructure/command line option for such support.
> >   We have the -M flags to describe the machine that
> >   we are running, but that abstracts away guest-visible machine,
> >   which the migration format is not.
> >   Also, same qemu could migrate to any older version.
> >   So I think we would have to add a flag (call it -V for now)
> >   to savevm/migrate commands to specify the format to be used.
> >   Naturally some machines would be incompatible with
> >   specific -V values, that's nothing new.
> >
> >Pls comment.

OK, assuming we want this, let's talk about implementation.
I think that spreading custom flags all over the code like
this patch does would be pretty bad.

What I'd like to see is a way to
- map stable versions (e.g. machine type if we are going
  to tie to that)  to savevm format using
  some kind of table
- for save callbacks to be able to figure out what
  version to use

-- 
MST

[Qemu-devel] Re: new->old version migration

[Anthony Liguori]

On 02/07/2011 01:53 PM, Michael S. Tsirkin wrote:
> On Mon, Feb 07, 2011 at 01:33:57PM -0600, Anthony Liguori wrote:
>    
>> On 02/07/2011 10:07 AM, Michael S. Tsirkin wrote:
>>      
>>> New thread stated intentionally, the original patch is Message-ID:
>>> <349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.shah@redhat.com>
>>>
>>> On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote:
>>>        
>>>> Add a compat property for older machine types.  When this is used (via
>>>> -M pc-0.13, for example), the new flow control mechanisms will not be
>>>> used.  This is done to keep migration from a machine started with older
>>>> type on a pc-0.14+ qemu to an older machine working.
>>>>
>>>> The property is named 'flow_control' and defaults to on.
>>>>
>>>> Reported-by: Alex Williamson<alex.williamson@redhat.com>
>>>> Signed-off-by: Amit Shah<amit.shah@redhat.com>
>>>>          
>>> So, I think there are two things that need to be agreed on:
>>>
>>> - Can we commit to support migration from new qemu version to an old one?
>>>    We haven't in the past but downstreams do want this,
>>>    so it makes sense to have the infrastructure upstream.
>>>        
>> Only within a stable release series and only when it's possible
>> without sacrificing integrity.  I know some downstreams disagree
>> with this but I don't think this is a business we want to get into.
>>
>> Regards,
>>
>> Anthony Liguori
>>      
>>> - The infrastructure/command line option for such support.
>>>    We have the -M flags to describe the machine that
>>>    we are running, but that abstracts away guest-visible machine,
>>>    which the migration format is not.
>>>    Also, same qemu could migrate to any older version.
>>>    So I think we would have to add a flag (call it -V for now)
>>>    to savevm/migrate commands to specify the format to be used.
>>>    Naturally some machines would be incompatible with
>>>    specific -V values, that's nothing new.
>>>
>>> Pls comment.
>>>        
> OK, assuming we want this, let's talk about implementation.
> I think that spreading custom flags all over the code like
> this patch does would be pretty bad.
>
> What I'd like to see is a way to
> - map stable versions (e.g. machine type if we are going
>    to tie to that)  to savevm format using
>    some kind of table
> - for save callbacks to be able to figure out what
>    version to use
>    

Why doesn't subsections already solve this problem?

Regards,

Anthony Liguori

[Qemu-devel] Re: new->old version migration

[Michael S. Tsirkin]

On Mon, Feb 07, 2011 at 02:56:50PM -0600, Anthony Liguori wrote:
> On 02/07/2011 01:53 PM, Michael S. Tsirkin wrote:
> >On Mon, Feb 07, 2011 at 01:33:57PM -0600, Anthony Liguori wrote:
> >>On 02/07/2011 10:07 AM, Michael S. Tsirkin wrote:
> >>>New thread stated intentionally, the original patch is Message-ID:
> >>><349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.shah@redhat.com>
> >>>
> >>>On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote:
> >>>>Add a compat property for older machine types.  When this is used (via
> >>>>-M pc-0.13, for example), the new flow control mechanisms will not be
> >>>>used.  This is done to keep migration from a machine started with older
> >>>>type on a pc-0.14+ qemu to an older machine working.
> >>>>
> >>>>The property is named 'flow_control' and defaults to on.
> >>>>
> >>>>Reported-by: Alex Williamson<alex.williamson@redhat.com>
> >>>>Signed-off-by: Amit Shah<amit.shah@redhat.com>
> >>>So, I think there are two things that need to be agreed on:
> >>>
> >>>- Can we commit to support migration from new qemu version to an old one?
> >>>   We haven't in the past but downstreams do want this,
> >>>   so it makes sense to have the infrastructure upstream.
> >>Only within a stable release series and only when it's possible
> >>without sacrificing integrity.  I know some downstreams disagree
> >>with this but I don't think this is a business we want to get into.
> >>
> >>Regards,
> >>
> >>Anthony Liguori
> >>>- The infrastructure/command line option for such support.
> >>>   We have the -M flags to describe the machine that
> >>>   we are running, but that abstracts away guest-visible machine,
> >>>   which the migration format is not.
> >>>   Also, same qemu could migrate to any older version.
> >>>   So I think we would have to add a flag (call it -V for now)
> >>>   to savevm/migrate commands to specify the format to be used.
> >>>   Naturally some machines would be incompatible with
> >>>   specific -V values, that's nothing new.
> >>>
> >>>Pls comment.
> >OK, assuming we want this, let's talk about implementation.
> >I think that spreading custom flags all over the code like
> >this patch does would be pretty bad.
> >
> >What I'd like to see is a way to
> >- map stable versions (e.g. machine type if we are going
> >   to tie to that)  to savevm format using
> >   some kind of table
> >- for save callbacks to be able to figure out what
> >   version to use
> 
> Why doesn't subsections already solve this problem?
> 
> Regards,
> 
> Anthony Liguori


How does it? We need to know we are saving in 0.13
format and skip the new subsection, otherwise
0.13 will see a subsection it does not recognize
and exit.

We also need API to add subsections without vmstate,
because virtio serial wasn't yet converted.

-- 
MST

[Qemu-devel] Re: new->old version migration

[Anthony Liguori]

On 02/07/2011 03:52 PM, Michael S. Tsirkin wrote:
> How does it? We need to know we are saving in 0.13
> format and skip the new subsection, otherwise
> 0.13 will see a subsection it does not recognize
> and exit.
>    

If you used subsections for flow control, presumably you would only send 
the new savevm data if you had data buffered.

If you add a qdev property to enable/disable flow control, then if it's 
disabled, you naturally would never send the subsection because you'd 
never buffer data.  So no explicit code is needed to support migration.

The difficult case is when you truly need to change the savevm version.  
I don't think we have a proper fix for this because versions are linear 
so the proposed patch certainly wouldn't be a good way to do it.  if 
flow_control=0 causes savevm 3 to be used instead of 4, and then the 
next_feature=0 causes savevm 4 to be used instead of 5, the semantics of 
flow_control=0,next_feature=1 becomes problematic.

But as long as the feature has isolated state, we can solve the problem 
robustly with subsections.

Regards,

Anthony Liguori

> We also need API to add subsections without vmstate,
> because virtio serial wasn't yet converted.
>
>    

[Qemu-devel] Re: new->old version migration

[Michael S. Tsirkin]

On Mon, Feb 07, 2011 at 08:23:08PM -0600, Anthony Liguori wrote:
> On 02/07/2011 03:52 PM, Michael S. Tsirkin wrote:
> >How does it? We need to know we are saving in 0.13
> >format and skip the new subsection, otherwise
> >0.13 will see a subsection it does not recognize
> >and exit.
> 
> If you used subsections for flow control, presumably you would only
> send the new savevm data if you had data buffered.
> 
> If you add a qdev property to enable/disable flow control, then if
> it's disabled, you naturally would never send the subsection because
> you'd never buffer data.  So no explicit code is needed to support
> migration.

But the result is we get a new property that we can never remove
as any qdev property is part of interface.

> The difficult case is when you truly need to change the savevm
> version.  I don't think we have a proper fix for this because
> versions are linear so the proposed patch certainly wouldn't be a
> good way to do it.  if flow_control=0 causes savevm 3 to be used
> instead of 4, and then the next_feature=0 causes savevm 4 to be used
> instead of 5, the semantics of flow_control=0,next_feature=1 becomes
> problematic.
> 
> But as long as the feature has isolated state, we can solve the
> problem robustly with subsections.
> 
> Regards,
> 
> Anthony Liguori

I see. I'm unhappy with the facts that
1. if (feature) is spread all over the code instead
   of just in migration
2. it is also obfuscated with if (flow_control)
   instead of plain if (migrate to qemu < 0.14)
   so removing it will be much harder
3. this forces anyone who wants
   a VM compatible with qemu 0.13 to also lose data,
   even if migration to 0.13 is never attempted.

> >We also need API to add subsections without vmstate,
> >because virtio serial wasn't yet converted.
> >

[Qemu-devel] Re: new->old version migration

[Amit Shah]

On (Tue) 08 Feb 2011 [08:42:14], Michael S. Tsirkin wrote:
> I see. I'm unhappy with the facts that
> 1. if (feature) is spread all over the code instead
>    of just in migration
> 2. it is also obfuscated with if (flow_control)
>    instead of plain if (migrate to qemu < 0.14)
>    so removing it will be much harder
> 3. this forces anyone who wants
>    a VM compatible with qemu 0.13 to also lose data,
>    even if migration to 0.13 is never attempted.

If a machine is started with -M pc-0.13 then we can safely assume the
user will want to migrate to another 0.13 machine.

Also, flow control is not part of qemu yet.  This code ensures that when
flow control lands, we'll be ready to use it.

So there's 0 difference with this code to a user that runs with -M
pc-0.13.  But this code will ensure a user running with 0.15 and 0.14
can migrate among the two machine types with and without flow control
being available (assuming chardev flow control lands in 0.15).

		Amit

Re: [Qemu-devel] Re: new->old version migration

[Anthony Liguori]

On 02/08/2011 01:07 AM, Amit Shah wrote:
> On (Tue) 08 Feb 2011 [08:42:14], Michael S. Tsirkin wrote:
>    
>> I see. I'm unhappy with the facts that
>> 1. if (feature) is spread all over the code instead
>>     of just in migration
>> 2. it is also obfuscated with if (flow_control)
>>     instead of plain if (migrate to qemu<  0.14)
>>     so removing it will be much harder
>> 3. this forces anyone who wants
>>     a VM compatible with qemu 0.13 to also lose data,
>>     even if migration to 0.13 is never attempted.
>>      
> If a machine is started with -M pc-0.13 then we can safely assume the
> user will want to migrate to another 0.13 machine.
>    

No, a user wants a guest that works.  If there was a bug in 0.13 and 
it's fixed in 0.14, then reintroducing the bug in -M pc-0.13 is not 
expected.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: new->old version migration

[Amit Shah]

On (Tue) 08 Feb 2011 [01:44:32], Anthony Liguori wrote:
> On 02/08/2011 01:07 AM, Amit Shah wrote:
> >On (Tue) 08 Feb 2011 [08:42:14], Michael S. Tsirkin wrote:
> >>I see. I'm unhappy with the facts that
> >>1. if (feature) is spread all over the code instead
> >>    of just in migration
> >>2. it is also obfuscated with if (flow_control)
> >>    instead of plain if (migrate to qemu<  0.14)
> >>    so removing it will be much harder
> >>3. this forces anyone who wants
> >>    a VM compatible with qemu 0.13 to also lose data,
> >>    even if migration to 0.13 is never attempted.
> >If a machine is started with -M pc-0.13 then we can safely assume the
> >user will want to migrate to another 0.13 machine.
> 
> No, a user wants a guest that works.  If there was a bug in 0.13 and
> it's fixed in 0.14, then reintroducing the bug in -M pc-0.13 is not
> expected.

For this particular patch and use-case, the bug exists in 0.13 as well
as 0.14.  It's just the migration state that has changed, no other
guest- or host- visible changes.

		Amit

Re: [Qemu-devel] Re: new->old version migration

[Anthony Liguori]

On 02/08/2011 12:42 AM, Michael S. Tsirkin wrote:
> On Mon, Feb 07, 2011 at 08:23:08PM -0600, Anthony Liguori wrote:
>    
>> On 02/07/2011 03:52 PM, Michael S. Tsirkin wrote:
>>      
>>> How does it? We need to know we are saving in 0.13
>>> format and skip the new subsection, otherwise
>>> 0.13 will see a subsection it does not recognize
>>> and exit.
>>>        
>> If you used subsections for flow control, presumably you would only
>> send the new savevm data if you had data buffered.
>>
>> If you add a qdev property to enable/disable flow control, then if
>> it's disabled, you naturally would never send the subsection because
>> you'd never buffer data.  So no explicit code is needed to support
>> migration.
>>      
> But the result is we get a new property that we can never remove
> as any qdev property is part of interface.
>
>    
>> The difficult case is when you truly need to change the savevm
>> version.  I don't think we have a proper fix for this because
>> versions are linear so the proposed patch certainly wouldn't be a
>> good way to do it.  if flow_control=0 causes savevm 3 to be used
>> instead of 4, and then the next_feature=0 causes savevm 4 to be used
>> instead of 5, the semantics of flow_control=0,next_feature=1 becomes
>> problematic.
>>
>> But as long as the feature has isolated state, we can solve the
>> problem robustly with subsections.
>>
>> Regards,
>>
>> Anthony Liguori
>>      
> I see. I'm unhappy with the facts that
> 1. if (feature) is spread all over the code instead
>     of just in migration
>    

Yeah, but it's no different than say msi enablement.

> 2. it is also obfuscated with if (flow_control)
>     instead of plain if (migrate to qemu<  0.14)
>     so removing it will be much harder
> 3. this forces anyone who wants
>     a VM compatible with qemu 0.13 to also lose data,
>     even if migration to 0.13 is never attempted.
>    

It depends on whether we consider flow control a feature or a bug.  If 
it's a bug, then we have to bump the live migration version and then 
live with the compatibility breakage.

Regards,

Anthony Liguori

>>> We also need API to add subsections without vmstate,
>>> because virtio serial wasn't yet converted.
>>>
>>>        
>    

Re: [Qemu-devel] Re: new->old version migration

[Michael S. Tsirkin]

On Tue, Feb 08, 2011 at 01:42:59AM -0600, Anthony Liguori wrote:
> On 02/08/2011 12:42 AM, Michael S. Tsirkin wrote:
> >On Mon, Feb 07, 2011 at 08:23:08PM -0600, Anthony Liguori wrote:
> >>On 02/07/2011 03:52 PM, Michael S. Tsirkin wrote:
> >>>How does it? We need to know we are saving in 0.13
> >>>format and skip the new subsection, otherwise
> >>>0.13 will see a subsection it does not recognize
> >>>and exit.
> >>If you used subsections for flow control, presumably you would only
> >>send the new savevm data if you had data buffered.
> >>
> >>If you add a qdev property to enable/disable flow control, then if
> >>it's disabled, you naturally would never send the subsection because
> >>you'd never buffer data.  So no explicit code is needed to support
> >>migration.
> >But the result is we get a new property that we can never remove
> >as any qdev property is part of interface.
> >
> >>The difficult case is when you truly need to change the savevm
> >>version.  I don't think we have a proper fix for this because
> >>versions are linear so the proposed patch certainly wouldn't be a
> >>good way to do it.  if flow_control=0 causes savevm 3 to be used
> >>instead of 4, and then the next_feature=0 causes savevm 4 to be used
> >>instead of 5, the semantics of flow_control=0,next_feature=1 becomes
> >>problematic.
> >>
> >>But as long as the feature has isolated state, we can solve the
> >>problem robustly with subsections.
> >>
> >>Regards,
> >>
> >>Anthony Liguori
> >I see. I'm unhappy with the facts that
> >1. if (feature) is spread all over the code instead
> >    of just in migration
> 
> Yeah, but it's no different than say msi enablement.

I think it's different, some guests might have bad support for msi,
so ability to disable it in qemu is useful.

> >2. it is also obfuscated with if (flow_control)
> >    instead of plain if (migrate to qemu<  0.14)
> >    so removing it will be much harder
> >3. this forces anyone who wants
> >    a VM compatible with qemu 0.13 to also lose data,
> >    even if migration to 0.13 is never attempted.
> 
> It depends on whether we consider flow control a feature or a bug.
> If it's a bug, then we have to bump the live migration version and
> then live with the compatibility breakage.
> 
> Regards,
> 
> Anthony Liguori

I'm not sure. I don't see how it's useful to drop frames but maybe I'm wrong.
Amit?

> 
> >>>We also need API to add subsections without vmstate,
> >>>because virtio serial wasn't yet converted.
> >>>