qemu-devel
[Top][All Lists]
Advanced

[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 20:56:00 +0200

On Tue, Nov 24, 2009 at 8:51 PM, Anthony Liguori <address@hidden> wrote:
> Paolo Bonzini wrote:
>>
>> On 11/24/2009 06:08 PM, Michael S. Tsirkin wrote:
>>>>
>>>> >  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.
>>
>> We have Juan's VMState work to start from.  If we can take it a step
>> further and use anything (including CPP) to make the primary representation
>> of state an XML document or anything like that (and convert it back to
>> VMState structs at build time), it would not be a huge work, and it would
>> give important benefits.
>
> Like adding tremendous complexity for little to no gain.

But the complexity would be a problem only for the transformation
matrix project. For QEMU the gain would be simplified design, maybe at
the expense of some CPP magic.




reply via email to

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