VMware Mac OS X Guest Package for ESX, Workstation, Player, Server and Fusion

[Donk]

How I can install PS/2 mouse & keyboard drivers (along with ACPIPS2Nub) + should also install VMMouse, please...

 

 

 

Using Donk's darwin310b2 patch on my ESXi 4.0 U1, I was able to install Snow Leopard Server 10.6.0

After that I try to install 10.6.3 combo update, but after installation reboot my VM stop working beginning to reboot every time. 10.6.4 combo update has the same problem...

 

The PS2 drivers are automatically loaded when you boot from darwin.iso, so no need to install them. The issue with booting is Nehalem-C processors or later throwing an error when reading the virtual TSC. It can be fixed using a non-vanilla kernel, but my aim is to run vanilla SL. I have a couple of ideas for VMX file entries that may help. You would need to test them for me as I don't have access to machine with those processors that I can mess around on.

 

The first one to try is:

 

monitor_control.virtual_rdtsc = FALSE

 

The next one I still need to do a bit of research so will be back when I have done a few tests on whether it will be picked upo by the operating system.

[hippoth]

I have updated my server to ESXi 4.0 U2 Build 261974 but without success, the problem isn´t solved - it was a try

[Donk]

I have updated my server to ESXi 4.0 U2 Build 261974 but without success, the problem isn´t solved - it was a try

 

 

It is not going to be fixed until we get ESX update to include the enhancements in Workstation 7. Usually that is a major release e.g. ESX 5. Have you tried the VMX file change I mentioned. Otherwise we are looking at kernel changes. I can put one on the ISO, but I really want to see if this can be sorted out.

 

monitor_control.virtual_rdtsc = FALSE

[Zenith432]

The PS2 drivers are automatically loaded when you boot from darwin.iso, so no need to install them.

Are you sure the PS/2 drivers you added are dual-arch x86_64/i386? If the version is i386-only, and the kernel is 64-bit, they won't get loaded!

 

It can be fixed using a non-vanilla kernel, but my aim is to run vanilla SL.

I built a patched Darwin 10.4 kernel for whoever is interested. It fixes the TSC issue, provided the bootloader measures TSC frequency and stores it in the device tree. There's a link in the "Snowkitty" thread.

[hippoth]

It is not going to be fixed until we get ESX update to include the enhancements in Workstation 7. Usually that is a major release e.g. ESX 5. Have you tried the VMX file change I mentioned. Otherwise we are looking at kernel changes. I can put one on the ISO, but I really want to see if this can be sorted out.

 

monitor_control.virtual_rdtsc = FALSE

Yes I tried but without success ...

 

I built a patched Darwin 10.4 kernel for whoever is interested. It fixes the TSC issue, provided the bootloader measures TSC frequency and stores it in the device tree. There's a link in the "Snowkitty" thread.

The link is dead, can you provide a new one?

kernel.log.txt

vmware.log.txt

[DFox]

It is not going to be fixed until we get ESX update to include the enhancements in Workstation 7. Usually that is a major release e.g. ESX 5. Have you tried the VMX file change I mentioned. Otherwise we are looking at kernel changes. I can put one on the ISO, but I really want to see if this can be sorted out.

 

monitor_control.virtual_rdtsc = FALSE

 

Copy/paste into my vmx file but my VM still continues to reboot...

[yanis]

Could you tell me please the platform used, please??? Workstation, ESXi, Fusion, or other???

Could you tell me your procedure, please???

 

Thank you very much!!!

 

I used the original GM release of Snow Leopard Server on ESX4i, U1. I followed the instructions provided earlier in the thread with the b3 disk. I used a Windows 7 VM running the vSphere 4 client.

 

Now, first, slow down. You seem to be in a massive rush, are panicing and are missing steps. Read the information provided. Second. Delete your VM. If there are issues with it, screwing with it will only make it worse.

 

Start from the beginning. Uninstall the iso as per instructions and ensure you're using the correct B3 iso.

 

Then, create the VM as instructed. Ensure you enter the correct changes as has been noted a few times you've missed a few things. I used IDE for both CD and HDD. IMHO the difference between that and SCSI for performance will be negligible.

 

Boot up, at the F8 prompt mount the SL iso and let it boot. Don't bother with -v, -f or any other boot flag, either the host will boot to the setup portion, or not. If it won't boot clean, it's not going to install properly anyway. From there, you should be able to format the HDD (if it's a new HDD, use the partition tab to create the volume) and move around. You should find that 'tab' will let you navigate around if the mouse isn't working, with 'space' and 'enter' actioning.

 

If you manage to get the OS to install ok, as soon as you have got past the final setup questions and have a running install, STOP. Install the VMware tools first. Ignore the reboot request and install the VGAII driver and patches, again ignoring the reboot option until they're all done. Make sure you reboot AFTER doing all the installs.

 

