PowerOnVM_Task - The file specified is not a virtual disk - Power On virtual machine with multiple failure messages

[KatGL]

Try to power on a vm and I get the following error messages:

Failed to start the virtual machine

Cannot open the disk '/vmfs/volumes/54945749-.../ADMIN2vm.vmdk' or one of the snapshot disks it depends on

Failed to lock the file

Module DiskEarly power on failed

Cannot open the disk '/vmfs/volumes/54d56373-.../ADMIN2vm_vmdk' or one of the snapshot disk it depends o.

The file specified is not a virtual disk.

When the virtual server stared to fail, I though if I rebooted it I could get what I needed.  I know the reason it was failing ws because the CL drive was just about completely full.  I had configured it for 75 GB but I see the file size is 78 GB now. I also discovered that I could not log in to the vSphere Client for the esxi server with my AD account. I could log in usin gthe IP of the esxi server and root password.  I ended up rebooting the esxi server and then found out I could not start the vm server.  I could now log in to the esxi with my AD account though.

I had 2 hard drives, the OS - 2018R2 was the C: and it was on the datastore drive. the DL drive was on the storage drive. It had plenty of space left.

I tried mounting the 😧 drive to a new vm as a second drive but I got a similar message that it was not a vm drive. When I browsed to it's location  to add the second drive, even though it had the same vmdk extension, it would not see it.

Not sure how catastrophic the problem is, a little worried since I built another vm on the same esxi box. Box was new last summer and is running esxi 5.5 on sd card as a standalone.

Would be great if I can get both drives running but right now, I would be extremely appreciative to get the second drive open on either a new or different server.  I see that the data drive is 209 GB but was configured for 200 GB.  Both drives configured for Thin provisioning.

[continuum]

The reason for this message can be found in one out of three boxes:

1. syntax error in vmdk-descriptorfile
2. bad path, unexpected format,,size smaller than configured, , graintable-errors  - this affects flat,delta,redolog - vmdks
3. VMFS filesystem has bad references to the fragments of the vmdk, extents may be missing, heartbeat locks may be stale ...

Most times looking in box 1 is enough - all you need to do is to read the vmdk-descriptor by doubleclicking it in WinSCP.

Fix bad quotes, non-printable characters ,,, , check paths, check size in descriptor against size on disk
Do you still get the same eroor ?

[KatGL]

This is the ADMIN2vm.vmdk file:

# Disk DescriptorFile version=1 encoding="UTF-8" CID=d01497b8 parentCID=ffffffff isNativeSnapshot="no" createType="vmfs" # Extent description RW 157286400 VMFS "ADMIN2vm-flat.vmdk" # The Disk Data Base #DDB ddb.adapterType = "lsilogic" ddb.geometry.cylinders = "9790" ddb.geometry.heads = "255" ddb.geometry.sectors = "63" ddb.longContentID = "f051c0d13ea453e4344d420bd01497b8" ddb.thinProvisioned = "1" ddb.toolsVersion = "9344" ddb.uuid = "60 00 C2 95 0f 77 ac 2b-4b ee 52 af 1e 42 87 d5" ddb.virtualHWVersion = "8"

I don't see what you are describing

[continuum]

It is not possible to detect syntax errors when the file has been posted as text in this forum.
Use an attachement next time.
But it looks ok at first sight.
Is the path to the flat.vmdk valid ?
Whats the size of the flat.vmdk ?

[bharathl]

Try to recreate the .vmdk descriptor file with the exact size of the flat.vmdk file and attach the vmdk file to the VM again.

[KatGL]

I configured the original drive to be 75 GB, thin provisioned.  I see that the vmdk file is not 78 GB.  How can it get bigger than the actual drive (even if it is virtual)?

I'm now comparing the failed server with a new one. Both have the OS drive on the datastore drive and both have a data drive on the storage drive (of an ESXi server).  The broken server has the flat.vmdk file and the vmdk descriptor.  The new one, which is currently running, just has one vmdk file (vm_1.vmdk) which is the size of my hard drive, actually provisioned 9 GB more than the size I configured it for but is not "flat".  When I compare the folders for each server in the datastore, neither appear to have a descriptor file.  The broken server has an hlog file and the running server has 2 vswp files and a lck file.  Again I see that the provisioned size is larger than the configured size so I am less concerned about my question on the first line but still puzzled.

