From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32790) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJITH-00074B-Rq for qemu-devel@nongnu.org; Thu, 05 Feb 2015 04:11:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJITD-00041S-RR for qemu-devel@nongnu.org; Thu, 05 Feb 2015 04:11:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50298) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJITD-00041G-IT for qemu-devel@nongnu.org; Thu, 05 Feb 2015 04:11:31 -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 t159BUMS022644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 5 Feb 2015 04:11:31 -0500 Date: Thu, 5 Feb 2015 09:11:26 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20150205091125.GA2589@work-vm> References: <20150204113229.GN3032@redhat.com> <20150204130821.GH2329@work-vm> <20150204140259.GR3032@redhat.com> <54D26620.40902@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54D26620.40902@redhat.com> 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: Eric Blake Cc: amit.shah@redhat.com, qemu-devel@nongnu.org, quintela@redhat.com * Eric Blake (eblake@redhat.com) wrote: > 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. > > > > 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. > > > > Yes, that does make sense in that way, > > > >> 2) Postcopy and fault tolerance need a bidirectional channel; and that back > >> channel tends to be small messages. > > > > TLS will require bidirectional channels too in order to perform the > > handshake. SASL will require bidirectional channels too. So this > > seems rather inevitable. > > > >> 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 am 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. That's something that's pretty easy to do via exec-migration; so I'm not sure it's worth doing anything particularly special for it. Dave > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK