Number of VMs – Number of desktops.

Concurrent VMs – Number of concurrently powered on desktops.

Desktop Pools Type – Select either Linked Clones or Full Clones.

Number of vCPU – Number of virtual CPU per desktop. Recommended 1 vCPU for normal workloads or 2 vCPU for intensive workloads, such as graphic or OLPT applications.

Average vCPU MHz – Average CPU utilization per desktop. If not known leave, as Default.

vCPU MHz Overhead – This setting prevent CPU oversubscription. It is recommendable to leave 20% or more room for bursts.

Memory Size – Amount of RAM per desktop.

Full Size of Parent VM – Size of VMDK assigned to Parent VM. This number is used to calculate storage utilization.

Thin Size of Parent VM – Total disk space utilized by Parent VM. This number is used to calculate replica disks.

Refresh OS disk on logoff at – How often desktops are refreshed after use (Affect only Linked Clones)

Persistent Disk (UDD) – Size of Persistent Disks (Affect only Linked Clones)

Disposable Disk – Size of Disposable Disks (Affect only Linked Clones)

Number of Desktop Pools – Maximum of 512 desktops is allowed per pool. It will show an error (ERR) if the number of desktops pools is too small to support the number of desktops. Read more at A review of VMware View 4.5 Limits and Maximums.

Number of Parent VMs – One Parent VM may serve several desktop pools.

Number of VMs per Datastore – For Fiber Channel connectivity it’s recommended to keep this number between 64 and 128 due to the number of SCSI reservations per LUN. For NFS arrays it is possible to increase this number to higher values.

Number of Snapshots per Pool – Recommended to set two snapshots per desktop pool to accommodate recomposes operations. This number affects the calculation of the replica datasore.

Desktop State when Not in use – Defines host CPU consumption and storage footprint for VMs in suspended mode or powered off when not in use.

Cores per Host – Total number of cores per host. Not necessarily more cores are always better. Read Cores and more Cores… We don’t need them!

VMs per Core – For Nehalem/Westmere processors 12 desktops per core is an ideal number for most workloads, while maintaining vSphere cluster high availability (N+1) and staying below the maximum supported VMs per core of 16. Read more at A review of VMware View 4.5 Limits and Maximums.

% Host Used Memory – Amount of usable host memory

% Host Shared Memory (TPS) – Define the amount of Transparent Page Sharing per host. This number changes according to GuestOS type, applications in execution, and helps to calculate the total amount of memory required per host.

% VM Memory Reservation – Increasing memory reservation reduces VM swap file. This setting plays a key factor on storage savings. Read more at Pagefiles and VDI. Not so simple.

Hypervizor Memory Overhead – Amount of RAM reserved for hypervisor kernel operations.

VM Memory Overhead – This field is automatically calculated based on several external factors.

vCenter Server – Version of VMware vCenter server is used for scalability and sizing. Read more at A review of VMware View 4.5 Limits and Maximums.

vCenter HA (n+1) – Calculate high availability (n+1) for all View Clusters. The use of this setting increases High Availability but reduces de overall number of VMs per View cluster. Recommended to set it to YES.

vCenter VM Limit (4.1 and 5.0) – Maximum number of VMs per vCenter Server.

VMware View – Version of Vmware View

Connection Server HA (n+1) – Calculate redundant connection brokers in a N+1 scenario.

Display Protocol – Define the scalability of the connection brokers. For display protocol calculation visit https://myvirtualcloud.net/?page_id=1562

Number of Displays – Affect VM Memory Overhead

Display Resolution – Affect VM Memory Overhead

Color Depth – Color depth for the dispays in use

3D (0 = No) –Amount of vRAM to be assigned for 3D use. Read more at

VMware View 5.0 3D Reverse Engineeredand

vSphere 5.0 New .vswp file & Storage Tax on VDI.

Connection Type – (Only for RDP connections) Define the scalability of connection brokers. Tunneled connections decrease amount of connections per broker.
External Users – Number of users simultaneously connecting through View Security Servers.

Dedicated Replica Datastore – View 4.5 introduced the ability to dedicate datastores for read IO intensive replicas. The use of Dedicated Replica Datastore helps to reduce the amount of storage required and allow assignment of tier 1 storage for replica disks. Read more at VMware View 4.5 Linked Cloning explained.

Place VM .vswp on Local Storage – Placement of VM .swsp files on local storage help in reducing amount of shared storage required. Read more at Save [VDI] Storage using VM Swap File Host Placement.

Storage Overhead – Define amount of additional storage to be included in the calculations.

Workload IOPS – Expected average IO per VM

Custom – Expected average IO per VM

RAID Type – RAID type impact on performance. Select the appropriate RAID group for the Linked Clone datastores.

%Read – %Write – Define IO pattern for IO operations per VM. This settings impact directly on the number of IOs calculated.

Transport Protocol – Define if communication to array is done via block (FC, iSCSI, FCoE) or File (NFSv3).

VAAI – vStorage API for Array Integration enabled storage arrays provide ATS mechanism to run more VMs per LUN.

Caching– Intelligent arrays make use of DRAM and/or SSD memory to store most accessed blocks in memory. Memory stored in memory do not require backend spindle access, therefore reducing the total requirements on the backend. This is a powerfull option but should be used with caution. Normally is not possible to know the caching ratio until a project pilot is done.

Block De-duplication – Some arrays have either in-line block de-duplication or offline block de-duplication that helps to reduce the total capacity requirement. The de-duplication ratio for VDI deployments is normally high due to the block communality across multiple Windows desktop VMs. This is a powerful option but should be used with caution. Normally is not possible to know the caching ratio until a project pilot is done.