qemu-devel
[Top][All Lists]
Advanced

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

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


From: Dor Laor
Subject: Re: [Qemu-devel] [RFC PATCH 0/4] Fix subsection ambiguity in the migration format
Date: Mon, 01 Aug 2011 00:25:12 +0300
User-agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110707 Thunderbird/5.0

On 08/01/2011 12:03 AM, Anthony Liguori wrote:
On 07/31/2011 03:57 PM, Dor Laor wrote:
On 07/31/2011 11:43 PM, Anthony Liguori wrote:
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.

I should have qualified my statement. VMState did solve many real
problems. I meant that at this point in time, we've gotten pretty much
what we can get out it.


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.

Because with Visitors you can do:

Devices -> internal QObject representation -> ASN.1 -> wire -> ASN.1 ->
internal QObject representation -> Device.

I admit that QObject sounds more appealing than VMState, we can convert all into it. I'm not sure what's the difference between visitor and the load/save functions, potentially with enhanced parameters like name which can be part of QObject anyway.


While it's in an internal representation, we can make large changes like
translating entire device state structures to new formats, splitting one
device into two, etc.

It's sort of the ultimate mechanism to make compatibility changes. If
you just go Devices -> ASN.1, you miss out on that.

What's important in ASN.1 is not the data representation itself but the ability to have a flexible protocol. We can have it with VMState and QObject as well. I do admit that QObject+ASN.1 will ease the way to make it right so you convinced me :).

I still don't see have using ASN.1 will easily join/split several devices into few and some other magics. Not that it is not possible but it is way too hard.

The main 'real' problems you're trying to solve are migration from one release to the other while most of our problems were forgotten fields here and there (floppy/ide/rtl/kvmclock/etc). I doubt that live migration of the same release worked on upstream for the random git head. Verifying save(i)== load(i)+save(i+1) is simple but no one executing it. Looks like we might be ready to go with your suggestion, I'm just worried that there are too many other non migration open issues. If the above work won't get complete we're better off with the current machine type + VMState + subsections. If it will be all completed, we're better with your suggestion.


BTW, another really useful thing that Visitor would enable is the
ability to read an individual device to a QObject and implement the
equivalent of 'show devicename' which dumps the state of arbitrary
devices via QMP. This could be very useful for debugging.

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.

Yeah, I think the critical technical requirement to achieve this is that
the devices need to generate their own serialization format, and then
another layer translates that to the "live migration protocol" format.

Regards,

Anthony Liguori



Regards,

Anthony Liguori



Regards,

Anthony Liguori












reply via email to

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