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

[Matthias Bolte]

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.

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

Matthias