libvirt: Custom disk_bus setting is being lost on hard_reboot

Currently, a non-default disk_bus setting of and image will not be used,
when powering on an instance (or _hard_reboot).

hard_reboot() should use image_meta, if it exist, when constructing
the disk_info

Closes-Bug: #1255449

Change-Id: I477f69c47515ad22165421b4d23ac865c7869873
Update vnc virt driver api to take Instance object

Update the get_vnc_console() virt api method to take an Instance object
instead of a dict.  No real changes were needed in the drivers to make
this work.  While we're changing the API call, add the context, as well.

Change-Id: I2026ea725d61df4b88e7618f9fd4498c62843296
Make Instance object compatible with older compute nodes

This teaches the Instance object how to make itself compatibile with
older compute nodes running code from a few revisions ago.

Related to blueprint icehouse-objects

Change-Id: I3fe7d89751ad191c24cf6daa7e281eb480e83e1f
Require List objects to be able to backlevel their contents

Right now, a client declares its supported version of a given object
automatically in the remoted calls it makes to conductor. However,
in the case of things like InstanceList.get_by_foo(), they are
reporting the version of their InstanceList object, not their
Instance object. Conductor fills a version-matching InstanceList
object with brand new Instance objects, which the client, of course,
barfs on.

There may be a better way to handle this going forward, but for now,
stop the bleeding by requiring a version bump to the corresponding
List object whenever the object type it contains takes a version
bump. This adds a test to validate that all the objects registered
have a suitable mapping for the current version in the tree.

Since this actually caused a breakage in the Instance object
recently, this also bumps the InstanceList version so that
conductors running this commit (or later) will properly send
version 1.9 Instance objects to Havana clients and version 1.10+
to newer ones.

Change-Id: I2668dead4784fbd0411d1b6372a9a8006eeb2e84
Related-Bug: #1258256
Closes-Bug: #1254902
Merge "Update vnc virt driver api to take Instance object"
Merge "libvirt: Custom disk_bus setting is being lost on hard_reboot"
Merge "Make Instance object compatible with older compute nodes"
Merge "Require List objects to be able to backlevel their contents"
XenAPI: Speedup host_ref cannot change - get it once

The host we run on is fixed - getting this each time from XAPI
is expensive

Change-Id: Ifee9a778f3ed855ef52b001de3fc2ebbd0b972cf
XenAPI: get_info was very expensive

Getting the whole VM record is expensive and slowed down Tempest tests
significantly.  Replaced with getting each required item.

When getting power state, only need that specific value, so reduce the
calls to get_info too.

Change-Id: I93bcef5b692a531aac41518dc29d5d4f46cded65
XenAPI: Tidy calls to get_all_ref_and_rec

get_all_records is more efficient than getting them individually in the
old get_all_ref_and_rec implementation.

Replaced some cases of get_all_records with a faster and more
specific API call.

Change-Id: I4725c3f1fdebdf1737941cb7db69b19afb22df9f
XenAPI: Speedup get_vhd_parent_uuid

In many cases the VDI record has already been retrieved.
Use it rather than expensively getting a new VDI record from XAPI.

Change-Id: I469e2a415c1f1924010f47d3927ca18c45a7b8f8
XenAPI: Use get_VALUE in preference to get_record()['VALUE']

Replaces calls to get_record where only a single item is retrieved
from the record with the specific get_VALUE call.

Change-Id: I52e20c4f4c9d6a6ad019694916ee057cc96b18a6
XenAPI: Monitor the GC when coalescing

Add a new host plugin to monitor whether the garbage collector is running.
This is then used by the wait_for_vhd_coalesce function to know whether
waiting any more is likely to produce the expected results.

Increased the number of times we loop waiting for coalesce as the loop
now has knowledge that something is still happening.

Change-Id: Idcc0738945bd1aee8cdb52c9cfabd798f85c31db
Closes-bug: 1258169

Conflicts:

	nova/virt/xenapi/vm_utils.py
XenAPI: Use direct IO for writing config drive

If you don't use direct IO when writing to the device, the unplug
immediately following this may not succeed as the device may still
be in use.

Also add a sync to ensure the device is not being used at the point
of unplug.

Closes-bug: 1259163

Change-Id: I68f09835648b36772a7839af9718123a4c60734f