Undocumented Option Structures in the API

A lot of the time options structures are provided to provide future proofing and in fact there are no exposed options available to a user, and even when they are the defaults are usually the optimal set.

To work round the documentation limitations you can resort to reading the underlying source code:
https://github.com/xen-org/xen-api/tree/master/ocaml/xapi

For example in https://github.com/xen-org/xen-api/blob/master/ocaml/xapi/xapi_host.ml
you can identify migrate_receive doesn't use the options dictionary

In https://github.com/xen-org/xen-api/blob/master/ocaml/xapi/xapi_vm_migrate.ml you can with some effort work out that the only option available is an option "force" which can be true or false. These are passed as dictionaries so it would be force="true"

If you can work out the xe equivalent the tab completion available will let you know what options can be set:


root@dt56 ~# xe vm-migrate // double tab here to see....
destination-sr-uuid= live= remote-username=
force= remote-master= vdi:
host= remote-network= vif:
host-uuid= remote-password= vm=
root@dt56 ~# xe vm-migrate force= // leave it empty and tells you the options
Error: Failed to parse parameter 'force': expecting 'true' or 'false'

 

About XenServer

XenServer is the leading open source virtualization platform, powered by the Xen Project hypervisor and the XAPI toolstack. It is used in the world's largest clouds and enterprises.
 
Commercial support for XenServer is available from Citrix.