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.

To ensure a level is set on the capabilities that VMware vCenter Server provides, the key terminologies are listed as follows:

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.

View Connection Server is the primary component of a View solution. If VMware vCenter Server is the foundation for managing communication with the virtual infrastructure and the underlying physical servers, then the View Connection Server is the gateway that end users pass through to connect to their vDesktops. In classic VDI terms, it is the VMware's broker that connects end users with desktops (physical or virtual). View Connection Server is the central point of management for the VDI solution and is used to manage almost the entire solution infrastructure. However, there will be times when the architect will need to make considerations for vCenter cluster configurations, as discussed later in this book. In addition, there may be times when the View administrator will need access to the VMware vCenter Server.

The View Manager user interface continues the new look and feel introduced in the previous version. The interface is streamlined and faster. View has also been localized to five different foreign languages (French, German, Japanese, Korean, and Simplified Chinese). The right-click functionality (as shown in the following screenshot) helps to streamline the process of managing desktop pools, entitlements, desktops, context menus, linking to saved View Administrator pages, and enhanced table column viewing. The overall feel continues to be faster and cleaner.

Precreated Active Directory machine accounts

The View Manager has the ability to provision View desktops with precreated Active Directory accounts. This addresses the need of locked-down Active Directory environments that have read-only access policies. Use precreated Active Directory accounts when provisioning View desktops in environments that require read-only access policies in your Active Directory.

This feature is a welcomed addition for companies that wish to create their own Active Directory computer accounts due to security/compliance requirements or because of an automated process used to ensure that Active Directory objects are created when users join the company.

Notice the pre-creation option in the following screenshot:

vCenter and View Composer's advanced settings

Changes to the VMware View UI allow administrators to specify the maximum concurrent number of provisioning and maintenance operations. Previously, only Power and vCenter concurrent operations were available for configuration using this user interface. You could hack into the Active Directory Application Mode (ADAM) and vCenter databases to increase the number of concurrent operations for higher scalability (completed unsupported). It is recommended not to change the default settings in the production environment as it could affect user experience if IOPs or throughput go beyond the limits supported by your storage subsystem.

The following screenshot includes the new options for the maximum concurrent number of provisioning and maintenance operations:

The Phone Home option

Phone Home is an optional (opt-in) choice you make during the installation for anonymous View usage statistics collection. All data is anonymous and untraceable. The phone home will collect information on versions, features used, the system's architecture, and the deployment scale. VMware will use this information to provide better support and more enhancements to popular features. In addition, VMware believes the data collected will allow for better alignment of the View product with R&D priorities and help match the way the customer is actually using View.

You could choose the Send anonymous data to VMware option on the screen, as shown in the following screenshot:

View Agent is a component that is installed on the target desktop, either physical (seldom) or virtual (almost always). View Agent allows the View Connection Server to establish a connection to the desktop. The Remote Experience Agent is integrated with the View Agent. Before this release, the Remote Experience Agent, which contains HTML Access, Unity Touch, Real-Time Audio-Video, and Windows 7 Multimedia Redirection, needed a separate installation. View Agent also provides the following capabilities:

The new Horizon Client is available for Windows, MAC, Ubuntu, iOS, and Android, to allow the connection to an entitled desktop resource. When the Horizon Client is installed on selected endpoint devices, a user can access the virtual desktop sessions from different devices such as smartphones, thin and zero clients, Windows, Macs, iOS, and Android devices. With the Unity Touch feature, the users can run Windows apps much easier on their mobile devices.

In addition to providing the functionality of being able to connect to a desktop, Horizon Client talks to View Agent to perform tasks such as USB redirection and Single Sign-On.

