VMware: unable to launch an instance on a 'portgroup' provider network

[Gary Kotton]

The vmware_nsx NSX|V and DVS plugins enable a admin to create a provide network that points to an existing portgroup.

One is uanble to spin up and instance on these networks.

The trace is as follows:

2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] Traceback (most recent call last):
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2514, in _build_resources
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] yield resources
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 2384, in _build_and_run_instance
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] block_device_info=block_device_info)
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] File "/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/driver.py", line 429, in spawn
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] admin_password, network_info, block_device_info)
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] File "/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vmops.py", line 872, in spawn
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] metadata)
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] File "/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vmops.py", line 328, in build_virtual_machine
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] pci_devices)
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] File "/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vif.py", line 170, in get_vif_info
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] is_neutron, vif, pci_info))
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] File "/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vif.py", line 138, in get_vif_dict
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] ref = get_network_ref(session, cluster, vif, is_neutron)
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] File "/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vif.py", line 127, in get_network_ref
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] network_ref = _get_neutron_network(session, network_id, cluster, vif)
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] File "/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vif.py", line 117, in _get_neutron_network
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] raise exception.NetworkNotFoundForBridge(bridge=network_id)
        2016-08-20 01:16:01.289 13629 TRACE nova.compute.manager [instance: cd811ab1-9bef-4f07-b107-196276123a6a] NetworkNotFoundForBridge: Network could not be found for bridge 7bc687f6-aeff-4420-9663-03e75b7c28e3

This is due to the fact that the validation for the network selection is done according the the network UUID (which is the name of the port group). In the case of importing a existing port group this actually needs to be the name of the portgroup.

The NSX|V and DVS plugins enforce that the name of the network needs to match the name of the existing port group

[Sean Dague (sdague)]

There are no currently open reviews on this bug, changing the status back to the previous state and unassigning. If there are active reviews related to this bug, please include links in comments.

[Sean Dague (sdague)]

Found open reviews for this bug in gerrit, setting to In Progress.

review: https://review.openstack.org/358425 in branch: master

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/358425
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=77e51f14a50dafb46176e50ff3788e7918ff29df
Submitter: Zuul
Branch: master

commit 77e51f14a50dafb46176e50ff3788e7918ff29df
Author: Gary Kotton <email address hidden>
Date: Sun Aug 21 23:37:27 2016 -0700

    VMware: ensure that provider networks work for type 'portgroup'

    When an existing portgroup is used as a provider network the
    vmware_nsx NSX|V and DVS plugins will validate that the name
    of the network is the same name as the actual portgroup. This
    name is used when searching for the portgroup. Using the network
    UUID will not match here as that is the network UUID.

    A provider network can be a regular port group or a NSX virtual
    wire.

    Change-Id: Icc72b9c4ddd11964f0e4a774588684eb016fae0f
    Closes-bug: #1615498

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/nova 17.0.0.0b2 development milestone.