Xen project Mailing List

On 18/07/13 15:51, Shriram Rajagopalan wrote:

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

On Thu, 2013-07-18 at 09:26 -0400, Shriram Rajagopalan wrote:

> 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.

Actually I think this is exactly the sort of complexity which libxl
serves to remove from all toolstacks. If they all need to do it then it
belongs in libxl.

> system("modprobe ifb numifbs=10")

Only this can go into the host config toolstack.

I'm not sure what you mean by "host config toolstack"; but the idea is to treat this configuration just like the bridging or OVS -- one thing set up at the beginning which the toolstack doesn't bother about.

> system("ip link set ifbX up")

the ifbX is an example.. the ifb module names the interfaces ifb0 to ifbN where N is

determined by modprobe ifb numifbs=N.

Now, lets say we have 10 ifbs in the system. which ones do we pick for the guest ?

if the VM has 3 interfaces, we need 3 ifbs, ifb0-2. Thats easy.

What if there are two remus streams in the same system ? then we need to maintain

a list of ifbs that are being used and which ones are free. The current remus python code

(tools/python/xen/remus/device.py) has some code to do this ("class Netbufpool").

Something similar needs to go into libxl.

This is exactly like assigning vif numbers to guests, isn't it?

These two should be part of the required host configuration I think.
Along the same lines as how we pushed general host networking setup out
of the toolstack and into the administrators capable hands, e.g
http://wiki.xen.org/wiki/Network_Configuration_Examples_%28Xen_4.1%2B%29

IOW just document it, same as we document "create xenbr0"

> 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")

These should be part of the existing vif hotplug scripts (called from
libxl), shouldn't they?

They don't belong in the vif-hotplug script.

Adding these lines means that all egress traffic from the VM will be routed via the IFB device

whether or not Remus is running. I don't think people would want that.

No, the idea is that if an ifbX argument is present, you use it; otherwise not. Since this needs to be done exactly once per interface before it can be considered fully set up, the vif script is the natural place to put it.

Perhaps based on a new vif parameter to specify
the ifbX

See previous explanation on finding a free IFB device.

If we throw the responsibility of specifying IFB devices onto the admin, libxl can basically

do two system() calls, as stated above and install the plug_qdisc and move on.

If we throw that to the admin it's a royal pain to use. This can easily be done by a computer; an admin has better things to spend his mental energy on.

-George

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