VMware vSphere SDKs and Tools 8.0

8.0 7.0 6.7 6.5

Working with Microsoft Shadow Copy

Microsoft Shadow Copy, also called Volume Snapshot Service (VSS), is a Windows Server data backup feature for creating consistent point-in-time copies of data (called shadow copies).
The type of quiescing used varies depending on the operating system of the backed-up virtual machine, as shown in Table 1. ESXi 4.1 added support for Windows 2008 guests using application level quiescing.
Driver Type and Quiescing Mechanisms Used According to Guest Operating Systems
Guest Operating System
Driver Type Used
Quiescing Type Used
Windows XP 32-bit
Windows 2000 32-bit
Sync Driver
File-system consistent quiescing.
Windows Vista 32- or 64-bit
Windows 7 32- or 64-bit
VMware VSS component
File-system consistent quiescing.
Windows 2003 32- or 64-bit
VMware VSS component
Application-consistent quiescing.
Windows 2008 32- or 64-bit
Windows Server 2008 R2
VMware VSS component
Application-consistent quiescing. For this to be available, several conditions must be met:
  • Virtual machine must be running on ESXi 4.1 or later.
  • The UUID attribute must be enabled. It is enabled by default for virtual machines created on 4.1 or later. For details see Enable Virtual Machine Application Consistent Quiescing.
  • The virtual machine must use SCSI disks only and have as many free SCSI slots as the number of disks. Application-consistent quiescing is not supported for virtual machines with IDE disks.
  • The Windows VM must not use dynamic disks. If the VM has dynamic disks, the snapshot will be file-system consistent.
Windows Server 2012
VMware VSS component
Same as for Windows 2008.
Windows Server 2016
VMware VSS component
Same as for Windows 2008.
VMware Tools 10.1.0 or later is required for quiescing support.
Application quiesced snapshots are not supported for encrypted VMs, nor for virtual disks managed by Storage Spaces. Use file-system quiescing instead.
Windows Server 2019
VMware VSS component
Same as for Windows 2016.
Windows Server 2022
VMware VSS component
Same as for Windows 2016.
Other guest operating system
Not applicable
Crash-consistent quiescing.
File-system consistent quiescing prevents file systems from becoming corrupted, for example, journaled file systems are allowed to write out pending transactions. Crash-consistent quiescing is the ability to restore an application as if it suddenly crashed and lost all stateful information. This involves minimal effort because only data already written to disk is guaranteed safe. Application-consistent quiescing is the ability to restore stateful information as well.
Restore must be done using the backup application’s guest agent. The vSphere APIs for Data Protection provide no host agent support for this. Applications authenticating with SSPI might not work right because HTTP access will demand a user name and password, unless the session was recently authenticated.
When performing VSS quiescing while creating the snapshot of a Windows virtual machine, VMware Tools generate a
vss-manifest.zip
 file containing the backup components document (BCD) and writer manifests. The host agent stores this manifest file in the
snapshotDir
 of the virtual machine. Backup applications should get the
vss-manifest.zip
 file so they can save it to backup media. There are several ways to get this file:
  • Using the datastore access HTTPS protocol, for example by browsing to https://<server-or-host>/folder/ and continuing downward to the snapshot directory until you find the
    vss-manifest.zip
     file.
  • By calling the
    CopyDatastoreFile_Task
     method in the vSphere API. This method accepts the URL formulated above for HTTPS, or a datastore path. (
    CopyVirtualDisk_Task
     is for VMDK files).
  • With the
    vifs
     command in the vMA or vCLI.
  • With the
    Copy-DatastoreItem
     cmdlet in the PowerCLI (requires PowerShell and VMware snap-in).
Windows 2008 application level quiescing is performed using a hardware snapshot provider. After quiescing the virtual machine, the hardware snapshot provider creates two redo logs per disk: one for the live virtual machine writes and another for the VSS and writers in the guest to modify the disks after the snapshot operation as part of the quiescing operations.
The snapshot configuration information reports this second redo log as part of the snapshot. This redo log represented the quiesced state of all the applications in the guest. This redo log must be opened for backup with VDDK 1.2 or later. The older VDDK 1.1 software cannot open the second redo log for backup.
Application consistent quiescing of Windows 2008 virtual machines is only available when those virtual machines are created in vSphere 4.1 or later. Virtual machines created in vSphere 4.0 can be updated to enable application consistent quiescing by modifying a virtual machine’s enableUUID attribute.
For information about VSS, see the Microsoft TechNet article,
How Volume Shadow Copy Service Works
. For information about Security Support Provider Interface (SSPI), see the MSDN Web site.

Content feedback and comments