VMware 5.5: Plenty that's new and exciting... but what about the obvious stuff?
A view from the ground
For a number of years I sat on the periphery of server virtualisation. After all, I ran my company's network and telecoms team, and if I had a server issue I'd wander five yards to the servers and storage team and ask them nicely to fix their world.
With the increasing coming together of networks and servers in a virtualised infrastructure, however, it was inevitable that I'd end up spending a couple of weeks sitting in a room while a trainer educated me initially in the art of vSphere and then in the magic of vCloud.
So as someone whose previous server experience revolved primarily around cabinets full of physical tin and flashing lights, how do I find this virtual server world? Is it the utopia I've been told about for years by the server guys, or is it actually just a load of old cobblers?
The instructor on my vSphere course described the installation process for the ESXi host software as “Bung in the CD and click Next, Next, Next”. And you know what, he's about right. The software likes to use the whole of the disk you're installing it on, but that's fine. The whole install process is incredibly painless, and what you end up with is an ESXi host that's nearly useful.
“Nearly useful?” you cry? Yes indeed. A single ESXi host is really only any good for a test or lab environment, because it's a hideous single point of failure: replace eight physical servers with eight VMs on one ESXi host and you're in big trouble as a single hardware failure will kill all eight VMs. You can, of course, introduce several ESXi hosts to spread the load, but they'll all be stand-alone entities: what you actually need to do is bring them together in clusters so they can interact, and for that you need vCenter.
vCenter was traditionally an application that you installed on a Windows server. That was fine, but was a hell of a faff to install because you had to muck about with the back-end database and such like (and, of course, you needed a Windows licence to sit the application on).
With the 5.x generation of vSphere, vCenter is available as a virtual appliance. No more buggering about installing loads of components – just hit File → Deploy OVF Template... and wait for it to do its thing. vCenter brings all the things that you really need in a virtual environment – clustering, migration of VMs between hosts and automated fault tolerance and high availability.
When it's working, vCenter is great: it just works. My problem is starting it up: I can grow a long, bushy beard in the time between the admin GUI telling me the services are up and the vSphere Web Client service actually starting to respond to my browser. VMware take note: don't bother telling me that the service is started until I can actually interact with it!
Management of a VMware setup was traditionally achieved via what the oldies call the “C# client”. It's a Windows application whose general look and feel hasn't changed much in recent years, and although the actual concepts you're managing with it are often far from trivial, the application itself is fine.
From release 5.0, however, VMware have introduced the vSphere Web Client. Many die-hards curse the Web Client; this is partly because it's quite a lot different from the C# cllient in its look and feel and partly because it can be a bit slow. Personally I quite like it, though this may well be because my 5.5 version in the lab feels considerably snappier than the 5.1 version I used a few months ago on a different installation.
The problem, though, is that VMware needs to make its mind up – because unbelievably you actually need to use both clients to manage your world. Some functions can only be achieved through the C# client – notably Site Recovery Manager and Update Manager, but most importantly direct management of the ESXi host. Other functions (anything new in vSphere 5.1 onwards, basically) haven't been included in the C# client and so you have to use the Web client.
This latter issue is a particular pain in the arse if, like me, you're a Mac person. Once you've made a manual change to a config file (an out-of-the-box 5.5 install doesn't quite work on Macs as the remote console function doesn't respond) it works a treat, but if you want to work individually on a host you'll need a PC or, if you're like me, a Windows VM inside VMware Fusion on the Mac. VMware really need to sort themselves out and make the Web Client universal.
Appliances and templates
The core benefits of virtualisation are, of course, the ability to share physical resources effectively between virtual servers, reducing the amount of idle CPU, disk and memory and hence reducing the requirement to buy all of the above.
My favourite two aspects are on the usability front, though. First of all is the ability to clone VMs, which has saved me literally days of work in the relatively short time I've been doing that kind of thing. In any installation I use I'll run up my first (say) WS2008 R2 server, let Windows Update download and install a bazillion items, then right-click, say Clone to Template... and wait a couple of minutes for the copy to happen. If I'm feeling energetic I'll play a little bit with the template – so I'll make it into a VM, boot it up, change its name and IP to something that's not going to clash with a real server, then switch it back to being a template.
Also cunning is the concept of a virtual appliance. More and more commercial software is being delivered as a virtual appliance – in the same way that I discussed earlier in the context of the new delivery mechanism for the vCenter server. Virtual appliances save hours of effort and make the process of installing a commercial package simplicity itself. In the old days you'd create a VM, installing a host OS, reading through pages of configuration instructions, walking through the software installing, realising that Windows Firewall is stopping everything working, and so on and so on. Now you simply say File → Deploy OVF Template... and your appliance winks into existence before your very eyes. All the simplicity and setup speed benefits that you get with a hardware appliance, but in software.
Working in the cloud
The cloud is, of course, a popular concept these days. The thing is, though, it's largely a new word for a concept that's been around for years – managed services in multi-tenanted infrastructures. VMware's offering to multi-tenanted installations is vCloud Director … which I find a complete pain in the arse.
Whenever I play with vCD I find myself thinking: they rushed this out to get things multi-tenanted and address the cloud market. It's a layer that sits on top of vSphere and vCenter and allows you to provide many customers with virtual private VMware setups, using overlapping IP network address ranges without breaking each other's worlds, limiting the available resource on a per-client and per-virtual datacentre basis, and all that nice stuff. And unlike our friend vSphere the client management app is entirely Web-based (and very usable). On the surface it's actually stonkingly useful and clever.
The problem is that they really do need to get it integrated properly with vSphere and vCenter sooner rather than later rather than, as is presently the case, having it as a kind of wrapper around them. The problem is that vCD and vCenter use completely separate databases; if a device is managed by vCD and you modify it in the vSphere client, everything gets out of kilter and vCD starts screaming at you about inconsistencies. vCD is also not yet shipped as a virtual appliance, which means lots of mucking about running up database servers and Linux-based VMs to host your vCD “cells”. It needs to be an appliance that integrates properly with vSphere, so that it simply doesn't let you do something in the latter if it'll break vCD.
“What's new” = “What shouldn't be new”
This latter point about the relative clunkiness of vCD is merely one example of the main thing that frustrates the hell out of me about VMware, though: the fact that although they're making progress by shipping things like the vCenter server as an appliance, there are plenty of clunky aspects and inadequacies about the platform that should have been addressed long before they were.
Let's take a handful of examples from the “What's New” PDF for release 5.5 to illustrate the point:
- The addition of native Active Directory support: blimey, they took their time!
- Support for 62TB VMDK (virtual disk) files: sounds great, but this means that until 2013 you were limited to a shade under 2TB!
- Hot-plug support for PCIe SSD devices: again, why has this only just arrived?
I understand VMware's priorities for development: put simply, the priority has to be on optimising performance and ensuring that they keep up with the competition (primarily Microsoft Hyper-V) and continue to add new features and support new technologies that appear.
So in 5.5 they needed to keep the green army happy by enhancing power management, and they needed to address video performance for those who don't just do number crunching on their virtual machines, and they needed to address limitations in their high availability failover process, and they needed to do something for people who do large-scale distributed computing with Hadoop.
Let's hope, though, that they find the time to say to themselves: “Right: what less exciting, non-ground-breaking features haven't we got round to implementing yet?”, and “What's really hacking off our users that we could easily fix?”. VMware's great, and it does everything I want, but even for organisations of relatively modest size, it's often only just good enough.
Keep doing the really cool, really hard new stuff then, VMware, but not at the expense of the obvious stuff.
Oh, and make your bloody minds up on the client app, if you please. ®