rectalogic: Virtualizing Mac OS X Leopard Client

Monday, August 04, 2008

Virtualizing Mac OS X Leopard Client

VMWare Fusion 2.0 beta2 supports virtualizing Mac OS X Server as a guest OS. If you try to install a Leopard Client guest, you get an error

The guest operating system is not Mac OS X Server.

However, if you create an ISO/CDR image from your Leopard install DVD, mount it then do

touch "/Volumes/Mac OS X Install DVD/System/Library/CoreServices/ServerVersion.plist"

then unmount it, you can now use that image to install Leopard Client into VMWare with no complaints. After you install, reboot VMWare from the install DVD ISO again, run Terminal and

touch "/Volumes/Macintosh HD/System/Library/CoreServices/ServerVersion.plist"

then reboot from the HD. This probably violates your license agreement so don't do it, I certainly wouldn't.

Update:
You can automate the deletion and creation of the ServerVersion.plist file using a LaunchDaemon. Put the following xml in a new file /Library/LaunchDaemons/com.rectalogic.vmware.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.rectalogic.vmware</string>
<key>ProgramArguments</key>
<array>
<string>/bin/bash</string>
<string>-c</string>
<string>/bin/rm -f /System/Library/CoreServices/ServerVersion.plist; trap "/usr/bin/touch /System/Library/CoreServices/ServerVersion.plist; exit" SIGINT SIGTERM SIGHUP; sleep 999999 & wait $!</string>
</array>
<key>KeepAlive</key>
<true/>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>

Then run

sudo launchctl load /Library/LaunchDaemons/com.rectalogic.vmware.plist

Now when you login ServerVersion.plist will be deleted, when you shutdown it will be recreated ready for the next reboot.

Alternative approach:
An alternative approach discussed in the comments is to hack VMWare to disable the check for server.

sudo bash
cd "/Library/Application Support/VMware Fusion/isoimages"
mkdir original
mv darwin.iso tools-key.pub *.sig original
sed "s/ServerVersion.plist/SystemVersion.plist/g" < original/darwin.iso > darwin.iso
openssl genrsa -out tools-priv.pem 2048
openssl rsa -in tools-priv.pem -pubout -out tools-key.pub
openssl dgst -sha1 -sign tools-priv.pem < darwin.iso > darwin.iso.sig
for A in *.iso ; do openssl dgst -sha1 -sign tools-priv.pem < $A > $A.sig ; done
exit

Instead of sed (which seems to add an extra newline to the end of the iso) you might want to use

perl -n -p -e 's/ServerVersion.plist/SystemVersion.plist/g' < original/darwin.iso > darwin.iso

# posted by rectalogic @ 11:23 PM

Comments:

Software Updates are a bit tedious with this hack. You have to remove ServerVersion.plist before checking for updates, or it won't find any. Then after you install them when you reboot, you need to leave it removed or the updates won't install. So then when you reboot the VM will fail to start since it is now Client again. So you have to mount the disk or boot off the hacked DVD ISO and use Terminal to restore ServerVersion.plist and then you can reboot off the HD again.

# posted by

rectalogic : 11:28 AM

ServerVersion.plist is identical to SystemServer.plist with the exception of the product name, which is Mac OS X Server instead of Mac OS X

# posted by

Anonymous : 10:48 AM

Couldn't you just symbolically link ServerVersion.plist SystemVersion.plist ? On my 10.5.4 client I don't see a SystemServer.plist in /System/Library/CoreServices

# posted by

Jon : 11:13 AM

Does this work for Tiger? I would *love* to virtualize that for application / web browser testing...

# posted by

insideo : 12:01 PM

One solution for the SystemServer.plist issue would be a script or LaunchDaemon that deletes it on boot, and creates it when killed. Unfortunately, I don't see any way to capture the quit signal in a bash script without resorting to subscripts, which just wouldn't work well with launchd. I'll keep examining this, and whip up a little C program if necessary.

# posted by

Anonymous : 9:19 PM

I updated the post with a LaunchDaemon that automatically removes the ServerVersion.plist on bootup and recreates it on shutdown.

# posted by

rectalogic : 10:23 PM

I'm using disk utility to create a dmg, then running the 'touch' command, then converting to iso - still won't boot the installer image.... what am I doing wrong?

Using beta2 and a retail disc to create the image....

# posted by

Anonymous : 2:50 AM

I had problems converting a DMG to an ISO with Disk Utility. Try creating an ISO directly from the DVD instead of a DMG.

If it's not booting with the "The guest operating system is not Mac OS X Server" error, then you probably didn't create the ServerVersion.plist in the correct place in the ISO.

# posted by

rectalogic : 10:10 AM

For those that care, this hack lets you install in Parallels Server also.

# posted by

