Comment 15 for bug 1202266

@Thierry, sorry for the delay, screwed up my email filters, and just back from holiday.

I agree, its probably best to fix this up.

Not sure of the best way to phase this, but it would be good to alert people to the fact this

A quick fix for non-live migration is probably just a cut and paste of this code:
And put it either side of the boot command here (for migration):

In terms of the public bug, around migration not setting up security groups, you can see my attempt at a "proper" fix here:

I am not really sure how to fix it for live-migration, need someone with more neutron skills than me really.

The problem is the VM domain and networking is created on the destination by XenAPI, auto-magically, in a single live-migrate operation:

We could add a "post_live_migration_at_destination", that does the firewall setup, but that would be after the VM has become active on the destination, so there is likely to be a small period when the traffic is not filtered, unless we can some how block all the traffic during that time (which I think might happen when you have an OVS controller present, but I am not sure). The missing code that would go in post_live_migration, must be something like this:

In libvirt, I think the VIFs are plugged before the live-migrate happens, so its covered by this method call:
XenAPI has a rather dodgy implementation of that:
I see familar code in the libvirt driver, but I don't think that will work when the VIFs have not been created, and the VIFs are not created in time:

As far as getting a networking guru, I know Salvatore Orlando worked on this first implementation of these bits, maybe he would be a good person to cast his eye across the above ideas. But there might be someone on the security team who can help out, not sure who is on the list.