Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts

[Michael S. Tsirkin]

On Tue, Nov 24, 2009 at 07:06:01PM +0200, Blue Swirl wrote:
> On Tue, Nov 24, 2009 at 4:21 PM, Michael S. Tsirkin <address@hidden> wrote:
> > On Tue, Nov 24, 2009 at 01:59:49PM +0000, Paul Brook wrote:
> >> > > Reading in old state files is a whole lot easier (to write
> >> > > maintain, and stay sane) than producing state that is bug-compatible 
> >> > > with
> >> > > previous versions.
> >> >
> >> > It seems to me that old->new and new->old migrations are
> >> > of about the same level of difficulty.
> >> > Supporting one of these but not the other is of course
> >> > easier than supporting both, but I don't see where
> >> > "a whole lot" comes from.
> >>
> >> Migrating from old version requires the restore routine be version aware.
> >> Migrating to old versions requires the the save routine also be version 
> >> aware,
> >> which I'd expect to be about double the amount of work.
> >>
> >> Paul
> >
> > Heh, it seems the question is whether double is a lot or not :)
> >
> > The advantage of both save and restore being version aware
> > is that you can do light compatibility testing without
> > having an old qemu lying around.
> > This is not enough, but better than nothing.
> 
> I think the best for us would be if we could make the translator
> between versions an external tool with a separate project.
> 
> Supporting only the current version would make QEMU simpler to
> maintain, any backward compatibility baggage could be thrown out.
> 
> The external version translator tool could support arbitrary
> conversion between the whole NxN matrix of versions (including distro
> hacks), or just those that RHEL happens to use. The tool would not be
> limited to QEMU development environment, it could use databases, XSLT,
> SOA or be written in C#.

Yea, maybe cross-hypervisor migration could be made to work :)
All that would be possible if the migration protocol would
be specified at some level. As it is, the protocol
really dumps out internal infromation about current
qemu implementation, and it seems that making
it a separate project would just slow us down.

-- 
MST