Architecture - The VMware® View™ 4.5 Floating Reference

The VMware® View™ 4.5 Floating Reference Architecture R E F E R E N C E A R C H I T E C T U R E

The VMware® View™ 4.5 Floating Reference Architecture

R E F E R E N C E A R C H I T E C T U R E / 2

Table of Contents

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Hybrid Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

Design Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

Reference Architecture Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

The Building Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Virtual Infrastructure Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Physical Component Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Compute Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

Shared Storage Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Access Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Physical Network Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

VMware View Pod Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

VMware View Building Block Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Session Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Desktop Pool Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Active Directory Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Detailed VMware View Pool Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Virtual Machine Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Validation Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Client Access Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Workload Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Validation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

CPU Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Memory Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Application Response Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Storage Subsystem Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Network Subsystem Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

About the Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27



OverviewIncreasingly, organizations are turning to virtual desktop technologies to address the operational and strategic issues related to traditional corporate desktop environments. VMware® View™ 4.5 not only provides a virtual desktop environment that is secure, cost effective, and easy to deploy; but also provides comprehensive design flexibility.

VMware View 4.5 modernizes the desktop experience to deliver on-demand private cloud capabilities to users for a consistent experience across the global enterprise.

This document provides a reference architecture for floating virtual desktops with VMware View 4.5. Full descriptions of the test environment as well as performance metrics captured during test validation are provided.

This reference architecture provides a proven and tested floating architecture for enterprise desktop deployments. The goal was to design and validate a standardized building block, consisting of components capable of supporting 1,000 virtual desktops. The overall design also includes the infrastructure components necessary to integrate ten building blocks to support a 10,000-user VMware View “pod” that can be managed as a single entity.

The architecture uses common components and a standardized design to reduce the overall cost of implementation and management. All the infrastructure components used to validate the reference architecture are interchangeable, which allows components from an organization’s vendor of choice to be incorporated and utilize unique features that enhance the value of the overall solution.

Hybrid Design

In the previous Stateless Reference Architecture White Paper, a design based around a single host with unmatched scalability was introduced. The fresh design was enabled by a highly flexible design methodology where the individual needs of the desktop were treated as separate layers.

Design flexibility allows for a floating desktop regardless of back-end storage medium, including both local solid-state drives and shared storage. A blended design is possible using both solid-state drives within the host in addition to shared storage. This allows use of both shared storage and the local SSD depending on the pool use case. Individual desktop types could even use local host cache in very specific ways if application needs required.

The primary purpose of a hybrid design is to allow an environment to start with extremely low up- front capital cost, but still allow the architecture to easily take advantage of shared storage as required for certain desktop pool types.

The architecture focuses on enterprise desktop environments and targets larger deployments commonly found in campus environments. However, a floating design provides a high degree of scalability from only a few hosts to hundreds of hosts because of the assembly of the desktop at the last minute for the end user. This allows even small environment to utilize the same design, yet allow for that design to scale to tens of thousands of users.

This whitepaper, based around the same flexible design methodology, is designed to be an extension of previous work. Please view the prior document for VMware View 4.5 component descriptions and VMware View reference architecture methodology. While the prior architecture used local solid-state disk, the design principles in this reference architecture are the same.

http://www.vmware.com/files/pdf/VMware-View-45-Stateless-RA.pdf




Design Flexibility

When building a highly scalable, flexible, and cost-effective architecture, it is important to view each area of a virtual desktop separately. User data, applications, and desktop operating systems must be thought of as dynamic, flexible layers. Each layer must be independent of another layer if the environment is to have the highest level of scalability and cost effectiveness.

Individualized data is extremely important to be separated for the cost effectiveness of virtualized desktops, as it is the lynchpin to allow floating desktop environments.

User information can be handled using several primary methods:

•Redirectkeyfolderstonetwork-basedfileshares,anduseroamingprofiles

•Useprofilemanagementsoftware,suchasRTOSoftwareorLiquidwareLab’sProfileUnity

•ConfigureVMwareuserdatadisks,attachedatthevirtualizationlayer.

