[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Blue Swirl
Subject: Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts
Date: Tue, 24 Nov 2009 19:06:01 +0200

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#.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]