Posted: 1/26/2012

Persistent-versus-Non-persitent-VDI

If you are just starting to get into VDI I think this blog is important for you to read and understand. If you are experienced with VDI I would love to get youor feedback on this topic. Often when I talk to prospective customers this is where I need to start because, quite frankly, if you are only getting information from the major VDI vendors about what architecture you should use to meet your requirements, you are probably being steered in one direction without enough emphasis addressing your actual requriements . Often early discussions are solely on what broker or storage you will use but there are more fundamental questions than that for what basic architectures you must be able to support. I wanted to write this blog as a primer for this discussion and I am hoping to spread awareness of the differences between the persistenent and non-persistent VDI models so that organizations looking at VDI or ones that have issues with their current implementation will understand the alternatives and be able to architect the right solution for their organization.

One of the most important architectural considerations you will need to make in VDI is whether to use a persistent, non-persistent or mixed model for your desktops. If using a persistent model, a user will be assigned a desktop and they will always use that desktop. The work they do on "their" desktop is saved on "their" desktop. This approach pretty much matches the physical desktop world. A non-persistent desktop is more like a typing pool. The user connects to the connection broker and they select a "pool" of desktops. They are then allocated one of the desktops from the pool which they use during that session. If they log off, when they return they get a different desktop from the pool.

Each of these architectures have benefits and drawbacks depending on the requirements of a particular use case. It is likely that you will want to use both architectures in your environment unless you are only implementing for one or two use cases.

Non-Persistent Approach

The non-persistent desktop architecture is marketed heavily by VMware and Citrix. VMware has their linked clone technology with View Composer and Citrix uses Provisioning Services with XenDesktop. This model is excellent for minimizing the storage usage and manageability of the operating system. The technologies are slightly different which I will explain here.

VMware View Composer

In the VMware model you create a gold image called a Parent virtual machine, take a snapshot of that VM, then deploy desktops from the snapshot. Composer then creates a replica from the snapshot (a thin provisioned version of the Parent VM) on each datastore that you spread the desktops across. You are able to have a single replica or multiple replicas but most designs will use multiple to spread out the IO, and reduce risk by having more redundancy. Then the desktop is created as a linked clone which is implemented with a delta disk "linked" to the replica disk. The delta disk is where all the change that happens to the desktop are stored. This architecture is illustrated in the following diagrams. Note, View has several required and optional disks. A disposable disk can be used to store the page file and temporary windows files. If used this data is removed after every reboot. View uses the Internal disk to hold the Windows Active Directory machine password. This ensures that the desktop does not lose its domain trust when the desktop is recomposed (the OS update process).

Commposer Datastore

There is also an optional "persistent disk". The persistent disk is assigned a drive letter at the pool level which is normally the D: drive. Files stored on the persistent disk are not removed during a recompose or refresh operation. You can also redirect the windows profiles automatically to the persistent disk.

If we actually look at these files we will see that they are all pretty small. The next two illustrations show the view of the files from vCenter and the datastore. File A is the delta disk of the linked clone where changes are stored. Remember the underlying OS disk is a read only copy so this is similar to a snapshot. It will grow substantially over time and if a Recompose is performed this disk is cleared. The B file is the disposable disk for the page and temp files. This file is cleared every reboot. The C file is the user data disk or "persistent disk". This file is thin provisioned and grows over time. As an aside isnt it funny VMware marketing changed the name to the User Data Disk to the Persistent Disk but in the technology it never changes. The last file D is the internal disk which is very small and does not grow.

Composer Files

If you look at the same files on the actual vmfs volume you see that the vcenter client combines some files together to simplify the view.
Composer Files Alt View

So we got pretty deep here in the file structure but it is a good way to illustrate what you can do with View Composer. You see that to start with (BTW this is a brand new desktop) the linked clone uses very little storage above the size of the replica which is not even shown here. The many caching type files which include the disposable disk, the delta disk and the persistent disk will all grow over time and the growth can be substantial. When you recompose or refresh the desktop the delta disk and disposable disk are both cleared and lose whatever changes they contained.

