CA-118027: Don't send RPC calls that are too large

The request size limit is known by xapi and so slaves shouldn't try and send
requests that it knows will be rejected.

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

Conflicts:
	ocaml/database/master_connection.ml

Resolved-by: Si Beaumont <simon.beaumont@citrix.com>
CA-118466: Prevent snapshot revert from deleting VM VDIs that were attached
after the snapshot was taken.
Signed-off-by: Siddharth Vinothkumar <siddharth.vinothkumar@citrix.com>
Merge pull request #1524 from siddharthv/CA-118466

CA-118466: Prevent snapshot revert from deleting VM VDIs that were attached after the snapshot was taken.
Merge pull request #1535 from johnelse/code-tidying

Dead code removal and typo fixes
Merge pull request #1531 from simonjbeaumont/ca-118027-trunk

Don't send RPC calls that are too large
TODO - find a less hacky way of doing this
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