Regardlessoftheuserdatahandling,theimportantaspecttorememberistheactualdesktopshouldbeviewed as disposable. Floating architecture is only able to obtain low cost and high flexibility when user data is properly separated.

While roaming profiles have had a perception of being problematic in the past, with proper design they can be stable and successfully leveraged on a very large scale. A key to successful roaming profiles is keeping the size of the profiles as small as possible. Using extensive folder redirection, especially beyond the defaults that are found in standard group policy objects, the roaming profiles can be stripped down to a bare minimum of files.

Examples of recommended folder redirections:

•ApplicationData

•Documents

•Media(includebothpicturesandmusic)

•Desktop

•Favorites



Lockingdownthedesktop,specificallynotallowingtheusertosavedatalocallyisespeciallyimportantwithfloating desktops as the data on the desktop could be eliminated entirely when a user logs out of the system. While a persistent design is not required, it is still considered a best practice to allow for addition flexibility and cost savings.

Application flexibility can take on many forms, which include the applications in the base desktop image. As mentioned in the previous stateless whitepaper, if the application was abstracted from the base image additional, use cases are easily provided by the same base image. A single pool could be deployed within an environment with multiple user roles. The abstraction of the application would allow each user to leverage the samebaseOSbutstillmaintainsubstantialdifferencesintheapplicationset.



Reference Architecture DesignFor this reference architecture a building block-based floating desktop solution capable of supporting at least 10,000 virtual desktops was designed. The solution includes the typical components necessary to integrate 10,000 users into a VMware View “Pod”, which can be managed as a single unit, leveraging a 1,000-user

“building block” as the single replicated entity.

Because VMware View 4.5 enables the centralization of the virtual desktop environment in a highly modular fashion, a high degree of design flexibility is possible in the design. This reference architecture leverages VMwarevSphere™4.1andVMwareView4.5,inadditiontonetwork,compute,andstorage.Overall,thesecomponents optimize performance, scalability, and design flexibility while reducing costs.

This architecture uses common components and a standardized design across the building blocks to reduce the overall cost of implementing and managing the solution. All the physical infrastructure components used to validate this reference architecture are interchangeable. This means that an organization can use a vendor of choice for any physical component of the architecture, including the network, storage, and server components. Various vendors might offer or include unique features that further enhance the value of the overall VMware View offering for a particular enterprise.

The VMware View 4.5 floating 10,000-user pod is show below.

VMware ESX Cluster

Eight VMware vSphere Hosts

VMware View Building Block

Switched Network

1,000 Users

VMware ESX Cluster



VMware ESX Cluster



1,000 Users

VMware ESX Cluster



1,000 Users

VMware ESX Cluster



1,000 Users

VMware ESX Cluster



1,000 Users

VMware ESX Cluster



1,000 Users

VMware ESX Cluster



1,000 Users

VMware ESX Cluster



1,000 Users

VMware ESX Cluster



1,000 Users

VMware ESX Cluster



1,000 Users

Load Balancing

Network Core

VMware View Manager VMware View Manager VMware View Manager VMware View Manager VMware View Manager VMware View Manager

Switched Network

vCenter ServervCenter Server vCenter Server vCenter Server vCenter Server

1,000 Users

Figure 1: VMware View 10,000-User Pod



The Building Block

The overall pod contains 10 building blocks of 1,000 users each, which is the focus of this reference architecture. Each buildingblockcontainseightphysicalserversconfiguredinasinglecluster.Centralizedsharedstorageisusedforthevirtualization desktops, applications, and user profile data, as well as the core infrastructure server data.

The blade server chassis used for this validation were each capable of supporting 16 blade servers at full capacity; however,anytypeofserverwiththesamehardwarespecificationcanalsobeused.Oneconsiderationwhenusing blades is the port consolidation of each blade server-to-uplink module. Port consolidation is a common factor when leveraging blade servers. Because of the ability to leverage 10Gbit Ethernet, extensive bandwidth was available to the cluster tested, and would easily scale to accommodate 16 blades within the chassis.