Does it only become "flat" when it is not running?

Now I'm comparing to another server "test" with both the OS drive and data drive on the Storage drive.  No flat drive (it is running) and no descriptor file.  I am assuming that the descriptor file is the second vmdk file that is less than 1 KB in size.

Everything I mentioned above is what I see in the datastore browser.  Now I'm even more puzzled.  So, how or why do I need to create a new descriptor file?  To clarify, I only have a vm_1.vmdk file of 0.51KB in the folder on the storage drive of the dead server.

Just another note: the "size" of my broken OS drive is showing as 78.5GB and "Provisioned size" is 78.6GB. 

[KatGL]

Question: does the vmdk file that is the hard drive for the vm become a ***-flat.vmdk when it is uploaded somewhere else, and a much smaller vmdk gets created as well?

If this is true, how could this happen if I didn't copy the drives anywhere, i.e. by data drive for teh dead server was created in place and was not downloaded from somewhere else.

[bharathl]

Normally the flat.vmdk file is not visible in the datastore browser. Only the .vmdk descriptor file is visible. When you copy the .vmdk file it copies the flat.vmdk file also along with it. You can use the following article to recreate the descriptor file and test it.

VMware KB: Recreating a missing virtual machine disk descriptor file

[continuum]

Hi
reading your last post was a shocking experience.
No offense intended - it is not your fault - you are another victim of a very user-hostile gang of UI-designers with a mean streak that made a super-stupid design decision years ago.
Probably you just started with vSphere and so you naturally assumed that looking into the VMs directory with something that seems to behave like a "file-browser", "filemanager"
would be a useful troubleshooting step.
Forget it - Datastorebrowser is useful to register a VM by rightclicking a vmx-file - but never use it for troubleshooting.

Please follow this little "thought-experiment":

Assume that you make a small textfile edit - something as simple as adding a space somewhere in line 5.
Now predict the changes in the display of the directory - to display use the standard GUItool that is also used in the documentation.
Select all items that apply:
- number of files in the directory has changed : the small textedit seems to add a new file ???

- number of files in the directory has changed : the small textedit seems to have deleted one file ???
- two files changed their icons - voddoo at work ???
- timestamp of the edited files has changed - now that makes sense
- size in bytes display has changed  - now that makes sense too

Datastorebrowser may most of the time display last 2 only - but then one day switch to the first 3 or any other combination

For troubleshooting you need a tool that enables you to understand how everything fits together.
Datastorebrowser  tries to confuse you by unexpected renaming actions, changing icons and other unexpected pranks.
The risk for panic-reactions and silly mistakes like "everything was fine when I had no flat.vmdk - now I have one and the VM is broken - lets delete it"

Do yourself a favour - start using WinSCP now.
You need to see 2 files even for the most basic checks - like "is the path to the flat.vmdk valid" or" is there a syntax error in the text-descriptor-file ?"

A virtual disk in Workstation-format would really appear as a single file - but this one vmdk - one file thing does not make anything easier - on the contrary.
Editing a 80Gb binary file in a texteditor is no fun at all.
Regard it as nice feature: ESXi uses one large binary file plus a small textfile. This makes editing it way easier.

Your error-message said: file is not a virtual disk.

This means:
reading the line in the textfile "my-vm.vmx"
scsi0:0.filename = "my-disk.vmdk"
was a success
finding "my-disk.vmdk" was a success
opening "my-disk.vmdk" for reading was a success
looking up the path for the associated binary file may have worked

Next step would be to open and load the binary-part - but for some reason something goes wrong at this point.

Your task now is to look for the most trivial reasons you can think about - maybe one quote is missing, maybe a path is incorrect ...

WinSCP  will safe you a lot of time - when you are inside your VMs directory you simply doubleclick the descriptor-vmdk to inspect it, if you inspect the value for size of file xy in the filemanager of WinSCP you can be sure that this tool will really display what there actually is.

Probably you still need help later - but then you can provide useful input so it also gets easier for us to help.

Ulli