Whether IT is upgrading an existing VDI deployment or implementing VDI, there are a series of tests it should run, including making sure users can access their virtual desktops.
Before deploying or upgrading a VDI deployment, IT should perform thorough tests to ensure that the rollout is successful.
The amount of VDI testing IT should do depends on the scale and criticality of its deployment. A general purpose VDI deployment for 20,000 users, for example, requires some serious VDI testing. A VDI deployment for 150 workers in one department who only work from the office with zero clients, on the other hand, requires far less testing.
No matter the size of the VDI deployment, there are six critical areas IT should test. Some of the tests are only useful as part of the deployment process. Others should be part of ongoing monitoring of the VDI platform.
Test access
IT should make sure users can access their virtual desktops from:
Their current devices, including laptops, desktops, smartphones, tablets and thin clients. IT should also make sure access is smooth, with no warnings or errors that might confuse non-IT users.
Different locations, including in the office on the wired network and on the office Wi-Fi.
Remote offices, such as a factory or warehouse network.
Home networks.
Public locations, such as Wi-Fi at a coffee shop.
Business partner networks.
Test printing capabilities
Printing problems are a common source of pain with VDI, so IT must make sure that the nearest printers work at each location where printing is allowed. IT should also make sure that users can perform different printing functions, including using specialized printers that can handle unusual paper sizes, duplex printing, and even booklets and banners, as necessary.
How well does a VDI deployment fit?
Test applications
The hardest part of any VDI testing plan is ensuring that applications can meet the users' needs. To really test that applications function correctly, IT must monitor real users doing their normal jobs.
A quiz on VDI access for mobile
Users require access to virtual resources on their mobile devices. IT can manage VDI on smartphones and tablets using authentication methods, individual virtual app delivery and more.
Large organizations, particularly those with custom applications, may have approved test plans to validate applications. In smaller organizations, the testing may be more organic, with some IT-savvy end users piloting the system.
Test performance
There are many dimensions to VDI performance that do not come up with physical desktops. Even changes in VDI architecture are a challenge.
For example, if IT moves a group of users from persistent virtual desktops -- where users can customize their desktops -- to nonpersistent desktops -- where the desktop resets each time the user logs out -- and changes from local profiles inside the persistent desktops to roaming profiles that follow the users to each new desktop they log in to, login times can change. This happens chiefly because users with persistent desktops often stay logged in for long periods of time and don't have to log out as often. It could take a few days for the users who were accustomed to persistent desktops to acclimate to the extra 30 seconds of login time they have to sit through with nonpersistent desktops.
Login time is such a fundamental aspect of VDI performance testing that many VDI monitoring tools proactively launch sessions and monitor login times regularly. These same tools can often perform basic application tests, such as logging into an SAP application inside the virtual desktop and reporting on performance.
Using a desktop application performance monitor before and after moving to VDI can help reduce finger-pointing.
Application performance can be very subjective, too. People often blame VDI changes for latency issues with application performance. Using a desktop application performance monitor before and after moving to VDI can help reduce finger-pointing by showing people other sources of performance issues. The tools that help IT identify user application requirements before VDI migration can usually help quantify performance after the deployment.
IT professionals should not overlook their own needs when VDI testing for an upgrade or implementation. They should test the time it takes for IT operations tasks, such as creating a new desktop VM or updating a pool to use an updated base VM.
Test failures
IT's best opportunity to test what happens when things fail is before the deployment is in production. IT seldom gets permission to intentionally cause failures after a system is live.
Test what happens to access when a broker is down or if a hypervisor host fails. If something fails, IT must be able to make sure that users can still access their desktops to get their work done.
Test upgrades
Most of these VDI testing methods are as crucial for an upgrade to a VDI platform as they are for the initial deployment, but there are some additional tests reserved for VDI upgrades. One test is to make sure older VDI clients still work with the new version. In one instance, VMware Horizon View actually disabled some old Secure Sockets Layer (SSL) ciphers on some older zero clients.
IT should also be mindful of what carries forward from the old to the new. For example, some upgrades just reuse old SSL certificates with their original expiration dates. If the certificate has a five-year life, the upgrade may not add five more years before the certificate stops working.
Dig Deeper on Virtual and remote desktop strategies
