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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
