VMware ESXi, Xserve, and virtualizing your old Mac server infrastructure

I've been asked quite a bit on this blog, offline and via email about Mac Virtualization. Specifically, virtualizing old Mac OSX servers that previously ran on Apple's discontinued XServes. With VMware's ESXi, you can easily consolidate clusters of old Mac servers into fewer machines and easily provide failover and redundancy. For example if you had 4 Xserves, you can dedicate two as Hypervisors and virtualize all four older Mac Servers on a single machine. With two hypervisors, you would have duplicate and redundant standby failover new Mac servers.

Hopefully, this post will be a guide to help many of those who want to consolidate and virtualize their old Mac OSX 10.6 (and up servers). Think of this as a road-map, blueprint from this fortysome geek. This is my article on running ESXi on the Xserve and virtualizing old Mac servers.

First of all, you will need a few things.

• VMware's Free Hypervisor server, ESXi version 5.1.0
• VMware's Desktop Fusion. 
• an INTEL XEON Power Mac or XServe. My host is a XServe 3,1 which was the last one from 2009.

You could probably skip VMware's Fusion and do everything on the server and I can probably write a separate post on that. However,  you'll probably want to test and image your old servers locally before deploying. I do all my imaging on my Macbook. Hence, this post will assume you have VMware Fusion.

Now, you will also want to brush up on two old articles I previously written:

Cloning a Physical Mac into a VMware Guest using Fusion 5.
and
My first attempt at installing ESXi 5 on Apple's XServe

You've probably one or both but stuck. Yes, I know because people have been hounding me on this. Hopefully this guide helps.

As I mentioned before, you will need Fusion to prep everything in this exercise  In addition, you will need VMware's command line tools, OVFTool. You can google it and read about it here.

After you have successfully cloned your live Mac into a VMware Fusion Guest, you will need to clean it up and ready it for deployment.

Here is an example of a successfully cloned XServe running in Fusion. This is running off my Retina Macbook Pro.

So far, everything works. In fact, I can probably just dedicate a Mac running Fusion to host this but we rely want to run ESXi because it is bare metal  fast and the "proper" way to host VM machines.

Fusion VMs are actually a package folders with a bunch of files. There are a couple of files that make up the VM guest. A .vmx file is the configuration file, the .nvram is the BiOS state, and the .VMDK is the hard drive images. The other files are not that important as they are things like snapshot, swap files, and log files. You are primarily focus on two files the .VMX and the .VMDK.

If your machine is fully shut-off and not in a suspended state, you don't have to worry about those other files. Moreover, you should not have any snapshots if you just did a clean clone.

We will use OVF tool to make a OVF (Open Virtualization Format) package. OVFs allow us to easily store and deploy to our Hypervisor server. You can skip OVF and copy your VMDK into a ESXI data storage, create a new shell and use the ESXi CLI to do some conversions but for the general intent of this article, we should focus on using OVF tool properly to make it more manageable. There will be some instances where OVF tool fails and we rely on ESXi and I will cover that.

Think of it as a best practice.

Pre-flighting a VM.

I am using the term Pre-flighting because most mac users know what that means when it comes to publishing and they want to prep their print design. Like InDesign or Quark, you want to make sure your file (the VM Guest) will be compatible and usable by others. Others, in this case is ESXi.

A couple of things to note. VMware treats OS X storage devices as SCSI LSI Logic controller.Gigabit  Ethernet is INTEL E1000. The LSI SCSI is important to know later if you come into problems.

Next, you want to remove as much un-necessary things that will fail in the importing into ESXi. You will also need to make some modifications in your Guest VM.

Here is a checklist.

In Fusion's settings for the VM Guest, you can modify, add and replace elements.

First,  remove the CD-ROM. The CD-ROM will flag the OVF file (which is in XML) that there is a IDE SATA device. This will automatically fail the import and cause problems.

Next, change the VM Compatibility.  I make all my machines Hardware version 8 to work with ESXi 5.1. I believe ESXi 5.5 has support for Hardware version 10 but I won't get there due to other issue.

Next disable sharing, remove any shares you have. Remove Bluetooth sharing as well.

In short, remove whatever is not necessary. This will ensure the OVF generated XML file is minimal. The extra option flags tend to generate import errors. I've imported quite a few Macs into ESXi and wasted a lot of time. These best practices helped me quite a bit.

This is the end of the pre-flighting. There are no guarantees you will get a clean import but only 3 out of 20 or so imports have failed on me.

OVF Tool

After pre-flighting, you will need to make the OVF package using OVF Tool. If you installed it
properly, it will be in /Applications/VMware OVF Tool/ovftool.

In the command line, you'll need to account for the spaces in the folder name.

Here is a sample OVF conversion.

Note the path of the tool.

The syntax is

 ovftool -dm=thin /PATH/GUESTNAME.vmwarevm/GUESTNAME.vmx /OUTPATH/FINAL.ovf  

and let me explain.

