This helpful video shows how to quickly get started with Login VSI and explains all the steps to perform your first test such as installation and configuration of Login VSI.
This video contains audio
3. Environment overview
A Default Login VSI implementation consists of 4 components:
AD Domain controller for user accounts and standard policies
A file share for central configuration and logging
Launcher workstations (Master and Slaves) to initiate the sessions
Target platform (VDI or SBC) where the user load script are installed and performed
4. Test scenarios
With Login VSI you can compare one of many many different scenarios:
Impact of changes or updates like service packs or security fixes
VDI vs. SBC / x64 vs. x86
VMware/vSphere, XenServer/XenDesktop or Microsoft Hyper-V (or any other hypervisor / broker) running virtual desktops or
Terminal / Citrix Servers
Virtualized Windows XP desktops versus virtualized Windows Vista / 7 desktops
Performance impact of application streaming technologies
Impact of (different) virus scanners
Performance impact of tuning parameters
Different storage platforms
Etc…
5. Design requirements
When the development of Login VSI was started, the following requirements were defined:
Login VSI is a benchmarking methodology based on the amount of simultaneous sessions that can be run on a single physical machine running either bare-metal or virtualized operating systems.
The results must be easily replicable; this means that the free Login VSI version cannot allow any customization to the load scripts.
The purpose of Login VSI is to compare platforms and technologies, specifically not to predict the exact amount of sessions you can run in your own production environment. Such predictions are impossible, since this completely depends on the application set and how these applications are used in practice. Those who are interested in customizing the benchmark for tests with their own applications should use Login VSI PRO.
Login VSI should run a realistic user workload. Therefore, every user session will simulate a medium workload user (office worker) with generic applications like Microsoft Office, Microsoft Internet Explorer including Flash applets and Adobe Acrobat Reader. Like real users, the scripted session will leave multiple applications open at the same time. Every session will average about 20% minimal user activity, similar to real world usage.
The workload is performed by scripts (AutoIt based) on the target operating system. This makes Login VSI independent of virtualization platforms and the remote desktop protocol used. The overhead of the AutoIt scripts used will never exceed 5% and averages below 1% per session.
The setup and configuration of Login VSI is simplified where reasonably possible: this helps ensuring that the results can be replicated by others and Login VSI can be used like any other benchmark tool.
Sessions must be started through a remoting protocol (ICA, RDP or other) at a resolution of 1024x768. Each session must remain connected for the duration of the tests since the overhead of the protocol does influence system performance and the workload scripts can only function within a connected session.
Login VSI is platform independent:
Support for Windows based Presentation Virtualization platforms (Server Based Computing)
Support for Windows based Desktop Virtualization platforms
Support for Windows based Application Virtualization technologies (Application Streaming)
Support for both Windows x86 and Windows x64
Support for Microsoft Windows XP, 2003, Vista, Win7 and 2008 and 2008R2
Support for Microsoft Office 2003, 2007 and 2010.
Support for Microsoft, Citrix, VMware, Provision IT and other presentation or desktop virtualization vendors through a custom command-line to launch session.
User sessions will start every 30 seconds in sequential launch mode, this is not customizable to other values in Login VSI Express (Login VSI Pro offers full flexibility with the launch interval).
Every session will run completely local: there is no connection to back-end services or external applications (client printers, home/group drives, roaming profiles, Microsoft Exchange, printers, databases, webpage’s, etc...) with the exception of a file share for logging and controlling purposes. This ensures that the result is not dependent on back-end services or other external factors.
In a virtual desktop environment it is not required to create multiple users when the de-duplication of memory pages is disabled on a virtual infrastructure level, as there is no back-end connection in the session. Since every user session environment is running isolated on a virtual desktop, using single or multiple users will not impact the test results.
In virtual desktop environment where de-duplication of memory pages on a virtualization platform is enabled, unique test accounts and therefore unique profiles need to be pre-created in the workstation image. This prevents unrealistic de-duplication of memory pages by using a single user account.
This video contains audio