<img src="//bat.bing.com/action/0?ti=5794969&amp;Ver=2" height="0" width="0" style="display:none; visibility: hidden;">

VDI: A look at Persistent vs. Non-persistent Desktops

[fa icon="long-arrow-left"] Back to all posts

[fa icon="pencil'] Posted by Lewan Solutions [fa icon="calendar"] January 21, 2016

As we enter a new year, let’s talk about the past challenges of desktop virtualization and what the future holds, specifically persistent VDI vs. non-persistent images.

lewan-vdi-desktop-virtualization-solutions.jpg

Side 1: The Argument for Persistent VDI

One camp argues that we know how to manage desktop PC's and that the simplest and most effective approach is to do with virtual desktops what we've already done with physical PCs. The argument being that we already know how to do this; already have the tools needed to do this; and already have the skill, knowledge, and expectations set with the user community about what the experience is going to be like. Essentially “if it’s not broken, don’t fix it.”

Side 2: The Argument for Non-Persistent Images

The other camp argues that we can make things better (and hey, traditional desktop management is broken) by leveraging the virtualization infrastructure. We have the ability to clone, update and image machines like never before.

When did your PC run best? When it was brand new right? Well with non-persistent it can be brand new every time. No more pushing out a patch with WSUS and only having 95% of the desktops actually apply it - imaging techniques can guarantee 100% get updated. No more users down because "his PC is broken"...because everybody's PC is everybody else's.

And scale is a non-issue because we can manage 1000 PC's as if they were just 1 all courtesy of image-based management. All you have to do it get to a non-persistent desktop solution.

Ok, so both camps have their points.

Traditional desktop management can work, but you really have to work at it. You have to put in the time and tools to really do it right.

Image-based management can work well if you have a largely homogenous user population who doesn't have admin rights and who aren't prone to installing software on their own desktops.

If every user is building their own PC and configuring it today, then putting them into an image-based solution is going to be painful. That's reality, but does play well to traditional management techniques. If traditional management is failing you in the physical world then it's not going to solve your issues in the virtual one.

The Holy Grail and Image Sprawl

The "Holy Grail" of the image-based management world is the idea of a single gold image for all of your users. Update one and done. The challenge here is that this goal pretty much precludes any per-user or per-department customization of the desktop image. It means no custom apps and certainly no user installed applications. This concept might work well for a training lab or a call center but really doesn't describe many traditional desktop environments.

The end result of this is that we typically end up creating an image for each department. Classifying users and determining how many users will be using each image and subsequently provisioning pools of virtual desktops based around each image. As users change roles we then need to manage the desktop pool(s) they are assigned to, to ensure that they have what they need. This concept is what we refer to as "Image Sprawl."

In some environments this sprawl may result in 2-3 images instead of the goal of 1. In others it can result in 10's or even more distinct image builds which each need to be maintained, tested, and deployed. Certainly this is fewer than you've have with traditional methods (where every machine is unique), but we also typically don't have the automation tools in place for these environments to assist with scaling. The end result being that we can quickly lose the management benefits of single image management.

So that's the story of the past. The challenges we've faced and the difficulty going forward.

What's the solution?

Today we have the concept of Application Layering. The basic concept is that we start with a “vanilla” layer that represents the operating system itself and possibly a basic suite of apps that are common to all of your users. This base layer will be maintained as a single unit and will be common to the entirety of your user population. Additional layers are built by installing one or more applications into a separate container (usually a .vhd or .vmdk) which can be logically merged with the base and other layers. Subsequently you maintain the contents of each layer independently of the other layers.

An Example

We have a customer who has standardized on Windows 7 and Office 2010. Their accounting department needs QuickBooks and Dynamics; marketing needs Publisher, Photoshop and Dreamweaver; and engineering needs AutoCAD and SolidWorks. Of course the IT admins have their own needs for management apps.

A traditional image model would dictate at least 4 distinct images. With layering it could be as simple as:

  • Base Layer - Windows 7 + Office 2010
  • Accounting Layer - QuickBooks and Dynamics
  • Marketing Layer - Publisher, Photoshop, and Dreamweaver
  • Engineering Layer - AutoCAD and SolidWorks
  • IT Admin Layer - VI Client, PowerShell, etc.

Of course that's not very different than having 4 separate images but does mean you can update only the one item that contains updates. For instance, patch the base layer monthly and maybe update the department layers quarterly or semi-annually, as the apps require changes.

The challenge comes if you have someone in IT Admin who needs access to AutoCAD. Do you assign them to both desktop pools? You certainly could. But you could also structure your layers like this:

  • Base Layer - Windows 7
  • Office 2010
  • QuickBooks
  • Dynamics
  • Publisher
  • Photoshop
  • Dreamweaver
  • AutoCAD
  • SolidWorks
  • VI Client
  • PowerShell
  • Etc.

Now you have the flexibility to assign each application separately and update each one independently of all of the rest. If engineering decides to switch from AutoCAD to Microstation you don't have to mess with uninstalls just unassign the layer.

Static and Dynamic Assignments

Depending on the layering technology the layer assignments can be static, dynamic and machine (VM) or user (ID) based. With static assignments you build your desktop pools based on what goes into each pool and then assign the users to the pools. With dynamic assignments a user logs into a machine and the layers assigned to that user are attached at/during logon. 

Static assignments work well for VDI and for RDS environments (Yes, you can use this with Citrix XenApp!). Static assignments have some advantages in performance since the layers are already attached before the users connect and can have greater compatibility by ensuring the layers are present earlier in the boot process to support drivers and services. The downside is that everything must be pre-determined and cannot change while a session is active.

Dynamic assignments are pretty much only for VDI environments since adding/removing layers on a server while other users are working could be pretty disruptive. However you can add (and potentially remove) layers based upon who the user is and what they need right now. Some products even allow you to add layers while a session is in progress without requiring the user to logoff. With nothing pre-determined you could have a single large desktop pool and assign all the apps dynamically based upon who logs onto any given VM.

Layering also supports the concept of a "user layer" - this is a container dedicated to a single user where anything they modify (or install) is saved. Some products will allow you to replace profile management with the user layer where others will only augment existing profile management solutions. This gives users the ability to install their own apps if the system is configured to support it. This works particularly well with dynamic layering assignments since the user still logs into a pooled desktop but gets all of their custom apps. With static assignments a user must be returned to their specific VM (which has their layer) each time.

So that's the concept. One image, the “Holy Grail,” and layers for everything that's not in the image. The future looks brighter don't you think?

What products can do this?

Lewan Technology works with VMware AppVolumes, Liquidware ProfileUnity and Unidesk. We leverage these products because they support Citrix XenDesktop, Citrix XenApp and VMWare Horizon View. They support both RDS and VDI delivery models. We offer more than one because each product has its advantages and disadvantages and we want to make sure that our customers get what's best for unique user environment.

Contact Us  to arrange a demonstration and a consultation to determine which virtualization solution is best for your organization.

Topics: Virtualization, VMware, Citrix XenApp, Citrix XenDesktop, Unidesk

Lewan Solutions
Written by Lewan Solutions

  • View & Submit Comments

[fa icon="envelope"] Subscribe to Email Updates



[fa icon="comments-o"] Follow us

Get even more great content, photos, event info and industry news.



[fa icon="calendar"] Recent Posts