Open Stack

> But I still need to
> figure out more details about device renaming and what other side
> effects might come with it.

Device renaming might not be a good idea in the macvtap context, as the
interface used could also be used with by other applications that might
insist on a fixed device name. It's not like in the sriov case, where
there's a pool of interfaces that is handled as Openstack resource. It's
more like with ovs vxlan approach - the eth device used for tunneling
could also be used by other apps and is not dedicated to Openstack



I digged deeper into the Live Migration code. I wonder if before live
migration, some checking is done if the target hypervisor could serve
the same physical network with neutron as well? I haven't found
something like that. 
The only thing I found is, that during pre_live_migration the nova plug
code is being called. and some instance specific netork info is being
gathered

Are you aware of additional checkings?


I also had the following other ideas:

- use the libvirt network approach and have a api call to
neutron-agent-show in our "vendor" specific plug/unplug code

- if some other neutron pre_live_migration checkings exist, maybe I can
enrich the data with some content...


But I would need some more time for evaluation next week.


Thanks so far!

Andreas