vSphere 5.5 Improvements Part 1 – The New Hotness in ESXi 5.5

I’ve really been enjoying the evolution of vSphere.next (the code word used for any new flavor of vSphere) through various beta builds. Since ESXi 5.5 has finally been announced (yay), let’s go over some of the new hotness that you’ll probably be interested in. Some of these are speeds and feeds, which I find a little boring, but the rest are awesome new features or much anticipated improvements.

To begin with, just about every configuration maximum published with ESXi 5.1 has been doubled with 5.5. This underscores exactly why I never care to commit any config maximums to memory – they change all the time. Hats off to VMware for figuring out how to double the maximums in a dot release (meaning 5.1 to 5.5). This allows for some rather crazy virtualization, as I don’t know many folks who can really use a 320 physical CPU vSphere host with 4 TB of memory yet – but I’m sure this will see the light of day soon.

It also grants you the opportunity to create 4096 vCPUs worth of virtual machines on a single host. Obviously, many of these numbers are not actually there as a target (a 12.8 to 1 ratio of pCPU to vCPU seems extreme), but it does allow you to sit back, relax, and go nuts with your virtualization efforts … at least for a little while longer.


Platform Feature Updates

OK, hopefully you’ve filled your noodle with the new speeds and feeds, because we’re moving on to features.

Virtual Machine Compatibility ESXi 5.5

You heard it right. The term “virtual hardware version” was officially dead as of vSphere 5.1, but not many folks noticed. With vSphere 5.5, the latest compatibility is “ESXi 5.5” – this roughly equals virtual hardware version 10. With this new compatibility format comes support for LSI SAS for Solaris 11, new CPU enablement (for the latest gen processors), and AHCI Controller Support for those that like to run the Fruit OS (Mac).

gpuExpanded vGPU and GP-GPU Support

First, let’s cover the terminology. vGPU is the act of taking a physical host’s GPU (Graphics Processing Unit) and allowing the virtual machines to map and consume the resource. A GP-GPU is a “General Purpose” GPU. While vGPU is definitely something I see many folks striving towards in the end user compute (EUC) space, GP-GPU is a bit more focused on leveraging the awesome calculating power of a GPU to do research.

Curious for more? Here’s a list of ideas on GP-GPU applications.

VMware is making an investment to ensure compatibilty across a greater number of GPUs (including Intel and AMD), along with supporting vMotion across different GPU vendors. There are three rendering modes you can leverage for your GPU – Automatic (detect), Hardware, and Software. Keep in mind that setting the rendering mode to Hardware will ensure that a workload cannot vMotion to a host that doesn’t have a hardware GPU, but Automatic will let it float among hosts both with and without hardware GPUs.

Miscellaneous Improvements

I also wanted to take a moment to point out that vSphere 5.5 supports hot-plug flash SSDs and PCIe devices, which I think will play very nicely into a situation where you are looking to leverage server-side caching with a minimal hit.

There’s also greater integration and coordination with physical host C-States with vSphere 5.5, which can ultimately reduce power consumption. In essence, I feel this just means that VMware recognizes that there are a ton of C-States available in modern server architectures and they are taking advantage of them.