Anonymous : 11:02 AM

>> I'm using disk utility to create a dmg, then running the 'touch' command, then converting to iso - still won't boot the installer image.... what am I doing wrong?

Be sure you select the disk itself when creating the image, not the Mac OSX installer volume. If you don't select the disk you don't get the boot sectors off the DVD

# posted by

Phillip Moore : 3:31 PM

Actually, all this is far too complicated. The check for Server vs. Client is in darwin.iso, which can be modified.

Unfortunately, the ISO images are signed. Well, kind of. The public key for verifying the signatures is located in the very same directory. Nice.

cd "/Library/Application Support/VMware Fusion/isoimages"
mkdir original
mv *.sig original
mv darwin.iso original
sed "s/Server.plist/System.plist/g" < original/darwin.iso > darwin.iso
openssl genrsa -out tools-priv.pem 2048
openssl rsa -in tools-priv.pem -pubout -pubout -out tools-key.pub
openssl dgst -sha1 -sign tools-priv.pem < darwin.iso > darwin.iso.sig
sh -c "for A in *.iso ; do openssl dgst -sha1 -sign tools-priv.pem < $A > $A.sig ; done"

(Posting this to give the fine VMWare guys a chance to close this particular hole in Fusion 2 final.)

# posted by

Anonymous : 6:39 AM

Forgot one step:

mv tools-key.pub original/

where appropriate.

# posted by

Anonymous : 6:40 AM

Nice! Works for me, but it should be:

sed "s/ServerVersion.plist/SystemVersion.plist/g" < original/darwin.iso > darwin.iso

# posted by

rectalogic : 10:37 AM

The last shell script is giving me an error about A being and undefined variable. What shell should I be using?

# posted by

Nic : 2:31 PM

The correct and reliably sequence is probably

sudo bash

followed by

cd "/Library/Application Support/VMware Fusion/isoimages"
mkdir original
mv darwin.iso tools-key.pub *.sig original
sed "s/ServerVersion.plist/SystemVersion.plist/g" < original/darwin.iso > darwin.iso
openssl genrsa -out tools-priv.pem 2048
openssl rsa -in tools-priv.pem -pubout -out tools-key.pub
openssl dgst -sha1 -sign tools-priv.pem < darwin.iso > darwin.iso.sig
for A in *.iso ; do openssl dgst -sha1 -sign tools-priv.pem < $A > $A.sig ; done
exit

Works for me :-)

# posted by

Anonymous : 4:46 PM

That was the ticket! Thanks!

# posted by

Nic : 9:26 PM

Another (easier?) way of creating a working ISO is y converting a dmg into a toast image or creating a toast image from the installer DVD. .toast images are 100% ISO. Just rename the .toast extension into .iso.

# posted by

Wappie : 5:28 AM

Also intersting: I managed to clone my everyday Leopard install and run it as a VM by mounting my VMware Leopard-Server virtual disk on my desktop and overwriting its contents by cloning my startup-disk onto it using Carbon Copy Cloner. After that the Leopard-client VM booted just fine using the "SystemServer.plist " method posted here (THANKS!). Just remember to use the right name for your volume, if it isn't "Macintosh HD".

# posted by

Wappie : 5:39 AM

For those of you who don't know how to mount your VM's virtual-disk: just right-klick your virtual-machine file (i has the extension .vmwarevm) and select "Show Package Contents" Now look for the file "Virtual Disk.vmdk" Doubleklick it and it will just mount on your desktop.
You won't be able to mount suspended disk-images or VM's with snapshots. So make sure your leopard-VM is shut down, and all snapshots are gone.

# posted by

Wappie : 5:52 AM

For me the script at first seemed to work (VMWare detected my Leopard DVD as OS X Leopard Server 64-bit), however once VMWare booted into the installer it says: Mac OS X cannot be installed on this computer. Any ideas?

# posted by

Anonymous : 2:26 PM

"Mac OS X cannot be installed on this computer." means you are using a non-retail install DVD on a different platform. The client DVDs you get with a new Mac are specific to a set of hardware (e.g. a certain generation of MacBook Pro, or iMac or whatever). You will have best luck with a retail DVD. I'm not sure if you could use the DVD for the physical Mac you are running VMWare on - not sure if VMWare virtualizes the right pieces to fool the DVD.

# posted by

rectalogic : 3:08 PM

When I run the "touch..."-command I get the message "Read-only file system".
How to make a image, which is not Read-Only but can be used as bootimge for VM?

# posted by

Anonymous : 3:30 PM

Instead of "sudo bash" it's better to use "sudo -i"

# posted by

Anonymous : 11:37 AM

"sudo -i" will run the current users preferred shell, which may not be bash - could be zsh, tcsh whatever. The script is a bash script, so better to be explicit.

