xenlight: add support for .qcow2 via qdisk

If the VDI attach_info contains "format" information, we
select the QDISK libxl disk backend. This allows a storage
implementation to return "format": "qcow2".

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Update to 0.9.18; add ChangeLog entry.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Merge pull request #34 from djs55/add-qcow2

Add qcow2 file format support
Add missing file: bootloader.mli

From xen-api c/s f45d493e7ed9b5a60fed1db64ce52708c76465a6

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-100685: When domain disappears during VM shutdown operation, just go ahead instead of rasing any cancellation error

Import xen-api c/s 96cad346b8af1c98d253ee98e180fad4e5e98768

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Signed-off-by: Zheng Li <zheng.li@eu.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.

Signed-off-by: Miëtek Bak <mietek.bak@citrix.com>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-81449: Take VCPUs_at_startup into account when starting a guest.

Previously we were creating all the CPU devices as online.

n.b. adding the "online" option to Device.Vcpu.add means it's
functionally identical to Device.Vcpu.set

Signed-off-by: John Else <john.else@citrix.com>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CP-4145: Allow configuration of QEMU parallel port emulation

By default the toolstack does not instruct QEMU at all about parallel
port emulation. This causes QEMU to emulate a parallel port by default.
This commit allows for a "parallel" key to be specified in the platform
VM record parameter. The string used as this key will be passed to QEMU
as "-parallel <string>". For example, one can disable the parallel
port emulation completely by issuing:
xe vm-param-set uuid=<vm-uuid> platform:parallel=none

Signed-off-by: John Else <john.else@citrix.com>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CP-4147: Change the USB emulation platform flag semantics

Instead of having a single flag, "nousb", which turns off all USB
emulation, we now have two flags:

  - "usb", which controls USB emulation
  - "usb_tablet", which controls USB emulation, as long as USB emulation
    is turned on

xapi defaults to both keys being true, whereas xenopsd defaults to both
keys being false.

Signed-off-by: John Else <john.else@citrix.com>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-109035: Remove the correct xenstore key when PCI unplugging.

We were always attempting to remove dev-0 instead of dev-n. This
led to multiple attempts to e.g. deassign_device for all but the
first passed through device. It also led to a cancelled shutdown
attempting to unplug everything again without any exception handler,
leading to an infinite loop.

Signed-off-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com>
CA-105903: vbd-unplug --force works regardless of surprise-remove state

This is just acknowledging the changes that were introduced in Tampa, and not a
change in behaviour since Tampa.

Signed-off-by: Mike McClurg <mike.mcclurg@citrix.com>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Attempt to reset PCI device by writing to device reset file if present.

Signed-off-by: Siddharth Vinothkumar <siddharth.vinothkumar@citrix.com>
CA-105159: Wait for ack of shutdown request for HVM guests with PV drivers

The code paths only handled fully-PV guests and HVM guests without PV drivers.
In the case of PV drivers we did not wait for the shutdown request to be
acknowledged. This did not enable early exit if the request was not
acknowledged.

Signed-off-by: Si Beaumont <simon.beaumont@citrix.com>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-105002: Robustify against domains that are unkillable

Signed-off-by: Jon Ludlam <jonathan.ludlam@eu.citrix.com>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-92550: Update xenstore permissions on /vm/<uuid> tree to reflect the new domain ID when a domain is rebooted or migrated to localhost

Signed-off-by: Euan Harris <euan.harris@citrix.com>
Signed-off-by: David Scott <dave.scott@eu.citrix.com>
CA-113055: Take the right code path when domain is HVM.

Signed-off-by: Vincent Bernardoff <vincent.bernardoff@citrix.com>
Allow alternative implementations of the device-model and domain builder (aka xenguest)

To use an alternative device model, first put a new executable in

  /opt/xensource/alternatives/device-model/name

and then set VM.platform:device-model=name

To use an alternative xenguest, first put a new executable in

  /opt/xensource/alternatives/xenguest/name

and then set VM.platform:xenguest=name

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>
CA-85940: when "cancelling" a xenguest subprocess, raise the Cancelled exception

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Fix logic at the conclusion of Xenguest for domain creation and migration.

As part of the control protocol, Xenguest is expected to write the string

  "result: <xenstore mfn> <console mfn>\n"

to the a pipe back into xenops.  forkexecutioner has already executed a
waitpid() on the xenguest process, waiting for it to exit.

Unfortunately, as soon as xenops receives the result string, it decides to
SIGTERM the xenguest process.

This begins a race condition.  If xenguest finishes executing and exits
cleanly (which it will do, given the result string) in a timely fashion, fe
will record success and the domain creation/migration will be all good.

If however xenguest gets killed with the SIGTERM before it has exited cleanly
(such as actually having valgrind wrapped around xenguest, and the recipient
of the SIGTERM), fe will record a failure at which point xenops will clean up
the domain, despite it having actually been created/migrated successfully.

This could likely explain some spurious failures seen in high-load situation
but not reliably enough to investigate.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>