Home > Blogs > VMware Consulting Blog > Tag Archives: App Volumes

Tag Archives: App Volumes

App Volumes Writable Volumes Orphaned

JeffSmallBy Jeffrey Davidson

In this blog entry I will talk about App Volumes and how Writable Volumes can become orphaned.

In some cases Writable Volumes can become orphaned as shown below.

JDavidson Writable Volumes 1

This status message can be confusing. The status message makes it seem as if the Writable Volume may be missing, or there is some other issue at hand. However, that may not be the case.

In some cases this orphaned state occurs when the owner user account in Active Directory is disabled, as shown below.

JDavidson Writable Volumes 2

When an account in Active Directory has been assigned an App Volumes—or a Writable Volume is disabled or deleted—the users’ Writable Volume can become orphaned when App Volumes synchronizes with Active Directory. As a result of this process, the status of the Writable Volume changes to orphaned.


Jeffrey Davidson, Senior Consultant, VMware EUC. Jeffrey has over 15 years of IT experience and joined VMware in 2014. He is also a VCP5-DCV and VCP5-DT. He is a strong advocate of virtualization technologies, focusing on operational readiness with customers.

 

App Volumes AD Objects Move Issue

JeffSmallBy Jeffrey Davidson

In this blog entry I will talk about App Volumes and things to check when you are having trouble logging in.

There are times when a user may not be able to login to the App Volumes Manager Server. Users might get a message similar to “You must be in the Administrators group to login” as shown below. There can be a few reasons for this issue to occur.

App Volumes AD Objects Move Issue JDavidson 1

The first is that an administrators group needs to be defined in the App Volumes configuration, which is done during the initial setup of the App Volumes instance. Users need to be members of this group in order to login to the App Volumes Manager Server.

Secondly, you need to validate the App Volumes Manager Server to be able to communicate with the SQL instance configured during installation and Active Directory. The credentials for connectivity to both environments should be verified.

If you have validated that all of the above configurations are accurate and the services are running, there is one other thing you should investigate; this issue can occur if the user object has been moved in Active Directory. For example, a user was in the “Chicago” organizational unit (OU) and has been moved to the “Cleveland” OU. When an object is moved in this way, App Volumes can have trouble finding the user because its distinguished name (DN) value in Active Directory has changed. App Volumes stores the user DN value in the “Users” App Volumes SQL database table.

App Volumes AD Objects Move Issue JDavidson 2

To restore App Volumes functionality to the object, the App Volumes SQL database needs to be updated with the new Active Directory DN value. This is done by retrieving the correct DN value from Active Directory, then updating the database record for that user.

App Volumes AD Objects Move Issue JDavidson 3

Updating the SQL record can be done directly through SQL Server Management Studio.

If this issue is occurring for all users then you will want to validate that the Active Directory group—defined as the App Volumes Administrators group—has not been move. In this circumstance you will want to validate the DN of the group specified in the App Volumes SQL Database against its location in Active Directory. The administrators group DN is stored in the “group_permissions” App Volumes SQL database table.

App Volumes AD Objects Move Issue JDavidson 4

If the group has been moved you will need to update the App Volumes SQL Database with the DN value of the new group.

App Volumes AD Objects Move Issue JDavidson 5

This record can also be updated directly through SQL Server Management Studio.


Jeffrey Davidson, Senior Consultant, VMware EUC. Jeffrey has over 15 years of IT experience and joined VMware in 2014. He is also a VCP5-DCV and VCP5-DT. He is a strong advocate of virtualization technologies, focusing on operational readiness with customers.

 

Copying App Volumes AppStacks Between Environments That Use vSAN Storage

JeffSmallBy Jeffrey Davidson

There is an issue copying App Volumes AppStacks (VMDK files) if using Secure Copy (SCP) from one environment to another when using VSAN storage. This is not an App Volumes problem; it is related to the way VSAN stores VMDK data.

Clients will often want to create AppStacks in a test environment, then copy those AppStacks to a production environment, and finally import them into App Volumes. In situations where any of those environments use VSAN storage, you will not be able to copy (SCP) AppStacks (specifically VMDK files) between environments.

In this blog entry I will discuss a workaround to this issue, using an example in which the client has two VSAN environments (DEV and PROD), and needs to copy VMDK files between them.

The VMDK files created by App Volumes are nothing special and are traditionally comprised of two files.

What we normally identify as <filename>.vmdk is a type of header/metadata file. Meaning it only holds information regarding the geometry of the virtual disk and, as such, references a file that contains the actual data.

The file referenced is often called a “flat” file; this file contains the actual data of the VMDK. We can identify this file as it has the naming pattern of <filename>-flat.vmdk

On traditional block level storage these two files are normally stored together in the same folder, as shown in the example screenshot below.

JDavidson1