Don't install any other updates, any kexts.. just the tools. Once restarted you'll be able to create a VM snapshot while the host is running. That snapshot can then be 'reverted' back to should something break.

 

Next, install updates from Apple. You can use software update and you sure as eggs don't need a patched kernel. Once they are installed and you have rebooted ok, you can delete the snapshot. I've had no issues with the stock kernel.

 

The whole point of the initial boot loader is to effectively run a vanilla install - so the LESS tweaks and kexts and patches (and other general {censored} you might be tempted to install) the better.

 

That's what I did. Took my time. Made snapshots "just in case" and didn't try and do the whole thing in five minutes flat. Anytime I'm making major changes, I create a new snapshot; apply the change and if all good, delete the snapshot. If anything breaks I can revert right back to an ok install.

 

Your mileage may vary, but the above has worked for me and the server has been up and stable for over 20 hours at this point. Really this should be considered as a platform to serve stuff from, not as a day to day host.

 

If you want a day-to-day mac, buy one or look at building a white box for it.

[Zenith432]

The link is dead, can you provide a new one?

It worked for me. Anyhow this post links to a new one.

[DFox]

I used the original GM release of Snow Leopard Server on ESX4i, U1. I followed the instructions provided earlier in the thread with the b3 disk. I used a Windows 7 VM running the vSphere 4 client.

 

Now, first, slow down. You seem to be in a massive rush, are panicing and are missing steps. Read the information provided. Second. Delete your VM. If there are issues with it, screwing with it will only make it worse.

 

Start from the beginning. Uninstall the iso as per instructions and ensure you're using the correct B3 iso.

 

Then, create the VM as instructed. Ensure you enter the correct changes as has been noted a few times you've missed a few things. I used IDE for both CD and HDD. IMHO the difference between that and SCSI for performance will be negligible.

 

Boot up, at the F8 prompt mount the SL iso and let it boot. Don't bother with -v, -f or any other boot flag, either the host will boot to the setup portion, or not. If it won't boot clean, it's not going to install properly anyway. From there, you should be able to format the HDD (if it's a new HDD, use the partition tab to create the volume) and move around. You should find that 'tab' will let you navigate around if the mouse isn't working, with 'space' and 'enter' actioning.

 

If you manage to get the OS to install ok, as soon as you have got past the final setup questions and have a running install, STOP. Install the VMware tools first. Ignore the reboot request and install the VGAII driver and patches, again ignoring the reboot option until they're all done. Make sure you reboot AFTER doing all the installs.

 

Don't install any other updates, any kexts.. just the tools. Once restarted you'll be able to create a VM snapshot while the host is running. That snapshot can then be 'reverted' back to should something break.

 

Next, install updates from Apple. You can use software update and you sure as eggs don't need a patched kernel. Once they are installed and you have rebooted ok, you can delete the snapshot. I've had no issues with the stock kernel.

 

The whole point of the initial boot loader is to effectively run a vanilla install - so the LESS tweaks and kexts and patches (and other general {censored} you might be tempted to install) the better.

 

That's what I did. Took my time. Made snapshots "just in case" and didn't try and do the whole thing in five minutes flat. Anytime I'm making major changes, I create a new snapshot; apply the change and if all good, delete the snapshot. If anything breaks I can revert right back to an ok install.

 

Your mileage may vary, but the above has worked for me and the server has been up and stable for over 20 hours at this point. Really this should be considered as a platform to serve stuff from, not as a day to day host.

 

If you want a day-to-day mac, buy one or look at building a white box for it.

 

Thank You very very much for explanation... Only one thing: what processor is installed on your ESXi server??? Donk said that could be problems with some processors type like my Xeon X3460.

 

Thanks again!

[yanis]

Thank You very very much for explanation... Only one thing: what processor is installed on your ESXi server??? Donk said that could be problems with some processors type like my Xeon X3460.

 

Thanks again!

 

Could be, yes. I have a Core 2 Duo. http://ark.intel.com/Product.aspx?id=30783

 

Ultimately, like any other OS, Snow Leopard has a set of hardware it's designed to run on. VMware ESXi isn't even close to a supported platform, so everyone's experience is going to potentially be different.

 

It's entirely possible the way VMware exposes the CPU instructions means some rig's just won't work. You may be able to make changes within VMware and the system BIOS to affect the CPU feature set available, but it's pretty much Russian Roulette.

[DFox]

Could be, yes. I have a Core 2 Duo. http://ark.intel.com/Product.aspx?id=30783

 

Ultimately, like any other OS, Snow Leopard has a set of hardware it's designed to run on. VMware ESXi isn't even close to a supported platform, so everyone's experience is going to potentially be different.

 

