VMware ESX Server 3.5

The other major feature addition is Storage VMotion. Traditional VMotion required that the host servers be connected to the same shared storage, be that iSCSI, NFS, or Fibre Channel, and when a VM transitioned from one physical host server to another, the storage remained in the same location -- only the VM's RAM footprint and network connections were moved. Storage VMotion moves everything from one host to another, including the disk. As with traditional VMotion, this happens live, without rebooting the VM.

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 IPM (Intelligent Platform Management) 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 non-functional 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.