Use 201 instead of 200 for action create of flavor-manage v3

All of v3 create action should return 201. Fix this for flavor-manage v3

Closes-bug: 1252162
DocImpact

Change-Id: I4fc698abdf89c93cb6ea0990ae43960f8c651d95
Fix logic in LibvirtConnTestCase._check_xml_and_uri

The _check_xml_and_uri method has two loops making it
iterate over different hypervisor types. By default it
will iterate over qemu, kvm, xen and lxc, but it can be
made to only check xen by setting the 'xen_only' param
or the 'expect_xen_hvm' parameters.

Unfortunately the second loop is only filtered if the
'expect_xen_hvm' parameter is set, not if only the
'xen_only' parameter is set. This flaw hasn't showed
up before, due to a flaw elsewhere in the libvirt
driver code, cancelling it out.

Change-Id: If70faa05975b726067ab6edaa505ca8d0c230a38
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Remove duplicate setting of os_type in libvirt config builder

In the following change

  commit 158d821204d2f79cc06c1443562b3ce9bbe7cb9f
  Author: Christoph Thiel <cthiel@suse.com>
  Date:   Thu Jul 26 00:07:24 2012 +0200

    libvirt driver: set os_type to support xen hvm/pv

The libvirt driver get_guest_config() method was changed to
use the 'vm_mode' property from the instance to set the guest
os_type attribute. If this property was not set, then it used
defaults based on the virt type. Unfortunately it neglected to
remove most of the existing later code which also set os_type
based on virt type. So in many cases we end up setting the
os_type twice. Fortunately this did not have any ill effects,
since only Xen currently needs the ability to override os_type
using 'vm_mode'. This change cleans up the mess to avoid
future confusion & problems.

Change-Id: Ib11cb1196755f993b07e892e9f2adfc36e44a4e2
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Merge "Fix logic in LibvirtConnTestCase._check_xml_and_uri"
Merge "Remove duplicate setting of os_type in libvirt config builder"
Merge "Use 201 instead of 200 for action create of flavor-manage v3"
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: Synchronize on all VBD plug/unplug per VM

Dynamically adding or removing a device needs to be synchronized
to work around a bug in XenServer 6.1 and 6.2 where simultaneous
events can be partially ignored, leading to a failure to plug or
unplug.

Change I041365ed863a1a1c55e88025dff42d01c35494a2 attempted to
work around the issue by retrying - however that does not catch
all failures.  This change should eliminate some of the known
INTERNAL_ERROR failures, but not all, so I041 should not be
reverted.

Change Ie7a64c481a9e3874df9d5924fbb050ac7ab117db does the same
as this, but only for VBD.plug.

Change-Id: If78d4e5f1dd84f1d4a588f25b8f887a7b125bbea
Closes-bug: 1217972
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:

	etc/nova/nova.conf.sample
	nova/virt/xenapi/vm_utils.py