libvir-list-bounces@redhat.com 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? Stefan