A separate set of servers were used to host the common infrastructure components needed for an enterprise desktopenvironment,suchasMicrosoftActiveDirectory,DNS,DHCP,andtheVMwareViewConnectionServers.TheVMwarevCenter™serversalsoranwithinthiscluster.EachdesktopinfrastructureservicewasimplementedasavirtualmachinerunningWindows2008ServerR2.Theinfrastructurebladechassisalso hosted the simulated client devices. Because of the minimal load created by the core infrastructure in comparison to the overall infrastructure, the actual performance of the core infrastructure was left out of this document for clarity.

Each building block shared items such as the physical networking layer, as did the core infrastructure environment. In a smaller environment, it would be possible to have both local and shared storage within the same cluster and provide the floating desktops and the support infrastructure from the same building block.

Figure 2: VMware View 4 .5 Floating Cluster



Virtual Infrastructure Configuration

The virtual infrastructure at the core of each building block is comprised of physical servers and VMware Virtual Infrastructure4(VI4).Theoverallvirtualinfrastructureisdesignedtosupport10,000desktopusersacross80hosts. Depending on the environment and desktop workload, these results may vary.

TheoverallVMwareView4.5floatingbuildingblockisdesignedtobesupportedbyasingleVMwarevCenter4.1server.TheVMwarevCenterserverdatabasewashostedonasingleMicrosoftSQL2008server.BothVMwarevCenterandtheMicrosoftSQLserverwereimplementedasvirtualmachines.ThevSpherehostsrunningtheseinfrastructurevirtualmachineswerepartofastandardVMwarevSphereHighAvailability(HA)clustertoprotect them from any physical server failures. This is a common approach for hosting desktop infrastructure services that helps provide the highest level of availability.

Each VMware View building block contains one VMware vSphere ESXi 4.1.0 cluster of eight physical servers each. The 8-node cluster is designed to host 1,100 virtual desktops with N+1 redundancy. The cluster was configured with HA and vMotion enabled and configured with default requirements.

AlthoughtheoverallpodisdesignedwithadedicatedVMwarevCenterserverthatincludesitsowndedicateddatabase server, it might be desirable to consolidate the database servers into only one or a few larger database servers. However, database consolidation is not covered as part of this validation effort.



Physical Component Configuration

Compute Configurations High performing commodity-compute capabilities were chosen to maximize the per-host value of the reference architecture.ParticularwhentestingwithWindows7,ampleCPUisnecessarytoprovideastandarduserusecase a cost effective yet low latency desktop consolidation.

VMwARe View DeskTOp 1,000-UseR ClUsTeR

QTY Description

8 ComputeServers–vSphereESXi4.1.0Build260247

2 SixCore2.93GhzIntelXeonX5670Processors

18 144GBRAMTotalperhost,comprisedofKingston8GBDDR3-1333,Part#KTH-PL313/8G

2 73GBSASdrives,10kRPM,configuredasRAID1

2 BroadcomCorporationNetXtremeII57711E10GbitEthernet

inFRAsTRUCTURe seRVeRs

QTY Description

8 ComputeServers–vSphereESXi4.1.0Build2602472–InfrastructureServices(AD,SQL,andsoon)6–Loadtestinghosts

2 QuadCoreIntelX55702.93GHzProcessors

12 48GBRAM,Kingston4GBDDR3-1333RAM,Part#KCSB200A/4G

2 73GBSASDrives,notused(ESXibootfromSAN)

2 BroadcomCorporationNetXtremeII57711E10GbitEthernet

1 VMwarevCenterVirtualMachineWindows2008ServerR22–vCPU8GB–RAM30GBVirtualDisk

1 MicrosoftSQL2008ServerWindows2008ServerR22–vCPU8GB-RAM40GB Virtual Disk

1 Windows2008ServerR21–vCPU4GB–RAM20GB Virtual DiskActive Directory DNS/DHCP


