Installing vCenter in a virtual machine is supported and recommended by VMware:
The advantages of a virtual vCenter are the same for any other virtual machine, however there are concerns on what will happen if vCenter were to drop offline or become unavailable. There are several opinions on this subject. Most of them can be found in this blog entries and the comments that follow:
vCenter survives multiple failures in this blog post by VMware’s Duncan Epping:
vCenter dies in this blog post by Joseph Griffith:
The differences between the two are the specific failure that each experienced/tested and, although not specified, the version of vSphere in the infrastructure. The argument is with the different kinds of ports used in the port groups and where the dVS configuration lives beyond the vCenter database. However, port type may not be the issue, rather how do the hosts and vCenter work together to maintain connectivity?
According to the official VMware Virtual Distributed Switch Whitepaper:
“When provisioned, hosts and virtual machine networks operate independently of vCenter Server. All components required for network switching reside on ESXi hosts. Even if the vCenter system fails, the hosts and virtual machines will still be able to communicate.”
I needed to dive into that last paragraph a little more. First, what information do the hosts actually have locally, in unshared storage?
From Duncan’s blog entry:
Now let’s look at the “basics” first. When an ESXi host boots it will get the data required to recreate the VDS structure locally by reading /etc/vmware/dvsdata.db and from esx.conf. You can view the dvsdata.db file yourself by doing:
net-dvs -f /etc/vmware/dvsdata.db
The dvsdata.db file, when opened in a putty session, reveals information to build the switch with the parameters set by vCenter. However, the port assignments are missing. At this point, the ESXi host can build the switch, but it can’t assign any ports. Now, the host relies on shared storage and the .dvsData folder, which is created in the datastore if one or more virtual machines are using a dVS for network connectivity. In other words, if VM01 in Datastore01 is connected to a dVS with vCenter, a .dvsData folder is created in Datastore01 and all the ESXi hosts connected to Datastore01 can read the file and correctly place VM01 on the dVS after a migration.
Inside the .dvsData folder is the port information: The Name column lists the current ports in use.
So, what happens when a machine is removed from inventory? The ESXi host releases the port and changes the configuration in the .dvsData folder. Here’s a basic before/after:
Before Inventory Removal: The 03 machine is mapped to the port.
After Inventory Removal: The machine entry has been removed and the port is now free. The entry is also removed from the .dvsData folder.
In summary, ESXi hosts can build a switch based on its locally stored information, but will need storage connections to successfully map VMs to a dVS port whether vCenter is available or not.
Now, back to Joseph’s vCenter failure; it looks like he chose to remove the vCenter from inventory and move it to another ESXi host. As we can see from the above, vCenter will be unable to get a network connection because the port assignment has been removed and a new one can only be provisioned by vCenter.
This doesn’t seem to be a Static port problem, just a limitation due to a very specific scenario involving vCenter going offline then being removed from inventory.
Changing the Isolation Response in the HA settings may have helped Joseph out in this scenario; here is a breakdown of the options:
Things get nastier with vCenter 5.5 AND you have VMs on the latest virtual hardware version (vmx-10). Since the ability to manage these machines is limited to the web interface, any scenario where vCenter isn’t available will stop the ability to edit any VM settings. I have been assured by VMware that vSphere 6.0 will give more power to the locally installed vSphere Client.
In a situation where vCenter cannot gain a port to a dVS, the best course of action is to create a vSS, or move a host pNIC from a dVS to a vSS that has access to the production network. Once that is done, edit the .vmx file of the downed vCenter. Change the following entry:
ethernet0.networkName = “the network name on the vSS“
Also, the following entry may help vCenter gain network access once it’s powered on:
ethernet0.startConnected = “TRUE”
From there, power on the vCenter and wait for the web services to start. From the web GUI, change the vCenter’s port group to the dVS that it needs to be on.