WilliamLam.com

Can You Backup & Restore Apple Mac OS X Guests Using vSphere Data Protection (VDP)?

by // 1 Comment

It is really cool to see more and more customers show interest in running Apple Mac OS X on vSphere. Just the other day there was another interesting question that was raised from a customer asking whether vSphere Data Protection (VDP) would be able to backup and restore Mac OS X guests.  Apparently there is still an assumption that VMware Tools do not exist for Mac OS X guests? Perhaps virtualizing Mac OS X is still relatively new for some folks, but it is just like any other guest operating system that is supported on vSphere.

I think the following two statements should help clarify any confusion that may exist:

  • To virtualize an Apple Mac OS X guest, you need to be running vSphere on Apple hardware. This is due to a requirement in Apple's EULA and is also enforced within the vSphere platform. You can get more details in this article. 
  • VMware Tools does exist for Apple Mac OS X guests, take a look at this article for more details.

Now, if we take a look at VDP's evaluation guide on page 4 we will see the prerequisite for backing up a guest OS is pretty straight forward:

At least one virtual machine running a supported guest operating system (OS) with VMware Tools installed

Since Apple Mac OS X (10.8, 10.7, 10.6 and 10.5) is a supported guest operating system and we have VMware Tools for this operating system, then yes VDP can be used to backup and restore an Apple Mac OS X guest. To demonstrate that this actually works, I have a Mac OS X 10.7 VM running in my home lab (Apple Mac Mini which is not officially supported) and I have deployed the latest version of VDP.

I then setup the backup job for the Mac OS X guests using the super simple VDP backup wizard and then initiate a backup.

Now, let's say I accidentally fat fingered an operation and deleted this VM. Uh oh!? What am I to do? Well don't worry, VDP is there to the rescue!

To restore the VM, it is simply going through the VDP restore wizard and in just a few minutes, I  have now recovered my Mac OS X guest and it is up and running again!

I have said this many times, but it still amazes me on the number of guest operating systems vSphere supports! There really is no workload that vSphere can not virtualize! So if you have any use cases for Mac OS X workloads, rest assure you can safely virtualize it and back it up on vSphere.

Note: Though I showed using VMware VDP as the backup/recovery solution, you should also be able to leverage both VMware vSphere Replication as well as VMware Site Recovery Manager.

number of guest OSes the vSphere platform supports

Executing Commands During Boot Up In ESXi 5.1

by // 6 Comments

There maybe certain use cases where you need to execute a command or series of commands during the boot up of an ESX(i) host and historically administrators have added commands to the /etc/rc.local which is one of the last scripts to be executed in the boot up process. However, with ESXi 5.1, the location of the file has changed from /etc/rc.local to /etc/rc.local.d/local.sh.

VMware also provides a KB2043564 that describes the locations for the various version of ESX(i):

  • In ESX 3.x/4.x - You would add the command(s) to /etc/rc.d/rc.local
  • In ESXi 4.x/5.0 - You would add the command(s) to /etc/rc.local
  • In ESXi 5.1 - It has changed to /etc/rc.local.d/local.sh

Disclaimer: As mentioned in the VMware KB, though this is supported, it is still not recommended that you edit these files unless directed by VMware support or under special scenarios.

A question that came up recently was about automatically loading the "multiextent" VMkernel module (which is required if you wish to use the 2gbsparse VMDK format, you can find more details in this blog article here) during the boot up of an ESXi 5.1 host as this had to be done manually, even if you had enabled the module. To do so, you just need to edit the /etc/rc.local.d/local.sh and add the following command above the "exit 0".

localcli system module load -m multiextent

Note: The reason I used localcli versus ESXCLI is that hostd may not be completely ready and hence the command may fail during the boot up process. One can also loop and wait for ESXCLI to be ready, but this is another way of performing the operation.

 

How To Compile Google Authenticator for ESXi

by // 2 Comments

In my previous article I demonstrated how to use Google Authenticator to provide two-factor authentication for ESXi using the custom VIB that I had built. In this article, I will show you how to compile Google Authenticator to run on ESXi as well as an additional customizations that can be made to the source code to support multiple users.

Disclaimer: This is not officially supported by VMware, use at your own risk

Prerequisite:

  • Download and install 32-bit Linux distribution. In my lab, I used latest CentOS 6.2
  • Install pam-devel package (CentOS) or libpam0g-dev package (Ubuntu). You can reference this blog here for more details on installation
  • Ensure you have both gcc and make installed

Step 1 - Download Google Authenticator source code by running the following command:

wget http://google-authenticator.googlecode.com/files/libpam-google-authenticator-1.0-source.tar.bz2

Step 2 - Extract the source code by running the following command and change into the libpam-google-authenticator-1.0 directory:

tar -jxf libpam-google-authenticator-1.0-source.tar.bz2
cd libpam-google-authenticator-1.0

Step 3 - Edit pam_google_authenticator.c and towards the top of the file comment out the following three lines which should look like this:

//#include <sys/fsuid.h>
//#define HAS_SETFSUID
//#endif

Step 4 - By default the SECRET file is stored in /.google-authenticator and we can change the path by modifying both google-authenticator.c and pam_google_authenticator.c by editing the SECRET macro file which should look like the following:

#define SECRET      "/etc/vmware/.google_authenticator"

Google Authenticator supports multiple users by default and you can also provide this support in ESXi by leveraging the $USER OS environmental variable within the SECRET file location. This would allow each user to generate and store their own SECRET file. To do so, set the path to /etc/vmware/$USER/.google-authenticator and the username will automatically be populated when configuring Google Authenticator for each user.

Note: If you are going to create a custom VIB and would like to support multiple users, you will need to know the usernames in advance so you can create the dummy .google-authenticator file for each user. This is required so the files will automatically persist after setting up Google Authenticator.

Step 5 - Save the changes and then type "make" which will then compile the source code and produce google-authenticator binary and PAM module pam_google_authenticator.so in the same directory.

Step 6 - If you decided to create your own custom VIB, ensure you include an empty secret file so when you go and configure it, the changes will be saved. If you do not wish to lower the acceptance level of your ESXi host for the custom VIB, an alternative trick is to store the google-authenticator binary and PAM module in a local datastore as well as the secret file and copy them over using either /etc/rc.local.d/local.sh for ESXi 5.1 or /etc/rc.local for ESXi 5.0. Here is a sample of what that should look like: