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

[Daniel P. Berrange]

On Tue, Jan 26, 2010 at 10:16:23AM -0500, Stefan Berger wrote:
> libvir-list-bounces at 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?

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 :|