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

[Anthony Liguori <anthony@codemonkey.ws>]

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