Home > Storage > PowerStore > Virtualization and Cloud > PowerStore: 1,500 VMware Horizon VDI users > Virtual machine types
In a virtual desktop environment for end users, Horizon supports several different types of virtual workspaces that are referred to collectively as virtual desktop infrastructure (VDI). However, the various types of virtual desktops have different characteristics.
Full clones were the first type of clone used. The use of full clones requires no special tools. It is as simple as cloning a VM in vCenter. If the clone is a Windows VM, it is typically provisioned from a system-prepared (Sysprep) source image. Changing the name and IP address of the clone before joining it to a domain also works. If Horizon is used, it brokers the creation of unique full clones.
Although PowerStore data reduction can help reduce the disk footprint, full clones require the most disk storage because they do not share a common base image. An important consideration with full clones is management overhead. Each full clone must be managed as an individual desktop and each full clone requires individual patch management and updating.
The I/O profile of full clones is that of full machines, with reads and writes spread across the entire dataset. Full clones typically save user data to the local profile resulting in a persistent virtual experience. This VM type typically has the lowest overall storage I/O and CPU impact since data is saved between sessions. The VM is not refreshed at logoff. The downside is management overhead as each full clone must be managed and updated individually like a physical desktop.
The impact on network bandwidth and storage can be significant, however, if thousands of full clone machines attempt to do Windows Updates all at once. Activities such as patch management should be planned carefully. Leverage a local Windows software update server (WSUS) to avoid consuming Internet bandwidth needlessly. Maintenance windows should be defined and scheduled so WSUS updates a subset of machines that finish updating before the next group updates. This strategy helps to spread out the resource demands. The impact of each round of monthly updates can vary based on the number and type of updates released for that cycle, making it difficult to predict the resource impact.
Linked clones for a time were the most common type of clone used in VMware Horizon environments.
However, with the rapid adoption and improvements offered with instant clone technology, support for linked clones was deprecated with the release of VMware Horizon 8. In addition, linked clones are not supported in cloud or hybrid cloud environments.
Linked clones use a common base image with a disk digest architecture to redirect changes. All changes to the VM are written to the digest. If persistence is required, all changes are saved. Otherwise, all changes are flushed on logout. The disk load is higher in a nonpersistent configuration as a new user profile gets created on each login.
The disk footprint of linked clones is small. The base image is copied to each datastore in the pool and all machines share the base images. This behavior greatly reduces duplication of the base image.
Instant clones have replaced linked clones as the preferred VDI method with Horizon. The improvements in instant clone technology have enabled this clone type to replace other clone types in most configurations. However, instant clone implementations are I/O intensive during pool creation, and at user logoff as each VM gets refreshed based on the current base image.
A major advantage of instant clones is each machine is refreshed on every user logoff so it matches the current base image. This behavior greatly simplifies the update process: update the base image, and each VM is refreshed to use the new base image at the next user logoff. The base image can be updated frequently without user interruption. The instant-clone deployment and update process reduces management overhead and minimizes end-user impact.
It is necessary to anticipate the significant burst of I/O and CPU demand on the storage array when using instant clones:
Tip: Create pools outside of peak hours to avoid impacting active VDI users.
Most user logoffs occur toward the end of the workday or work shift. As the number of active VDI users shrinks, logoffs are less likely to impact active VDI users.
When user logoffs are sporadic and spread out, the I/O and CPU bursts are spread out and less impactful. However, if a high percentage off simultaneously, the burst in I/O and CPU demand will stress the storage array. A correctly sized environment can accommodate bursts in I/O and CPU due to pool creation and user logoffs. When using instant clones, the extra demand on the storage array from a CPU and disk I/O perspective must be anticipated and factored in when sizing the environment. The architecture in this document accounts for the bursts in I/O and CPU demand for these activities.
Dedicate a PowerStore array to VDI if the user count is high enough that bursts caused by pool creation and image refreshes at user logoff will impact other workloads.