[libvirt] the case for volatile nwfilters

Daniel P. Berrange berrange at redhat.com
Thu Oct 31 09:20:16 UTC 2013


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 :|




More information about the libvir-list mailing list