# posted by

rectalogic : 12:34 PM

Hey this is great. But I'm having a problem.

I run my virtual machine, it boots off the .iso ok, launches into the installer and I step through to where it asks where do I want to install OSX. But there's nothing in that window to select to install OSX on to.

I'm having the same problem if I try to install OSX Server too.

I'm sure I've set up the virtual machine settings to use a 64GB IDE virtual disk...

Any ideas?

# posted by

Dave : 6:49 AM

Umm... sorry... never mind. I figured it out. I'm a dufus :p

# posted by

Dave : 6:50 AM

I did the "darwin.iso" hack, and I OS X causes a stack fault in kernel mode just after the gray "apple" logo screen appears.

I have a 10.5.0 Retail DVD. Tried both "32bit" and "64bit" options for the VM type, and this is on my Mac Pro (dual 2Ghz xeons)

# posted by

urkle : 10:15 AM

This post has been removed by the author.

# posted by

Alan@polyphase.ca : 10:58 PM

Virtualizing Mac OS X Leopard Desktop is much easier now. Just use the DiscCloud Virtual Appliance that runs on VMware. Load the Appliance on Vmware server or ESX, connect a Leopard client, and run the DiscCloud tools to virtualized the desktop.

See: http://www.disccloud.com

and

http://disccloud.ning.com

Its real easy .. I set up my 4 year old dual opteron box with 4 SATA drives and now my user desktop on my eMac is 1TB! My desktop lives entirely in a virtual machine running on VMware server on the opteron machine!

# posted by

Anonymous : 8:58 PM

Just tried the iso image hack with the latest vmware fusion "Version 2.0 (116369)" and it works nicely. Albeit for me the install never gets past the spining grey circle :( perhaps its a coreduo vs core2duo thing?

great blog btw!

# posted by

Anonymous : 12:11 PM

My problem is, that after having tried this process, my system request server serial after that action and i can type anything during the boot and the system doesn't boot at all. Any idea? Any suggestion is welcome! Thanks in advance!

# posted by

Imre : 8:49 AM

Installation went great. I used the plist-method. But now, when it comes to the welcome screen, it can't use mouse and keyboard no more. The virtual machine doesn't seem to have any input devices and I haven't found a way to activate it in a virtaul machine. Did i miss something, or is there a special trick about it?

Thanx!

# posted by

Martin : 3:23 PM

I used the patch method on a final (= non beta) VMware Fusion 2.0 (Build 116369) - with the perl command instead of sed. I'm using a 24" Aluminum iMac with 4 GiB and 2.8 GHz.

After the patch the freshly created VM accepted the regular retail OS X 10.5(.0) Client DVD without any complaints straight from the SuperDrive and booted right into the installer.

As I'm typing this, the VM has already rebooted: Afterwards I was able to create my usual user/administrator accounts (of course I canceled the registration process, duh!) - as I type this it has just rebooted again after the installation of the VMtools.

Thanks a lot for this very valuable blog post!

# posted by

Anonymous : 12:14 PM

I got OS X Leopard Client installed and updated to 10.5.5. Now the only thing I can't get to work is Sound. I installed VMware Tools, and still no sound. Does the VMware Tools not work on the Client?

# posted by

rdbrown : 3:34 PM

Thanks for writing this.

# posted by

Rhea : 12:06 AM

Is it possible to just somehow run Mac OS X Server in VMware on a leopard client desktop/laptop? Everytime I try with my dvd it doesn't work right.
in 64-bit it says EBIOS error, and 32-bit it says that andjust loading dvd contents

# posted by

zyvangelist : 3:17 PM

It appears that VMware Fusion version 2.0.1 (released Nov 14, 2008) has added some checks that disable the work-arounds listed above.

I previously had Mac OS X 10.5.5 running flawlessly using the "alternative approach" with the perl command (listed near the end of the instructions above). With VMware Fusion 2.0, I was able to restart the VM at will, but when I attempt to boot this same VM under 2.0.1, it gives me the "Not Mac OS X Server" error.

Luckily I still have a snapshot taken with my Mac OS X client 10.5.5 VM running, so I can always revert to that. I just can't reboot the VM any more.

If anyone finds a way around this problem, please share!

# posted by

Anonymous : 12:45 AM

Installing 2.0.1 overwrote your patched darwin.iso. Given that the stock Leopard Client DVD boots just fine in 2.0.1 with a freshly patched darwin.iso: Did you re-apply the patch commands after updating?

# posted by

Anonymous : 7:56 AM

rdbrown: Fusion doesn't support sound for MacOS guests, regardless whether Server or Client :-( That's a known limitation (and documented in the release notes.)

# posted by

Anonymous : 2:09 PM

I'm the Anonymous guy who posted above: "I used the patch method on a final (= non beta) VMware Fusion 2.0 (Build 116369)"

After updating to Fusion 2.01 (Build 128865), the Leopard VM did not boot - as others have reported, "Not Mac OS X Server" ... sure the 2.01 installer overwrote the patched files.

I then re-applied the patch (again with perl instead of sed), and it went right through without any trouble.
As I'm typing this, Fusion 2.01 has booted the Leopard VM as if nothing happened.

# posted by

Anonymous : 6:31 AM

The "signature hack" worked flawlessly on my MacBook, with VMWare 2.01 and Leopard retail - thanks!

# posted by

Anonymous : 4:45 AM

Has anyone tried or has gotten Mac OSX Leopard Client to work on Parallels 4?

# posted by

Anonymous : 6:02 PM

I'm having trouble following the last part. What do you mean by, " After you install, reboot VMWare from the install DVD ISO again, run Terminal and touch "/Volumes/Macintosh HD/System/Library/CoreServices/ServerVersion.plist"
then reboot from the HD."

I'm getting an error from VMWare Fusion that reads "The Guest Operating System is not OS X Server."

Is the touch command creating the plist file on the Host OS X or the Virtual OS X Machine? I ran the touch "/Volumes/Macintosh HD/System/Library/CoreServices/ServerVersion.plist" command and found it created the ServerVersion.plist on my Host OS X system.

# posted by

Anonymous : 6:12 PM

Great posts here. I also tried the alternative approach and did the perl. It did finally recognize the Mac OS X DVD installation but when booting during the setup it could never get past to the "circle colored ball." Just spins and unable to install completely. Any ideas on how to resolve this?

# posted by

hayward room : 8:43 PM

Hi all !! i did the touch thing and the Hack for darwin iso. but i'm still block after choosing language :( it saied that OS X can not be installed on this computer... is it bcause i'm using a retail DVD i had with my MBP ?

# posted by

Anonymous : 10:00 AM

Still working with the 2.0.2 update :)

