VMware vCenter is a required component of a VMware View solution as the View Connection Server interacts with the underlying
Virtual Infrastructure (VI) through vCenter Web Service (typically over port 443). vCenter is also responsible for the complementary components of a View solution provided by VMware vSphere, including vMotion and DRS (used to balance the virtual desktop load on the physical hosts). When a customer purchases View, VMware vCenter is automatically included and does not need to be purchased via a separate stock keeping unit (SKU). In the environments that leverage vSphere for server virtualization, vCenter Server is likely to already exist.
Note
It would not be a good idea to use the same vCenter that manages the servers to manage your View environment.
To ensure a level is set on the capabilities that VMware vCenter Server provides, the key terminologies are listed as follows:
vMotion: This has the ability to live-migrate a running virtual machine from one physical server to another with no downtime.
DRS: This has the vCenter Server capability that balances virtual machines across physical servers participating in the same vCenter Server cluster.
Cluster: This is a collection of physical servers that have access to the same networks and shared storage. The physical servers participating in a vCenter cluster have their resources (for example, CPU, memory, and so on) logically pooled for virtual machine consumption.
HA: This is the vCenter Server capability that protects against the failure of a physical server. HA will power up virtual machines that reside on the failed physical server on available physical servers in the same cluster.
Folder: This is a logical grouping of virtual machines, displayed within the vSphere Client.
vSphere Client: This is the web-based user interface used to connect to vCenter servers (or physical servers running vSphere) for management, monitoring, configuration, and other related tasks.
Resource pool: This is a logical pool of resources (for example, CPU, memory, and so on). The virtual machines (or the groups of virtual machines) residing in the same resource pool will share a predetermined amount of resources.
Designing a View solution often touches on typical server virtualization design concepts such as proper cluster design. Owing to this overlap in design concepts between server virtualization and VDI, many server virtualization engineers apply exactly the same principles from one solution to the other.
The first misstep that a VDI architect can take is that VDI is not server virtualization (it is client OS/desktop virtualization), and should not be treated as such. Server virtualization is the virtualization of server operating systems. While it is true that VDI does use some server virtualization (for example, the connection infrastructure), there are many concepts that are new and critical to understand for success.
The second misstep a VDI architect can make is in understanding the scale of some VDI solutions. For the average server virtualization administrator with no VDI in their environment, they may be tasked with managing a dozen physical servers with a few hundred virtual machines. In comparison, there are View deployments that are close to 60,000 desktops for a single company that go well beyond the limits of a traditional VMware vSphere design.
VDI is often performed on a different scale. The concepts of architectural scaling are covered later in this book, but many of the scaling concepts revolve around the limits of VMware vCenter Server. It should be noted that VMware vCenter Server was originally designed to be the central management point for the enterprise server virtualization environments. While VMware continues to work on its ability to scale, designing around VMware vCenter server will be important.
So why does a VDI architect need VMware vCenter in the first place?
VMware vCenter is the foundation for all virtual machine tasks in a View solution. It includes the following tasks:
VMware vCenter is not used to break the connection of an end device to a vDesktop. Therefore, an outage of VMware vCenter should not impact inbound connections to already-provisioned vDesktops, but it should prevent additional vDesktops from being built, refreshed, or deleted.
Because of vCenter Server's importance in a VDI solution, additional steps are often taken to ensure its availability even beyond the considerations made in a typical server virtualization solution.
Later in this book, we will address the pros and cons of using the existing vCenter Server for an organization's VDI solution, or whether a secondary vCenter Server infrastructure should be built.
View 6 supports virtual appliance-based vCenter Server Appliance (VCSA) deployments that eliminate vCenter dependencies on Windows. VCSA also enhances View deployment flexibility and makes it easier to install and upgrade. The other advantage is the potential Windows license cost reduction.
Now, the question is, would you prefer VCSA or the Windows-based vCenter Server? The answer is… it depends. You still need to have a Windows host for the Update Manager. If you combine vCenter and Update Manager on one Windows host, then you don't gain any licensing advantage. If you are using Windows Datacenter licensing, then the number of Windows-based VMs is not an issue from a licensing perspective. Regarding the database compatibility, the built-in database is suitable for environments with a maximum of 100 hosts and 3000 VMs. If your environment was to grow beyond that, then you have to use Oracle DBMS.
You need to think about these issues, but when they appear in the future, VMware will move away from the Windows-based vCenter. The VCSA could be the right choice if you have to deploy a vSphere environment very fast for a demo or a testing solution. VCSA is the right choice, especially when the size of the environment is not too big.