vNetwork Distributed Switch challenges

Among the new technologies introduced with ESX4, I’m particuarly inpressed with the vNetwork Distributed Switch.  We have chosen to slowly introduce the dvSwitches into our environment and transition VM’s over to these switches.  The distributed switch allows us some new capabilities such as centralized management, individual port assignments, retained state after vMotions, port statistics and improved monitoring, and rate limiting.    That said, the distributed vSwitch has posed some challenges in the transition to it and from a design perspective.

Transition
The transition to the dvSwitches was an unexpected complication.  In vCenter, the port group names, although identical, are presented differently in vCenter.  Because of this, you could not simply VMotion from an ESX3.5 node to ESX4.  As a solution, I decided to make an temporary standard vSwitch on one node of the new ESX4 cluster as the destination for all my vMotions.  Each of my dvSwitches on the ESX4 cluster had two uplinks, so I stole one uplink for each of my temp standard vSwitches.  This allowed me to seemlessly change the network configuration of each VM after it vMotioned from the standard port group to the distributed port group.   Although it was more steps and trouble, it allowed me to make the transition during the day while production workloads stayed online with no impact to them.

Design Considerations
vNetwork Distributed Switch has certainly saved me time, and its only been in my VMware environment a really short time.  I like several things that the distributed switch allows – such as persistent ports, port statistics and the ability to maintain the distributed switch in one place across all nodes in my cluster.  The downside to this centralized administration is an increased dependence on vCenter Server.

Rich Bramley of VM/ETC posted on the challenges of distributed switches with virtualized vCenter instances — largely the problem of a cyclical relationship that could leave you between “the vDS rock and a hard place,” as he puts it.   He and I drew the same conclusions and ultimately, I have decided to keep a mix of distributed and standard vSwitches within my environment.

Perhaps I am overly cautious, however, I run my service console, VMotion, FT Logging all across VMware Standard Switches.  All VM traffic across the vNetwork Distributed Switch.  The exception to the “all VM traffic” rule will be when  if we introduce a virtualized vCenter instance on our cluster.  The dependance on vCenter for dvSwitches and having a virtualized vCenter assigned to a distributed port group makes for a potential disaster, since the VM cannot access or bind to his port on the distributed vSwitch without vCenter running.  Also of note,  Rich reports that vCenter on a distributed switch is NOT supported by VMware because of the cyclical relationship between the two.