This blog post sort of acts as a follow-up to the post I wrote back in May. In that post, I covered the evolution of App Volumes while going from version 2.x to 4.x (we still don’t talk about 3.x) and some of the updates released after that.
I’ll be doing the same in this blog post, covering some of the most significant additions made in the releases 2111, 2203, 2106, and 2103.
In no particular order, I’ll be covering the following topics:
- Apps on Demand
- Command-line capture
- Maximum number of disks supported per PVSCSI Controller
Apps on Demand
Typically, applications are delivered during startup or sign-in, depending on the type of assignment (computer versus user). This impacts the logon duration, as applications must be attached, and part of that process is a validation that the application has been successfully attached. This might not be an issue when only attaching something in the range of 1 to 5 applications, but the impact becomes noticeable when we’re talking about 25 applications.
The real question is, is it worth it? Is that user actively using all those 25 applications during every session?
This is where apps on demand helps, only attaching applications when the employee clicks on the shortcut or when launched via different methods (such as Dynamic Environment Manager DEM)). When apps are delivered on demand, the employee sees the desktop or Start menu icon, just like they would normally. But they won’t be present if you were to check the locally installed applications (appwiz.cpl).
And to make things even better, since App Volumes 2206, applications can be attached when clicking on a file associated with a specific application based on the file type association!
Command-line capture
This feature is probably one of the older ones in this post, but it can really make an impact for organizations that have a large application landscape, especially one that frequently changes.
Automating packaging with App Volumes isn’t new, as silently installing applications isn’t new. And some tasks could’ve been automated via the API. But doing the entire process, from front to back, fully automated, is something else.
In essence, the process doesn’t change compared to doing things manually. You still need a packaging machine with a fresh snapshot that you’ll use every time. So what did change? The fact that you’re no longer required to interact with the App Volumes Manager directly did.
You can capture, update, or validate packages by using the App Volumes Tools (available from the same installer as the Manager and Agent).
Now, if you want to automate everything, you can call these scripts from an automation tool using something like WinRM and Invoke-Command.
Validating a package is done by attaching it to a virtual machine. If this process completes without any issues, the application is considered validated. However, it’s important to mention that this doesn’t mean the application has been validated and works as it should!
Check the following page for a complete list of the available command-line arguments, or if you prefer PowerShell: click here
Maximum number of disks supported per PVSCSI Controller
This might not sound like a big deal, but it certainly is. Since App Volumes 4.x was released, it has been unclear what the maximum number of attached applications should be. For 2.x, it has been clear based on the following KB that you shouldn’t exceed 8-10. The big disclaimer is always YMMV (your mileage may vary), but with App Volumes 4.x, this number was supposed to be somewhere in the ’20s without negatively impacting performance!
Now the release notes of App Volumes 2203 mention the following:
“Up to 64 disks, including an operating system disk, can now be added to each PVSCSI Controller when using vSphere 6.7 and later. Customers on earlier versions of vSphere are still limited to 15 disks per controller. In earlier versions of App Volumes Manager, administrators had to add more controllers (up to 4) to get more than 15 disks. Now, one controller can support the same quantity, thus avoiding the overhead of adding more controllers.”
Now, if you are good at math (or have a calculator nearby), a single virtual machine would be able to have 256 virtual hard drives (64 per controller) over four controllers (which is the current maximum with vSphere 7.0). You’ll have to reduce that number by 1, as you need to have an OS disk as well.
Obviously, this doesn’t mean that attaching such a number of applications would run without any performance impact (or run at all). But it could be a hint for the future that something like this might be possible! And I’m more than interested to see any of the performance benchmarkers take up the challenge of pushing this to the limits.
Wrapping it up
Everything mentioned above might not sound as impactful as something like Multi-Instance Management. But these changes are very welcome and have a positive impact on qualities such as performance (apps on demand), manageability (command-line capture), and scalability (maximum number of disks).
As with everything, it might not apply to you and your organization, but if you have some time available, give these new features a spin!
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