But VSAN storage is different; if you look at the contents of the “header” file you see something similar to the screenshot below. In this screenshot, the section in red is normally a reference to a “flat” file (example: Adobe_Acrobat_Reader -flat.vmdk). In the case where VSAN is the storage platform, we see something different. The screenshot below shows a reference to a VSAN device.

JDavidson2

VSAN storage employs object-level storage, which is different from traditional block-level storage. The VSAN objects are managed through a storage policy which, for example, can allow for greater redundancy for some virtual machines over others. Because the reference in the VMDK file points to a VSAN DOM object, it cannot be copied through traditional means (SCP).

To work around this issue you will need traditional block-level storage which acts as a “middle man” to allow the SCP copy of VMDK files between environments. You will also need SSH access enabled on one host in each environment.

The first step is to clone the VMDK you wish to copy from the VSAN volume to the traditional storage volume. Once on traditional storage you will be able to copy (SCP) the two VMDK files directly to a host in a different VSAN environment. After you have copied (SCP) the VMDK files to a destination VSAN environment, you will need to perform a clone action to re-integrate the VMDK with VSAN as a storage object, so it can be protected properly with VSAN.

The diagram below is an overview of the process to copy AppStack (VMDK) files between VSAN environments.

JDavidson3

The example below shows the commands required to copy an App Volumes AppStack (VMDK) between environments that use VSAN storage. Before executing these commands you should create a staging area in each environment where AppStacks will be copied temporarily before being copied between hosts for getting re-integrated in the destinations’ VSAN storage.

For example:

In the source environment, create the folder <path to block level storage>/AppVolumes_Staging

In the destination environment, create the folder <path to cloud volumes root folder>/cloudvolumes/staging

Step 1:

SSH into the host where the AppStack currently resides.

Execute the following command to clone the AppStack to block-level storage. Note that after you execute this command there are two files on the block-level storage. One is the header file, and the other is the “flat” file, which was previously integrated with VSAN as a storage object.

vmkfstools -d thin -i <VSAN path to App Stack>/cloudvolumes/apps/<filename>.vmdk <path to block level storage>/AppVolumes_Staging/<filename>.vmdk

Example:

vmkfstools -d thin -i /vmfs/volumes/vsan:4a65d9cbe47d44af-80f530e9e2b98ac5/76f05055-98b3-07ab-ef94-002590fd9036/apps/<filename>.vmdk /vmfs/volumes/54e5e55d-97561a60-50de-002590fd9036/AppVolumes_Staging/<filename>.vmdk


Step 2:

Execute the following commands to copy (SCP) an AppStack from one environment to another.

scp <path to vmdk clone on block level storage>/<filename>.vmdk root@<esxi mgt IP>:<path to staging folder>/<filename>.vmdk

scp <path to vmdk “flat” file clone on block level storage>/<filename>-flat.vmdk root@<esxi mgt IP>:<path to staging folder>/<filename>-flat.vmdk

Example:

scp /vmfs/volumes/54e5e55d-97561a60-50de-002590fd9036/AppVolumes_Staging/<filename>.vmdk root@10.10.10.10:/vmfs/volumes/vsan:265d91daeb2841db-82d3d8026326af8e/6efbac55-f2f7-f86a-033f-0cc47a59dc1c/Staging/<filename>.vmdk

scp /vmfs/volumes/54e5e55d-97561a60-50de-002590fd9036/AppVolumes_Staging/<filename>-flat.vmdk root@10.10.10.10:/vmfs/volumes/vsan:265d91daeb2841db-82d3d8026326af8e/6efbac55-f2f7-f86a-033f-0cc47a59dc1c/Staging/<filename>-flat.vmdk


Step 3:

Run the commands below to delete the AppStack from the staging folder on the source environment.

rm <path to staging folder>/<filename>.vmdk

rm <path to staging folder>/<filename>-flat.vmdk

Example:

rm /vmfs/volumes/54e5e55d-97561a60-50de-002590fd9036/AppVolumes_Staging/<filename>.vmdk

rm /vmfs/volumes/54e5e55d-97561a60-50de-002590fd9036/AppVolumes_Staging/<filename>-flat.vmdk


Step 4:

SSH into the host where the AppStack has been copied to. In this example the host IP address is 10.10.10.10.

Run the command below to clone the copied AppStack from the staging folder to the App Volumes “apps” folder, and re-integrate the VMDK into VSAN as a storage object.

vmkfstools -d thin -i <path to staging folder>/<filename>.vmdk <path to cloud volumes root folder>/cloudvolumes/apps/<filename>.vmdk

Example:

vmkfstools -d thin -i /vmfs/volumes/vsan:265d91daeb2841db-82d3d8026326af8e/6efbac55-f2f7-f86a-033f-0cc47a59dc1c/Staging/<filename>.vmdk /vmfs/volumes/vsan:265d91daeb2841db-82d3d8026326af8e/6efbac55-f2f7-f86a-033f-0cc47a59dc1c/apps/<filename>.vmdk


