Virtual Machine Checkpoint fails with Access Denied when running on a Clustered Shared Volume

When you attempt to create a CheckPoint of a virtual machine that is running on a Cluster Shared Volume (CSV) , you may receive a General access denied error as shown below.

clip_image001

You will receive this error if the virtual machine’s VHD is placed on the root of the drive.

clip_image002

clip_image003

The reason for the access denied error is due to the VM worker process (VMMS) not having relevant permissions on the CSV volume.  Below are default permission that is present for a typical CSV volume.  It is strongly recommended that these permissions not be changed.

clip_image005

To resolve the issue, migrate the storage from Failover Cluster Manager or reconfigure the VM and place the VHDX in a folder off the root.  By moving the VHDx to a subfolder or if the VM is reconfigured, the VMMS service updates the permissions on the subfolder as it should.

For example, this is the current location of the file: 

C:\ClusterStorage\Volume1\Test Lab.Vhdx

You would want to move it (and any other VHDX files present) to a subfolder you can create, such as this: 

C:\ClusterStorage\Volume1\Test Lab\Test Lab.Vhdx

There are several options you can run through to accomplish this task.

Option 1:

Using the Virtual Machine Storageselection from Failover Cluster Manager, move it to the folder you created.  This is an option that can be done without affecting production as it can be done while the virtual machine is online and running.

clip_image007

clip_image008

Option 2:  

Shut the virtual machine down and, in Explorer, move the VHDx from the root of CSV to a folder you create.  In Failover Cluster Manager, bring up the settings of the virtual machine and manually change the path of the relocated VHDx.  This is an option that can be done but will affect production as it cannot be done while the virtual machine is online and running.  So you would need to schedule downtime to accomplish this task.

General Rule:

Microsoft has always not recommended to keep any type of data files in the root of a drive.  Even though things may appear to work fine, problems could arise from this configuration.

Shasank Prasad
Senior Support Escalation Engineer
Microsoft Corporation