Often when I talk to prospective customers they think having the persistent disk means that they have a persistent desktop but this is certainly not the case because files are definitely lost from the "C:" drive on a recompose action. The profile and files placed on the D: drive persist but this is not everything as I will discuss later. Also, remember that on a persistent desktop you and many software developers expect the computer name, MAC address, volume serial number, and disk signature to not change and if they do strange things can happen with applications.

Still View composer is a very elegant solution to managing a shared non-persistent infrastructure implemented in a simple and straightforward manner that works reliably.

Citrix Provisioning Services

Citrix also has a method to create space efficient desktops where the OS image can be managed centrally. Their solution is called Citrix Provisioning Services (PVS) which is Citrix PVS

technology they acquired when they purchased Ardence at the end of 2006. When this technology was originally developed we used it to manage images for Citrix MetaFrame servers. It was a fantastic way to ease image management for large Citrix farms. The technology is fairly similar to View Composer's linked clones but it is implemented in a way that does not requirie SAN storage and it can be used for virtual or physical desktops.

Like View Composer PVS uses a cache file to capture the changes to the underlying OS when running in "Standard" mode. There is also a "Private" mode which allows you to save changes to a vDisk in the disk itself. This is normally used to update or change a vDisk. Generally the way you work with PVS is that you use two vDisk images for a build. One is in standard mode streaming to the desktops and you use the other to update for a new revision. You then have to either keep the two in sync or make clones each time you want to do an update. Once you update the image you swap. Frankly for VDI I think this is a bit tedious compared to other solutions but the ability to use either local storage or SAN storage is great for us architects. You can even use local storage in a PVS Farm but you have to keep the local images in sync or you will have problems.

What about Apps?

For the non-persistent desktop alternatives apps are generally deployed in one of two ways. Either they are streaming to the desktop or they are included in the base image. For streaming, organizations generally use App-V or ThinApp. Of course XenApp can always be used as well to provide applications to physical and VDI desktops. Citrix does have their own application streaming product and there are several others on the market but ThinApp and App-V are certainly used the most. Both of these are very good products. Back in the day at RapidApp we worked with SoftGrid (now App-V) on most Citrix MetaFrame implementations because it was the best way to manage applications for a large server farm. With App-V you have streaming servers that stream virtualized applications to desktops. The desktop has a client with a large cache. You can either load the whole application at run time or pre-cache the application out to the desktops. App-V has a concept of "sequencing" an application where it figures out the files that are needed first when you run the application and it streams those down to the desktop first when the application is launched speeding up launch times significantly. ThinApp works slightly differently in that they encapsulate the streaming file into an executable that can be either run from a file server or copied locally to the desktop and run. One last thing that's very cool about these products is that they isolate the applications from each other by default which allows you to run conflicting applications side by side. One drawback to that is that if you want applications to integrate with each other you have to know that in advance and define it in the build. Another benefit of app streaming is that it provides dynamic assignment of application to users as they log on. This allows the desktops to be generic with customization on logon.

On the negative side, app streaming technologies have trouble with applications that include kernel mode drivers, printer drivers or early start services because they are themselves services and they have to wait for Windows to load, so they can be loaded and stream down the application. Note this is not a drawback of XenApp unless of course you want to manage XenApp with application streaming. What this negative means to you as an architect is that there are about 15-25% of applications you will have to build into your base image because you won't be able to virtualize them. Then, because not all applications will be used by all desktops you will have to build different images for different groups that require different applications. What I normally see is about 1 image for every 100 desktops in an environment. This could certainly be more or less depending on your requirements. Of course the problme with this is now you have manage and patch many images that have lots of overlap in the applications they have installed.

Good Use Cases

So now we have reviewed the non-persistent model. If I were to characterize the main benefits and drawbacks to the model I would define the following:

Benefits

