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