Application Layering with VMware App Volumes

By Peter Von Oven

Delivering applications within a virtual desktop environment has always proven to be a challenge given the stateless nature in which virtual desktops are deployed. How can organizations deliver applications each time an end user logs in to his or her desktop given that the desktop they just logged in to has been created as a brand-new machine and basically has nothing installed on it?

App Volumes delivers applications in real-time to virtual desktop machines, enabling VDI deployments to return even greater flexibility, agility and cost reduction. Enterprises can fully utilize the stateless virtual desktop model in all use VDI uses cases. For users such as developers who required a persistent, fully-stateful virtual desktop machine of their own, they too can take advantage of the advantages of a stateless virtual desktop model enabling better return on investment as well as centralised application delivery.

This book will guide you on a journey of how to deploy an App Volumes environment, with easy-to-follow step by step instructions with real-life screenshots based on a test lab environment that you can build as you go.

The book starts with an overview of what App Volumes delivers and the challenges it resolves. From there, we will start to explore the architecture and components that make up the solution, concentrating on how to design and plan your own environment.

Once you have understood the technology and use cases, then it’s time to start installing and configuring the App Volumes software. Once installed we can then start to look more closely at the core components to the App Volumes solution and how to build your application layers. As part of this, we will also cover some of the more advanced management tasks for managing the environment.
Once you have built the core environment and created some examples of application layers, we will then look at how to integrate App Volumes with some of the other EUC technologies that are available in the market such as VMware ThinApp, Microsoft RDSH, Citrix XenApp (Citrix Virtual Apps), and Citrix XenDesktop (Citrix Virtual Desktop).

Throughout this book we will provide you with useful hints and tips, along with best practices, all based on experience of deploying App Volumes within the Enterprise.

At the end of the journey, you will have built a complete working App Volumes environment and will have acquired the skills and knowledge to deploy your own production environment.

• Language: English
• Publisher: BPB Online LLP
• Release date: Nov 13, 2019
• ISBN: 9789389328776

Book preview

CHAPTER 1

Introduction to App Layering and VMware App Volumes

All about the technology and how it works

Application layering is a relatively new technology and was primarily developed to address the issue of how to deliver applications to stateless virtual desktop machines. This stateless or non-persistent model of delivering and building virtual desktop machines on-demand meant that end users would not own their own virtual desktop machine and instead would be allocated one on-demand as they logged in. The next time they logged in they would potentially be allocated a completely different virtual desktop machine. So, how do you ensure they have all their applications made available to them?

For IT teams, to ensure the delivery of the right applications, this meant they would have to build several gold images to be used as templates for these virtual desktop machines so that the applications would be available to the end users. This also meant that they would have to rebuild an entire gold image just to update a single application, and then must rebuild the desktop pools as a result. The rebuilding process of the desktop would take time to complete, typically done out of office hours, and would put additional load on the storage infrastructure. It could also mean downtime for the end users.

To solve this issue around having to manage operating system and applications as one entity, IT needed a solution that would separate the two. Akin to virtualization where operating system has been abstracted from the underlying hardware, IT needed to apply the same practice but now between the operating system and the applications. This would allow them to deliver applications independently of the operating system.

This method of separating applications from the operating system is what we know today as application layering. With Application layering, IT teams can create that layer of abstraction, separating the applications from the underlying OS, and thereby enabling IT to deliver the apps back to the end users on-demand. As the applications are now independent to the operating system, they can be easily patched and updated without having to touch the image of the operating system. They now had a way of delivering a truly stateless desktop environment to the end users.

Structure

In this chapter, we are going to cover the following topics:

Application layering

Usage of application layering

VMware App Volumes

How does App Volumes work?

Why deploy App Volumes in your environment?

Other app delivery technologies – a high-level comparison

When to use App Volumes

Delivering stateless, non-persistent virtual desktops

RDSH – Delivering apps for Citrix XenApp and VMware Horizon Apps

App Volumes licensing options

Practical examples – creating a test lab

App Volumes architectural and feature overview

App Volumes solution components

App Volumes Manager

App Volumes Agent

AppStacks

Writeable Volumes

Provisioning machine

Storage groups

App Volumes architecture

Architecture from an end user’s perspective

Infrastructure architecture from an IT admin’s perspective

