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

[Dor Laor]

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