[RFE] bridge name not set in vif:binding-details by ml2/linux-bridge

[sean mooney]

* Summary: bridge name not set in vif:binding-details by ml2/linux-bridge.

* High level description: when ports are bound the linux bridge name should be
populated in the vif:binding details so that it can be used by nova to during
live migration.

* Expected output: when a port is bound by ml2/linux-bridge the linux bridge bridge
name is populated in vif:binding-detail and on live migation of a vm form
ovs to linux bridge the vm is correctly plugged to the correct linux bridge.

* Actual output:
nova libvirt error in virDomainMigrateToURI3 because the xml generated based
on the destination port binding used the source bridge name since it was not
available in the dest vif binding.

ug 14 12:16:33 devstack1 nova-compute[14852]: Traceback (most recent call last):
Aug 14 12:16:33 devstack1 nova-compute[14852]: File "/usr/lib/python2.7/site-packages/eventlet/hubs/hub.py", line 457, in fire_timers
Aug 14 12:16:33 devstack1 nova-compute[14852]: timer()
Aug 14 12:16:33 devstack1 nova-compute[14852]: File "/usr/lib/python2.7/site-packages/eventlet/hubs/timer.py", line 58, in __call__
Aug 14 12:16:33 devstack1 nova-compute[14852]: cb(*args, **kw)
Aug 14 12:16:33 devstack1 nova-compute[14852]: File "/usr/lib/python2.7/site-packages/eventlet/event.py", line 168, in _do_send
Aug 14 12:16:33 devstack1 nova-compute[14852]: waiter.switch(result)
Aug 14 12:16:33 devstack1 nova-compute[14852]: File "/usr/lib/python2.7/site-packages/eventlet/greenthread.py", line 214, in main
Aug 14 12:16:33 devstack1 nova-compute[14852]: result = function(*args, **kwargs)
Aug 14 12:16:33 devstack1 nova-compute[14852]: File "/opt/stack/nova/nova/utils.py", line 810, in context_wrapper
Aug 14 12:16:33 devstack1 nova-compute[14852]: return func(*args, **kwargs)
Aug 14 12:16:33 devstack1 nova-compute[14852]: File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 7134, in _live_migration_operation
Aug 14 12:16:33 devstack1 nova-compute[14852]: LOG.error("Live Migration failure: %s", e, instance=instance)
Aug 14 12:16:33 devstack1 nova-compute[14852]: File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
Aug 14 12:16:33 devstack1 nova-compute[14852]: self.force_reraise()
Aug 14 12:16:33 devstack1 nova-compute[14852]: File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise
Aug 14 12:16:33 devstack1 nova-compute[14852]: six.reraise(self.type_, self.value, self.tb)
Aug 14 12:16:33 devstack1 nova-compute[14852]: File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 7127, in _live_migration_operation
Aug 14 12:16:33 devstack1 nova-compute[14852]: bandwidth=CONF.libvirt.live_migration_bandwidth)
Aug 14 12:16:33 devstack1 nova-compute[14852]: File "/opt/stack/nova/nova/virt/libvirt/guest.py", line 673, in migrate
Aug 14 12:16:33 devstack1 nova-compute[14852]: destination, params=params, flags=flags)
Aug 14 12:16:33 devstack1 nova-compute[14852]: File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 186, in doit
Aug 14 12:16:33 devstack1 nova-compute[14852]: result = proxy_call(self._autowrap, f, *args, **kwargs)
Aug 14 12:16:33 devstack1 nova-compute[14852]: File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 144, in proxy_call
Aug 14 12:16:33 devstack1 nova-compute[14852]: rv = execute(f, *args, **kwargs)
Aug 14 12:16:33 devstack1 nova-compute[14852]: File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 125, in execute
Aug 14 12:16:33 devstack1 nova-compute[14852]: six.reraise(c, e, tb)
Aug 14 12:16:33 devstack1 nova-compute[14852]: File "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 83, in tworker
Aug 14 12:16:33 devstack1 nova-compute[14852]: rv = meth(*args, **kwargs)
Aug 14 12:16:33 devstack1 nova-compute[14852]: File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1745, in migrateToURI3
Aug 14 12:16:33 devstack1 nova-compute[14852]: if ret == -1: raise libvirtError ('virDomainMigrateToURI3() failed', dom=self)
Aug 14 12:16:33 devstack1 nova-compute[14852]: libvirtError: Cannot get interface MTU on 'br-int': No such device

during port binding the linux bridge ml2 diriver does not set the destination bridge name in the vif bindings.
as a result when we regenerate the libvirt xml we produce the following fragment for the nic update
           Updating guest XML with vif config: <interface type="bridge">
Aug 14 12:15:27 devstack1 nova-compute[14852]: <mac address="fa:16:3e:a9:cf:09"/>
Aug 14 12:15:27 devstack1 nova-compute[14852]: <model type="virtio"/>
Aug 14 12:15:27 devstack1 nova-compute[14852]: <source bridge="br-int"/>
Aug 14 12:15:27 devstack1 nova-compute[14852]: <mtu size="1450"/>
Aug 14 12:15:27 devstack1 nova-compute[14852]: <target dev="tapbf69476a-25"/>
Aug 14 12:15:27 devstack1 nova-compute[14852]: </interface>

* Version:
  ** OpenStack version: Rocky RC1, neutron sha: 1dda2bca862b1268c0f5ae39b7508f1b1cab6f15, nova sha: afe4512bf66c89a061b1a7ccd3e7ac8e3b1b284d
  ** Linux distro, Centos 7.5
  ** DevStack

* Perceived severity: low (migrating form ovs to lb is not antisipated to be common)

[sean mooney (sean-k-mooney)]

not that if i create the a br-int linux bridge on the destination the migration succeeds but the vm has no network connectivity because the tap is connected to the br-int bridge not the linux bridge associated with the neutron network. so if the correct bridge name was used live migration would would.

[Hongbin Lu (hongbin.lu)]

To clarify, the error happened in nova side.

From neutron's point of view, this doesn't seem like a bug but a feature enhancement (because the request is to let neutron to provide more information to assist nova to bind the migrating port). I am going to mark this bug as RFE and leave it to neutron driver team for triaging.

[Miguel Lavalle (minsel)]

In the case of ovs, Neutron show the bridge in vif details:

| binding_host_id | allinone |
| binding_profile | |
| binding_vif_details | bridge_name='br-int', datapath_type='system', ovs_hybrid_plug='False', port_filter='True' |
| binding_vif_type | ovs |
| binding_vnic_type | normal |

And it should be the same in linuxbridge. So the "feature" already exists, it's just that it is not well implemented in the case of linuxbridge. Let's treat this as a bug

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Bug closed due to lack of activity, please feel free to reopen if needed.