VMware: Improve logging on failure due to invalid guestId

If a glance image has a vmware_ostype property which doesn't
correspond to a valid VMware guestId, VM creation will fail with the
unhelpfully generic error message:

A specified parameter was not correct.

This change improves this situation slightly by logging a warning if
VM creation fails and guestId is not a recognised value. We limit
ourselves to logging a warning because we don't want to tightly couple
ourselves to the vSphere behaviour. We can't guarantee that this is
the reason the RPC call failed, or that it is the only reason the RPC
call failed.

DocImpact

This change doesn't impact the behaviour of the VMware driver except
that it will emit an additional warning message to the logs under the
circumstances described. However, given the potential for
user misconfiguration, we should describe this pitfall in the docs.

Closes-Bug: #1357263
Change-Id: I10e0982c6c450facdeea41c7f1d266e20a924d08
Adds tests for Hyper-V Host utils

Adds unit tests for Hyper-V HostUtils class.

Co-Authored-By: Adrian Bora <abora@cloudbasesolutions.com>

Partial-Bug: #1220256

Change-Id: Ife8bd054e467209692225087cf29d0f50f60a05b
Adds tests for Hyper-V Network utils

Adds unit tests for Hyper-V NetworkUtils and NetworkUtilsV2 classes.

Co-Authored-By: Ionut Balutoiu <ibalutoiu@cloudbasesolutions.com>

Partial-Bug: #1220256

Change-Id: I4c3da97aa415c4af1900aa17d1327571afc8c792
VMware: Improve the efficiency of vm_util.get_host_name_for_vm

get_host_name_for_vm was extremely and unnecessarily inefficient. In
fetching a host, it:

1. Got the host_ref for the VM
2. Threw away the type component of the host_ref
3. Retrieved all HostSystem objects known to vSphere
4. Searched them for the object matching the value component of the
   host_ref
5. Retrieved the name property from the returned component

The new implementation does:

1. Get the host_ref for the VM
2. Get the name property of the HostSystem object with that host_ref

Consequently, the following functions are no longer used, and go away:

* get_host_ref_from_id
* property_from_property_set
* get_host_id_from_vm_ref

get_host_ref_for_vm is modified in both its implementation (see
above), and to return the host_ref its name suggests rather than an
ObjectContent object.

Change-Id: I89a731b2c5df61f031b93c861b2e4a222da49e99
Switch Nova to use oslo.concurrency

Let's switch to the newly released oslo library for the
processutils and lockutils. We use the config fixture(s) to
specify disable_process_locking and lock_path in the CONF
variable of oslo.concurrency library for correctly setting the
flags.

The previous attempt at updating nova to use oslo.concurrency
was reverted as it stopped running any tests. lockutils-wrapper
should have been used in ini/shell scripts
instead of lockutils.py module as the the module is
no longer runnable (__main__ has been removed).  In this
review we use lockutils-wrapper correctly. The test harness
has since been updated to bail out if 0 tests are run as
well for additional insurance.

Change-Id: I14c75ef2196fd08c9465d648e5cd53777bd9c7d1
Co-Authored-By: Nikola Dipanov <ndipanov@redhat.com>
Co-Authored-By: Corey Wright <corey.wright@rackspace.com>
Make resource tracker always use Flavor objects

Make sure that even when the Flavor is extracted from the instance by
_get_instance_type, it is always a Flavor object we can work with.

Also fix test_tracker.py tests to actually extract the flavor from the
instance, and not fall back on Flavor.get_by_id in
ResourceTracker,_get_instance_type, since we should really never hit
that under normal circumstances.

Change-Id: If704ac386bd4f35dbb7b8e5c46fdd240445ee0a4
Blueprint: virt-driver-cpu-pinning
Merge "Adds tests for Hyper-V Host utils"
Merge "Adds tests for Hyper-V Network utils"
Merge "Switch Nova to use oslo.concurrency"
Merge "VMware: Improve logging on failure due to invalid guestId"
Merge "VMware: Improve the efficiency of vm_util.get_host_name_for_vm"
Merge "Make resource tracker always use Flavor objects"