VDI vs. RDS: What are the differences? desktop as a service (DaaS)

VDI testing checklist: Key steps to test a VDI deployment

Whether IT is running VDI for the first time or simply tweaking the back-end hardware, admins should follow a VDI testing checklist to ensure positive UX and sufficient desktop resources.

When IT professionals deploy VDI, they can run into many potential pitfalls, including over- and under-provisioned resources, delivery issues for remote workers and application compatibility problems.

Whether an organization is just setting out on its VDI journey or it's planning to make significant alterations to its existing infrastructure, IT must test changes before implementing any in production. IT can test a cross section of desktops and user types to understand the deployment's exact needs.

A well-executed VDI test addresses concerns around network bandwidth requirements, desktop and application latency, user experience, printer compatibility and more. Once IT professionals are comfortable with the testing results, they can deploy VDI across their organization knowing they resolved issues before they even occurred.

However, IT professionals should make a VDI testing checklist before anything else to ensure that their process will yield accurate and actionable results.

Benchmarks to include in a VDI test

One of the central aspects of a VDI test is determining the resources each user requires. The storage and memory requirements of a user who runs video editing software will far surpass the needs of a user who only runs Microsoft Outlook and Word. IT pros must use a VDI test to determine just how large that resource disparity is so users can avoid performance issues.

Another resource-based aspect of a VDI test is desktop logon time. Resource shortages during boot storms can cause major delays for users attempting to log on, leading to user frustration. IT should create a boot storm during its testing to determine how logon times are affected and address the issue. User profile complexities and policy applications can also cause longer logon times.

For problems with desktop performance and logon times, IT must set measurable VDI performance goals for the test results, such as maximum acceptable amounts of latency and average desktop logon time, based on its organization's needs. Some organizations might be able to handle long logon times, but others, with time-sensitive functions in fields such as banking or healthcare may be inclined to pay a high cost to minimize logon times.

Even with the proper infrastructure and configurations, VDI can perform poorly if the network can't accommodate the VDI's need for bandwidth. This could lead to issues with latency, especially with virtual applications.

One benchmark IT can use for VDI network load testing is comparing application boot time and performance on a virtual machine to a PC running the same operating system and applications in a traditional desktop environment. While it isn't always realistic to expect the exact same performance on the VM, this benchmark gives IT admins a realistic idea of the UX when they undertake network capacity planning.

VDI testing checklist

Checklist for VDI testing

Once IT professionals have the desired benchmarks in place for their VDI, they should go through a VDI testing checklist to ensure they have their bases covered.

While the exact steps will differ from vendor to vendor, there are certain parameters that IT professionals should follow.

1. Determine success criteria

Before IT admins begin a VDI test, they should sit down with business leaders to determine criteria that will measure success. VDI isn't a good fit for every use case, so organizations starting out with VDI must determine whether the pros will outweigh the cons. Oftentimes this involves creating a proof-of-concept to outline goals, such as increased security, reduced maintenance costs or improved ease of upgrading applications.

Organizations should aim for specificity and measurability while developing goals. For example, if the goal is to reduce maintenance costs, organizations should set a specific amount or percentage that the costs should be reduced by.

Organizations should outline these goals in writing, so there are no fluctuations or disagreements between IT staff and business leaders down the line.

2. Define the testing parameters and validate basic functionality

Before deploying VDI or making any changes to virtual desktops, IT staff should ensure that their existing infrastructure meets the requirements that will allow virtual desktops to run smoothly.

Organizations should ensure that:

  • they have enough resources (CPU, memory, etc.) to support VDI;
  • the VMs meet the requirements for any software they plan to test; and
  • the network connection is strong enough to support the VM.

This step on the VDI testing checklist includes setting benchmarks for acceptable performance in metrics such as latency, desktop logon time, application performance and tracking desktop resource use relative to the expected resource use. IT professionals can also load test their entire VDI system by looking at the resources that the test virtual machines consume and comparing the numbers to the total VDI resource pool.

As a small-scale example, if IT typically runs 100 virtual machines for video editing at the same time and plans for each machine to pull from a pool of 200 virtual GPUs, then the test machines shouldn't use more than 2 virtual GPUs at a time. If the machines use anything more than 2 virtual GPUs, the VDI admins will have to make some changes to the infrastructure. With virtual GPUs, however, the VDI can allocate these resources based on which users need them the most for their workloads. This doesn't eliminate the need to plan for maximum capacity, but it can help with the user experience when the VDI isn't operating at full capacity.

During this step, IT should ensure that end users will have basic functionality on their virtual desktops, such as access to login and initial app screens. Oftentimes the easiest way to do this is with a third-party tool such as Login VSI. IT admins can do it manually, but they should consider a third-party tool -- especially for large-scale testing.

3. Spin up and prepare the virtual machines for testing

IT professionals can go about this process in several different ways. If they only want to test a single VM image from various user groups, they can spin up one clone of each user group's image. If IT professionals want a larger sample size of images to test, they can clone a single image in bulk. This process varies from vendor to vendor, but virtual desktop administrators should be familiar with the spin up and cloning process.

IT admins should consider a provisioning system as a part of this process. Using a provisioning system can be more work, but it generates the golden images as the basis for cloning.

4. Run user acceptance testing

