Comment 12 for bug 1202266

So, not sure the best way to fix this stuff, advice needed.

I almost want to say we should just issue an advisory to clarify the state of the security groups feature as "experimental" with more work required before it is production ready, and the work around is not to rely on security groups. But that doesn't feel like the right response. However a proper fix will require this feature to (effectively) be implemented.

So lets try summarize the issues:
* nova has missing calls to the firewall driver (there are open public bugs on this one, and there are fixes in progress, in the public, which is probably bad) - I am happy to look into getting this fixed, but do we need to backport these? Will need a networking expert to check the fixes.
* the firewall driver in nova doesn't work with OVS - I could do with a hand fixing that
* I don't know the state of the various neutron drivers and how they interact, we don't yet have the equivalent VIF drivers for XenAPI, but that might not matter - again, not something I really know how to fix
* MAC and IP address spoofing should also be checked

Going into the firewall driver issues, it was written when XenServer used bridge networking, back in 5.6. The OVS case has always been avoided, because until recently, the version of OVS shipping with XenServer (apparently) did not have the bit masking operation that would allow you to avoid some of the worst bits of rule explosion in the number of rules. You need to take care, because there is a massive OVS slowdown once the rules don't fit in your processors L2/L3 cache, or something like that, which would give users a sort of DoS attach on the other VMs the host their VM is present.