Xen devel - Oct 2011 - Examples for using xl migrate -s ?

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.

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

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-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Hi,

sorry to disturb, but are there any in-depth docs about migration in xl?
It appears this is not just me not knowing it :>

Greetings,
Florian


---------- Forwarded message ----------
From: Florian Heigl <florian.heigl@gmail.com>
Date: 2011/10/25
Subject: Examples for using xl migrate -s ?
To: Xen Users <xen-users@lists.xensource.com>


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.

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

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.



-- 
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@lists.xensource.com
http://lists.xensource.com/xen-devel

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@gmail.com>
> Date: 2011/10/25
> Subject: Examples for using xl migrate -s ?
> To: Xen Users <xen-users@lists.xensource.com>
> 
> 
> 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@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi,

2011/10/28 Ian Campbell <Ian.Campbell@citrix.com>:
>> sorry to disturb, but are there any in-depth docs about migration in
xl?
>
> Not that I know of, sorry.
usage as an exercise left to the user. :>
> 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?
I don''t write network protocols ... I don''t know which way of
connection setup would be best, but using ssh to securely initiate
things definitely makes sense.
On the other hand I don''t like the initiator of (the migration)
something telling the receiver where to listen. That''s like the NAT
traversal stuff in SIP.

Maybe, uh, something like:
ssh into migration target, saying hi, please spin up a receiver using
(stdin|network)
server says: receiver ready at (stdin|network ip+socket)
client sends to the correct destination.

The advantage would be that the server could have the final decision
about which interface to use, it might well be different from the
SSH-facing one.
> It''s the Unix way, surely ;-)
Hehe, getting me from the Unix angle, I feel trapped!

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

On Sat, 2011-10-29 at 20:38 +0100, Florian Heigl wrote:
> Hi,
> 
> 2011/10/28 Ian Campbell <Ian.Campbell@citrix.com>:
> >> sorry to disturb, but are there any in-depth docs about migration
in xl?
> >
> > Not that I know of, sorry.
> 
> usage as an exercise left to the user. :>
As part of the documentation day last week Stefano Stabellini posted a
manpage for xl which no doubt contains a few words on this subject.
Please could you have a look in the archives and see if what is written
there would have helped.
> > 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?
> 
> I don''t write network protocols ... I don''t know which
way of
> connection setup would be best, but using ssh to securely initiate
> things definitely makes sense.
> On the other hand I don''t like the initiator of (the migration)
> something telling the receiver where to listen. That''s like the
NAT
> traversal stuff in SIP.
> 
> Maybe, uh, something like:
> ssh into migration target, saying hi, please spin up a receiver using
> (stdin|network)
> server says: receiver ready at (stdin|network ip+socket)
> client sends to the correct destination.
I think that could work, yes.
> The advantage would be that the server could have the final decision
> about which interface to use, it might well be different from the
> SSH-facing one.
> 
> > It''s the Unix way, surely ;-)
> 
> Hehe, getting me from the Unix angle, I feel trapped!
:-)

Ian.


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