In 9 out of 10 my vSphere 4 or vSphere 5 implementations vCenter server is installed on virtual machine. I’m not going here to write How-To for vCenter server installation but how to configure vCenter server virtual machine, vSphere cluster to make sure that doors (vCenter server) to your kingdom are available and in case of problems you can easily find it and start it or recover it.
There are some general rules which you should follow:
- Exclude virtual machine VM from DRS rules – whatever happen (shutdown, bluescreen etc) you will always know on which ESX(i) host vCenter virtual machine was running and without logging into tens of physical hosts admin start vCenter server VM.
[box type=”warning”] Keep in mind, when you exclude VM from automatic DRS it will affect operations such as:- enter host in maintenance mode – manual vMotion out of host where VM run
- orchestrated upgrade or patching – manual vMotion out of host where VM run[/box]
- enter host in maintenance mode – manual vMotion out of host where VM run
- Setup High Priority restart in VMware HA – in case of physical host failure, where vCenter server was running, HA restarts vCenter VM in a first order.
- DRS affinity rule for vCenter and database VM’s – Keep virtual machines together. In scenario where vCenter database run on different VM than vCenter server, make sure that both – vCenter VM and DB VM always run on the same host. This is very important when you have vDS (Virtual Distributed Switches) deployed, all vDS settings are kept in vCenter DB and when admin change vDS settings, first change is stored to vCenter DB, secondly vCenter send update to ESX(i) hosts. If, for any reason during sending update to ESX(i) hosts vCenter server lose communication to vCenter DB you might get into trouble with networking misconfiguration on some of ESX(i) hosts. Setting up affinity rule significantly decreased risk.
- Reserve resources – reserve resources for vCenter server VM and vCenter DB VM if exists. The easiest way to make sure that VM has always high priority to compute resources is use resource pools with HIGH shares and add VM’s to it. If for any reason you don’t use resource pools setup shares (RAM and CPU) to HIGH in resource tab (edit virtual machine settings) or use CPU and RAM reservation.
[box type=”warning”] If you choose to use per VM resource reservation (CPU and RAM) it will affect an HA slot size (if you have Admission Control Policy set to Maximum number of failed hosts). HA slot is calculated either based on highest CPU and Memory reservation or (if there is no per VM reservation) – highest memory overhead and 256MHz in vSphere4 or 32MHz in vSphere5. If you would like to avoid problems with slot size change HA Admission Control Policy to Percentage[/box] - Make a clone of your vCenter on a weekly basis – just in case, apart from standard backup keep somewhere a clone of your vCenter VM.
If you have your own good practices which you use in your deployments and would like to share, comment article and I will update my post.
[learn_more caption=”Link Repository”]
- HA Deep Dive – slot size
- Slot size calculation
- Installing vCenter server 5 – Best Practices[/learn_more]
Hi Artur,
I slightly disagree on no.1. I would keep the vCenter on 2 hosts with VM affinity rules, which also implies to no.3 to keep all your vCenter infra together. But this of course depends on the environment and the design.
Overall, good post 🙂
Cheers!
Marek.Z
Why not use a reservation vs shares? If you create a resource pool reservation for each VM it’s doesn’t count against your slot size calculation.