Error: Can't open 'vmfs/volumes/<vm file path>.vmdk': Could not find the file" while powering on virtual machine

Products

VMware vCenter Server VMware vSphere ESXi

Issue/Introduction

Provide information to troubleshoot and fix virtual machines failing to power on with the error "Can't open 'vmfs/volumes/<vm file path>.vmdk': Could not find the file"

Symptoms:
Powering on a virtual machine (VM) fails with the message "Error: Can't open 'vmfs/volumes/<vm file path>.vmdk': Could not find the file".

Environment

VMware vCenter Server 8.0.x

VMware vCenter Server 7.0.x
VMware vCenter Server Appliance 6.7.x

VMware vSphere ESXi 8.x
VMware vSphere ESXi 7.0.0

VMware vSphere ESXi 6.7
VMware vCenter Server 6.7.x

Cause

Datastore errors
Datastore missing
VM descriptor file not updating for disk changes
Virtual disk descriptor file problem
Virtual disk file missing

Resolution

Note: For any listed commands below, the '#' represents the command line and does not need to be typed in.

If the virtual disk referenced in the error is a -ctk.vmdk, see “Could not open/create change tracking files” error when powering on VM.

Check if datastore is missing:

If the datastore is not found in the vCenter UI, look for datastore in the ESXi host client UI.
If the datastore is not found anywhere:
- Troubleshoot the missing datastore
- Restore or rebuild the VM

Check if the datastore is having Input/Output errors:

Connect to the ESXi host command line.
Find and navigate to the affected VM's configuration file path per Get virtual machine file path and virtual disk information through ESXi command line.
Run the command to touch and update the files:

# touch *

If the command fails with "I/O errors", either:

Troubleshoot the datastore I/O problem.

OR,

Restore or rebuild the VM to a healthier datastore

Check if virtual disk files are missing:

If the datastore is responsive, look for the virtual disk (*.vmdk) file listed in the error.

If you know of any attempts to rename the VM or its files, the VM may be looking for files under the wrong name. If so, follow Renaming a virtual machine and its files in VMware ESXi

To check and resolve any attempt VM file naming problems, follow Verifying ESX/ESXi virtual machine file names
Otherwise, find and navigate to the affected VM's configuration file path and obtain the current virtual disk list. Follow Get virtual machine file path and virtual disk information through ESXi command line
Look for the file in the error, which will be a "virtual disk characteristics file" (see VM file types in Virtual Machine Files).
- Normally-named .vmdk files are for the base virtual disk, versus a snapshot virtual disk
- If the missing .vmdk file has a name similar to <vm name>-0000<number>.vmdk then the issue is with a snapshot file(example: myvm-000003.vmdk):
If the characteristics file exists, list out the vmdk file:

# cat <vm characteristics filename>

Note the file name listed under # Extent description
1. For vSAN systems, this should appear as a vSAN object UUID. Example:
  - RW 2621440000 VMFS "vsan://12d8bf5a-411c-1016-034c-a0369fb102c0"
2. For SAN systems this should appear as a "<vm name>-flat.vmdk" filename.
Look for the data file
1. For base virtual disks on SAN systems, look for the *-flat.vmdk file in the VM's file directory
2. For snapshot virtual disks on SAN systems, this should appear as a "<vm name>-sesparse.vmdk" filename.
3. For older SAN systems, smaller snapshot files may appear as a "<vm name>-delta.vmdk" filename.
4. For vSAN systems, run this command to see the status of the data object:

# esxcli vsan debug debug object list --uuid=<UUID from the vmdk>

What to do if base virtual disk files are missing?

Restore the VM from backup or rebuild the VM.

What to do if snapshot virtual disk files are missing?

If VM had just finished consolidation, the VM configuration file (*.vmx) may not have updated to point to the base disk.
- Examine the vmware.log within the VM's file directory for entries showing that consolidation was successful.
- If you find the entries, you can verify further that the *.vmx file needs updating by looking for more entries to see if the files being consolidated were the ones shown in the UI error
- If you find all of these types of entries, you can be confident the VM needs to repoint to the base disk
You may have a VM for which snapshot files contain no significant data. You may decide that repointing the VM to the base disk and losing the snapshot data is preferable to restoring it from backup or rebuilding the VM. To repoint the VM to base disks, and the base disks exist:
1. Ensure that you have a good backup of the VM.
2. In the vCenter Server or ESXi host client, right-click the VM object and select Edit Settings...
3. Click the Virtual Hardware tab.
4. Delete the virtual disk object for the missing virtual disk.
5. Select Add New Device > Existing Hard Disk and browse to the base *.vmdk file.
6. Save the changes.

What to do if the virtual disks are actually still in the directory?

If you had changed an Independent-persistent disk to a Dependent disk mode with SVMotion see Change Disk Mode to Exclude Virtual Disks from Snapshots.

Otherwise, the virtual disk characteristics file could be corrupted. You can rebuild it by following;

For a base virtual disk for a VM on a SAN system, see Recreating a missing virtual machine disk descriptor file (.vmdk)
For a snapshot virtual disk for a VM on a SAN system, see Recreating a missing virtual disk (VMDK) descriptor file for delta disks

If rebuilding the virtual disk characteristics file fails to resolve the issue, it can be a problem with the VM descriptor file (*.vmx). If so:

Follow Rebuilding the virtual machine's .vmx file from vmware.log

OR,

Create a new VM, and attach the existing hard disks to it.

Additional Information

Failed to power on virtual machine

Impact/Risks:
Deleting the virtual disk data file cause permanent data loss for any data which has not yet been backed up.
Also, repointing the virtual disk descriptor file (*.vmx) to repoint to the base disk instead of the snapshot disk is not reversible and can lead to permanent data loss for data that has not yet been backed up.