Running vCenter as a VM or Physical Server?
As the virtualization has grown more mature during the years, many users has asked me this question, especially users who have just ride on the virtualization journey. There isn't a right or wrong answers however what do you want to achieve at end state. Do you have what you wanted keeping it at the current state?
Let us take look why run the vCenter as physical machine.
- Do not feel comfortable running management server as a virtual machine, prefer all management server as a physical machine
- Uncomfortable to run the vCenter as part of the virtual infrastructure
- Easy to locate the vCenter physical server when required
Why run the vCenter as a virtual machine?
- Able to enjoy protection from VMware Hight Availability
- Able to have DRS perform on vCenter (consider DRS exception or DRS infinity on vCenter)
- Less hardware maintenance and better utilize hardware
- For higher availability, run vCenter Heartbeat however two set of vCenters is required.
So what are the limitations to run on VM?
This will result if you lose your vCenter in your environment.
- Cannot clone, Storage vMotion or vMotion VMs
- Hard to edit virtual hardware properties of all VMs in the environment only able to do so by using the vSphere client connecting directly to the hypervisor and edit the VMs
- Difficult to locate the vCenter/VM, you might have to use the vSphere client to connect to each host to find where it is hosted to power it on (unless you disable vCenter from DRS or set DRS infinity. You can also note down the datastore vCenter reside and browse the datastore from any Host and add it to the host inventory however in vSphere 5, exclude vCenter from Storage DRS if you enable this funtion.)
Summary
Personal preference? I would run vCenter as a VM. Reason are its simple, I can set up the DRS rules to make sure the vCenter is boot up on the specific hosts so I would minimize the problem of not able to locate the vCenter. Maximuize physical resource usage for use to host more VMs.
Still worried, have vCenter Heartbeat as a protection to your vCenter to have availability for your vCenter even due to corruption of OS/Database.
If you run as a physical machine and like to virtualize in the future, you are still given the option to perform a P2V migration on the vCenter as well or use vCenter Heartbeat to have one physical and one as a VM a mixed of both.
In vSphere 5, the vCenter Appliance is a even more concrete of where vCenter is going; as a VM. While the vApp is still new and users can consider running this in their environment, I would recommend to use this in non production environment unless certain limitation from the vApp is not a concern e.g. linked-mode, no plugin like Update Manager, etc.
Read about the other reference from the other practitioners below.
Reference
Best Practices: running vCenter virtual (vSphere)
VirtualCenter, run it on physical or virtual?
Cold Starting a Datacenter
vCenter Appliance
Let us take look why run the vCenter as physical machine.
- Do not feel comfortable running management server as a virtual machine, prefer all management server as a physical machine
- Uncomfortable to run the vCenter as part of the virtual infrastructure
- Easy to locate the vCenter physical server when required
Why run the vCenter as a virtual machine?
- Able to enjoy protection from VMware Hight Availability
- Able to have DRS perform on vCenter (consider DRS exception or DRS infinity on vCenter)
- Less hardware maintenance and better utilize hardware
- For higher availability, run vCenter Heartbeat however two set of vCenters is required.
So what are the limitations to run on VM?
This will result if you lose your vCenter in your environment.
- Cannot clone, Storage vMotion or vMotion VMs
- Hard to edit virtual hardware properties of all VMs in the environment only able to do so by using the vSphere client connecting directly to the hypervisor and edit the VMs
- Difficult to locate the vCenter/VM, you might have to use the vSphere client to connect to each host to find where it is hosted to power it on (unless you disable vCenter from DRS or set DRS infinity. You can also note down the datastore vCenter reside and browse the datastore from any Host and add it to the host inventory however in vSphere 5, exclude vCenter from Storage DRS if you enable this funtion.)
Summary
Personal preference? I would run vCenter as a VM. Reason are its simple, I can set up the DRS rules to make sure the vCenter is boot up on the specific hosts so I would minimize the problem of not able to locate the vCenter. Maximuize physical resource usage for use to host more VMs.
Still worried, have vCenter Heartbeat as a protection to your vCenter to have availability for your vCenter even due to corruption of OS/Database.
If you run as a physical machine and like to virtualize in the future, you are still given the option to perform a P2V migration on the vCenter as well or use vCenter Heartbeat to have one physical and one as a VM a mixed of both.
In vSphere 5, the vCenter Appliance is a even more concrete of where vCenter is going; as a VM. While the vApp is still new and users can consider running this in their environment, I would recommend to use this in non production environment unless certain limitation from the vApp is not a concern e.g. linked-mode, no plugin like Update Manager, etc.
Read about the other reference from the other practitioners below.
Reference
Best Practices: running vCenter virtual (vSphere)
VirtualCenter, run it on physical or virtual?
Cold Starting a Datacenter
vCenter Appliance
Comments