Protecting Horizon View – Debunking the myth

Quick Summary

This post describes some concepts and methods that could be used to backup a VMware Horizon environment and more so the VMware View components. VMware View is an enterprise solution for managing the lifecycle of virtual desktops, the applications running on those desktops and the user environment like user data and documents.

In times gone by there was a myth that VMware View could not be backed up using traditional methods and I would disagree with that. With everything, there are always going to be limitations and it’s just about understanding those limitations. Every component that can be backed up mentioned in this post can be backed up using the Vembu BDR Suite and needs no special agent or product.

In this post, we focus on older versions of VMware View for backward compatibility but will discuss where components have been deprecated and where newer v7 components need discussion. The assumption is you understand the architecture of VMware View and Horizon.

Components Overview

The components view for View 5, and View 6 pretty much looked like the following diagram:

The components we need to concern ourselves with regarding backup include:

• View Connection Server
• View Security Server
• View Transfer Server
• View Composer
• Persistent Desktops
• Template used for Floating Pool (Full VMs)
• Parent Image for Floating Pool (Linked Clones)
• ThinApp and User Profile Stores

The Myth

So the myth came about because of one specific limitation. The current technique for backing up virtual machines which essentially what virtual desktops are, is to use the VMware snapshot function. It is common practice to use a clone of a master desktop image, and VMware offers a very efficient way of creating something called a linked clone. Instead of cloning the whole desktop image VMware would create a delta disk and which was very quick and referred to the master desktop image for reads. This minimizes storage requirements for VMware View desktops and was very quick. The issue was the VMware snapshot function couldn’t snapshot this linked clone effectively. This one fact lead people into thinking VMware View and virtual desktops couldn’t be backed up… Not true… So let’s see why.

The core concept

The concept here is to tackle clones, data, and management software separately. We’ll discuss each of these in the following sections.

Bring in the clones

• Challenge: Linked Clones cannot be backed up using VM Backup solution
• Misconception: Linked Clones need to be backed up
• Solution: Backup the parent images and user profiles separately

So let’s discuss that in more detail. Linked Clones can be created very quickly so knowing that is it worth trying to back up the Linked Clone when we can refresh a virtual desktop in a matter of minutes. Probably faster than you could restore a whole desktop.

NOTE: so that I don’t miss this. You could argue that if the VM snapshot is not effective with linked clone snapshots then use the storage array snapshot to capture the storage where the linked clones reside. You could, but I don’t think there is a need. If you understand the myth, follow best practice and this document you should never need too.

But what about the contents of the linked clone I hear you say? What about the user data and the applications that were added after the creation of the linked clone. If you refresh the machine, those would be wiped out sure? Well, that is a nice Segway.

User Persona and User Data

Really to take full advantage of virtual desktops you should have designed that all user profiles, user persona, and any data created by the user be centralized somewhere. This is typically stored on a share on a server accessible by the user and the desktop. Why this is good practice is because typically linked clones are seen as floating desktops. A user may not get the same desktop they were on last time and given the configuration may actually receive a fresh desktop every time they logon. Easily done with VMware View and the advantage is that any problems that may have been introduced into the last desktop, like a virus or dodgy software are wiped out automatically as the desktop is automatically destroyed and refreshed… The only way to take advantage of this floating desktop idea is to have user persona/data centralized, so it’s available to the user on any desktop.

So how do you do that? Well, you either use the native VMware UEM solution or my favorite is using Liqduidware Labs Profile Unity to manage the centralisation of User Persona and User Data. Using these tools gives you the freedom control how persona and data are accessed.

But what do you backup? Well using the Vembu BDR solution you should backup

• The file server where the user share is that contains the user persona and data
• The 3rd party tool which is typically installed in a VM

Ya see nothing too complicated there right?

Applications

What about the applications installed on the virtual desktops?

Applications that were installed in the master image are protected when you protect the master image which could be another VM or a VM template. And as long as you have those in your backup schedule then you are covered.

Applications that were installed after the clone was created? Hmmm… you are using the principal of a floating desktop that is non-persistent, meaning it will be destroyed and refreshed from the master every time the user logs on. Then you have a problem there my friend. But I do have a solution and some advice…Firstly stop users from installing their own apps. Secondly, if this is not possible due to the nature of how your users need to use virtual desktops then here is my idea: Install Liquidware Labs FlexApp. This product can capture application installations on the fly and centralize them, so they are available on every subsequent desktop the user logs on to… The key word there is centralised…centralised on a network share again on a file server which means once again Vembu BDR can protect them

What about streamed Apps? So it’s very common today to use an application streaming function to stream apps into a desktop mid-flight and not have to worry about applications installed in the master image. This is done using 3rd party tools like VMware App Volumes or again my favorite Liquidware Labs FlexApp. These tools typically have a repository where the applications to be streamed are stored and centralized. Normally it’s a file share…. You see where I’m going with this now… most of the time the important pieces of the puzzle are easily protected by something like Vembu because they reside in a file share, in a VM that is not complicated to backup and restore at file-level.

Virtualized Apps? Part of the VMware Horizon Suite is a tool called ThinApp that allows you to package up applications into a single file. It means as long as a virtual desktop has access to this single file it can run the application without installing the application. The good news again is these “thinapps” are stored in a file share… bingo we can backup VMs that contain shares easy! And restore at file-level using Vembu.

Persistent Desktops

If your virtual desktop is a full-fat persistent desktop and not created from a linked clone then you have no issues backing this up as a normal VM. However, there is a chance that your persistent desktop was created from a linked clone… it’s persistent because the plan is not to have it floating or destroy it on logout but it’s still derived from a linked clone….having researched this scenario many times it has a very low use case… centralizing apps and data will help though if you still need to protect this kind of desktop. Or worst case it’s back to SAN snapshot.

View Components and artifacts

Now we have discussed how to protect the desktops let’s focus on the management software components.

VMware View Connection Server

• This is the core View component and use to manage most of the VMware View environment
• The main Management User interface is found in this component
• All the configuration data stored in ADAM (Lightweight Active Directory) It makes sense to store data in a directory service like this as most of the view state config is related to users
  ADAM is compatible with VSS which means it can be consistently backed up back Vembu BDR. All you have to do is add the connection server to your backup schedule. Vembu will handle the rest
• Importance = HIGH. Without this component means no new desktops

VMware View Security Server

• Secures desktop connections. This component provides a level of security from the outside world and allows you to access virtual desktops safely
• It’s a subset of connection server and installed in pretty much the same way
• It is also compatible with VSS meaning that Vembu can produce a consistent backup of it
• Importance = MEDIUM, can be rapidly redeployed. I’d still back it up as normal, though

VMware View Transfer Server

VMware View Composer Server

VMware ThinApp Packages

Linked Clone Master Image

User Persona and Data

• User Persona usually Includes Application Settings. The last thing you need is an irate user who has lost their MS Word settings
• User Authored Data, ya know things like my documents, etc
• Perosna Profiles stored in on a file share (store)
• Easy to backup at file-level. This will normally reside in a VM anyway so its easy to backup file share servers
• Importance = HIGH

Conclusion

Hopefully, you got the message and you’ve seen you don’t need any fancy expense backup products with expensive agents. All you need is a good VM backup solution like Vembu BDR. As long as you have a consistent back using VSS you are good to go. Don’t try to back up the linked clones themselves, backup the artifacts that constitute the linked clone. Centralize user persona, data, applications, and make sure you backup the parent images while protecting the core components.