Xen project Mailing List

On Wed, Jul 17, 2013 at 9:57 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>
> On Sun, 2013-07-14 at 10:13 -0500, Shriram Rajagopalan wrote:
>
> > I can use xenstore too but I don't want to pollute xenstore entries
> > unless absolutely necessary.
>
> Ultimately it may be that the script is running in a different domain
> (e.g. a driver domain) so xenstore may be the best way.
>
> Can you enumerate what would be going in there? It may be
> that /libxl/<domid> or even /tools/remus/<domid> might be an appropriate
> home for it.
>

driver domains is something that I didnt think about. interesting idea though.

basically, if I were to use xenstore as a communication medium between
the script & xl-remus, things that xl would need as return values from the script

(via xenstore) are the ifb devices that map to each of the vifs belonging to the guest,

so that plug qdiscs can be installed on all of them.

Simplest (and most common case): install network buffer on all
interfaces in the guest and obtain relevant ifb devices:
xl forks "/etc/xen/scripts/remus-netbuf <domid> install"
script installs ifbs on all vifs
script writes to xenstore . e.g., /libxl/domid/remus/netbufs="ifb0,ifb2,ifb6"
xl reads /libxl/domid/remus/netbufs and

installs plug_qdisc on all these ifb devices and moves on.

on cleanup (i.e., backup failure)
xl forks "/etc/xen/scripts/remus-netbuf <domid> uninstall"

In order to allow the possibility of installing network buffer on select vifs:
script writes to xenstore in the following way:
/libxl/domid/remus/netbufs/vifX.Y=ifb0
/libxl/domid/remus/netbufs/vifX1.Y1=ifb2

followed by xl reading each of the entries under remus/netbufs.

This is basically like the hotplug script stuff, except that its done

on demand when remus is started.

> > Or is it as simple as reading and writing to files or using standard
> > communication primitives like named fifos or pipes ?
> >
> >
> > As an alternative,
> > Instead of adding libnl dependency to xl,
>
> Would it be that bad for xl (or perhaps better libxl) to depend on
> libnl?
>

Maybe not. anything above libnl 3.2.8 should do.. (unfortunately, debian wheezy still is at 3.2.7.
same applies to ubuntu versions before 13.04).

> > I can reuse existing python code for network buffering and control the
> > python process via unix sockets or pipes or fifos. The python code
> > does not rely on libnl.
>
> I don't think we want to go down this route.
>

Why ? Not only will we be complicating xl code with netlink stuff, but
we will also be adding more code related to drbd/blktap3 or so on.

My intention was to factor out the generic parts of existing remus-python

code base (most of it is in tools/remus and tools/python/xen/remus/device.py)
and simply fork off the script from xl. The two can communicate using
a simple pipe.

There wont be any legacy dependencies on xend whatsoever. Most of that
code base is self contained.

> Ian.
>
>

Re: [Xen-devel] xl remus - Invoking scripts from xl