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? Dan. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list