I’ve been using my Intel i7  MacBook Pro daily for work and then during the evening for the past couple of months and have found it, on the whole, pretty good.  I bought my MacBook Pro with a 5400rpm SATA based internal disk as to buy a MacBook Pro with a 7200rpm SATA or SSD drive a special order was required which would have taken a number of days to come through which at the time I didn’t have the luxury of.  Disappointingly my MacBook Pro hasn’t been quite as responsive as I’d expected.  Now I don’t mean it’s sluggish it’s just a case of it lacking that extra sharp responsiveness I’d hoped for from a laptop of this specification and price. 

Adding an SSD to get the required IOPS to allow me run an effective portable vSphere lab was the logical option but the price of an SSD large enough (ie: >256GB) to accommodate the OSX install, OSX apps including VMware Fusion, ESX/ESXi VM and associated nested VMs was unfortunately way beyond my budget.  No doubt in a year or so 256GB and 512GB SSD’s will be the norm as far as SSD drives are concerned, but for now I had a requirement for IOPS and to some extent capacity – all on a limited budget.

Having dual drives in a laptop is an idea I have always quite fancied because of the flexibility around resilience (if in a RAID configuration), mixing of drive types (eg: SATA and SSD) and for increased capacity if required.  A quick Google search looking to see if there was an option to add a second drive to a MacBook Pro brought back a number of results and forum based reviews/comments.

The general consensus from the various forums seemed to be that by removing the CD/DVD SuperDrive in the MacBook Pro and replacing it with a 3rd party produced hard drive caddy which in turn utilised the SATA connection used by the SuperDrive was the best way.  After more research online I decided to go for a MCE OptiBay which seemed to be a popular choice in the online community.  Although the MCE OptiBay is not the cheapest at US$99 it sure beat buying a 256GB or 512GB SSD.

Along with the drive caddy the Optibay kit comes with an external CD/DVD housing in which to mount the SuperDrive which is removed from the MacBook Pro.

For the remainder of this post I will run through what is included in the MCE OptiBay kit and how I installed it into my MacBook Pro.    I should point out that there are different kits for the various models of MacBook and MacBook Pro, past and present, so if you end up doing similar make sure you buy the correct one.

IMPORTANT – INSTALLING AN OPTIBAY WILL VOID YOUR APPLE WARRANTY!

The Optibay comes well packaged in a small box.  If ordering it from outside of the UK be prepared to pay import duty.  I ended up paying having to pay an additional UK£21.00.

In the box, there was the OptiBay caddy, the external CD/DVD case along with USB and USB power cable, an instructional CD and a rather useful screw driver (which will no doubt also come in useful in the future).

Here is a close-up shot of the OptiBay.  It fits in perfectly where the SuperDrive occupies in the MacBook Pro and has the necessary hard disk mount points and a SATA/Power connector.

To install the OptiBay you need to remove 10 screws from the base of the MacBook Pro.  These are very small so be sure not to lose them when removing the base cover.  Check out this video to find out in more detail how to install an OptiBay into a MacBook Pro.

Once the base cover is removed the SuperDrive can then be removed (below) – this can be a little bit fiddly.  Make note of where you remove the screws from.  Also, as you can see I have already installed a 120GB OCZ SATA disk into my MacBook Pro.

I added a 500GB 7200rpm hard disk into the OptiBay housing and secured the hard disk using the usual mount points.  This was straight forward to do.

With the hard disk mounted into the OptiBay (below) and the SATA and power connectors connected all that needs doing is the base plate to be secured.  The entire process took about 25 minutes with an inexperienced OptiBay n00b such as myself installing it.

Upon starting the MacBook Pro and it booting into OSX I am now presented (see below) with both the OCZ SSD drive (primary) and the 500GB 7200rpm SATA drive (Secondary).  I can now move my photos, music and other space hungry files onto the slower SATA disk thereby providing sufficient spare space on the SSD drive from which to run a VMware ESX/ESXi VM and nested VMs from within it.

So how quickly does VMware ESXi 4.1 take to load off of the SSD drive in my MacBook Pro?  The answer is about 45 seconds which is pretty darn quick in my opinion, along with having the sufficient IOPS to run nested VMs off of it. Best of all my new vSphere lab environment is highly portable and ideal of customer demonstrations.  Check out the video below to watch the ESXi boot process on my SSD in real time.

Feel free to leave a comment if you have any questions regarding my experience with running VMware ESXi off of the SSD or the OptiBay installation process.

When running a virtualized instance of ESX/ESXi 4.0 Update 1 from within VMware Fusion or VMware Workstation you may notice the following error message on the front ESX/ESXi screen:

“NUMA: 706: Can’t boot system as genuine NUMA. Booting with 1 fake node(s)”

I started experiencing this message after beginning to run VMware ESXi (4.0 Update 1) on my new MacBook Pro with VMware Fusion. As you see from the screenshot below the CPU in my MacBook Pro is an Intel i7 with a pair of vCPUs and 4GB of memory allocated to the ESXi VM instance.

The good news is that despite the message you can still run VMware ESX/ESXi under VMware Workstation or Fusion without any issue though you may want to disable this message, which can be easily achieved via the following couple of steps:

1.  Open the vSphere Client

2.  Choose you ESX/ESXi host within vSphere Client, select the ‘Configuration’ tab and then ‘Advanced’ Settings

3.Select ‘VMkernel’ and ‘Boot’, then scroll down to almost the bottom of the ‘Boot’ settings.  Here you will find the ‘VMkernel.Boot.useNUMAInfo’ option.  This is option consists of a check box which you can toggle to enable/disable the NUMA Information.

