VMware Communities
resting
Contributor
Contributor

Fix VMFusion 6 internal error?

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

Reply
0 Kudos
7 Replies
wila
Immortal
Immortal

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

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos
resting
Contributor
Contributor

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?

Reply
0 Kudos
WoodyZ
Immortal
Immortal

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.

Reply
0 Kudos
resting
Contributor
Contributor

It's not important to recover as I had already move on with my backup.

But I think I'll attach the vmware.log here anyway, to see if it fixes the problem.

Reply
0 Kudos
WoodyZ
Immortal
Immortal

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.

Reply
0 Kudos
resting
Contributor
Contributor

So I'd replace the .vmx file and its now saying "The file specified is not a virtual disk".

Reply
0 Kudos
WoodyZ
Immortal
Immortal

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.

Reply
0 Kudos