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

[Dor Laor <dlaor@redhat.com>]

On 07/31/2011 11:43 PM, Anthony Liguori wrote:
> On 07/31/2011 05:48 AM, Dor Laor wrote:
>> On 07/30/2011 01:28 AM, Anthony Liguori wrote:
>>> No, not at all. Just that converting everything to VMState isn't a
>>> prerequisite for building a more robust migration protocol.
>>
>> The main thing is to priorities the problems we're facing with.
>> - Live migration protocol:
>> - VMState conversion is not complete
>
> But this is not a problem because it doesn't gate anything. That's my
> point.

The VMState might be an exception but in general we have too many 
unfinished businesses going on.

>
>> - Live migration is not flexible enough (even with subsections)
>
> To make it more flexible, we need to be able to marshal to an internal
> data structure that we can transform in more flexible ways.
>
>> - Simplify destination cmdline for machine creation
>
> This needs qdev fixing.
>
>> - Qdev
>> - conversion is not complete
>> - Machine + devices description are complex and have hidden glue
>
> This is a hard problem.
>
>> - Qapi
>> - Needs merging
>
> We merged the first part (which includes the new QMP server). The work
> is done for converting the actual QMP commands.
>
>> - QOB
>> - Only the beginning
>>
>> So overall there are many parallel projects, probably more than the
>> above. The RightThink(tm) would be to pick the ones that we can converge
>> on and not try to handle all in parallel. There are problems we can live
>> with. Engineering wise it might not be a beauty but they can wait (for
>> instance dark magic to create the machines). There are some that prevent
>> adding new features or make the code hard to support w/o them.
>>
>> Cheers,
>> Dor
>>
>> ps: how hard is to finish the vmstate conversion? Can't we just assume
>> not converted code is not functional and just remove all of it?
>
> No. VMState is a solution looking for a problem. Many important device

The initial target solved some rare bugs, that tend not to bite us with 
virtio. On the way, it got enhanced with subsections that was a major 
improvement.

> models are still not converted and ultimately, it doesn't solve the
> problem we're really trying to solve.

 From the start I supported Michael Tisrkin's idea for ASN.1 protocol.
The question is how visitors and ability to translate from one 
representation to another will help us. I do see value in it but I don't 
think it is that important. If we have one real device serialization 
method that is flexible enough we can stick with it w/o translation. If 
we define qdev serialization into vmstate/asn.1/json/other and add some 
capability negotiation and various other goodies it should be enough.

btw: separating the live migration protocol from the machine state is 
even more important if we take a gradual approach.

>
> Regards,
>
> Anthony Liguori
>
>>
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>
>>
>>
>
>