import_raw_vdi: use vhd-tool helper program

The vhd-tool helper is capable of O_DIRECT I/O and minimises
data copies.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
import_raw_vdi: log output from vhd-tool

This can be useful in diagnosing errors.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Revert to using Uuid instead of Uuidm

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
Don't package sparse_dd in xapi-core RPM

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Correct vhd-tool path for backport

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
VDI.copy: add extra arguments for deltas, and copying "into"

VDI.copy now takes arguments:
 vdi: the disk to copy
 base: if present, we will copy differences from here only
 SR: if no "into" VDI is provided, a fresh VDI will be created
     in this SR
 into: if present, the existing disk we will write the blocks into

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
xe vdi-copy: add new arguments base-vdi-uuid and into-vdi-uuid

We also make sr-uuid optional, since only one of sr-uuid and
into-vdi-uuid should be provided.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-120529: Wait for receiver in X-host VDI.copy

The sender was completing the VDI.copy operation after it had sent the last of
the data. This meant that any subsequent operations on the new VDI could fail
with VDI_IN_USE because the datapath on the receiver had yet to be destroyed.

Now we forward the task to the receiving host and wait for it to set it as
complete.

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
 CA-120529: Propagate VDI.copy receiver failures

If the receiver fails but the sender has already sent all its data then it
would have deemed the copy a success. This is dangerous since we can end up
with VDI corruption on the receiver and the impression that the copy was
successful.

Now we re-raise any errors encountered on the receiver back on the sender side
in the case of cross-host VDI.copy.

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
VDI.copy: add implementation for 'base' and 'into' arguments

If 'base' is provided then we will perform a delta-copy.
If 'into' is provided then we will copy into this existing VDI,
  otherwise we will create a fresh VDI in the SR given by 'sr'

However:
* if 'into' is read-only then we will fail with VDI_READONLY
* if 'into' is too small then we will fail with VDI_TOO_SMALL
* if 'base' is provided but the destination VDI (either 'into'
  or the fresh one we created in 'sr') does not support spareness
  then we fail with VDI_NOT_SPARSE

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
quicktest: add a test for new VDI.copy functionality

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Also don't package sparse_dd.conf in xapi-core RPM

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
CA-125060: add bash completion for '{base,into}-vdi-uuid' params of 'xe vdi-copy'

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Merge pull request #1601 from robhoes/clearwater-felton

CA-125060: add bash completion for '{base,into}-vdi-uuid' params of 'xe ...
CA-126652: sr-introduce CLI doesn't record sm-config param

This is not consistent with either sr-create CLI or sr-introduce API, which both take and record the sm-config param happily.

Signed-off-by: Zheng Li <zheng.li@eu.citrix.com>
Correct API versioning for the vdi.copy extension

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Bump API version to 2.2

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Merge pull request #1613 from robhoes/clearwater-felton

Clearwater felton
Merge pull request #1619 from zli/xenserver/clearwater-felton/CA-126652

CA-126652 for clearwater-felton
Merge pull request #1634 from xapi-project/clearwater-felton

Merge clearwater-felton into clearwater-sp1-lcm