Somehow opening a VM causes an "internal error".
It was fine, until I opened /Library/Preferences/VMware Fusion/vmnet8/dhcp.conf but I didn't save it.
In the .vmwarevm file, there's 3 files that look suspicious.
- 564d1a43-8310-eeb8-6061-59edf8f3ac85.vmem.lck
- Virtual Disk.vmdk.lck
- 564d1a43-8310-eeb8-6061-59edf8f3ac85.vmem
Can those be removed?
Is it possible to recover from this error?
VMFusion 6.0.4
Hi resting,
Those files are fine. No need to delete them by hand.
You're not giving a lot of information.
You say that you did not save the dhcp.conf file, but with OS X textEdit, closing IS saving.
Anyways, assuming you did not mess up the dhcp.conf file, the first thing to try is to go to Repair Permissions.
From Applications -> Utilities -> Disk Utility
Select "Macintosh HD" in the left and click on the "Verify Disk Permissions" button.
If it reports any errors, then use "Repair Disk Permissions" afterwards.
If that doesn't help (or there was nothing to repair) try restarting OS X as the next troubleshooting step.
Hope this helps,
--
Wil
Hi Wil,
Thanks. But I think I screwed it up.
My VM is in an external HDD, so I only have the `Verify Disk` option.
Turns out it found some problems so I proceeded with the `Repair Disk` option.
Now VMF complaints that .vmx file is corrupted and looking into it, yeah it is now a bunch of garbage characters now.
So I guess that's the end of hope to recovering?
Its not crucial cause I have a physical copy of the VM that works, only lost a couple of changes.
Could you advise what kind of troubleshooting we could do ourselves if we encounter such problem again?
The `Verify Disk Permissions` button in Disk Utility is disabled for external HDD.
Unless you wanted me to verify VMF's permission instead?
Now VMF complaints that .vmx file is corrupted and looking into it, yeah it is now a bunch of garbage characters now.
So I guess that's the end of hope to recovering?
Attach a copy of the vmware.log file, as a file!, and one of us will create a new .vmx configuration file from it for you.
The attached "Ubuntu_14.04.1_dev_64-bit.vmx.zip" file contains a new "Ubuntu 14.04.1 dev 64-bit.vmx" file created from the supplied vmware.log file.
With VMware Fusion closed, unzip (double-click) the downloaded attached "Ubuntu_14.04.1_dev_64-bit.vmx.zip" file and replace the original "Ubuntu 14.04.1 dev 64-bit.vmx" file with the one here.
So I'd replace the .vmx file and its now saying "The file specified is not a virtual disk".
I'm assuming you replaced the .vmx configuration file on the Virtual Machine that was having an issue and not the one that was working, right? Anyway, one common reason for the error when using a virtual hard disk of create type twoGbMaxExtentSparse (a split disk vs monolithic) is that either an extent is missing or it's zero bytes in size. Need to see a file listing of the .vmdk files showing filename, size and date/time stamp.