# posted by

Anonymous : 4:23 PM

I had to reapply the Anonymous' "correct and reliable" hack after the 2.0.2 update, but it worked.

# posted by

barakthecat : 4:39 PM

Using the launch daemon may require one more step. When you log in to your OS for the first time, launch terminal. You'll need to change permissions on the script.

sudo chown root:wheel /Library/LaunchDaemons/com.rectalogic.vmware.plist

After that, run the launch daemon loader:

sudo launchctl load /Library/LaunchDaemons/com.rectalogic.vmware.plist

Then you should be all good. I noticed that the console was giving me "dubious permissions (skipped)" for the .plist file. Once chown is run, the system will launch it automatically.

# posted by

David Martorana : 3:14 PM

Same here - I again used the hack with the "perl" line instead of the "sed" line. Worked flawlessly on 2.0.2 (147997), my Leopard Client test VM boots again.

# posted by

Anonymous : 4:44 AM

Though the alternative patch works great with a Leopard host, if you run Fusion on a Tiger host then the very same Leopard client machine won't work. Of course that's when you implement the .plist flipper, and then you're back in business.
The reason for a Tiger host, btw, is that there isn't as much fighting over graphics resources that way, and dragging VMLeopard windows is less choppy - for those of us cursed with GMA 950 displays.

# posted by

Anonymous : 12:02 AM

Nevermind about using a Tiger host to get rid of choppiness: If you have a GMA 950 machine, then only use *one* CPU in your VMs (of course, I modified the VM to use *two*). The best I could come up with for an explanation for this was Google results for the MacBook Air, which is basically a really flat incarnation of a regular MacBook (for VMware hosting purposes anyway) -- that article simply said that it can't handle it.

I hardly ever go with the defaults when I install any software, but the algorithm VMware uses to determine machine defaults is pretty much right on.

# posted by

Anonymous : 2:03 PM

For those who have a DMG and need to convert it to ISO, just use this command.

hdiutil convert image.dmg -format UDTO -o image.iso

# posted by

Anonymous : 10:34 AM

As usual: I again used the hack with the "perl" line instead of the "sed" line. Worked flawlessly on 2.0.3 (156731), my Leopard Client test VM boots again - on a Leopard host.

# posted by

Anonymous : 7:11 PM

Just to chime in, this still works with the 2.0.4 update. Had to redo the hackery after updating, hence returning to this page...

# posted by

Pepijn : 4:03 PM

Used the alternative method w/ PERL and it worked with my dev build of Snow Leopard.

# posted by

William J Sisti : 9:09 PM

Still works for the 2.0.5 update from 6/23/09.

# posted by

Pepijn : 10:12 AM

rectalogic

Monday, August 04, 2008

Virtualizing Mac OS X Leopard Client

Links

archives