Move /xapi/* -> /xenops/* in XenStore

It's really xenops that's using these paths so it makes sense that these paths
be under that name.

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
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>
CA-119831 Apply GRO settings to bond and vlan interfaces
Ethtool settings (Generic Receive Offload etc.) need to be set on the
bond and VLAN devices where applicable.

Signed-off-by: Thomas Sanders <thomas.sanders@citrix.com>
TODO - find a less hacky way of doing this
CA-103062: Fix for preventing vm pause during SXM

assert_can_migrate needs to be grouped with migrate_send operation inside with_vm_operation so that while SXM is in operation, vm pause should not interfere after assert_can_migrate completes or in between

Signed-off-by: Ravi Pandey <ravi.pandey@citrix.com>
CA-112880: Fix race condition writing memory-actual

There was a race condition between the sender and receiver during migration.
This is due to the interplay with the monitor threads. Monitor_rrds.update_rrds
is run every 5 seconds and checks for changes. This module also has a cache of
values and only writes to the database if the cache is dirtied to avoid
excessive database writes. There is such a monitor thread running on each host.

The monitor thread on the sender may wake and write a value to the database
after the domain has been resumed on the receiver but before it is destroyed on
the sender. This could be a spuriously low value in the case where Xen is
reclaiming the memory on the sender side during the domain destroy.

The receiver however may have already updated its cache and written its value
to the database. It never writes on subsequent runs of the monitor thread since
it thinks the value that is in its cache (the correct value) is already in the
database (which it is not).

To remedy this we need to ensure that the monitor for a given host only updates
the VM_metrics in the database for VMs that are resident on that host. We also
provide a means to mark the cache as dirty when the migration has finished
since the receiver may have its cache updated before the resident_on field is
set.

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
Merge pull request #1543 from simonjbeaumont/ca-112880-trunk

CA-112880: Fix race condition writing memory-actual
CA-116281: restart syslog service instead of reload

rsyslog does not support reload, host-syslog-reconfigure
is not working at present.

Signed-off-by: Simon Rowe <simon.rowe@eu.citrix.com>
Merge pull request #1545 from srowe/master

CA-116281: restart syslog service instead of reload
Update to use new Tar, Tar_unix interface from ocaml-tar 0.2.1

The new ocaml-tar library separates the modules into:

   Tar: for pure OCaml definitions
   Tar_unix: for impure Unix I/O
   Tar_lwt: for impure Lwt I/O

So mostly we have to replace Tar. with Tar_unix. and adjust the
OCAMLPACKS.

Most of this code concerns VM import/export. There is an alternative
implementation which is much more efficient inside recent releases
of vhd-tool, so we should switch to that soon.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Merge pull request #1546 from djs55/ocaml-tar

Update to use new Tar, Tar_unix interface from ocaml-tar 0.2.1
Merge remote-tracking branch 'trunk/master'
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>
Merge pull request #1548 from simonjbeaumont/ca-120529-trunk

Fix race condition in X-host VDI copy
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>
HFX-990: Don't package sparse_dd in xapi-core RPM

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>

Conflicts:
	xapi.spec.in
HFX 990: Correct vhd-tool path for 6.0.2 backport

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
Merge pull request #1547 from djs55/upstream/VDI.copy-O_DIRECT

Use O_DIRECT for VDI.copy