Remus: support for pvops dom0
PATCH 1/1 Remus: support for pvops dom0
These two patches update the Remus network buffering code to work with newer kernels, including the pvops tree.
Built and run, but not extensively tested (I'm still working on some blktap2 issues on the disk replication side).
PATCH 1/1 Remus: make ebt_imq and sch_queue compatible with pvops
# HG changeset patch
# User Brendan Cully <[email protected]>
# Date 1271123805 25200
# Node ID b0d4c221e926feff21bea0c2f3c852a692782586 # Parent f28f1ee587c8d3fb8450e5aae9541d785e8914cc
Remus: make ebt_imq and sch_queue compatible with pvops
tools/remus/kmod/Makefile +3 -0
@@ -9,6 +9,9 @@ ifeq ($(KERNELS),linux-2.6-xen0) LINUX_VER=2.6.18-xen0 endif +ifeq ($(KERNELS),linux-2.6-pvops) +LINUX_VER=2.6-pvops +endif KERNELDIR ?= $(XEN_ROOT)/build-linux-$(LINUX_VER)_$(XEN_TARGET_ARCH)
tools/remus/kmod/ebt_imq.c +60 -9
94 lines not on this page · raw message
tools/remus/kmod/ebt_imq.h +5 -1
@@ -1,10 +1,14 @@#ifndef __LINUX_BRIDGE_EBT_IMQ_H#define __LINUX_BRIDGE_EBT_IMQ_H -#define IMQ_F_ENQUEUE 0x80 +#ifdef OLDKERNEL +# define IMQ_F_ENQUEUE 0x80 +#endif struct ebt_imq_info {unsigned int todev; }; +#define EBT_IMQ_TARGET "imq" +#endif
tools/remus/kmod/sch_queue.c +40 -8
110 lines not on this page · raw message
PATCH 1/1 Remus: fix alignment bug in python rtnl library
In reply to Brendan Cully# HG changeset patch
# User Brendan Cully <[email protected]>
# Date 1271281121 25200
# Node ID 16eee52ac2ee7c3d4ddc25c9f4371ad7a9a00ae9 # Parent b0d4c221e926feff21bea0c2f3c852a692782586
Remus: fix alignment bug in python rtnl library
tools/python/xen/remus/netlink.py +2 -2
@@ -77,7 +77,7 @@ return align(self.rta_len) def pack(self): - self.rta_len = align(self.fmtlen + len(self.body)) + self.rta_len = self.fmtlen + align(len(self.body), 2) s = struct.pack(self.fmt, self.rta_len, self.rta_type) + self.body pad = self.rta_len - len(s) if pad:
@@ -88,7 +88,7 @@ args = struct.unpack(self.fmt, msg[:self.fmtlen]) self.rta_len, self.rta_type = args - self.body = msg[align(self.fmtlen):self.rta_len] + self.body = msg[self.fmtlen:self.rta_len] class rtattrlist(object): def __init__(self, msg):
Brendan Cully writes ("[Xen-devel] [PATCH 0 of 2] Remus: support for pvops dom0"):
Quoted 2 lines
These two patches update the Remus network buffering code to work with newer kernels, including the pvops tree.
Excellent.
Quoted 2 lines
Built and run, but not extensively tested (I'm still working on some blktap2 issues on the disk replication side).
I haven't looked at the code for the "remus" utility, but: How hard is it going to be to port it to libxl ? I think remus is too exciting a feature to be left to rot with xend.
Ian.
Quoted 4 lines · Ian Jackson
Brendan Cully writes ("[Xen-devel] [PATCH 0 of 2] Remus: support for pvops dom0"):
Quoted 2 lines
These two patches update the Remus network buffering code to work with newer kernels, including the pvops tree.
Quoted 8 lines
Excellent.
Quoted 2 lines
Built and run, but not extensively tested (I'm still working on some blktap2 issues on the disk replication side).
I haven't looked at the code for the "remus" utility, but: How hard is it going to be to port it to libxl ? I think remus is too exciting a feature to be left to rot with xend.
Thanks :)
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.
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.
Brendan Cully writes ("Re: [Xen-devel] [PATCH 0 of 2] Remus: support for pvops dom0"):
Quoted 4 lines
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).
Quoted 6 lines
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.
Quoted 6 lines · Ian Jackson
Brendan Cully writes ("Re: [Xen-devel] [PATCH 0 of 2] Remus: support for pvops dom0"):
Quoted 4 lines
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.
Quoted 6 lines
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.
Quoted 18 lines
Quoted 6 lines
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
[email protected]
http://lists.xensource.com/xen-devel
Quoted 1 line · On Thursday 15 April 2010 15:58:27 Ian Jackson wrote:
Brendan Cully writes ("[Xen-devel] [PATCH 0 of 2] Remus: support for pvops
dom0"):
Quoted 4 lines
Quoted 2 lines
These two patches update the Remus network buffering code to work with newer kernels, including the pvops tree.
Excellent.
Great news. I will test them in the next week.
Quoted 3 lines
I haven't looked at the code for the "remus" utility, but: How hard is it going to be to port it to libxl ? I think remus is too exciting a feature to be left to rot with xend.
What is wrong with xend? I'm new here, and I just started to learn this stuff... :)
Regards,
Łukasz Oleś
áukasz Oleû writes ("Re: [Xen-devel] [PATCH 0 of 2] Remus: support for pvops dom0"):
Quoted 7 lines · On Thursday 15 April 2010 15:58:27 Ian Jackson wrote:
Quoted 3 lines
I haven't looked at the code for the "remus" utility, but: How hard is it going to be to port it to libxl ? I think remus is too exciting a feature to be left to rot with xend.
What is wrong with xend? I'm new here, and I just started to learn this stuff... :)
xend has a huge amount of unfortunately rather unreliable code to do what is essentially a very simple set of tasks. IMO it needs to be thrown away. Part of the benefit of libxl is that it provides a basis for providing a utility like xl which does the same things as xm but with much less code - specifically without xend.
Ian.
Forgive me
Where I found this patch?
Thanks
Brendan Cully escreveu:
Quoted 11 lines
These two patches update the Remus network buffering code to work with newer kernels, including the pvops tree.
Built and run, but not extensively tested (I'm still working on some blktap2 issues on the disk replication side).
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Signature · 6 lines
Gilberto Nunes Ferreira *Suporte T.I.* *Selbetti Gestão de Documentos* *(47) 3441-6004 / (47) 8861-6672* *Fax (47) 3441-6021* /*[email protected]*/