Step 5:

Run the commands below to delete the AppStack from the staging folder on the destination environment.

rm <path to staging folder>/<filename>.vmdk

rm <path to staging folder>/<filename>-flat.vmdk

Example:

rm /vmfs/volumes/vsan:265d91daeb2841db-82d3d8026326af8e/6efbac55-f2f7-f86a-033f-0cc47a59dc1c/Staging/<filename>.vmdk

rm /vmfs/volumes/vsan:265d91daeb2841db-82d3d8026326af8e/6efbac55-f2f7-f86a-033f-0cc47a59dc1c/Staging/<filename>-flat.vmdk
After completing these steps, you will have successfully copied a VMDK from one VSAN storage platform to another.

App Volumes also creates a “metadata” file during the creation of an AppStack, as shown in the screenshot below.

JDavidson4

The “metadata” file is a “text” file and should be copied to the destination environment so the AppStack (VMDK) can be imported into the destination App Volumes instance. Because this is a “text” file, it can be copied (SCP) without the cloning process and need for block-level storage as described in steps 1–5 above.


Jeffrey Davidson, Senior Consultant, VMware EUC. Jeffrey has over 15 years of IT experience and joined VMware in 2014. He is also a VCP5-DCV and VCP5-DT. He is a strong advocate of virtualization technologies, focusing on operational readiness with customers.

EUC Professional Services Engineering (PSE) and VMworld

By Dale Carter

VMworld in San Francisco is approaching very quickly. It’s a must-attend event for VMware customers, but there is a lot to take in, so I thought I would take a few minutes to highlight some key activities led by my team of End User Computing (EUC) consultants and architects that you won’t want to miss.

Our organization is called Professional Services Engineering (PSE) and is part of the Global Technical and Professional Services Organization. As VMware’s EUC subject matter experts, our team works with some of our largest EUC customers worldwide. From our experiences with these large organizations, our team is responsible for creating VMware’s EUC methodologies, which are then leveraged by our global EUC professional services organization.

VMworld Sessions Delivered by the PSE Team:

EUC4630 – Managing Users: A Deep Dive into VMware User Environment Manager

Managing end-user profiles can be challenging, and often the bane of a desktop administrator’s existence. To the rescue comes VMware’s User Environment Manager. In this session, attendees will be provided with a deep dive into UEM, including an architectural overview, available settings and configurations, and user environment management options. The session will also outline UEM deployment considerations and best practices, as well as discuss how to integrate UEM into a Horizon 6 environment. Attendees will even learn how UEM can be used to manage physical desktops.

EUC5516 – Delivering the Next Generation of Hosted Applications

VMware continues to innovate and evolve our EUC products with the introduction of Hosted Applications with Horizon 6, VMware UEM, App Volumes and Workspace. Join our experienced experts for a panel discussion on how VMware technologies can be used to support your existing Server Based Computing (SBC) infrastructure or move away from it all together onto a platform that addresses what people want, not just what a published application needs.

EUC4437 – Horizon View Troubleshooting – Looking Under the Hood

Attend one of the most popular EUC sessions from previous VMworlds! Learn from VMware’s best field troubleshooters on how to identify common issues and key problem domains within VMware Horizon View.

EUC4509 – Architecting Horizon for VSAN, the VCDX Way – VMware on VMware

VMware Horizon is a proven desktop virtualization solution that has been deployed around the world. Balancing the performance and cost of a storage solution for Horizon can be difficult and affects the overall return on investment. VMware Virtual SAN has provided architects with a new weapon in the battle for desktop virtualization. VSAN allows architects to design a low-cost, high-performance hybrid solution of solid-state and spinning disks, or go all-flash for ultimate desktop performance. Learn from two Double VCDXs on how to go about architecting your Horizon on VSAN solution to ensure it will provide the levels of performance your users need, with management simplicity that will keep your administrators happy and a cost that will ensure your project will be a success.

EUC5126 – Citrix Migration to VMware Horizon: How to Do It and What You Need to Know

Are you planning a migration from Citrix XenApp or XenDesktop to VMware Horizon? Or simply interested in learning how to do it? This is the session for you! Come hear from the architects of VMware’s Citrix migration strategies and services as they break down different approaches to migration using real-world case studies. We will dive deep into how to evaluate the state of the Citrix environment, assess system requirements, design the Horizon infrastructure, and then plan and perform the migration. By the end of the session you will know all the best practices, tips, tricks and tools available to make sure your migration from Citrix to VMware Horizon is a complete success!

VMworld Booth in the Solutions Exchange

We can also be found at the Professional Services demo station in the VMware booth Wednesday from 12–4 PM. Come by with your EUC questions or just discuss any EUC solutions you are looking to implement in your organization. I will be there along with my colleague Nick Jeffries.

