Product review: VMware pumps up VI3
ESX Server 3.5 and VirtualCenter 2.5 upgrades boost scalability and add handy new features; integrated tools for capacity planning, VM patching, and storage management fill important gaps, but wrinkles and loose ends remainFollow @infoworld
Storage VMotion can be a slow process, especially if the storage isn't terribly speedy, but it does work. This functionality can be a lifesaver in a number of situations, such as during storage migrations and upgrades. It further reduces the management and maintenance tasks that require a VM reboot, which ultimately helps service uptime and further extends the number of tricks that VMs can do that physical servers can't. Working in concert with Storage VMotion and DRS is the new DPM (Distributed Power Management) capability that can be used to power off dormant hosts if load drops. This nice green feature requires Wake On LAN (WOL) support on the physical servers.
The halfway point
VMware did some nice things in this combo dot-five release but could have taken it further. There are still plenty of issues with VI3 that haven't been addressed, not the least of which are the truly obtuse error reporting and logging mechanisms. In one instance, trying to create a RDM (Raw Device Mapping) for a VM to directly interface with an iSCSI LUN would continually fail at the last step with a "General Error" statement that was thoroughly unhelpful. It turns out that the nature of RDM mappings require that pointer files be created on a VMFS file system that reference the iSCSI LUN mapped to the host. If the datastore in use happened to be NFS, then RDM pointers can't be created, and thus can't be used.
Seeing an error message with that information anywhere along the line would have been extremely helpful.
A number of other common functions still need work. For instance, if you rename a VM in the client, it renames the VM in the display, but it doesn't rename the folders and files related to the VM. Thus, you can't create a VM using the old name. Further, if you migrate the "renamed" VM to another datastore while it's powered off, some of the files get renamed to the new VM name, but some don't -- notably snapshots. In this instance, you're left with a nonfunctional VM after the migration. This seemingly simple step can be highly frustrating, and there's really no excuse for it. Simply renaming a VM shouldn't cause so much trouble.
Networking is still more complex than it perhaps needs to be, with service consoles, VMkernel interfaces, multiple default routes, and so on. It would be nice to see a consolidation of sorts there, with clearer definitions of networking functions and certainly clearer interpretations of commonly used networking terms. Configuring EtherChannel NIC bonding requires navigating a labyrinth of dialog boxes that becomes tiresome very quickly, although the addition of CDP (Cisco Discovery Protocol) support in ESX 3.5 goes a long way toward untying some knots by making it far simpler to identify connected switchports on each ESX host, provided you're using CDP-compliant switches. In some instances, though, this new feature turned up blank even when connected to a Cisco 6509 with CDP enabled. Speaking of networking, one of the more welcome hardware support updates is for selected 10-gigabit cards from Neterion and NetXen.
There are more new features to be found in ESX 3.5, such as IPv6 support for VMs, increases to host logical CPU counts and RAM counts (32 CPUs and 256GB, respectively), and support for as much as 64GB of RAM per VM. VirtualCenter 2.5 is more scalable as well, able to manage as many as 200 ESX hosts and 2,000 VMs. Another welcome improvement to VirtualCenter: VM client tool installations can now be automated on both Linux and Windows, thank you.