1
VMware View – Design Guidelines
Russel Wilkinson, Enterprise Desktop Solutions Specialist, VMware
2
3
Overview
• Steps to follow: Getting from concept to reality
• Design process: Optimized for efficiency
• Best Practices for VMware View Designs
4
From Concept to Reality
5
Phases of a Troubled View Deployment
Define Design Deploy Manage
No baseline for comparison
Lessons Learned shifted to Support Organization as issues, not opportunities
6
Guess the Outcome
Read 30% of Admin
Guide Deploy Manage
7
Major Phases of View Deployment
Define Assess Measure Baseline
Prototype Pilot
Test Confirm
Design Deploy Manage
Compare
Lessons Learned
8
Design Process
View Pool Design
View Pod and Block
Design
Storage Design
9
View Block and Pod Architecture
10
View Block and Pod Architecture
11
View Block and Pod Architecture
12
Pool Design: Desktop OS Considerations
Apps
• Are my apps supported by a specific OS?
User Familiarity
• Will I need to train users on a new OS?
VM Density
• Will the OS demand more resources?
Licensing • Do I have a VLK or MAK?
Time invested in pool design pays dividends many times more than any other aspect of View design work.
13
Pool Design: View VM Memory Considerations
VM Swap size and storage
VM Density
Windows pagefile
Memory for Apps
Disposable disks (Daytona)
Balance between paging and VM Swap file size
• VM Swap size = VM RAM • Local vs. shared datastore
• Size of delta disk • IOPS
• TPS Optimization • Disk consumption
14
Pool Design: Pool Type Considerations
User installed
apps
• Will users need to install apps?
User initiated machine changes
• Are users modifying registry keys or environment variables?
Available disk
space
• Is disk space inexpensive or plentiful?
Linked clones will work for roughly
Common Pool Types: • Persistent/non-persistent • Linked clone/non-linked clone
Persona management is a key enabler for floating pools
15
VI Design: View Block—vCenter and Clusters
vCenter Servers
Cluster Hosts
Cluster Settings
• One VC per 1,000 (VI3.5), 2,000 (VI4.x) desktops
• Max Eight ESX hosts per cluster serving linked clones • Leave room for failover and maintenance
• Keep max pool size to 320/875 for DRS enabled clusters • 80 (100 ESX 4.1) VMs per host for HA
vCenter and Cluster Design
16
View Manager Design: View Pod
Redundancy
Ingress
Access Mode
• Tunneled Mode: Fewer max sessions per CS
• Direct Mode: Direct network access to VMs
Max 5 Connection Servers to ADAM Group (5+2 in Daytona)
• Security server: Many SS to One CS • VPN: Only option for external access using PCoIP
17
VI Design: ESX Server Considerations
RAM • Density and cost
pNICs
• VMs/pNIC/VLANs
• 1GBE vs. 10GBE • Storage network
(NFS/iSCSI)
Storage • Type/protocol • Size and
Quantity • Performance
~1GB b/w for 150 VMs
Higher density DIMMs increase price
10GBE cost dropping
NFS—Best performance with jumbo frames
Local disk—good storage location for vSwp files
iSCSI vendors optimizing performance
Balance CPU and memory needs
Blades have emerged as ideal platform for hosting virtual desktops
1 Port group per VLAN ID
18
Storage Design: Sizing Considerations
Linked Clone Pool datastore size=
Replica VM VMDK size
+ (Desktop VM Memory Provisioned * 2)
+ (Parent VM VMDK * 25%)
+ Log File storage size
* Number of VMs per Datastore
+ Datastore free space allocation
10GB (Same as Parent VM)
VM Swap and Windows PF
Growth for delta files
~100 MB
Max per LUN: 64
15% overhead
128
Conservative
Conservative
19
Storage Performance Considerations
The tricky part about VDI storage is the peak load, NOT the steady state
Storms • Boot storms, AV storms, software installation storms,
login storms, logout storms • Validate operational SOPs during pilot, or risk the consequences!
Pool Deployment • Size of Parent VM disks x number of replicas
CX4: ~5 minutes to deploy one replica for pool, 10GB Parent VMDK
Storage Controller Failover Time • Time required to complete Storage Controller switch
Peaks can be 15 to 100 times the load of average!
2-8 IOPS/VM Avg
25-100 IOPS/VM Peak
20
A look ahead to Daytona: Design Considerations
Profile Management • RTO configuration is View Manager scope, not per pool
ThinApp Package Repository • Store MSI and EXE packages in one highly available CIFS share
• DFS is still a great choice with multiple replicas and fast storage
Disposable Disks • Initial release: Disposable disks on same volume as delta disk
Correct disk alignment will be in the shipping product • Including user data disks and disposable disks
21
Best Practices
Best Practices
22
General View Best Practices
Optimize View Desktop guest OS for VDI • Opt-in components model, not a build and remove model
Install and enable only the services and components needed
• Nlite and Vlite serve as good examples of possibilities www.nliteos.com, www.vlite.net
• Avoid over-provisioning memory and vCPUs
• Size Windows page file between 50-100% of memory
Profile the storage IOPS—and tell the storage architect • This critical step is often overlooked!
Size the Parent VM System Disk appropriately • Replica creation time greatly affected by Parent VM disks
23
General View Best Practices
Validate size of User Data Disk • Provisioning too little disk for UDD can be detrimental
• Outlook .OST will likely end up on UDD in Outlook cached mode (and UDDs are difficult to resize) Validate the cost and performance tradeoffs of Cached Outlook mode for VDI
• Adjust browser cache size to lowest useful setting
Exclude Java Message Bus folder from AV scanner • C:\Program Files\VMware\VMware View\Server\MessageBus
Avoid running concurrent AV scans • Full systems scans cause major performance impacts
• Stagger full systems scans (when full system scans are a corporate standard)
24
Operational Best Practices
Operations Common Sense • Don’t reboot all VMs during operational hours
• Perform Refresh and Recompose operations on a schedule, during off-peak times
• Track or limit user initiated changes, or plan on increasing cluster capacity over time
User Application Virtualization to save on application licensing costs • Don’t include licensed apps in the base image whenever possible
Use an image build tool (i.e., MDT) • Structured build process and predefined modules drives consistency,
fewer untracked changes
Keep master image metadata outside of View/VI • Create and enforce strong naming conventions for Parent VMs and snapshots
25
Operational Best Practices
DHCP • Adjust default lease time (MS DHCP) from 8 days to 1 hour
• Release DHCP script for floating pools that refresh on logoff
VLAN Usage • Avoid “overloading” VLANs used for View desktops to avoid
running out of IP addresses This situation is difficult to troubleshoot
vCenter Management • Do not allow a vCenter VM to manage the ESX host it’s running on
26
Recommendations
User Data and Persona Management • Use folder redirection for My Documents
Easier to use existing file archival system, maintain multiple file versions
• Start evaluating the capabilities of RTO Virtual Profiles
Turn off Outlook Cached Mode • VMs on same high speed network don’t benefit as much from cached mode
• Save on disk space and conserve storage IOPS
Never P2V a physical machine for a View master image • It would be more efficient to build a VM from scratch
27
Questions
Top Related