Network ports

Objective

This first chapter is going to introduce you to application layering, how it works, and what it is used for within your desktop environment.

Once we have introduced you to application layering as a concept, we will move on to the specifics of VMware’s application layering solution, App Volumes looking at how it works and what it will deliver in terms of use cases.

This book is going to cover the theory of App Volumes and the more practical elements as well as the how-to elements of App Volumes. To help with this practical side, we are going to build a test lab to demonstrate this practical side, building the lab chapter by chapter, using actual screenshots of the solution so that by the time you reach the final chapter you will have built your own fully working App Volumes environment, whether for a proof of concept, pilot, or to take straight into production.

Let’s now look at what application layering is all about.

Application layering

As we have already discussed in the introduction to this first chapter, application layering provides a solution that enables IT admins to separate applications from the underlying operating system, thereby allowing those applications to be managed independently. This is similar in approach to how virtual desktop infrastructure came about which abstracts the desktop operating system from the underlying hardware and runs it as a virtual machine on a hypervisor, which, in turn, is running on the physical server, allowing the desktops operating systems to be managed and delivered from a central location.

This is often referred to as the composite desktop model whereby all the component parts of what makes up a complete desktop, such as the operating system, application, user profiles, and user data are all extracted from the operating system, centrally managed, and then delivered back independently in order to reassemble the complete desktop environment on-demand. Before this model, all these components would have been tightly integrated into the operating systems and therefore the entire operating system and everything contained within it would need to be managed as a single entity. It is not very flexible or efficient.

In the composite desktop model, application layering plays the part of delivering the applications and potentially the user data as well.

So how does application layering work?

Once an application layer has been created, by completing some form of install capture process, the resulting applications can then be delivered to the virtual desktop machine. Delivery is dynamic and on-demand based on user entitlement and delivered as the end user logs in to a virtual desktop machine. It’s typically just a case of mounting a virtual disk that contains the captured applications, to the virtual desktop machine.

Figure 1.1 shows a typical application layering architecture in a bit more detail:

Figure 1.1: Architectural overview of application layering

If you take the captured application, as we have mentioned earlier, this is captured onto its own virtual hard disk. The user logs in and the disk is mounted to the operating system of the virtual desktop machine. Using a filter driver or agent, the application files are temporarily inserted, or layered into the OS of the virtual desktop machine. As far as the operating system is concerned the files are installed and available locally, and so the icon will appear on the desktop, and the end user can launch the application.

If you were to open the registry, for example, you would see the application registry settings. The same is true for the application files, and if you were to look in c:\program files, for example, you would see all the files there. However, they are actually on the mounted virtual hard disk.

The next question is what happens when the end user logs out?

Basically, the mounted virtual hard disk is unmounted which effectively means that the filter driver removes the layers from within the operating system, the application is gone, and the virtual desktop machine is back in a clean ready for the next user to log in to. That next user may not have access to the previously attached application and so could have a whole new set of applications delivered.

If you were to look at the operating system, namely the registry and files, after the application had been unmounted, you would see now a reference to the application. It’s as if it was never there!

Usage of application layering

What is the core use case for application layering? Application layering was designed to address the issue of how to deliver applications within the fully stateless or non-persistent virtual desktop environments that organizations strived to deliver. It allows IT admins to manage applications independently of the base operating system image and help deliver that nirvana of virtual desktop infrastructure in having just a single gold image. The advantages are lower management overheads in the number of images to manage, and the fact that you run a stateless desktop environment that is simpler to troubleshoot and manage, and potentially requiresless infrastructure.

For end users, it means that they’ll get access to applications much quicker than they would before as they no longer need to wait for the applications to be installed by the IT admin team. The end users can simply have them allocated or assigned immediately.

VMware App Volumes

To start with a little bit of history, VMware acquired a company called CloudVolumes back in August 2014. CloudVolumes enabled the real-time delivery of applications to virtual and physical desktops. Soon after the acquisition, in December 2014 to be precise, VMware rebranded CloudVolumes changing the name to App Volumes which in turn became an integrated part of the Horizon Enterprise edition.

VMware App Volumes is VMware’s implementation of application layering. It works in exactly how we have described application layering in general in the earlier sections of this chapter. At a high-level description; it enables the real-time delivery of applications within a virtual desktop environment.

