7.0
Table Of Contents
- View Architecture Planning
- Contents
- View Architecture Planning
- Introduction to View
- Planning a Rich User Experience
- Feature Support Matrix for Horizon Agent
- Choosing a Display Protocol
- Using Hosted Applications
- Using View Persona Management to Retain User Data and Settings
- Using USB Devices with Remote Desktops and Applications
- Using the Real-Time Audio-Video Feature for Webcams and Microphones
- Using 3D Graphics Applications
- Streaming Multimedia to a Remote Desktop
- Printing from a Remote Desktop
- Using Single Sign-On for Logging In
- Monitors and Screen Resolution
- Managing Desktop and Application Pools from a Central Location
- Advantages of Desktop Pools
- Advantages of Application Pools
- Reducing and Managing Storage Requirements
- Application Provisioning
- Deploying Individual Applications Using an RDS Host
- Deploying Applications and System Updates with View Composer
- Deploying Applications and System Updates with Instant Clones
- Managing VMware ThinApp Applications in View Administrator
- Deploying and Managing Applications Using App Volumes
- Using Existing Processes or VMware Mirage for Application Provisioning
- Using Active Directory GPOs to Manage Users and Desktops
- Architecture Design Elements and Planning Guidelines for Remote Desktop Deployments
- Virtual Machine Requirements for Remote Desktops
- View ESXi Node
- Desktop Pools for Specific Types of Workers
- Desktop Virtual Machine Configuration
- RDS Host Virtual Machine Configuration
- vCenter Server and View Composer Virtual Machine Configuration
- View Connection Server Maximums and Virtual Machine Configuration
- vSphere Clusters
- Storage and Bandwidth Requirements
- View Building Blocks
- View Pods
- Advantages of Using Multiple vCenter Servers in a Pod
- Planning for Security Features
- Understanding Client Connections
- Choosing a User Authentication Method
- Restricting Remote Desktop Access
- Using Group Policy Settings to Secure Remote Desktops and Applications
- Using Smart Policies
- Implementing Best Practices to Secure Client Systems
- Assigning Administrator Roles
- Preparing to Use a Security Server
- Understanding View Communications Protocols
- Overview of Steps to Setting Up a View Environment
- Index
Local Datastores for Floating, Stateless Desktops
Linked-clone desktops can be stored on local datastores, which are internal spare disks on ESXi hosts. Local
storage offers advantages such as inexpensive hardware, fast virtual-machine provisioning, high-
performance power operations, and simple management. However, using local storage limits the vSphere
infrastructure configuration options that are available to you. Using local storage is beneficial in certain
environments but not appropriate in others.
NOTE The limitations described in this section do not apply to Virtual SAN datastores, which also use local
storage disks but require specific hardware, as described in the preceding section about Virtual SAN.
Using local datastores is most likely to work well if the remote desktops in your environment are stateless.
For example, you might use local datastores if you deploy stateless kiosks or classroom and training
stations.
If you intend to take advantage of the benefits of local storage, you must carefully consider the following
limitations:
n
You cannot use VMotion, VMware High Availability (HA), or vSphere Distributed Resource Scheduler
(DRS).
n
You cannot use the View Composer rebalance operation to load-balance virtual machines across a
resource pool.
n
You cannot store a View Composer replica and linked clones on separate datastores, and, in fact,
VMware recommends storing them on the same volume.
If you manage local disk usage by controlling the number of virtual machines and their disk growth, and if
you use floating assignments and perform regular refresh and delete operations, you can successfully
deploy linked clones to local datastores.
For more information, see the chapter about creating desktop pools in the ViewAdministration document.
Reducing Storage Requirements with Instant Clones
The instant clones feature leverages vSphere vmFork technology (available with vSphere 6.0U1 and later) to
quiesce a running base image, or parent virtual machine, and hot-clone it to create a pool of up to 2,000
instant clones.
Not only do instant clones share the virtual disks with the parent virtual machine at the time of creation,
instant clones also share the memory of the parent. Each instant clone acts like an independent desktop,
with a unique host name and IP address, yet the instant clone requires significantly less storage. Instant
clones reduce the required storage capacity by 50 to 90 percent. The overall memory requirement is also
reduced at clone creation time.
Replica and Instant Clones on the Same Datastore
When you create an instant clone desktop pool, a full clone is first made from the master virtual machine.
The full clone, or replica, and the clones linked to it can be placed on the same data store, or LUN (logical
unit number).
Replica and Instant Clones on Different Datastores
Alternatively, you can place instant clone replicas and instant clones on separate datastores with different
performance characteristics. For example, you can store the replica virtual machines on a solid-state drive
(SSD). Solid-state drives have low storage capacity and high read performance, typically supporting tens of
thousands of I/Os per second (IOPS).
View Architecture Planning
42 VMware, Inc.