[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: Dor Laor
Subject: Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts
Date: Tue, 24 Nov 2009 13:00:24 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Lightning/1.0pre Thunderbird/3.0b4 ThunderBrowse/

On 11/23/2009 08:28 PM, Anthony Liguori wrote:
Eduardo Habkost wrote:
That may be good enough for upstream Qemu, but IMO for RHEL it is not a
realistic policy. If the definition of "guest visible state" is buggy on
the current implementation, we can't drop entirely the possibility of
fixing it on our stable branch.

After mulling over it a bit, here's what I'd suggest:

1) Integrate VMstate with qdev
2) Introduce a bitmap blacklist for unsupported VMstate versions
3) Expose that bitmap as a qdev property for each device.
4) By default, upstream qemu will always set the bitmap to be 100% correct.

This provides a mechanism for informed users and downstreams to reduce
correctness in favor of migration compatibility on a case-by-case basis.

This takes qemu out of the business of creating these sort of policies
but allows RHEL to make decisions about what default policy it uses. It
also lets well informed users of RHEL to override those policy decisions
when they deem it to be appropriate.

This would make me happy both from an upstream qemu perspective but also
as a consumer of RHEL.

How does this improves the pvclock MSR migration problem?
This is a 5.4.1 -> 5.4.0 migration problem that was originated by time drift of pvlcock *on* live migration... It doesn't work today and it will surely be put in the black list if implemented this way. Only windows guest might get benefit out of it since they do not use pvclock, but it will turn into management night mare instead. In Qemu we know best what fields/sections are optional and what are must have.

If we'll move into a real protocol with specification of every device and chunk blocks similar to Paolo/Eduardo suggestions will have maximum flexibility and we can allow such migration to happen.

IMHO we need to standartize the migration protocol like an other network protocol. The current approach is to use qdev and -M and it's not good enough. We should make an effort and try to harden it. It's the same as the user/kernel ABI - usermode query capabilities, not version number.

Lastly, coming to think of it, we should make the migration fail at the beginning instead of doing all the dirty bit tracking + pause the VM and only then be surprised by different version/capability.


Anthony Liguori

reply via email to

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