Since vSphere 5.1 I have heard many advises that it is better to have a physical vCenter due to its enormous resource requirements. In the last years I had many discussions on that topics and it turned out that most people are just afraid because of this "chicken and egg" situation. Technical arguments are mostly related to dvSwitch issues or resource worries. In the following post I'll cover both sides of the argument.
Short answer: Virtual. The way i see, there is no technical issue that can't be addressed.
What does VMware recommend?
With the release of vSphere 4.1 VMware recommended to install the vCenter inside a virtual machine. There are no further recommendations since vSphere 5.x. VMware best practice guides describe that the vCenter Server can be installed on a physical machine or virtual machine. Both is fully supported.
vCenter resource consumption
Having machines with a high resources consumption might prevent you from virtualizing it. The latest vCenter version requires at least 10GB of RAM. Memory requirements are higher if the vCenter Server database is on the same machine, which is not bad practice. It is not unusual to see vCenters servers with 16, 24 or 32GB of RAM. Compared to that, a common ESXi hosts has between 64GB and 512GB of RAM. From that perspective, resource consumption is no reason to use a physical server.
Separation of duties
Your company might have a separation of duties policy which prevents you from installing a management system as part of the managed environment itself. That does not explicitly denies you from virtualizing it, as you can install it on a single ESXi host, but this means that some features like VMware HA are not available for the vCenter virtual machine.
Eating your own dog food
I, as a virtualization admin, always state that you can virtualize everything. As of today, we are close to virtualize not only servers but also firewalls, load balancers, routers, switches and storages. How can i say that you should virtualize all critical applications but not the vCenter Server? You should believe in the product and use it.
The chicken or the egg
The chicken or the egg causality dilemma is commonly asked question: "Which came first, the chicken or the egg?". This analogy might be valid for a vCenter as virtual machine. The vCenter belongs to the platform which it is managing, so how can you install it without having it? Another problem might come up when you complete platform goes down due to a power outage? I do not really see a problem in both cases. I usually install the first ESXi Host, install the vCenter on that host, create a Host Profile and everything else happens automatically. When the whole platform or the vCenter VM goes down, you could check an previously configured inventory list to see where it was running. Another possible solution could be to pin the vCenter to known ESXi Host with affinity rules.
One problem that might came up in vSphere 5.1 was when you want to restore the vCenter virtual machine with VMware vCenter Data Protection (VDP). You need the vCenter to restore it, so you are screwed up in that situation. This issue has been resolved in vSphere 5.5 with the new VDP appliance which can do a emergency restore directely to an ESXi Host.
When you decide to run the vCenter virtual you can take advantages of all virtualization features including but not limited to:
- Server Consolidation
- Redundancy with HA
- Hardware Maintenance
Features like VMware HA are working without the vCenter. You need a vCenter to create a Cluster and activate HA, but it works definitely without it. If the vCenter goes down, the HA agent running on each ESXi Host, is going to restart it.
There is something to know when the vCenter is provisioned with a ports on a dvSwitch. When the vCenter is down and you want to connect to the ESXi host directly you might have a problem because you can not configure a dvPort while the vCenter is down. Usually, everything is fine with dvPortgroups, even when the vCenter goes down. But sometimes you might encounter an inconsistent configuration and the port is not connected. I haven't seen that often, but if you are afraid of that issue you can connect the vCenter and ESXi Management Ports to a standard switch. This circumvents the dvSwitch issue.
All the reasons you mentioned in this article are the reasons I choose virtual. It hasn't been an issue until we had a complete powerdown recently and I ran into the dvSwitch issue. Doing some research brought me to your site.
When doing my installs for customers normally I will keep management networking off the dvSwitch by adding two 1Gb ports and leaving them on a std switch with vCenter.
In my office environment, due to security policies, the DCUI service is disabled and lockdown is enabled, if for whatever reasons, the virtualized vCenter cannot power up, we will need to reinstall the vCenter, because we cannot even troubleshoot the vCenter to start with(due to the lockdown mode).