These test results describe a View 5.2 setup with 10,000-desktops, in which one vCenter Server 5.1 instance managed 5 pools of 2,000 virtual machine desktops each. Only one maintenance period was required for provisioning a new pool or for recomposing, refreshing, or rebalancing an existing pool of 2,000 virtual machines. A logon storm of 10,000 users was also tested.

The test results provided here were accomplished with the software, hardware, and configuration settings described in the following topics:

Capacity for an Hour-Long Logon Storm of 10,000 Users

Note: This example was used in a View 5.2 setup, which was carried out prior to the release of VMware vSAN. For guidance on sizing and designing the key components of View virtual desktop infrastructures for VMware vSAN, see the white paper at http://www.vmware.com/files/pdf/products/vsan/VMW-TMD-Virt-SAN-Dsn-Szing-Guid-Horizon-View.pdf. For test results with various workloads and View operations when using vSAN, see the reference architecture white paper at http://www.vmware.com/files/pdf/techpaper/vmware-horizon-view-virtual-san-reference-architecture.pdf.

The vSAN feature available with vSphere 6.0 and later releases contains many performance improvements over the feature that was available with vSphere 5.5 Update 1. With vSphere 6.0 this feature also has broader HCL (hardware compatibility) support. For more information about vSAN in vSphere 6 or later, see the Administering VMware vSAN document.

In a test setup, the following desktop and pool configurations were used for a logon storm scenario for 10,000 desktops. The power policy for desktops was set to Always On.

For 10,000 desktops the logon storm occurred over a 60-minute period, using a normal distribution of logon times. The virtual machines were powered on and were available before the logon storm began. After logon, a workload started, which included the following applications: Adobe Reader, Microsoft Outlook, Internet Explorer, Microsoft Word, and Notepad.

Following are additional details of the logon storm that was sustained during testing:

  • 95% of logons occurred within +/- 2 standard deviation window (40 minutes).
  • 68% of logons occurred within +/- 1 standard deviation window (20 minutes).
  • Peak logon rate was 400/min, or 6.67/second.

Time Required for Provisioning a Pool

Pools are provisioned either up front, when you create the pool, or on demand, as users are assigned to them. Provisioning means creating the virtual machine and configuring it to use the correct operating system image and network settings.

In a test setup already containing 4 pools of 2,000 virtual machines in each pool, provisioning a fifth pool that contained 2,000 virtual machines took 4 hours. All virtual machines were provisioned up front.

Time Required for Recomposing a Pool

You can use a recompose operation to provide operating system patches, install or update applications, or modify the desktop hardware settings of virtual machines in a pool. Before recomposing a pool, you take a snapshot of a virtual machine that has new configuration. The recompose operation uses that snapshot to update all virtual machines in the pool.

In a test setup of 5 pools of 2,000 virtual machines in each pool, a recompose of one pool of 2,000 virtual machines took 6 hours and 40 minutes. All virtual machines were powered on and available before the recompose operation began.

Time Required for Refreshing a Pool

Because disks grow over time, you can conserve disk space by refreshing a desktop to its original state when users log off, or you can set a schedule for periodically refreshing desktops. For example, you can schedule desktops to refresh daily, weekly, or monthly.

In a test setup of 5 pools of 2,000 virtual machines in each pool, a refresh of one pool of 2,000 virtual machines took 2 hours and 40 minutes. All virtual machines were powered on and available before the refresh operation began.

Time Required for Rebalancing a Pool

A desktop rebalance operation evenly redistributes linked-clone desktops among available logical drives. A rebalance operation saves storage space on overloaded drives and ensures that no drives are underused. You can also use a rebalance operation to migrate all virtual machines in a desktop pool to or from a vSAN datastore.

In a test pod that contained 5 pools of 2,000 virtual machines in each pool, 2 datastores were added to the pod for one test. For another test, 2 datastores were removed from the pod. After the datastores were added or removed, a rebalance operation was performed on one of the pools. A rebalance of one pool of 2,000 virtual machines took 9 hours. All virtual machines were powered on and available before the rebalance operation began.