Re: [libvirt] [RFC] Proposal for introduction of network traffic filtering capabilities for filtering of network traffic from and to VMs

On Tue, Jan 26, 2010 at 02:24:43PM +0100, Gerhard Stenzel wrote: > On Mon, 2010-01-25 at 14:59 +0000, Daniel P. Berrange wrote: > > On Fri, Jan 22, 2010 at 01:29:16PM +0100, Gerhard Stenzel wrote: > > > On Wed, 2010-01-13 at 17:36 +0000, Daniel P. Berrange wrote: > ... > > > > The shear size of the ruleset inside the <interface> element is > > rather alarming to me. Imagine if you have a guest with more > > than one NIC. I'm inclined to suggest that the <interface> > > element in the domain XML description should only have a single > > rule > > > > <filter name='BLAH'/> > > > > and if apps wish to construct a filter, from multiple independant > > sub-filters, then that should be done against the filter object's > > config, rather than the domain object's config. > > > ... > > What was the idea with the empty attributes here ? Are those > > implying that the attribute value is to be filled in with the > > value from the domain XML ? If so I'd probably make that more > > explicit using something like $IP and $MAC to represent the > > guest configured IP/MAC > > > ... > > I don't think that '<firewall>' is the top level object to be

> > here. I would suggest that '<firewall>' and '<template>' elements

> > redundant, and that <filter> should be for the top level managed

> > The libvirt API would allow listing of existing filters, creating / deleting > > filters and updating the config. The <filter> element would allow some kind > > of <include> element to allow a complex filter to be built out of multiple > > simpler filters. > > > > > > Regards, > > Daniel > > Daniel, > > ok, trying to combine your suggestions: > > - guest contains a single filter reference per interface > > guest.xml: > ---------- > <domain type='kvm'> > <name>demo</name> > <memory>256000</memory> > <devices> > <interface type="bridge"> > <filter name='demofilter' ipaddr='10.0.0.1'/> > </interface> There's no need for ipaddr there - the XML schema already allows for a <ip address='10.0.0.1'/> within the <interface> tag here. We already have MAC address as a separate tag too. We could likely add VLAN in a similar way.