Application layers are captured using the App Volumes provisioning process with the newly created layers being stored on virtual hard disks within your virtual infrastructure environment. When an end user logs on, the virtual disk containing the application is mounted, and the applications layered into the operating system are ready to be launched. When the end user logs out, the layer is removed, and the virtual hard disk is unmounted.

How does App Volumes work?

Let’s now get into a little more detail around how App Volumes works. The objective of the App Volumes solution is to address the issue of applications being tightly integrated into the operating system, meaning management becomes a bigger overhead and moving to a stateless virtual desktop environment becomes harder.

App Volumes provides this layer of abstraction between the operating system and the applications allowing applications to be managed and delivered independently by effectively containerizing them. These so-called containers are called AppStacks (for corporately delivered applications) and Writeable Volumes (for user-installed applications). It is the AppStacks and Writeable Volumes that are delivered to the end users.

Figure 1.2 pictorially describes the traditional static model of application delivery, compared with the App Volumes on-demand delivery method:

Figure 1.2: Comparison of the static model with the dynamic model

Up until now, we have only concentrated on application delivery, that is applications being delivered by the central IT teams to the entire user base. Despite mentioning the term Writable Volumes, we have not really covered it in any great depth. So, let’s do that now.

The App Volumes Writeable Volume feature enables end users to have their own virtual hard disk mounted to the virtual desktop they log in to. Since the Writeable Volume is another type of layer, it works in the same way as an AppStack does; however, where it differs from an AppStack is in that fact that it starts off life as a completely blank disk, apart from the App Volumes files, which are required to make it work. The Writeable Volume allows end users to install their own applications, which are then redirected, by the App Volumes Agent into the Writable Volume. This addresses a use case that typically would not have fitted the stateless desktop deployment model. In a stateless desktop model any applications an end user installs onto his or her virtual desktop machine would be deleted at log off time. This is because the virtual desktop machine gets refreshed and reset ready for the next user to log in. To stop this happening, you had no choice other than to deploy a stateful or persistent virtual desktop machine, which is kind of against the point of VDI in reducing infrastructure and management.

But now, with Writable Volumes, you can easily provide a stateless virtual desktop machine for this particular use case.

Figure 1.3 shows an overview of the App Volumes solution delivering application containers (AppStacks) and user writeable containers (Writeable Volumes):

Figure 1.3: App Volumes high-level overview of AppStacks and Writeable Volumes

Earlier in this chapter, we discussed about creating AppStacks and this concept of capturing the install process to do this. But, what exactly does that mean, and how do you do it?

We will go through the practical process of how this is done in a later chapter. As of now, we will cover the high-level theory. To create an AppStack, you will first need a machine on which the application can be installed. In App Volumes terms this is called the provisioning machine. The provisioning machine runs the App Volumes Agent and is connected to the App Volumes Manager so that it can capture the install.

When the capture process starts, an empty virtual disk file, the AppStack, is mounted on the provisioning machine. Once mounted you will be in record mode. Although you’ll be able to install the application normally, the application files and settings would still be redirected to the virtual disk to become the AppStack.

In addition, you’ll switch out of record mode and the AppStack will be set to read-only when you have installed the application. At this point, the AppStack will be ready to be assigned to end users based on AD group policy.

Now, when an end user who has been entitled or assigned to an AppStack logs in to their virtual desktop machine, which is also running the App Volumes Agent, the AppStack virtual disk file will be mounted, and the application will be available to the end user, appearing as if it were fully installed locally on the desktop. AppStacks can also be dynamically assigned while the end user is logged in so that the apps appear immediately.

We talked previously about the user data layer, or the Writeable Volumes disk. If the end user also has a Writeable Volume assigned to him or her, then it to will be mounted at login time.

Why deploy App Volumes in your environment?

We have talked a lot about the benefits that App Volumes provide such as delivering applications to end users in real-time, allowing IT admins to manage applications independently, and allowing them to deploy a single operating system build. All this means that it becomes much easier to deploy a fully stateless virtual desktop environment.

Having said that App Volumes can work on physical desktops as well, with a few caveats, but to get the most out of what it is really designed to deliver then virtual desktop infrastructure environments is where App Volumes comes into its own. In fact, VMware has an entire just-in-time solution for delivering stateless environments of which App Volumes plays a key role.

