An ESX host was configured to have a DVS with the right set of physical adapters, virtual switches configured with the right VLAN tags. In order to do maintenance, we moved VMs running database, vCenter VMs and a few others to this host. All of a sudden the VM running vCenter VM froze, nothing seemed to work and VI client became unresponsive. Amusing as it may be, with windows (and since we were doing maintenance), our first line of defense is rebooting the machine. That did not help and the VM was pretty much unresponsive. Logging into the VM console directly from the ESX host and killing vCenter server helped as much, but only to a point where we could click on start menu and really something like windows start up menu would show up. Since this virtual machine was exclusive to vCenter Server for a large scale deployment, having vCenter Server laid to rest did not fit in the grand scheme of things.
Taking a step back, we moved all the VMs to the pre-configured standard vSwitch with the same VLAN tag but with a different vNIC with the visibility in the network identical to that of the newly configured DVS. It was spring time for VC, database and everything came back to life. Little surprise that this prompted a 'scratch your head' reflex action in me and a few others. Moving just the database VM in to the newly configured DVS broke down the VC as we observed it lost the connection to the database.
In order to move virtual machine hosting a vCenter Server is not as straight forward. The classic divide and rule did the trick. We had a spare host with the right DVS configuration. Migrating the virtual machine hosting database to this server's DVS did not disrupt the vCenter Server. The secret is, although the DVS and standard vSwitch are available to the virtual machine's vnic to choose, these two cannot talk to the same VLAN. If we have database and vCenter VMs co-hosted and either of them moves to the DVS, the VC loses its connectivity to the database.
Moving vCenter Server VM to the DVS became a non issue as DVS and standard vSwitch with its VLAN tag had visibility into DVS of the host that hosted the database VM. Now you can keep them separate or move the Database VM back here to co-host with VC or on second thoughts, why fix it when its not broken?
