VM Junkie

January 20, 2009

VMware View article at BrianMadden

Filed under: thinapp, vdi, vmware — Justin Emerson @ 1:27 pm

Roland van der Kruk over at BrianMadden.com has been writing up some articles about VMware View, his latest one has some conclusions at the end which I wanted to take issue with:

  1. Providing linked clones to users that have full control to the system, resulting in user initiated changes to the OS like copying data, removing it, etc., will end up in a system disk that eventually has a bigger size than if the OS was provided to the user without the linked cloning technology.
    This is not the case. The way a linked-disk in VMware ESX works is that the linked disk can only grow to the maximum size of the hard disk it was based off of. So a 20GB system disk fully provisioned is 20GB, and the maximum size of a thin-provisioned disk is 20GB. If Roland would like to test this, just use IOMeter to write a giant file to your system disk and see the size increase and stop.
    At the same time, you can specify at what size to automatically recompose a VM, so if it grows over, say 10GB you can automatically recompose it.
  2. If a View Administrator decided to refresh the OS because he added some hotfixes or extra software, all user modifications to the OS are deleted. In fact the System Disk is simply deleted and a new linked clone is generated off the new state of the ‘master image’.
    This is correct, but this is clearly outlined in the documentation. The purpose of the User Data Disk (or just using Roaming Profiles of some kind) is to keep the user’s profile persistent between Recompositions. As for how you handle Applications, see below.
  3. What ‘Persistent desktop’ actually means is that the state of a disk provided by a View Administrator is ‘persistent’. A desktop can be made persistent by recomposing or (scheduled) refreshing the deployed linked clones, resulting in exactly the state that a View Administrators expects it to be. From the view of end users using Linked Cloned Desktops, no persistence can actually be guaranteed, because all user actions will be undone by ‘Desktop Refresh’ or ‘Desktop Recompose’.
    This is only half-true. Any persistence made in user space are guaranteed by the recomposition. If it’s a change made to HKEY_CURRENT_USER, or to anything in Documents and Settings, it will be persistent across recomposition or refreshes.
  4. As soon as user modifications to the System Disk need to be persistent, no linked clone technology should be used. Instead, 1-on-1 desktops need to be provided, in which deployment tools like SCCM or Altiris will have to be available to maintain the system.
    This exact reason is why you cannot purchase View Composer without purchasing ThinApp. In order to make sure applications persist between rebuilds, as well as application settings and such, you need to use ThinApp (or at least some kind of Application Virtualization technology).

View Composer deployments do not make sense unless the base operating system is disposable. You have 4 components in any desktop:

The Desktop Blob

The Desktop Blob

User Data is handled by Roaming Profiles or the User Data Disk. Applications need to be either disposable (you can throw them out because they are stateless) or through App Virtualization. The hardware is just a VM hardware which is always identical or easily changeable. If those three things are taken care of, the OS itself is disposable, so a desktop recomposition should have no negative effects.

I will agree that View Composer is not perfect, but I think it’s come closest to the best possible solution available so far. That being said, you can ignore the whole recomposition options entirely and just use thin provisioned desktops, but they will grow over time just due to the way Windows writes to the filesystem.

On the upside, there is a really great session from VMworld which talks about performance and best practices for VDI which contains information on modifications you can make to a default Windows XP installation to reduce the amount of space that will be used by the OS at idle. Check out Slide 39 on the PDF.


1 Comment

  1. Indeed your statements are correct and more specific than mine. All user data can be kept separate, what is not persistent to the users are OS/system disk changes.

    About the size of the snapthos/linked clone, I didn’t test that and indeed I read that, it makes sense that its’ size will be limited to the configured size of the vitual system/os disk.

    Thanks for clarifying that.
    Roland van der Kruk

    Comment by Roland van der Kruk — January 21, 2009 @ 4:09 am

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Blog at WordPress.com.

%d bloggers like this: