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