Re: [Xen-users] xl migrate command - disable ssh

["Dr. Greg Wettstein" <greg@xxxxxxxxxxxxxxxxx>]

On Mar 13,  9:55pm, Sean Greenslade wrote:
} Subject: Re: [Xen-users] xl migrate command - disable ssh

Good morning, hope the end of the week is going well for everyone.

> As I said, you'll first need to get some sort of remote shell
> working.  My suggestions are for RSH or Telnet, but anything that
> can get you a shell will work. Unfortunately, I have absolutely no
> experience with either, as I have been raised in an ssh world. In
> fact, I use sshfs for remote file shares, and I've never had an
> issue with performance bottlenecks even while saturating my gigabit
> link. So not that I'm discouraging your academic exploration, but I
> would say that in all likelihood, the performance loss of using ssh
> is negligible and the security gained is substantial. Just my $0.02.

Our group has just spent a fair amount of time working out issues with
VM migration on 4.2.1.  Using SSH as the transport framework has a
number of advantages, modulo the generic security concerns of having
to have root access to SSH enabled and having to have root credentials
floating around to authenticate the remote shell invocation.

We have a setuid wrapper program I should clean up and make available
which exec's the 'xl migrate-receive' command.  It has all the obvious
issues of any setuid program but it does provide the ability to
implement a somewhat stronger security architecture.

The other issue is that depending on the configuraton of the migration
target there may not be a path to the xl command.  The following
wrapper script is useful for automating migration on the send side:

#! /bin/bash
exec ssh -C $1 /usr/sbin/xl migrate-receive;

The following snippet should be saved in a file named 'xen-migrate'
and placed in a directory accessible to the PATH variable of the user
requesting migration.  Migration of a virtual machine can then be
requested with the following command:

xl migrate -s xen-migrate DomainID TargetHost

Where:
        DomainID = id of domain to migrate
        TargetHost = name of host to migrate VM to.

The -C switch to ssh requests compression of the data stream which
tends to positively impact the transfer rates of the VM image.

The other issue is that you have to have a method for making sure the
VM disk image is available to both the sender and receiver dom0
environments.  NFS will work for a simple setup but if you are a bit
crafty and can setup an iSCSI target using a Linux target stack such
as SCST the following package allows domU instances to be implemented
as first class SAN guests:

        ftp://ftp.enjellic.com/pub/xen/Xen-SAN-0.1.0.tar.gz

The hotplug support implemented in that package will automtically
setup and teardown the iSCSI block connections for the guest as part
of the migration process.  The functionality of this support has been
extensively tested with the 4.2.1 Xen release.

Hopefully the above is useful to others.  VM migration is incredibly
useful but does have some generic usability barriers which one has to
putz with in order to get everything working.

Best wishes for a pleasant weekend to everyone.

Greg

}-- End of excerpt from Sean Greenslade

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@xxxxxxxxxxxx
------------------------------------------------------------------------------
"More people are killed every year by pigs than by sharks, which shows
 you how good we are at evaluating risk."
                                -- Bruce Schneier
                                   Beyond Fear

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users