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

[Anthony Liguori]

On 07/31/2011 03:43 PM, Dor Laor wrote:
> On 07/31/2011 09:46 PM, Christoph Hellwig wrote:
> > On Sun, Jul 31, 2011 at 02:45:07PM +0300, Dor Laor wrote:
> > > > No, definitely not. I think most people using non-x86 architectures
> > > > don't use the vmsave/vmload/migration features at all, but would
> > > > be annoyed if the perfectly functional device models they were
> > > > using got deleted...
> > >
> > > I didn't mean to erase the entire device, just the code for save/load
> > > which
> > > as you say, might not be used at all.
> >
> > Like the one in virtio?
>
> /me caught off guard. I wonder why it wasn't converted to VMSTATE
> before? virtio is one of the key devices, it's not just random forgotten
> one that might not care about migration.
>
> It's worth to utilize this discussion to realize whether vmstate is
> significant enough.

VMState does two things.  It provides a common code path for save/load. 
 This is wonderful and it absolutely has prevent numerous bugs from 
happening.  Undeniably, it's made migration better and more robust 
because of that.

It also provides a declarative description of the serialization state. 
The declarative language has gotten complex and it's still not quite 
covering everything we do (there's a lot of one-off marshalling handlers 
to handle corner cases).

I think we've basically gotten as much as we can with the declarative 
approach.  I think we have to take the next logical step which is to use 
the declarative descriptions (or imperative marshallers) to generate a 
richer internal representation that we can manipulate in a high level 
fashion.

We could keep trying to make everything declarative but that in and of 
itself does not get us to the next step with improving migration.  And 
it shouldn't gate us either.

>  From my brief browsing it looks like vmstate helps to reduce some plain
> errors with double save/load coding, ease the field encoding and handles
> subsections (which imho is the most important).

I think we need to really step back and look at the larger picture.

What do we really need to "fix" migration?  I've given this a ton of 
thought, and I think there's really two classes of problems:

1) Creating the same guest visible device model in two, potentially 
different, versions of QEMU.

2) Given an identical guest visible device model, coping with variations 
in the internal implementation and state serialization.

Subsections and versions are solutions to (2), but limited to the scope 
of an individual device (and really, individual fields).  We completely 
punt (1) to management tools.

You need a comprehensive object model to solve (1).  I'm convinced of 
that.  To solve (2), we need to be able to separate compatibility from 
internal implementation.

To me, this means migrating to an internal data structure and then 
manipulating that data structure before/after transferring it over the wire.

> It's true that we need to introduce capabilities to the live migration
> protocol and some other goodies but we might be able to do that with
> the existing method of gradual enhancement for VMSTATE to whatever form
> it may be.

I've already written this up:

http://wiki.qemu.org/Features/Migration/Next

Regards,

Anthony Liguori

>