1 Comment

A customer recently asked:

“Why should the option disk.enableUUID=true be set to false when a reboot is just pending, as stated in KB article: Backing up a Windows Server 2008 R2 virtual machine using vSphere Data Protection 5.1 fails with the error: Execution Error: E10055:Failed to attach disk (2035736).”


When this specific parameter (disk.enableUUID) is absent from the vmx, the effective setting is false. If the parameter is introduced into the vmx and set to true while the VM is still powered on, it will result in the following behavior:

  1. The guest OS (Windows) will never write the disk UUID/Serial to the VMX because the vmx has not been reloaded.
  2. The snapshotting process will see that the parameter is set to true and attempt to quiesce, but it will fail because no parameter exists (due to 1 above).

The correct resolution is to reboot the VM (so the vmx is reloaded) and the guest OS writes the Disk UUID/serial. Then the backup/snapshotting process will read this value and be able to successfully quiesce.

There is a non disruptive workaround, and that is to edit the vmx and set the disk.enableUUID value to false, then vMotion the vm (to any other host), to reload the vmx in host memory. This effectively disables application level quiescing (file system quiescing is still available though). This can be done in bulk via PowerCLI and non-disruptively (while the VMs are powered on).

There is also another method to reload the vmx file with the vm remaining powered on detailed in KB article: Reloading a vmx file without removing the virtual machine from inventory (1026043).

Also, see the “cause” and “resolution” sections of KB article: Taking a snapshot of a virtual machine after a Storage vMotion on an ESX/ESXi 4.1 or 5.0 host fails (2009065).