I recently wrote an article about how the architecture of VMware Horizon has evolved over the years. In this article, we’ll cover the same, but in this case, it’ll be about VMware App Volumes version 4.
Now I hear you say, we were on version 2, and now we’re on version 4. So, what happened to version 3? The answer is quite simple; we don’t talk about version 3…
And even though version 4 has been out for quite some time, I still frequently meet organizations that use version 2. So perhaps this post convinces them to make a move to version 4.
So, remind me, what is App Volumes again?
App Volumes is an application delivery solution from VMware, which drastically simplifies application life cycle management by separating applications from the operating system. By having applications stored in a VMDK (or VHD if you prefer) on a vSphere datastore (or a CIFS share when using VHDs), they can be added to virtual desktops as needed.
This potentially reduces the amount of time spent on image management and the number of images in general and enables applications teams to test and push new applications or application updates faster.
Applications management has been simplified even more
In the App Volumes version 2, you’d put one or more applications in an object called an AppStack and assign that to employees. Due to this process and a hard limit on the amount of AppStacks you could connect to a desktop, you’d typically organize AppStacks based on departments or teams.
Now consider you were asked to update a single application in that AppStack. You would have to either start over or change it and validate if everything still works as it is supposed to do.
Now with App Volumes 4, applications typically follow the following structure:
- Applications – An application is the first object you create. An application represents one or more packaged software versions assigned to employees, groups, computers, or organizational units
- Packages – The packages are the AppStacks as you know them. This is what you capture using a packaging VM and should typically only contain a single piece of software as you can group multiple packages as part of an application
- Programs – the program is auto-generated during package creation. The program’s name is automatic, and executables and actual bits are captured during the package creation
The image below depicts the new structure and underlying relationships.
A great new feature in this structure is the availability of markers. You can use markers to assign different versions of applications and determine which is the latest version. This means you don’t have to create a new Appstack, assign it and remove the previous assignment.
Multi-instance management
While introduced in version 2111, the real added value came with version 2203. It has always been possible to synchronize applications across datacenters using storage groups or even across instances (development/test/production) using some form of tooling or scripting.
But with the introduction of multi-instance management, this process has been simplified a lot!
As you can now join multiple instances of App Volumes, be it with different purposes or in different locations. And manage them from a single management console. In addition to this functionality came in version 2203, as it’s now possible to synchronize assignments and markers too!
The diagram below shows a high-level overview of the different synchronization flows.
The metadata sync is responsible for items such as assignments, markers, and actually what applications are present. This was either done through some sort of scripting or via a Fling that has been available for quite some time.
The replication storage is used to synchronize the applications (their VMDKs, and metadata files) across different sites via storage groups.
Some other noteworthy changes
- The snapvol.cfg file, which can be used for controlling what goes in or out of writable volume, has been moved to the operating system instead of the template disk. This means you don’t have to update the template disk anymore, which was quite a cumbersome task
- You can now connect more virtual hard disks (which means more applications) to virtual desktops by optimizations done to the App Volumes agent
- Since version 2111, there is the option to let applications be connected on-demand. Which means they will be connected when the employee clicks the shortcut for the application. This decreases the logon time and loads on the platform in general, as fewer operations are required
- Command-line packaging has been added in version 2103, which offers the capability of packaging an application from A to Z without using the App Volumes management console
To conclude
App Volumes have always been a great addition to any virtual desktop infrastructure. But with the release of version 4 (and subsequent releases), the added value has only increased. The new ways to manage the lifecycle of applications combined with the removal of some pain points in multi-site scenarios make the solution more mature.
And the good thing is that App Volumes 4 still works with App Volumes 2 agents and AppStacks. So, if you are still on version 2 but want to benefit from these new features, take a look to see if your environment is eligible for an upgrade to version 4!
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