Very High Availability - If a host or storage fails, users can simply logon to another desktop. There are still parts of the environment that if they fail, can cause an outage, but it will be rare.
Good Manageability - Management of the OS is good. Modification to central images are deployed to many desktops. If applications are the same for all, app manageability is also excellent. If apps must be different, manageability depends on the ability to virtualize the applications.
Minimal Storage Footprint - Both Composer and PVS provide greatly reduced storage requirements. PVS can even be used with local storage on the PVS servers.
Fast Deployment of Simple Apps - Using app streaming applications can be deployed very quickly to all of the desktops in the environment. However for apps that are not simple this becomes harder and may require creating and deploying new OS images.
Very Fast Deployment of New Desktops - in this model desktops can be deployed very quickly as the OS is already created.
Simple Desktop Refresh - to get a desktop back to the standard state you just reboot it. The desktop is then reset back to its original state. This is great for student labs, many classroom use cases, kiosks, and training facilities.

Drawbacks

Application Incompatibility - there will be some percentage of applications that cannot be delivered with app streaming and a smaller percentage that will not work at all with the non-persistent model due to the way they are installed or the way they implement licensing checks.
No User Installed Apps - If you need the flexibility of users installing applications you cannot provide that with the non-persistent model.
Image Sprawl - For environments with different types of users with different application requirements you will have to build several to many images to provide applications to the end users. The more images you need the more work it takes to patch and update the images.
Issues with User Confidence - in this architecture I often here about instances where users have saved files to their C: drive which are lost on a recompose. You can consider this a training issue but it does point out that non-persistent desktops may not meet the needs of our users.

So given the benefits and drawbacks where does it make sense to utilize this model. I think the most successful implementation of the non-persistent model is for environments that require the utmost in availability that are also fairly simple in their application needs. The classic use case is the large call center. What if I have 600 - 1000 desktops that all have the same set of applications and must be available 18 to 24 hours a day. This model is perfect for that. What about the manufacturing floor or warehouse. Possibly for retail outlets or small branch offices. Certainly classrooms, training rooms, and student labs. The real key I think is that the application are either the same for everyone or they can be delivered using application streaming. To reiterate the good use cases in a bullet list:

Call Center
Classroom, Student Lab, Training Room
Library
Task Worker
Kiosks

Note: I want to remind everyone that I do work for Unidesk but I try very hard to be impartial here. I was an independent consultant for 15 years and I am not really able to change my colors from that experieince. I believe in telling the truth as a vendor because if I lie you will find out anyway and we will both be worse off for it. Anyway, I do want to point out that Unidesk also provisions non-persistent desktops. I will show how Unidesk works in the persistent model discussion which is our bread and butter but remember that you can use us for both.

Persistent Approach

Now we move on to the persistent desktop model. The key to this model is that it should be the same as a physical desktop based on what administrators can provide to users. So the ability to make users administrators if required. The ability to install applications, printers, toolbars, utilities, whatever.

The most common way to provide a persistent virtual desktop is to provide a full clone virtual machine. All virtual desktop brokers provide the ability to create full clone virtual machines in an automated way. However, once the machine is created it stands on its own. The question then becomes how do I manage that desktop. You could of course use the same technologies you use on physical machines. For example to manage applications and Operating Systems patching deploy SCCM, Kace, Landesk, Altirs, etc.

But what about storage? Here certainly if you deploy 1000 desktops of Windows 7 and they each have 25 GB of storage you will be using 25 TB of storage. Even if this is thin provisioned storage you will likely be upwards of 15 TB of storage. Remember also, this needs to be high performance storage not SATA storage. One option organizations use to lessen this requirement is deduplication. This can be a good solution but be careful there are risks to post processing deduplication if you get low on available storage or overcommit too much and nothing is worse in VDI than running out of storage.

Citrix Personal vDisk

