How We Tested

High availability, storage and networking capabilities also get a work over.

I used four Intel-based servers, Cisco 3560G switches and an OpenFiler iSCSI storage management system to host a sneak preview copy of VMware vSphere 5.0 for most of August. The two stalwart HP servers, a DL360 G6 and a DL380 G6, were equipped with Nehalem-class Intel Xeon processors. The other systems, a Lenovo RD210 and an Acer AR380 F1, had more advanced Intel processors and more memory, 12GB and 24GB of RAM, respectively.

I started the first round of tests by doing an in-place upgrade of the two HP systems, going from vSphere ESX 4.1 to ESXi 5.0. Migrating the systems was a piece of cake. Where I would have benefited from more planning was in migrating VMware's VMFS (Virtual Machine File System) storage and networking.

The VMFS goes from 3.0 to 5.0 in this release of vSphere. The VMFS 5.0 does away with variable block size formatting by using only 1MB blocks. vSphere 5.0 can use either file system, and further testing and field experience will be needed to make a recommendation about the best approach to use in mixed environments. My tests showed that it is possible to upgrade in place although the process took several steps and a fair amount of reading and planning to get our VMFS 3.0 data stores correctly migrated to VMFS 5.0. The virtualization team will definitely need to involve the storage team in this planning process to ensure a smooth transition.

In a similar, but less successful vein, I also implemented the latest version of the VMware vDS (vSphere Distributed Switch). In the end, I discarded all the existing networking, and implemented the networking from scratch. While it is possible to migrate from vNetwork Standard Switches (a virtual switch created on a single, physical vSphere host) to a vDS, this process takes considerable planning. Further, IT managers will have the greatest chance of success if they start with hosts configured with similar numbers of NICs (network interface cards) and similarly configured standalone Standard Switches.

Note that vDS was introduced in vSphere 4.0. Those already using a vDS will find that it is relatively simple to upgrade the switch. The journey will be considerably more involved for organizations migrating from Standard Switches. I performed various migrations, most where the VMs were shut down and my small number of hosts joined to the vDS, one at a time. It is also possible to use host profiles to transition physical host systems onto the vDS.

The biggest changes in vDS in vSphere 5.0 are the addition of some quite basic network troubleshooting features. I was able to use the newly added network monitor port (a feature of physical switches that coincides with the age of the dinosaurs) to analyze virtual network traffic without needing to route the traffic to an external, physical network.

Adding a monitoring port is an important step in the maturation of the VMware vDS. The old saw that "you can't manage what you can't monitor" holds true: The addition of a monitor port is a significant improvement in the vDS.

Even so, it's clear from my tests that networking is currently an "also-starring" role in vSphere 5.0, playing second fiddle to the first-rate part of creating and managing VMs. Migrating to the vDS and correctly configuring the vDS for production use will require that significant networking expertise be added to the virtualization team. Pooling physical host NICs and configuring profiles to correctly apply policies to these pooled resources was finicky and easily broken when compared with the process of creating and maintaining VMs.