The View administrator can allow users to download the Horizon Client directly from the VMware download center (https://my.vmware.com/web/vmware/info/slug/desktop_end_user_computing/vmware_horizon_view_clients/2_0#drivers_tools).

The administrator can also control the Horizon Client for each user by storing the client software on a local storage device using a Horizon portal.

The components covered earlier in this chapter belong to the set of mandatory components in a View solution. The major component that is optional in a View solution is the View Composer. It should be noted that when some third-party solutions such as Unidesk or storage-based cloning are used in conjunction with View, View Composer is not used. This is because solutions such as Unidesk or storage-based cloning have their own approach for handling mass provisioning of vDesktops.

View Composer is used in majority of View-based solutions today, but there are valid scenarios and solutions that do not require the use of View Composer. As this book focuses on VMware View solutions and not View with third-party components, View Composer will be discussed heavily throughout this book.

A snapshot saves a point-in-time state of a given virtual machine. Changes beyond the snapshot of the point-in-time state are written to a delta disk while the original virtual disk (.vmdk) is marked as read-only. This preserves the point-in-time state of the virtual machine until the snapshot is deleted by an administrator. Multiple snapshots of a given virtual machine can be taken, and it is these point-in-time snapshots that are used as the basis for View Composer linked clones.

A linked clone is a copy of a virtual machine based on a specific snapshot of that virtual machine (known as the parent). When a linked clone pool is created, View Composer creates a replica.

A replica is the original read-only base virtual machine disk merged with a specific point-in-time snapshot chosen to be the point of deployment for a given View desktop pool. Replicas are always thin-provisioned.

A View desktop pool can only point to one specific snapshot at a time, but this can be changed easily through techniques discussed later in this book. A virtual machine can have multiple snapshots; thus, a single virtual machine with multiple snapshots could be the foundation for all the View desktop pools in an environment. This allows each pool to be based off of their own (or the same) point-in-time snapshot. This is possible because View desktop pools using the linked clone technology do not actually use the base virtual machine snapshots; instead, they use a replica (base virtual machine plus snapshot).

While linked clones are based off of an original parent VM, each linked clone still has a unique name, Media Access Control (MAC) address, and a virtual machine Universal Unique Identifier (UUID).

The preceding figure illustrates a parent virtual machine with three snapshots (Snap 1, Snap 2, and Snap 3). Each snapshot represents a different point-in-time of the virtual machine. For example, the Snap 1 snapshot may have Office 2007 installed, the Snap 2 snapshot may have Office 2010 installed, and the Snap 3 snapshot may have Office 2010 and Visio 2010 installed. In this example, the Snap 2 snapshot was chosen for virtual desktop deployment. Once this snapshot has been selected and the desktop pool has been enabled for provisioning, a replica is created. The replica does not copy the other Snap 1 or Snap 3 snapshot states.

The use of a replica that preserves the original parent vDesktop's snapshot state allows the parent vDesktop to be powered on, patched, or altered without impacting the state of the vDesktop using the replica. Again, this is because the replica is a copy of a parent vDesktop's snapshot and not the actual parent vDesktop itself.

View Composer uses the linked clone technology. A virtual desktop using this technology contains a pointer to a replica of the original gold snapshot. To clarify, the pointer is not pointing to the original (parent) vDesktop but to an exact copy (replica) of the parent vDesktop from a specific point in time. View Composer uses this technology so that each vDesktop doesn't need its own full-sized virtual disk. The pointer uses the replica only for read-only access and writes all changes to a secondary disk, called the delta disk.

Delta disks can be viewed as a change of record. Instead of defiling a gold snapshot, all changes (deltas) to the original disk are recorded outside of the gold snapshot to the delta disk. This leaves the original gold snapshot in pristine condition while still ensuring a usable operating system that accepts changes made by the user and other applications.

There are several types of disks—OS disk, secondary OS disk, user data disk, and temp data disk.

Many options of disk types and redirection

The following is a list of the available options of the disk types and the redirection:

• OS disk: For an OS disk, there are following options:
  • Linked clones (1)
  • Full clones (2)
• User data: For a user data disk, there are following options:
  • OS disk (3)
  • Persistent disk (4)
• Temp data: For a temp data disk, there are following options:
  • OS disk (5)
  • Non-persistent disk (6)

The following figure illustrates the preceding disk types and their redirection. Note that the secondary OS disk is not illustrated as it is not a configurable option within View.

Actions for linked clones – Reset, Refresh, Recompose, and Rebalance

When using linked clones, there are several actions that can be performed on the clones themselves. These actions are discussed in the following sections.

Reset

The Reset action is equivalent to hitting the Reset button on a virtual machine. This is an ungraceful restart of a virtual machine that is equivalent to pulling the power cable out of a desktop and then plugging it back in.

Refresh

The Refresh action is an action that resets the delta disk back to its original state. An OS delta disk bloat can happen as a user continues to write changes to their delta disk over time. Data inside the OS delta disk is lost during a Refresh action.

Note

The Refresh option is only available when using the persistent and automated linked clone desktop pools. During this action, data (for example, user data) can potentially be lost if it is not redirected elsewhere (for example, a non-persistent disk).

Recompose

The Recompose action is an action that is used to change the snapshot and/or a parent VM that is used by the desktop pool. In the following figure, number 1 is the original mapping to a base snapshot, and number 2 represents the available options during a Recompose action.

Administrators can use the Recompose action in the following scenarios:

• To change the linked clone pool to use a different snapshot (for example, Snapshot_B) of the original parent (for example, ParentVM_1) instead of the current one in use
• To change the linked clone pool to use a snapshot (for example, Snapshot_A) of a different parent (for example, ParentVM_2) instead of the current parent in use

Note

The Recompose option is only available when using the persistent and automated linked clone desktop pools.

Rebalance

The Rebalance action is an action that will evenly distribute desktops across all of the available data stores in the desktop pool. The desktop must be in the ready, error, or customizing state (with no pending tasks or cancellations) to be rebalanced.

A Rebalance action automatically executes the Refresh action on the desktop as well, which resets the OS disk back to its original state.

During a Rebalance action, the administrator can set whether to rebalance the desktop once the users log off of their desktop or to force all of the active users to log off.

The Rebalance action is also the only supported way to move linked clones to a new data store.

VCAI leverages the native cloning abilities in a storage array to offload the storage operations within the View environment. This option improves provisioning speeds and the management regarding View Composer along with offering another solution to customers who want to leverage their other storage options.

The feature allows the creation of linked clones to be offloaded to the storage array. VCAI expands the capability to deliver faster provisioning of View pools and proper alignment of linked clones on your storage array. It allows you to use Array Native Clones with View deployments on most NAS storage solutions such as NexentaConnect View Edition and Hitachi NAS 4000 Series. This means that the array takes over the creation of the clones and relieves the CPU on the vSphere server.

The new VMware Horizon View is available in three editions: View Standard, Advanced, and Enterprise. All three editions include all components needed for a comprehensive virtual desktop solution. The following table shows the editions and their components for both named users and concurrent users (CCU):

This chapter has provided a solid introduction to the components of a VMware View VDI solution, including VMware vSphere fundamentals. Without an understanding of the basic concepts of the View architecture as well as the underlying VMware vSphere architecture, it will be very difficult to build a proper View solution. For additional reading on either View or VMware vSphere, please refer to the administration, evaluation, and installation guides from VMware on the desired product set (https://www.vmware.com/support/pubs/view_pubs.html).

This chapter reviewed the components that make up the View environment and highlighted some of the new features of version 6 along with the new edition purchasing options.

The next chapter will cover how to collect an organization's inputs to ensure that a VMware View design meets the requirements for success. Collecting the requirements is a phase many VDI architects either skip or do in haste, resulting in a less-than-ideal end product. Once a VDI architect has performed several discovery engagements with an organization, it is certainly possible that he simply asks the likely pitfall questions (for example, "Will you be using a bidirectional audio?"), but until this level of comfort has been reached, performing a full discovery is advised.