VMware View 5 Desktop Virtualization

Core components of VMware View

This book assumes a familiarity with server virtualization, more specifically, VMware vSphere (sometimes referred to as ESX by industry graybeards). Therefore, this article will focus on:

  • The VMware vCenter Server
  • The types of View Connection Server
  • Agent and client software

vCenter Server

VMware vCenter is a required component of a VMware View solution. This is because 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 VMware View solution provided by the underlying VMware vSphere, including VMotion and DRS (used to balance the virtual desktop load on the physical hosts). When an end customer purchases VMware View bundles, VMware vCenter is automatically included and does not need to be purchased via a separate Stock Keeping Unit (SKU). In the environments leveraging vSphere for server virtualization, vCenter Server is likely to already exist. To ensure a level set on the capabilities that VMware vCenter Server provides, the key terminologies are listed as follows:

  • vMotion: It is the ability to live migrate a running virtual machine from one physical server to another with no downtime.
  • DRS: It is the vCenter Server capability that balances virtual machines across physical servers participating in the same vCenter Server cluster.
  • Cluster: It 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: It 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: It is a logical grouping of virtual machines, displayed within the vSphere Client.
  • vSphere Client: It is the client-side software used to connect to vCenter Servers (or physical servers running vSphere) for management, monitoring, configuration, and other related tasks.
  • Resource pool: It 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 VMware View solution often touches on typical server virtualization design concepts such as the 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 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 the connection infrastructure, for example), 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 pure scale of some VDI solutions. For the average server virtualization administrator with no VDI in their environment, he/she may be tasked with managing a dozen physical servers with a few hundred virtual machines. The authors of this book have been involved in VDI solutions involving tens of thousands of vDesktops, 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 do we need VMware vCenter in the first place, for the VDI architect?

VMware vCenter is the gateway for all virtual machine tasks in a VMware View solution. This includes the following tasks:

  • The creation of virtual machine folders to organize vDesktops
  • The creation of resource pools to segregate physical resources for different groups of vDesktops
  • The creation of vDesktops
  • The creation of snapshots

VMware vCenter is not used to broker the connection of an end device to a vDesktop. Therefore, an outage of VMware vCenter should not impact inbound connections to already-provisioned vDesktops as it will 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, there is a question asking whether an incumbent vCenter Server should be used for an organization's VDI or whether a secondary vCenter Server infrastructure should be built.

View Connection Server

View Connection Server is the primary component of a VMware View solution; if VMware vCenter Server is the gateway for management communication to the virtual infrastructure and the underlying physical servers, the VMware View Connection Server is the gateway that end users pass through to connect to their vDesktop. In classic VDI terms, it is VMware's broker that connects end users with workspaces (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 to vCenter cluster configurations, as discussed later in this book. In addition, there may be times when the VMware View administrator will need access to the vCenter Server.

The types of VMware View Connection Servers

There are several options available when installing the VMware View Connection Server. Therefore, it is important to understand the different types of View Connection Servers and the role they play in a given VDI solution.

Following are the three configurations in which View Connection Server can be installed:

  • Full: This option installs all the components of View Connection Server, including a fresh Lightweight Directory Access Protocol (LDAP) instance.
  • Security: This option installs only the necessary components for the View Connection portal. View Security Servers do not need to belong to an Active Directory domain (unlike the View Connection Server) as they do not access any authentication components (for example, Active Directory).
  • Replica: This option creates a replica of an existing View Connection Server instance for load balancing or high availability purposes. The authentication/ LDAP configuration is copied from the existing View Connection Server.

Our goal is to design the solutions that are highly available for our end customers. Therefore, all the designs will leverage two or more View Connection Servers (for example, one Full and one Replica).

The following services are installed during a Full installation of View Connection Server:

  • VMware View Connection Server
  • VMware View Framework Component
  • VMware View Message Bus Component
  • VMware View Script Host
  • VMware View Security Gateway Component
  • VMware View Web Component
  • VMware VDMDS

VMware VDMDS provides the LDAP directory services.

View Agent

View Agent is a component that is installed on the target desktop, whether physical (seldom) or virtual (almost always). View Agent allows the View Connection Server to establish a connection to the desktop. View Agent also provides the following capabilities:

  • USB redirection: It is defined as making a USB device—that is connected locally—appear to be connected to vDesktop
  • Single Sign-On (SSO): It is done by using intelligent credential handling, which requires only one secured and successful authentication login request, as opposed to logging in multiple times (for example, at the connection server, vDesktop, and so on)
  • Virtual printing via ThinPrint technology: It is the ability to streamline printer driver management through the use of ThinPrint (OEM)
  • PCoIP connectivity: It is the purpose-built VDI protocol made by Teradici and used by VMware in their VMware View solution
  • Persona management: It is the ability to manage a user profile across an entire desktop landscape; the technology comes via the recovery time objective (RTO) acquisition by VMware
  • View Composer support: It is the ability to use linked clones and thin provisioning to drastically reduce operational efforts in managing a mid-to-large-scale VMware View environment

View Client

View Client is a component that is installed on the end device (for example, the user's laptop). View Client allows the device to connect to a View Connection Server, which then directs the device to an available desktop resource. Following are the two types of View Clients:

  • View Client
  • View Client with Local Mode

These separate versions have their own unique installation bits (only one may be installed at a time). View Client provides all of the functionality needed for an online and connected worker. If Local Mode will be leveraged in the solution, View Client with Local Mode should be installed.

VMware View Local Mode is the ability to securely check out a vDesktop to a local device for use in disconnected scenarios (for example, in the middle of the jungle).

There is roughly an 80 MB difference in the installed packages (View Client with Local Mode being larger). For most scenarios, 80 MB of disk space will not make or break the solution as even flash drives are well beyond an 80 MB threshold.

In addition to providing the functionality of being able to connect to a desktop, View Client talks to View Agent to perform the following tasks:

  • USB redirection
  • Single Sign-On

Optional component—VMware View Composer

The components covered earlier in this article belong to the set of mandatory components in a VMware View solution. The major component that is optional in a VMware View solution is View Composer. It should be noted that when some third- party solutions such as Unidesk or storage-based cloning are used in conjunction with VMware 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 the majority of view-based solutions today, but there are very valid scenarios and solutions that do not require the use of View Composer. As this book focuses on VMware View solutions and not VMware View with third-party components, View Composer will be discussed heavily throughout this book.

Introduction to View Composer

View Composer is the component that manages the deployment of linked clones, described later in this article, for desktop VMs from a single base snapshot.

View Composer is installed on vCenter Servers only.

View Composer also uses a separate database to store the information regarding mapping, deployment, and so on of the linked-clone desktops. This database can reside on the same database server as the existing vCenter database, assuming that it is a supported platform. However, the database itself must be unique to View Composer. This means that the View Composer database cannot use the existing vCenter Server database (but it could use the same server with a separate database instance).

In addition, a separate Open Database Connectivity (ODBC) connection must be set up on the vCenter Servers with the appropriate information for the View Composer database connection.

If View Composer is used, only automatic pool types are supported. Also, the database instance must be unique to View Composer.

Using vCenter's SQL Express Installation for View Composer

Small Proof-of-Concept (PoC) environments may want to leverage the existing SQL Express installation on their VMware vCenter Server. It is possible to leverage the same SQL Express instance as long as a separate database is created. To create a separate database, perform the following steps:

  1. Download and install SQL Server Management Studio Express.
  2. Connect to the vCenter Server instance of SQL Express.
  3. Right-click on the instance name and add a new database (for example, View_Composer).
  4. Configure the ODBC connection and use <vCenter Server>/SQLEXP_VIM for the connection string. Replace <vCenter Server> with the appropriate information for your environment.

Snapshots and linked clones

A snapshot saves a point-in-time state of a given virtual machine. Changes beyond the snapshot of the point-in-time 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 VMware View Composer linked clones.

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, VMware View Composer creates a replica.

The 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 VMware 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 + snapshot).

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

The preceding diagram illustrates a parent virtual machine with three snapshots (Snap1, Snap2, and Snap3). Each snapshot represents a different point in time of the virtual machine. For example, the Snap1 snapshot may have Office 2007 installed; the Snap2 snapshot may have Office 2010 installed; and the Snap3 snapshot may have Office 2010 and Visio 2010 installed. In this example, the Snap2 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 Snap1 or Snap3 snapshot states.

The use of a replica, which preserves the original parent vDesktop's snapshot state, allows the parent vDesktop to be powered on, patched, or altered without impacting on 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.


A template is a virtual machine that has been marked read-only by converting it into a template. A template is simply a virtual machine, which has had its .vmx configuration file converted into a .vmxt configuration file. Virtual machines are read-only virtual machines that are then used for cloning purposes. A virtual machine created from a virtual machine template is a direct copy of the original template. However, customization specifications can be used to alter certain aspects (for example, SID, hostname, IP address, and so on) of the newly created virtual machines. Customization specifications are created by using the Customization Specification Wizard in the vSphere Client when connected to a vCenter Server.

Full provisioning versus linked clones

VMware View has the ability to use both full clones and linked clones. A full clone is a 1:1 independent copy of an existing VM template. This follows the same procedure as deploying a virtual machine from a template in VMware vCenter. A template is selected as the base for the vDesktops and (likely) a customization specification is also chosen.

A vDesktop that has been deployed using full provisioning (for example, think: virtual machine template) does not require access to the original template once it has been built.

A linked clone uses one master VM and then creates a delta disk for each additional VM. The additional VMs have a pointer back to the master VM when they need to talk to their base image (for example, to access the core Windows OS components) but use their delta disk for any unique data for that particular VM or user (for example, ...\Documents and Settings\). A desktop built using the View Composer technology will have read-only access to the replica VM and read/write access to its delta disk.

Full clones are based off of a VM template, whereas linked clones are based off of a VM snapshot.

Types of disks

There are three types of disks—OS Disk, User Data Disk, and Temp Data Disk.

OS Disk

The OS Disk stores the system data (for example, Windows 7) and provides the base for a functional desktop.

Secondary OS Disk

The secondary OS Disk stores OS data that must be preserved during certain View Composer activities (such as Refresh or Recompose). Each virtual desktop will have a secondary OS Disk. These disks are typically 10 MB in size and are not configurable.

The secondary OS Disk can only be stored on the same data store as the OS Disk.

User Data Disk

A persistent User Data Disk is an optional component of a VMware View virtual desktop. The User Data Disk stores user profile information. By storing this information on a persistent disk, View Composer actions such as Refresh and Recompose will not affect the user profile data. The alternative is to store this information inside the OS Disk, which would cause user profile data to be lost during a Refresh or Recompose task.

The size of the User Data Disk is configurable. In addition, the persistent User Data Disk can be stored on the same data store as the OS Disk or on a separate data store.

Temp Data Disk

A non-persistent Temp Data Disk is an optional component of a VMware View virtual desktop. It is also referred to as the disposable disk. The Temp Data Disk stores the OS swap file as well as temporary data that is created during a user session. By storing this information on a non-persistent disk, VMware View will delete all data stored on the disk whenever the virtual desktop is powered off. This can help minimize the growth (in MB) of the virtual desktop as disposable user interaction is discarded and does not become part of the standard OS Disk for each respective user.

The size of the Temp Data Disk is configurable. The Temp Data Disk can only be stored on the same data store as the OS Disk.

Many options of disk types and redirection

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

  • OS Disk
    • Linked clones (1)
    • Full clones (2)
  • User Data
    • OS Disk (3)
    • Persistent disk (4)
  • Temp Data
    • OS Disk (5)
    • Non-persistent disk (6)

The following diagram illustrates the preceding disk types and their redirection:

In the preceding diagram, the secondary OS Disk is not illustrated as it is not a configurable option within VMware View.

Thin provisioning versus thick provisioning

When a virtual disk is created using thin provisioning, the disk only occupies the actual data size on the disk. For example, a virtual disk (.vmdk) that is 20 GB in size but only has 8 GB of data will occupy only 8 GB on the data store. Two virtual desktops that have a 20 GB virtual disk but only 8 GB of data per disk will occupy 16 GB on the data store.

When a VM that is using thin provisioning needs to write new data to the virtual disk (and thereby increase the size of the virtual disk), it does so in the blocks defined by the data store's block size. The data store's block size is defined prior to being formatted in the Virtual Machine File System (VMFS) format. In VMware vSphere 5, the newly created (versus upgraded from vSphere) data stores use a unified block size of 1 MB.

For example, if the VM lives on a 500 GB VMFS-3, which is the data store that was formatted using a 2 MB block size, a 10 MB new write operation will require the write of 5 blocks (10 MB file/2 MB block size), which results in a less efficient use of the overall storage space.

Thin provisioning makes it possible to over-allocate the available storage and can introduce significant issues if not monitored and managed properly.

When a virtual disk is created using thick provisioning (default), the disk occupies its entire allocated size on the disk. For example, a virtual disk that is 20 GB in size but only has 8 GB of data will occupy 20 GB on the data store. Two virtual desktops that have a 20 GB virtual disk but only 8 GB of data per disk will occupy 40 GB on the data store.

View Composer uses linked clone technology. A virtual desktop using this technology contains a pointer back to a replica of the original gold snapshot. To clarify, the pointer is not to the original (parent) vDesktop itself, but 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 for read-only access only and writes all changes to a secondary disk, called the delta disk.

Delta disks can be viewed as a change 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 allowing for a usable operating system that accepts changes made by the user and other applications.

Reset, Refresh, Recompose, and Rebalance actions for linked clones

When using linked clones, there are several actions that can be performed on the clones themselves. These actions are as follows:


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.


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

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


The Recompose action is an action that is used to change the snapshot and/or parent VM that is used by the desktop pool:

In the preceding image, number 1 is the original mapping to a base snapshot, 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

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


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.

Optional component—VMware View Transfer Server

The VMware View Transfer Server is a new component in VMware View since version 4.5. The transfer server's primary role is to deliver the desktop virtual machines from the data center to the end local device for use in an offline scenario. Running a vDesktop locally on the end device is known as Local Mode in VMware View.

The transfer server also manages the repository for the virtual desktops that will be available for Local Mode and provides synchronization capabilities between the local image and the desktop image residing in the data center.

The transfer server cannot be installed alongside any other VMware View component.

The transfer server's repository can live in:

  • A local directory on a local drive
  • Shared access via Universal Naming Convention (UNC)

It is important to ensure that the transfer server's repository does not run out of space. For a point of reference, an average checked out Windows XP image will consume approximately 3 GB in the repository.

Additionally, the transfer server must use the following things:

  • A static IP address
  • The LSI parallel SCSI controller

Checking out

Checking out a virtual desktop is likely the most intensive operation the VMware Transfer Server will perform. The checkout operation involves downloading the entire published virtual desktop image from the View Transfer Server to the local client to be run in Local Mode; the local image is stored in an encrypted format and has a lifetime associated with the image. The checkout operation also places a lock on the virtual desktop to ensure that future inbound requests to the desktop from connecting to the instance running within the virtual infrastructure are prohibited:

Due to the network bandwidth used (copying gigabytes of data), the checkout process should be performed when the end device is on the same LAN as the VDI. Performing a checkout process over a 3G hotspot could take hours or even an entire day, depending on the size of the vDesktop infrastructure.

Checking in

Checking in to a virtual desktop involves uploading the delta data and configurations to the VMware View vDesktop via the View Transfer Server. This data resides on the OS Disk and the User Data Disk (if it exists). The local copy of the base image is not uploaded as it has not been changed. The lock on the virtual desktop is released within the virtual infrastructure and future inbound connections to the desktop are directed to the virtual machine running within the data center (versus redirecting to Local Mode again).


Replication is the process of synchronizing a local vDesktop with its data center peer. Replication only transfers the delta data (changes generated by the user). Replication is managed by a replication policy, which configures settings such as frequency and user deferrals:

If changed user data from a Local Mode vDesktop is viewed as valuable data, it is important that a replication policy is defined with the View Admin console. Otherwise, if replication is not enforced, valuable data could be lost if an end device has a failure.

One of the benefits of VDI in general is the concept of keeping the data in the data center. Local Mode has several use cases (discussed later in this book) but does bring data back to the edge, even if encrypted. Local Mode should be used only in specific use cases and should not be looked at as a typical VMware View solution.


Rollback is one method of removing access to a local desktop that has been checked out (the other method involves removing ownership). It is also possible for an end user to perform a rollback if it is allowed by the policy settings within View:

A rollback performs the following actions:

  • If the user is currently logged into the checked out local desktop, the session is terminated and the user is prohibited from logging back into the local desktop. A new check out task must be performed to restore the Local Mode functionality.
  • If the user is not logged into the checked out local desktop, all future login requests are sent to the instance running in the data center. A new checkout task must be performed to restore the Local Mode functionality.

You've been reading an excerpt of:

VMware View 5 Desktop Virtualization Solutions

Explore Title