"Cannot open the disk '..' or one of the snapshot disks it depends on. 22 (Invalid argument)." - But no Lock-files!

[NullDevice23]

Hello!

After quite a long uptime an ESXi 6.0 Host froze, possibly because of a hardware issue / overheat, or maybe a powersupply problem.

However, i rebooted an VMs came up again. - Except one.

It always always says:

Cannot open the disk '/vmfs/volumes/56072c60-522f7803-c17d-6805ca3baf74/jupiter/jupiter.vmdk' or one of the snapshot disks it depends on.

22 (Invalid argument)

I read a lot of articles and discussions, who had similar issues, but not the same:

Because they had .lck files that they could delete.

In my case i don't have any .lck files in the VM directory, or in other datastores where the VM has vDisks.

The vDisk is quite big, its 6 TB.  The VM was the fileserver, and this vdisk was the data-partition.

I detached the vdisk from the VM, and attached it to another one.

But that did not work either, so i attached it back to the original one.

vmkfs tools says there are no errors:

[root@helios:/vmfs/volumes/56072c60-522f7803-c17d-6805ca3baf74/jupiter] ls -alh

total 6442451976

drwxr-xr-x    1 root     root         560 May  7 13:12 .

drwxr-xr-t    1 root     root        1.6K Sep 27  2015 ..

-rw-------    1 root     root        6.0T Jul  8 11:34 jupiter-flat.vmdk

-rw-------    1 root     root         501 May  7 13:12 jupiter.vmdk

[root@helios:/vmfs/volumes/56072c60-522f7803-c17d-6805ca3baf74/jupiter]

[root@helios:/vmfs/volumes/56072c60-522f7803-c17d-6805ca3baf74/jupiter] vmkfstools --fix check jupiter.vmdk

Disk is error free

[root@helios:/vmfs/volumes/56072c60-522f7803-c17d-6805ca3baf74/jupiter]

I decided to upgrade to the latest ESXi version, which is 6.5.

But the issue still remains.

In the web client, the error looks a bit different.  It says:

Power On VM

Key

haTask-16-vim.VirtualMachine.powerOn-142162972

Description

Power On this virtual machine

Virtual machine

jupiter 

State

Failed - File system specific implementation of OpenFile[file] failed

  Errors 

• File system specific implementation of OpenFile[file] failed
• File system specific implementation of LookupAndOpen[file] failed
• File system specific implementation of LookupAndOpen[file] failed
• File system specific implementation of LookupAndOpen[file] failed
• 22 (Invalid argument)
• Cannot open the disk '/vmfs/volumes/56072c60-522f7803-c17d-6805ca3baf74/jupiter/jupiter.vmdk' or one of the snapshot disks it depends on.
• Module 'Disk' power on failed.
• Failed to start the virtual machine.

Im already becoming kind of frustrated with this issue after those few days now.

Is there anything else i can do?

This is a site with a very small count of users and VMs.  They have only the free verison of ESXi.     Means no vmware support in this case.

Thankful for any hint..

Regards, ND.

[mhampto]

Hello,

Depending on the storage, there may not be a lock file.  This KB has more information on looking for locks:Investigating virtual machine file locks on ESXi (10051) | VMware KB

The vmkfstools -D command is the most useful for determining the source MAC address.

Let me know if this helps.

[ocarl]

This helped me alot.

https://jc-lan.tk/2017/02/01/esxi-6-5-host-crash-then-guest-fails-to-power-on/

1	vmkfstools -x check /path/to/vmname.vmdk

1	vmkfstools -x repair/path/to/vmname.vmdk

perform the commands on the primary (pointer) vmdk (not vmname-s###.vmdk).

[Finikiez]

Can you show 'vmkfstools -D' on this files and 'touch *' from the folder?

Also what do you see in vmkernel.log and vmware.log when you try to power on VM?

[Wonlliv]

Hi there,

I would try a few more steps.

- Un-regeister and re-register the VM at the host

- Restart management services

- Restart the host

- Attach an USB disk as temporary datastore and move the VM to this datastore

I had a very similar situation, where the lock was bind to the MAC VMware Knowledge Base

Best regards

[wowitsdave]

Wonlliv​ I know this is an old post but thanks, I had a similar issue where I could not start the VM and Unregister/Register did the trick. Thanks!