vCenter server on VM – good practice

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:

  1. 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 patchingmanual vMotion out of host where VM run[/box]
  2. 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.
  3. 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.
  4. 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]
  5. 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”]

Artur Krzywdzinski

Artur is Consulting Architect at Nutanix. He has been using, designing and deploying VMware based solutions since 2005 and Microsoft since 2012. He specialize in designing and implementing private and hybrid cloud solution based on VMware and Microsoft software stacks, datacenter migrations and transformation, disaster avoidance. Artur has been in IT industry since 1999 and consulting since 2008. Artur holds VMware Certified Design Expert certification (VCDX #077).

  • 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

    • czesc Marek,
      thanks for comment
      well, you are right, but instead excluding vCenter VM from DRS is possible to create VM to host affinity rule with “Should run on specific host” . I will update post in near feature

      thanks to @vcdxnz001
      Artur

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

    • Shares don’t give a VM any kind of guarantee to compute resource whereas reservations do – shares are used to prioritise under periods of contention. Allocating a reservation to a resource pool without then allocating a reservation to the VMs inside that resource pool achieves nothing with regards to those VMs – the VMs would still have no reservation/guarantee to any compute resource.