Re: [Qemu-devel] [RFC] Migration capability negotation

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]

On 10/25/2013 04:27 AM, Peter Lieven wrote:

> Ok, one way direction - i forgot about this paradigm.
> 
> 2 thoughts:
> 
> a) a send-capabilities capability that "stores" the capabilities that where
> used when savevm was used. I would implement a special segment
> right at the beginning of the data stream that has all capabilities listed that
> where set and that ultimately must be supported to import a saved state
> under any circumstances. capabilities that are only have a meaning at
> the source VM should not be set. if there is an unsupported capability
> set the import can be aborted right at the beginning.

Sounds reasonable; but ideally, it would either have to be in such a way
that doesn't break back-compat with older qemu, or else you have
invented a new file format; and once you invent a new file format, we
might as well make the file format sane by being FULLY self-describing
(see also Alexander Graf's work from KVM forum on adding a migrate-debug
device).  That is, don't just require the same capabilities, but also
require all other command line arguments to be sane in comparison to
what the savevm image was using.

> 
> b) an extension the the qmp-migrate-capabilities or a new command that give
> the controlling process (e.g. libvirt) a hint which features are a good thing to turn on
> if they are supported on both sides (e.g. zero-blocks in block-migration).

Not really needed.  New capabilities must be off by default (back-compat
reasons), so the only time they will be turned on at the source is if
the management (such as libvirt) is smart enough to know what the
capability does; once you can assume that, you can also assume the
management knows how to set up the destination properly.  Which is why
what we have already works (making management do all the negotiation
correctly).  Yes, maybe qemu could make it easier or more foolproof, but
since management already has to handle the job (particularly because
management might be dealing with older qemu that doesn't have the
ease-of-use additions), I'm not sure the effort of extra code in qemu is
worth the effort.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]