nova team mailing list archive
Mailing list archive
Re: Network filtering for libvirt and for non-libvirt hypervisors
Apologies for the delay in replying to this -- I've been travelling. Replies
inline where they belong.
On Wed, Sep 15, 2010 at 12:33:37PM +0100, Soren Hansen wrote:
> I have a spec and a corresponding branch about making basic use of
> libvirt's nwfilter support. It basically just adds a snippet to the
> libvirt templates that enables a number of network filtering techniques.
> Specifically, it prevents MAC spoofing, ARP spoofing, and IP spoofing. I
> didn't bother making this configurable, since it seems like the sort of
> thing everyone will always want. As such, there's no API call to enable
> it, nor is there a setting in the datamodel that enables/disables it.
> While this is a great feature to have, it raises a few questions about
> the non-libvirt hypervisors.
> Ideally, of course, we don't want the choice of hypervisors to affect
> the utility of Nova. Lacking decent network filtering IMO limits a cloud
> computing platform's utility significantly.
> So, what to do? Should we more clearly define the contract to which a
> hypervisor driver is meant to adhere and list the above mentioned
> spoofing protections as requirements?
I think in the future we have to be willing to accept that some features are
optional at the hypervisor layer. When I add the "play the Blue Danube Waltz
through the PC speaker" feature that I've been working on, I don't expect
all other platforms to support it. Particularly since that would mean getting
it into the underlying platforms _and_ libvirt.
For most things though, we're likely to want them to be supported by all
platforms equally. Anti-spoofing is definitely one of those. I would
certainly support a common profile for hypervisors, saying what they need to
be able to to in order to be OpenStack-ready. This feature is definitely one
Note that XenServer (the commercial product) can't actually do this network
filtering today. Netfilter is compiled out of our commercial kernel, and we
don't yet support the use of Open vSwitch, which would be the alternative
implementation. We will be addressing this with haste, as we recognise the
necessity of this in any public cloud environment.
Users of Xen Cloud Platform (the OSS software) can of course compile a kernel
with netfilter support, so we will be able to test this particular feature
through XenAPI using XCP.
> We could assign specific people as
> designated maintainers of the different hypervisor drivers, and make it
> their responsibility to make their driver conformant to the contract.
I'm happy for Citrix to take that role for the XenAPI driver.
I assume that you wouldn't want to block a merge on the grounds that it
extended the hypervisor contract without the necessary changes to all the
drivers. That would end up as a big bottleneck waiting for everyone to
implement their piece. I wouldn't want to block merges like that. However,
it's probably reasonable that we would want to co-ordinate well enough that
the support was lined up for each release milestone.
That means that someone who wants to extend the hypervisor contract would
need to check that there was enough manpower available from each of the
designated maintainers in order to get the work completed before the next
release. Either that, or the feature has to be optional.
How does that sound?