Personal vDisks and Application Conflict Resolution

With the recent release of XenDesktop 5.6, Citrix has introduced the “Personal vDisk” feature into its XenDesktop product line.  See below for links on how Personal vDisks work, but the basic idea behind this technology is that it allows you to create pools of non-persistent desktops and still allow users to install applications on top of these desktops and those applications persist between reboots and base image updates.  This is a significant improvement over “dedicated” virtual desktops, where any updates to the base image would completely wipe out user customization.  This limitation forced administrators to apply updates to each dedicated desktop which would, over time, consume large amounts of storage space.  Needless to say, the Personal vDisk model is a welcome step forward for Citrix.

Now, with this release there was some exciting news about this technology’s ability to resolve application conflicts between user and admin installed apps.  For example, in this video, between the 6min-7:40min mark an interesting scenerio is given where a user installs Firefox 9 but the admin installs Firefox 10 as part of an image update.  The default behavior is that Firefox 9 will be “hidden” and Firefox 10 will be the application available to end users.  Another scenerio is given where both the user and admin have installed the exact same application, we are told that in this scenerio the user installed app is removed from their Personal vDisk to save space and only the admin installed app is utilized.  In the Personal vDisk FAQ, we’re also told that “Should an end-user change conflict with an administrator’s change, personal vDisk provides a simple and automatic way to reconcile the changes”.  With these things in mind, I set out to test this feature myself and see how this actually works.  As you might have guessed, things aren’t quite as “easy” as advertised.

What follows are the high-level steps I took to initially test this feature and try to get it to work:

Test #1

  1. Install Firefox 10 in the base/parent image
  2. Update Inventory and Shutdown, create new snapshot
  3. Update Image
  4. Install Firefox 11 as user
    At this point I was expecting to get an error or some warning denying me access to install Firefox 11 and that it conflicts with an admin installed app.  However, this did not happen and I was able to install Firefox 11 as a user.  This led to my next test.

Test #2

  1.  Install firefox 11 in the base/parent image
  2. Update Inventory and Shutdown, create new snapshot
  3. Update image
  4. Install firefox 10 as user
    Again, I was expecting some kind of error or warning at this point but it never happened.  As a user, I was able to install the older version of Firefox without any issues.  This led to another test.

Test # 3

  1. Install firefox 11 in base image/parent image.
  2. Update Inventory and Shutdown, create new snapshot.
  3. Update image.
  4. Install firefox 11 as user and observe more space being taken up on the Personal vDisk.
    Again, no warnings or errors at this point despite directly creating a conflict between a user and admin installed app and wasting space on the Personal vDisk.  I tried this same test with several different applications but had the same result each time.  Frustrated, I turned to the Citrix Forums and found the answer to why this doesn’t work.

As explained in that forum, the reason my tests didn’t turn out the way I thought they would is because Personal vDisk application conflict resolution does not happen proactively, during the time when a user is installing an application, but only after a base image update when files or folders have been modified and updated.  To borrow the example given in the forum and at a more granular level, say that “app.dll” is present in the base image.  The user installs an application or in some way changes “app.dll” on their virtual desktop.  This change will persist indefinitely until “app.dll” is once again updated in the base image.  At that point the inventory process will note that “app.dll” has been modified and the user changes to “app.dll” will be overwritten the first time the virtual desktop boots up after an image update.

I decided to test this out at the individual file level to easily verify the results.  Here is a file in C:\Test on my base image.  Note the size:

As a user, I modify this file by deleting all of the content and create another file in this directory.  Note the sizes:

Now, these user changes persist between reboots and even persist between image updates when this specific file is not updated.  However, when I go back into my base image and update that file (add a word), here’s what it looks like to the user after an image update:

