Open Stack

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)