Being able to manage applications independently makes it far easier for patching and updating, and all without having to touch the operating system. It also means that IT admin teams can respond much quicker to the updating and patching of applications and not worry about rebuilding gold images and going through a whole deprovisioning process. A gold image is your master image from which all virtual desktop machines are deployed. Once an application is updated, it can be made available immediately and next time end users log in, they’ll have the latest version of the application. In this use case, App Volumes can be used as an application life cycle solution.

When it comes to onboarding new users, App Volumes makes it simple to entitle end users to the applications they need. Based on their Active Directory membership, they will have all their applications delivered during the first time when they log in, along with their virtual desktop machine.

If an existing user needs a new application and the AppStacks have already been created, all the IT admin team need to do is add that user to the group. Depending on how the AppStack has been configured, it could be delivered immediately, with the icon appearing on the desktop as they are already logged in and working. This means end users can be simply onboarded as new users and application can easily be delivered to existing users.

We’ve focused purely on delivery until now, but due to the way in which App Volumes dynamically deliver applications, then they can also be removed just as easily. When the end user logs off their virtual desktop machine, the AppStack is unmounted, so all you need to do now is to remove them from the group. This again makes it much easier to manage your application estate and how many licenses you need for example.

Other app delivery technologies – a high-level comparison

VMware also has a couple of other solutions for delivering applications that are different from the way App Volumes deliver. We are talking about ThinApp and Horizon Apps. There used to be a couple of other technologies, VMware Mirage and Horizon FLEX; however, these solutions are both now end of life.

The question is why there are seemingly three ways to deliver applications with VMware solutions? The simple reason is that they may all deliver apps, but how they do it is completely different, with each one solving a specific issue or use case. In fact, you could combine all three solutions to deliver an end-to-end solution covering all use cases. So, what do each one of these solutions offer?

Let’s start with VMware ThinApp. ThinApp is an application virtualization

technology, which packages an application into its own isolated bubble, completes the file system, registers and virtualizes components of the operating system that it requires. This bubble is delivered as a single executable file that contains all these elements. Its use case is for when you need to isolate the application from the operating system, as they are not compatible with that version. For example, you might need to deploy an older version of an application that doesn’t run on your current operating system version. App Volumes does not isolate applications and instead integrates (layers) the applications into the desktop operating system.

In fact, you could combine both App Volumes and ThinApp to deliver virtualized, isolated applications as app layers. The use case would be to deliver applications that don’t run on the version of the operating system being used for non-persistent virtual desktop machines.

The high-level architecture Figure 1.4 shows how ThinApp and App Volumes can integrate:

Figure 1.4: App Volumes and ThinApp delivery of apps

We have talked mainly about non-persistent virtual desktop machines, but App Volumes could also be used for persistent virtual desktop machines and even physical desktop machines as long as they have a good connection to the network. It’s also not just limited to desktop operating systems either. You can deliver app layers to server operating systems that are used for publishing apps, enabling you to build stateless server farms to help scalability.

As you can see there are several use cases, which brings us nicely on to the next section, where we are going to look at these different use cases in more detail.

When to use App Volumes

In this section, we are going to cover the two main use cases of where to use App Volumes.

Delivering stateless non-persistent virtual desktops

Virtual desktop infrastructure is the primary use case for App Volumes. As we’ve already discussed earlier, it enables IT administrators to deploy applications in real-time and independently of the core operating system image. This means patching becomes a whole lot easier. Entitlement of applications is based on user and group policy, so users automatically have their applications available as they log in.

What makes VDI such an important use case for App Volumes?

Ultimately VDI is why application layering came to be. IT needed a way to deliver applications simply using the most effective methods, and the most optimized virtual desktop infrastructure you would want to opt for would be a floating or a non-persistent model. This means that virtual desktop machines are delivered on-demand from a pool of available machines, and that nobody owns their own desktop. Everything is built and delivered on-demand and when the user logs off, everything is removed, and the virtual desktop machine gets either deleted or return to the pool as a brand new cleanly built desktop ready for the next user to log on.

