nic ordering is inconsistent between hard reboot

[Pavel Kholkin]

If instance is assigned to several networks nic ordering is inconsistent between hard reboots (for neutron). This information could be found in interfaces section of instance xml file.

Related-bug (for nova-network): https://bugs.launchpad.net/nova/+bug/1405271

[Alexander Bozhenko (alexbozhenko)]

For some reason LP doesn't shows this change
https://review.openstack.org/#/c/231009/
made for this bug.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Pavel Kholkin (<email address hidden>) on branch: master
Review: https://review.openstack.org/231009
Reason: this problem seems to be fixed

[Pavel Kholkin (pkholkin)]

this problem seems to be fixed, bug was not reproduced on devstack, moved to invalid

[Thom Gerdes (tgerdes)]

I have evidence of this occurring in Kilo. On my compute node: in the file /var/log/libvirt/qemu/instance-000002c0.log
I can see in the /usr/bin/kvm command line that the first and second network interfaces' mac addresses are transposed from one boot to the next (lines wrapped for readability)

2015-11-05 20:13:39.125+0000: starting up
....
-netdev tap,fd=50,id=hostnet0,vhost=on,vhostfd=47 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:df:3c:2a,bus=pci.0,addr=0x3 \
-netdev tap,fd=48,id=hostnet1,vhost=on,vhostfd=49 \
-device virtio-net-pci,netdev=hostnet1,id=net1,mac=fa:16:3e:b7:0d:88,bus=pci.0,addr=0x4 \
-netdev tap,fd=51,id=hostnet2,vhost=on,vhostfd=52 \
-device virtio-net-pci,netdev=hostnet2,id=net2,mac=fa:16:3e:5e:45:72,bus=pci.0,addr=0x5 \
-netdev tap,fd=53,id=hostnet3,vhost=on,vhostfd=54 \
-device virtio-net-pci,netdev=hostnet3,id=net3,mac=fa:16:3e:e9:68:03,bus=pci.0,addr=0x6 \
....
2015-11-06 22:36:52.829+0000: shutting down
2015-11-09 17:51:06.915+0000: starting up
....
-netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=42 \
-device virtio-net-pci,netdev=hostnet0,id=net0,mac=fa:16:3e:b7:0d:88,bus=pci.0,addr=0x3 \
-netdev tap,fd=43,id=hostnet1,vhost=on,vhostfd=44 \
-device virtio-net-pci,netdev=hostnet1,id=net1,mac=fa:16:3e:df:3c:2a,bus=pci.0,addr=0x4 \
-netdev tap,fd=47,id=hostnet2,vhost=on,vhostfd=48 \
-device virtio-net-pci,netdev=hostnet2,id=net2,mac=fa:16:3e:5e:45:72,bus=pci.0,addr=0x5 \
-netdev tap,fd=49,id=hostnet3,vhost=on,vhostfd=50 \
-device virtio-net-pci,netdev=hostnet3,id=net3,mac=fa:16:3e:e9:68:03,bus=pci.0,addr=0x6 \
...

The instance and it's ports were created via a heat template. The instance was not modified after first booting it. The instance was powered off and back on through the Horizon dashboard.

[Jian Wen (wenjianhn)]

Confirmed by wuhao. See bug 1520319

[Pavel Kholkin (pkholkin)]

Do you try abandonded fix above? If it helps I can make the same for stable/kilo.

[Thom Gerdes (tgerdes)]

I brought up a devstack in order to test that patch: It will not work for my use case. Our application is sensitive to the order of the attached networks, and that code will order the interfaces by their UUIDs, not the order specified when booting the instance. For example with two pre-existing ports:

$ nova boot --flavor m1.nano \
    --image cirros-0.3.4-x86_64-uec \
    --nic port-id=cadf451c-d578-467c-a79f-dc6e245af1c5 \
    --nic port-id=1d8d3a5b-be32-433b-b899-bb1d03b67e9a \
    test

expected: eth0 is port cadf451c-d578-467c-a79f-dc6e245af1c5 and eth1 is 1d8d3a5b-be32-433b-b899-bb1d03b67e9a.

actual [with that patch], the ports are always sorted alphabetically, which often will be wrong.

[Alexander Bozhenko (alexbozhenko)]

@Pavel what version did you use when you originally reported this bug? Probably, root cause was https://bugs.launchpad.net/mos/+bug/1501430

[Zsolt Krenák (zsolt-krenak)]

I'm seeing a similar issue on Ubuntu 14.04 and Kilo 2015.1.4.

A VM with multiple interface loses connectivity after a rebuild or a shut off start.
One interface has floating-ip on which should be on eth0 the others are for other communicaton (internal). After a rebuild an internal interface gets the eth0 position and VM can not be reached with floating-ip.

[John Garbutt (johngarbutt)]

It looks like this has been fixed by this bug: https://bugs.launchpad.net/nova/+bug/1467581

Can anyone reproduce this on a branch that has the above fix applied?

[Launchpad Janitor (janitor)]

[Expired for OpenStack Compute (nova) because there has been no activity for 60 days.]