Login VSI Automation – Completely Hands Off

Finally! I’ve been working on Login VSI Automation for at least 6 months now. This has been running fine in my small lab with tests of VSImax of 25, but my limit has always been CPU.

Luckily I was invited to Rick Dehlinger’s SilvertonHCL Project which is running on some amazing Cisco HyperFlex hardware. My role in the project is to use my Automation Framework to rapidly provision VM’s and of course Login VSI tests.

For those of you that have followed Project VRC knows there’s tons of tests to be conducted, and they are VERY time consuming. So the goal of this post is to show you what I’ve cooked up to do Login VSI Automation. The goal is to simply start the test and pick up the results 15 hours later.

Login VSI Automation

Login VSI Share

The setup is straight forward. Download the latest version and extract the content to the $Version folder below and run the script.

Then completely remove Windows Defender

or add the LoginVSI folder to the excluded folders

Configure and run the Active Directory Deployment script and finally give the LoginVSI group Share and NTFS modify rights.

Login VSI Launchers

When I was running in my home lab I just needed 1-2 launchers, but if you e.g. want to run a 1000 users VDI test you’ll need at least 40 launchers! I could fix that with my Automation Framework but that’s more work than I wanted and tons of wasted storage. Time to think outside of the bubble…

Ahhh, why don’t we install Citrix VDA on the Launcher Master Image and use Citrix Studio with MCS to handle it all? Freaking genius if you ask me. Just remember to put them into the Launcher Organization Unit.

Login VSI Automation

There are many advantages of this approach and it gives us a very easy way to update the launchers & power control which I’ll talk about later.

Login VSI Targets

The targets are the actual workers. The Master Image was built using my Automation Framework and we just pointed to the default Login VSI Target Setup.

Login VSI Automation

Put them into the Target Organization Unit.

Login VSI Preparation

Before we actually dig into the rest, make sure you can successfully connect to one of your launchers through RDP. I’m using GPO to add the user Launcher-v4 to the local Remote Desktop Users group and to Enable Remote Desktop Services.

I would also HIGHLY recommend using ControlUp to monitor the real time health of both Launchers and Targets.

Login VSI Automation

Login VSI Automation

So finally the script we all been waiting for. My script is based upon this post Scheduling automatic Login VSI performance tests for your virtualized desktop environment.

Issue 1 – PowerShell Remoting

The original script used PowerShell Remoting, which is extremely hard to configure in a one-way trust domain setup. After lots of testing I found out that I didn’t really need it because the Launchers & Targets needs to reboot anyway in between each test loop.

Issue 2 – Remote Computer Verification

Microsoft RDP throws out a stupid warning which you need click OK on, lots of work for 40 launchers. The Registry key below fixes that.

Issue 3 – Unstable Test Results

The “old” rule of thumb has always been to restart and wait 15 minutes for the VMs to settle down. Well that doesn’t apply to Windows 10 & 2016.

Using ControlUp I found out that I was on the safe side when letting the VMs settle down for 40 minutes.

There could be many reasons for this, OS not optimized, Windows Defender running etc, but before you start to do optimization you NEED to find your Baseline VSIMax.

Issue 4 – Restarting Launchers and Targets

This was a funny one. When I really pushed the limit of the VMs they ran out of memory and/or CPU. Guess what, VM tools stop working so the normal shutdown /r /t /m command won’t work any more. Time to think outside of the bubble…

Login VSI Automation

We could of course use some PowerShell magic to connect to the Hypervisor, but then we would expose the credentials in the script and we would need a section for each and every Hypervisor.

So why don’t we use Citrix PowerShell SDK instead? That way no credentials is needed, because they’re already stored in Citrix Studio, for your favorite Hypervisor.

Just make sure you run the Login VSI Automation script from your Citrix Delivery Controller.

Issue 5 – Microsoft RDP

So after the first loop runs successfully the Launchers will restart leaving X number of broken RDP Windows. So I simply kill that process which seems to work fine.

Login VSI Automation Script

Make sure to run some small loops before going all in. A normal 10 loop test will run for around 15 hours…

Conclusion

First of all I want to dedicate this post to Jasper Geelen the support hero of Login VSI. Without his help this post would never been published. I still live by the fact that everything I publish need to work over and over again, just not some bullshit for publicity.

That being said, it’s not perfect and I’ll continue to improve it. But there’s been too many sleepless nights so I wanted to hand it over to the community so we can improve it together. Please submit any feedback in the comments below. Enjoy your VSIMax.

PS: Results from future tests will be published on CUGC, make sure to follow the SilvertonHCL tag.

Leave a reply