XEN live migration over encrypted connection (ssh tunnel) | SUSE Communities

XEN live migration over encrypted connection (ssh tunnel)


As XEN only has limited authorization capability for its live migration and all the communication is unencrypted, this solution shows how to set up live migration over an ssh tunnel.

If live migration is enabled, the xend listens at port 8002 on any interface for incoming migration requests, as configured in /etc/xen/xend-config.sxp:

# Port xend should use for the relocation interface, if xend-relocation-server
# is set.
(xend-relocation-port 8002)
# Address xend should listen on for relocation-socket connections, if
# xend-relocation-server is set.
# Meaning and default as for xend-address above.
#(xend-relocation-address '')

# The hosts allowed to talk to the relocation port.  If this is empty (the
# default), then all connections are allowed (assuming that the connection
# arrives on a port and interface on which we are listening; see
# xend-relocation-port and xend-relocation-address above).  Otherwise, this
# should be a space-separated sequence of regular expressions.  Any host with
# a fully-qualified domain name or an IP address that matches one of these
# regular expressions will be accepted.
# For example:
#  (xend-relocation-hosts-allow '^localhost$ ^.*\\.example\\.org$')
#(xend-relocation-hosts-allow '')
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')

If any request arrives, it checks the hosts for existence in the xend-relocation-hosts-allow list and accepts or refuses the connection.

If you would like some more sophisticated authorization and also encryption, set up your system like described in this solution.

First restrict the interface to listen on to the loopback interface. The allowed hosts now only play a secondary role, as only localhost will be able to access the relocation port.

(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address '')
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')

If you would like to start live migration from a SourceHost now, create an ssh tunnel first. For maximum flexibility and easy adoption, I am using variables for the key values here. On the SourceHost enter (one line, no breaks):

 ssh -f -i ${XEN_SSHKEY} ${XEN_USER}@${SOURCEHOST} "ssh -f -i ${XEN_SSHKEY} -L ${XEN_MIGRATION_PORT}:localhost:${XEN_RELOCATION_PORT} ${XEN_USER}@${TARGETHOST} sleep 30" 2>/dev/null

Where XEN_USER is a non-root user to avoid direct root login, XEN_SSHKEY is the appropriate ssh key file, which has to be put into the authorized_keys file first.

XEN_MIGRATION_PORT is 8002, the value you are using in /etc/xen/xend-config.sxp and XEN_RELOCATION_PORT is any port you would like to use (personally I use 13001 and following). The tunnel command logs in to the target host and creates a tunnel from there back to the source host, which is going to be open for 30 seconds. This backtunneling is necessary to allow access to on the target host. The tunnel will close after the 30 seconds until you already have got active communication (our live migration) through it. Then the tunnel will stay open as long as there is any active connection attached to it.

Then start the live migration on the SourceHost via (one line, no breaks):

/usr/sbin/xm migrate --live --port=${XEN_MIGRATION_PORT} ${VMNAME} localhost

The xend opens a connection to (in our example case) port 13001 on the SourceHost, which is tunneled to 8002 on on the TargetHost. All authorization and encryption is done by ssh.

After live migration, the 30 second timeout is probably outdated by far and so the tunnel closes after the migration.

If you don’t like creating the tunnel just before live migration (which could be handled by a wrapper script), you could also create persistent tunnels, but this will probably end up in a lot of permament cross connections.

(Visited 1 times, 1 visits today)

Leave a Reply

Your email address will not be published.

No comments yet