Daniel, thanks a lot for your input! Please see my novel below ;) > I could have sworn I've previously reviewed patches which dealt with > NIC device naming changes across migration, but I can't find them > now. Did you ever submit patches which tried to fix this, or am I > perhaps thinking of someone elses.
> I understand the difficulty in getting the information across to > the right place, but I thought I remembered seeing a solution ot > that. Failing that though, the other option is to rename the ethernet > devices when assigning them to a guest, so they have a stable name > across hosts. This was in the spec of sriov-live-migration with macvtap [4] I already talked to Robert Li who is the main owner of this spec. What they are finally doing is to modify the xml with the new source device name during pre_live_migration. But as it's in the pci context, they can figure out the target interface name via the nova pci manager - I would need to talk to neutron. For Device renaming I would required another unique identifier which can be used for everlasting configuration on a host, as the device name is not stable anymore. The only thing that comes to my mind is the mac address. It could be used as identifier on all distros, regardless of the network adapter type used. Then on agent start, the neutron agent could rename the interface along a calculated pattern (e.g. net_<physnet-name> or whatever) The disadvantage would be, that the value of the interface_mappings parameter, that maps and interface to a physical network will look differently on every hypervisor (as there's another mac on each host). But that would be a compromise that would be ok I guess (maybe a little more difficult for chef deployment) These are the disadvantages Rob pointed out: "The approach was initially chosen and implemented. One of the issues is how to revert the interface back to its original interface name once the interface is freed. In addition, changing the names back and forth is considered by some people as being a bit complicated." I will think about these concerns as well, but they seem not to be unsolvable! Anyhow this will be in the scope of neutron in my case, so nothing nova should worry about too much. So for now I see the following approaches: 1) Use the mac address as identifier in the interface_mappings configuration and rename the corresponding interface to a openstack global name (e.g net_<physnet-name>). This ensures that the device has the same name on each hypervisor 2) Document, that for Live Migration the admin has to ensure, that the eth devices use for a physical network, must have the same name over all nodes. 3) Duplicate the neutron config with the interface_mappings to nova.conf 4) Have a shortcut between nova and neutron to figure out the target device name before live migration In all 4 cases both vif_types would be thinkable: a) use macvtap vif_type (direct) in domain.xml [2] --> vif plug/unplug would be required for creating vlan/vxlan devices b) use libvirt network vif_type in domain.xml [1] --> vif plug/unplug has to create the libvirt network and vlan/vxlan devices --> no additional value add comes with the libvirt network approach The most promising solutions sound to be 1 a). But I still need to figure out more details about device renaming and what other side effects might come with it. At least it looks like that I can drawback my blueprint for a libvirt network vif type [1], as it does not bring any additional benefits... Or do you still see anything that might justify the libvirt-network type? Or would you prefer another option, or even have a better one? ;) Thanks! [1] https://blueprints.launchpad.net/nova/+spec/libvirt-network-vif [2] https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif [3] https://launchpad.net/networking-macvtap [4] https://blueprints.launchpad.net/nova/+spec/sriov-live-migration -- Andreas (irc: scheuran) __________________________________________________________________________ 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