User acceptance testing (UAT) helps IT determine whether user experience will be an issue. Again, third-party testing tools such as Login VSI can help with this by using virtual users to test the performance of desktops.

IT staff should also involve a few real users with testing because there may be delays with screen refreshes or other issues that automated tools won't track.

This step should also include application testing. The testing process for the virtual applications can differ significantly based on how the organization's VDI is set up. There are numerous ways to host and deliver virtual applications with methods such as application layering and application streaming. This makes the troubleshooting process extremely unique on a case-by-case basis, but the testing process focuses on the same goal for most organizations: Replicate a user activity.

IT will need to open and interact with applications in the same way users do. In some cases, this means opening multiple applications and switching back and forth between them. In other cases, this may involve interacting with one resource-intensive application for a long period of time. Once IT has replicated the user behavior, they should compare the performance for the benchmarks they set in step three. Additionally, IT should involve real end users that will use the applications during this step -- not just IT staff.

5. Go over UAT performance results

While users' issues with logon times may be more complicated in practice than during a test, it's an important step to ensure there aren't any major resource issues or machine configurations that take an exceptionally long time to load.

Resource shortages during boot storms can cause major delays for users attempting to log on, leading to user frustration.

Boot and logon times are some of the most important performance metrics that IT professionals can measure. While IT professionals aren't likely to cause a boot storm with a few test machines, they can extrapolate to see if the logon times are acceptable in a test environment.

IT admins should also check access to peripherals during this step. If the VM is expected to interact with any external devices, such as printers, additional monitors, a Bluetooth mouse or USB flash drives, then IT professionals should test the virtual machines to see if they can do so successfully.

For example, virtual machines generally rely on the host machine's mapping and configurations for interactions with external and auxiliary devices, so VDI admins should check if the endpoint itself can connect to the devices. If the endpoint is connected to a device but the virtual machine is not, IT should be able to edit the machine's hardware settings or check policy settings to add a new device connection.

This step should verify users' access to files they may need for their work. While organizations that use an enterprise file sync-and-share service generally don't rely too much on users opening and editing files from drivers, other users need to access these shared drives frequently. Still, in many cases users will need at least some access to certain drivers, so IT professionals should open the Windows File Explorer to make sure all the required drives are available.

6. Remedy known issues

If there are unexpected issues or anomalies that IT encounters, the event log in a VDI platform -- or better yet, the vendor's monitoring system -- could hold the answers to what is going wrong. Even if the virtual machine is running perfectly fine, VDI admins should still look through the event log to make sure there are no unexpected events. Admins should then cross-reference any error messages or unfamiliar events with the VDI software vendor's known event catalogue, which should be readily available with its online documentation.

For example, one option VDI admins have to fix slow boots and logons is to add more IOPS. Admins could also configure virtual machines to begin the booting process a couple hours before users typically log in. This way, the pre-booted machines are ready as soon as the users type in their credentials. Slow boots can be due to a host of other reasons as well, such as RAM, network or user profile issues.

VDI testing vendors and tools

Virtualization vendors provide testing tools in products such as VMware Workstation and Citrix Workspace that IT can use to run a test deployment as part of a VDI testing checklist.

Each tool has its own set of directions to follow, but with VMware Workstation, IT professionals should start the testing process by defining the conditions of the VM that will run the test, including the application usage and available disk space, RAM and CPU for each desktop. IT must define the host itself, in this case, VMware's ESXi hypervisor.

Once the test deployment is ready, IT should open its virtualization platform management console, in this case, VMware vCenter, and instruct it to add the ESXi host and run the test VM. At this point, IT should integrate the VM into Active Directory (AD) to track, alter and manage the test deployment.

For Citrix virtual desktop deployments, the VDI test team can use the Citrix Quick Launch Tool for VDI performance testing and capacity measurement. However, this tool may be insufficient for some organizations' needs, as it has limits, including a 30-account maximum to test. In that case, virtual desktop administrators should turn to a third-party testing tool from vendors such as Login VSI or EG Innovations.

Citrix admins that are running a test should start by specifying the server or servers in the data center via IP address or XML command. Then, IT can set the customizable options for the test session, including checking client printers, display type and bitmap caching. Just like the VMware VDI test, a Citrix VDI test targets an AD domain.

Measuring VDI test results and retesting

With the results of the VDI test, IT professionals now have more information on how their performance and resource requirement estimates will hold up in reality. If the test results indicate over- or under-provisioning, then IT should rework estimates and run more tests until the VMs perform at a satisfactory level.

IT pros must go beyond simply looking at logon times to determine the test's success; they must also factor in any crashes, latency issues and hardware or software compatibility problems across all user types. AD and the VDI management console should provide IT with the necessary performance metrics to judge the results.

IT pros should approach their supervisors or executives with their results, the comparison to the previous benchmarks and any other relevant data. Organizations need administrators and decision-makers to discuss the best options moving forward, which could include increasing VDI resource pools or using different virtualization technologies entirely.

When the VDI test yields results that align with estimates, IT can move forward with its deployment plan. IT pros may encounter unexpected issues when they scale up the deployment to their entire organization or alter the VDI with security patches, OS updates or other new software components. However, testing the VDI plan in advance ensures that major provisioning or performance issues won't blindside IT.

Dig Deeper on Virtual and remote desktop strategies