From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZSWu-0002BY-1s for qemu-devel@nongnu.org; Thu, 24 Oct 2013 17:33:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VZSWo-0008GU-4k for qemu-devel@nongnu.org; Thu, 24 Oct 2013 17:33:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20893) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VZSWn-0008GK-RV for qemu-devel@nongnu.org; Thu, 24 Oct 2013 17:33:14 -0400 Message-ID: <52699201.7080001@redhat.com> Date: Thu, 24 Oct 2013 22:32:49 +0100 From: Eric Blake MIME-Version: 1.0 References: <5269694B.2030106@kamp.de> In-Reply-To: <5269694B.2030106@kamp.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8HiJS8UXK5OIqouJDuaUbHLKH9Gq3uufI" Subject: Re: [Qemu-devel] [RFC] Migration capability negotation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven , "qemu-devel@nongnu.org" , Paolo Bonzini , quintela@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8HiJS8UXK5OIqouJDuaUbHLKH9Gq3uufI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/24/2013 07:39 PM, Peter Lieven wrote: > Hi, >=20 > I was thinking that it would be great to have the source and destinatio= n during migration negoatiate > migration capabilities e.g. something like this: >=20 > User wants to use a feature e.g. 'zero_blocks'. He switches it to 'on' = or maybe a new state 'auto' on the source VM. >=20 > If the migration is started the source hypervisor sends a set of all de= sired features. The destination hypervisor > answers with a subset of all features it supports and automatically ena= bles them on its side. Depending on the returned > subset the source disables all features the destination does not suppor= t. >=20 > This would also allow us also to introduce new features which we would = like to enable by default, but we cannot > because we do not know if the destination will support it. >=20 > Is there any way to add this without breaking backwards compability? It's already been added: QMP has 'migrate-set-capabilities' and 'query-migrate-capabilities', which the management uses to negotiate the capabilities between source and destination before starting the migration= =2E Other than that, you MUST remember that migration is one-directional (the source does NOT get any input from the destination, other than what the management app such as libvirt provides via the setup it does outside of qemu before telling qemu to start migration). --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --8HiJS8UXK5OIqouJDuaUbHLKH9Gq3uufI 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/ iQEcBAEBCAAGBQJSaZIBAAoJEKeha0olJ0NqpD4H/1YbnCtmjyi6Dl2yUNKE7noO bTX9YG2z+m8YGTL9iYA7hutNL/+NBw13oefxX5CvZxON8/CJ8K2tbt0w7q4k9+hK evN37rhlJRKk3BPeTvgA5OICcTlHgXq8y5BOTkNW4MOyQGFzj4eGl1jOte/nu63d /bKaEvRYKTXOQM3qTVefbXYRxGcE7FARQA1SJgbfIZQCu4dyBHCD0D/+/xASWE+x OfZ1IviG/DMR28NNYRG1Ay/WAkN2x14A3eHGJ8YZ3XubhBAp5XU5zajrW2DtSoog LeFTRw4/wsIJDSz+r3wNPHt0B+xjnMMdI/hTuRTqcsaIBGiNmCy9/T34dlbaP2c= =MEya -----END PGP SIGNATURE----- --8HiJS8UXK5OIqouJDuaUbHLKH9Gq3uufI--