On 05/17/2018 01:37 PM, Daniel P. Berrangé wrote: > 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. > So in the future , will the <filterbinding> possibly have a "type" attribute? Should we go there now or just leave it for the future? Would it be something that we'd need for one of the API's to come soon. All this code is mind-numbing. John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