VMworld Hands On Labs

Finally, my colleague Jack McMichaels and I will both be working in the VMworld Hands On Labs this year. The Hands On Labs are a great way to come and try all of the VMware technologies. If you have never attended a Hands On Lab at VMworld then I would highly encourage you to come and give them a go. They are a great way to learn if you have an hour or two to spare in your agenda.

See you in San Francisco!


Dale is a Senior Solutions Architect and member of the CTO Ambassadors. Dale focuses in the End User Compute space, where Dale has become a subject matter expert in a number of the VMware products. Dale has more than 20 years experience working in IT having started his career in Northern England before moving the Spain and finally the USA. Dale currently hold a number of certifications including VCP-DV, VCP-DT, VCAP-DTD and VCAP-DTA.

For updates you can follow Dale on twitter @vDelboy

Complex Apps

Jeremy WheelerBy Jeremy Wheeler

From time to time we all come across that extremely complicated application that an organization needs packaged – and of course, it has a lot of moving parts. In this blog entry I will walk through a proven process that has worked successfully, unlike the typical packaging style where, if you make a mistake, you are back at square one. An important key to keep in mind in this blog is the “disposable virtual machine.” I consider a disposable virtual machine an App Volumes Provisioning that will eventually become contaminated, and you will not be able to revert to a clean-state using a snapshot.

Note: Not utilizing a ‘disposable’ provisioning machine will place your normal provisioning machine at risk. The very end of this process involves removing ALL snapshots from the virtual machine.

JWheeler Complex Apps Stage 1

 

1. Prepare a ‘disposable’ provisioning machine. This virtual machine will lose all its snapshots once you finish this process, so it’s best not to use your typical provisioning machine.

2. Point the App Volumes Manager to the Provisioning virtual machine to start the provisioning process.

JWheeler Complex App Stage 2

3. Install any prerequisite applications such as Java, etc.

4. Power down the Provisioning virtual machine and take a snapshot, using this as more of a bookmark in case you need to go back. The snapshot process will capture all the virtual machine elements including the attached App Volume VMDK file as long as you are still in provisioning mode when you powered down the virtual machine.

5. Power on the virtual machine and continue installing any core applications, or your target application. One step my application required was an installation of SQL Express with an imported database, so I installed SQL Express during this step.

6. Power down the Provisioning machine once SQL is cleanly installed and has created another snapshot.

JWheeler Complex Apps Stage 3

7. Power on the provisioning virtual machine, and create any custom databases, accounts, etc.

8. Power down the virtual machine once you have completed all your installs and are ready to complete the App Volumes capture process.

9. Edit the virtual machine’s snapshots (VM > Snapshot > Snapshot Manager) and then ‘Remove All Snapshots.

10. Once the virtual machine’s snapshots have all been removed, you need to consolidate the redo logs. (VM > Snapshot > Consolidate)

11. Once consolidation has completed, power on the virtual machine

12. Select ‘OK’ on the App Volumes dialog box to complete the provisioning process and let the virtual machine reboot.

13. Login to the virtual machine and you should have the message that provisioning has finished successfully. Select ‘OK’

14. Provisioning is now complete and the VMDK should successfully detach from the virtual machine.

Once you complete these steps I recommend a lot of testing to validate the application is performing as expected.


Jeremy Wheeler is an experienced senior consultant and architect for VMware’s Professional Services Organization, End-user Computing specializing in VMware Horizon Suite product-line and vRealize products such as vROps, and Log Insight Manager. Jeremy has over 18 years of experience in the IT industry. In addition to his past experience, Jeremy has a passion for technology and thrives on educating customers. Jeremy has 7 years of hands-¬‐on virtualization experience deploying full-life cycle solutions using VMware, CITRIX, and Hyper-V. Jeremy also has 16 years of experience in computer programming in various languages ranging from basic scripting to C, C++, PERL, .NET, SQL, and PowerShell.

Jeremy Wheeler has received acclaim from several clients for his in-¬‐depth and varied technical experience and exceptional hands-on customer satisfaction skills. In February 2013, Jeremy also received VMware’s Spotlight award for his outstanding persistence and dedication to customers and was nominated again in October of 2013

VMware App Volumes Multi-vCenter and Multi-Site Deployments

By Dale Carter

With the release of VMware App Volumes 2.9 comes one of the most requested features so far: multi-vCenter support. With multi-vCenter support it is now possible to manage virtual desktops and AppStacks from multiple vCenter instances within the same App Volume Manager.

The following graphic shows how this works:

DCarter App Volumes

With this new feature App Volumes can now be used to support the Horizon Block and Pod architecture with just one App Volumes manager, or cluster of managers.

Now that we can support multi-vCenters, I started to wonder if this new capability could be leveraged across multiple sites to help support multiple site deployments.

