vif type unbound not supported when creating server

Bug #1705012 reported by Stefan Nica on 2017-07-18
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Low
Unassigned
networking-midonet
Critical
YAMAMOTO Takashi
networking-vsphere
Undecided
Unassigned
neutron
Critical
Kevin Benton

Bug Description

Creating a vmware server (using stable/newton packages) fails with the following error logged in nova-compute.log:

2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [req-a970b485-da9e-4032
-8c8a-af6f57d4d0f5 c8380cb1ad1842729061bff8d4a2b637 6fec64fa2bd947e680100e1877db
a0c7 - - -] [instance: c27d61ad-6884-4881-9fdb-5201c17141f7] Instance failed to
spawn
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-688
4-4881-9fdb-5201c17141f7] Traceback (most recent call last):
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-688
4-4881-9fdb-5201c17141f7] File "/usr/lib/python2.7/site-packages/nova/compute/
manager.py", line 2083, in _build_resources
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-688
4-4881-9fdb-5201c17141f7] yield resources
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-688
4-4881-9fdb-5201c17141f7] File "/usr/lib/python2.7/site-packages/nova/compute/
manager.py", line 1924, in _build_and_run_instance
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-6884-4881-9fdb-5201c17141f7] block_device_info=block_device_info)
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-6884-4881-9fdb-5201c17141f7] File "/usr/lib/python2.7/site-packages/nova/virt/vmwareapi/driver.py", line 316, in spawn
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-6884-4881-9fdb-5201c17141f7] admin_password, network_info, block_device_info)
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-6884-4881-9fdb-5201c17141f7] File "/usr/lib/python2.7/site-packages/nova/virt/vmwareapi/vmops.py", line 739, in spawn
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-6884-4881-9fdb-5201c17141f7] metadata)
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-6884-4881-9fdb-5201c17141f7] File "/usr/lib/python2.7/site-packages/nova/virt/vmwareapi/vmops.py", line 281, in build_virtual_machine
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-6884-4881-9fdb-5201c17141f7] network_info)
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-6884-4881-9fdb-5201c17141f7] File "/usr/lib/python2.7/site-packages/nova/virt/vmwareapi/vif.py", line 178, in get_vif_info
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-6884-4881-9fdb-5201c17141f7] is_neutron, vif))
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-6884-4881-9fdb-5201c17141f7] File "/usr/lib/python2.7/site-packages/nova/virt/vmwareapi/vif.py", line 164, in get_vif_dict
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-6884-4881-9fdb-5201c17141f7] ref = get_network_ref(session, cluster, vif, is_neutron)
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-6884-4881-9fdb-5201c17141f7] File "/usr/lib/python2.7/site-packages/nova/virt/vmwareapi/vif.py", line 153, in get_network_ref
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-6884-4881-9fdb-5201c17141f7] network_ref = _get_neutron_network(session, cluster, vif)
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-6884-4881-9fdb-5201c17141f7] raise exception.InvalidInput(reason=reason)
2017-07-11 13:52:02.494 21616 ERROR nova.compute.manager [instance: c27d61ad-6884-4881-9fdb-5201c17141f7] InvalidInput: Invalid input received: vif type unbound not supported

Stefan Nica (stefan.nica) wrote :

My initial investigation reveals that this started acting up in nova/stable/newton only after this following neutron patch was backported to neutron/stable/newton: https://review.openstack.org/#/c/470297/

If I manually restore these two changes in neutron/plugins/ml2/driver_context.py and restart neutron-server, I no longer see the problem:

        self._binding = copy.deepcopy(binding)
        self._binding_levels = copy.deepcopy(binding_levels)

Kevin Benton (kevinbenton) wrote :

Something must be different about how the vmware driver is doing port binding. I need someone with VMware expertise to take a look at this.

Changed in neutron:
assignee: nobody → Gary Kotton (garyk)
status: New → Triaged
Gary Kotton (garyk) wrote :

Hi,
Can you please let us know which neutron plugin you are using? If this is the ML2 plugin then which drivers?
Thanks
Gary

Changed in neutron:
status: Triaged → Confirmed
importance: Undecided → Critical
assignee: Gary Kotton (garyk) → Kevin Benton (kevinbenton)
Stefan Nica (stefan.nica) wrote :

My setup is using the ml2 plugin, with both vmware_dvs and openvswitch mechanism drivers enabled. This is the ml2 section of my ml2_conf.ini:

[ml2]
type_drivers = vlan,vxlan,gre,flat
tenant_network_types = vlan,vxlan,gre
mechanism_drivers = vmware_dvs,openvswitch,l2population
extension_drivers = port_security

I should also note that I'm using a vlan network - the only type of network supported by the vmware_dvs driver - so there's no confusion about the type driver involved.

When vmware_dvs is configured, nova should receive a VIF type of 'dvs', but receives a 'unbound' value instead, which is the immediate cause of the error.

Sean Dague (sdague) on 2017-07-25
tags: added: vmware
Changed in nova:
status: New → Confirmed
importance: Undecided → Low
Kevin Benton (kevinbenton) wrote :
Changed in neutron:
status: Confirmed → Fix Released
Kevin Benton (kevinbenton) wrote :

@Sean,

Can you remove Nova? This is purely a Neutron/driver bug. Nothing to do on the Nova side.

YAMAMOTO Takashi (yamamoto) wrote :

I confirmed the symptom seen in bug 1700448 was fixed

Changed in networking-midonet:
assignee: nobody → YAMAMOTO Takashi (yamamoto)
importance: Undecided → Critical
milestone: none → 5.0.0
status: New → Fix Released
Stefan Nica (stefan.nica) wrote :

This issue has been fixed in Newton, but it's still reproducible in Pike. The simplest solution would be to revert https://review.openstack.org/#/c/441231/ from Pike the same way that https://review.openstack.org/#/c/470297/ was reverted in Newton. Kevin, do you agree with my assessment ?

Stefan Nica (stefan.nica) wrote :

Actually, for Pike, it will not be enough to revert https://review.openstack.org/#/c/441231/, we also need to revert https://review.openstack.org/#/c/441231, which is an update of the previous one.

Fix proposed to branch: stable/pike
Review: https://review.openstack.org/577156

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers