XEN live migration over encrypted connection (ssh tunnel)

By: olorin112

March 19, 2010 4:26 pm





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.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.

Tags: , ,
Categories: SUSE Linux Enterprise Server, Technical Solutions

Disclaimer: As with everything else in the SUSE Blog, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.