R E F E R E N C E A R C H I T E C T U R E / 1 0

Shared Storage Configuration

VMwARe View DeskTOp 1,000-UseR ClUsTeR

QTY/Version Description

1 NetApp3140

1 OnTapRelease8.07-mode

2 10G Ethernet

2 2.2GHzPentiumIVCPUs2x32-bit(SingleCore)

4 1,024DoubleDataRateRAM(400MHzDIMMS)

2 10/100/1,100BaseTEthernetports

Release3.0 BIOS

28 (3)300GB15,000rpmdisks(usedforuserdata,applicationstreaming,andsoon)

(25)300GB15,000rpmdisks(usedforthedesktoplinkedclonesandrelateddata)

Access InfrastructureThe physical networking was implemented with a redundant network core of a full 10Gbit Ethernet Module. The networkcorealsoloadbalancesincomingrequestsacrossVMwareViewConnectionServers,whereuserrequestswere routed to the appropriate building block for each virtual desktop session.

Realistically,itwouldbepossibletoprovidenetworkingat10Gbitspeedsfor80hosts(inbladechassis)withapair of switches.

The primary purpose of load balancing in VMware View architecture is to optimize performance by distributing desktopsessionsevenlyacrossallavailableVMwareViewConnectionServers.Italsoimprovesserviceabilityandavailability by directing requests away from servers that are unavailable, and improves scalability by distributing connection requests automatically to new resources as they are added to the VMware View environment.

Secondarily, load balancing provides a critical protection from log on storms, specifically as it relates to spikes in users attempting to be authenticated to the system. This issue is easily mitigated with replica connection servers and proper load balancing.

Support for a redundancy and failover mechanism, typically at the network level, prevents the load balancer from becomingasinglepointoffailure.Forexample,VirtualRouterRedundancyProtocol(VRRP)communicateswiththe load balancer to add redundancy and failover capability. If the main load balancer fails, another load balancer in the group automatically starts handling connections.

To provide fault tolerance, a load balancing solution must be able to remove failed VMware View server clusters from the load balancing group. How failed clusters are detected may vary, but regardless of the method used to remove or blacklist an unresponsive server, the solution must ensure that new, incoming sessions are not directed to the unresponsive server. If a VMware View server fails or becomes unresponsive during an active session, users do not lose data. Instead, desktop states are preserved in the virtual desktop so that, when users reconnect to a different VMware View connection server in the group, their desktop sessions resume from where they were when the failure occurred.



Physical Network Details

pOD CORe neTwORking COMpOnenTs

QTY Description

2 ModularCoreNetworking

8 10 Gbit Ethernet Modules

2 LoadBalancingModules

BUilDing BlOCk neTwORk COMpOnenT (TeChniCAlly shAReD ACROss BUilDing BlOCks)

2 10Gbit Network Switches

VlAn COnFigURATiOn

VLANID Description

10-16 VMwareViewDesktops–Infrastructure802.11qTagged

17 InfrastructureServers–802.11qTagged

20 ManagementNeeds–802.11qTagged

23 Storage–iSCSIandNFS–802.11qTagged

24 vMotion–802.11qTagged

VMware View Connection ServersTwoVMwareViewConnectionServerswereimplementedwithloadbalancingtoprovideredundancyforthebuildingblockforthistest.Fora10,000-userPod,atleastsixVMwareViewConnectionServersshouldbedeployed to support added capacity and provide the highest level of performance and redundancy.

PerVMwarebestpractices,theVMwareViewConnectionServerswereconfiguredasareplicagroup,withtheloadbalancerinfrontofthebrokerprovidingclientnetworktrafficrouting.ThisallowsaViewConnectionServer to fail and have zero impact to the end user base.

VMware View Pod Detail

pOD CORe neTwORking COMpOnenTs

QTY Description

5+1 VMwareViewConnectionServerConnectionServers

10 VMwareViewBuildingBlockClusters

2 VMwareViewPodNetworkCoreComponents

