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(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org