[sm] allow xapi to use SMAPIv2 services in domain 0

If the driver domain for an SR is dom0, then xapi first looks for
a registered SMAPIv1 plugin. If one isn't found then it attempts
to contact an SMAPIv2 service over a unix domain socket.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[SMAPIv2] add SR.create to the SMAPIv2

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[sm-cli] add "query" subcommand

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[SMAPIv2] make Query more regular: in a module with a "dbg" argument

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[sm-cli] add sr-create

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[SMAPIv2] improve the Unimplemented exception by adding a function name argument

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[sm-cli] add '-v' for verbose; sr-create and sr-attach

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[sm-cli] add sr-detach

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[SMAPIv2] enhance the exception Sr_not_attached by adding the SR

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[SMAPIv2] enhance the Sr_attached exception by adding the SR

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[SMAPIv2] enhance the Vdi_does_not_exist exception by adding the VDI

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[sm-cli] add vdi-{attach,activate,deactivate,detach}

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[smtest] allow the local SMAPIv2 Unix domain socket to be specified

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[SMAPIv2] use the feature flags from query in the allowed-operations

Whenever an SMAPIv2 backend is registered with storage_mux, the features
are queried and cached. On PBD.{plug,unplug} the SR's allowed_operations
are recomputed.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[SMAPIv2] if the storage service has failed, call SR.reset instead of failing to start

This will forget all SR state and set the PBD.currently_attached=false.

This isn't ideal as some VMs may still be running using resources from this SR.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[SMAPIv2] the VDI.allowed_operations should check the SMAPIv2 capabilities too

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[sm] register SMAPIv2 plugins in the SM table on PBD.plug

Unlike the SMAPIv1 plugins, the v2 ones may be hidden away in offline
driver domain VMs making them hard to query. Instead we re-query
their capabilities at PBD.plug time.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[sm] don't rely on the SM backend deleting the VDI record from the database

Only an SMAPIv1 plugin can do this, so we need to be able to delete these ourselves.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[sm] consider the lowercase version of the SM plugin's "driver" as the primary key

Note the SMAPIv1 backends require the SM.driver_filenane and SM.type fields.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
[SMAPIv2] add support for non-persistent disks

The SMAPI now has a "persistent" boolean in vdi_info and a function
  VDI.set_persistent

The non-persistent configuration for SMAPIv1 (explicit clone; destroy)
has been moved to the storage_access compat shim.

Two new SMAPI functions provide the backend opportunity to effect non-
persistence:

  VDI.epoch_begin: called when a disk is being dynamically added to a VM
                   in start, reboot or hotplug
  VDI.epoch_end:   called when a disk is being dynamically removed from a VM
                   in shutdown, during reboot or hotunplug

Note that neither of these functions are called over suspend/resume or migrate.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>