To ensure a successful Virtual Desktop Infrastructure (VDI) implementation it is highly recommended to include in the project planning and pilot phases ways to understand the workload a certain architecture may handle. Use tools to measure and meet performance and scalability requirements, baseline the start point of the environment and model future growth or changes to avoid unexpected surprises when going from the pilot and grow to a production environment (not even talking about the costs to recover from all those surprises). 

But how will you measure if the architecture can be, or is, up to the right numbers? There are a some ready tools around to help getting those numbers and VD load simulations. One of them is specific for VMware Horizon VD environment. I have written about it in a few blog posts back, I’m talking about VMware view Planner (read it here: https://www.pascalswereld.nl/post/66369941380/vmware-view-planner).
And of course vCOPS (for view) is also capable in giving you insights in your environment and giving future predictions (limited!).
In some way DesktopDirector/EdgeSight are capable of giving you valuable insights in your running Citrix environment. But modeling for future changes and load seems to be less worked out in those products. If you are like me working with both VMware or Citrix VD (shared and one-to-one) solutions, you probably want a less locked in product as VMware View Planner obviously is. Have something ready to deploy with all sorts of VD and go for the numbers. Well you can with Login VSI. This blog post I wanted to take an initial look at Login VSI. A little what and a little how on the installation. In part two we will give Login VSI a little spin and end with a conclusion.

What, Login VSI you say? That rings a bell..

Login Virtual Session Indexer (Login VSI) is the industry standard bench marking tool (at least that is what is claimed on their website) for Windows based VD architectures. It is used to test the performance and scalability of virtual desktop environments like Shared VD or Server Based Computing (SBC) and one-on-one Virtual Desktop Infrastructures (VDI). Login VSI is vendor independent on the sort of VDI. Login VSI is targeted mainly on the Windows VD image. It can test VDI’s like Citrix XenDesktop, XenApp, Microsoft, VMware Horizon View or any other Windows based SBC or VDI architecture. 
Login VSI is used for testing and bench marking by a great number of major vendors in the field (you will see Login VSI in a lot of those vendors whitepapers), and is often recommended in the technical community.
Login VSI works with pre-defined user workloads (also you are able to customize for specific needs, and you probably will), results are provable and repeatable. Login VSI is easy to use and can be deployed very quickly.

Some basic categories Login VSI can be used:

• Benchmarking; testing and comparing the performance of different software and hardware solutions in your own VD environment. 
• Capacity Planning; planning the optimal infrastructure configuration (right sizing) to support the desired number of users and applications.
• Load / Stress Testing; measure the maximum capacity of your current infrastructure. The simulated user workload is with the same applications as your average employee will use. These standard include Word, Excel, Outlook and Internet Explorer. You can easily add your own custom applications to the tests.
• Change Impact Analysis; Test and predict the impact of any change in software and hardware, on the performance of your VDI or SBC Infrastructure.

All this helps you to make educated and objective decisions instead of guessing. Know your workload and know how your environment can deliver them and what the limits are. Minimize the possibility to be surprised (again) by unexpected performance issues.

The Login VSI architecture

The Login VSI consists of:

• A VSI Server or data server as central infrastructure component. Here is the file share, web service (some testing websites in IIS) and license service (via the share). The share is used for binaries (launchers), log location, scenario’s etc. The web site is used for the launcher to open up some websites (for example there is a BBC home site in there).
• One or more VSI workload launcher/analyzer client or servers. These are the workhorses of the Login VSI infrastructure by launching the workloads and analyzing the received counters, converting the response time measurements into clear graphs and automatically calculates the maximums of the tested environment. Multiple launchers are needed when wanting to increase the number of VD sessions you can test.
• AD DS for storing OU’s, Users, Security groups and GPO.
• VD infrastructure(s). Targets for the launchers and your Login VSI workloads. VMware Horizon View, Citrix XenApp, Microsoft RDS or Citrix XenDesktop workload. On the workload/target client or servers client components need to be deployed to connect correctly to the environment (for example VMware Horizon client is not included in Login VSI).

All this together is shown in the following graphical model.

Installation

Installation is straightforward and can be easily done with the instructions from the Login VSI site (http://www.loginvsi.com/documentation/index.php?title=Installation). Be sure to have .Net 3.5 Framework Feature set up before starting the data server installation. Also running the AD DS scripts needs the RSAT – AD DS – AD LDS tools and the Group Policy Management features to be in place for the PowerShell cmdlets to be recognized. A domain controller as described in the documentation has this tools ready, but I’m not really fond of using domain controllers as an installation start point, leave the domain controller alone for the roles/services it is doing for you infrastructure. I rather install these components on the Login VSI data server. And last have the Web Server role (IIS) setup. Change the default website location to access the VSIShare_VSI_Websites.

The installation procedure is as follows:

1. Get a license. You can evaluate for 30 days with a 50 user license.
2. Prepare File Share. Add VSI_Share to a system with appropiate permissions.
3. Add a LoginVSI user to the AD DS with access to a root OU where it can create OU siblings, user objects and security groups. Don’t use the default LoginVSI username as the PowerShell script from the management console tries to create a group object with exactly that name (LoginVSI) what isn’t allowed if you already used that name as user (object already exists). Further more Login VSI needs permissions to add and link GPO’s to the OU structure. (Optional but highly recommended, else it is creating the structure manually without the help of some prepared PowerShell scripts).
4. Install Data Server (unpack installer). Uncheck the start console, we first want to patch and save license.
5. Patch 4.09. Install over existing.
6. Save License file received (download from site when receiving the authorization code via e-mail). License file has to be place in the _VSI_Configuration subdirectory (when the VSI_Share is created on D:VSI_Share, this will be D:VSI_Share_VSI_Configuration or via \servernameVSI_Share_VSI_Configuration).
7. Start the console from _VSI_ManagementConsole. Let it select the default location and flag the license file in the share.
8. Choose your continent for the EULA and accept (and of course I mean read it before you accept, yes…really.. I do..read it…there is ehhhm.. in there ….and some other….ehhmmm…just read it ok?!).
9. And the console starts up. From here you can setup AD DS connection, Launchers, Scenario’s, Data servers, Connection to VD targets and step 6 Gentlemen start your engines.

Be sure to log on with a domain account before setting up AD from the management console, else the binding from the console will not work. Use the AD DS connection to create the scripts for you to prepare the environment (via ps1 or ZIP with the scripts & GPO when you don’t have enough permissions and someone else needs to do this). Before you run the provided PowerShell script, you will have to change the PowerShell execution policy. Change this to RemoteSigned with Set-ExecutionPolicy RemoteSigned command.

Be sure to fill in your values accordant to your test.. 

Afterwards the following is added to your environment (I just used root dc=testlab,Dc=local).

Next up step 2 launcher. The launcher is used as a workload broker for your target VD infrastructure. Per 50 users you need approx. 2 vCPU and 4GB RAM, and the client to connect to the target. Prepare a Windows VM and add the agent for the appropiate VD targets (type of Windows is key here). Just add the launcher by it’s FQDN to the Login VSI management console for the amount of user connections it will handle. Depending on the sort of workload the maximum per launcher is 50 sessions, for multimedia workloads do not exceed 20 sessions per launcher.

Next up creating a target connection. A target is the VD environement (Windows VD or Windows server for shared VD) you want to use the Login VSI tests. Setup a connection from connection Wizard (test setup connections or step 5 from the start screen).
Before using the VD image, you can use the target setup from the Login VSI installer to install workload applications, only office should be installed separately in the benchmark image. Other like Adobe Reader, Adobe flash, Java runtime and DoroPDF can be installed from the target setup.

Test driving

I want to test drive Login VSI in my testlab. This is a nested VMware View test infrastructure in a notebook environment (view-in-a-notebook if you would like). This will only show you the works and some basics abouts. It is in no way an environment for a what can this VMware product handle as limits or good figures as this lab environment isn’t capable of delivering any.

……..

At this time I’m thinking this blog post is long enough already. I’m saving the test drive in my lab and conclusion to a part two. We will be right back (cliffhanger) at the same bat channel.

And in the mean time, if you can’t wait take it out for a spin yourself.

– Happy load testing your VD environment!