Re: [Xen-devel] [PATCH 0 of 2] Remus: support for pvops dom0

[Brendan Cully <brendan@xxxxxxxxx>]

On Monday, 19 April 2010 at 14:09, Ian Jackson wrote:
> Brendan Cully writes ("Re: [Xen-devel] [PATCH 0 of 2] Remus: support for 
> pvops dom0"):
> > Remus doesn't really use xend at all. It has its own bindings to libxc
> > and reimplements the migration control layer. I'd had tighter
> > integration with xend on my TODO list, but it sounds like I may not
> > need to do that any more.
> 
> Surely it uses xend at the receiving end at the very least ?  The
> remus utility connects to something at the destination.
> 
> xl doesn't have a daemon at the far end; xl migration is done over
> ssh by default (although you can make it use some other transport if
> you like).

Yes, that's true -- Remus does just open up the xend migration socket
for sending. But if xl has support for migration, then it sounds like
remus just needs a different handshaking shim to set up its file
descriptor, which shouldn't be too bad. On the other hand, I expect
ssh will generally be too heavyweight for Remus.

> > I haven't been paying close attention to the libxl patches flying by
> > on the list, but it looks like the area where libxl and Remus might
> > interact in the short term is your cleanups to the save image
> > format. Off the top of my head, I remember having to hack up a
> > slightly different stream format for HVM because the qemu blob had no
> > length prefix.
> 
> The save image format is not defined by libxl but by the command-line
> tool xl.  I expect it will move to the "kit of parts" library
> libxlutil.
> 
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 

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