On Tue, Jan 26, 2010 at 10:16:23AM -0500, Stefan Berger wrote: > libvir-list-bounces@xxxxxxxxxx wrote on 01/26/2010 08:35:36 AM: > > > > > 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. > > 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. > > 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 > filters and referenced sub(-sub)-filters to the target host. Correct? Yes, management apps are responsible for ensuring that each host within a "migration pool" has the same configuration for all relevant areas, including storage mount points / device naming, network device naming, firewall configuration, etc, etc Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list