login vsi company logo login vsi company logo 250x40

Test Run hangs on Launcher Check

  • cobrien
  • cobrien's Avatar Topic Author
22 Jan 2014 21:42 #1592 by cobrien
I am running LoginVSI Pro, and I am running into an issue trying to launch tests. I have setup a simple RDP-based Medium workload test. When I am running the Start Test Wizard, I get through the settings to the Launcher Check screen. Once there, the defined Launcher(s) will simply sit with a status of Waiting...

The launcher that I have defined definitely launches, I can see the RDP connection, and I can see the desktop load. Inside the launcher RDP session I can see that the Launcher Agent is running as well, with "Waiting for test to start *" as the text being displayed. The stars will continue to cycle as it waits, but it never goes beyond that point.

The LoginVSI Session Monitor shows a current status of "Waiting for test to start" and the Test name is listed as "None" though I have selected the Medium Workload in the Test Setup screens of the Management console.

Any ideas? I had a ton of issues getting the management console to connect to Windows 7 based launchers to begin with, so I am hoping I am not missing any other undocumented settings (ie - a registry key to enable RemoteRPC needs to be altered in order to allow a default Windows 7 Pro install to work as a launcher, which isn't listed in any documentation I have found). Any ideas or help would be greatly appreciated!

Please Log in to join the conversation.

22 Jan 2014 23:43 #1593 by o.bouhaj
Hi Cobrien,

Thanks for the feedback. We know that Desktop OS are not yet supported by default with the Launcher Workflow, because of the RemoteRPC value. We are already aware and suggest to either apply that work-around (which will be documented) or to use Server OS.

- Did you add the Launcher machine(s) by 'host-name' (part of Add Launcher in /VSI Management Console (MMC))?
- Is the VSIshare configuration setup for either a Group of Test users (default, LoginVSI) or specific users with 'Modify' permissions, Make sure that they can read/write.

Let me know. Thanks,

Please Log in to join the conversation.

  • cobrien
  • cobrien's Avatar Topic Author
23 Jan 2014 13:42 #1599 by cobrien
On the desktop OS note...I wish the documentation was more clear on this point. The only listed requirement is a "Microsoft Windows based OS". The VSIshare requirement specifically asks for a Server OS, but the other requirements aren't so clear.

When adding the Launchers, I added them via hostname, FQDN specifically. In the Management console, where the Launchers are listed, I am able to right click on them and get successful ping tests, reboots and RDP session launches.

The share was setup with group permissions, as follows:
Local Administrators for the hosting server: Modify
LoginVSI Domain group: Modify
LoginVSI Access group created for internal reasons: Modify

The NTFS permissions are setup in the same manner. As far as I can tell, the Launcher account, and any others I have used, seem to have permissions to the share.

One point of note...internally we have a policy to create shares as hidden by adding a "$" to the end of the share name. Since the Launcher Agent seems to run, and LoginVSI was able to work with it, I didn't think anything of that decision. Would that present any issues?

Please Log in to join the conversation.

  • cobrien
  • cobrien's Avatar Topic Author
23 Jan 2014 18:10 - 23 Jan 2014 18:14 #1602 by cobrien
Ok, so I have noted that, depending on which set of Launcher instructions you look at, you may or may not be warned that using the FQDN won't work. I was using the Getting Started and Installation guides to get the environment ready.

For starters, that's unfortunate, as I really need to have support for FQDNs. The workarounds to make name resolution work without specifying the FQDN aren't ideal, and I worry that I am not getting an accurate picture of the environment when I short-circuit DNS. Is this just a bug that is being worked on?

I seem to be able to get the tests to launch now, but they seem to be hanging on the basephase now. I am working on verifying the target config now.

Please Log in to join the conversation.

23 Jan 2014 18:16 #1603 by o.bouhaj
it is a requirement to add the launcher by hostname. this is only for the launcher part, is that an issue?
how you mean by accurate picture? you name your launcher to a name point that makes sense, for example: Launch001, Launcher1 etc etc.

Not sure what you mean by is this a bug?

the launcher has nothing to do with LoginVSI measuring/calculating the threshold of an testing environment.
if you need help please contact support<at>loginvsi<dot>com


Please Log in to join the conversation.

  • cobrien
  • cobrien's Avatar Topic Author
23 Jan 2014 18:34 #1604 by cobrien
Our network has several hundred domains in DNS, due to the nature of being a hosting provider. For various reasons, it isn't feasible to put a list of DNS suffixes into the network configs of our servers. On top of that, the main environment we want to test consists of a resource domain and a user domain.

So if I simply specify my Launchers by their name, without specifying the domain, the names won't resolve, and the VSI management console won't be able to talk to them. In order to get around that, I have to create host file entries, which basically short circuits the DNS infrastructure entirely.

I doubt it will amount to much, but I don't like the idea of having to cut pieces of our infrastructure out. And if we want to run these tests against customer systems, I would likely end up with a Launcher that is in a different domain than the admin console. I could create a host file entry to point the admin console to the launcher, but the Launcher itself won't be able to find the VSIshare without its own host entry.

I am asking if it is a bug because it seems, well, odd that FQDNs wouldn't be supported. It would make setting up a testing environment much easier with our setup.

Please Log in to join the conversation.

24 Jan 2014 16:16 #1605 by o.bouhaj
Thanks for the feedback!

We have put your request to be developed in a upcoming release (patch).
ETA; not known yet . But I will update you.

PS, Let me know if this requires priority and if you can continue at this current moment.


Please Log in to join the conversation.

  • cobrien
  • cobrien's Avatar Topic Author
24 Jan 2014 16:22 #1606 by cobrien
Omar - Very much appreciated! Thank you for the update.

At this point, I have successful tests running with the StoreFront connector against XenDesktop 7.1. Some things aren't working quite like I expect them, but I am working on scaling up the test environment now. If I see anything unexpected when I start running tests again, I will submit an email with my questions to the support address.

I greatly appreciate the insights so far!

Please Log in to join the conversation.

Login VSI, Inc.

3945 Freedom Circle
Suite 670
Santa Clara, CA 95054

Phone: +1 844 828 3693

300 Tradecenter
Suite 3460
Woburn, MA 01801

Phone: +1 844 828 3693

Login VSI B.V.

De Entree 85
1101 BH Amsterdam
The Netherlands

Phone: +31 20 705 1200