VMware Infrastructure 3 is a hard act to follow. When VI3 was originally released, it not only set the bar for all virtualization solutions in its wake, but was so polished that many shops put it into production immediately, with no ill effects. Yesterday’s release of “VMware Infrastructure 3 with ESX Server 3.5 and VirtualCenter 2.5” (yeah, that’s the official name) hopes to continue the trend of stable, function-rich releases from the leader in virtualization. Based on what I’ve seen in the beta code I’ve been testing, it’ll be a close call.
I’ve been running ESX Server 3.5 and VirtualCenter 2.5 in the lab for weeks now, using the code provided from VMware’s beta program. The highlights of the new VI3 release include new features such as live storage migration and distributed power management, plus a bevy of new add-ons – for example, an automated patch manager and a tool for capacity planning and P2V migration.
The big news in the updated VI3 isn’t the core functionality – VMotion, Distributed Resource Scheduler, High Availability, and Consolidated Backup have been in customers’ hands for more than a year now. There are a few little additions here, such as Cisco Discovery Protocol support on ESX hosts (which makes switchport location trivial), but the larger story is in the management additions to the base packages.
One of the most prominent of these is Update Manager, essentially an automated Windows and Linux patch manager application specifically designed for virtual machines. It allows admins quick and easy access to reports on outstanding security patches and bug fixes that apply to one or more VMs, and to schedule the installation of those patches.
Update Manager traces its ancestry to Shavlik’s HFNetChk and functions in a similar fashion. The key difference is that it automatically takes a snapshot of the VM’s current system state before applying the update or patch, providing a safety net that is crucial for maintaining stability across a virtualized environment.
Update Manager also significantly eases some of the administration burden found in manual or outboard patch management solutions.
Essentially, applying patches to one or more VMs is as simple as selecting them and running through a wizard. Once that’s done, it takes a snapshot of each VM, the updates are applied, and the VM is rebooted. If something has gone awry and the VM becomes unstable, it can be quickly restored to a known-good state from that snapshot. The length of time to retain these snapshots is also configurable, which reduces storage overhead while still providing a time-limited backup plan.
In the beta, this feature functioned reasonably well, although it seems to be more in tune to Windows patches than Linux patches, and it does raise some questions about automated patch installations on some Linux distributions. For instance, CentOS is essentially Red Hat Enterprise Linux without any branding or support, and is technically unsupported on VMware, but Red Hat patches can be applied to CentOS systems, which may be problematic from a licensing standpoint. The beta produced several interesting errors while running Update Manager, but no showstoppers. It’s a wide-ranging feature that could wreak havoc with an otherwise stable infrastructure if not closely controlled, but we’ll have to wait for the released code to accurately gauge its stability and reliability.
Called Storage VMotion, live migration of virtual hard disks is another eagerly anticipated new feature. The original VMotion is used to migrate VMs from one ESX host to another, provided that each ESX host shares access to the same central storage volume on an NFS, iSCSI, or Fibre Channel device. With Storage VMotion, running VMs can be migrated between data stores as well as ESX hosts. This opens up several new backup and load-balancing scenarios as well as providing a means to ensure suitable VM performance across multiple data stores.
The addition of Capacity Planner and Converter to VirtualCenter 2.5, in the form of the wizard-driven Guided Consolidation tool, is also quite notable. Capacity Planner, which has been something of a hidden product from VMware, is now moving to the forefront. With Guided Consolidation, VirtualCenter can be used to monitor any number of physical servers for a period of time, then produce reports on how well they will integrate into the virtual infrastructure. Once those decisions have been made, the P2V migration can be managed directly from VirtualCenter using VMware’s converters. This combination is sure to be a hit with shops that are just starting their virtualization implementations, but may also hurt several third-party P2V companies such as Leostream and PlateSpin.
Again, in the beta code, these tools were functional, but didn’t appear to be fully realized yet.
Also new is Distributed Power Management, which puts a green twist on automated load balancing. Working in concert with Distributed Resource Scheduler, this can be used to further reduce power and cooling costs in certain infrastructures.
For instance, in a Virtual Desktop Infrastructure scenario, if desktop VMs typically become dormant after business hours, it would be possible to shut down many of those VMs, migrate others to ESX hosts with low utilization, and then power down the ESX hosts that won’t be needed until load ramps back up in the morning.
One addition to the core platform is coming in the wake of the VI3 update, at a date VMware has not yet announced. Rather confusingly named V3i, or VMware ESX Server 3i, this is the embedded version of ESX Server, designed to be run from a USB flash drive or a CompactFlash card. Many server manufacturers have been integrating internal USB headers or CompactFlash slots in their servers for purposes just like this. V3i removes the need for ESX hosts to have local disks, further hardening them against hardware failure. However, make no mistake – V3i is nothing like the current ESX server. It’s completely new and removes the ability for any direct management of ESX hosts. There’s no Linux base in V3i, so it’s not possible to SSH into a V3i host or apply any third-party packages. This may make it a nonstarter with some advanced VMware shops, but for those running more vanilla setups, V3i might be the way to go. In order to alleviate concerns regarding direct host management and scripting, VMware is releasing a kind of CLI for V3i hosts. Basically a Perl wrapper around direct API calls to the hosts, it serves the same purpose as a true CLI, but it’s not running on the host itself.
In my tests of the beta code, V3i seemed to be the most fragile component. If VMware aims to release V3i shortly after yesterday’s launch, then it definitely has some work to do in the interim. I had several problems managing and using V3i hosts on supported hardware such as the Dell PowerEdge 2950. VMware’s equivalent of the Windows Blue Screen of Death is a Purple Screen of Death, and I saw that many times while testing the beta.
Apparently there was some discussion within VMware regarding whether to release VMware Infrastructure 3 with ESX Server 3.5 and VirtualCenter 2.5 as VI3.1. Given the scope of the new features, dubbing it a “dot-five” release was the right choice, and there aren’t enough core functionality feature additions to warrant a push to VI4. But hey, what’s wrong with a short and simple “VI3.5”? And how about coming up with different terminology to denote the embedded hypervisor? It’s already hard enough to explain VI3, ESX 3.5, and VirtualCenter 2.5 to the uninitiated. Adding V3i (or V3.5i) to the mix almost commands the eyes to glaze over in a complete lack of understanding.
Whatever it’s called, VMware has a lot riding on this release, not the least of which is the company’s outstanding track record of shipping no software before its time. If the released code is significantly more stable than the beta, it will undoubtedly be a winner.
