VM does not start after copying to an disk and copying to a new server.

[Tom0101]

After all VMs with snapshots were copied from the old system to a hard disk, the hard disk was plugged into the new ESXi host and successfully recognized. Afterwards the hard disk was mounted as datastore and the data of the VMs were accessible. The VM folders have been copied to a RAID in the new server. Next I added the VMs to the inventory.

Unfortunately I can't start the VMs after copying. I get the following error when starting:

Failed to power on virtual machine NAME_OF_MY_VM. Unable to enumerate all disks. Click here for more details.

If I let more information be output, I get this displayed this:

Power On VM

Key:

haTask-9-vim.VirtualMachine.powerOn-1219

Description:

Power On this virtual machine Virtual machine NAME_OF_MY_VM State Failed - Unable to enumerate all disks.

Errors:

Unable to enumerate all disks.

The specified feature is not supported by this version

The old server runs esxi 5.0 and the new 6.7.

[daphnissov]

Attach your VMX file so we can inspect it.

[SupreetK]

Was the VM (or any of it's disks) were running on snapshot on the older environment?

Cheers,

Supreet

[Tom0101]

No, the VMs were not recovered or executed by a snapshot

[Tom0101]

My VMX file.

[diegodco31]

Hi

Try copy the VMs without the snapshot.

[Tom0101]

I've deleted the respective files from the VM directory. Unfortunately, that didn't work.

[continuum]

You will need:

scsi0:0.fileName = "NAME_OF_MY_VM_v2-000001.vmdk"

scsi0:1.fileName = "Win7 Pro, 64bit, Office 2013, Vo_2-000001.vmdk"
and most likely

scsi0:0.fileName = "NAME_OF_MY_VM_v2.vmdk"

scsi0:1.fileName = "Win7 Pro, 64bit, Office 2013, Vo_2.vmdk"
to recover the latest state.

If you can live with the data-loss you can discard the latest data inside the snapshots and use the VM with only>

scsi0:0.fileName = "NAME_OF_MY_VM_v2.vmdk"

scsi0:1.fileName = "Win7 Pro, 64bit, Office 2013, Vo_2.vmdk"

[SupreetK]

As we can see from the below entries in your vmx file, the VM was (and is) running on snapshot disks. The way 6.7 handles snapshot disks is different than how 5.1 used to treat it. Therefore, it is highly unlikely that you will be able to power on these VMs on 6.7 environment.

scsi0:0.fileName = "NAME_OF_MY_VM_v2-000001.vmdk"

scsi0:1.fileName = "Win7 Pro, 64bit, Office 2013, Vo_2-000001.vmdk"

Per my understanding, you have two options -

1) Consolidate the VM on a 5.1 host.

2) Exclude the snapshot disks from the chain and make the VM boot from the base disks. Needless to say, you will lose the data from the delta files.

Please consider marking this answer as "correct" or "helpful" if you think your questions have been answered.

Cheers,

Supreet

[continuum]

> The way 6.7 handles snapshot disks is different than how 5.1 used to treat it. Therefore, it is highly unlikely that you will be able to power on these VMs on 6.7 environment.
Sorry - but  this is neither helpful nor correct.
It makes no sense at all to try a consolidation on a 5.1 host.
That will not magically restore the missing files.

[a_p_]

I can't reproduce this at the moment, so this is more of a guess:

How exactly did you copy the virtual machine's files to the target datatore on the new server?

In case the target datastore is VMFS6 formatted, the issue may be caused by the snapshots' file format. VMFS6 supports the SEsparse format for snapshots, and your files are most likely VMFSsparse (delta) files.

Do you have a VMFS5 datastore to which you can copy the VM's folder/files to see whether this works?

André

[SupreetK]

This explanation was made on the assumption that he might have had a VMFS-3 datastore on the ESXi 5.1 host and the current one being VMFS-6, the delta files will not be in a supported format. However if the delta files are completing missing, you are absolutely right in saying that it will not restore the files even on the 5.1 host (or a VMFS-3 datastore).

Cheers,

Supreet

[Tom0101]

After I have edited the.vmx file, I can start the VMs. Unfortunately I have to restore the snapshots to the latest state. This does not work because there is probably an incompatibility as described by a.p. and SupreetK. My idea would be to clone (copy) the VM from inside on the old host with Acronis True Image 2018 or Clonezilla and then restore it to the new system. To my knowledge, you can create a completely new VMware VM and work around all incompatibilities.