After speaking with the App Volumes Product Manager, I am happy to confirm that, “Yes,” you can use this new feature to support multi-site deployments – as long as you are using the supported SQL database.

The architecture for this type of deployment would look like this:

DCarter App Volumes 2

 

I would recommend that App Volumes Managers at each site be clustered. Read the following blog to learn how to cluster App Volumes Managers: http://blogs.vmware.com/consulting/2015/02/vmware-appvolumes-f5.html

Although 2.9 is just a point release, this is one of the biggest features added so far for multi-vCenter support.

To add a second―or more―vCenter instance to App Volumes, follow these simple steps:

  1. Login to the App Volumes Manager
  2. Select Configuration, then Machine Manager, and then click Add Machine Manager
    DCarter App Volumes 3
  3. Enter the vCenter information and click Save.
    DCarter App Volumes 4
  4. Follow these steps for each vCenter instance you want to add.

Dale is a Senior Solutions Architect and member of the CTO Ambassadors. Dale focuses in the End User Compute space, where Dale has become a subject matter expert in a number of the VMware products. Dale has more than 20 years experience working in IT having started his career in Northern England before moving the Spain and finally the USA. Dale currently hold a number of certifications including VCP-DV, VCP-DT, VCAP-DTD and VCAP-DTA.

For updates you can follow Dale on twitter @vDelboy

VMware App Volumes™ with F5’s Local Traffic Manager

By Dale Carter, Senior Solutions Architect, End User Computing & Justin Venezia, Senior Solutions Architect, F5 Networks

App Volumes™—a result of VMware’s recent acquisition of Cloud Volumes—provides an alternative, just-in-time method for integrating and delivering applications to virtualized desktop- and Remote Desktop Services (RDS)-based computing environments. With this real-time application delivery system, applications are delivered by attaching virtual disks (VMDKs) to the virtual machine (VM) without modifying the VM – or the applications themselves. Applications can be scaled out with superior performance, at lower costs, and without compromising the end-user experience.

For this blog post, I have colluded with Justin Venezia – one of my good friends and a former colleague now working at F5 Networks. Justin and I will discuss ways to build resiliency and scalability within the App Volumes architecture using F5’s Local Traffic Manager (LTM).

App Volumes Nitty-Gritty

Let’s start out with the basics. Harry Labana’s blog post gives a great overview of how App Volumes work and what it does. The following picture depicts a common App Volumes conceptual architecture:

HLabana AppVolumes

 

Basically, App Volumes does a “real time” attachment of applications (read-only and writable) to virtual desktops and RDS hosts using VMDKs. When the App Volumes Agent checks in with the manager, the App Volumes Manager (the brains of App Volumes) will attach the necessary VMDKs to the virtual machines through a connection with a paired vCenter. The App Volumes Agent manages the redirection of file system calls to AppStacks (read-only VMDK of applications) or Writeable Volumes (a user-specific writeable VMDK). Through the Web-based App Volumes Manager console, IT administrators can dynamically provision, manage, or revoke applications access. Applications can even be dynamically delivered while users are logged into the RDS session or virtual desktop.

The App Volumes Manager is a critical component for administration and Agent communications. By using F5’s LTM capabilities, we can intelligently monitor the health of each App Volumes Manager server, balance and optimize the communications for the App Volume Agents, and build a level of resiliency for maximum system uptime.

Who is Talking with What?

As with any application, there’s always some back-and-forth chatter on the network. Besides administrator-initiated actions to the App Volumes Manager using a web browser, there are four other events that will generate traffic through the F5’s BIG-IP module; these four events are very short, quick communications. There aren’t any persistent or long-term connections kept between the App Volumes Agent and Manager.

When an IT administrator assigns an application to a desktop/user that is already powered on and logged in, the App Volumes Manager talks directly with vCenter and attaches the VMDK. The Agent then handles the rest of the integration of the VMDK into the virtual machine. When this event occurs, the agent never communicates with the App Volumes Manager during this process.

Configuring Load Balancing with App Volume Managers

Setting up the load balancing for App Volumes Manager servers is pretty straightforward. Before we walk through the load-balancing configuration, we’ll assume your F5 is already set up on your internal network and has the proper licensing for LTM.

Also, it’s important to ensure the App Volume agents will be able to communicate with the BIG-IP’s virtual IP address/FQDN assigned to App Volumes Manager; take the time to check routing and access to/from the agents and BIG-IP.

Since the App Volumes Manager works with both HTTP and HTTPS, we’ll show you how to load balance App Volumes using SSL Termination. We’ll be doing SSL Bridging: SSL from the client to the F5 → it is decrypted → it is re-encrypted and sent to the App Volumes Manager server. This method will allow the F5 to use advanced features—such as iRules and OneConnect—while maintaining a secure, end-to-end connection.

Click here to get a step-by-step guide on integrating App Volumes Manager servers with F5’s LTM. Here are some prerequisites you’ll need to consider before you start:

  • Determine what the FQDN will be and what virtual IP address will be used.
  • Add the FQDN and virtual IP into your company’s DNS.
  • Create and/or import the certificate that will be used; this blog post, does not cover creating, importing and chaining certificates.

The certificate should contain the FQDN that we will use for load balancing. We can actually leave the default certificates on the App Volumes Manager servers. BIG-IP will handle all the SSL translations, even with self-signed certificates created on the App Volumes servers. A standard, 2,048-bit web server (with private key) will work well with the BIG-IP, just make sure you import and chain the Root and Intermediate Certificates with the Web Server Certificate.

Once you’re done running through the instructions, you’ll have some load-balanced App Volumes Manager servers!

Again, BIG thanks to Justin Venezia from the F5 team – you can read more about Justin Venezia and his work here.


Dale is a Senior Solutions Architect and member of the CTO Ambassadors. Dale focuses in the End User Compute space, where Dale has become a subject matter expert in a number of the VMware products. Dale has more than 20 years experience working in IT having started his career in Northern England before moving the Spain and finally the USA. Dale currently hold a number of certifications including VCP-DV, VCP-DT, VCAP-DTD and VCAP-DTA.

For updates you can follow Dale on twitter @vDelboy

Justin Venezia is a Senior Solutions Architect for F5 Networks

Application Delivery Strategy: A Key Piece in the VDI Design Puzzle

By Michael Bradley and Hans Bader

Let’s face it: applications are the bane of a desktop administrator’s existence. It seems there is always something that makes the installation and management of an application difficult and challenging. Whether it’s a long list of confusing and conflicting requirements or a series of software and hardware incompatibilities, management of applications is one of the more difficult aspects of an administrator’s job.

It’s not surprising that application delivery and management is one of the key areas that often gets overlooked when planning and deploying a virtual desktop infrastructure (VDI), such as VMware’s Horizon View 6. This often-overlooked aspect is a common pitfall hindering many VDI implementations. A great deal of work and effort goes into ensuring that desktop images are optimized, the correct corporate security settings are applied to the operating system, the underlying architecture is built to scale appropriately, and the guaranteed end-user performance is acceptable. These are all important goals that require attention, but the application delivery strategy is frequently missed, forgotten, or even ignored.

Before we go further, let’s take a moment to define application delivery. A long time ago in a cube farm far, far away, application delivery was all about getting the applications installed on the desktop. But with the emergence of new technologies the definition has evolved. Software application delivery is no longer solely about the installation; it has taken on a broader meaning. In today’s end-user environment, application delivery is more about providing the end-user with access to the applications they need. In today’s modern enterprise, end-user access can come in many different forms. Some of the most common examples are:

  • Installing applications directly on the virtual desktop, either manually or by using software such as Microsoft SCCM.
  • Application virtualization using VMware ThinApp or Microsoft’s App-V.
  • Delivering the applications to the desktop using technologies such as VMware App Volumes or Liquidware Labs’ FlexApp.
  • Application presentation using RDS Hosted Applications in VMware Horizon 6.

All these examples are application delivery mechanisms. Each one can solve a different application deployment problem, and each can be used alone or in conjunction with a complimentary one. For example, using App Volumes to delivery ThinApps.

An application delivery strategy should be an integral part of your VDI design; it is just as crucial as the physical infrastructure, like storage, networking, processing and the virtual infrastructure. It is perfectly alright to have a top-notch VDI, but if you can’t deliver new and existing applications to your end-users in a fast and efficient manner, you might be spinning your bits and bytes. Your end-users need applications delivered efficiently and quickly, or the VDI project becomes a bottleneck. The prime factor to remember about VDI is it forces you to change the way you operate. Features―such as VMware’s Linked Clone technology―can change the application delivery paradigm that many desktop administrators have grown accustomed to in a physical PC world. Let’s face it: how effective is it to push and install applications to linked clone desktops every time a desktop refreshes or recomposes?

To this end, if an application delivery strategy is so important, why is it often missed or ignored? There are three primary reasons for this:

  • First, it is simply forgotten, or the VDI designers simply don’t realize they need to consider it as part of the design.
  • Second, application delivery is often considered too big of a challenge, and no one wants to tackle it when they’re already facing tight deadlines on a VDI project.
  • Third, and probably most commonly heard in enterprise environments, is there is already a mechanism in place for application delivery for physical PCs, so it is assumed that what exists will suffice.

Once the need for an application delivery strategy is established, you need to determine what goes into one. First, you need to consider all tiers of your applications: tier one, tier two, tier-n. With that be sure to identify which are most common. Determine which applications need to be provided to all end-users versus which ones go to just a small subset. That will help determine what could be installed in the base image, as opposed to being delivered by some other mechanism. For instance, Microsoft Office may be an application that would be included in the base image for all users, but a limited use accounting package may only be required for the accounting team, and therefore delivered another way.