As you can see, the admin changes in the base image have overwitten the user changes.  If we go back to my earlier examples we will see that this same behavior holds true for entire applications as well.  For instance, on Test #3, if I go back into the base image and reinstall Firefox 11, those files get removed from the Personal vDisk the first time it boots up and I now use the application as installed by the administrator from the base image .  On Test #2, if I go back in and reinstall Firefox 11 on the base image, I now see Firefox 11 as the end user and the Firefox 10 files are overwritten.

Conclusion
While the Personal vDisk feature of XenDesktop 5.6 is a definite step in the right direction, there is still some work that needs to be done with application conflict resolution.  Currently, the only way to be sure that admin installed apps overwrite any conflicting user installed apps is to regularly go into the base image and update or reinstall your applications.  Further, since the default behavior is for admin installed apps to “win” in the event of a conflict, administrators should take care when updating applications and images as they could inadvertantly be overwriting user installed apps that they didn’t intent to overwrite and this could lead to a confusing experience for the user (“Hey!  I didn’t install this version!?”).

Not having a solid application conflict mechanism in place isn’t a deal-breaker for me, after all, current “dedicated” desktops don’t have a solution for this either.  However, it is important to know how this works and when overwrites occur so you can properly manage applications in your environment and aren’t unintentionally creating a bad experience for your users.  A future post may delve into ways to modify the default behavior (admin apps overwriting user apps) but for now I put this out there for all who may be confused as to to how this works, as I was.

Here are some useful Personal vDisk links:
http://blogs.citrix.com/2011/08/29/digging-into-ringcube/
http://support.citrix.com/proddocs/topic/xendesktop-ibi/cds-about-personal-vdisks-ibi.html
http://www.citrix.com/tv/#videos/5359
http://www.citrix.com/tv/#videos/5348
http://www.citrix.com/tv/#videos/5269

About these ads

, , , ,

  1. #1 by Greg on September 17, 2012 - 4:22 pm

    I found an interesting senario with an Oracle application called JDE Enterprise One. I’m using XD 5.6, Pooled VMs with PvD catalog that’s provisioned using MCS. The JDE software is installed on the base image just like MS Office, Adobe, and other primary apps. My users are able make changes within JDE and retain those changes if they reboot their VM. However, if they either Shutdown their machine from the Start Menu or do a restart from the Web Interface by clicking “Problem connecting” link, the JDE software reverts all their changes back to what’s on the base image that was installed by the Administrator. Basically when MCS clears the diff disk it reverts back. The JDE software changes many files on the C: drive. To keep things simple I focused on one file “C:\windows\JDE.ini that keeps reverting back to the base image on a Shutdown. Whether I manually modify the JDE.ini or the JDE software modifies it, it reverts back to whats on the base image after a Shutdown. There are also lots of oracle files that get changed under C:\Oracle and C:\E910_1. I’ve confirmed PvD is functioning properly since these users can install virtually any new application and it’s retained just fine within their PvD with a Shutdown and restart. It’s just this JDE software that’s being a pain. For a test I modified the section “File-Catalog-Construction” with Action “Catalog-Location-Guest-Modifiable” label in the files_rules.txt file on the base image and included the line C:\windows\jde.ini file. I re-ran inventory, shutdown, and restarted and re-tested. This didn’t initially work until I reset the my PvD, CtxPvd.exe -s reset. Once I reset the PvD, shutdown, log back on I’m able to modify the JDE.ini file and it retain the changes. That’s great and now all I have to do is add all files under C:\Oracle and C:\E910_1 to the files_rules.txt. Right? Not so fast. When I do that and attempt to run an inventory process it fails. When I look through the logs the inventory is attempting to copy everything under C:\Oracle and C:\E910_1 to the guest volume V: drive, UserData.vhd.tmp. It can’t since there’s only 2GB for the UserData.vhd and these two folders combined totals over 11GB. Now what? I’ve tried to find documentation on modifying the files_rules.txt and folders_rules.txt. But, I can’t find any. What are your thoughts?

  1. Citrix Virtualisierung,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: