AppVolumes (formerly known as CloudVolumes) was just released a couple of days ago as GA (available via trial), I downloaded a copy of the software and installed it into my lab environment as the solution itself sounds very promising solving application delivery issues by using layering technology.
CloudVolumes was lead by some strong minds from the industry, for example Harry Labana (former Citrix CTO), which resulted in a product that can be described as a layering solution for application delivery. Just recently VMware bought CloudVolumes and renamed it to AppVolumes and opened up the GA via a trial program a couple of days ago.
The solution.. for what?
AppVolumes is an application delivery solution which can add layers of applications to desktops, meaning shared hosted desktops, hosted virtual desktops or physical desktops.
It will allow IT to deliver a desktop with applications and data without compromising user experience by adding and/or removing layers to the desktop.
By delivering applications and data via layers (volumes) on a read-only virtual disk we can provide base layer applications with shell integration but also on a separate layer departement applications and even individual applications if needed.
Things to think about?
As the product itself works pretty slick (I had it up and running within the hour with different volumes) it does have some things to consider:
- It does not isolate applications; If you would need application isolation AppVolumes isn’t providing that. It would require another tech stack to do the isolation e.g. App-V, ThinApp or Spoon.
- Layering adds complexity and as Brian Madden states here VMware recommends that no more than 15 individual volumes be used per virtual desktop, meaning that you need to plan your Volumes very carefully.
And there’s always that user data question, luckily it got answered in the FAQ:
|Q. How does App Volumes work with user data?
A. Each device or user optionally has a single writable volume
that contains the device or user’s data and user installed
applications. If a user moves from one virtual desktop to
another, the data and user installed applications follow that user.
If you start with AppVolumes you need to have a full view of your application landscape up front. If you don’t have a clear view of your application landscape it will end up in a mess.
How does it work?
VMware provides an excellent deployment guide which provides us with the following architectural pictures:
To deploy your AppStack you’d first go into the AppVolumes Management console to create an AppStack, it will ask for a name and a VM to mount the writable VMDK. After the VMDK is mounted to the VM you can log in to the VM and will be prompted by AppVolumes to install your applications and confirm the installation of the applications. After a reboot all writes are committed to the VMDK and it will be stored to be shared and you can go back into the AppVolumes console and assign the AppStack to either users or groups (or both) from AD.
You can even choose if you want the VMDK be mounted immediately or at next logon/boot which results in direct delivery of applications and services.
What would I need to get it up and running?
The following items are needed before you can get AppVolumes up and running:
|AD users||An AD account with App Volumes Manager server and vCenter
administrator permissions for initial setup and connection
A designated AD user group that allows administrator access to the App
Volumes Manager server
A vCenter administrator-level account for AppStack virtual machine
End users require administrator privileges to install applications into their
writable volumes (UIA).
|App Volumes Management Server||Windows Server 2008 R2 or Windows 2012
Application Server Role must be enabled with .NET 3.5 framework
2 vCPUs (recommended 4 vCPUs)
4 GB of RAM
1 GB of disk space
|Hypervisor||VMware ESXi™ 5.x with Virtual Center 5.xHyper-V with SCVMM 2012 SP1|
|App Volumes agent||Windows 7/Windows 8.1
1 GB of RAM
5 MB of disk space
|App Volumes Manager
| SQL Express 2008 R2 supported for testing/non-production
SQL 2008 R2 or 2012 standard and above for production
A SQL server account with DB_Owner role is required for installation
|Supported browser to
|Active Directory||Microsoft AD Domain, 2003 functional or later|
|Licensing||Valid VMware App Volumes license deployed|
|Basic networking access
(defaults – these can be
|App Volumes Web Console: 80 (HTTP)/443 (HTTPS)
App Volumes Agent to Server Communications: 80 (HTTP)/443 (HTTPS)
App Volumes Server to vCenter and ESXi Hosts: 443 (SOAP/hostd)
App Volumes Server to remote SQL Server: 1433
App Volumes Server to AD Domain Controller: 389 (LDAP)/636 (LDAPS)
|Storage||Shared storage for all ESXi hosts that host desktops connecting to
AppStacks and writable volumes. Local host storage can be used for small test environments.
If local storage is used, AppStacks can be placed on the same datastorewhere VMs reside. The App Volumes service can be configured to refer to local storage before referring to shared storage. If specified AppStacks exist on the local storage, then these are mounted in favor of duplicate copies that exist on shared storage.
I wanted to create a video for my AppVolume deployment but I figured that there are some video’s from VMware that demonstrate the power of AppVolumes:
So how does this work out in a XenDesktop environment?
The whole concept of AppVolumes is more about communication between AppVolumes, vCenter (or SCVMM) and the VM and has limited interaction with the actual desktop broker so for a XenDesktop environment this works the same as for a View environment. As said, the installation and configuration took me less than an hour although the planning of AppStacks would take some more time.
My AppStack layers:
My XenDesktop VM:
Combining AppVolumes and Citrix XenApp/XenDesktop could be a very logical step, depending on the costs of the product it would be interesting to deploy large sets of applications via AppVolumes but remember it needs a lot of planning and a clear scope of applications.
Latest posts by Kees Baggerman (see all)
- Recovering a Protection Domain snapshot to a VM - September 13, 2019
- Checking power settings on VMs using powershell - September 11, 2019
- Updated: VM Reporting Script for Nutanix with Powershell - July 3, 2019
- Updated (again!): VM Reporting Script for Nutanix AHV/vSphere with Powershell - June 17, 2019
- Updated: VM Reporting Script for Nutanix AHV with Powershell - April 8, 2019