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

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