Remove redundant assertion in VM.pool_migrate: assert_can_see_SRs

This function was called both in Message_forwarding and in assert_can_boot_here.

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Reorganise Xapi_vm_helpers.assert_can_boot_here

This does not change any functions, but hopefully makes it easier
to see what is being asserted, and how.

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Use set_difference from Listext in Xapi_vm_helpers

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Remove redundant assertion in Xapi_vm_migrate.migrate_send

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Fix #snapshot assertion in for storage migrate

The restriction of not allowing more than one snapshot for storage
migration applies to both intra and cross pool migration. The assert
function did not reflect that. Also, the assertion was in two places.

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
In VM.migrate_send, perform assert_can_migrate on the master

For efficieny reasons, do the asserts on the master, before forwarding
the actual VM.migrate_send call to the host that has the VM running on
it (which may be a slave).

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Cpuid_helpers.assert_vm_is_compatible must pass for halted VMs

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
Use optional parameter in assert_can_boot_here rather than separate functions

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
CA-86959: Call assert_can_boot_here in assert_can_migrate for in-pool migrate

This ensures that the same checks/assertions are done for intra-pool
storage migrations as for (old-style) VM migrations, with the exception
of the SR visibility check.

Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
CA-87324: a non-existent xenstore device doesn't require any maintenance action

So 'device_action_request' should return None rather than throwing an exception.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-87324: return whether a VM is running HVM in VM.stat

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-87324: simulate VBD eject/insert as plug/unplug in xapi rather than xenopsd

Simulating this in xenopsd leads to states where a VDI has been
ejected but the device is still 'active' and therefore 'currently_attached=true'
Although this is self-consistent, it confuses xapi and the regression
tests using the XenAPI. Instead we fall back to transforming eject into
unplug and insert into plug at the XenAPI level.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Merge pull request #794 from djs55/CA-87324

CA-87324: fix PV cdrom "insert" and "eject"
CA-87324: when starting a PV VM, don't "plug" empty VBDs

We respect the convention that empty VBDs are currently_attached = false
for PV guests.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Merge commit '7dcf7d8ab0bfefaa665ddfb7185ec7731d3c5518'
CA-87492: Add migrate_send to need_pv_drivers_check

We didn't check for PV drivers for HVM guests, so we could migrate_send a guest
when we wouldn't have been able to pool_migrate it. We now do the same
allowed-operations checks for both migrate_send and pool_migrate.

Signed-off-by: Mike McClurg <mike.mcclurg@citrix.com>
CA-87459: if an event from xapi is received for a VM which has been destroyed, skip and don't pause for 15s

It's possible to have a VM be shutdown and uninstalled before all
events have been processed. If this happens then we log the
event and avoid calling "Thread.delay 15."

When a VM is actually shutdown, we trigger a xapi event re-registration
since we don't need to receive events on it any more.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Merge commit 'c8b745d8a0b3d818001581f18267ee0282ce7ebc'
Merge commit '8ab1041eaf35e45523787e637cc0771d3abacceb'
Merge commit '4e4c34c63474ecf00ee806b4c3d93e51345d300f'