In this chapter, you will get a high-level introduction to App Volumes. We will talk about how it works and what benefits it can bring to your desktop environment.
We will also look at where it fits within the overall VMware End User Computing (EUC) portfolio, where you would use App Volumes compared to some of the other application delivery/packaging technology, before finally discussing some of its key use cases.
This book provides you with both the theory and the practical elements of App Volumes. Each chapter will explain specific areas of the solution and then give you the opportunity to try them out using an Example Lab. You will be introduced to the Example Lab at the end of this chapter.
In August 2014, VMware acquired a start-up called CloudVolumes. The CloudVolumes technology provided a virtualized, real-time application-delivery engine for virtual desktop infrastructures as well as physical desktops.
In December 2014, CloudVolumes was rebranded and named App Volumes, and offered as a part of Horizon Enterprise Edition.
So, what does App Volumes give you? At a high-level, App Volumes provides a real-time application-delivery and life cycle management solution that is used as a delivery system for your virtual and physical desktops.
Let's start with our typical virtual desktop environment. Although the desktop operating system has been abstracted from the underlying hardware, the applications are still tightly integrated into that operating system. The ideal virtual desktop solution is to deliver fully stateless desktops and have the user elements added on the fly, depending on the user's profile. The fully stateless desktop model provides the most cost-effective solution by being easier to manage and requiring less infrastructure.
Today, there are a number of tools that can take care of delivering the user personalization, user data, and user profile elements to the desktop; however, applications are still delivered either as part of the base operating system image or using some form of application remoting or publishing.
App Volumes provides a layer of abstraction between the operating system and applications by delivering the applications in separate containers. These containers are called AppStacks and they integrate seamlessly into the operating system of the virtual desktop machine.
The following diagram shows the traditional, static model on the left and the App Volumes on-demand delivery method on the right:
As well as application containers, App Volumes provides the end users with their own container or virtual hard disk, into which they can install their own applications. This container, called a Writable Volume, "follows" them when they log in to different virtual desktop machines, bringing all their applications with them.
The following diagram illustrates the App Volumes model of having application containers (AppStacks) and user-writable containers (Writable Volumes):
So how do you get started? The first thing you do is create or capture an application that can be delivered by App Volumes. You start the process by installing the application on a virtual desktop machine, which is referred to as the provisioning machine. This provisioning machine is basically a vanilla installation of the operating system, with no applications installed.
When you start the capture process, an empty Virtual Machine Disk (VMDK) file, called an AppStack, is mounted on to the provisioning machine. Next, you start the application installation as you would normally do. All the files associated with this application are then redirected to the AppStack or VMDK file.
Once you have completed the capture process, the AppStack is set to read-only mode and is ready to be assigned to end users based on their Active Directory group membership. AppStacks can also be assigned to individual users or other groups.
For the users to be able to access the applications in their assigned AppStack, an App Volumes Agent runs on their desktop, mounting the VMDK file and making the application appear as if it were fully integrated and installed locally rather than running from an additional drive. This is how applications are able to be delivered to a user in real time, as AppStacks can be assigned on the fly.
As well as the applications that get delivered as part of the AppStack, a user is able to have their own disk or VMDK file on which they can install their own applications. This is called a Writable Volume and will also follow the user when they roam among virtual desktops, making it perfect for developers to have non-persistent virtual desktops.
In the next chapter, Chapter 2, Architectural and Feature Overview, we will dive a little deeper into what exactly each of the different components does, and then in Chapter 6, Working with AppStacks, and Chapter 7, Working with Writable Volumes, we will take a deeper dive into how App Volumes, AppStacks, and Writable Volumes work.
So the question is what App Volumes does differently and what benefits it will bring.
As we have already discussed, App Volumes gives you the ability to deliver applications to users in real time; however, you also benefit from being able to manage application life cycles much more easily, as well as a reduction in costs.
Once you have created your AppStack, it's simply a case of a few clicks to assign it to a user or group of users. Conversely, it's that simple to remove it as well. This means that, when a user requests a new application, for example, it's very easy to assign it to them without having to go and install it.
If you are running a virtual desktop environment, then App Volumes helps you drive towards achieving a truly stateless desktop since applications are immediately and dynamically made available upon login, or even while the user is already logged in.
A question that comes up most of the time when talking about App Volumes and application delivery in general, in a VMware context, is this: which technology should you use and when?
People often ask whether or not App Volumes is going to replace ThinApp and Mirage, and whether these technologies are still required. The key thing to point out here is that each solution addresses a specific use case, and they actually do not all do the same thing. In fact, combining all three delivers a more complete solution.
To the question of whether or not App Volumes is going to replace ThinApp and Mirage, the answer is no. All three technologies are key to the VMware vision and strategy, and won't be going anywhere for the foreseeable future.
In this section, we will discuss which solution you will need, why you will need it, and then see how they are complementary to each other.
Let's start with Mirage. Mirage is a centralized, Windows image-management solution, primarily designed to manage physical desktop PCs and laptops. It is also used to deliver the containerized desktop solution, Horizon FLEX, for delivering virtual desktops in a BYOD (short for Bring Your Own Device) environment on both Mac and Windows laptops.
Next up is ThinApp. ThinApp is an application virtualization/packaging technology that is primarily used when you need isolation between applications. For example, you might need to deploy an older version of an application that doesn't run on your current operating system version. You may also need to run multiple versions of applications; for example, you may need to run different versions of Internet Explorer. This is one of the key differences in what the solutions deliver. ThinApp is an application-packaging technology. Mirage and App Volumes do not provide any packaging capabilities.
We have outlined what these technologies deliver and we have talked about them being complementary. Depending on your use case, you can use them in combination.
When it comes to managing a physical desktop environment or delivering containerized desktops with Horizon FLEX, Mirage is the technology you should use. If you have applications that need to be isolated, you will combine them with ThinApp to create Mirage application layers, with the application layers containing those ThinApp packages.
If we now take virtual desktop environments and, in particular, those that are built using linked clones and have a floating user assignment, then App Volumes will be the ideal solution for this use case. When they log in, end users will be assigned a vanilla desktop from a pool of floating desktops. Their applications will then be deployed by simply mounting the relevant VMDK file, thus containing the applications in real time.
That was the model for non-persistent, linked, clone desktops, but what about virtual desktops that are built using full clones and have a persistent assignment? For this use case, all three solutions can be combined: Mirage to manage the operating system element, App Volumes to deliver the applications, and the applications potentially being packaged using ThinApp, if you require the isolation between applications.
The VMware documentation for the latest version of App Volumes talks about being able to deliver AppStacks to physical desktops. Although this is possible, Mirage would be a better option for managing physical desktops.
As you can see, there are several use cases that lend themselves to the different technologies, and this is the key to deciding which ones to use and when.
The following diagram shows a high-level overview of how the technologies complement each other and work together:
In the next section, we will discuss the key use cases for App Volumes in more detail.
There are several key use cases for deploying App Volumes within your environment.
The first of these use cases is deploying App Volumes within a virtual desktop infrastructure environment.
A virtual desktop infrastructure (VDI) is the primary use case for App Volumes. It allows IT administrators to deploy applications in real time and independent of the core operating system. The decision on who gets which applications is based on the user and group policies, depending on the user's membership in Active Directory.
So why is this important and a key use case?
In order to deploy the most optimized VDI, you would want to opt for a floating, 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 delivered on demand, and when the user logs off the virtual desktop machine gets destroyed, ready for the next user to log on.
This model would suit the majority of users; however, there are some users, such as developers, who would still require a persistent virtual desktop machine so that they have the ability to install their own applications that will remain when they log off rather than being destroyed when the virtual desktop machine they have been using gets destroyed. Deploying these types of virtual desktop machines is more costly and puts a greater load on infrastructure resources as you need more computing power and more storage than you would in a non-persistent deployment.
By deploying App Volumes, and the Writable Volumes feature in particular, users essentially get their own hard drive with their own user-installed applications on that drive. As they log on to a non-persistent, floating virtual desktop, their writable volume or hard drive gets attached and mounted to that virtual desktop machine. To the user, it looks as if their applications are natively installed on their desktop and that it is their own desktop.
The end users also benefit from having their core applications delivered immediately, and for the IT department, this means they can easily manage application delivery in real time, allowing them to assign new applications on the fly as well as deploy any updates to existing applications.
Allowing users to work with this model of virtual desktop machine deployment also means that the overall infrastructure requirements, particularly storage, are significantly lowered.
It's also important to note that we are not just talking about VMware virtual desktop solutions. App Volumes also supports Citrix environments, and can be purchased specifically for this, which we will cover in the How to license App Volumes section of this chapter.
This particular use case is one that often gets overlooked since Remote Desktop Services Host (RDSH) is in itself an application-delivery mechanism. So how can App Volumes help with this use case?
If you look at the basic infrastructure around RDSH, applications have to be installed onto the RDSH server before they can be published to the end users. This in itself makes the infrastructure pretty static in nature. By static we mean that if you need to scale up your RDSH deployment, you not only have to build a new server but also install the applications all over again afterwards. It's a similar story when you have to update applications.
App Volumes, in this use case, works in the same way it would with a VDI, but instead of mounting AppStacks on the virtual desktop machine's operating system this time you are mounting them on the RDSH server. It's just a case of installing the App Volumes Agent and capturing an AppStack for use in this environment. Obviously, your RDSH servers need to be running as virtual machines.
Essentially, you are creating a stateless RDSH server that allows you to add additional server resources and just mount the AppStacks on them rather than having to install the applications each time.
We already mentioned that App Volumes can be deployed in a Citrix environment and can deliver exactly the same benefits. XenDesktop-based virtual desktop machines work in exactly the same way as a VMware Horizon View virtual desktop machine when it comes to delivering applications; however, you can now support the Virtual Hard Disk (VHD) format.
XenApp works using the functionality of an RDSH server. This means that you can now deploy stateless XenApp Servers by mounting AppStacks to RDSH servers, as we discussed previously. Like XenDesktop deployments, this can also be done using VHD deployments if you use a virtualization platform based on XenServer or Hyper-V.
There are several ways in which you can purchase and license App Volumes.
Firstly, App Volumes is a standard component of the Horizon Enterprise Edition license.
The second option is to purchase App Volumes as a part of the VMware Horizon Application Management Bundle. This bundle includes all the components except the core VDI solution, Horizon View, and is designed to complement existing Citrix environments.
Lastly, you can purchase App Volumes as a standalone product as part of an à la carte list of solutions. Whichever option you choose to purchase App Volumes, the product itself is licensed on a per-concurrent-user basis.
Now that we have covered the introduction to App Volumes, let's just take five minutes to introduce you to how this book works and what you will need to get the most out of it.
This book will guide you through the key use cases for App Volumes, from the theory of how it works and how to design a solution, to the more practical elements, such as installation.
Each section of this book has been written based on everyday, real-world experiences of working with the product in both production and proof-of-concept/pilot environments.
In parallel with the chapters, you can set up your own lab environment, which will cover practical examples of how the technology works, giving you the option to follow the steps and try them for yourself. This can either be as an exercise while reading the chapters or to assist you in setting up a proof-of-concept, pilot, or live deployment.
Accompanying this book, as previously mentioned, is an Example Lab that you can build along the way. In this introductory section, we are going to cover the requirements for this lab and what it will look like. The lab is optional, and you can choose to build your own environment.
The lab environment used in this book was built on a Dell PowerEdge R720xd LE configured with two E5-2680V2 2.8-GHz 10-core processors and 64 GB RAM, running VMware vSphere 6 as the hypervisor.
Although the server had internal storage, the lab was built using a Tintri all-flash array. By using Tintri and its VM-aware capabilities, you can monitor right down to the virtual-machine level.
The reason I chose Tintri storage is the fact that it has been developed from the ground up for virtualized environments removing contention points and collision domains such as the LUN construct. Tintri was very easy to deploy. It was done in just under 15 minutes. The folks at Tintri have created a new storage category. They call it VAS (short for VM Aware Storage). This "awareness" is backed by Tintri's analytics engine learning the behavior of individual VMs underpinned by an intelligent filesystem. The architecture is designed to adapt to the fluidity that comes with virtualized workloads enabling it to deliver the right quality of service where and when it is needed. This makes Tintri ideal for VDI-type deployments as it has the ability to respond to performance bursts that can result from use cases such as App Volumes.
All of this was used to host the following virtual machines. The computer names of the virtual machines are shown in brackets and will be referred to in the lab examples throughout the book:
Windows Server 2012 R2: configured with AD, DNS, and a file server (DC)
VMware vCenter Server Appliance (VCSA)
VMware ESXi v5.5 host server (ESX-1)
Windows Server 2012 R2: App Volumes Manager (APP-VOL-MGR)
Windows Server 2012 R2: Microsoft SQL 2008 Express*
Windows Server 2012 R2: configured with the RDSH role**
Windows Server 2012 R2: Horizon View Connection Server (VIEW-CS)***
Windows 7: AppStack-provisioning desktop (AV-PROVISION)
Windows 7: used as a virtual desktop machine (WIN7-DESKTOP-1)
Windows 7: used as a virtual desktop machine (WIN7-DESKTOP-2)
Windows 7: virtual desktop machine delivered by Horizon View (VIEW-1)
Windows XP: used for ThinApp Setup Capture (WINXP-DESKTOP-1)
* In the Example Lab, the Microsoft SQL Express server is also installed on the same server as the App Volumes Manager. As this lab is just for testing, it is fine to configure it in this way. This is not recommended for production environments.
** Only required in Chapter 11, Deploying App Volumes in a RemoteApp Environment. If you don't plan to install and test this feature, there is no need to deploy an RDSH server.
*** Only required in Chapter 9, Horizon View Integration. If you don't plan to install and test Horizon View, there is no need to deploy a Horizon View connection server.
If you plan to build a lab as you follow the chapters, it's worth building the infrastructure detailed here beforehand. Build and install all the virtual machines, but with the exception of installing any of the App Volumes software components.
In writing this book, VMware vSphere 6 has been used as the hypervisor to host all of the VMs used in the Example Lab, but you could also run this in VMware Workstation.
If you choose not to follow the steps described, they will still help by providing you with a reference and foundation for building and managing your own environment.
A schematic diagram of the core lab environment used for the examples is detailed in the following diagram:
The next schematic diagram shows the optional lab components for integrating App Volumes with VMware Horizon View and RDSH servers:
The file server in the lab environment was used to host a shared folder containing all the installation files so that they are accessible by all the other virtual machines.
This final schematic diagram shows the optional lab for Chapter 8, Delivering ThinApp Packages with App Volumes:
We also require an administrator account and a number of Organizational Unit (OU) groups and user accounts.
For administering App Volumes, a group called
AppVol Admin was created. The administrator account was then added to this group. You can, of course, create other App Volumes administrator accounts.
In addition to the administrator account, we have created a number of Active Directory groups to reflect different departments. In each group, there are a few user accounts. These have been set up as shown in the following table:
These users and groups will be used throughout the Example Lab to demonstrate user assignments.
In this chapter, we have covered a high-level introduction to App Volumes, looking at what it is, how it works, and what it can deliver.
We then went on to cover exactly where App Volumes fits into the overall VMware EUC portfolio, bearing in mind that products such as ThinApp and Mirage seem to deliver almost the same functionality.
Finally, we saw how to get the most out of this book, and you were introduced to the Example Lab that you can build along the way in each chapter.
In the next chapter, Chapter 2, Architectural and Feature Overview, we will start to look a little deeper into each of the App Volumes components.
