Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format

[Kevin Wolf]

Am 26.07.2011 14:37, schrieb Anthony Liguori:
> On 07/26/2011 07:07 AM, Juan Quintela wrote:
>> Anthony Liguori<address@hidden>  wrote:
>>> == What we need ==
>>>
>>> We need to decompose migration into three different problems: 1)
>>> serializing device state 2) transforming the device model in order to
>>> satisfy forwards and backwards compatibility 3) encoding the
>>> serialized device model on the wire.
>>
>> I will change this to:
>> - We need to be able to "enable/disable" features of a device.
>>    A.K.A. make -M pc-0.14 work with devices with the same features
>>    than 0.14.  Notice that this is _independent_ of migration.
> 
> In theory, we already have this with qdev flags.
> 
>> - Be able to describe that different features/versions.  This is not the
>>    difficult part, it can be subsections, optional fields, whatever.
>>    What is the difficult part is _knowing_ what fields needs to be on
>>    each version.  That again depends of the device, not migration.
>>
>> - Be able to to do forward/bacward compatibility (and without
>>    comunication both sides is basically impossible).
> 
> Hrm, I'm not sure I agree with these conclusions.
> 
> Management tools should do their best job to create two compatible 
> device models.
> 
> Given two compatible device models, there *may* be differences in the 
> structure of the device models since we evolve things over time.  We may 
> rename a field, change the type, etc.  To support this, we can use 
> filters both on the destination and receive end to do our best to 
> massage the device model into something compatible.
> 
> But creating two creating compatible device models is not the job of the 
> migration protocol.  It's the job of management tools.

I'm not sure if I agree with this.

Let's forget about management tools for a moment, and just think of a
qemu instance with a given set of command line option describing its
devices. Then you start another instance with different options and
-incoming and start a migration. The result will be something, but
definitely not a successfully migrated VM (even though it might look
like one at first).

This is why I believe that the information about which devices to use
actually belongs into the migration data. There's no way to make use of
it with different options.

>>> 5) Once we're here, we can implement the next 5-year format.  That
>>> could be ASN.1 and be bidirectional or whatever makes the most sense.
>>> We could support 50 formats if we wanted to.  As long as the transport
>>> is distinct from the serialization and compat routines, it really
>>> doesn't matter.
>>
>> This means finishing the VMState support, once there, only thing needs
>> to change is "copy" the savevm, and change the "visitors" to whatever
>> else that we need/want.
> 
> There's no need to "finish" VMState to convert to visitors.  It's just 
> sed -e 's:qemu_put_be32:visit_type_int32:g'

Actually I think the real question is whether we want to have VMState or
not. If we do (and I think it's a good thing), then yes, we need to
finish it. If not, then we should revert the parts that are already
there. We shouldn't end up in an inconsistent state where half of qemu
is converted and we don't feel a need to do anything about the other half.

Kevin