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

[Shriram Rajagopalan <rshriram@xxxxxxxxx>]

On Thu, Jul 18, 2013 at 7:10 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

On Thu, 2013-07-18 at 11:53 +0100, George Dunlap wrote:
> On Wed, Jul 17, 2013 at 5:39 PM, Shriram Rajagopalan <rshriram@xxxxxxxxx> wrote:
> > 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.
>
> Just to check, are you making a distinction here between xl and libxl?
>  Ideally the important functionality to do Remus would be in libxl, so
> that any toolstack could impliment it.  xl is meant to represent an
> example toolstack one might build; it in theory one should be able to
> implement Remus using libvirt or xapi without significant effort.

That helps a lot. I somehow got a wrong impression that xl was part of libxl (sort

of a frontend).

Right, and that's why I would prefer to avoid a dependency on Python.
Since I think at least some of these projects will see it as an
additional barrier.

On the other hand if its just an implementation detail of a remus
specific script which libxl happens to call out to when asked then I
suppose it is up to the Remus folks whether they find this acceptable.

correction. This script will be called by xl not libxl. As George put it, other toolstacks

may choose to do this setup in their own way. If there was a decent way of doing stuff like

"modprobe ifb" or "tc filter add dev vif1.0 parent root u32 match u32 0 0 .." in C, I would have

jumped on it. 

As it turns it, there isnt one. So, if you folks are okay with "xl" code doing things like

system("modprobe ifb numifbs=10")

system("ip link set ifbX up")

system("tc filter add dev vif1.0 ingress")

system("tc filter add dev vif1.0 parent ffff: proto ip pref 10 u32 match u32 0 0 action mirred egress redirect dev ifbX")

I can get rid of the script all together. I thought you guys would find this distasteful ;) and 

hence the decision to invoke an external script.

OTOH, the only thing that libxl needs is a list of ifb devices to install the qdisc.

This will be done programmatically.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel