> 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