Next, consider the delivery mechanism for your virtual desktops. Are they all full virtual machine desktops – or linked clone desktops? Determining which type you are using will play a major part in what your application delivery strategy looks like. If you are using all full virtual machine desktops―which deserves serious consideration―then you could effectively continue to use the existing application delivery strategy you use for physical PCs. But using linked clones could cause your existing application delivery strategy to become a bottleneck.

Then, you need to consider what technology will work best for you and your applications. Will application virtualization such as ThinApp be a suitable mechanism? Or, perhaps using RDS Hosted Applications in Horizon 6 is a more viable option for application delivery. You may even find the best option is a combination of technologies. You should take time to evaluate the pros and cons of each option to ensure the needs of your end-users are met ‒ and with efficiency. One question you should ask is, “Do my end-users have the ability to install their own applications?” If the answer is “yes,” you need to ensure you either change corporate policy or select a technology that supports user-installed applications. Keep in mind that an application delivery strategy can vary for different types of users.

Finally, you should consider how to handle one-off situations. There will always be the one user, or a small group of users, who require a specialized application that falls outside the realm of your standard application delivery mechanisms. Determining how to address those instances are rare but inevitable, but as a desktop administrator, it will help you respond quickly to the needs of your end-users.

A good VDI implementation is only successful if the end-users can perform their assigned tasks. Nine times out of ten, that requires access to applications. Ensuring you have a strategy in place to ensure delivery of the right applications to the right end-users is vital to the success of any VDI implementation.


Michael Bradley

Michael Bradley, a VMware Senior Solutions Architect specializing in the EUC space, has worked in IT for almost 20 years. He is also a VCP5-DCV, VCAP4-DCD, VCP4-DT, VCP5-DT, and VCAP-DTD, as well as an Airwatch Enterprise Mobility Associate.

 

Hans Bader

Hans Bader Consulting Architect, VMware EUC. Hans has over 20 years of IT experience and joined VMware in 2009. With a focus on helping organizations being operationally ready, he works with customers to avoid common mistakes.  He is a strong advocate for proactive load testing of environment before allowing users access.  Hans has won numerous consulting awards within VMware.

App Volumes AppStacks vs. Writable Volumes

By Dale Carter, Senior Solutions Architect, End-User Computing

With the release of VMware App Volumes I wanted to take the time to explain the difference between AppStacks and Writable Volumes, and how the two need to be designed as you start to deploy App Volumes.

The graphic below shows the traditional way to manage your Windows desktop, as well as the way things have changed with App Volumes and the introduction of “Just-in-time” apps.

DCarter AppVolumes v Writable Volumes 1

 

So what are the differences between AppStacks and Writable Volumes?

AppStacks

An AppStack is a virtual disk that contains one or more applications that can be assigned to a user as a read-only disk. A user can have one or many AppStacks assigned to them depending on how the IT administrator manages the applications.

When designing for AppStacks it should be noted that an AppStack is deployed in a one-to-many configuration. This means that at any one time an AppStack could be connected to one or hundreds of users.

DCarter AppVolumes v Writable Volumes 2

 

When designing storage for an AppStack it should also be noted that App Volumes do not change the IOPS required for an application, but it does consolidate the IOPS to a single virtual disk. So like any other virtual desktop technology it is critical to know your applications and their requirements; it is recommended to do an application assessment before moving to a large-scale deployment. Lakeside Software and Liquidware Labs both publish software for doing application assessments.

For example, if you know that on average the applications being moved to an AppStack use 10 IOPS, and that the AppStack has 100 users connected to it, you will require 1,000 IOPS average (IOPS pre-user x number of users) to support that AppStack; you can see it is key to designing your storage correctly for AppStacks.

In large-scale deployments it may be recommended to create copies of AppStacks and place them across storage LUNs, and assign a subset of users to each AppStack for best performance.

DCarter AppVolumes v Writable Volumes 3

 

Writable Volumes

Like AppStacks, a Writable Volume is also a virtual disk, but unlike AppStacks a Writable Volume is configured in a one-to-one configuration, and each user has their own assigned Writeable Volume.

DCarter AppVolumes v Writable Volumes 4

 

When an IT administrator assigns a Writable Volume to a user, the first thing the IT administrator will need to decide is what type of data the user will be able to store in the Writable Volumes. There are three choices :

  • User Profile Data Only
  • User Installed Applications Only
  • Both Profile Data and User Installed Applications

It should be noted that App Volumes are not a Profile Management tool, but can be used alongside any currently used User-Environment Management tool.