It's entirely possible the way VMware exposes the CPU instructions means some rig's just won't work. You may be able to make changes within VMware and the system BIOS to affect the CPU feature set available, but it's pretty much Russian Roulette.

 

Thank You again...

[flynjets]

Thanks - that did it!!!

Any idea why the disk utility hans in "unmounting" the IDE drive when trying to partition it?

 

Best regards!

 

UPDATE:

 

Confirmed the no-go for the disks - DiskUtility hangs in "unmounting". Adding disks etc. doesn't help!

Any idea why this happens and how to fix it???

 

(P.S. 10.5 works with the regular package w/o problems now.)

 

I'm having this same issue. Anyone have any ideas? I'm using ESXi 4.0 u2. Using ide for HDD. I've tried two different HDD, same result. Tried booting from retail DVD in the drive and from mounting the iso. Haven't tried with the b3 iso yet.

 

Thanks

New_Virtual_Machine.txt

Mac_OS_X.txt

[hippoth]

We use an Intel Xeon E5530 --> http://ark.intel.com/Product.aspx?id=37103

[yanis]

For those interested, have attached my (working) VM's .vmx config.

 

Apart from CPU and disk, it may give some pointers regarding CPU instruction; you may be able to copy the CPU section to see if it'll 'fake' the right instruction set, but odds are a Nahalem based rig is going to be a problem (indeed Apple really only has just recently started using them).

 

vmx.txt

 

Good luck.

 

EDIT: one recommendation I have for quad cores with HT, is either a) disable Hyper Threading in BIOS, or in the VM config itself you can disable HT (see below). HT is a known problem in some instances.

 

[hippoth]

For those interested, have attached my (working) VM's .vmx config.

 

Apart from CPU and disk, it may give some pointers regarding CPU instruction; you may be able to copy the CPU section to see if it'll 'fake' the right instruction set, but odds are a Nahalem based rig is going to be a problem (indeed Apple really only has just recently started using them).

 

vmx.txt

 

Good luck.

 

EDIT: one recommendation I have for quad cores with HT, is either a) disable Hyper Threading in BIOS, or in the VM config itself you can disable HT (see below). HT is a known problem in some instances.

 

I don´t understand how you disabled HT? My config is the same but HT is already active. In BIOS of the VM I also do´t find a way to disable HT and in the BIOS of the host I can disable but I won´t do this because there are other machines running on the ESXi.

[Donk]

For those interested, have attached my (working) VM's .vmx config.

 

Apart from CPU and disk, it may give some pointers regarding CPU instruction; you may be able to copy the CPU section to see if it'll 'fake' the right instruction set, but odds are a Nahalem based rig is going to be a problem (indeed Apple really only has just recently started using them).

 

vmx.txt

 

Good luck.

 

EDIT: one recommendation I have for quad cores with HT, is either a) disable Hyper Threading in BIOS, or in the VM config itself you can disable HT (see below). HT is a known problem in some instances.

 

 

I am working on changing the kernel patcher to fake a different CPU for Nehalem and later CPU models. This should get around the instructions causing the problem. The other way maybe to modify the masks in the CPUID VMX settings. Unlike the older ESX3/VI2.5 these new mask in the VMX file aren't documented.

 

Zenith432 reminded me what was wrong and it is CPU specific, and is due to reading certain MSRs. By changing the CPUID mask or family we can bypass those issues without using a 3rd party kernel.

[hippoth]

I am working on changing the kernel patcher to fake a different CPU for Nehalem and later CPU models. This should get around the instructions causing the problem. The other way maybe to modify the masks in the CPUID VMX settings. Unlike the older ESX3/VI2.5 these new mask in the VMX file aren't documented.

 

Zenith432 reminded me what was wrong and it is CPU specific, and is due to reading certain MSRs. By changing the CPUID mask or family we can bypass those issues without using a 3rd party kernel.

Thanks for your great work. I don´t give up the hope!

[Donk]

Thanks for your great work. I don´t give up the hope!

 

Can you try this one for me please? http://www.filedropper.com/darwin310b4 (Darwin 3.1.0 Beta 4)

 

If it fails can you do the serial file trick again for me please?

 

Note that I have not tested it at all, as Sunday at home and cannot connect to my test server.

[DFox]

I am working on changing the kernel patcher to fake a different CPU for Nehalem and later CPU models. This should get around the instructions causing the problem. The other way maybe to modify the masks in the CPUID VMX settings. Unlike the older ESX3/VI2.5 these new mask in the VMX file aren't documented.

 

Zenith432 reminded me what was wrong and it is CPU specific, and is due to reading certain MSRs. By changing the CPUID mask or family we can bypass those issues without using a 3rd party kernel.

 

Thanks Donk, You're great! Tomorrow I also will made the test with your new beta4 darwin.iso.

[hippoth]

Can you try this one for me please? http://www.filedropper.com/darwin310b4 (Darwin 3.1.0 Beta 4)

 

