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

[Stefan Berger]

libvir-list-bounces at redhat.com wrote on 02/04/2010 08:50:29 AM:

> 
> libvir-list, Gerhard Stenzel, Vivek Kashyap
> 
> 2010/2/4 Gerhard Stenzel <gstenzel at linux.vnet.ibm.com>:
> > On Mon, 2010-01-25 at 14:59 +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.
> >
> > Daniel,
> > we could achieve something similar with the following construct:
> >
> > <xi:include href="demofilter.xml"
> > xmlns:xi="http://www.w3.org/2001/XInclude"/>
> >
> > This would also have the advantage that the filter rules do not 
clutter
> > up the domain xml, but the migration of the rules might be simpler to
> > implement.
> > What is your thinking about this approach?
> >
> > --
> > Best regards,
> >
> > Gerhard Stenzel,
> 
> Such an include mechanism was suggest by Dan before, but I don't think
> that XInclude is a good approach, because this will make the XML
> handling more complicated.
> 
> The main libvirt functions to define/create a new guest are
> virDomainDefineXML and virDomainCreateXML. Both take the domain XML
> description a string. They don't take filenames. Using XInclude
> introduces the need for filenames to be able to reference them by the
> href attribute of an XInclude element. Even if libvirt stores the
> filter rules as files internally this should be considered as an
> implementation detail. IMHO exposing paths to internal files isn't a
> good design decision. The same is true for virDomainGetXMLDesc, it
> would have to expose paths to internal files to be read by management
> applications using libvirt.
> 
> I think the best approach to handle the filter setup while being able
> build complex filter from simpler parts is an include mechanism, but
> not using XInclude or reference the filter parts by filename, but by
> filter name.

The problem with the references is the migratability. In my opinion, the 
filters attached to a virtual machine's interface should migrate to a 
destination host completely transparently using 'virsh migrate' and allow 
migration to fail if the instantiation of the rule fails due to for 
example a missing ebtables/iptables support module, but not due to missing 
filter XML. This means that in the simple case where the VM had a filter 
rule no-ip-spoofing active on an interface on the source this same 
filtering should become active on the destination. However, most VMs will 
have much more complex rules and may use references to existing templates 
and add their own interface specific rules on top of that. Now how do you 
migrate that? How do you handle cases where a template on the source was 
referenced and may be missing on the destination or if the template on the 
destination is different (ignore it?). I guess the more involved solution 
would be to migrate the whole tree of referenced filters and using 
internal APIs to again make them available on the host, failing if filters 
with same names already exists, succeeding for others. Not sure whether 
the migration protocol can handle that...

> 
> <domain>
>   <devices>
>     <interface>
>       <filter name='demofilter'/>
>     </interface>
>   </devices>
> </domain>
> 
> <filter name='demofilter'>
>   <include filter='dropall'/>
>   ...
> </filter>
> 
> <filter name='dropall'>
>   ...
> </filter>
> 
> libvirt would have API to handle filters by name and their XML
> description in string form, no file handling involved. Maybe something
> like this in line with the rest of the libvirt API:
> 
> virConnectListFilters to list all known filters
> virFilterDefineXML to define a filter from an XML description in string 
form
> virFilterUndefine to undefine an existing filter
> virFilterGetXMLDesc to get the XML description in string form of an
> existing filter
> virFilterLookupByName to find a filter by name
> ...

Yes, initial prototype provides similar functions but does not solve the 
migration problem ...

   Stefan


> 

> Matthias
> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100204/829af062/attachment-0001.htm>