(FYI, I'm about to disappear for a long weekend, back on Tuesday)
On Fri, 2011-06-10 at 00:59 +0100, Shriram Rajagopalan wrote:
> On Thu, Jun 9, 2011 at 7:34 AM, Ian Campbell
> <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> The "foo|bar" syntax is completely new to me (and I suspect
> anyone else not familiar with remus). How does it work? Is the
> full "backupHost:port|aio:/dev/foo" considered the argument to
> Remus (in which case I think it can work via the Remus script
> as above) or does xend somehow parse this into
> "remus:backupHost:port" and "aio:/dev/foo"?
> In the latter case I've no idea what to suggest!
>
> I dont think the script= directive is going to work (or even
> necessary). The entire "foo|bar" part is handled by the blktap2 code
> base. IOW, if the disk spec is tap:remus:host:port|aio:/dev/abc, then
> xl invokes the blktap2 code and passes remus:host:port|aio:/dev/abc ,
> which gets parsed and both remus and aio drivers are created (remus
> driver on top of aio).
OK, so in the terminology of xl-disk-configuration.txt "remus:host:port|
aio:/dev/abc" is the "target" and could potentially be handled
internally when libxl creates a blktap backend.
You mention below that block-drdb works so I very much expect that
block-remus would work too, even if ultimately it was just a thin
wrapper around tapctl etc. In that case I think the target would end up
just being "host:port|aio:/dev/abc" because the remus: would be a
shortcut for script=remus.
> Have you considered making Remus a more top-level domain
> configuration option rather than disk specific? i.e. adding
> remus_backup = "..." to the cfg. This would allow libxl to do
> the right thing internally and setup the disks in the right
> way etc etc.
>
> Yes I have, several times. Wading through xend code was not so much
> fun :(.
Yeah, I didn't mean for xend...
> With xl, as long as it can construct the "remus:host:port|
> aio:/dev/abc" arg and pass it to the blktap2 code, things should be
> fine.
> With a DRBD based backend, nothing of this sort is required. Xend
> automatically invokes the block-drbd script, which does the rest. If
> xl does the same, then things should be fine.
[...]
> looks mostly the same as xl, except xl does all the
> xc_domain_save stuff
> in process rather than indirecting via an external binary.
> Do you mean that xl does all the xend stuff ? Because xl still calls
> xc_domain_save
> in libxl_dom.c:libxl__domain_suspend_common
What I meant was that in xend the xc_domain_save happens in a separate
helper process (xc_save) while in xl the xc_domain_save happens in the
original xl process itself (via libxl which calls libxc).
libxl uses libxc to do the low level stuff, like make hypercalls and do
migrations etc. Users of libxl (e.g. xl) don't get to see libxc though,
it is abstracted away.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home