VMware App Volumes 4 – Testing Logon-times

Release date: March 10th 2020

Welcome to my VMware App Volumes series. With the release of App Volumes 4, I was very curious about how this new release would affect logon times for virtual desktops. I therefore did an “extensive” test in my lab environment, consisting of two old IBM X3650 M4 servers, connected to an old IBM SAN via fiber. The are absolutely no SSD or NVME to accelerate logon time in my lab. Bearing this in mind, the results from these tests aren’t the logon times in themselves, but rather the percentage increase in logon time. This to get an indication of what we can expect in a production environment.

In my test, I created 3 desktop pools with 3 different Windows 10 builds. The desktop-image was as identical as I could get them. When it comes to which applications I have picked for this test, I believe I have chosen a good diverse collection of applications of different size and complexity. I have previously created a session about capturing applications for App Volumes 4, posted here: VMware App Volumes 4 – Capture Application. In order to create a baseline, I logged into the desktops tree times to get a good reading up front. The logon times, I collected from the Vmware View logon monitor logs. I also made sure that there weren’t any other operations running on the storage during my tests, this to ensure the most comparable result as possible.

In my first test, with a Windows 10 1809 desktop, the initial baseline logon time was 17,46 seconds. (Not horrific when considering the underlying hardware). After having added all of my applications, the logon-time had more than doubled. The most interesting result from this segment of testing, is the percentage increase when adding GIMP and LibreOffice, which are the biggest vmdk’s in size. The logon time increases by 187 % when attaching the LibreOffice application. Knowing that all the images have the same App Volumes Agent installed and the same virtual hardware, this result somewhat puzzled me, because this is not something I saw when I did the same tests on Windows 10 1903 or Windows 10 1909.

The table below shows the exact result from the Windows 10 1809 test.


I’m not exactly an expert in using MS Excel, but I wanted a little graphical presentation of my findings as well. In the graphs below, we can see how the logon time developed throughout my test, also how it differed from the baseline in percent.


In my second test, with a Windows 10 1903 desktop, the initial baseline logon time was a little higher, 21,93 seconds. As we can see from the results below, the logon time more than doubles, but the evolution is a little more stable and predictive.


As mentioned above, the graphs shows the same development, no sudden spikes as apposite to the Windows 10 1809 desktops.


Finally, when testing the same applications with Windows 10 1909, the logon times became even more predictable. The logon time more than doubled, but adding big vmdk’s as LibreOffice or Gimp, did not spike the logon time as much as I saw with Windows 10 1809. We also notice that the baseline has increased even more as compared to the two former tests. This is also something I have seen in several environments with the newest Windows 10 build.


The tests above is really a test of what happens with the logon time when we attach a vmdk to the scsi-controller in a virtual desktop. The max number of applications that can be attached to a desktop is limited by the SCSI ID limitation. In my tests I maxed out my SCSI controller with 13 applications attached. When I look at the virtual hardware, I can see that I have 14 hard disk attached.


So, what happens if I attach more applications than the SCSI controller have available ID’s? I of course wanted to test this, and what happened was that I didn’t get any applications inside the virtual desktop. In vSphere I saw the error below.


The reason for the error above is the setting “devices.hotplug=false” which I set when I created the template for the desktop pools.


But, as I was still curious, I changed this value to true, took a snapshot and deployed it to the desktop pool.


I assigned several more applications and logged in again. As we can see below, I automatically get an extra SCSI-controller and the new applications’ vmdk’s are attached to this.


I again tested how this affected the logon time. As we can see, doing this quite obviously increases the login time dramatically. Although this is a workable solution in scenarios where there are needs for a large number of applications, it has a severe penalty on the logon time.


Conclusion: If I were to endeavor on a conclusion of my tests above, it would be to limit the number of applications in each desktop. There is no shame in installing applications inside the templates and differentiate the desktop pools with different application-sets for different desktop pools. Complement the desktop pools with a limited set of applications from VMware App Volumes and thereby provide the ultimate desktop experience for the users. Having a fast storage solution and server infrastructure is also a very important factor for accomplishing this.

Finally,  if anybody out there want to contribute to crowdfunding my new NUC-based VSAN Homelab, feel free to get in touch, as my lab environment is in dire need of an upgrade, the testing above is a clear evidence of this…:)

VMware App Volumes 4 Release Notes

VMware App Volumes planning, deployment etc.

Disclaimer: Every tips/tricks/posting I have published here, is tried and tested in different it-solutions. It is not guaranteed to work everywhere, but is meant as a tip for other users out there. Remember, Google is your friend and don’t be afraid to steal with pride! Feel free to comment below as needed.

%d bloggers like this: