Re: [Xen-devel] Prevent vif-bridge from adding user-created tap interfaces to a bridge

[Jim Fehlig <jfehlig@xxxxxxxx>]

Ian Campbell wrote:
> On Thu, 2011-10-27 at 16:12 +0100, Ian Jackson wrote:
>   
>> Jim Fehlig writes ("[Xen-devel] Prevent vif-bridge from adding user-created 
>> tap interfaces to a bridge"):
>>     

Ok, my original post comes through now on a new thread...

>>> I received a report that vif-bridge adds any tap interface to a bridge,
>>> regardless if xen is running and who created the tap interface.  E.g.
>>>
>>> # tunctl -p -t tap42
>>>
>>> will cause vif-bridge to be executed as per the following rule in
>>> xen-backend.rules
>>>
>>> SUBSYSTEM=="net", KERNEL=="tap*", ACTION=="add",
>>> RUN+="/etc/xen/scripts/vif-setup $env{ACTION} type_if=tap"
>>>       
>> Urgh.  What a mess.
>>
>>     
>>> I'm not sure how to improve the rule to prevent execution of vif-setup
>>> in this case.  But it seems better to handle it in vif-bridge anyhow, by
>>> not connecting the interface to a bridge if there is no corresponding
>>> info in xenstore.  Something along the lines of the attached quick
>>> patch.  Comments?
>>>       
>> Aren't tap devices like this created by Xen's qemu ?  And as such we
>> should be letting qemu run the script, and not have any hotplug
>> script called by udev.
>>     
>
> We explicitly changed away from that scheme not so long ago. The issue
> is that each tap has a vif counterpart which is somewhat logically the
> same device and should be setup the same way, hence via the same
> mechanisms.
>   

And qemu isn't involved when using netback.

So how to proceed?  Ian C. seemed to hesitantly ACK the patch in the
other thread [1] :).  The suggestion to write the info to another path
in xenstore can also be implemented, although IMO, that the path is not
accessible to the frontend would be the only benefit.

Thanks,
Jim

[1] http://lists.xensource.com/archives/html/xen-devel/2011-10/msg02016.html


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel