My OS X Lion VMware image, which has always been working fine on my computer, a 2.53GHz Intel Core i5 HP notebook, stopped working when I migrated to a Dell Core i7 notebook. The machine would immediately stop at boot-up with the following VMware error message:
My first thought was that the VMware patcher to enable OS X guest on Windows was somehow not executed successfully. I tried to reinstall VMware, rerun the patcher, and install different versions of VMware many times but to no avail. I finally tried to enable verbose boot using:
and the screen showed a little bit of more information, although not much useful:
There is no problem indicated by the above messages – it is simply part of the OS X boot process. The CPU was apparently halted as soon as the boot device was detected (indicated by the info ‘root device uuid is…’) without even attempting to boot further. Following a strange idea, I reverted the virtual machine to one of the previous snapshot, saved when OS X Lion was already running, and received the following warning about processor features difference:
The features supported by the processor(s) in this machine are different from the features supported by the processor(s) in the machine on which the snapshot was saved.
I chose to proceed, and guess what, my OS X booted up and functioned properly without further problems. For more than 2 weeks, due to time constraints, I simply worked with the virtual machine in that saved state, suspended it when done and reverting back to the snapshot (after saving all data) when I needed to reboot!
Solution: CPU ID masking
Recently I had some free time and determined to solve the problem completely. Following a Google search of the root device uuid message, I found this blog which describes a similar problem and the solution for VMware ESXi by editing the CPU ID:
- click on the Options tab
- click on the CPUID Mask menu item
- click Advanced
- scroll to the bottom of the window on the Virtual Machine Default tab
- under “Level 1″ set “eax” to 0000:0000:0000:0001:0000:0110:1010:0101.
I am using VMware workstation, which does not have such an option to mask the CPU ID. However, using instructions from this forum, I was able to change the CPU ID by modifying the VMX file and add the following line:
cpuid.1.eax = “0000:0000:0000:0001:0000:0110:1010:0101″
With this change, my OS X Lion booted up properly and there is no need to work with it in a saved state anymore.
But what makes OS X Lion dislike my new laptop’s processor and refuse to boot up? The fact that the unmodified virtual machine can still work on the new processor with the previously saved state implies that the processor difference is probably not critical – it was most likely a check that disables the processor if an unwelcome processor is found! With further research I realized that my new laptop processor architecture is Ivy Bridge, as compared with Sandy Bridge in my old laptop. Max OS X Lion doesn’t like Ivy Bridge architecture, and thus refuses to boot up unless the CPU ID is masked to make OS X think it’s running on a Sandy Bridge processor. What a hassle created by Apple, the virtual machine would have booted up properly and saved me precious time troubleshooting without this check.
Luckily, according to my research, this is probably not needed with Mountain Lion, since it supports Ivy bridge natively. I have not had the time to verify this, however.
USB 3.0 on VMware
On a side note, when trying to connect your USB device to the Mac virtual machine via VMware menu, you may receive the following error message:
“The connection for the USB device was unsuccessful. The device is currently in use”
When this happens, first check if the error message is telling you the truth. Stop all Windows applications that are currently using the device, reboot your laptop and the virtual machine and try again. If that doesn’t help and you’re using a new laptop with USB 3.0 ports, most likely you’ve hit a known problem – VMware does not support most USB 3.0 chips on Windows host. The Linux version does, however. This means, on Windows, you must revert back to a USB 2.0 or USB 1.1 port to avoid this error. So much for backwards compatibility!
In my case, I was lucky. My laptop has 4 USB ports, 3xUSB 3.0 ports and 1xUSB 2.0 port. I plugged the device to the USB 2.0 port and VMware was able to connect the device successfully.