[libvirt] [PATCH V4] nwfilter: Add support for ipset

Eric Blake eblake at redhat.com
Thu May 17 22:46:54 UTC 2012


On 05/15/2012 11:47 AM, Laine Stump wrote:

>> Since ipset management is quite complex, the idea was to leave ipset
>> management outside of libvirt but still allow users to reference an
>> ipset.
>> The user would have to make sure the ipset is available once the VM is
>> started so that the iptables rule(s) referencing the ipset can be
>> created.
> 
> I think that at least a subset of it needs to be in libvirt, if only so
> that the use of ipset makes sense when it isn't available natively on a
> host. On that topic - could the new XML you're proposing be made
> useful/applicable with a packet filtering system other than iptables
> (or, for that matter, on a system with iptables but no ipset?). Or is it
> specific to ipset? (I haven't thought about it enough to come up with my
> own answer; I'm just at the stage of questions).
> 
> I'm concerned that we might add something by definition
> iptables-specific, and even within that requiring a particular version
> of iptables, which would then be difficult/impossible to translate to
> some other filtering system. If there are too many features like that,
> we can be guaranteed that we'll never see any support other than iptables.

I'm a bit worried about this too.  In an IRC chat with Stefan, he
mentioned to me the possibility of adding a new virIpsetPtr object
(similar to virNwfilterPtr) with operations to construct the set in that
manner; and where if the underlying iptables or other firewall solution
doesn't support sets natively, then maybe libvirt can still use the
virIpsetPtr object to manually expand into one rule per combination of
the set.  Obviously not as efficient as using the iptables ipset
functionality, but that description sounds to me like ipset is a way to
optimize existing firewall technology, rather than a new form of filtering.

So I think we have room to expand libvirt XML in the future to expose an
ipset object, even if we don't support it right away, and in the
meantime, the optimizations are worth supporting to make nwfilter
faster.  So I'm leaning 70-30 towards including this patch even if we
don't yet have a way to create ipset objects from within libvirt.

Any other opinions?

> (Yes, I know we currently only have a driver for iptables, but it seems
> like a good idea to not lock us into that. I've got this thought in the
> back of my head that maybe someday firewalld could (should?) be
> supported as a separate driver, rather than just using its passthrough
> mode (which bypasses some of the automatic management it's trying to
> provide, for better or for worse)) (It's really too bad nobody has
> written an ipf (or whatever) filter driver for libvirt - that would help
> keep us honest when adding new features :-)
> 

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120517/2d1c946f/attachment-0001.sig>


More information about the libvir-list mailing list