| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Fwd: Examples for using xl migrate -s ?
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
|
|
|
| |
|
Home