Installing OS X guests earlier than 10.6 on Mac hosts fail with kernel panics
|Mac OS X
Up through version 4.3.6 of VirtualBox I've been able to successfully install versions of OS X 10.4 and 10.5 as guests on Mac hosts. In my case the Mac hosts are a 2010 iMac and a 2008 Mac Pro. Since VB 4.3.8, trying to do the the same results in a kernel panic in the OS X guest during the install. I know this is not supported but it has worked in the past and I would like to see it continue to work in the future.
I've attached logs for both VB 4.3.6 where the install works for OS X 10.4 and 10.5 guests and VB 4.3.12 where it doesn't. I've also included logs for both versions of VB when installing OS X 10.6 as a guest, where the install always works for both versions of VB. In all cases it is necessary to choose the 64-bit versions of the OS X templates for the guests in the VirtualBox General Settings because the 32-bit versions will hang on a blank black screen, something that, by the way, does not happen in 4.2.24. In 4.2.24 the kernel panic occurs in the 64-bit templates and the 32-bit templates allow the installation of the guest. I've also included a log for the hang that occurs when using the 32-bit template in VB 4.3.6.
Checking the logs I don't really see much difference that would explain the issue. There are two things that may stand out that I should explain. In order to install older versions of OS X as guests on newer Mac hardware hosts it is necessary to present an older supported CPUID to the installer. I do that using the VBoxManage modifyvm --cpuid command. To have the install complete successfully it is also necessary to present a supported Mac Model Identifier for the version of OS X I'm attempting to install, which I do by modifying the DmiSystemProduct value.
The only thing that really stands out is the following example in the 4.3.12 logs:
00:00:00.572732 CPUM: Matched host CPU INTEL 0x6/0x1e/0x5 Intel_Core7_Nehalem with CPU DB entry 'Intel Core i7-3960X' (INTEL 0x6/0x2d/0x6 Intel_Core7_SandyBridge).
This does not exist in the 4.3.6 logs. Since this started in 4.3.8 when the devs started improving the emulation of certain MSR registers I'm tempted to suspect that something in those improvements broke the earlier functioning. If that indeed turns out to be the case it would be nice if the devs either fixed the issue, provided a CPU DB entry match that would allow things to work for earlier OS X guests, or provided some means to turn off this feature for individual guests.