On Wed, Oct 30, 2013 at 09:33:51PM +0000, Dan Kenigsberg wrote: > 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. Yep, OpenStack's usage isn't ideal. > 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? I believe you *can* update a filter while it is in use. NWFilter will build the new ruleset, then switch over to it atomically. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list