Migrated VM to external drive. Now Fusion crashes on launch.

[janderfu]

I Installed a 2nd hard drive in my MacBook tonight. Migrated the VM to the new drive, and now when I try to load Fusion (5.0.3) all it does is crash.

It warns me that I should do a disk cleanup but when I try, it give me the error "An operation is already in progress" and then Fusion crashes again. I have a feeling the two things are related. I have attached my support information logs.

Machine is a 2013 MacBook Pro 13"

Core i5 2.3

16GB Memory

OSX 10.9.5 -> 256GB SSD

Windows 7 Pro -> 256GB SSD

[Mikero]

Just putting it out there, but have you re-installed Fusion and/or rebooted the Mac?

[janderfu]

Yes. I have rebooted the machine and reinstalled fusion. It seems to be some kind of corruption of the virtual disk. Because the whole reason I did any of this was so I could expand the size of the virtual disc. And now, when I try to do that, it simply crashes Fusion.

[janderfu]

I also noticed that there is a .lck file generated when the program crashes. It is generated in the library file for my windows installation.

[Mikero]

The logs seem to be complaining about the .lck state.

Try the steps outlined here and see if that helps:

Fixing an unexpected signal 10 error in Fusion

[Eric_Allione]

Is Fusion itself crashing right when you try to open it or just when you deploy that VM? Is it your only VM?

If you have other VMs perhaps you could get Fusion to open by going to that file's location if you know where it is, and then using "Open With". On my Mac the kind of file shows up as VMBundle for a Windows 10 OS that I deployed straight from an ISO. Note that I appear to be unable do to this with my OVA/OVF VMs.

Just for fun, I dragged the VM Bundle to a new location, and then right-clicked it and used "Open With" Fusion. It gave me a pop-up asking me to confirm whether I moved or copied it, I selected "Moved", and then the VM fired up in just a few seconds without going straight through the Fusion GUI.

Another thing I noticed is how old your version is. Mine says version 8.5.6. Maybe your version (5.0.3) is showing its age?

[wila]

Hi,

You mention both "external drive" and "in my macbook pro".

As your model is from 2013 it might still be "in".

If so, then I've seen something similar when adding a 2nd drive to my macbook pro.

It had to do with the sata cable... (or at least with the 2nd disk connection on which normally a dvd rom resides)

If adding a SSD on that connection I would get disk corruption and IIRC not full sata3 speed.

If adding a normal disk it was fine.

The normal disk gets just "negotiated Link Speed: 3 Gigabit"

This was a real head breaker to figure out at the time and I wasn't happy having to swap the drives.

But it worked fine since then (2012 MBP)

--

Wil

[janderfu]

I tried that. No change. Relaunch simply recreates the .lck file.

[janderfu]

Yes, technically its internal and in place of the old broken SuperDrive. That is interesting.

I was able to pull an old copy of my virtual disk via Time Machine. And I can get that to load in Safe Mode but it will not load in normal mode.

[wila]

Hi,

In that case, first check the speed that the disk is communicating with your MBP (apple icon-> About this Mac -> More info -> System Report -> Sata )

Then look at the negotiated disk speeds for both disks.

My guess is that one says 6 Gb/sec and another one (the problem disk) 3 Gb/sec

Now that by itself of course might not be a problem and if you're not seeing it, you still might not be in the clear.

It does however indicate that not both disks are treated the same.

I remember that copying already destroyed parts of the data and that I managed to isolate it by taking md5sums of the full disks both on the original disk as well as on the new disk.

The md5sums did not match after copying as a few bits had flipped.

FWIW, if you google a bit you'll find articles like this one:

SOLVED: Replace superdrive with SSD SATA I or SATA II? - iMac Intel 21.5" EMC 2389 - iFixit

His explanation is slightly different as mine, but the gist is still the same.

It might be that you are seeing issues because your SSD disk is not communicating correctly with the SATA controller.

Oh and PS..please be careful when depending on Time Machine for your Virtual Machine backups. TM is not a reliable means for backing up virtual machines.

Google this forum for the horror stories, or take a look on the following page at my website Why is Time Machine not good for making backups of Virtual Machines? – Vimalin

(Yes, I am the author of that tool, there's a free version you are welcome to use or make manual copies of your VM, but please be aware that depending on TM for backup of virtual machines and thus virtual disks is not recommended)

--
Wil

[janderfu]

I looked at my system report. Both drives show a 6Gb/s links speed.

http://i.imgur.com/X8hNCKZ.png

[wila]

That's at least hopeful in that you might not be affected by that particular issue.

A better test however is to md5sum a bunch of large files (say your virtual disk) and copy it over to the new disk and md5sum again to see if it stll matches.

Eg. Shut down a VM, Then run a command like I'm doing here below for a CentOS virtual machine of mine

md5 CentOS\ 64-bit/*.vmdk
MD5 (CentOS 64-bit/CentOS 64-bit-000001-s001.vmdk) = fbbaf543d11322be046a23d90c274e6a
MD5 (CentOS 64-bit/CentOS 64-bit-000001-s002.vmdk) = 65e4bf553ee78515000c25dd49a230a9
MD5 (CentOS 64-bit/CentOS 64-bit-000001-s003.vmdk) = 6c0e5d5fbd1970a9df72ae113e465bf5
MD5 (CentOS 64-bit/CentOS 64-bit-000001-s004.vmdk) = 7b1d2f4edb6a754f0ba5d51051588da7
and a lot more output that I snipped

Copy the virtual machine and repeat the exercise from above for the copied files.

If the hash of the files don't match then you've got hardware issues. (Your story would suggest the SSD and/or connection to the controller), but it might also be something like RAM)

It it matches and the virtual machine is as big as the one that you had problems with then hardware issues are less likely to be the cause.

--

Wil