From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZaAf-0002M4-4a for qemu-devel@nongnu.org; Fri, 25 Oct 2013 01:42:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZaAX-0000hi-9x for qemu-devel@nongnu.org; Fri, 25 Oct 2013 01:42:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZaAX-0000hc-1m for qemu-devel@nongnu.org; Fri, 25 Oct 2013 01:42:45 -0400 Message-ID: <526A04CA.3050705@redhat.com> Date: Fri, 25 Oct 2013 06:42:34 +0100 From: Eric Blake MIME-Version: 1.0 References: <5269694B.2030106@kamp.de> <877gd21brg.fsf@elfo.elfo> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="APpgqa115xAVhKDNeHLchIokm4Scoh1FR" Subject: Re: [Qemu-devel] [RFC] Migration capability negotation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven , quintela@redhat.com Cc: Paolo Bonzini , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --APpgqa115xAVhKDNeHLchIokm4Scoh1FR Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/25/2013 04:27 AM, Peter Lieven wrote: > Ok, one way direction - i forgot about this paradigm. >=20 > 2 thoughts: >=20 > a) a send-capabilities capability that "stores" the capabilities that w= here > used when savevm was used. I would implement a special segment > right at the beginning of the data stream that has all capabilities lis= ted 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. >=20 > 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-migratio= n). 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --APpgqa115xAVhKDNeHLchIokm4Scoh1FR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJSagTKAAoJEKeha0olJ0NqRMsH/3uouo0RE423xAN96DVL1ItR ewuHzHbcWYELc0B96FwWYuCD9LzmM6nP5q6lb4GYaeAlyVSy+3GcxrAIrMwOVAXa dDEl//mGWdNgpJeKxfgqEUfnGb4AiLEUUteRTPrLkSmIF99XjC0HIjYmvpc4QUcG Camqvsu2s+1vLB531D3u+XxErUsp2Hpx0/+qtvXqDipL0ijATjEyn3+vCKGL67I8 mqJaNljlXXhDorjyDrtIwm3Jcs4sWCh0+o0IOi/pljtSQmmxTXS9GvW7S9v50jJV 9o3OUDCktL5he0FDPe5TgNtcpqeAgo8Ec/CB5oYq2VBZoReYMWQPMuGw+W3NSRw= =aegD -----END PGP SIGNATURE----- --APpgqa115xAVhKDNeHLchIokm4Scoh1FR--