Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels

["Dr. David Alan Gilbert" <dgilbert@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