This model works for most use cases, however there are some, such as developers, that would still require a persistent virtual desktop machine so they can install their own applications rather than having them removed each time they log on and off. Persistent virtual desktop machines are not ideal as it would cost more to manage and would need more in terms of infrastructure resources than a non-persistent deployment. But, with App Volumes Writeable Volumes, this use case can now be provided.

With App Volumes Writeable Volumes, users have their own hard drive onto which they can install applications and store user data. When they logon to a non-persistent virtual desktop machine, their Writeable Volume is attached and mounted to that virtual desktop machine and appears as if it is part of their native environment. This means that they can install apps or store personal files and data onto the virtual hard disk that follows them as they log on to different virtual desktop machines. Of course, for profile information or user environment the data which you would really want to deploy will be something like VMware UEM.

RDSH – Delivering apps for Citrix Virtual Apps (XenApp) and VMware Horizon Apps

When it comes to delivering application layering, we are not just talking about desktop delivery operating systems as we have mainly discussed up until now. Applications can also be delivered or published to end users using the Remote Desktop Session Host role of Windows Server. However, this in itself is a way of delivering applications, so how does App Volumes come into play in this scenario?

In the basic RDSH infrastructure, applications must be installed onto the RDSH servers before they can be published to the end users. As with the virtual desktop machines, this makes the infrastructure static in nature. This means that if you need to scale up your RDSH deployment, you would not only have to build new servers with the RDSH role configured, but you would also need to install the applications again.

Therefore, App Volumes within an RDSH environment delivers the same benefits as it would within a virtual desktop infrastructure, but instead of mounting AppStacks to the virtual desktop machines operating system, this time you are mounting the AppStacks to a server OS running RDSH You then configure end user access as you would normally, using RemoteApp, VMware Horizon Apps, or Citrix XenApp. Another difference is that for RDSH servers you would need to provision the AppStacks using an RDSH server so that they are captured in a multi-user mode.

The use case for App Volumes and RDSH is to create a stateless RDSH server. This allows you to add additional RDSH servers quickly and easily without having to install the applications. All you need to do is build the server, which can also be automated, and then just mount the AppStacks to add the applications.

In fact, VMware has this automated solution already available in the form of the Just-in-Time Management Platform (JMP). This combines Instant Clones, App Volumes, and VMware UEM to deliver an entirely stateless environment, not only for virtual desktop machines, but also for RDSH environments. We will talk about the JMP solution in more detail later in the chapter.

As Citrix XenDesktop and XenApp both use the RDSH server role to deliver published applications and desktops, it works in exactly the same way as we have just described earlier. However, if you use a different hypervisor, such as XenServer or Hyper-V, to deploy your RDSH servers, App Volumes also supports the VHD disk format for creating AppStacks.

App Volumes licensing options

You can purchase App Volumes in several different ways. The first option is to purchase the standalone version, that is, App Volumes and not any of the other Horizon products. There are three different versions to choose from:

App Volumes Standard: Supports real-time app delivery, user profile and policy management, and provides a platform for cloud-based solutions. Works with Horizon, Citrix XenApp, and XenDesktop, as well as RDS hosts.

App Volumes Advanced: Builds on standard and adds the AppToggle, AppCapture, and AppScaling features.

App Volumes Enterprise: Designed for Citrix environments only, delivers the same features as Advanced, but also includes VMware infrastructure components as well as app and session monitoring capabilities.

The second option is to purchase App Volumes as part of the VMware Horizon Enterprise Edition, as it is included in this edition of VMware Horizon.

The final option is with VMware Horizon Apps Advanced which provides all the components required to deliver the JMP platform.

Practical examples – creating a test lab

You will at this stage have a good understanding of the theory around how App Volumes works, and where it can be used, but to get the best out of the theory you need to put what you have learnt into practice. To do this, accompanying the theory discussed in this book, there is a practical element that will show you how one can step-by-step complete the practical side of App Volumes.

This practical element will take the form of a test lab environment; it will show you how features work and how to configure and manage them. Taking this approach will assist you in deploying App Volumes in production or for a proof of concept or pilot environment by showing you exactly how to complete these tasks using actual screenshots.

What does the test lab look like?

To complete the core lab tasks, you will need to build the following virtual machines, hosted on a VMware ESXi v6.x host:

Windows Server 2016 Configured with –AD, DNS, and File Server role