It has been a while but now it’s time for another VCDX56 blog sponsor blog post. This time its Login VSI that will describe their product/offering and it will include the following:

• What it is
• What are the usage areas
• How it works
• The main components in a test
• Potential pre-reqs

So here we go, from no on it’s text and pictures provided by Login VSI

Login VSI

What is Login VSI, and what are the usage areas?

Login VSI is a software product that simulates real-world users in your VDI environment. There are good reasons for how this could useful for a company. One reason could be that you are a critical member of the IT department and wish to benchmark a newly deployed VDI environment. Or, you are a consultant who, because of knowledge and experience might feel confident in the VDI environment you have built, wants to prove to the customer that the environment meets the project requirements or that user experience is as expected. Login VSI could be used for both of these purposes.
Another common scenario is that you have an existing VDI environment and you wish to perform a change within it. How do you ensure that the planned change does not have a negative impact on your environment’s user scalability or user experience? By running a Login VSI test before and after the planned change, you can evaluate the impact. It could be a Microsoft Office, antivirus or business critical application update that you wish to implement, for instance. In the blog post referenced here, you can read about how an upgrade from Office 2010 to 2013 in our testing reduced user scalability by 20%, as an example.

Microsoft Office testing performed by LoginVSI

How does Login VSI work?

So with two above reasons (planning/assessment and change impact analysis) for using Login VSI defined above, how does Login VSI technically work? If an administrator wishes to run a Login VSI test, there are a few things he or she needs to specify:

• How many users do want to simulate in the test?
• For how long should the test run?
• Should the test users be logged on slowly or quickly?
• Are we simulating a user login storm?
• What should the test users perform in their VDI sessions, what applications should they run?

In addition to above, the administrator needs to prepare the VDI environment by generating the Active Directory users that will used in the test, and to bind a GPO (provided by Login VSI) to the Login VSI test users. These steps can be done either manually or with a script automatically generated by the Login VSI software.

For specifying what actions the simulated users should perform during the test, Login VSI makes use of pre-defined workloads that we ship with the product. Currently there are four of these workloads – TaskWorker, OfficeWorker, KnowledgeWorker and PowerWorker. Each one represents a different real-world type of users, and you can read more about the workloads here. For instance, a PowerWorker is a heavy user that will run many applications and put more load on your environment compared to an average user. The administrator preparing the Login VSI test should select a workload, or a combination of several, so that the Login VSI test best represents the VDI user base.
The workloads are text files that make use of a script language Login VSI has created, and this language is in turn based on AutoIT. You can read more about our script library here. If you wish to run a Login VSI test that incorporates your custom business application(s), or if you wish to make changes to an existing workload, this can easily be done by using Login VSI’s script language to create or edit workloads.

What are the main infrastructure components in a Login VSI test?

In the Login VSI infrastructure, you have four main components.

• Launcher machines, which will generate the user sessions
• Target machines, which are your VDI or SBC machines
• VSIShare which is a Shared Folder on one of your Windows File Servers
• Active Directory where the Login VSI test users reside.

A brief summary of the process flow of a Login VSI test is outlined below.

1. An administrator prepares a Login VSI test by specifying the test parameters
2. The test is launched and the Launcher machines start generating user logons (users are logging on to their VDI desktops)
3. When a user is logged on, an executable called VSI Engine is automatically started. The VSI Engine will run the workload specified by the administrator, and the actions in the workload will start to be performed. User simulation begins.
4. Throughout the test, measurements are taken from each user and stored. These measurements include, but are not limited to, response times for opening applications, time it takes copy a file or time to zip some files.
5. Test is completed and the data from test is now viewable in Login VSI Analyzer. The Analyzer will present the data in graphs and show, among other things, your VSImax value. The VSImax value is the amount of users your environment can handle before user experience becomes too poor.

In a PoC, you can experiment with your VDI environment or your VDI Golden Image(s) and re-run tests to see how different configurations generate different VSImax values. This is a great way of building an excellent VDI environment, in addition to relying on your own expertise and available VDI Best Practices.
Showing data from a Login VSI test. The X (114 active user sessions) marks the spot where VSImax was reached.

Do I need to know anything else to run a successful Login VSI test?

There are numerous customizations and tweaks you can perform for your test, and we at Login VSI have best practices on how to run an optimal test. I would recommend that you read our documentation and blog posts, or contact us directly to receive guidance. Below are some things to keep in mind:

• If you have non-VDI related VMs running on your physical servers that are hosting your VDI machines, they can impact your VSImax if they are powered on during the Login VSI test.
• If IO-heavy operations are running on your shared storage (such as backups being taken) during the test, that can have an impact on your VSImax
• Always reboot your VDI machines or SBC Session Host servers (XenApp servers, for example) before running a Login VSI test, and then wait 30 minutes before starting Login VSI test (it takes that long for VMware’s Transparent Page Sharing, TPS, to kick in)

If you have any further questions, feel free to contact me through email at info@loginvsi.com.