178
If the metadata parameter is true, then the disks are not exported, and only the VM metadata is written to
the output file. This is intended to be used when the underlying storage is transferred through other mechanisms,
and permits the VM information to be recreated (see the section called “vm-import”).
The VM or VMs on which this operation should be performed are selected using the standard selection
mechanism (see VM selectors). Optional arguments can be any number of the VM parameters listed at the
beginning of this section.
vm-import
vm-import filename=<export_filename>
[metadata=<true | false>]
[preserve=<true | false>]
[sr-uuid=<destination_sr_uuid>]
Import a VM from a previously-exported file. If preserve is set to true, the MAC address of the original VM
will be preserved. The sr-uuid determines the destination SR to import the VM into, and is the default SR if
not specified.
The filename parameter can also point to an XVA-format VM, which is the legacy export format from XenServer
3.2 and is used by some third-party vendors to provide virtual appliances. This format uses a directory to store the
VM data, so set filename to the root directory of the XVA export and not an actual file. Subsequent exports of
the imported legacy guest will automatically be upgraded to the new filename-based format, which stores much
more data about the configuration of the VM.
Note:
The older directory-based XVA format does not fully preserve all the VM attributes. In
particular, imported VMs will not have any virtual network interfaces attached by default. If
networking is required, create one using vif-create and vif-plug.
If the metadata is true, then a previously exported set of metadata can be imported without their associated
disk blocks. Metadata-only import will fail if any VDIs cannot be found (named by SR and VDI.location) unless
the --force option is specified, in which case the import will proceed regardless. If disks can be mirrored or
moved out-of-band then metadata import/export represents a fast way of moving VMs between disjoint pools
(e.g. as part of a disaster recovery plan).
Note:
Multiple VM imports will be performed faster in serial that in parallel.
vm-install
vm-install new-name-label=<name>
[ template-uuid=<uuid_of_desired_template> | [template=<uuid_or_name_of_desired_template>]]
[ sr-uuid=<sr_uuid> | sr-name-label=<name_of_sr> ]
[ copy-bios-strings-from=<uuid of host> ]
Install or clone a VM from a template. Specify the template name using either the template-uuid or
template argument. Specify an SR using either the sr-uuid or sr-name-label argument. Specify to
install BIOS-locked media using the copy-bios-strings-from argument.
Note:
When installing from a template that has existing disks, by default, new disks will be created
in the same SR as these existing disks. Where the SR supports it, these will be fast copies. If
a different SR is specified on the command line, the new disks will be created there. In this
case a fast copy is not possible and the disks will be full copies.
When installing from a template that does not have existing disks, any new disks will be
created in the SR specified, or the pool default SR if not specified.