Video Screencast Help

Reduce SWV fslrdr Directory Size - Disk Full

Created: 11 Jul 2012 | 5 comments

I am virtualizing upwards of 30 applications. Usually, these apps will take 4-8GB or more of space on their own, but with layers that seems to double. Is there any specific ideas or steps that I can take to reduce the amount of space taken up by the ReadOnly sublayer. I am filling up disk space faster than I'd like for these applications, but certainly want to keep them in layers to alleviate administrative headaches.

Thanks in advance for your help!!!

Comments 5 CommentsJump to latest comment

InkByte's picture

More info: 

Most of these are apps are high-end 64-bit CAD apps: SolidWorks, ProE, Catia and this is an educational environment, specificially Engineering and Technology/Mechanical Engineering.

We are running on HP Blade Workstations and have only 170GB of hard drive space.

Thanks again...

EdT's picture

Is there any chance that the original source of the apps is somehow being captured into the ReadOnly sublayer? The ReadOnly sublayer should be no bigger than the install folders under Program Files on an installation into the base. Although the RO sublayer lives in the fslrdr folder, it is "mapped" into the Program Files address space when the layer is activated - no second copy is generated.

Could you take us through the process you follow when creating the layers?

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

InkByte's picture

These are the steps that my employee takes to currently create layers. We have used the Wise Virtual Composer in the past, but not recently. 

1. Open SWM Admin Tool

2. File -> New Layer -> Install application -> next -> (name layer) -> next

3. Single program capture -> c:\windows\system32\cmd.exe -> next -> Finish

4. cmd.exe opens and program is installed through the command prompt.  (most installations are run from a network source)

5. After installation completes run the installed program and make necessary changes to UI, default settings, etc.

6. Run xcopy through cmd to change the program's shortcut locations.  

7. Exit cmd.exe

8. Export the .xpf to a network location.

9. Done

We are also concerned that maybe dependencies of MS Visual Studio portions, or .NET peices might also be bloating the layer. Some of the apps have been created on a workstation where those dependencies exist, and other apps have been done in a cleanly installed virtual machine. We are actually running some tests of creating a layer of a sepcific CAD application, one on a workstation as described, the other on a virtual as described, to see what differences we might see.

Keep in mind that we are doing all of these apps as 64-bit apps on Win7x64. That is the specific reason we are migrating from ThinApp to Symantec Layers due to that 64-bit support!

Are there specific steps that are recommended for minimizing the size of the layer? We are not overly concerned with speed as these are such large apps, they take a while to load anyway and a few more seconds isn't of consequence.

Thanks again for your assistance

EdT's picture

The main problem you are likely to be experiencing is due to the use of an inconsistent development platform.

With complicated application installs that have many dependencies, you should always endeavour to include things like .NET frameworks, Visual Studio runtimes, Office PIAs, etc.

A while back, I wrote an article ( that listed the standard components I would add to a base build when deploying a new operating system, to simplify the process of packaging applications, whether physically or as virtual layers. 

If you do not do this already, then your test machine base operating system should be pre-installed with EVERY dependency of your application, other than the explicit component that you want to put in the layer - unless that dependency is 100% unique to that application. If you do not do this, you end up with extra crap in your layers that is not needed. So your development workstation basically needs to be an exact configuration match for your production machines, and your production machines must be kept at a consistent build level.

Without this discipline you are just storing up problems for the future and also increasing your support costs substantially.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

erikw's picture

Many application executables that we try to capture first unpack and a lot of MSi's are in the base layer. You might search in your layer for these MSI files as they are not necessary and take all your space.

Regards Erik Dinamiqs is the home of VirtualStorm (

If your issue has been solved, Please mark it as solved