Category Archives: App Volumes

This section is about App Volumes infrastructure components.

App Volumes: Architecture, Security, Storage, and Logs…Oh My!

So, you’ve gone and gotten yourself a copy of App Volumes, or are thinking about it? Welcome to the club. It is a pretty slick piece of software, and I am really enjoying working with it. We have replaced our Unidesk deployment with Horizon Enterprise using App Volumes for application delivery. If you already have App Volumes deployed, or are even just thinking about it, here is some info that may be of use. Shout out to @chrisdhalstead and @VirtualStef for all the great info presented here. They put on some great sessions at VMworld this year.

Architecture Considerations:

2 App Volumes Managers at minimum, load balanced.

SQL Express for Dev / Test ONLY

Clustered SQL servers

App Volumes – Storage


  • Read Only
  • 1:Many
  • 20GB Default Template
  • Dedicated Datastore Recommended for AppStacks
  • Right-Size your templates (No need for 20GB template for a 10MB program)

Writable Volumes

  • Read / Write
  • 1:1 Per User
  • 10GB Default Template
  • Right-Size your templates here too.

Optimize storage volumes for Writable Volumes

  • Consider RAID 1 or RAID 10

Flash Storage Array Support

User Concurrency for each application and storage requirement may impact IOPS

Security Considerations

Replace default self-signed SSL certificate for App Volumes Manager (svserver.crt)

Deploy ThinApp packaged applications to leverage isolation modes

Use a read-only Active Directory service account for App Volumes

  • vCenter Administrator Privileges required for mount operations.
  • ESXi root required if using local mount option

App Volumes – Agent Log Files

The App Volumes Agent has 2 log files that can be found on the machine. These two files are the svservice.log and the svdriver.log. Both of these logs can be found in the same directory:


The App Volumes Agent can be found in the Windows Services, as with any other agents. Check there if you’re not getting any response or issues from the agent.

App Volumes – Manager Log Files

The App Volumes Manager also has 2 log files that can be found on the App Volumes Manager server. These logs are called production.log and svmanager_server.log. Both of these logs can be found in the same directory:

C:\Program Files(x86)\CloudVolumes\Manager\*.log


Hopefully some of this info was helpful to you. If you have any questions or concerns about your deployment, feel free to leave a comment or tweet in my general direction. Happy Stacking!



App Volumes 2.9 “Upgrade” – And Migration

Well, it’s 7:00AM on a Saturday. Of course, that means its the only real time I have to take any production systems offline. Today’s task involves getting App Volumes migrated to a new storage frame. In order to do this, I need to upgrade it from 2.6 to 2.9 so that I can take advantage of Storage Group Automation. More on that shortly. If you’re not familiar with App Volumes, it is a semi-recent acquisition by VMware of a company called Cloud Volumes. It is a seamless virtual application delivery platform. See here:

This product is fantastic. Though, I have found a small issue. You may have noticed above that the word upgrade is in quotes. This is because there is no upgrade.  You have to fully uninstall the management server and re-install the newer version on top of the existing database and app stacks on your storage. Yes, you retain your existing app stacks. It just seems sketchy. This process is outlined in the App Volumes 2.9 user guide found here.

The first step is to completely uninstall the existing App Volumes Manager. Note that this does unmount all app stacks! The services will be unavailable. No reboot is required when doing this. Next, mount the App Vols 2.9 ISO to the management server. I find it is easier later to just unload all the files from the ISO to a share. That way I can access the agent later without the ISO. When you are going through the install, make sure that you select to use an existing DB server. Point it at your SQL instance, and make sure that the overwrite checkbox is UNCHECKED.



Let the installer do its thing. Leave the connection ports default, unless you changed them for your installation. Once the installer is done, you should be able to log back into the Manager with the same credentials you did before.



All you do now is update your templates with the new agent, and recompose the pools. If you want, do it manually. Whatever you’re into.


And now what everybody has been waiting for….



I had to complete this upgrade today, because of my real problem. We are migrating our VDI environment off of a shared EMC VNX storage frame to a new dedicated Compellent storage frame. App Volumes 2.6 doesn’t make this an easy task. App Volumes 2.9 includes a nifty little update called Storage Group Automation. This allows the software to replicate the stacks to the new storage for you.

You start off by going into Infrastructure -> Storage Groups. From there you’ll want to create a new storage group. Give it a name like “temp_migration.” Leave auto import app stacks unchecked, but do select Automatically Replicate AppStacks. This is the key to the software moving stuff for you. Select Spread for the Distribution Strategy. Select what volume you want for your Template Storage. Under Storage Selection, choose Direct, then select the existing AppStack LUN as well as the new LUN.



Once you hit Create, the magic starts automatically. As soon as all the copy operations are done in vCenter, you should be fully replicated. Simply go in and delete the Storage Group.