Give the ESX/ESXi host a reboot and then you’re good to go and should receive the NUMA message anymore.

This fix is also outlined in this VMware Knowledge base article (KB1016141).

But what is NUMA?  With modern server architecture and vSphere, although you are not likely running VMworkstation on server grade hardware, it is useful to know NUMA stands for and how its shared memory architecture applies to an ESX/ESXi host.  The following is a good description from the “VMware vSphere 4: The CPU Scheduler in VMware ESX 4” white paper:

In a NUMA (Non-Uniform Memory Access) system, there are multiple NUMA nodes that consist of a set of processors and the memory. The access to memory in the same node is local while the access to the other node is remote. The remote access takes longer cycles because it involves a multi-hop operation. Due to this asymmetric access latency, keeping the memory access local or maximizing the memory-locality improves performance. On the other hand, CPU load-balancing across NUMA nodes is also crucial to performance.

The NUMA load-balancer in ESX assigns a home node to a virtual machine. For the virtual machine, the memory is allocated from the home node. Since the virtual machine rarely migrates away from the home node, the memory access from the virtual machine is mostly local. Note that all vCPUs of the virtual machine are scheduled within the home node.

If a virtual machine’s home node is more heavily loaded than others, migrating to a less loaded node generally improves performance, although it suffers from remote memory accesses. The memory migration may also happen to increase the memory-locality. Note that the memory is moved gradually because copying memory has high overhead.

So in a nut-shell,  a NUMA node consists of a physical CPU and an allocation of physical memory to which a VM and its vCPUs and memory are then allocated to.  There is an excellent article from Frank Denneman which covers the topic of sizing CPU and NUMA nodes in which he goes into a good level of detail around NUMA along with a few of the more common gotchas – definitely worth a look.  It is worth pointing out that for ESX/ESXi to apply NUMA nodes the underlying physical(s) CPU and architecture of the ESX/ESXi host must be NUMA compliant and have the associated NUMA architecture to support this mode.  Modern Intel based CPUs such as the Nehalem and Opteron processors from AMD are such processors.

In most instances where VMware workstation or Fusion is used to run VMware ESX/ESXi it is being run on a non-NUMA based system, with the underlying workstation or laptop also only having a single physical CPU installed.

From time to time you may have a requirement to rename a VMware ESX host, although this is quite straight forward to do in ESXi via the Direct Console User Interface (DCUI) there are a few more steps involved in making this change in ESX via the service console (SC).

The following post will take you through the steps to make this host name change in ESX.

The first thing to do before going any further is to remove the ESX host (whose name you want to change) from any cluster within vCenter Server that it may be a member of.  Also, remove the ESX host from vCenter Server.

Next log into the service console using the ‘root’ account.

We now want to edit the hosts file, so type:

vi /etc/hosts

If your ESX host’s host file doesn’t contain a server name such as the example below then you will want to manually add it.

I am adding the IP address (fixed: 192.168.1.25) and host name (esxhost1).  It is worth noting that at this point you can also add the domain name in which the ESX host will be participating to the end of this host name.

To save the changes we want to put the VI editor into ‘Command Mode’ by pressing the ‘Esc’ key and then typing :wq (write the changes & quit).  At which point you should be returned to the command prompt in the service console.

We now want to make a change to the network config file.

To do this type the following

vi /etc/sysconfig/network

Change the ‘HOSTNAME’ to be the new name of your ESX host.  Once again, save this change by pressing the ‘Esc’ key and then typing :wq 

Next we want to execute the following command:

esxcfg-advcfg -s <your new ESX hostname> /Misc/HostName

We want to register the new ESX host name in DNS so remove the old ESX host name and enter the new DNS name and associated IP address.

Now the final step is to reboot your ESX host for the changes to be applied.  Before doing this ensure you have migrated any running VMs to another ESX host or at least power off any running VMs first.

After the ESX host has rebooted you should now add it back into vCenter Server using its new name.

Ta daaa… It’s as easy as that. 

The vSphere Host Update Utility 4.0 is something of an overlooked utility for small business and lab environments wanting to patch or upgrade their ESX/ESXi hosts. In this basic ‘how to’ post I’m going to run through the steps in upgrading a VMware ESXi 4.0 host to ESXi 4.0 Update 1 using the utility.

The first thing I should mention is that the checking for updates and patching part of the utility is for ESXi and not ESX use, though the upgrading (eg: v3.5 –> v4.0) can be used by both versions.  If you are wondering how you get a copy of the vSphere Host Update Utility, it can be installed as an option at the time of installing the vSphere client on your PC. 

To start the utility navigate to the VMware folder and click on the ‘vSphere Host Update Utility 4.0’ menu item.

You’ll first be greeted with a message box asking it you want to ‘download the patches from the VMware patch repository’.  Click ‘Yes’.

Press the ‘Scan for Patches’ button and enter the ESXi’ hosts logon credentials when prompted.

The vSphere Host Update Utility will now scan the ESXi host for available patches. As you can see below there are 13 available patches detected.

If you’re ready to patch the host first make sure that your ESXi host is in ‘Maintenance Mode’’ and then click ‘Patch Host’.

You’ll now be shown a separate window containing a list of the available patches along with a description of each.  Take some time to read through each to ensure that you do in fact want to install them.  Deselect any you don’t want to apply and then click ‘Install’.

The VMware vSphere Host Update Utility will now apply the selected patches to your ESXi host.  Go and make a cup of tea as this can take at least a few minutes.

In this particular instance the ESXi host rebooted to complete the patching process (to ESXi 4.0 Update 1). When the host comes up again you will now see that it is running the latest version of ESXi.

Now what could be easier!    Hope you found this quick ‘how to’ guide useful.