Last year Citrix bought RingCube to obtain their vDisk technology which allows you to build persistent desktops and still use PVS. This technology is close to its first release from Citrix as part of XenDesktop. What the Personal vDisk does is create one persistent layer on top of the PVS image for each desktop. In this layer you can allow users to install application but you could also use SCCM to install applications here. Users can use local profiles and install applications and those will be persistent with this technology. That said for most folks using this architecture will also require multiple base OS images to deploy different sets of centrally managed departmental applications.

Unidesk

I think you will find that Unidesk is a fairly unique product. Unidesk is not only a persistent desktop model provider but it allows the flexibility of providing both persistent and non-persistent desktops using the same OS layers and Application layers. I think the key to the Unidesk product is flexibility. You will be able to create a centrally managed virtual desktop solution that allows you to decide what users are able to do and whether you want to deploy an application centrally, managed by IT or installed by the user.

The Unidesk architecture is built around the concept of layers. First you provision an OS layer by creating a gold image VM and importing that VM into Unidesk. During the import all the files are copied from the VM to the Unidesk Master CachePoint. The Master CachePoint acts as the library for all OS layers and Application layers. After you have built your OS layer you use it to build application layers. An application layer is built by creating (an automated process) an Installation Machine, logging into the machine and installing the application. Once you have your layers created you can create desktops from these building blocks. Unidesk desktops are created with a small boot disk which is used to capture all of the boot files for Windows. This includes drivers, and early start service files as well as the pagefile. Anything required prior to loading the Unidesk Windows drivers. Unidesk desktops boot from the boot drive then when all the Unidesk drivers are loaded the rest of the OS is loaded from the CachePoint. The majority of the Windows OS and all the applications reside on the shared storage provided by the CachePoint. CachePoints mount storage on vSphere datastores.

Unidesk Architecture

Typically there is one CachePoint deployed per vSphere host and all of the desktop deployed on that host are deployed to that CachePoint. The CachePoint will only host an OS or Application layer if one of its desktops is using that layer. The Master CachePoint is responsible for distributing the layers to the downstream CachePoints as necessary when a desktop is configured with the layer.

Most of the layers are shared amongst desktops. This sharing of layers provides native dedupe for application files because the layers are stored on the CachePoint just once for all the desktops that use that CachePoint. This also helps to keep the most used layer and OS blocks HOT on hybrid storage which decreases IO latency.

One layer is not shared on the CachePoints and that is the Desktop Personalization Layer. This layer is where all the changes happen for a Unidesk Desktop. Any file or registry setting saved or changed by a user is stored here. If the file initially is stored within an App layer or the OS but is written to by the desktop, then that file is first copied to the Personalization Layer then written to. Then on the desktop the Unidesk file system filter driver always looks in the Personalization Layer first to find files and therefore it will always find the edited version of a file stored there first.

The key to this architecture for persistent desktops is that the Personalization layer is never cleared. You can update any layer underneath this layer but any files or registry settings added to the personalization layer remain after these updates are applied. This allows for user installed applications, as well as the use of local profiles. The idea here is that you get a desktop, it's always yours, if allowed you can install applications, printers, network shares, whatever on your desktop and those changes will persist including updates to the centrally deployed OS's and Applications. But the system can deploy most applications whether or not they have kernel drivers, printer drivers or services associated with them. The key here is flexibility with manageability.

Unidesk Non-Persistent

Earlier I mentioned that Unidesk can also provide non-persistent desktops. This is done by taking a snapshot of the desktop after Microsoft mini-setup runs and on logoff or a reboot bringing the machine back to that snapshot. In many ways the desktop behaves like a persistent desktop, its name never changes, its MAC and volume serial number also remain the same so for licensing it looks more like a persistent desktop with benefits.

Persistent as Non-Persistent

One last thing we should review in the persistent versus non-persistent discussions that there will be application requirements you may have that will force you to use persistent desktops even for use cases where non-persistent would be best. A good example of this is an application that licenses in a way that requires the license to be installed on the desktop. This would include licensing to a computer name, MAC address, or volume serial number on the boot disk. When you must provide these types of applications but prefer not to save changes on the desktops you can use mandatory roaming profiles with a locked down desktop which will clear profile changes on exit or Unidesk non-persistent desktops which are mostly persistent except we toss the changes to the desktop on logout or reboot.

