As we rapidly approach yet another VMworld conference and the general release of VMware vSphere 5, it's clear that VMware hasn't been resting on its laurels. The newest version of vSphere builds on the strong foundations of vSphere 4.1, showcasing new management and automation features and levels of scalability.
Almost to a feature, the new capabilities mainly benefit larger environments, at a time when smaller shops may find what they need at lower prices among VMware's competitors. As I noted in the virtualisation shoot-out earlier this year, VMware's still the king of the hill, but the competition is climbing fast.
VMware once enjoyed the advantages of having the only virtualisation solution with big ticket features like vMotion, DRS (Distributed Resource Scheduler) and HA (High Availability), but those features or reasonable facsimiles are now present in competing solutions from Red Hat, Microsoft and Citrix. This pushes the feature race up the ladder, as features beyond the core virtualisation group have a smaller audience, and they're more likely to be useful in enterprise infrastructures.
The big new features in vSphere 5 include a scalability bump allowing VMs to have 32-way SMP and 1TB of RAM, a redesigned HA architecture, storage DRS, profile-driven storage, automated host deployment, a new Linux-based vCenter Server appliance and the elimination of ESX in favour of ESXi. These are very handy new features for larger environments, especially the new HA design, assuming it proves less finicky than the previous incarnation.
Storage DRS and profile-driven storage are two other features that will make an impact. Storage DRS is exactly what it sounds like, the ability to have vSphere automatically trigger migrations of VM disks when capacity or performance of a particular storage array eclipses certain thresholds. In concert with normal DRS, this allows vSphere to load-balance the entire infrastructure, from the CPU and RAM utilisation in the hosts, through to the storage space and disk I/O on the back end.
Storage DRS also introduces the concept of storage maintenance mode, which functions much like host maintenance mode. This allows an administrator to automate the evacuation of all VMs running on an array. Large shops with significant numbers of storage arrays will really dig into these new features.
Those same shops will find that profile-driven storage is another significant new feature, as it allows various storage arrays to be tiered within vSphere. This feature ensures that VMs requiring the fastest disk always get it, and VMs that don't need so much speed are tied to slower, cheaper arrays.
The new auto-deployment framework is also mainly for larger shops. Prior to vSphere 5, you could install new physical hosts via traditional PXE methods, but with the new version, you must use Auto Deploy. This might not be that big of a deal to some, especially with the new-found capability to run stateless ESXi boxes. However, those with a rich PXE environment may not be so thrilled at this change.
The advent of stateless hypervisors may also aid larger shops, as it eliminates the need for any form of local storage on the physical servers. Each physical host can ostensibly boot from the network, configure itself appropriately and start taking a load of VMs.
The new Linux-based vCenter Server appliance should be a welcome addition in shops large and small. It's based on a SUSE 11 distribution and functions just like its Windows-based sibling. However, there's no migration path between the two, so all configuration and historical performance data will be lost if transitioning from the Windows-based vCenter Server to the new Linux appliance. This will likely prevent many existing infrastructures from deploying the appliance, at least in the short term.
As you can see, much of what vSphere 5 brings to the table may not have much impact on smaller virtual infrastructures. The expanded VM scaling is great news to those who need 32-way 1TB VMs, but the vast majority of virtualisation shops aren't even running physical hosts with those specs, much less VMs.
When VMware announced the new licensing scheme for vSphere 5, the hue and cry from existing users was deafening. By tying licensing to virtual RAM utilisation rather than physical host sockets and RAM, VMware had many customers looking down the barrel at a massive increase in licensing costs to support their existing infrastructure, much less any additional capacity they may have been planning on.
In fact, the pushback was so severe that VMware backed down and made significant changes to the licensing plan. It doubled the RAM entitlements in the Enterprise and Enterprise+ levels, to 64GB and 96GB respectively, and increased the entitlements in Essentials and Essentials+ to 32GB, versus 24GB in the original plan.
VMware also capped the licensing limit to 96GB per VM, so companies running those monster 1TB VMs pay for only the first 96GB. In addition, it shifted the virtual RAM calculation from current usage to a 12 month average. This was a particularly significant change, because prior to this modification, bringing backup and disaster recovery VMs up for testing and compliance checks could have instantly doubled the RAM utilisation, throwing all licensing calculations out the window.
While many folks are still not thrilled with the new licensing scheme, these concessions make it usable. Had the original plan been maintained, it's likely that VMware would have priced itself into oblivion, sparking a mass exodus of users to competing products. In fact, the startling number of customers who began evaluating other solutions after the new licensing was unveiled may have forced VMware's hand and led to these changes.
VMware vSphere 5 gives larger shops many reasons to consider an upgrade, while smaller outfits might want to stick with vSphere 4 for the time. I have vSphere 5 running on several boxes in the lab and will be putting it through its paces for a full hands-on review soon. It's too soon in the testing to know for sure, but I've already encountered a few problems that may point to the common situation of a problematic x.0 release, including what appears to be a tricky spontaneous reboot issue. Stay tuned for that review in the coming weeks.