Since vCenter Server 2.0 was released, VMware has supported running vCenter as a virtual machine. Administrators,...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
architects and consultants around the world have been making their cases for running vCenter either on a physical machine or on the virtual appliance.
I'm all for running vCenter on a virtual machine (VM); in fact, I'll go one step further and recommend that people run the vCenter Server Appliance (vCSA). If you've ever been through a vCenter installation on Windows, you will appreciate the ease of setup of the vCSA. Components such as single sign-on, Web Client and Inventory services are configured and started with the click of a button. If you are just starting out -- or even thinking of migrating to a virtualized vCenter -- I would recommend taking a very close look at the vCSA to see if it suits your needs.
There are many reasons to run a virtualized vCenter, vCSA or not. For one, you can place vCenter inside of an HA-enabled cluster; if a host fails, HA will automatically restart vCenter. In terms of scalability, you can take advantage of vSphere's hot-add CPU and memory features. Granting more memory or CPU in a virtual instance of vCenter is much faster and requires less downtime than it would in the physical world. When maintenance and patch time comes around, vCenter is able to vMotion itself between hosts, as well as utilize Storage vMotion to move between data stores. You can also take, revert and delete snapshots of a virtualized vCenter -- something that isn't feasible in a physical deployment.
But what if vCenter isn't available? How will your hosts and VMs react without the management plane? Below are many of the common misconceptions that I've seen throughout the years.
I won't be able to manage my hosts if vCenter is unavailable.
Yes, of course you will! Just as you use the vSphere Client to connect to vCenter, you can also use it to connect directly to a host. From here, you can access the console and perform limited foundational operations on your hosts. Of course, I would concentrate on getting my vCenter instance up and running before making any major changes, but you can still manage hosts without vCenter.
I won't be able to manage my VMs if vCenter is unavailable.
It may be possible. While you can always gain access to your VM consoles and perform power operations, other operations, such as editing VM hardware, may not be available. In the past, it's been possible to perform all operations on VMs without vCenter, but with the introduction of hardware version 10 in vSphere 5.5, some operations are not possible without utilizing the vSphere Web Client, which in a lot of scenarios is installed on the same server as vCenter. That said, in most situations, being able to access the hosts directly to simply power on the vCenter Server is often enough to get you through.
HA cannot restart VMs without vCenter.
This is false. HA does require vCenter for the initial setup, but after that the dependencies, configuration and heartbeating all reside on the individual hosts. With vCenter out of the picture, you can still depend on HA to restart your VMs, and even the vCenter Server itself can participate in HA restarts.
My VMs will lose network connectivity if utilizing dvSwitches.
Again, this is false. The control plane of a distributed switch containing all of the configuration information does reside on vCenter, but the data plane -- the connections to the actual networks -- reside on both the vCenter and the ESXi hosts themselves. Therefore, if we lose our vCenter Server, our VMs can still access the respective networks, even if they have been restarted by HA. Note that some port-group operations, such as assigning a VM to a new port, may not be available without vCenter and our control plane being online, leaving us with the option to remap that specific VM to a standard switch.
OK, sounds great, let's virtualize it.
At this point, if I have debunked enough myths around virtualizing vCenter that you've decided to go ahead, then I've done my job. Well, not quite! As with any production-tier application that we virtualize, there are always some gotchas and fine details that we need to pay attention to, and virtualizing vCenter is no different
First, you need to know what won't be available if you happen to lose the vCenter Server. Without access to vCenter, any operations relating to DRS or resource pools become unavailable. All of these operations require vCenter to be available and functioning properly. Any template operations will not be possible, and you will not be able to perform any vMotion or Storage vMotions within the environment until you get vCenter back.
Keeping tabs on the virtualized vCenter
How can you mitigate some of the risk of not having these functions? Connecting directly to a host to fix and power on vCenter could be the final solution, but this can turn out to be somewhat time-consuming, especially in a large environment. Say you had 200 hosts; connecting to each one individually and looking for your vCenter Server can be quite cumbersome. One way to help is to utilize DRS affinity rules. Affinity rules can dictate which host(s) you want certain VMs to remain on, rather than having DRS migrate them off in its normal operations. My recommendation for a large environment would be to set up an affinity rule dictating that your vCenter Server should remain on a certain host and document which host that is, thus making the discovery process quicker when you go looking.
Another possible issue is hardware version 10. We've seen new features of vSphere 5.5 implemented only inside of the Web Client and with that, the inability to edit VMs with hardware version 10 in the Windows desktop client. This, coupled with installing the Web Client on the same server as your vCenter instance, can pose significant risk to our environment, especially if you have upgraded your VM to version 10. Say you've upgraded the VM that hosts our vCenter and Web Client components to version 10 and a change in hardware is required to get that VM up and running. You will not be able to edit the settings of that VM without the Web Client being up -- kind of a Catch-22 situation! There are workarounds dealing with the downgrade to version 9, but officially the vCSA comes preconfigured with version 9 and the documentation specifically states to not upgrade to version 10. Certainly leave your vCenter and Web Client instances running version 9 until we see a new direct-host connection component released by VMware.
With all that said -- I'd still go ahead and virtualize
The debates for vCenter being physical or virtual have been going for quite some time, and I'm sure they will continue throughout further releases of vSphere. If you do decide to virtualize vCenter, be sure to keep some of the above situations in mind.
As always, you should have a solid backup/business continuity DR plan that references how to recover from a vCenter failure whether it be physical or virtual. (Image-level backups can be performed on a virtual vCenter Server with much more ease). VCenter Server can easily be virtualized and, in my opinion, the benefits of running virtual far outweigh the risk involved. If budgets permit, consider implementing vCenter in its own management cluster that is segregated from your production environment. By keeping the above precautions in mind, you can have your vCenter Server running on the same environment it manages.