VMware Communities
benfeisers
Contributor
Contributor

Couldn't open VM, VMX file is corrupt

Could not open virtual machine: X:\Virtual Machines\Windows 7 x64\Windows 7 x64.vmx

VMX file is corrupt.

This is the error message I receive whenever I try to turn on my VM after a computer crash. I've tried looking at the logs but wasn't able to detect anything, I would greatly appreciate it if anyone with better knowledge will take a look at the attached logs on this post.

So far I've tried:
Assigning a new VM to the VMDK files, but it looks like it goes only back to February of this year which isn't very helpful as it is a big data loss.

Googling, couldn't find anyone with a similar issue to mine, just config issues and nothing else...

9 Replies
continuum
Immortal
Immortal

Try the attached vmx-file


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
benfeisers
Contributor
Contributor

Sorry to be a burden, but now this error pops up:

The parent virtual disk has been modified since the child was created. The content ID of the parent virtual disk does not match the corresponding parent content ID in the child

Cannot open the disk 'P:\Virtual Machines\Windows 7 x64\Windows 7 x64-000001.vmdk' or one of the snapshot disks it depends on.

Module DiskEarly power on failed.

Failed to start the virtual machine.

Attached log.

Reply
0 Kudos
continuum
Immortal
Immortal

Hi Ben
obvoiusly you already created a test-VM that was configured to bypass the snapshot you have.
I hope that you did not run that VM too long or allowed  it to run a checkdisk or any made any other larger edits.Workstation assumes you already damaged the filesystem inside the guest  - thats why you receive the "parent has been changed" message.
To force the VM to start agaon you need to edit the embedded descroptorfile of the parent vmdk !!!

Do not try to do this with a hexeditor - instead use the approach that I described here:
Read
VMDK-Handbook-Basics
to understand how to edit a large binary vmdk-file.
Here is an example case:
VM-sickbay

Normally you must extract all embedded descriptors  ( to understand where exactly the CID-chain was interrupted)- and typically you just edit and reinject only one descriptor.
Please keep us updated about your results - or ask if a step is unclear

Ulli


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
coloradosky
Contributor
Contributor

This matches what I am seeing as well!

My workstation crashed and now I have multiple VM's that will not start. I click on the .vmx file and it gives me a blank screen.  I checked the most recent log for one of the vm's and it is garbage.  I suspect the others are as well.

How do I restore the vmx file to get these running again?

Log for Centos 7 vm is attached.

thanks,

jerry

Reply
0 Kudos
RDPetruska
Leadership
Leadership

You attached a corrupt vmx file, not the vmware.log from the VM's folder.

Reply
0 Kudos
a_p_
Leadership
Leadership

In case you are running on Windows, you may use the batch script that I've posted at HowTo: Recreating a .vmx from the vmware.log file .

Please be careful if the VM has active snapshots (<vmname>-00000x.vmdk files). In such cases it's important to ensure that the newly created .vmx file points to the latest/current snapshot .vmdk file (usually the one with the newest time stamp).

André

PS: I assume that you do not use encryption for your VMs.

coloradosky
Contributor
Contributor

OopS!!

Here is the corrupt "log" file.  I will check out the script.

I also attached the previous log file.

thanks for the quick response!!!

Reply
0 Kudos
RDPetruska
Leadership
Leadership

First one was corrupt as well, but I recovered this file from the second log...

Reply
0 Kudos
coloradosky
Contributor
Contributor

thanks for the script!

That rebuilt the vmx and they are back working!

Reply
0 Kudos