This article outlines Power ON/cloning/snapshot issues faced for VMs which are converted from other Hypervior's (Hyper-v, KVM and so on) format to ESXi compatible format and then uploaded to vSAN datastore.
The VM files available would be the .vmx and .vmdk files. This KB is for instances where there is not -flat.vmdk available after conversion of the VM format.
When trying to clone VM, create snapshot of the VM, it fails with error: "Some of the disks of the virtual machine WLHVMAPP04 failed to load. The information present for them in the virtual machine configuration may be incomplete".
If Physical disk placement for the VM is validated (vSphere Client > vSAN Cluster > Select VM > Monitor > vSAN - Physical disk placement), it can be seen that there are vSAN objects only for the VM folder and the VM swap:
VMware vSAN (All versions)
This issue occurs when the VMDKs are uploaded to the VM folder on the vSAN datastore using the datastore browser or WinSCP or other FTP tools.
vSAN does not support uploading of vmdk files directly to the vSAN datastore, as these files, by default are not in stream optimized format.
If the vmdk is not in a stream optimized format, vSAN does not understand it and thus does not create a backing vSAN object for it.
To resolve this issue:
Upload the vmdk file to VMFS or NFS datastore.
Run the command in an SSH of a host which has access to this datastore: vmkfstools -i vm_name.vmdk vm_name_clone.vmdk
Where "vm_name.vmdk" is the name of the vmdk file (data disk) in it's original format and "vm_name_clone.vmdk" is the name of the vmdk file in a format which is suitable for NFS or VMFS datastore.
This command would result in creation of two files:
"vm_name_clone.vmdk" --> Virtual disk descriptor file
"vm_name_clone-flat.vmdk" --> Virtual disk data file
Either create a new VM and attach the newly created disk (attach the descriptor file), or if the VM has been registered, remove the currently attached disk from the VM and attach the newly created disk.
Follow steps 1 to 3, if there are multiple disks for the VM.
Finally perform storage vMotion of the VM from VMFS/NFS to the vSAN datastore.
This will automatically convert the regular vmdks to a format recognizable by vSAN and thus also create backing object for the vmdk(s).
If migration is successful, only a ".vmdk" file would be present for each disk for the VM in the VM folder. The "-flat.vmdk" file won't be there anymore as the data would now be moved to the backing vSAN object(s).
If the ".vmdk" and "-flat.vmdk" files are copied directly to vSAN datastore instead of Storage vMotion, refer Flat VMDK on vSAN.