5 VMwarevCenterServer4.1.0–ViewComposerInstalled

1 Microsoft2008SQLServer

1 SharedStorageComponent



VMware View Building Block Detail

1 ,000-UseR VMwARe View ClUsTeR

QTY Description

1 VMwarevSphereESXi4.1.0Clusters

8 VMware vSphere ESXi 4.1.0 Hosts

Details for each connection server were as follows:

•VMwareViewGlobalSettings(includedforclarity)



•ViewConnectionServerSettings

•ViewConnectionServerAuthenticationSettings



Session Management

Desktop Pools were configured to match a floating deployment in a simulated production environment. Because of the type of design, only two pools were needed and thus created per 1,000-user building block.

Individual user accounts were created in Active Directory and assigned to specific groups. Each Group was entitledtoaVMwareViewConnectionServerdesktoppool.

Desktop Pool ConfigurationsView MAnAgeR pOOl COnFigURATiOns

Users Unique ID Desktop Persistence Image Type ClusterAssignment

500 RA_Testing_1 Floating LinkedClone RATesting1

500 RA_Testing_2 Floating LinkedClone RATesting2

Active Directory GroupsView MAnAgeR ACTiVe DiReCTORy gROUps

Group Name Number of Users

Entitle_RA_Testing_1 500

Entitle_RA_Testing_2 500

Detailed VMware View Pool ConfigurationOnceapoolwascreated,theconfigurationforeachwasasfollows:

•PoolSettings



•ProvisioningSettings

• vCenterSettings



Virtual Machine Image

Each virtual desktop in the reference architect environment was based on a single optimized Microsoft Windows732-bittemplate.Windows7isnotdesignedforavirtualenvironment,andassuch,isexpectedtouse a traditional hard disk. Because of these two facts, it is highly recommended to optimize the Windows 7 desktop.

An optimized image will have a drastic decrease in processor, memory, and disk utilization. All testing in this reference architect was performed with an optimized image following the VMware View Windows 7 Optimization Guide in detail.

The template configuration:

ViRTUAl MAChine COnFigURATiOn

QTY Description

1,000 Windows732-bitVirtualMachines

1GB RAM

24GB Virtual Disk

Applications contained with the template:

ViRTUAl MAChine AppliCATiOns

MicrosoftOffice2010

AdobeAcrobatReader9

Microsoft Internet Explorer 8

Windows Media Player

http://www.vmware.com/files/pdf/VMware-View-OptimizationGuideWindows7-EN.pdf

http://www.vmware.com/files/pdf/VMware-View-OptimizationGuideWindows7-EN.pdf



Validation MethodologyWhen validating VMware View reference architecture designs, it is important to simulate a real world environment as closely as possible. For this validation, each component was built and validated for the virtual infrastructure necessary in a 1,000-user cluster using a simulated workload. The networking, load balancing, and core common infrastructure components were also implemented for access infrastructure necessary to support a 10,000-user VMware View Pod.

Figure 3: VMware View Reference Architecture Lab Workflow

Each test was then conducted in two phases. In the first phase, desktop pools were created provisioning the virtual machines to a single server. Each pool was created manually, just as it typically would be created in a normal environment. Testing was performed to find a realistic limit of the single server, which for a 12-core serverallowed143desktops.

The second phase of the validation included session establishment, log on, and execution of a workload across a full cluster. Each client access device established individual VMware View session connections to assigned ViewDesktopsusingtheVMwareViewClient.Onceasessionwasestablished,theworkloadwasruntosimulate typical user activity.

Each session worked in the environment as a standard user throughout the test, during which time the overall system statistics were collected from several components of the architecture. The following sections explain in more detail how each layer was implemented and used as part of the validation and how the workload was implemented.



Client Access Devices

