Re: [Xen-devel] Fwd: Examples for using xl migrate -s ?

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2011-10-27 at 21:47 +0100, Florian Heigl wrote:
> Hi,
> 
> sorry to disturb, but are there any in-depth docs about migration in xl?

Not that I know of, sorry. 


> It appears this is not just me not knowing it :>
> 
> Greetings,
> Florian
> 
> 
> ---------- Forwarded message ----------
> From: Florian Heigl <florian.heigl@xxxxxxxxx>
> Date: 2011/10/25
> Subject: Examples for using xl migrate -s ?
> To: Xen Users <xen-users@xxxxxxxxxxxxxxxxxxx>
> 
> 
> Hi,
> 
> I must find a way around the way live migration now uses ssh. I tested
> it and I see high cpu usage by SSH and overall sense of things being
> slow.
> My prod systems have a dedicated, fast link for live migration, but
> with ssh it would be crippled down to a <1Gbit.
> Does anyone have a working example of how to not use SSH as the transport 
> layer?
> 
> I guess this is what the -s option is for, but I don't really get how
> it's intended to be used.

AIUI the argument which you give to -s must be a command which arranges
for it's stdin to be fed to the stdin of an "xl migrate-receive" on the
remote machine.

Probably that's a little bit of scripting on either end of the link to
spawn the necessary nc invocations.

Would it be useful to have a daemon mode for xl migrate-receive, i.e.
you would start it and it would listen on a dedicated port, forking to
receive each incoming connection. That would not be a good idea in
general but for a dedicated migration network it would be ok.

Perhaps an option to xl migrate-receive to have it receive a single
connection on a specified socket from a given source instead of
expecting things on stdin would be a useful compromise? i.e. you should
use ssh to execute that command "securely" then pipe the data to the
unsecure socket?

> 
> What I can think of ( -s "ssh other box, run netcat listener there;
> launch nc locally and receive migration data) sounds absolutely
> disgusting...

It's the Unix way, surely ;-)

> 
> Thanks for any pointers,
> Florian
> 
> --
> the purpose of libvirt is to provide an abstraction layer hiding all
> xen features added since 2006 until they were finally understood and
> copied by the kvm devs.
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel