Virtualization , the technology of abstracting the operating systems from the underlying physical server components, has become a cornerstone of the data center architecture. Virtualization allows organizations to run not just one operating system per physical server in the data center, but tens, dozens, or even hundreds, on a single physical server. The benefits of virtualization are many, including a reduction in hardware, power, and cooling costs. In addition, virtualization allows for new techniques of distribution and resilience to be applied, such as VMware Distributed Resource Scheduler (DRS) and VMware High Availability (HA). Server virtualization, the virtualization of server operating systems on server hardware, is now a mainstream technology, which is readily accepted, adopted, and implemented in organizations across the world.
The reason for the slower adoption of the virtual desktops was originally due to many factors, including an immature technology, lack of general understanding of a comprehensive solution, a proven delivery methodology, and a clear understanding of the success criteria of a given virtual desktop project.
Today, many of these hurdles have been removed. The supporting technologies from communication protocols to computing density, platform stability, and desirable end devices, now exist. Design methodologies have been built by some of the largest integrators in the world; yet virtual desktop projects continue to fail, falter, or stall.
This book will provide the architect, the engineer, the project manager, the freelance consultant, or the contractor, with a proven blueprint for success. More importantly, this book will teach the key success criteria to measure the most important design considerations to make and how to tip the probability of the project's success and sign-off in your favor.
Before these concepts can be covered in depth, it is important to understand the components of a virtual desktop (vDesktop) solution. The technology in this book focuses on VMware View, which is a market leader in VDI. While some concepts in this book apply specifically to VMware View-based solutions, many of the topics will help a VDI architect of any technology plan and build for success.
The VMware vCenter Server
The types of View Connection Server
Agent and client software
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:
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.
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?
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 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.
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:
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 VDMDS provides the LDAP directory services.
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:
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)
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:
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:
The components covered earlier in this chapter 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.
View Composer is the component that manages the deployment of linked clones, described later in this chapter, for desktop VMs from a single base snapshot.
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).
If View Composer is used, only automatic pool types are supported. Also, the database instance must be unique to 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:
Download and install SQL Server Management Studio Express.
Connect to the vCenter Server instance of SQL Express.
Right-click on the instance name and add a new database (for example,
Configure the ODBC connection and use
SQLEXP_VIMfor the connection string. Replace
<vCenter Server>with the appropriate information for your environment.
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.
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 IDentifier (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.
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.
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,
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.
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.
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.
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.
Following is a list of the available options of the disk types and the redirection:
In the preceding diagram, the secondary OS Disk is not illustrated as it is not a configurable option within VMware View.
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.
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.
In the preceding image, number 1 is the original mapping to a base snapshot, number 2 represents the available options during a Recompose action.
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 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.
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's repository can live in:
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:
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 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:
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.
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 VMware View architecture as well as the underlying VMware vSphere architecture, it will be very difficult to build a proper VMware View solution. For additional reading on either VMware View or VMware vSphere, please refer to the Administration, Evaluation, and Installation guides from VMware on the desired product set.
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.
Later in this book, the collected inputs of Chapter 2, Solution Methodology, will be used to produce a working design for an organization.