Twins – Exploring the new “Clone Layer” Feature of Symantec Workspace Virtualization 6.1

The recent release of "Symantec Workspace Virtualization" 6.1 (formerly known as SVS or Software Virtualization Solution) introduces a new feature that allows you to clone an existing layer. Unlike the 1988 movie classic "Twins" where Arnold Schwarzenegger and Danny DeVito play a pair of very unlikely (not to mention very dissimilar ) twins, a cloned layer is identical to the original from which it is derived, with the exception of its layer ID, which must be different in order for the two layers to coexist. What is the purpose of adding such a feature and how can it make your life as an administrator or user of SWV better? We'll explore the answer to this question in this article and also look at some tips on how to use this new feature. I think you might be surprised by the usefulness of layer cloning. In fact, you may come up with some additional uses we haven't even thought about! Well, let's get started.

Evaluating an Update

Have you ever wanted to quickly evaluate an update to an application and compare it side by side with the original? Perhaps you'd like to look at multiple, incremental updates to an application and evaluate how each behaves before you roll it out to a larger audience. The "Clone" layer feature make this very easy to do. Suppose you have Adobe Reader 9.0.0 installed and you get one of those notifications from the Adobe Updater in the system tray telling you there is a new update to Adobe Reader (9.1.0) that resolves some security vulnerabilities and improves stability. You'd like to try it out but not affect the 9.0.0 version of the layer. You right-click the existing layer (Adobe Reader 9.0.0) and select "Clone...".

You will be presented with a dialog box that allows you to give the layer a unique name. Because we'll be using this layer to evaluate an update to version 9.1.0 let's name it "Adobe Reader 9.1.0". We are also presented with a checkbox which gives us the option to "Copy writeable sublayer from existing layer". If checked, the Read/Write layer will also be copied to the cloned layer. This may be desirable if you've customized a layer by adding your own settings, customizations, etc, to an application and you'd like to see how they fare after updating an application to a new version.

After giving our "Clone" a new name, SWV Admin will chug away at cloning the layer for a few moments and viola!, our new clone named "Adobe Reader 9.1.0" appears. Now you can select the cloned layer, activate it and tell it to go check for updates. After a few moments it will begin downloading the update and installing it.

I quick check of "Help-> About Adobe Reader..." reveals that it has indeed been updated to version 9.1.0.

Now we have two layers, the original layer Adobe Reader 9.0.0 and Adobe Reader 9.1.0. With both layers side by side you can quickly test the update and compare it to the original to ensure it is ready for deployment to the enterprise. At this point you might be asking yourself: What will happen if both Adobe Reader Layers are active at the same time? The answer is that the last layer to be activated "wins".

Cloning for Patch

Cloning a layer is an important feature for layer patching. The ability to create and deploy layer patches is also new to SWV 6.1 and will be covered in an upcoming article, however, let's take a closer look at the role layer cloning plays in this process.

Suppose you've tested Adobe Reader 9.1.0 and now you'd like to update all of your users to this new version. In the pre-SWV 6.1 days, you'd capture a new layer and apply the update, then export the layer to a .VSA file. This .VSA file is then deployed and imported on all the client nodes. For a small, incremental update from Adobe Reader 9.0.0 to 9.1.0 this requires that a .VSA file approximately 185 MB in size be deployed to all client nodes. The ideal way to deploy this change would be to create a binary difference between the 9.0.0 and 9.1.0 and only deploy the software components that have changed between the two versions. The size of a binary difference (or patch file) is 60 MB in size, significantly smaller than deploying a layer 185 MB in size just to update to a small, incremental update of a layer!

Layer Cloning makes creating a patch quite simple. As I've already demonstrated, it is very easy to create a clone of the original layer (9.0.0) and then apply updates to the clone to create a new, updated layer (9.1.0). Layer cloning is therefore the first step in creating a patch. Stay tuned for the upcoming article on Layer Patching which will describe the feature in detail and describe the best practices for layer patching.

Cloning for Dependent Layers

Dependent layers, also a new feature to SWV 6.1, provides a mechanism for layers to increase efficiency and reduce redundancy by sharing a layer. For example, suppose you have two layers A & B that require a specific version of Java 1.4.2 which we'll call layer C. Rather than requiring layers A and B to both include Java 1.4.2 it would be much more efficient, and less redundant, to set layer C as a dependent layer of both A & B. Now that we have a quick introduction to the value of dependent layers, let's look at the role layer cloning might play in evaluating updated versions of a dependent layer.

Suppose that an incremental update to Java from 1.4.2 to say 1.4.6 becomes available and you'd like to evaluate how applications A & B behave with the updated version. The process outlined in the section "Evaluating an Update" can be used to update Java from 1.4.2 to 1.4.6 in a new, cloned layer which we'll call layer D. The cloned layer (D) can then be set as the dependent layer of A and B to determine if the layers continue to function as expected. If completely separate environments are desired, layers A and B could also be cloned and tested with layer D (Java 1.4.6) to ensure proper function of the application. The combination of Layer Cloning and Dependent layers provides a quick way to evaluate changes to dependent layers without disrupting the existing layers in the process.

Summary

Clone Layer, a new feature of Symantec Workspace Virtualization 6.1, makes an exact copy of an existing layer, with the option of also preserving the Read/Write layer. The only difference is the layer ID (GUID) which makes it possible for two identical layers to co-exist on the same system. This characteristic enables the use of Layer Cloning to evaluate software updates without impinging on the original layer, to create an updated layer for the purposes of creating a layer patch and to evaluate the behavior of updated dependent layers without causing intrusive changes to existing layers. There are probably many other uses of Layer Cloning yet to be explored. Share your ideas on the comments section of this article.