I generally steer people away from virtualizing the Virtual Center.  The reason why is that there is a certian loss of control over a cluster if you loos the Virtual Center, so putting all the eggs in one basket may not be in the best interest.

Even with MS Clustering service I would not virtualize VC. It does protect you against hardware failure, yes. But what about systemwide failure?

What if, for some reason, your VC virtual server refused to power on... due to, let's say... licensing problems? Let's learn something from what happened with VMWare ESX 3.5 Update 2. Will it happen again? Probably not. But probably is not good enough for me. Human errors will continue to pop up and kick you hard when you least expect it. THAT we can at least learn from history. It's a universal truth.

I like to sleep at night. That's why we run VC on a seperate physical server. It takes away the link between ESX failure and VC failure completely!

Imho, you need that safety. If your manager doesn't want to give you the budget for a seperate server, you need to tell him about Update 2. If your VC server was running on a virtual machine then, AND the ESX server went down at the same time, HA would not be able to save you. You would be stuck without VC until the patch was released.

Go physical.

Hi Rick,

You are right, and I should have added that in a non-production environment running VC on VMs is fully allowed. This is also true for a system on a very tight budget and that is non-critical, ie. one that can survive a half day or more downtime. Many production systems cannot survive that long, such as trading platforms, factory production systems, corporate emails, etc.

Every heard of the perfect storm? You can bet that during the Update 2 licensing bug phase, there were ESX servers dropping because of hardware failures at the same time.

Hardware failures on their own were not a problem (MSCS, VMWare HA, etc), and the licensing issue was not a problem unless you had to power on servers during the fault phase. However, if the two unrelated (and "unthinkable") incidents happened at the same time (which you will find out it did for a lot of people last week) you have a serious problem.

If you have a system with a high demand for uptime, a critical system (vmware is now at the CORE of many datacenters), I would not run VC as a virtual server. It just isn't worth the risk, however small, for the small amount of money it costs to have a seperate physical server watching over your VMWare system.

I do, however, acknowledge there are times when running a VC as a VM is perfectly fine.

Kind regards,

Even Glemmestad

We've virtualized VC with no problems. One thing we did to keep it segregated is to put it on a server which we installed ESXi on, which is seperate from our ESX servers.

To me, this is a great solution, especially now that ESXi is free.

Not that this hasn't been aswered in 50 different ways, but my two cents is to NOT do it.  We did and regret it. We are buying a physical box to move this to.  You loose to much control if it virtual.

Perhaps they are assuming you have multiple ESX host.  In that case, you can bring up VC on another functioning host.

True, which we do, but if the ESX server that VC is on goes down, VC goes down, along with whatever else was running on that host. How is VC then supposed to be able to bring those guests in the cluster back up? You can do this manually, but one of the features of VC is that it is supposed to be able to do this automatically, which reduces your downtime.

Edit: Being still new to Virtual Infrastructure, I did not realize that HA could still function while VC is down, but my argument against not recommending this remains the same.

Message was edited by: Michael Unsworth