Summary

This is to describe some use cases, best practices, and what to look out for regarding Login VSI 4.x debug logging. During troubleshooting looking at Login VSI logs can be helpful.

Usage notes and best practices

• The newest log lines are at bottom of file
• When the test is running, the banner (vsi.exe) will be red on the targets. It's usually orange.
• Recommend having debug logging toggled off when not performing troubleshooting. Though the text files are small that are generated and uploaded to the Login VSI server (only a couple of KBs), they will still generate networking and IO overhead especially in large tests
• The results end up in \\{Login_VSI_server}\{Login_VSI_share}\_vsi_logfiles\{test_name}\debug\ EngineLogs and WorkloadLogs
  Note in some cases logs won't be generated at all if the Login VSI target Engine, vsi.exe, doesn't detect an issue. For example, if client antivirus prevents vsi.exe from successfully running.
  
  • They are also found in %temp%\vsi on target profiles when a test is in progress. This can be helpful if logs aren't ending up on the server for whatever reason
• Some cases they can be helpful looking into and diagnosing (among many others):
• Where the Login VSI engine (vsi.exe) is getting stuck during invocation, sometimes even if the test banner doesn't become visible
• What workload function was being performed when a session got stuck
• Which windows were open when a stuck session occurred should be outputted as text
• Where to enable:
  

See also

• Data to collect for support ticket requests
• https://www.loginvsi.com/documentation/index.php?title=Login_VSI_Management_Console#Workload_2