networkd: set the broadcast address when configuring an IPv4 address

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Allow CLI lookup of PBDs by SR.name_label and host.name_label

The equivalent is already implemented for the other connector types
(VIFs, VBDs and PIFs).

Signed-off-by: John Else <john.else@citrix.com>
CA-87757: Allow VM operator and above to set task.other_config:XenCenterMeddlingActionTitle

Signed-off-by: John Else <john.else@citrix.com>
CA-86764: Fully specify VDI map in VDI.pool_migrate

Signed-off-by: Mike McClurg <mike.mcclurg@citrix.com>
CA-86474: don't guess destination SR, and require full VDI map for migrate_send

Signed-off-by: Mike McClurg <mike.mcclurg@citrix.com>
Remove unneccessary check for xenopsd in migrate_send

Signed-off-by: Mike McClurg <mike.mcclurg@citrix.com>
CA-86568: Kill only the vncterm parent process

Do not kill the process group.

vncterm will now catch SIGTERM, pass it on to its child process,
wait for it to exit, clean up, and finally exit itself.
CA-86764: call migrate_send with VM lock in Message_forwarding.VDI.pool_migrate

Before this change, migrate_send operations for consecutive VDI.pool_migrate
operations on the same VM were being queued after VDI:SR maps had been
specified in the VDI.pool_migrate operation. So by the time the first
migrate_send operation completed and the second one began, the cached VDI:SR
maps were stale and pointing the wrong SRs. Because we wait to call
VDI.pool_migrate until we hold the VM lock, the VDI:SR map is created with the
correct VDIs and SRs.

This patch will build, but will unfortunately deadlock without the following
patch applied, since VDI.pool_migrate now tries to call VM.migrate_send with
the VM lock held, and this lock isn't reentrant.

Signed-off-by: Mike McClurg <mike.mcclurg@citrix.com>
CA-86764: Move Xapi_vdi.pool_migrate to Xapi_vm_migrate.vdi_pool_migrate.

To fix the deadlock mentioned in the previous commit, we needed to call
migrate_send directly, instead of going through the message forwarding layer.
This caused a mutually recursive module error, so we had to move
VDI.pool_migrate to Xapi_vm_migrate.

Note that we've moved the code which determines which host to run the local API
call on to *inside* the critical section, so that if the VM is moved by a
previous migration that we're waiting on, we don't try running this command on
the wrong host.

Signed-off-by: Mike McClurg <mike.mcclurg@citrix.com>
Add comment to xapi_vdi.ml explaining where pool_migrate was moved

Signed-off-by: Mike McClurg <mike.mcclurg@citrix.com>
Merge commit 'a1b7fc8996f70d5ef9c6c9ebaa18b6863454883c'
Merge commit '4853ef6bea940829488732c41f85e4bba06b505c'
Merge commit 'a3b9c610b4d649e3b86845452aea927d5de6efca'
CA-77238: Use "ip link set <device> [up|down]" to manage disabled VIFs.

This makes things more consistent between bridge and vswitch.

This patch also moves the usual "ip link set <device> up" from the VIF
udev script into setup-vif-rules - this fixes the bug where
setup-vif-rules would call "mod port down" on a disabled VIF, but the
udev script would then call "ip link set up", erroneously re-enabling
the VIF.

Signed-off-by: John Else <john.else@citrix.com>
CA-87277: Allow migration of a VM with one snapshot which has multiple VBDs.

Previously we were using the total number of VBDs connnected to all
snapshots to determine whether we could migrate a VM - now we just use
the number of snapshots.

Signed-off-by: John Else <john.else@citrix.com>
CA-88488: VM.reboot still exposed transient states where VBDs,VIFs were unplugged

A VBD or VIF is said to be 'active' while it is associated with a VM
even over a reboot. Unfortunately the record of which devices are 'active'
was stored in xenstore and deleted during the destroy phase of a reboot.

We now delay the deletion of the /vm/<uuid> tree until the VM metadata
is removed from xenopsd.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-88267: if a critical xenstore key is missing, the udev vif script will signal failure

Rather than ignoring keys (such as vm/uuid) which should always be
present, the udev script will log the problem and signal the error
directly to the toolstack by writing

  hotplug-error = some error string

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Merge pull request #820 from djs55/CA-88488
Re-add xapi API methods related to cooperativeness.

This is done in order to prevent breaking compatibility. The implementations
are dummy, and are marked as such. The API methods are marked as deprecated.

Signed-off-by: Rok Strniša <rok.strnisa@citrix.com>
CA-88361: Clear the appliance field when importing a VM.

Signed-off-by: John Else <john.else@citrix.com>