Todo Secure Migration
Not all hypervisors have built in support for secure migration, and even those that do will have varying capabilities for encryption and authentication, and different configuration requirements. It is desirable to provide some form of secure migration capability directly using the libvirtd daemon as a proxy. The libvirtd daemon already has support for a range of auth options (x509 certs, kerberos, username/password, SSH public key), and encryption options (TLS, kerberos, SASL, SSH). Furthermore the libvirtd daemon will already have a well-known port available, avoiding the need to open more TCP ports in firewalls
The general idea would be along the lines of:
- A libvirt client connects to two libvirtd servers (one on each host) to trigger the migration operation
- The source libvirtd server connects to the destination libvirtd server directly (peer-to-peer) to setup a secure channel.
- The source libvirtd server has a TCP/UNIX socket open for listening on 127.0.0.1/::1 (ie localhost) and tells Xen/QEMU to migrate to this address
- The destination Xen/QEMU vm is started to accept incoming migration from 127.0.0.1/::1.
- The destination libvirtd receives data from the source libvirtd, and forwards it to the local incoming migration socket
So, the underlying hypervisors only need to be able to migrate insecurely to/from 127.0.0.1/::1. All the traffic over the 'public' network is handled by libvirtd.
The libvirtd daemon is currently single threaded. This isn't neccessarily a problem. It merely has to spawn a worker thread for each migration data channel.
Views
Personal tools
Toolbox
