September 26, 2011, 12:28 AM — VSphere 5.0, the latest iteration of VMware's "Cloud Operating System," boasts a wealth of updates, including new tools to manage fleets of VMs, and vast tiers of virtualized, vMotion-enabled storage links. (See "VMware makes cloud jumping easy".)
Since storage powerhouse EMC owns a significant chunk of VMware, we always wondered when the storage dimension would become exploited more heavily, and we got the answer. But the storage-related enhancements are by no means EMC-specific.
VMware's feature list comes at a price per processor that ranges from as low as $85 to $3,495. And that doesn't cover the cost of Acceleration Kits. What you get with vSphere 5 is a feature set of inclining gradients that include stronger storage virtualization options, large and wide hardware support (in terms of vCPUs per VM, memory, and storage) and new capacity to roll-out and "life cycle" VMs at a very fast pace.
Preventing server sprawl is accomplished in the way vSphere controls the VMs and their storage as objects.
With so many tiers of feature support, it can be confusing and VMware had to send a cheatsheet so that we could keep track of what was available in what type of license. The graduations of licensing will require a spreadsheet analysis for most organizations.
IP address issues addressed
We performed both a bare metal install and an upgrade of our existing VMware vSphere 4 installation. Our small network operations center (100+ cores in six test servers, and Dell-Compellent SAN) isn't the best place to hammer vSphere 5, but we were able to give it a bit of a workout. (Note that support for ESX VMs has expired in vSphere 5.)
VCenter, vSphere's central control app, can now be run as a VM appliance if desired; the appliance runs SUSE Linux, and is lightweight. Other executables still have Windows executable equivalents if you need them; we didn't.
The initial upgrades went smoothly, save for the fact that the vSphere installers misidentified the name of our Active Directory domain, a small problem that had us scratching our heads.
There are incumbent steps to upgrade VMware's virtual switch appliance, and the new strategy removes a lot of IP addressing problems that existed in the prior release.
IP addressing can be a problem for administrators when moving VMs around, especially from facility to facility, as each is likely to have their own location-endemic addressing allocation needs.
The prior version of vSphere, while allowing for a bit of location-diverse addressing, didn't have strong multi-site transparency. The new virtual switch takes care of a lot of the misery for both IPv4 and IPv6 addressing schemes. It's not quite ideal, and some administrative functions must be done outside of the appliance, but its visuals allow a more inter-site understanding of addressing needs and allocations.
Thin-provisioning options
We used both our lab and our NOC resources to launch varying sized VMs of different operating system types — mostly Windows 2003/2008 R2 and Red Hat, CentOS, and Ubuntu Linux. There was no mystery. VM conversions were unmentionably easy, save for some important characteristics: we now had up to 32vCPUs per virtual machine (with advanced licensing option cost), and could see a tremendous amount of oversubscribed (if set) memory and storage. (See how we conducted our test.)
It's possible to thin-provision (oversubscribe, under-allocate in actuality) almost every operational characteristic of a VM. Doing so has benefits, depending on the settings we used, and allows vSphere to make recommendations, or simply move VMs from one server to another to manage actual needs, vs. initial judgments.
In doing so, VMware has also met a checklist item with over-subscription capabilities for those needing multi-tenancy options, as thin-provisioning permits "elbow room" that can be later physically provisioned when tasks and campaigns mount up.
