[libvirt] [PATCH v2 05/21] conf: add support for parsing/formatting virNWFilterBindingDefPtr

[Daniel P. Berrangé]

On Thu, May 17, 2018 at 01:31:04PM -0400, Laine Stump wrote:
> On 05/15/2018 01:43 PM, Daniel P. Berrangé wrote:
> > A typical XML representation of the virNWFilterBindingDefPtr struct
> > looks like this:
> >
> >   <filterbinding>
> >     <owner>
> >       <name>f25arm7</name>
> >       <uuid>12ac8b8c-4f23-4248-ae42-fdcd50c400fd</uuid>
> >     </owner>
> >     <portdev name='vnet1'/>
> >     <mac address='52:54:00:9d:81:b1'/>
> >     <filterref filter='clean-traffic'>
> >       <parameter name='MAC' value='52:54:00:9d:81:b1'/>
> >     </filterref>
> >   </filterbinding>
> 
> 
> I haven't had time to look at this in detail yet, or to really think
> about the comment I'm going to make, but I wanted to be sure I said it
> right away in case there are any public API implications
> 
> 
> By now we all know the horror by which OpenStack's networking creates a
> separate bridge device, and connects the guest's tap device to that
> bridge so that (in addition to other reasons) there is a place for
> libvirt's nwfilter rules to attach (what they *really* want to connect
> to is an Open vSwitch, but ipfilter rules aren't in the data path when a
> tap device is connected to OVS). This atrocity could be avoided if
> nwfilter supported OVN (OVS's ipfilter analog) directly. In order to
> support it though, nwfilter would need to know more details about the
> network device that it's adding rules for. (because some guests may be
> connected to OVS and others may be connected to a standard host bridge
> (or nothing at all) we can't just have a system-wide config to decide).
> 
> I can't recall if there is a reasonable API to figure out what a tap
> device is connected to, but I think such a thing may not exist and, if
> so, we'll likely need to send some sort of indicator in the
> NWFilterBinding XML. It *might* be simpler / more futureproof if we
> included the <virtualport> element that is already in the domain XML
> <interface> information - that's currently what we use to decide how to
> connect the tap device; hopefully in the future it will continue to
> conain everything that's needed (if we think that's inadequate, we could
> just go for broke and include the entire <interface>, but that's
> probably overkill. (although..... - thinking about the potential case
> where some SRIOV network card supported some sort of filtering, if we
> sent the entire <interface>, we would know that it was a hostdev...)
> 
> I started typing this wondering if the C API might need any change, but
> now that I've typed this, I realize it would only require additions to
> the XML, which can always be done later, so

Yes, that's exactly why I ended up using XML for this - originally I
had just used virTypedParameters but felt XML would give us better
future proofing.  Esstentially any part of the domain XML <interface>
that is related to the /backend/ of the device is fair game for us
to include in the filterbinding XML. I just started with the minimal
set of data, rather than try to wire up everything, so it is simpler.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|