Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Some system admin apps like Data Protection Manager can manage/backup an entire virtual infrastructure. When installing such an app, they use SQL Server and Windows Server and thus are run in a VM. But is it a bad idea to run apps like this (which both run on Windows Server and use SQL Server) inside the hypervisor server?

E.g. VMWare vCenter Server is managing to ESX servers, hostnames "a" and "b". Would it be a bad idea to install vCenter Server and its SQL Server in a VM(s) in either "a" or "b"? Or would it need to be installed on a hypervisor outside of these two servers? If I add a HyperV server, with the hostname "c", but this time I am installing Data Protection Manager 2010, I would want to backup both servers "a" and "b", fine, but now also the server where DPM 2010 is sitting on ("c"). How would I get out of this deployment trap? Likewise if DPM or vCenter Server is installed on a physical server...

Apologies for the naivety.


share|improve this question
up vote 8 down vote accepted

I'm a big fan of keeping management infrastructure out of band of the infrastructure under management. This means that if I have an ESX cluster, I want the database server and the Virtual Center server physical, or at least in a completely different VM environment than what it's running. When things go deeply pear-shaped, not being able to get into the management service for ESX can be very bad; otherwise you have to be very versed on command-line and directory navigation on the ESX hosts themselves.

Yes this means more servers, but you're managing the infrastructure from it, so it is worth it. In my opinion.

share|improve this answer
+1 Popped in here to say the same thing. You'd have to make very strong arguments to me for not having your management stuff out of band. – GregD Aug 17 '10 at 20:44
+1, Infrastructure Management, Authentication, Remote Access (VPN), and Backup systems should be separate from Production Infrastructure. – Chris S Aug 17 '10 at 20:46
Can always vSphere directly to the server with vCenter in a pinch though couldn't you? – Kyle Brandt Aug 17 '10 at 20:51
@kyle If your database-server is in your hosed ESX cluster you want as rich a toolset as possible for figuring out WTF is wrong. At least with 3.5, no SQL, no vCenter. The built-in WebUI on the ESX hosts is nice for every-day, not so good for disaster. – sysadmin1138 Aug 17 '10 at 20:57
Agree completely. What you said about things going pear shaped is why I installed AD on physical hardware and not on a HyperV VM (though I was told by a guy in IS to put it on a HyperV VM but the clockdrift and ability to access when HyperV is down meant a big no no). – dotnetdev Aug 17 '10 at 20:57

The idea of having the vCenter physical was a best practice back in the vSphere 3.5 days.

Things have changed.

With vSphere 5.x, VMware recommends installing in a VM.

You get the benefits of vMotion, storage vMotion, VMware HA (high availability) etc.

If you have an outage on your physical server, your management is down until you bring that physical server back up.

If you have an outage of the physical machine that hosts the vCenter VM, then your management is only down until you can bring that VM back up on another host - which is an easy process and will most certainly be faster and easier than restoring a physical host.

In Summary - the benefits of virtualization apply to the management pieces as well.

Virtualize your vCenter without fear!

Jim Nickel VCP/VCP-DT

share|improve this answer

I can't answer your DPM question, but installing vCenter Server in a VM will work fine and is done quite often. Since you'll be using vCenter to manage all the hypervisors and VMs you should make sure you can access the ESX host directly via vSphere Client, just in case the vCenter VM doesn't work properly or boot up.

I would put vCenter on your first host and keep it there so you don't have to search for it in case of problems. You don't want DRS to automigrate the vCenter VM to another host, since you may need to blindly find it in case of trouble.

Look at your SQL and Active Directory dependencies since you may need those for vCenter to run.

Also, create an admin user on all ESX hosts, so you can still access the host directly with the VI Client even if lockdown mode is enabled (lockdown mode disables direct access for the 'root' account).

Of course if you can afford to, keeping the management tools separate from their targets will reduce your chances of trouble. So do a cost-benefits analysis.

share|improve this answer
Is it a bad idea? Well, it depends. :) As others have mentioned, it is a supported solution by VMWare. my opinion: if you do not have shared storage and multiple hosts, don't do it for the many reasons already mentioned. If you do have multiple hosts with shared data pools, it becomes a more interesting question. Running it in ESX would allow you a manual pseudo-HA ability in that if the host running your vCenter failed, you could connect your vSphere client directly to another host and manually start your SQL/vCenter up on that other host and get things back up fairly quickly. – Rex Aug 18 '10 at 0:45

vCenter is supported as a VM, so even though there's a school of thought to keep it separate, it can certainly be kept in the VM environment. I'd suggest that the vCenter server is a good candidate for a fault-tolerant configuration. This way, if you lose the main vCenter host, vCenter would keep running on another host. This assumes, of course, you have a version of VMware licensed to support Fault-Tolerant mode...

share|improve this answer

The problem on running vCenter as a VM on a machine that it manages, is that if that host fails (power supply, Motherboard, etc) then there is now no vCenter server to bring that VM back online.

The same goes for if you have a total power outage. Until vCenter is online is won't be auto-starting any VMs.

The same is true in a Hyper-V world as you have to have a physical domain controller so that Hyper-V and the cluster can start (which require a DC).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.