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

[Dor Laor]

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.

> Regards,
>
> Anthony Liguori