Before starting vCenter deployment, you need to make sure that all prerequisites and requirements are met.

The vCenter Server hardware requirements are:

JVM heap requirements as well as memory, CPU, and disk requirements for vCenter Server, depending on the size of environment, can be found in the VMware documentation at https://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.install.doc_50%2FGUID-67C4D2A0-10F7-4158-A249-D1B7D7B3BC99.html.

If you choose to use VMware vCenter Server Appliance, make sure you have a host that is running at least Version 4 of ESX or ESXi system.

Hardware requirements for VMware vCenter Server Appliances are listed in the VMware documentation at https://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.install.doc_50%2FGUID-67C4D2A0-10F7-4158-A249-D1B7D7B3BC99.html.

Recommended JVM heap settings for VMware vCenter Server Appliances can also be found in the VMware documentation at https://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.install.doc_50%2FGUID-67C4D2A0-10F7-4158-A249-D1B7D7B3BC99.html.

The vCenter Server software requirements are as follows:

A common VMware vSphere datacenter physical topology is shown in the following figure. It may be useful for better understanding of the different vSphere components and the relationships between them.

There are three interfaces that can be used to manage the vSphere environment and access virtual machines: VMware vSphere Client (vSphere Client), vSphere Web Client for access through a web browser, and vSphere Command-Line Interface (vSphere CLI). They are shown on top of the preceding figure.

Computing servers are shown at the center of the preceding figure. Each computing server is an ESX or ESXi host with one or multiple virtual machines running on it. When there are two or more hosts, they can be grouped into clusters to provide an aggregate set of resources and to take advantage of features such as fault tolerance, high availability, and so on.

Storage networks and arrays are shown at the bottom of the preceding figure. Depending on the environment, there may be Fibre Channel SAN arrays, iSCSI SAN arrays, NAS arrays, or their combinations. Storage arrays are usually connected to computing servers, and in most cases, they are connected through a separate network—Storage Area Network (SAN). This is often referred to as a third network after the management network, and it's also called the network or networks virtual machines are part of.

vCenter Server is shown as a separate physical server. Depending on how your infrastructure was designed, it can also be a virtual server located in one of the server groups. When vCenter is separate, computing servers continue to function in case vCenter Server becomes unreachable and the other way round. If one or few of the computing servers go down, you are still able to manage the rest of the environment using vCenter Server.

There are two approaches to the deployment of vCenter Server: it can be deployed on a virtual server or on a physical server. As an alternative to installing vCenter on your own Windows server, vSphere 5.0 provides VMware vCenter Server Appliance. vCenter Server Appliance is a Linux-based virtual machine configured and optimized for running vCenter Server and its services.

If you choose to use it instead of building a server by yourself, make sure all prerequisites mentioned in the previous section are met, download the appliance, and import it using the Deploy OVF template option from the File menu. The import procedure is straightforward. You can deploy Open Virtualization Format (OVF) with thin provisioning if you are not able or don't want to commit 80 GB to the server.

For vCenter Server Appliance, the default username and password are:

It's important to know that vCenter Server Appliance does not support the following:

The advantages of using virtual machines for vCenter Server are obvious and are listed as follows:

Virtual machines are easier to manage; so, in other words, you get all the advantages related to virtualization while deploying vCenter on a virtual server.

From the other side, running a virtualized vCenter has certain concerns. One of them is ESXi updates when there is only one host in your environment.

To be able to install updates, a host needs to be put into the maintenance mode. The host can't have any VMs running in the maintenance mode; therefore, all VMs need to be turned off or moved off the host. For environments with only one host, administrators have no choice other than turning all VMs off. However, Update Manager is a vCenter plugin, so you will not be able to run or install updates when vCenter Server is not online. In this case, you will have to download and install ESXi updates manually from the server's command-line interface. Many administrators find installing updates manually more time consuming and in certain cases more difficult.

Another concern with virtual vCenter Server is its accessibility in case of issues and failures. For example, if the host where the vCenter Server VM is currently running fails, and for some reason not all VMs were restarted on another host, vCenter Server becomes inaccessible until this host is back online or at least until its connectivity is restored. Thus, the administrator can move the vCenter VM manually to another host. Of course, the administrator can always connect to other hosts directly using vSphere Client; certain features, however, require vCenter, and it may be unacceptable for larger environments to not be able to manage vSphere and other hosts because of one host failure.

The bigger picture is that when you are running vCenter on a virtual machine, any issues with your vSphere environment are affecting vCenter as well. Many administrators will say that this is not desirable as in case of any issues, you still want to manage your environment and diagnose and troubleshoot these issues.