When designing for Writable Volumes, the storage requirement will be different than it is when designing for AppStacks. Where an AppStack will require all Read I/O, a Writable Volume will require both Read and Write I/O. The IOPS for a Writable Volume will also vary per user depending on the individual user and how they use their data; it will also vary depending on the type of data the IT administrator allows the user to store in their Writable Volume.

IT administrators should monitor their users and how they access their Writable Volume; this will help them manage how many Writable Volumes can be configured on a single storage LUN.

Hopefully this blog helps describe the differences between AppStacks and Writable Volumes, and the differences that should be taken into consideration when designing for each.

I would like to thank Stephane Asselin for his input on this blog.


Dale is a Senior Solutions Architect and member of the CTO Ambassadors. Dale focuses in the End User Compute space, where Dale has become a subject matter expert in a number of the VMware products. Dale has more than 20 years experience working in IT having started his career in Northern England before moving the Spain and finally the USA. Dale currently hold a number of certifications including VCP-DV, VCP-DT, VCAP-DTD and VCAP-DTA.

For updates you can follow Dale on twitter @vDelboy

App Volumes AppStack Creation

Dale CarterBy Dale Carter, Senior Solutions Architect, End-User Computing

VMware App Volumes provide just-in-time application delivery to virtualized desktop environments. With this real-time application delivery system, applications are delivered to virtual desktops through VMDK virtual disks, without modifying the VM or applications themselves. Applications can be scaled out with superior performance, at lower costs, and without compromising end-user experience.

In this blog post I will show you how easy it is to create a VMware App Volumes AppStack and how that AppStack can then be easily deployed to up to hundreds of users

When configuring App Volumes with VMware Horizon View an App Volumes AppStack is a read-only VMDK file that is added to a user’s virtual machine, and then the App Volumes Agent merges the two or more VMDK files so the Microsoft Windows operating system sees the files as just one drive. This way the applications look to the Windows OS as if they are natively installed and not on a separate disk.

To create an App Volumes AppStack follow these simple steps.

  1. Log in to the App Volumes Manager Web interface.
  2. Click Volumes.
    DCarter Volumes
  3. Click Create AppStack.
    DCarter AppStack
  4. Give the AppStack a name. Choose the storage location and give it a description (optional). Then click Create.
    DCarter Create AppStack
  5. Choose to either Perform in the background or Wait for completion and click Create.
    DCarter Create
  6. vCenter will now create a new VMDK for the AppStack to use.
  7. Once vCenter finishes creating the VMDK the AppStack will show up as Un-provisioned. Click the + sign.
    DCarter
  8. Click Provision
    .
    DCarter Provision
  9. Search for the desktop that will be used to install the software. Select the Desktop and click Provision.
    DCarter Provision AppStack
  10. Click Start Provisioning.
    DCarter Start Provisioning
  11.  vCenter will now attach the VMDK to the desktop.
  12. Open the desktop that will be used for provisioning the new software. You will see the following message: DO NOT click OK. You will click OK after the install of the software.
    DCarter Provisioning Mode
  13. Install the software on the desktop. This can be just one application or a number of applications. If reboots are required between installs that is OK. App Volumes will remember where you are after the install.
  14. Once all of the software has been installed click OK.
    DCarter Install
  15. Click Yes to confirm and reboot.
    DCarter Reboot
  16. Click OK.
    DCarter 2
  17. The desktop will now reboot. After the reboot you must log back in to the desktop.
  18. After you log in you must click OK. This will reconfigure the VMDK on the desktop.
    DCarter Provisioning Successful
  19. You can now connect to the App Volumes Manager Web interface and see that the AppStack is ready to be assigned.
    DCarter App Volumes Manager

Once you have created the AppStack you can assign the AppStack to an Active Directory object. This could be a user, computer or user group.

To assign an AppStack to a user, computer or user group, follow these simple steps.

  1. Log in to the App Volumes Manager Web interface.
  2. Click Volumes.
    DCarter Volumes Dashboard
  3. Click the + sign by the AppStack you want to assign.
  4. Click Assign.
    DCarter Assign
  5. Search for the Active Director object. Select the user, computer, OU or user group to assign the AppStack to. Click Assign.
    DCarter Assign Dashboard
  6. Choose either to assign the AppStack at the next login or immediately, and click Assign.
    DCarter Active Director
  7. The users will now have the AppStack assigned to them and will be able to launch the applications as they would any normal application.
    DCarter AppStack Assign

By following these simple steps you will be able to quickly create an AppStack and simply deploy that AppStack to your users.


Dale is a Senior Solutions Architect and member of the CTO Ambassadors. Dale focuses in the End User Compute space, where Dale has become a subject matter expert in a number of the VMware products. Dale has more than 20 years experience working in IT having started his career in Northern England before moving the Spain and finally the USA. Dale currently hold a number of certifications including VCP-DV, VCP-DT, VCAP-DTD and VCAP-DTA.

For updates you can follow Dale on twitter @vDelboy