With SAN transport mode, you must create a snapshot of the virtual machine before virtual disk restore. See Creating a Snapshot. If at restore time the virtual machine had a pre-existing snapshot, you must delete it, otherwise SAN mode restore will fail. For other transport modes, the restore snapshot is optional.
With a VVol datastore, the restore snapshot is forbidden when restoring to the parent (backing disk). A null MoRef is allowed in vSphere 6.0 to minimize code changes when applications restore to a VVol datastore.
To get the unique ID of a VVol object in the MOB (managed object browser) click VirtualMachine > Config > Hardware > Device (VirtualDisk) > Backing.
This section shows how to create a VirtualMachine object, which is complicated but necessary so you can restore data into it. Before creating this object, you must create a VirtualMachineConfigSpec describing the virtual machine and all of its supporting virtual devices. Almost all the required information is available from the virtual machine property
config.hardware.device, which is a table containing the device configuration information. The relationships between devices are described by the value
key, which is a unique identifier for the device. In turn, each device has a
controllerKey, which is the key identifier of the controller where the device is connected. Use negative integers as temporary key values in the
VirtualMachineConfigSpec to guarantee that temporary key numbers do not conflict with real key numbers when they are assigned by the server. When associating virtual devices with default devices, the
controllerKey property should be reset with the key property of the controller. Below are the settings for a sample
VirtualMachineConfigSpec used to create a virtual machine.
A backup application can also use information contained in a VirtualMachineConfigInfo. If at backup time you preserve all the
VirtualMachineConfigInfo details that describe the virtual machine, you can transfer much of this information into a
VirtualMachineConfigSpec to create a virtual machine at restore time. However, some of the information in
VirtualMachineConfigInfo is not needed, and if used in the
Spec, virtual machine creation can fail. For example, a
VirtualMachineConfigSpec that contains information about so called “Default Devices” usually fails. The list of default devices includes:
Some information about devices is unneeded and can cause problems if supplied. Each controller device has its vim.vm.device.VirtualController.device field, which is an array of devices that report to the controller. The server rebuilds this list when a virtual machine is created, using the (negative) device key numbers supplied as a guide. The relationship between controller and device must be preserved using negative key numbers in the same relationship as in the hardware array of
VirtualMachineConfigInfo.
One other configuration needs substitution. VirtualMachineConfigInfo contains the
cpuFeatureMask, field, which is an array of
HostCpuIdInfo. The array entries must be converted to
ArrayUpdateSpec entries containing the
VirtualMachineCpuIdInfoSpec along with the “operation” field, which must contain the value
ArrayUpdateOperation::add. The
VirtualMachineCpuIdInfoSpec also contains a
HostCpuIdInfo array that you can copy from the
cpuFeatureMask array in
VirtualMachineConfigInfo. These items are not reflected in the sample code. Everything else can be copied intact from
VirtualMachineConfigInfo data.
If backup clients want to edit or delete a device, they must use the server-provided key when referring to an existing device. For the definition of key, see
Creating a Virtual Machine. For example, see the
key and
controllerKey for CDROM in the source code on
// key number of CDROM. The
key uniquely identifies a device, while the
controllerKey uniquely identifies the controller where it is connected.
As in the section Low Level Restore Procedures,
VixDiskLib functions provide interfaces for writing the data to virtual disk, either locally or remotely.
To create an RDM disk using CreateVM_Task, use a LUN that is not occupied and thus is still available. Developers sometimes use the same LUN
uuid that is available in the
configInfo object, which can cause errors because the LUN
uuid is datastore specific.
Call QueryConfigTarget to fetch the
ConfigTarget.ScsiDisk.Disk.CanonicalName property, set in
VirtualDiskRawDiskMappingVer1BackInfo.deviceName. Also call
QueryConfigTarget to fetch
ConfigTarget.ScsiDisk.Disk.uuid, set in
VirtualDiskRawDiskMappingVer1BackInfo.lunUuid. When creating the virtual machine, avoid host-specific properties of
configInfo, which should be set according to host configuration where the virtual machine is restored.