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:
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'