Virtualization, a technology of abstracting the logical capabilities from the underlying physical resources 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 to these, virtualization allows 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 that 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 virtual desktops was originally due to many factors, including an immature technology, cost of storage, 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. Another key hurdle for the adoption of VDI has been the Microsoft VDA licenses, which many consider a desktop tax. 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 tip the probability of the project's success and sign-off in your favor.
This book assumes a familiarity with server virtualization, more specifically, VMware vSphere.
Before these concepts can be covered in depth, it is important to understand the components of a virtual desktop (vDesktop) solution.
Note
The technology in this book focuses on VMware Horizon View 6, 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.
This chapter will review improvements on:
VMware vCenter Server
View Connection Server
View Manager
View Agent
Horizon Client
View Composer
Snapshot and linked clones
Types of disks
View Composer Array Integration (VCAI)
VMware vCenter is a required component of a VMware View solution as the View Connection Server interacts with the underlying
Virtual Infrastructure (VI) through vCenter Web Service (typically over port 443). vCenter is also responsible for the complementary components of a View solution provided by VMware vSphere, including vMotion and DRS (used to balance the virtual desktop load on the physical hosts). When a customer purchases View, VMware vCenter is automatically included and does not need to be purchased via a separate stock keeping unit (SKU). In the environments that leverage vSphere for server virtualization, vCenter Server is likely to already exist.
Note
It would not be a good idea to use the same vCenter that manages the servers to manage your View environment.
To ensure a level is set on the capabilities that VMware vCenter Server provides, the key terminologies are listed as follows:
vMotion: This has the ability to live-migrate a running virtual machine from one physical server to another with no downtime.
DRS: This has the vCenter Server capability that balances virtual machines across physical servers participating in the same vCenter Server cluster.
Cluster: This is a collection of physical servers that have access to the same networks and shared storage. The physical servers participating in a vCenter cluster have their resources (for example, CPU, memory, and so on) logically pooled for virtual machine consumption.
HA: This is the vCenter Server capability that protects against the failure of a physical server. HA will power up virtual machines that reside on the failed physical server on available physical servers in the same cluster.
Folder: This is a logical grouping of virtual machines, displayed within the vSphere Client.
vSphere Client: This is the web-based user interface used to connect to vCenter servers (or physical servers running vSphere) for management, monitoring, configuration, and other related tasks.
Resource pool: This is a logical pool of resources (for example, CPU, memory, and so on). The virtual machines (or the groups of virtual machines) residing in the same resource pool will share a predetermined amount of resources.
Designing a View solution often touches on typical server virtualization design concepts such as proper cluster design. Owing to this overlap in design concepts between server virtualization and VDI, many server virtualization engineers apply exactly the same principles from one solution to the other.
The first misstep that a VDI architect can take is that VDI is not server virtualization (it is client OS/desktop virtualization), and should not be treated as such. Server virtualization is the virtualization of server operating systems. While it is true that VDI does use some server virtualization (for example, the connection infrastructure), there are many concepts that are new and critical to understand for success.
The second misstep a VDI architect can make is in understanding the scale of some VDI solutions. For the average server virtualization administrator with no VDI in their environment, they may be tasked with managing a dozen physical servers with a few hundred virtual machines. In comparison, there are View deployments that are close to 60,000 desktops for a single company that go well beyond the limits of a traditional VMware vSphere design.
VDI is often performed on a different scale. The concepts of architectural scaling are covered later in this book, but many of the scaling concepts revolve around the limits of VMware vCenter Server. It should be noted that VMware vCenter Server was originally designed to be the central management point for the enterprise server virtualization environments. While VMware continues to work on its ability to scale, designing around VMware vCenter server will be important.
So why does a VDI architect need VMware vCenter in the first place?
VMware vCenter is the foundation for all virtual machine tasks in a View solution. It includes the following tasks:
VMware vCenter is not used to break the connection of an end device to a vDesktop. Therefore, an outage of VMware vCenter should not impact inbound connections to already-provisioned vDesktops, but it should prevent additional vDesktops from being built, refreshed, or deleted.
Because of vCenter Server's importance in a VDI solution, additional steps are often taken to ensure its availability even beyond the considerations made in a typical server virtualization solution.
Later in this book, we will address the pros and cons of using the existing vCenter Server for an organization's VDI solution, or whether a secondary vCenter Server infrastructure should be built.
View 6 supports virtual appliance-based vCenter Server Appliance (VCSA) deployments that eliminate vCenter dependencies on Windows. VCSA also enhances View deployment flexibility and makes it easier to install and upgrade. The other advantage is the potential Windows license cost reduction.
Now, the question is, would you prefer VCSA or the Windows-based vCenter Server? The answer is… it depends. You still need to have a Windows host for the Update Manager. If you combine vCenter and Update Manager on one Windows host, then you don't gain any licensing advantage. If you are using Windows Datacenter licensing, then the number of Windows-based VMs is not an issue from a licensing perspective. Regarding the database compatibility, the built-in database is suitable for environments with a maximum of 100 hosts and 3000 VMs. If your environment was to grow beyond that, then you have to use Oracle DBMS.
You need to think about these issues, but when they appear in the future, VMware will move away from the Windows-based vCenter. The VCSA could be the right choice if you have to deploy a vSphere environment very fast for a demo or a testing solution. VCSA is the right choice, especially when the size of the environment is not too big.
View Connection Server is the primary component of a View solution. If VMware vCenter Server is the foundation for managing communication with the virtual infrastructure and the underlying physical servers, then the View Connection Server is the gateway that end users pass through to connect to their vDesktops. In classic VDI terms, it is the VMware's broker that connects end users with desktops (physical or virtual). View Connection Server is the central point of management for the VDI solution and is used to manage almost the entire solution infrastructure. However, there will be times when the architect will need to make considerations for vCenter cluster configurations, as discussed later in this book. In addition, there may be times when the View administrator will need access to the VMware vCenter Server.
There are several options available when installing the 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.
The 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.
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.
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). The Security Server is an instance of the Connection Server that adds a layer of security between the Internet and the internal network. It is located outside the corporate firewall in the DMZ. The Security Server acts as a portal to forward a connection request to the Connection Server.
All the View Connection Server types mentioned can be installed on the following operating systems:
Windows Server 2008 R2—Standard or Enterprise
Windows Server 2008 R2 SP1—Standard or Enterprise
Windows Server 2012 R2
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, which provides the LDAP directory services
The View Manager user interface continues the new look and feel introduced in the previous version. The interface is streamlined and faster. View has also been localized to five different foreign languages (French, German, Japanese, Korean, and Simplified Chinese). The right-click functionality (as shown in the following screenshot) helps to streamline the process of managing desktop pools, entitlements, desktops, context menus, linking to saved View Administrator pages, and enhanced table column viewing. The overall feel continues to be faster and cleaner.
The View Manager has the ability to provision View desktops with precreated Active Directory accounts. This addresses the need of locked-down Active Directory environments that have read-only access policies. Use precreated Active Directory accounts when provisioning View desktops in environments that require read-only access policies in your Active Directory.
This feature is a welcomed addition for companies that wish to create their own Active Directory computer accounts due to security/compliance requirements or because of an automated process used to ensure that Active Directory objects are created when users join the company.
Notice the pre-creation option in the following screenshot:
Changes to the VMware View UI allow administrators to specify the maximum concurrent number of provisioning and maintenance operations. Previously, only Power and vCenter concurrent operations were available for configuration using this user interface. You could hack into the Active Directory Application Mode (ADAM) and vCenter databases to increase the number of concurrent operations for higher scalability (completed unsupported). It is recommended not to change the default settings in the production environment as it could affect user experience if IOPs or throughput go beyond the limits supported by your storage subsystem.
The following screenshot includes the new options for the maximum concurrent number of provisioning and maintenance operations:
Phone Home is an optional (opt-in) choice you make during the installation for anonymous View usage statistics collection. All data is anonymous and untraceable. The phone home will collect information on versions, features used, the system's architecture, and the deployment scale. VMware will use this information to provide better support and more enhancements to popular features. In addition, VMware believes the data collected will allow for better alignment of the View product with R&D priorities and help match the way the customer is actually using View.
You could choose the Send anonymous data to VMware option on the screen, as shown in the following screenshot:
The Feature Packs are fully integrated into the View Connection Server installer and do not require a separate installation. The Feature Packs provide the following features and components:
HTML Access Agent: This allows users to connect to virtual desktops from their HTML 5 web browsers without having the Horizon View Client software installed on their systems. The HTML Access Agent runs on Horizon View desktops, and is the component that enables your users to connect to their desktops using HTML Access. You must install the Remote Experience Agent with the HTML Access Agent on the desktops on which you want to allow HTML Access.
Unity Touch: This enhances the way mobile client (tablets) users access a desktop. Instead of trying to manipulate a full desktop image designed for a keyboard and mouse, on a small device screen, users can browse between apps and documents in a native mobile user interface without seeing the desktop. The Horizon Client documents for mobile devices will provide more information about end user features provided by Unity Touch. With this update, you can now add a favorite application or file from a list of search results and use the Unity Touch sidebar to minimize a running application's window. This requires users to connect to their desktops from Horizon Client for iOS 2.1 or later, or Horizon Client for Android 2.1 or later.
HTML Access installer: This installer configures the View Connection Server instances to allow users to select HTML Access to connect to desktops. After you install HTML Access, the View Portal displays an HTML Access icon in addition to the View Client icon. You must run this installer if you want to use HTML Access to connect to desktops in a Horizon View deployment. Running this installer is also required if your users are using Horizon Workspace and they select HTML Access to connect to the desktops.
Flash URL Redirection: Users can now use Adobe Media Server and multicast to deliver live video events in a VDI environment. To deliver multicast live video streams within the VDI environment, the media stream should be sent directly from the media source to the endpoints and bypass the virtual desktops. The Flash URL Redirection feature supports this capability by intercepting and redirecting the Shock Wave Flash (SWF) file from the virtual desktop directly to the client's endpoint.
Real-Time Audio-Video: This allows View users to run Skype, WebEx, Google Hangouts, and other similar online conferencing applications on their virtual desktops. With Real-Time Audio-Video, the webcam and audio devices that are connected locally to the client system are redirected to the remote desktop. This feature redirects video and audio data to the desktop with a much lower bandwidth than can be achieved by using USB redirection. Real-Time Audio-Video is compatible with standard conferencing applications and supports standard webcams, audio USB devices, and analog audio input.
Note
For information about configuring these settings on Horizon View clients, see Setting Frame Rates and Resolution for Real-Time Audio-Video on Horizon View Clients on VMware KB 2053644.
For information about using this feature with third-party applications, see Guidelines for Using Real-Time Audio-Video with 3rd-Party Applications on Horizon View Desktops on VMware KB 2053754.
For more information about the Feature Pack, go to https://www.vmware.com/support/view52/doc/horizon-view-52-feature-pack-2-release-notes.html.
View Agent is a component that is installed on the target desktop, either physical (seldom) or virtual (almost always). View Agent allows the View Connection Server to establish a connection to the desktop. The Remote Experience Agent is integrated with the View Agent. Before this release, the Remote Experience Agent, which contains HTML Access, Unity Touch, Real-Time Audio-Video, and Windows 7 Multimedia Redirection, needed a separate installation. View Agent also provides the following capabilities:
USB redirection: This is defined as making a USB device, which is connected locally appear to be connected to vDesktop
Single Sign-On (SSO): This is done by using intelligent credential handling that requires only one secured and successful authentication login request, as opposed to logging in multiple times (for example, on the Connection Server, vDesktop, and so on)
Virtual printing via ThinPrint technology: This has the ability to streamline printer-driver management through the use of ThinPrint
PCoIP connectivity: This is the purpose-built VDI protocol made by Teradici and used by VMware in their VMware View solution
Persona management: This 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: This has the ability to use linked clones and thin provisioning to drastically reduce operational efforts in managing a mid-to-large-scale VMware View environment
The new Horizon Client is available for Windows, MAC, Ubuntu, iOS, and Android, to allow the connection to an entitled desktop resource. When the Horizon Client is installed on selected endpoint devices, a user can access the virtual desktop sessions from different devices such as smartphones, thin and zero clients, Windows, Macs, iOS, and Android devices. With the Unity Touch feature, the users can run Windows apps much easier on their mobile devices.
In addition to providing the functionality of being able to connect to a desktop, Horizon Client talks to View Agent to perform tasks such as USB redirection and Single Sign-On.
The View administrator can allow users to download the Horizon Client directly from the VMware download center (https://my.vmware.com/web/vmware/info/slug/desktop_end_user_computing/vmware_horizon_view_clients/2_0#drivers_tools).
The administrator can also control the Horizon Client for each user by storing the client software on a local storage device using a Horizon portal.
The new release of the Horizon Client has improved several features that pertain to the end user experience, as follows:
Expanded Windows Support: Horizon Client now supports the following Microsoft Windows releases:
Windows 8/8.1 Desktop
Windows 7 Desktop
Windows Vista Desktop
Windows XP systems
Unmatched performance: The adaptive capabilities of the PCoIP display protocol are optimized and normally improved with each client release. This is designed to deliver the best user experience, even over low-bandwidth and high-latency connections. Your desktop is faster and more responsive regardless of where you are.
Very simple connectivity: Horizon Client for Windows is tightly integrated with Horizon View for simple setup and connectivity.
Secure from any location: At your desk or away from office, your data is delivered securely to you wherever you are. The SSL/TLS encryption is always used to protect user credentials, and enhanced certificate checking is performed on the client. The View Client for Windows also supports optional RADIUS and RSA SecurID authentication (RADIUS support was added with VMware View 5.1 and View Client for Windows 5.1).
Other improvements with the Horizon Client are focused on Microsoft Lync 2013 and Flash URL redirection. This requires the current version of Horizon Client, which now includes the Remote Experience options, as follows:
Microsoft Lync 2013: This supports use on a remote desktop to allow Unified Communications (UC) VoIP (Voice over IP) and video chat calls with Lync-certified USB audio and video devices. A dedicated IP phone is no longer required. The architecture design requires the installation of the Microsoft Lync 2013 client on the remote desktop, and it uses a Microsoft Lync VDI plugin on the Windows 7 or 8/8.1 client. The Microsoft Lync 2013 client can be used for presence, instant messaging, web conferencing, and Microsoft Office functionalities. When a Lync VoIP or video chat call occurs, the Lync VDI plugin offloads the media processing from the data center server to the client's endpoint, and then encodes all media into Lync-optimized audio and video codecs. This architecture is highly scalable and results in lower network bandwidth. It also provides point-to-point media delivery with support for high-quality and real-time VoIP and video.
Flash URL redirection: Streaming Flash content from Adobe Media Server directly to the client's endpoints reduces the load on the data center's ESXi host. It also removes the extra routing through the data center and reduces the overall bandwidth required to simultaneously stream live video events to multiple clients. The Flash URL redirection feature will use a JavaScript that is embedded inside the web page by a web page administrator. Whenever the virtual desktop user clicks on the selected URL link from within the web page, the JavaScript will intercept and then redirect the Shock Wave File from the virtual desktop to the client's endpoint. The endpoint will open a local VMware Flash Projector outside of the virtual desktop session and then play the media stream locally.
The components covered earlier in this chapter belong to the set of mandatory components in a View solution. The major component that is optional in a View solution is the View Composer. It should be noted that when some third-party solutions such as Unidesk or storage-based cloning are used in conjunction with View, View Composer is not used. This is because solutions such as Unidesk or storage-based cloning have their own approach for handling mass provisioning of vDesktops.
View Composer is used in majority of View-based solutions today, but there are valid scenarios and solutions that do not require the use of View Composer. As this book focuses on VMware View solutions and not View with third-party components, View Composer will be discussed heavily throughout this book.
View Composer is the component responsible for creating linked clones, described later in this chapter, for desktop VMs from a single base snapshot.
View Composer 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. It also can be installed as a standalone server. This move is aimed towards creating a more highly-scalable Horizon View architecture. Another reason to allow the standalone option for View Composer is that you can use the VCSA. Having options is normally a good thing.
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.
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,
View_Composer).Configure the ODBC connection and use
<vCenter Server>/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 state are written to a delta disk while the original virtual disk (.vmdk) is marked as read-only. This preserves the point-in-time state of the virtual machine until the snapshot is deleted by an administrator. Multiple snapshots of a given virtual machine can be taken, and it is these point-in-time snapshots that are used as the basis for View Composer linked clones.
A linked clone is a copy of a virtual machine based on a specific snapshot of that virtual machine (known as the parent). When a linked clone pool is created, View Composer creates a replica.
A replica is the original read-only base virtual machine disk merged with a specific point-in-time snapshot chosen to be the point of deployment for a given View desktop pool. Replicas are always thin-provisioned.
A View desktop pool can only point to one specific snapshot at a time, but this can be changed easily through techniques discussed later in this book. A virtual machine can have multiple snapshots; thus, a single virtual machine with multiple snapshots could be the foundation for all the View desktop pools in an environment. This allows each pool to be based off of their own (or the same) point-in-time snapshot. This is possible because View desktop pools using the linked clone technology do not actually use the base virtual machine snapshots; instead, they use a replica (base virtual machine plus snapshot).
While linked clones are based off of an original parent VM, each linked clone still has a unique name, Media Access Control (MAC) address, and a virtual machine Universal Unique Identifier (UUID).
The preceding figure illustrates a parent virtual machine with three snapshots (Snap 1, Snap 2, and Snap 3). Each snapshot represents a different point-in-time of the virtual machine. For example, the Snap 1 snapshot may have Office 2007 installed, the Snap 2 snapshot may have Office 2010 installed, and the Snap 3 snapshot may have Office 2010 and Visio 2010 installed. In this example, the Snap 2 snapshot was chosen for virtual desktop deployment. Once this snapshot has been selected and the desktop pool has been enabled for provisioning, a replica is created. The replica does not copy the other Snap 1 or Snap 3 snapshot states.
The use of a replica that preserves the original parent vDesktop's snapshot state allows the parent vDesktop to be powered on, patched, or altered without impacting the state of the vDesktop using the replica. Again, this is because the replica is a copy of a parent vDesktop's snapshot and not the actual parent vDesktop itself.
View Composer uses the linked clone technology. A virtual desktop using this technology contains a pointer to a replica of the original gold snapshot. To clarify, the pointer is not pointing to the original (parent) vDesktop but to an exact copy (replica) of the parent vDesktop from a specific point in time. View Composer uses this technology so that each vDesktop doesn't need its own full-sized virtual disk. The pointer uses the replica only for read-only access and writes all changes to a secondary disk, called the delta disk.
Delta disks can be viewed as a change of record. Instead of defiling a gold snapshot, all changes (deltas) to the original disk are recorded outside of the gold snapshot to the delta disk. This leaves the original gold snapshot in pristine condition while still ensuring a usable operating system that accepts changes made by the user and other applications.
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.
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, a 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.
There are several types of disks—OS disk, secondary OS disk, user data disk, and temp data disk.
The OS disk stores the system data (for example, Windows 7) and provides the base for a functional desktop.
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 View virtual desktop. The user data disk stores the 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 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, 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.
The following is a list of the available options of the disk types and the redirection:
The following figure illustrates the preceding disk types and their redirection. Note that the secondary OS disk is not illustrated as it is not a configurable option within View.
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 has only 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 data stores (versus the ones upgraded from vSphere) use a unified block size of 1 MB.
For example, if the VM is located on a 500 GB VMFS-3 block, 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 usage of the overall storage space.
Note
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 has only 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.
When using linked clones, there are several actions that can be performed on the clones themselves. These actions are discussed in the following sections.
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. An OS delta disk bloat can happen as a user continues to write changes to their delta disk over time. Data inside the OS delta disk is lost during a Refresh action.
The Recompose action is an action that is used to change the snapshot and/or a parent VM that is used by the desktop pool. In the following figure, number 1 is the original mapping to a base snapshot, and number 2 represents the available options during a Recompose action.
Administrators can use the Recompose action in the following scenarios:
To change the linked clone pool to use a different snapshot (for example, Snapshot_B) of the original parent (for example, ParentVM_1) instead of the current one in use
To change the linked clone pool to use a snapshot (for example, Snapshot_A) of a different parent (for example, ParentVM_2) instead of the current parent in use
The Rebalance action is an action that will evenly distribute desktops across all of the available data stores in the desktop pool. The desktop must be in the ready, error, or customizing state (with no pending tasks or cancellations) to be rebalanced.
A Rebalance action automatically executes the Refresh action on the desktop as well, which resets the OS disk back to its original state.
During a Rebalance action, the administrator can set whether to rebalance the desktop once the users log off of their desktop or to force all of the active users to log off.
The Rebalance action is also the only supported way to move linked clones to a new data store.
VCAI leverages the native cloning abilities in a storage array to offload the storage operations within the View environment. This option improves provisioning speeds and the management regarding View Composer along with offering another solution to customers who want to leverage their other storage options.
The feature allows the creation of linked clones to be offloaded to the storage array. VCAI expands the capability to deliver faster provisioning of View pools and proper alignment of linked clones on your storage array. It allows you to use Array Native Clones with View deployments on most NAS storage solutions such as NexentaConnect View Edition and Hitachi NAS 4000 Series. This means that the array takes over the creation of the clones and relieves the CPU on the vSphere server.
The new VMware Horizon View is available in three editions: View Standard, Advanced, and Enterprise. All three editions include all components needed for a comprehensive virtual desktop solution. The following table shows the editions and their components for both named users and concurrent users (CCU):
This chapter has provided a solid introduction to the components of a VMware View VDI solution, including VMware vSphere fundamentals. Without an understanding of the basic concepts of the View architecture as well as the underlying VMware vSphere architecture, it will be very difficult to build a proper View solution. For additional reading on either View or VMware vSphere, please refer to the administration, evaluation, and installation guides from VMware on the desired product set (https://www.vmware.com/support/pubs/view_pubs.html).
This chapter reviewed the components that make up the View environment and highlighted some of the new features of version 6 along with the new edition purchasing options.
The next chapter will cover how to collect an organization's inputs to ensure that a VMware View design meets the requirements for success. Collecting the requirements is a phase many VDI architects either skip or do in haste, resulting in a less-than-ideal end product. Once a VDI architect has performed several discovery engagements with an organization, it is certainly possible that he simply asks the likely pitfall questions (for example, "Will you be using a bidirectional audio?"), but until this level of comfort has been reached, performing a full discovery is advised.
