From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58692) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ4mD-0005ED-8X for qemu-devel@nongnu.org; Wed, 04 Feb 2015 13:34:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJ4m9-0008Pa-VX for qemu-devel@nongnu.org; Wed, 04 Feb 2015 13:34:13 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38017) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ4m9-0008PQ-PC for qemu-devel@nongnu.org; Wed, 04 Feb 2015 13:34:09 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t14IY9oP003663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 4 Feb 2015 13:34:09 -0500 Message-ID: <54D26620.40902@redhat.com> Date: Wed, 04 Feb 2015 11:34:08 -0700 From: Eric Blake MIME-Version: 1.0 References: <20150204113229.GN3032@redhat.com> <20150204130821.GH2329@work-vm> <20150204140259.GR3032@redhat.com> In-Reply-To: <20150204140259.GR3032@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jaod5lQQ5NUxHqkbT5qGlN8sRdF46mFK0" Subject: Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , "Dr. David Alan Gilbert" Cc: amit.shah@redhat.com, qemu-devel@nongnu.org, quintela@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jaod5lQQ5NUxHqkbT5qGlN8sRdF46mFK0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/04/2015 07:02 AM, Daniel P. Berrange wrote: >> >> I think fixing this for migration might simplify stuff for users a lot= as well; >> the choice of whether libvirt does tunneling or not and what it means >> for how block migration happens etc can get very confusing. >=20 > Yes, and not helped by the fact that no single current impl offers all > desired features - they are all partially overlapping sets :-( >> Some things to keep in mind: >> 1) The current patch from Liang Li doing multi threaded compression >> It just strikes me as an exmaple of another type of filter in the= migration >> stream. >=20 > Yes, that does make sense in that way, >=20 >> 2) Postcopy and fault tolerance need a bidirectional channel; and th= at back >> channel tends to be small messages. >=20 > TLS will require bidirectional channels too in order to perform the > handshake. SASL will require bidirectional channels too. So this > seems rather inevitable. >=20 >> 3) I'd considered making a separate socket/fd for passing page data >> in the hope of maybe making that page take data via splice; but a= m not >> sure yet. Another thing to think about - should migration to file be something that can be encrypted? There, you don't have the luxury of a bidirectional channel, but securing the machine state so that only an authenticated user can decrypt to reload the state later sounds like another benefit that might be possible. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --jaod5lQQ5NUxHqkbT5qGlN8sRdF46mFK0 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJU0mYgAAoJEKeha0olJ0NqKT4H/jvI+V/6Luytz//fzm5rxKzv 23M3baJ/WJ62fIdGjymejtkt1J+prW2TPbgEyX34mWflsGjgTKu2+cDl658wuYK7 lX3fYtiZ5y1BdLUOH+TxtuNlzf1M9fv98pTEhGvtYRJQP4AJnM4Tj8VXQFKtjaiu glCqTupyjt3wnEmhwDBTVMRgCokGP06+nouDOq8BCoLVKMl/DtHkZ4n6dkOwSnKJ /Wjk1fciuwjnFU7zzRsLVoV3llBd1E7U6bZP+Jh357Zb2JDYFpG8UzJGU9V2misb +CI2q7JgJAd3JAymApY+agDrzq+ENmWUDY+pvsG1B8rLbo7CC4OvWrnAJuaItMk= =vdTs -----END PGP SIGNATURE----- --jaod5lQQ5NUxHqkbT5qGlN8sRdF46mFK0--