If it fails can you do the serial file trick again for me please?

 

Note that I have not tested it at all, as Sunday at home and cannot connect to my test server.

I have made a test but I don´t have good news. Maybe you find somethink usefull in the logs.

kernel.log.txt

vmware.log.txt

[Donk]

I have made a test but I don´t have good news. Maybe you find somethink usefull in the logs.

 

Damn! I have one last approach if that doesn't work then will have to go to modified kernels, based off Zentih432 work.

[Donk]

I have made a test but I don´t have good news. Maybe you find somethink usefull in the logs.

 

Let's try changing the CPUID masks to match my CPU model and family settings. I have no idea if this will work, but worth a shot.

 

1. Go back to using beta 2 please.

2. Edit the VMX and replace the existing lines with these:

hostCPUID.0 = 0000000b756e65476c65746e49656e69
hostCPUID.1 = 000106a500100800009ce3bdbfebfbff
hostCPUID.80000001 = 00000000000000000000000128100800
guestCPUID.0 = 0000000b756e65476c65746e49656e69
guestCPUID.1 = 000106a500010800809822010febfbff
guestCPUID.80000001 = 00000000000000000000000128100800
userCPUID.0 = 0000000b756e65476c65746e49656e69
userCPUID.1 = 000106a500100800009822010febfbff
userCPUID.80000001 = 00000000000000000000000128100800

 

with:

 

hostCPUID.0 = 0000000b756e65476c65746e49656e69
hostCPUID.1 = 000006fb00100800009ce3bdbfebfbff
hostCPUID.80000001 = 00000000000000000000000128100800
guestCPUID.0 = 0000000b756e65476c65746e49656e69
guestCPUID.1 = 000006fb00010800809822010febfbff
guestCPUID.80000001 = 00000000000000000000000128100800
userCPUID.0 = 0000000b756e65476c65746e49656e69
userCPUID.1 = 000006fb00100800009822010febfbff
userCPUID.80000001 = 00000000000000000000000128100800

 

Once I have this working on ESX, I plan to take a break from this work. Been going at it for 2 and half years, and I have other projects I want to work on. For all those using hosted products use the unlocker for now as it is the best solution, and as near to native VMware support as you can get.

[hippoth]

Let's try changing the CPUID masks to match my CPU model and family settings. I have no idea if this will work, but worth a shot.

 

1. Go back to using beta 2 please.

2. Edit the VMX and replace the existing lines with these:

hostCPUID.0 = 0000000b756e65476c65746e49656e69
  hostCPUID.1 = 000106a500100800009ce3bdbfebfbff
  hostCPUID.80000001 = 00000000000000000000000128100800
  guestCPUID.0 = 0000000b756e65476c65746e49656e69
  guestCPUID.1 = 000106a500010800809822010febfbff
  guestCPUID.80000001 = 00000000000000000000000128100800
  userCPUID.0 = 0000000b756e65476c65746e49656e69
  userCPUID.1 = 000106a500100800009822010febfbff
  userCPUID.80000001 = 00000000000000000000000128100800

 

with:

 

hostCPUID.0 = 0000000b756e65476c65746e49656e69
  hostCPUID.1 = 000006fb00100800009ce3bdbfebfbff
  hostCPUID.80000001 = 00000000000000000000000128100800
  guestCPUID.0 = 0000000b756e65476c65746e49656e69
  guestCPUID.1 = 000006fb00010800809822010febfbff
  guestCPUID.80000001 = 00000000000000000000000128100800
  userCPUID.0 = 0000000b756e65476c65746e49656e69
  userCPUID.1 = 000006fb00100800009822010febfbff
  userCPUID.80000001 = 00000000000000000000000128100800

 

Once I have this working on ESX, I plan to take a break from this work. Been going at it for 2 and half years, and I have other projects I want to work on. For all those using hosted products use the unlocker for now as it is the best solution, and as near to native VMware support as you can get.

It seems not possible to mask the CPUID, because the ESXi cancels the changes in the vmx. After shutting down the guest the vmx file has the old paramters for CPUID.

[Donk]

It seems not possible to mask the CPUID, because the ESXi cancels the changes in the vmx. After shutting down the guest the vmx file has the old paramters for CPUID.

 

You must have the guest shutdown and the VI Client closed to make manual edits to the VMX file. Can you try again? Or are you saying that even with everything powered off the edit doesn't stick?

 

Forget this approach. The settings are generated by VMware and cannot be changed.

[DFox]

You must have the guest shutdown and the VI Client closed to make manual edits to the VMX file. Can you try again? Or are you saying that even with everything powered off the edit doesn't stick?

 

Forget this approach. The settings are generated by VMware and cannot be changed.

 

I tried darwin301b4 but after software update to 10.6.4 it contines to reboot!