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?

On Wed, Oct 30, 2013 at 10:13:28AM +0000, Daniel P. Berrange wrote: > On Wed, Oct 30, 2013 at 11:57:16AM +0200, 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? > > As you say, the reason for not specifying <filter> directly on the VM > was to allow us more scope for improving the efficiency of filters in > the future, by using shared rules across VMs. Having separate rules > per guest NIC is a really non-scalable way to do network filtering as > we look to the future where having 1000's of guests per host will be > not uncommon. The use of filter parameters was included to make it > easier to have common filters, whose actual matching is parameterized > where needed. This rules out my fallback to creation of a filter per vnic and removal with vm destruction :-( It seems that OpenStack falls into this trap as well, with neutron/agent/linux/iptables_firewall.py's creation of an iptables chain per port.

The remaining alternative is to replicate a set of filters over all managed hosts. Maintaining something like that is a mission from hell, particularly since one cannot update a filter while it's used by an active VM. Any idea for a way out of this impass?