[libvirt] Fwd: Re: the case for volatile nwfilters

[Stefan Berger]

For some reason this message could not be sent to the list.

On 10/30/2013 05:57 AM, Laine Stump wrote:
> On 10/29/2013 06:33 PM, Dan Kenigsberg wrote:
>> I'd like oVirt to make a more extensive usage of libvirt's nwfilters in
>> order to implement security groups, i.e. which protocol/port/host should
>> be open on an interface.
>>
>> Since oVirt is cetrally-managed by ovirt-engine, filter definitions
>> should be edited there and kept in its database. However, libivrt's
>> domain xml requires to have a locally-defined filter as well:
>>
>>    <devices>
>>      <interface type='bridge'>
>>        <filterref filter='filter-name'/>
>>      </interface>
>>    </devices>
>>
>> We can leave with it by defining an ad-hoc filter before staring a VM,
>> deleting it after the VM stops, and collecting garbage (due to system
>> crashes) occasionally.
>>
>> It would be nicer if we could instead have just-in-time filter
>> definition such as
>>
>>    <devices>
>>      <interface type='bridge'>
>>        <filter name='nameless'>
>>           <rule/>
>>           <rule/>
>>           <rule/>
>>        </filter>
>>      </interface>
>>    </devices>
>>
>> avoiding nwfilter persistence. Would something like this be beneficial
>> to other libvirt users? Would it be easy to implement within libvirt?
> My first thought when I saw the subject line was of adding a transient
> "define and start" API similar to that used for domains and networks,
> but of course nwfilters have no concept of "start" or "destroy", so they
> wouldn't be able to follow the same semantics as transient domains and
> networks anyway.
>
> Most likely Stefan made nwfilters use in domains all be references to
> the actual nwfilters rather than having them contained in order to 1)
> save duplication in the configuration now, and 2) potentially save
> duplication in the kernel iptables rules in the future. I can see the
> convenience, but wonder how much inefficiency it could lead to.
>
> Structurally it makes sense though, and the xml has conveniently named
> the existing element as <filterref> so that <filter> is still available
> - was there some premonition of this being requested in the future? :-)
>
> I recall that Stefan has been extremely busy elsewhere and unable to
> completely follow libvir-list for awhile, so I'm Cc'ing him - Stefan, do
> you have any opinion/wisdom on this?
>

Why can the client not call nwfilter-define to define a filter and have
the filter referenced from the domain XML?
Also many of the items in the domain XML only become active after a
reboot of the VM (afaik) and I didn't want to change that with nwfilter.
So you can at any time replace the referenced nwfilter and it will be
instantiated when/while the VM is running or rejected if it cannot be
instantiated.

    Stefan