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

2010/2/4 Gerhard Stenzel <gstenzel(a)linux.vnet.ibm.com&gt;: 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