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.
15 responses to “XenDesktop (MCS) Personal vDisks”
This is a good blog around PvD but there is some confusion in the “Some pros and cons” section. Yes, Pooled desktops are created from a master images and changes to that system level image like installing a browser plugin or an application from the internet, is flushed at logoff (which will reboot the machine and bring up a fresh image). However, personalization settings, such as desktop background, MS Office preferences, etc., are part of the user’s profile and ARE retained. It’s extremely important for a customer to implement the correct profile structure when deploying either desktop workloads (VDI) or server workloads (old XenApp). My preference and what works well for the vast majority of my customers is use MS folder redirection for everything possible and then use Citrix Profile Management to handle the rest. AppData is in question as to whether or not to redirect but this is mostly dependent on the client’s applications and if they write heavily to that directory structure. If it does, I’ll use Profile Management for AppData. This keeps the logins small and fast and allows the users to “personalize” their desktop to their liking.
Hi Rob,
First of all, thank you, secondly, you are right; I did a poor job on the pros and cons part. I’m aware of how it works, regarding the user profile settings etc… I just didn’t describe the way I should’ve done; I will correct it when I get the chance. Doesn’t Citrix Profile Management offer folder redirection as well, or is that what you’re talking about as well? Totally agree on the profile part, a very important part of the architecture in place. Have you used or implemented PvD’s in production environments, or mostly just Pooled VDI environments in conjunction with redirected folders etc… like you described? Thanks again!
Profile Management does not do FR. It copies down what you want and excludes what you don’t want at logoff which keeps the profile size relatively small… especially if you’re redirecting all shell folders. XD7, however, can provide folder redirection through it’s policy engine but the settings won’t be visible in a normal GPO. Most customers are used to and comfortable with managing FR through GPO’s so that’s where I normally lead them. I like using XD policies for optimization of HDX, etc. that GPO’s can’t do.
I normally recommend PvD to customers who have a need for it. As an example, Developers and IT staff typically need and use applications that are outside of the normal corporate LOB applications. That is a great use case to create a desktop catalog for them and use PvD. With XD7, PvD is installed by default but just not enabled. This makes it really easy to spin up machines for those types of users that will use PvD.
Along those same lines of different users, which we call User Segmentation, when I describe to customers the user density they can get out of a “server workload” (XenApp) and how it can satisfy the requirements for roughly 80% of their users, they lean that way just on infrastructure savings alone. Example is a 96GB host. WIth a 2GB Win7 template, you’ll get about 40 desktops. That same host running server workloads with published desktop and apps will get you 5 16GB instances equating to about 4x the user density. This scenario is great for task-based workers that don’t need to install applications and they just want a consistent fast desktop every time they log in but still maintain their personalization settings. Your blog is specific to PvD so I’ll jump off the soap box on that one :)
Thank you Rob for such a detailed explanation, I appreciate it. Ok, that’s what I was aiming for, FR within XD7 as part of its profile management solution. I know both solutions, XD7 profile management and Citrix profile management, are different, I just thought it was available in Citrix profile management as well, my bad :-)
Many thanks Bas and Rob… you two are v inspiring :) I m new to Citrix world and very hungry for the right knowledge. Thanks once again.
Hi Sandeep, No problem at all, I’m glad we could be of help. Did you check you rmail :-)
How would you recommend backing up over 1,000 desktops using PVDs in VMware where LUN level snaps are not an option?
Hi Patrick,
To be honest, I don’t really have a recommendation, I’m not that big on the backup and restore part. If I understand correctly, to name one, VMware’s consolidated backups aren’t an option? Perhaps I’m miss interpreting the LUN level snapshot part.
Have you looked at the various disk / volume / file level backup solutions? Veeem, Commvault, Backup-exec… Or perhaps the backup and restore scripts that Citrix offers might do the trick?
Just trying to help, good luck!
Hi Bas
Hope you had a view nice day’s off over eastern.
I’am a little lost, and hope you can give me a hint to solve my question.
how to configure a master target win7 for xendesktop 7.5 and pvs 7.1, esxi 5.5
i would like to configer pvs with cache on hard disk. @ the moment i create a master with a second active and formated drive (letter D:10gig).
Out of that machine i create a template.
know, if i create a second drive and attach it to the master target. format mark active give drive (letter P:15gig) my pvs cache is jumping allways to drive P: and ignores drive D:
Can you explain, what steps are necessarily to create, format or not the drives for a pvs target device with cache on hard disk and a private disk?
i hope you can help me out here.
thank you in advance and wish you a nice week
Thorsten
Hi Thorsten,
Sorry for the late reply, I’ve been really busy.
Sounds like you’re going about it the right way. If in doubt, I would advice you to have a look at one of Citrix’s PVS manuals, it will provide you with step by step instructions on how to create and configure mater images / templates. I did a small search and it seems more people are struggling with a similar issue, perhaps these articles can help you out as well.
http://www.riverlite.co.uk/2013/12/pvs7-write-cache-drive-not-initialized-after-xendesktop-setup-wizard/
http://support.citrix.com/article/CTX133476
Let me know.
Regards,
Bas.
thats no problem
i’am glad that you have replied to my question! very happy and i will give you feedback if i have luck
Thorsten
Hi Bas,
A small question about: “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 :-)”
I was looking for Citrix recommendations regarding PvD & profile management solutions but couldn’t find it. Do you maybe know where Citrix makes this recommendation ?
Besides this, why should you Always use a profile management solution with PvD ? To keep a small profile size ? To use PvD only for user installed applications ?
Best regards,
Wim
Hi Wim,
Thanks for your reply. First of all have a look at these two articles, they talk a bit more on the profile part of the PvD solution:
http://blogs.citrix.com/2012/05/21/beware-the-5050-split-with-pvd/
http://www.showmehowtodoit.com/2012/citrix-xendesktop-5-6-personal-disk-and-citrix-profile-management-registry-tweak/
They don’t really do any real recommendations with regards to profile management solutions in general, but if you give it a good search you’ll probably end up with Citrix Profile Manager :-)
As you’ll read in the first article, keeping the profile small(er) in size isn’t a real issue if you take your time, test and think things trough a little. Using a separate profile management solutions is always optional, but not mandatory in any way. Especially in smaller environments using PvD’s you should be able to do just fine, depending on your demands and wishes. In larger environments, using PvD’s together with Citrix Profile Manager for example, the users profile won’t be redirected to the PvD, meaning smaller PvD’s and thus using less storage overall. Now I’m not sure if storage and the costs that come with it are that big of an issue nowadays, but something to keep in mind none the less.
Besides the above, and probably of more importance, using a profile management solution makes it possible to roam between devices if that’s what you need. Now don’t get confused with the traditional roaming profile, they are similar, but at the same time have some distinct differences as well.
Hope this helps, do let me know!
Regards,
Bas.
Hello Bas! Is there any site or something similar where you centralize rectifications or ajustments about your book? If it is necessary, sure. I bought both: paperback and kindle edition. Your book is awesome! Congrats!
Thank you. No, not really. I just keep posting new information on basvankaam.com. I’m having a hard time keeping up with everything that’s happening already, administrating another website or something similar doesn’t sound like a good plan at the moment :)