So, I’m back from my holiday (Tenerife Spain) but still have a couple of days off from work, although I’ll probably be back working by the time this goes online, anyway… Since I’m preparing for, and putting together a presentation on XenDesktop 7 which is due on October 1st I thought it might be smart to invest some of my spare time to get things organized. As I’m working on my slides, in which I also highlight Machine Creation Services, MCS in short, as part of the XD7 architecture, I came across Personal vDisks, kind of a hard one to miss I guess. Now, I’m not sure if this will make it into my presentation since it’s not a direct XD7 feature (although it has been updated to version 7.x have a look here) and it has been ‘on the market’ for over a year and a half, I still think it’s definitely one worth having a look at.
Let’s start at the beginning
Within XenDesktop MCS is one of the options you have to provision virtual desktops on your underlying Host Infrastructure, which is basically your Hypervisor of choice. Be aware that you’ll need to have this in place and configured correctly, otherwise MCS won’t be available and you’ll have to do with one of the other methods available, like; PVS (great piece of technology as well, note that this Blog is not meant as a comparison between the two) or manually created VM’s for example. In earlier releases these desktops were, or needed to be, based on client operating systems. As of XenDesktop7, MCS can also provision virtual machines based on server operating systems. However, Personal vDisks are only applied in VDI scenario’s, meaning client Operating Systems. As you probably all know, when creating these (virtual) client OS based desktops using MCS we normally had (before XenDesktop 5.6) two choices, we could either create Pooled (Pooled can be random or static, see below) or Dedicated desktops:
Pooled-Random: Desktops are assigned randomly. Each time a user logs on he or she could possibly get a different desktop. When rebooted, any changes made are deleted and the desktop is ‘thrown’ back in the pool, again, ready for use.
Pooled-Static: Desktops are permanently assigned to a single user. Once a user logs on a desktop is assigned to that specific user. Consequently, each the time that user logs off and on again he or she will get that exact same machine. During reboots, any changes made are destroyed.
Dedicated: As with Pooled-Static, desktops are permanently assigned to a single user. During reboots, any changes made will persist across subsequent startups.
Some pros and cons
The above have several pros and cons. In the case of Pooled desktops user tend to complain about not being able to install and or update applications themselves as far as personalization goes, or at least that their changes aren’t retained when rebooting or logging off, which in the end could lead to poor user acceptance. It does however, keeps management ‘easy’ and storage requirements low. In the case of Dedicated desktops, users are happy but costs per user rise because of increased storage needs and possible complex and unique based images, which makes daily management more complicated.
The (old) process
When a Pooled (random or static), or Dedicated desktop gets provisioned here’s what happens: The first step is to create your so called base (master), or golden, image. This is used as a ‘template’ for future VM provisioning. You start by creating a VM, assign it a vCPU, memory and Disk space. Install your OS of choice, applications, AV, the XenDesktop Virtual Agent etc… As far as the configured resources go, you will be able to adjust these later on if you want.
Next you create a Machine Catalog from XenDesktop Studio which will leverage MCS in the background or you can start the MCS wizard manually if you want. The first choice you need to make is what type of catalog you want to create, known as the ‘Machine Type’. When you select ‘Pooled’ this is also where you decide if they are going to be random or statically assigned to users when they log on.
As you can see in the above screenshot, during the steps that follow you need to select your base (master) image, decide how many VM’s you would like to provision, perhaps change some of the base resources like the amount of vCPU’s or memory you want to assign per VM, change the hard disk size and choose between if either new AD computer accounts need to be created automatically, or that you’ll use existing ones instead.
On the ‘Create accounts’ page, the next step, you can select the OU where you want these VM’s to be created in Active Directory. Of-course we need proper Administrative permissions to be able to. Finally we hit ‘Finish’ on the summary screen and off we go. Now MCS will create the number of machines specified, it will add two disks to each machine: an identity disk (16 MB) which provides the VM with a unique identity, also used for Active Directory, and a differencing disk used to store all writes made to the virtual machine, which by the way, is linked to the read only copy of your master VM or better said, the snapshot taken from it, as explained below. If it’s supported by your storage solution this disk can be thin provisioned, otherwise it will be as big as the base (master) virtual machine mentioned before. Be aware that each VM provisioned by MCS will get its own ID and differencing disk.
During the above process MCS will take a snapshot of the base (master) VM, unless you manually created and selected a snapshot yourself during one of the previous steps, see above. Doing it this way gives you the option to give it a name yourself, otherwise XD will name it for you.
Next, MCS creates a full copy (or clone) of the snapshot and places this in your storage repository. This is a ‘read only’ copy shared by all VM’s. If you have multiple storage repositories then each repository used by the catalog will receive its own copy. In a nutshell, these are the steps needed to set up your Pooled or Dedicated desktop catalog. Although I might have left out some smaller steps in between, the machines will also get registered in Active Directory for example, the above at least gives you the big picture.
Storage
Knowing this, you can probably imagine where potential storage ‘issues’ could come in. First imagine this, when managing a few hundred Pooled desktops, used at the same time, and for now I’ll just assume that your storage solution does support thin provisioning, these can all potentially grow as big as your underlying base (master) image, that’s a lot of storage. In practice this probably won’t happen that much, and even if it did, this isn’t something to worry about because when a Pooled desktop gets rebooted all changes made to the VM (stored on the underlying differencing disk) will get deleted. This way you end up with a fresh and empty VM, again, waiting to be (re)used. Just make sure you have enough free space available to start out with, especially If thin provisioning isn’t an option. But since we don’t live in the stone ages anymore we should be fine. Read on…
Now picture the same scenario but this time we use Dedicated desktops. We start out the exact same way, only this time when the VM gets a reboot all the writes to the underlying differencing disk won’t get deleted! The user logs off or shuts down, he or she comes back into the office the next day, the same VM gets fired up and the user logs on, they work throughout the day, again making changes to the underlying base (master) image (written to the differencing disk), perhaps installing new applications or updates etc… but now nothing gets deleted. No matter how many times the VM gets rebooted, the underlying differencing disk will keep expanding taking up more free, till it’s full of-course. If you look at the above example it’s obvious that these Dedicated machines will consume a lot more storage than their Pooled opposites. Size accordingly when using this solution.
Management
In the end you’ll also need to manage these Dedicated desktops on an individual basis. This is partly because with Dedicated desktops it isn’t possible to update the underlying base (master) image without destroying the accompanying differencing disk, as we will see in a minute. Next to that, it’s only a matter of time before each user starts installing their own applications, making each desktop just a bit different from the other. Of-course there are all sorts of automation tools out there that can assist you with these kind of tasks, but I’ll leave that up to you. Still, this solution offers some real big advantages over ‘normal’ hardware based desktops, it’s just that it might seem a bit more ‘romantic’ on forehand than it turns out to be once you implement it.
The underlying base image update process
But that’s not all. What about updating the underlying base (master) image? What happens then? For Pooled desktop it works like this: When you update the base image, you install or update an application or apply some security updates for example; the process described earlier basically repeats itself. All we need to do is point the (new) updated image to the Pooled desktops of choice, give them a reboot (you have several choices on how to accomplish this) and voila, we’re done.
Dedicated desktops work a bit differently; they cannot be updated the same way. Once a differencing disk is pointing to one of the master VM copies (clones), the base (master) image, it cannot be changed, at least not from studio. If you do change the base image, through PowerShell for example, or create a complete new one, a new copy, or clone, will get created and only newly provisioned Dedicated desktops will, or can, use this new or updated base image. The other Dedicated desktops will continue to use the ‘old’ base image, again, not making management any easier. See the image above which I got from: www.infrastructureadventures.com hosted by Joe Keegan.
Let’s summarize
Pooled machines definitely keep things simple and easy from a management perspective, also, the storage needs are far less drastic, especially when hundreds or thousands of VM’s are involved. On the other hand, your users will get what’s on the base image and that’s about it. Dedicated machines give your users all the freedom they want but also put a burden on your daily management tasks and can potentially, and probably will, consume a great deal of available storage. If we add in the base image update process it’s hard to pick a winner. Given these option I would personally prefer Pooled desktops for overall use and only offer Dedicated desktops when really needed.
Personal vDisks
What we really need is something in between, desktops which are customizable for our end users (assuming storage is not too big of an issue) but still manageable on a base (master) image level and preferably smaller in size. Well… Personal vDisks can offer us just that and even does one better! Note, that PvD’s are not completely new, they were introduced with XenDesktop 5.6 and again improved with XenDesktop 7 as mentioned in the beginning.
With Personal vDisks we still use one base (master) image just like before but we now get an extra Personal vDisk attached to our VM on which all our ‘personal’ changes will be stored, these will include all file level and registry changes including but not limited to: installed or streamed applications provisioned by SCCM, App-V (think cache) or XenApp for example, but also things like: desktop wallpapers, start menu settings, favourites etc. It basically stores all changes made under C:Users (Windows 7) as far as the user profile is concerned and everything else when it comes to applications that get installed / updated.
Size and allocation
The PvD VHD’s, by default, are split in two when it comes to storage allocation for personal (profile related) changes and application installs and or updates. So if you your PvD is 10 GB in size it will allocate 5 GB for profile / personal storage and the other 5 GB for application installs / updates etc. This can be changed (Registry setting) into 70 / 30, 90 / 10, or 99 / 1 even, give this some though and adjust accordingly. For example, when used in combination with user profile management and or folder redirection for example, there’s not that much left and it would be a waste of space not to change it. Make sure to give this one a read as well:
http://blogs.citrix.com/2012/05/21/beware-the-5050-split-with-pvd/
Personal vDisk enabled VM’s are created the same way as Pooled desktops, or Dedicated desktops for that matter, like explained earlier. Although I must note that with XenDesktop 7 the creation and configuration process of catalogs and delivery (desktop) groups does look and feels a bit different. In fact they are basically the same, the only difference is that when you create a Pooled desktop catalog you can now select ‘Pooled with Personal vDisk’ instead of just ‘Pooled’ as the ‘Machine Type’ and that’s it. Because of this you’ll still see a differential (and ID) disk attached to the VM as well, but remember, just as with ‘normal’ Pooled desktops, it’s stateless, meaning that it will be emptied with every reboot. The best thing is, it will hold all delta writes made to the underlying base (master) image OS, keeping the PvD, which only holds all of our personal changes as explained above, smaller in size, the way we want it to be, another (big) advantage. Again, XenDesktop 7 has a slightly different looking wizard and uses some new terminology here and there, but know that the general idea, and outcome, is the same.
Next, and probably one of the best features yet, when an administrator needs or wants to edit the underlying base (master) image, no problem! He or she simple updates or installs an application, service pack, security update or whatever needs fixing and the Personal vDisk will take it from there. The user will see all the changes he or she made (stored on the PvD) in conjunction with the base (master) image even if it’s being updated live, although the administrator must still roll out these changes to the end users from studio like before, so the VM will still need a reboot. It allows all of the user changes to persist over the base image changes, now that’s what we need! The best of both worlds!
The Personal vDisk communicates with the XenDesktop Personal vDisk agent which is installed on the base (master) image during (catalog) creation. This agent tracks what’s installed and available on the base (master) image versus what’s installed and changed on the Personal vDisk and will blend these two together once the base (master) image has been updated and rolled out, or applied, to the end user. This way we get the persistence of Dedicated desktops together with the management advantages of Pooled desktops.
Some characteristics
If a conflict exists, for example, when a user installs the same application on his PvD as the Administrator does on the base (master) image then the system will make note of this and remove the software installed by the user, keeping the PvD as small in size as possible. Note this is a default setting and is customizable the way you feel fit.
PvD’s can be resized afterwards. Their default size and location is selected during the catalog creation wizard (selecting MCS as the provisioning mechanism) from XenDesktop Studio or the PVS setup wizard when PVS is applied. They end up smaller in size then the ‘normal’ provisioned differencing disks created with Dedicated desktops.
Thin provisioning is supported, PvD’s can be attached to any storage target as defined within your Hypervisor, this means that PvD’s can be on different (storage) locations then your actual VM’s, enabling you to spread the IOPS load.
PvD can be used as a simple profile management solution for small sized environments, although Citrix recommends using a separate profile management solution alongside. It’s compatible with almost all profile management solutions out there. I’m not going to mention with one Citrix recommends :-)
PvD’s allow for easier management but with the flexibility of Dedicated desktops. They are a 100% persistent with Pooled VDI storage & management. As mentioned earlier PvD’s are compatible with most PC lifecycle management systems as SCCM and application virtualization solutions like Citrix XenApp. And just so you know, PvD’s are also available in VDI-in-a-Box.
Conclusion
For me my real interest in XenDesktop started with XenDesktop 7, there was so much to explore, and still is, that I didn’t had the time to look at some of the older versions first. Now that time progresses and I’m learning XD7 as I go I often find myself browsing through some of the older E-Docs sections still picking up new knowledge, for me anyway. I think Personal vDisks are great and it’s a shame that they’re not implemented more often, an underappreciated product to say the least. I mean, complex to manage? Come on, that can’t be (really) true right?! VDI scalability will improve; users will be ready to adopt this new model without a doubt and storage requirements and costs will drop. Since you won’t need to invest in new hard and/or software your costs per user will eventually decrease, besides that you can continue to use what you already know best, no training or additional tools required, again potentially saving time and money. That about sums it up for me, if you feel I left anything out, drop me a line.
