Eliminating VDI Boot Storms for VMware Horizon VDI Deployment

London, UK. January 20,2023.

AXA is a large multinational insurance company.

AXA’s IT department in London deployed VirtuCache to improve the performance of their newly deployed Instant Clone based Horizon VDI deployment. They use various Netapp All Flash Arrays as primary storage. They were specifically looking to eliminate VDI boot storm issues.

Virtunet Systems develops VirtuCache software. VirtuCache improves the storage performance of VMware VMs by caching all VM read and write operations to in-host SSD or RAM.

VDI boot storms result in slow end user VM boot.

VDI boot storms happen when large number of VDI end users login to their VDI VMs simultaneously. Typically end user VDI VMs require small IOPS since end users can only use so much storage IO bandwidth. However, when users come to work all at the same time and login to their VMs within a short interval of each other, the Windows OS now needs to boot as many times as the users are logging in, and this places quite a bit of stress on the storage array and network. Technical details on why this is so is on another one of our blog posts.

How VirtuCache improves VM boot times?

VirtuCache automatically caches frequently and recently used VM data (reads and writes) from SAN based storage to in-VMware host RAM or SSD. Subsequently, VirtuCache services more and more storage IO from this in-host cache media, instead of the IO requests traversing the storage network and served by the storage appliance. This alleviates the load on the storage infrastructure and improves VM latencies considerably.

When VDI VMs boot, they all use the same Windows OS image / Parent VM / Replica for all the VMs in the same pool. VirtuCache realizes that the OS image is frequently used and so it quickly caches the entire OS image / Parent VM / Replica to the in-host cache media that VirtuCache is configured with. Once the OS image is locally cached on each host, it speeds up end user VM boot, since the OS image is now on locally attached RAM or NVME and VMware doesn’t need to traverse the storage network to retrieve the OS image for every VM that boots up.

In case of non-persistent VDI using instant clones, as was the case at AXA, using the ‘Write-Back No Replica’ caching policy in VirtuCache leads to the quickest boot times for VDI VMs, much faster than even the fastest all-flash arrays. Typically for server VMs, ‘Write-Back One Replica’ caching policy is recommended so that in case of abrupt host failure, the VM write data is still preserved correctly through replication (mirroring) of write cache across ESXi hosts. However, in case of non-persistent VDI using instant clones, one doesn’t need to worry about preserving write data in case of host failure since write data is anyway not preserved. Hence the ‘Write-Back No Replica’ caching policy can be used which reduces VM latencies considerably as it avoids the incremental network latency required to replicate (mirror) the write data to other hosts in the VMware cluster. Especially when host RAM is used as VirtuCache cache media, all reads and writes are coming from and going to host RAM, and RAM is the fastest media there is. As a result, end user VM storage latencies are RAM level latencies for all storage IO including VM boot.

Customer Environment

• SuperMicro Sys-2029 GP servers running ESXi 7.0 with Nvidia GPUs.
• Datastores on various Netapp All-Flash storage arrays connected to ESXi hosts using 40g iSCSI.
• VirtuCache was configured to cache to 1.2TB host RAM in each host in their 8-host ESXi cluster. In VirtuCache, ‘Write-Back No Replica’ policy was applied to all the Datastores. ‘Write-Back No Replica’ policy caches all reads and writes to in-host cache media (in this case host RAM). As a result, all reads and writes are serviced directly from the in-host cache media without involving any backend storage arrays and networks, thus reducing storage latencies considerably.