[libvirt] the case for volatile nwfilters

[Dan Kenigsberg]

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.