Why Upgrade to VMware App Volumes 2.10: Experience from the Field
On November 24, 2015, VMware announced general availability of VMware App Volumes 2.10. There are two important reasons to upgrade to App Volumes 2.10:
- To enjoy new product features
- To focus your team on planning rather than troubleshooting, due to many resolved issues
As a member of the VMware Professional Services Team, I have worked in the field with our End-User-Computing (EUC) portfolio, and mostly with App Volumes, because of its fast growth and high adoption rate with enterprises. I would like to share with you the different ways in which organizations are working with the product, which highlight the reasons for upgrading now.
What Is App Volumes?
VMware App Volumes is a real-time application delivery system that IT can use to dynamically deliver and manage applications. You do not need to modify desktops in order to work with App Volumes because applications act as if they were natively installed. The App Volumes solution can be scaled out easily and cost-effectively, without compromising end-user experience.
Figure 1: Traditional App Model Compared to Real-Time App Model with App Volumes
In the previous figure, you can see the difference between the traditional application model and the VMware App Volumes model. With App Volumes, the application is decoupled from the operating system, and user information can be redirected to a personal volume. This creates a flexible, dynamic environment.
Read on to learn what’s new in App Volumes 2.10 and why you might want to upgrade right away.
What’s New in App Volumes 2.10
The following features are new in App Volumes version 2.10.
Writable Volumes Easy Expansion
The App Volumes writable-volume template is 10 GB by default. Although 10 GB might be more than enough for most users, what happens when a user fills the writable volume? In this case, either you can tell the user to delete some files on their C: drive, which automatically removes the files from the writable volume, or you can extend the size of the writable volume for the user. Before App Volumes 2.10, increasing the size of a writable volume was a tedious manual procedure for expanding the VMDK file in vSphere. In App Volumes 2.10, you can increase the size of the writable volume with the click of a button in the App Volumes Manager interface.
Figure 2: Increasing the Size of a Writable Volume in App Volumes 2.10
After you click the Expand button, you specify the new size for the writable volume.
Figure 3: Confirming Expansion of a Writable Volume
If you are managing an end-user-computing environment, you are probably familiar with vSphere and all of its benefits. One of these benefits is vMotion, which is the ability to perform a live migration of a running virtual machine from one host to another. (Do not confuse this with storage vMotion or migrating a datastore.) Administrators are familiar with vSphere features such as vMotion, DRS, and ESXi host maintenance mode as part of normal operations. Older versions of App Volumes did not support vMotion while volumes were attached, which affected service operations, maintenance, and the load distribution in the system.
App Volumes 2.10 removes this limitation and includes vMotion support. (Storage vMotion is not yet supported.)
Windows 10 Support
App Volumes 2.10 is the first version to support the latest Windows version, Windows 10. If you are upgrading, make sure you also have versions of vSphere and View in Horizon 6 that support the Windows 10 guest OS.
Note: Windows apps (formerly Metro Apps or Windows Store apps) are not yet supported on App Volumes 2.10.
Support for vSphere 6 Update 1
App Volumes 2.10 includes all the benefits of Update 1 for vSphere 6, including the latest features of Virtual SAN, such as Stretch Cluster. Virtual SAN is the VMware innovative, easy-to-use, software-defined storage solution. Utilizing local disks from your ESXi hosts, you are able to create a shared datastore with sophisticated yet easy-to-use Storage Policy-Based Management (SPBM).
App Volumes 2.10 includes some important storage-group enhancements:
- AppStacks can now be replicated between datastores from different vCenter Servers.
- A datastore can be flagged as “non-attachable” to prevent it from mounting volumes to users. This is useful to ensure that a slower storage tier is used only for backup and replication purposes.
This is only a partial list of the features of the new App Volumes 2.10 release; for the full list, see the VMware App Volumes 2.10 Release Notes.
The following issues were resolved in App Volumes 2.10.
“Self-Healing” Capabilities and Preventing “Why Is Everything Detaching?” Situations
Before version 2.10, if the App Volumes Manager failed to communicate with the vCenter Server (maybe vCenter was down, or the service account was locked), after a period of time the App Volumes Manager detached all volumes from the desktops.
This issue was fixed in version 2.10. Now the App Volumes Manager stays in control even when vCenter is down or unreachable.
Also, as a “self-healing” mechanism, the App Volumes Manager now automatically discovers attachments that it missed while vCenter was processing.
These changes are dramatic and important because they keep a high service-level availability in production environments.
Default Time to Load Volumes Is Now 0
The App Volumes Agent has a value called VolDelayLoadTime, which is the time (in seconds) to delay loading a user’s volumes on login. The value is now 0 by default (no delay) to ensure a successful and smooth login. (VolDelayLoadTime is configurable by way of the Windows registry.)
This new default value fixes the following issues noted in VMware Knowledge Base articles for previous versions of App Volumes:
- Logging to VMware App Volumes 2.7/2.9 user gets “Temporary Profile” or finds two profiles
- Writable Volumes do not save some user profile settings in App Volumes 2.7.0 / 2.9.0
Support for Large Active Directory Groups
Prior to version 2.10, the App Volumes Manager could not utilize Active Directory groups with more than 1,500 members for volume assignments. Because VMware App Volumes technology is increasingly implemented by large enterprises, this limitation was removed in version 2.10.
Ensuring No Drive Letter Is Mistakenly Assigned by Windows
All of the App Volumes templates (AppStack and writable-volume templates) in version 2.10 are configured by default with NODEFAULTDRIVELETTER to ensure that no drive letter is assigned by Windows mountvol (which creates, deletes, or lists a volume mount point).
If Windows mistakenly assigns a drive letter, this can cause confusion to the end user and potentially errors. You can avoid this when you use the updated 2.10 default templates.
Note: If needed, you can revert this change for a specific use case. Contact VMware Support for assistance.
Summary and Next Steps
Upgrading to App Volumes 2.10 provides new features and capabilities, with some critical resolved issues.
What are you waiting for? Upgrade today!
For more information about upgrading to App Volumes 2.10, go to the App Volumes download site.