By Ferry Stelte, Senior Consultant at Login Consultants
A frequently asked question I receive from customers is: “How many SBC hosts or VDI Desktops can run on one Hypervisor host?" Many customers have difficulties with Excel sheets or with a calculator to perform calculations on the amount of SBC-VDI machines that can run on one single Hypervisor.
At Login Consultants, we also use Excel sheets to make calculations. Even though this can work fine, the sheets are not very pleasant to work with and create to much room for debate. That’s why I started working on a programme that can make such calculations, suitable for Citrix, VMware and Microsoft environments. The programme I created is called the Login Virtual Desktop Estimator. As the name suggests, the programme gives an estimation of the number of VM’s that can be run on a single Hypervisor.
The calculator takes the following aspects into consideration:
- Which operating system is used? The used operating system for VM’s influence the density of a host.
- What CPU overcommit ratio* is used? This choice enables the usages of more VM’s on a host. However, this can affect the user experience.
- Which CPU and Memory overhead does the Hypervisor/Anti-Virus offloading appliances et cetera use?
* Only applicable for VDI (overcommit of CPU is not recommended for SBC).
The image above is a screenshot of the application. All texts marked with an (*) represent values that are changeable.
In the next part of this blog, I will describe how the application can be used.
To fill in the hardware specification, the following aspects need to be known:
- Number of physical cores that are in a host (without including HyperThreading). For instance, when there are two Intel Xeon E5-2699V4 in the host, that means 44 physical cores can be allocated.
- Core overhead. How many overhead of cores must be considered? This is important because the hypervisor needs cores in itself, but appliances for Anti-Virus also need CPU’s. Therefore, this has to be filled in.
- Total Memory: fill in the total memory of the host.
- Memory Overhead: How much overhead of memory must be considered during the estimation. This is important because the Hypervisor needs memory in itself, but appliances for Anti-Virus also need memory. Therefore, this has to be filled in.
CPU overcommit ratio
- Light VDI: drag the value between 5 to 7. For the light profile, a lower overcommit is assumed in comparison to other profiles.
- Medium VDI: drag the value between 7 to 10. For the medium profile, a higher overcommit than the lower profile is assumed.
- Heavy VDI: drag the value between 10 to 12. For the heavy profile, the highest overcommit in comparison to the other profiles is assumed.
RDSH HW profile
- vCPU per RDSH: Fill in the number of vCPUs that will be configured for one RDSH server.
- Memory per RDSH: Fill in the memory that will be configured for one RDSH server.
RDSH Session profile
This can only be used for VMware DaaS calculations (or when it is very clear how much CPU/Memory one user has).
- vCPU per session: the number of cores used in one session (can be in decimals).
- Memory per session: the number of memory used in one session (can be in decimals).
You can change the vCPU and Memory configuration for the light/medium/heavy VDI profile here. The standard configuration has already been filled in, but you can fill in as much vCPU or Memory to an existing profile as you want.
When everything has been filled in, the amount of usable VDI’s and RDSH CM’s on the hardware will be given, based on the filled in specifications, as can be seen in the image below:
The Estimator shows how many vCPUs are available and how much can be spent maximally on both CPU and Memory.
As mentioned in the Estimator itself: please remember that this is an estimation. Density and user experience depend on many factors. Thus, it is important to have a thorough capacity test executed (by Login Consultants! ;)) before transitioning an environment to an operational environment.