CP-6172: Add VBD.other_config:backend-kind

Note: this change is co-dependent on a change in xenopsd.

Blktap3 and kernel blkback need to co-exist and, since kernel blkback watches
keys in the /local/domain/0/vbd/ tree, the paths for blktap3 need to be moved.

A new key has been added to the other_config field of the VBD record which is
passed through to xenopsd to determine where to place the VBD's XenStore
entries.

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
CP-6172: Don't specify VBD backend-kind by default

Rather than defaulting this value (meaning we have to keep parity with
xenopsd), leave the default to be determined by xenopsd itself by not
specifying a backend-kind.

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
CP-6172: Xenopsd support for Blktap3

This allows Blktap2 and Blktap3 to coexist.

Note: the backend path is specified by a new "backend-kind" key in the
extra_backend_keys of the VBD metadata.

The default_vbd_backend_kind is configurable option and can be specified by
setting default-vbd-backend-kind in xenopsd.conf.

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
CP-6172: Refactor blktap3 support for backport

The work for Xenopsd to support multiple VBD backends was developed upstream in
xenopsd.git (post disaggregation) and was then squashed and ported wholesale in
478563a.

There are a number of differences in this pre-disaggregation world and this
commit adds the changes necessary for the backport to work:

    * Some fixes for the `xenops` binary to ignore the Vbd variant type
    * Move the parsed config away from xenopsd.ml to avoid circular dependency

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
CP-6172: Enable blktap3 as default VBD backend kind

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
CA-131057: Use list_frontends to get frontend device

This is how 'upstream' xenopsd.git gets a frontend in this function. Now we
support multiple backends for VBD, using list_devices is too naive and doesn't
construct the right device type for shutdown for example.

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
CP-8191: Nuke xenguest and dumpcore, because of the latest change to the libxc API

Backported from trunk 5394ac5d80dbf604e5c12c5ca97c2ec6a1512c44

Original patch from Andrew Cooper.
CP-8191 - Use 64bit location qemu-dm.
Fix logic at the conclusion of Xenguest for domain creation and migration.

As part of the control protocol, Xenguest is expected to write the string

   "result: <xenstore mfn> <console mfn>\n"

to the a pipe back into xenops.  forkexecutioner has already executed a
waitpid() on the xenguest process, waiting for it to exit.

Unfortunately, as soon as xenops receives the result string, it decides to
SIGTERM the xenguest process.

This begins a race condition.  If xenguest finishes executing and exits
cleanly (which it will do, given the result string) in a timely fashion, fe
will record success and the domain creation/migration will be all good.

If however xenguest gets killed with the SIGTERM before it has exited cleanly
(such as actually having valgrind wrapped around xenguest, and the recipient
of the SIGTERM), fe will record a failure at which point xenops will clean up
the domain, despite it having actually been created/migrated successfully.

This could likely explain some spurious failures seen in high-load situation
but not reliably enough to investigate.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CA-119317: Move backend-kind to VDI.other_config

This way the SM driver can set this and special case where necessary for
certain SR types.

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
CA-119317: Consider VDI.sm_config:backend-kind

Allow a way of an SM driver to configure the VBD backend to be used for this
VDI. This is done by setting the backend-kind key in the sm_config field.

This value will be used but will still be overridden if a value appears in
other-config (user-configurable).

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
CA-133523 - Stop passing -priv to QEMU because QEMU trad 4.4 doesn't support it
Whitespace: Fix formatting in Xapi_vbd module.

The following produces the same before and after the commit.

    $ camlp4o -printer o -no_comments ocaml/xapi/xapi_vbd.ml | md5sum
    4d75d489ebdf8bb7b186baaba12a35bb  -

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
CA-133780: Set VBD backend-kind on VBD creation

Getting this informaton from the VDI record in the Xenopsd metadata translation
layer caused CD-eject to hang because ejection is done by setting the VDI ref
for the VBD to NULL.

Instead, the SM can still set the backend-kind sm-config key which will be
placed in other-config of the VBD at creation. It can still be overwritten by
the user.

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
Merge commit '1218949154ef27ad71e4e6a617287481a05a72e8'
Merge commit '1218949154ef27ad71e4e6a617287481a05a72e8'
Merge remote-tracking branch 'hg/master' into xs64bit-blktap3
Use default VBD backend for empty CD drives

Now that the VDI is queried for a VBD backend at VBD creation, we need to
handle the case when the VBD is created with VDI ref NULL. This will be the
case for creating an empty CD drive, for example, on VM.import.

Since the model is to not add anything to the other_config field for default
behaviour then now we widen the exception handling such that _any_ failure to
find a specified backend kind results in the default.

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
Merge commit '9edddce5194f70956ea978e11000d48806174f03'
CA-101571: Allow the vcpu params weight and cap value to be set independently
Signed-off-by: Ravi Pandey <ravi.pandey@citrix.com>