-dm=thin is a flag to make the disk Thin Provisioned. You need to do this as simply copying your VMDK over to ESXI will not work. You disk may be chunked in 2Gb segments or Thick provisioned. The other stuff should be obvious: your source path to the .VMX file and your new output OVF file.

The VMF files are usually in the folder which Fusion often appends .vmwarevm.

After invoking ovftool, sit back and relax. This should take a while to convert depending on the size. The final manifest should look like this. Your OVF, MF (manifest) and final VMDK file. There are other variations that include certificates and other things but in general, a OVF file should have these minimum three things. I choose OVF instead of OVA because I want to make sure the files are  separate.

Once this is done, you can now attempt to import into ESXi. Hopefully, there should be no problems. I will address those problems as well.

Deployment

If you've gotten this far, you should already know this is running on Mac Hardware. For legal and licensing reason, you can't deploy a Mac Guest into a Non Apple Hardware running ESXi.

With my XServe 3,1 running ESXi, we are now ready to deploy our guest.

I'm not going to cover the basics of deployment. If you are using ESXi, you should already know how to do it. There are also general ESXi info out there on the net. Hence, this section will try to cover issues you may have and work arounds.

Ideally, once you deployed, your new Virtualized Mac Server should just fire right up. It should show up in vSphere admin client and you should see it in the console. Done. Congratulate yourself on a job well done. I will go into other POST deployment last.

However, there can be problems. Let's go through them.

First of all. If your import is quick, there is a problem. If you have a 20GB .VDMK file and it takes takes 5 seconds to deploy, there is a problem. Go into the Storage pool and verify the size of the .VDMK file. Over the network, it should take at least a few minutes to hours depending on your network speed. Use your intuition and try booting the VM. Not all is lost, you can try manually deleting the attached VMDK disk and manually uploading your OVF produced VMDK. If that doesn't work, there is still options below.

Next, remember the CD-ROM? Well, if you didn't remove it, you will get errors like this. If you followed my pre-flight best practices, you will avoid errors like this.

Also, you may encounter EFI boot errors. This may happen if you did some weird things like add/remove a bunch of disks while cloning, or have a different start-up in the OS compared to what the BIOS expects.

Again, not all is lost.

Now there are two things you can do and I'll cover both strategies. It depends on the situation.

The first is re-attaching a new VMDK file. This means manually uploading your OVF VMDK file. For EFI errors like the above, we want to do that last because re-uploading takes time and you don't want to waste it if you don't have to. In situations where the import took 5 seconds and was insanely quick, you have to re-upload the VMDK.

The next, second option is to create an shell VM on ESXI itself and attach an existing hard disk. This is the quickest solution. You'll need to go through the process which is fairly quick. Make sure Hardware version matches your original guest. In my case, it is Hardware Version 8.

Attach the existing VMDK

You may be asked to specify a disk controller. Choose LSI Logic Parallel.

Now, try booting. If it boots, you are done. You may want to detach the VMDK drive image, rename, move it into the VM folder,and re-attach to make it more organized.

Now for the step where you manually upload a VMDK disk.
You can attempt to re-upload and re-attach and see if the system boots. If it does, you are done and good.

However, if the VM on ESXi does not see your disk, you'll need to convert it again in the ESXi shell. Go brush up and Google how to enable ESXI shell and SSH. This is why I prefer the Fusion local pre-flight method to avoid this step unless necessary.

You will need to SSH into the ESXI machine and use vmkfstool to convert the VMDK file.

Now, you will need to run the following:

 vmkfstools -i original.vmdk -d thin -a lsilogic clone.vmdk  

Basically, you are thin provisioning the disk and specifying it to be LSI Logic SCSI compatible. There is more but I won't get into it for brevity. There is a bunch of other things you can do with vmkfstools but this is the basic.

Sit back as this will take a while.

When the conversion is finish. test it by attaching the new clone disk image. If all is good, delete the original file.

I think this should cover most of the scenarios I've encountered. Hopefully, this guide helps. I'm sure there may be other scenarios but these are my "Best Practices for cloning a Mac Server into a ESXi VM."

Post Deployment/Install

Once everything is working, there are a few things to do. I would install the VMware Guest Tools. This allows for resizing the display and guest ACPI shutdowns fromt he keyboards and other things that Guest tools provide.

Lastly, make backup OVF that you can use to re-deploy or archive. Sure, your original Fusion generated OVF may just be fine but if you did some major changes inside ESXi , you will probably want to do a clean new Export. This guarantees it will be easy to re-deploy on to another Mac running ESXi VSphere Hypervisor server.

That is it! When I have time, I will write a companion article on how to do everything without Fusion and just the Mac and ESXi itself. It will reference this post. I hope this helps those interested in virtualizing their old Mac server environments.

There is a whole lot more that I didn't cover but this should be the basics. Sure,there is storage issues and fail-over issues to think of. For storage, look into iSCSI  as the three drive bays are insufficient and provide no tolerance on an XServe. There is also eSATA RAIDs to consider. Again, a broader subject for a different article.

Now for the hero shot.