VMware View 5 Desktop Virtualization Solutions

By Jason Langone , Andre Leibovici
    What do you get with a Packt Subscription?

  • Instant access to this title and 7,500+ eBooks & Videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Components of VMware View

About this book

VMware View is a desktop virtualization solution that helps organizations automate desktop and application management, reduce costs, and increase data security through centralization of the desktop environment.

Written by VMware experts Jason Langone and Andre Leibovici, this book is meant as a guide for architects, solution providers, consultants, engineers and anyone planning to design and implement a solution based on VMware View 5. This book will pull information and expertise from real world scenarios so as to maximize practical learning. It will explain the settings and configurations needed to have a successful desktop virtualization solution as well as the ‘why’ behind the decisions.

This book is not meant to replace the official Administration or Installation Guides for VMware View or ThinApp published by the great people at VMware. The material in this book should be used during the design phase, which is before an implementation is underway. All components of a VMware View solution will be covered.

This book uses case studies from the real world including:

  • Hotel Kiosk

VDI solution used in a hotel lobby to provide basic connectivity to its guests

  • Federal agency with classified and unclassified information

VDI used to allow analysts to securely connect to both a classified and unclassified network from the same device

  • Remote Office

VDI used to provide connectivity to offshore developers

  • Out-of-band Scientist

VDI used to provide a secure desktop environment to scientists fighting disease in remote locales

Publication date:
June 2012


Chapter 1. Components of VMware View

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.

Virtual Desktop Infrastructure (VDI), the virtualization of desktop operating systems on server hardware, is another story.

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.


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

Introduction to View Composer

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


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.



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.

About the Authors

  • Jason Langone

    Jason Langone (@langonej) has been involved in VMware solutions for over seven years and has designed and implemented solutions around the world. Langone has a long history of designing VMware-based tools (for example, V-Moses and ESX Recovery Center), as well as designing robust solutions for enterprise customers. Langone spoke at VMWorld 2006 and won a VMware Vanguard Award in 2007 for Best DR Solution. He is a VMware Certified Design Expert (VCDX), a VMware vExpert, and a VMware Certified Professional (VCP). In addition, Langone has been involved in some of the largest VDI deployments from the Middle East to deployable solutions in the US. Langone maintains a blog dedicated to virtualization and cloud computing at www.ThinkVIRT.com

    Browse publications by this author
  • Andre Leibovici

    Andre Leibovici (@andreleibovici) is a leading expert in the current area of virtualization and End User Computing and maintains an award-winning and world-recognized blog. For the last 10 years, his passion and dedication around virtualization and End User Computing has helped many organizations while working for VMware Professional Services, EMC Virtualization Team (vSpecialists), and through creating professional blogging resources. His expertise is backed by more than 20 years industry experience managing IT infrastructures for large organizations. Andre's blog http://myvirtualcloud.net is recognized as one of the industry leading technical VDI blogs with more than 1.5 million views every month. Based on his field experience, he developed a number of free tools to help beginners and advanced architects to appropriately size and architect VDI solutions. Those tools include the VMware View Online Calculator, the XenDesktop Online Calculator, and the Display Protocol Online Calculator. His passion for End User Computing led him to find the APAC Virtualization Podcast and speak at conferences such as the Brazil vForum 2011, Las Vegas VMworld 2011, and the Sydney vForum 2010. Due to his creativity and accomplishments, he received the VMware Virtual Desktop Ingenuity Award 2009 and was recognized as vExpert recipient award for two consecutive years. Degree qualified, Andre also holds VCP 5, VCAP4-DCA, VCAP4-DCD, VCP4-DT, ITIL V3, EMCCA, EMCDCA, and MCSE certifications. He is currently helping to shape the future of End User Computing by working at VMware as an architect in the Office of the CTO and enjoying his work.

    Browse publications by this author
VMware View 5 Desktop Virtualization Solutions
Unlock this book and the full library FREE for 7 days
Start now