[Top][All Lists]

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

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

From: Michael S. Tsirkin
Subject: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts
Date: Tue, 24 Nov 2009 15:55:15 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

On Tue, Nov 24, 2009 at 07:45:13AM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> On Sun, Nov 22, 2009 at 09:49:26AM -0600, Anthony Liguori wrote:
>>>>    We cannot even create a new 'hack section' for new code since the
>>>>    sections are ordered and expected to be exact match on the
>>>>    destination.
>>>>    The result is that new->old migration cannot work. This is not cross
>>>>    releases even! It means that even a small bug in current release
>>>>    prevents live migration between various instances of the code.
>>>>    It forces us to decide whether to fix pvclock migration issue vs
>>>>    allow new->old migration. Another ugly hack is to add cmdline that
>>>>    will control this behavior. Still it's a pain to mgmt stack and
>>>>    users.
>>> This is a pretty normal policy (backwards compat but not forwards compat).
>> No one is asking that old qemu magically understands new format. It
>> would be enough that new qemu is able to migrate to a format that old
>> one understands.
> I've got no problem with that provided it's something explicitly  
> requested by the user.  This requires no migration protocol change  
> though so if this is what folks are asking for, why is this thread  
> focused around changing the live migration protocol?

I think the claim is that a section-based migration
protocol would make implementing this easier than
version-based one, especially for downstream which might
cherry-pick a feature from a new release to an old one.

It seems the requirement discussion and the implementation
discussion are going on together in this thread.

> Regards,
> Anthony Liguori

reply via email to

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