To test and validate each layer of the architecture, simulated client access devices were deployed to simulate arealworldenvironmentusingVMwareDesktopReferenceArchitectureWorkloadSimulator(RAWC).Thesimulated users connect from a client access device through the supporting infrastructure and establish network-basedsessionswiththeViewDesktops.TheRAWCclientaccessdeviceswereimplementedseparatelyfromtheactualbuildingblocksandotherinfrastructurecomponents,suchasActiveDirectory,DNS,DHCP,andfile and print services, to allow for realistic simulation of end users that are outside the datacenter.

EachRAWCclientaccessdevicewasimplementedusingWindowsXPSP364-bitrunningthe64-bitVMwareViewClient.Tenclientaccessdevicesweredeployed,andeachwasusedtoestablishonehundreduniqueVMwareView sessions. Each session was established using a unique individual user account that was entitled to use the desktop pool. During the tests, virtual clients were logged in at random intervals until all the virtual clients had been logged in. Each simulated client’s 100 sessions were started, logging in 10 sessions every 20 seconds.

TheexactRAWCconfigurationisshowbelow:



Workload Description

Each virtual machine was equipped to run a workload that simulates typical user behavior, using an application set commonly found and used across a broad array of desktop environments. The workload has a set of randomly executed functions that perform operations on a variety of applications. Several other factors can be implemented to increase the load or adjust the user behavior, such as the number of words per minute that are typed and the delay between applications being launched.

TheworkloadconfigurationusedforthisvalidationincludedOffice2010,includingWord,Excel,PowerPoint,andInternetExplorer8,AdobeAcrobatReader,andWindowsMediaPlayer.Duringtheexecutionoftheworkload, multiple applications were opened at the same time and windows were minimized and maximized as the workload progressed, randomly switching between each application. Individual application operations that were randomly performed included:

•MicrosoftWord2010 Open/minimize/close,writerandomwords/numbers,savemodifications.

•MicrosoftExcel2010

Open/minimize/close,writerandomnumbers,insert/deletecolumns/rows,copy/pasteformulas, save modifications.

•MicrosoftPowerPoint2010 Open/minimize/close,conductaslideshowpresentation.

•AdobeAcrobatReader Open/minimize/close,browsepagesinPDFdocument.

• InternetExplorer8 Open/minimize/close,browsepage.

•WindowsMediaPlayer OpenandViewasamplevideo.

Based on the “think time” and words per minute used for this validation, this workload could be compared tothatofahigh-endtaskworkerorlower-endknowledgeworker.Realresultswouldabsolutelydependonthe environment’s actual usage, but in general the results in this reference architecture are designed to be conservative.

With this workload, it was validated that at least 1,000 users were able to be maintained by this architecture using the provided server, network, storage resources, and configuration. In addition to being able to sustain 1,000 users with fast application response time, the necessary resources were also available to accommodate a host failure within each cluster, as well as to accommodate a moderate amount of growth or unpredicted increase or change in user workload. Depending on the specific environment, additional changes or features implemented, and the workload characteristics of your users, you may be able to accommodate more or fewer users.



Validation ResultsThis section details the results and observations that were concluded during the validation of floating desktop virtualization with VMware View 4.5.

All validation included several test iterations to ensure data consistency after a ramp up period, for clarity multiple iterations are not shown. All data includes the initial period of massive user logons ramping up the test to show even when pushed heavily the environment can provide an acceptable range of performance.

CPU Utilization

The graphs below is the per-host processor usage, both for the normal 125 users that would be on a server duringa1,100-user8-hosttest(58%average),aswellas143users,simulatingasinglehostfailureinthecluster(67%average).AmpleCPUusageisavailableforadditionalscalability.

Figure 4: 125-User Host CPU Usage

Figure 5: 143-User Host CPU Usage



Memory Usage

Because the total number of desktops on each host only consumed available memory, there is limited memory overcommitment.Additionaluserswouldbeabletobesupported.Asexpected,with143userssomememorypage sharing becomes active, however this is still minimal.

Figure 6: 125-User Host Memory Usage

Figure 7: 143-User Host Memory Usage



Application Response Times

In all tests, application response time was tracked to ensure user experience expectation would be in line with an acceptable environment.

