When going to deploy a VMware vSphere OVA based vApp package you may receive the following vague error message: “The OVF package is invalid and cannot be deployed” along with “The operation is not supported on the object”.  The latter part of this error message is the message which is more specific to this particular error.

One possible cause for the “The operation is not supported on the object” error message is that you are trying to deploy the vApp into a vSphere host cluster with a single host and/or where DRS isn’t enabled.  Admittedly this is something of a generic error message, though this is definitely something worth checking and I have received this error message a few times before via the scenario outlined above.

If this isn’t the cause of your error or you have a variation of the “The OVF package is invalid and cannot be deployed” error message (which can cover a number of errors) then I recommend you take a look at the VMware community forums here.

During the upgrade or installation process of the VMware vSphere Client you may find yourself presented with the following error message, “Error 1406. Could not write value …”.

As with most issues/errors/problems there are a couple of different ways to resolve it.  The easiest I have found in this case is to delete a particular Windows registry key.  The following basic steps will show you how to resolve this “Error 1406” error message when installing/upgrading your VMware vSphere Client.

Before we start however I should point out that the registry key we will be removing could be shared with other VMware applications or utilities, eg: VMware Converter.  So take care before removing the registry key.

If you are trying to upgrade your vSphere Client (not vSphere Server installation) I would recommend first de-installing it.  To do this or to proceed with the fix for this “Error 1406” issue press the ‘Abort’ button to exit and rollback the vSphere Client installation.

Next click the ‘Yes’ button to confirm the cancellation of the install.

Once the vSphere Client installation has been cancelled remove any existing vSphere Client installs (not vSphere Client) from the PC/Server.

Next start the Windows registry editor

With the Windows registry editor opened navigate to the following registry key: 

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VMware, Inc

Take a look inside it to see if there are any other VMware applications or utilities listed, if there is only remove the key entitled: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VMware, Inc.\VMware Virtual Infrastructure Client.

Once you have deleted the registry key then restart the VMware vSphere Client installation.  I recommend running this installation as an Administrator.  To do this right mouse click on the EXE and then select ‘Run as administrator’.

Everything going to plan your VMware vSphere Client installation should now run through without any issue.

Hope this helped you get past your pesky ‘Error 1406’ message. Good luck!

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.