Highlighted
Contributor
Contributor

esxi 6.7 can't start vm after cancel snapshot

Jump to solution

Hi,

Recently (05 oct) i did snapshot my vm, after couple weeks I decided to take a second snapshot (17 nov), but while doing it, I read that it is better to delete snapshots and not keep more than 3. I canceled the second snapshot and decided to delete the first snapshot. When i removing it got stuck at 57% then i canceled this snapshot too. Then I look at snapshot manager and he wrote that there was no snapshots. Then (19 nov) I decided to make 1 more snapshot and if it is created, click "delete all snapshots". But the vm suddenly turned off and began to write:

VMware ESX cannot find the virtual disk "BG Server-000002.vmdk". Verify the path is valid and try again.
Datastore contains:

BG Server.vmdk

BG Server-000001.vmdk

BG Server-000002-sesparse.vmdk

-rw-------    1 root     root     96474755072 Nov 17 21:29 BG Server-000001-sesparse.vmdk
-rw-------    1 root     root           319 Oct  5 19:43 BG Server-000001.vmdk
-rw-------    1 root     root     40235954176 Nov 19 19:44 BG Server-000002-sesparse.vmdk
-rw-------    1 root     root     5368709120000 Nov 17 21:29 BG Server-flat.vmdk
-rw-------    1 root     root          8684 Nov 19 17:31 BG Server.nvram
-rw-------    1 root     root           448 Sep 14 09:34 BG Server.vmdk
-rw-r--r--    1 root     root            77 Nov 19 21:14 BG Server.vmsd
-rw-r--r--    1 root     root          3151 Nov 19 23:19 BG Server.vmx
-rw-------    1 root     root           154 Nov 17 22:45 BG Server.vmxf
-rw-r--r--    1 root     root        308514 Mar 13  2020 vmware-1.log
-rw-r--r--    1 root     root        271802 Mar 19  2020 vmware-2.log
-rw-r--r--    1 root     root        255948 Apr 23  2020 vmware-3.log
-rw-r--r--    1 root     root        502518 Aug 12 23:16 vmware-4.log
-rw-r--r--    1 root     root        342628 Nov 19 19:44 vmware-5.log
-rw-r--r--    1 root     root         62033 Nov 19 21:13 vmware-6.log
-rw-r--r--    1 root     root         62033 Nov 19 22:19 vmware.log
-rw-------    1 root     root      90177536 Jun 17 13:14 vmx-BG Server-1730266294-2.vswp

log file: https://pastebin.com/vcHL5yqi

vmx config: https://pastebin.com/F9CRgg3d

ESXi version: 6.7.0 ESXi build number: 14320388

Сan it be fixed or maybe at least come back on October 5th?

0 Kudos
1 Solution

Accepted Solutions
Highlighted
User Moderator
User Moderator

What should do the trick is to copy "BG Server-000001.vmdk" to "BG Server-000002.vmdk" and modify it. Do not copy&paste the contents from this forum. The LongContentID get created (somehow derived from the CID), and to be honest I don't know how exactly. Simply remove it from the recreated file.

~start of file~
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=12345678
parentCID=4d27ec2a
createType="seSparse"
parentFileNameHint="BG Server-000001.vmdk"
# Extent description
RW 10485760000 SESPARSE "BG Server-000002-sesparse.vmdk"

# The Disk Data Base
#DDB

ddb.grain = "8"
~end of file~

  • The CID can be a random 8 character code (0-9 and A-F).
  • The parentCID has to match the CID from the parent .vmdk file
  • The file names are basically self-explaining

André

View solution in original post

5 Replies
Highlighted
User Moderator
User Moderator

I can't tell you why the file is missing, but I think we can easily recreate it.
Please post the contents of the two remaining .vmdk descriptor files "BG Server.vmdk", and "BG Server-000001.vmdk". Depending on their content I can tell you how the missing file has to look like.

André

Highlighted
Contributor
Contributor

here

[root@localhost:/vmfs/volumes/5e43e6cd-15fef2e0-d9ac-f8f082351938/BG Server] cat "BG Server-000001.vmdk"
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=4d27ec2a
parentCID=98e04414
createType="seSparse"
parentFileNameHint="BG Server.vmdk"
# Extent description
RW 10485760000 SESPARSE "BG Server-000001-sesparse.vmdk"

# The Disk Data Base
#DDB

ddb.grain = "8"
ddb.longContentID = "9d34c6d90c67e496462e8f624d27ec2a"
[root@localhost:/vmfs/volumes/5e43e6cd-15fef2e0-d9ac-f8f082351938/BG Server] cat "BG Server.vmdk"
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=98e04414
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 10485760000 VMFS "BG Server-flat.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "ide"
ddb.geometry.cylinders = "16383"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.longContentID = "5be61e277ee369a1ca0417db98e04414"
ddb.uuid = "60 00 C2 95 25 a6 3c ba-d2 d6 6c ad 7b 1b 1d 8d"
ddb.virtualHWVersion = "14"

 

I think I suspect something:

4d27ec2a parentCID BG Server-000001.vmdk

b57a72ce CID for Server-000002.vmdk

longcontenid e10e64321da2bcddfc853f0

right?

0 Kudos
Highlighted
User Moderator
User Moderator

What should do the trick is to copy "BG Server-000001.vmdk" to "BG Server-000002.vmdk" and modify it. Do not copy&paste the contents from this forum. The LongContentID get created (somehow derived from the CID), and to be honest I don't know how exactly. Simply remove it from the recreated file.

~start of file~
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=12345678
parentCID=4d27ec2a
createType="seSparse"
parentFileNameHint="BG Server-000001.vmdk"
# Extent description
RW 10485760000 SESPARSE "BG Server-000002-sesparse.vmdk"

# The Disk Data Base
#DDB

ddb.grain = "8"
~end of file~

  • The CID can be a random 8 character code (0-9 and A-F).
  • The parentCID has to match the CID from the parent .vmdk file
  • The file names are basically self-explaining

André

View solution in original post

Highlighted
Contributor
Contributor

the vm started, fsck in progress, thanks. if you have paypal I will send you a couple of euros for a beer 🙂

ps. "manage snapshots" still doesn't see snapshots.

0 Kudos
Highlighted
User Moderator
User Moderator

Thank you for the offer. If you live in Munich, I may get back to it once the Beer Gardens open again 😉

Once a snapshot task fails, the snapshot description (stored in the .vmsd file) is usually wiped out. In order to get rid of the snapshots you will need to use the Consolidate option, or create a new snapshot, and run "Delete All" as you did before. That said, make sure that you do have sufficient free disk space on the datastore in case the base disk is thin provisioned. To find out about this, run ls -lisa, which will show the file's usage in kB in the second column. If the size differs from the provisioned size, the virtual disk is thin provisioned.

In doubt, post the output of ls -lisa, and the free disk space on the datastore (df -h) to find out how much additional disk space you may need.

André

0 Kudos