Re: the case for volatile nwfilters

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?


--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]