On Tue, 2011-06-07 at 16:30 +0100, Shriram Rajagopalan wrote:
> On Tue, Jun 7, 2011 at 5:02 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
> wrote:
>
> On Tue, 2011-06-07 at 04:30 +0100, Shriram Rajagopalan wrote:
> > I am looking into adding Remus support for libxl. The
> easiest way is
> > to obtain the domain's sxpr, so that the rest of Remus
> python code
> > stays as is.
> >
> > Is there an api call in libxl to return a domain's sxpr ? a
> grep on
> > the libxl code
> > base returned nothing. Or am I missing something pretty
> obvious?
>
>
> xl has some code to do this but libxl doesn't. An sxpr
> representation of
> a domain is rather a xend specific concept which is the only
> reason xl
> has it.
> There are some plans to allow libxl to generate json for any
> of the IDL
> defined datastructures, mostly as a convenient pretty-printer
> but being
> machine parsable is a handy side-effect. Currently this would
> just be
> for individual datastructures though.
>
> Where/how does remus use sxp?
> tools/python/xen/remus/vm.py:domtosxpr()
> seems to consume a xend datastructure and make a Remus sxp out
> of it --
> can an xl equivalent not be written using the python bindings?
> (NB
> bindings may be incomplete, we can fix up as you discover
> stuff). Are
> all usages of sxp in Remus of that particular sxp format or
> are there
> others?
>
>
> The only reason remus uses sxpr is because xend conveys info in that
> form. Basically, it only needs the vif device name (vif1.0, etc), the
> disk device name and the access format (tap/drbd) for proper
> operation.
ok, this stuff should be available to xl/libxl (as appropriate) pretty
easily.
[...]
> The reason for bypassing the usual xend live migration code path is
> because of the callbacks, the checkpoint interval based
> suspend/resume, etc. Now that I know that xl/libxl doesnt use sxpr in
> its wire-protocol (dunce! :( ), the plan would have to be different.
>
> (a) Follow the same implementation style like that with xend (bypass
> xl's live migration mechanism) - involves some code duplication
> probably for communicating with remote machine, in xl's wire protocol.
> The advantage is most of remus' python code (save.py, device.py,
> qdisc.py, code to install/parse IFB devices, tc rules, etc) stays as
> is.
>
> (b) integrate the remus control flow into xl/libxl stack - I dont know
> how much work that would be yet.
I don't know enough about the needs etc of Remus to make much in the way
of concrete proposals but in general plan b is the sort of thing we
would prefer since all toolstacks can then benefit (at least to some
extent).
Certainly I would prefer to see libxl functions which provide the
necessary interfaces (likely sharing common code within the library) etc
to duplication of the code.
Perhaps you could quickly explain the Remus architecture within the xend
world, which might help us to advise. e.g. How are things different on
the tx and rx sides with and without Remus? What additional callbacks
and control flow are there etc?
Do I gather correctly that the thing on the receiving end is not xend
but rather a Remus process?
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home