[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] NBD TLS support in QEMU



On Fri, Sep 05, 2014 at 08:23:17AM +0200, Michal Privoznik wrote:
> On 03.09.2014 18:44, Stefan Hajnoczi wrote:
> >Hi,
> >QEMU offers both NBD client and server functionality.  The NBD protocol
> >runs unencrypted, which is a problem when the client and server
> >communicate over an untrusted network.
> 
> This is not problem for NBD only, but for the rest of data that qemu sends
> over  network, i.e. migration stream, VNC/SPICE, ...

We already have TLS support for VNC and SPICE.  We do need it for NBD,
migration and the chardev TCP backend.

I'd suggest that it is likely possible to add support for NBD, migration
and chardev all at the same time by doing a general purpose TLS socket
wrapper in QEMU that all those areas can use.

> >The particular use case that prompted this mail is storage migration in
> >OpenStack.  The goal is to encrypt the NBD connection between source and
> >destination hosts during storage migration.
> >
> >I think we can integrate TLS into the NBD protocol as an optional flag.
> >A quick web search does not reveal existing open source SSL/TLS NBD
> >implementations.  I do see a VMware NBDSSL protocol but there is no
> >specification so I guess it is proprietary.
> 
> In case of libvirt, we have so called tunnelled migration (both spelled &
> misspelled :P) in which libvirt opens a local ports on both src & dst side
> and then sets up secured forwarding pipe to the other side. Or a insecured
> one if user wishes so. The only problem is that when I adapted libvirt for
> NBD, I intentionally forbade NBD in tunnelled migration as it requires one
> more data stream for which libvirt migration protocol is not ready yet.
> Having saidy that, I feel that libvirt is the show stopper here, not QEMU.

While tunnelled migration via libvirt is doable, it is very much
sub-optimal as it involves a great many data copies which is bad
for performance of migration. This is the main reason that having
direct TLS support in the QEMU migration and NBD data channels is
desired.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]