Good Use Cases

What are the good use cases for the persistent model. Again, first it is good to describe the main benefits and drawbacks of this model:

Benefits

Manageability - This depends a lot on the chosen provisioning platform. If you use full clones you need other tools for OS and application management. If you use Unidesk, management of the OS and Applications is excellent.
Availability is good but not as good as the NP model. Compared to physical desktops it is much easier to keep users working using virtual desktops which support VMware HA, and snapshots. If you use Unidesk you get automated backups, and automated snapshots with repair. Some way to backup and recover persistent desktops is a requirement because unlike the NP model they do have important files and applications installed on the desktop.
Deployment of any Application - one of the big advantages of the persistent model is that it supports installation of any application because persistent desktops work like physical desktops. Also, it's up to you whether you allow user installed apps or not just like physical desktops.
Fast Desktop Deployment - as with all virtual desktops its very easy and quick to create a desktop. Normally less than 15 minutes.
Application Compatibility - this is where the persistent model shines. Many applications expect a persistent model. Also, you will not have driver or service issues with a persistent desktop.
User Installed Apps - If you need the flexibility of users installing applications this model provides that in all its versions.

Drawbacks

Availability while good, is not as good as the NP model because users do have a particular desktop and something can happen to that desktop. The "something happening" risk can be lowered with a product like Unidesk which takes periodic snapshots and offers repair or by backing up the desktops or taking a snapshot prior to a big change. The snapshot approach is not scalable though.
High Storage Usage - If you don't implement a complimentary technology like storage deduplication or Unidesk you will need a significant storage footprint for persistent desktops and don't forget they need to be backed up as well which can also increase secondary the storage you use for backups.

Now that we have outlined the benefits of the persistent model what are the good use cases. Here the reality is that, due the flexibility these desktop give you and the fact that they universally support what you want to do on the desktop, persistent desktops are good for most use cases except those that require extremely high availability or those where you do not ever want files saved from one logon to the next. If I were to make a list I would probably point out:

Developers
Office staff /knowledge workers
Professional workers like lawyers and writers
Healthcare workers
Engineers and Architects (as long as there is no 3D modeling requirement)
Student Virtual Desktop

One I find particularly interesting is the Student Virtual Desktop. In this design a student is provided a virtual desktop of their own when they start school. They are then provided applications they need for the classes they are taking that semester. They can access the desktop from their own computer, tablet or any station around campus. This seems to me like a great way to show students that IT is innovating to make their lives easier.

Putting It All Together

So this is a blog I am supposed to espouse a position and here it is. Unless you are using VDI for a single use case you will require the flexibility of providing both persistent and non-persistent desktops in your environment. You will have requirements that are best met with both models so you need to plan for how you will provide both types of virtual desktops.

I know of companies that have been very successful using one of the major brokers from VMware, Citrix, Leostream or Quest along with desktop management applications like SCCM to manage their persistent desktops. The organizations that have been successful already use these tools for large numbers of physical desktops so they are just extending that model to their virtual implementation. However, they have a significant number of IT resources trained to work with these tools and normally a whole department dedicated to them. If you do this with more than say 100 desktops consider deduplication for your storage otherwise it becomes prohibitively expensive even if the desktops are thin provisioned.

Lastly consider an approach based on VDI products made from the ground up for virtual desktops. Citrix or Unidesk can help you provide an environment that allows management of persistent and non-persistent desktops using the same technology. Citrix XenDesktop with the Personal vDisk and Unidesk with its Composite Virtualization and CacheCloud environment. I am partial to Unidesk but I work there. I think it betters Citrix for ease of use, recoverability, application management, storage reduction, and OS image management. That said, you should look at both products and decide which woud be better for your organization.