In terms of the public bug, around migration not setting up security groups, you can see my attempt at a "proper" fix here: https://review.openstack.org/#/c/38455/
I am not really sure how to fix it for live-migration, need someone with more neutron skills than me really.
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: https://github.com/openstack/nova/blob/master/nova/virt/xenapi/vmops.py#L444 https://github.com/openstack/nova/blob/master/nova/virt/xenapi/vmops.py#L462
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.
@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: /github. com/openstack/ nova/blob/ master/ nova/virt/ xenapi/ vmops.py# L444 /github. com/openstack/ nova/blob/ master/ nova/virt/ xenapi/ vmops.py# L462 /github. com/openstack/ nova/blob/ master/ nova/virt/ xenapi/ vmops.py# L311
https:/
https:/
And put it either side of the boot command here (for migration):
https:/
In terms of the public bug, around migration not setting up security groups, you can see my attempt at a "proper" fix here: /review. openstack. org/#/c/ 38455/
https:/
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: /github. com/openstack/ nova/blob/ master/ nova/virt/ xenapi/ vmops.py# L1881
https:/
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: /github. com/openstack/ nova/blob/ master/ nova/virt/ xenapi/ vmops.py# L444 /github. com/openstack/ nova/blob/ master/ nova/virt/ xenapi/ vmops.py# L462
https:/
https:/
In libvirt, I think the VIFs are plugged before the live-migrate happens, so its covered by this method call: /github. com/openstack/ nova/blob/ master/ nova/compute/ manager. py#L3794 /github. com/openstack/ nova/blob/ master/ nova/virt/ xenapi/ driver. py#L418 /github. com/openstack/ nova/blob/ master/ nova/virt/ libvirt/ driver. py#L3332
https:/
XenAPI has a rather dodgy implementation of that:
https:/
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:
https:/
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.