<tt>libvir-list-bounces@redhat.com wrote on 01/26/2010 08:35:36 AM: </tt> <tt>> > 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 managed > > > here. I would suggest that '<firewall>' and '<template>' elements are > > > redundant, and that <filter> should be for the top level managed objects. > > > 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.</tt> <tt>A VM may be allowed to generate traffic on multiple VLANs (having multiple different VLAN interfaces inside the VM). For that we may need different rules per VLAN traffic that the VM is allowed to send traffic on.</tt> <tt>Since we only reference the filter in the interface XML, I suppose that we need to rely on higher layers to take care of migrating those</tt> <tt>filters and referenced sub(-sub)-filters to the target host. Correct?</tt> <tt> Stefan</tt>