Is it a bad idea to install vCenter Server inside a server it manages? If so, why?

Question

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.

Thanks

Answer 1

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.

Answer 2

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.

Answer 3

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...

Answer 4

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).