Figure 8: 125 Desktops Application Response Time

Figure 9: 1,100-User Average Application Response Time



Storage Subsystem Detail

The user count storage detail reveals how important the writes are in a desktop virtualization environment that usesproperlyoptimizedimages.OncetheinitialreadI/Ostormsubsides,writestakeanimportantrole.

Figure 10: 125 Desktops, Storage I/O Per Second

Figure 11: 143 Desktops, Storage I/O Per Second



Particularlywhenviewingtheentire1,000-userclusterI/Ousage,theabilitytoprovide5,000sustainedwriteIOPSiscritical.However,theinitialreadstormmustbeplannedwithproperstoragecachesinordertoprovideacceptable performance in all cases.

Figure 12: 1,000 Desktops Storage I/O Per Second

Figure 13: 1,000 Desktops Storage MBytes Per Second



Network Subsystem Detail

Figure 14: 1,000 Desktops Storage Network MBits Per Second

Figure 15: 1,000 Desktops Virtual Machine Network MBits Per Second



ConclusionThe VMware View 4.5 floating architecture can be used to provide flexible low cost desktops in local host storage and storage alike. The flexibility in design allows an organization to start at even a single host, and slowly migrate to the other extreme to address different use cases. In this reference architecture, 1,000-user building blocks were shown to provide adequate performance and proper redundancy. The core design principles of separating user data, application, and the operating system are a foundation and a best practice regardless of the underlying technical VMware View design.

About the AuthorsWorldWideTechnology,Inc.(WWT)isaleadingSystemsIntegratorprovidingtechnologyproducts,servicesand supply chain solutions to customers around the globe. WWT understands today’s advanced technologies, including great depth in datacenter transformation by leveraging virtualization and cloud technologies. When properly planned, procured and deployed, these business solutions reduce costs, increase profitability and ultimately improve a company’s ability to effectively serve their customers.

Foundedin1990,WWThasgrownfromasmallstart-upbusinesstoaworld-classorganizationwithover$3billioninrevenueandmorethan1,400highly-trainedemployees.WWTcontinuestoachieveconsistentfinancial growth and provide our partners with uncommon strength and stability.

WWT’s proven processes span the technology implementation lifecycle as we provide customers with advanced technology solutions. By engaging WWT to manage their planning, procurement and deployment processes, our customers benefit from our certified technology professionals, nationwide logistics facilities and asuiteofeCommerceapplicationsdesignedtogreatlysimplifythesupplychain.

AcknowledgementsVMware would like to acknowledge the following individuals for their contributions to this paper and help with the test setup, analysis, as well as providing the lab infrastructure and building of the joint solution:

World Wide Technology, Inc.: Jason CampagnaandDavidKinsman

VMware, Inc.: Mac Binesh, Fred Schimscheimer, Matt Eccleston, and Mason Uyeda

http://www.linkedin.com/in/jasoncampagna

http://www.linkedin.com/pub/mac-binesh/0/432/912


VMware, Inc. 3401 Hillview Avenue Palo Alto CA 94304 USA Tel 877-486-9273 Fax 650-427-5001 www .vmware .comCopyright © 2011 VMware, Inc . All rights reserved . This product is protected by U .S . and international copyright and intellectual property laws . VMware products are covered by one or more patents listed athttp://www .vmware .com/go/patents . VMware is a registered trademark or trademark of VMware, Inc . in the United States and/or other jurisdictions . All other marks and names mentioned herein may be trademarks of their respective companies . Item No: VMW_11Q1_RA_Floating_EN_PXX

ReferencesVMware View http://www.vmware.com/products/view/

VMwareReferenceArchitectureforStatelessVirtualDesktopswithVMwareView4.5 http://www.vmware.com/files/pdf/VMware-View-45-Stateless-RA.pdf

VMware vSphere 4.1 http://www.vmware.com/products/vsphere/

http://www.vmware.com/products/view/


http://www.vmware.com/products/vsphere/