Virtual Disk API Programming Guide - Documentation - VMware

Virtual Disk Programming Guide
To summarize: when creating a virtual machine in which to restore virtual disk:
Exclude default devices, and VirtualController.device, from the VirtualMachineConfigSpec.
Set the parent virtual disk backing information (VirtualDisk.FlatVer2BackingInfo) to null.
Convert HostCpuIdInfo array entries to ArrayUpdateSpec, insert ArrayUpdateOperation::add, and
copy the HostCpuIdInfo array from cpuFeatureMask into VirtualMachineConfigInfo.
Editing or Deleting a Device
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” on page 73. For example, see the
key and controllerKey for CDROM in the source code on page 75. The key uniquely identifies a device,
while the controllerKey uniquely identifies the controller where it is connected.
Restoring Virtual Disk Data
As in the section “Low Level Restore Procedures” on page 73, VixDiskLib functions provide interfaces for
writing the data to virtual disk, either locally or remotely.
Raw Device Mapping (RDM) Disks
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.
Restore of Incremental Backup Data
At some point you might need to restore a virtual disk from the backup data that you gathered as described
in “Changed Block Tracking on Virtual Disks” on page 70. The essential procedure is as follows:
1 Power off the virtual machine, if powered on.
2 Using VirtualMachineConfigInfo that corresponds to the last known good state of the guest operating
system, re‐create the virtual machine as described in “Using the VirtualMachineConfigInfo” on page 79.
3 Completely reload the base virtual disk using the full backup that started the most recent series of
incremental backups.
4 Create a snapshot. This is mandatory for SAN mode restore.
5 For SAN mode restore, disable changed block tracking. SAN writes are not possible with it enabled.
6 Sequentially restore the incremental backup data. You can do this either forwards or backwards. If you
work forwards, the restore might write some sectors more than once. If you work backwards, you must
keep track of which sectors were restored so as to avoid restoring them again from older data.
a From your backup records, get the change ID of the incremental backup to be restored. Your software
must also store the changed‐block information, so it knows which sectors of virtual disk to restore.
Once you start restoring virtual disk, the change tracking mechanism will misreport.
b Restore only changed areas to the virtual disks referred to by the snapshot. This ensures that you do
not write the data to the redo log created by the snapshot. When restoring a thin provisioned (sparse)
disk, use the star "*" change ID to avoid writing zeroes to the unallocated blocks.
c Repeat Step a and Step b as necessary by applying incremental backup data sets in order.
7 If applicable, revert to the base virtual disk, thus eliminating the snapshot.
80 VMware, Inc.