This article was delayed for two years, because it was two years ago that I became acquainted with VDI based on Citrix XenDesktop and the
Personal vDisk (PvD) feature that was a bit discouraging. At that time, I was responsible for the
VDI infrastructure
managed by the Fujitsu PanoLogic product . Full clones were used, and it was a pain. Just imagine installing updates on 1000+ virtual machines located on a non-flash array.
We were looking at VMware View (now Horizon) with its Linked Clones, but we were very embarrassed by the fact that the update of the base image (Gold Image) brings all the desktops based on it to almost a virgin appearance, depriving the user of lovingly installed applications. Developers would definitely not be happy, and the rest are accustomed to good.
And when we were allowed to play around with Citrix XenDesktop, then another 7.0 or 7.1, I was delighted. Because when using PvD, all changes made inside the virtual machine were saved even after updating the master image. And by “all” I mean not only profile settings or documents on the desktop (this is achieved in VMware), but also installed and even remote (!) Applications. When I shared the results with VMware colleagues from another organization, they said that this was impossible, because it was not explicable.
In practice, of course, miracles rarely occur, and there is an explanation for what is happening.
')
Both manufacturers of VDI solutions approach differential disk infrastructure implementation in their own way. With VMware, it looks like this:
For obvious reasons, nothing can be written on
Replica , the whole record goes to
Delta .
Internal stores computer identification information (such as an AD password).
Persistent Disk can be created for data that must always be stored. Here you can transfer the profile, Redirected Folders and Home Directory.
Disposable Disk , on the contrary, is reset after each reboot. Here you can transfer data that you do not need to store at all (pagefile, temp) in order to reduce the size of Delta and the load on it.
And this is what the XenDesktop picture looks like when using MCS (it is closer to the VMware used than PVS)
Difference - to redirect the record.
Identity - to store the identity of the computer.
PvD - Personal vDisk for storing permanent data. It looks similar to the VMware Persistent disk. In the system, it is visible as a P: disk (by default) and if you access it, you will see user data (profile).
However, as I already wrote, when using PvD, the virtual machine "remembers" not only user settings and data, but also installed and even remote applications. Even after updating the master image. Conducted the following experiments.
Software installation
1. Created a master image with Windows 7 (VD-template).
2. Created a virtual desktop based on it (VD01).
3. In the virtual desktop installed 7zip (in C: \ Program Files).
4. Updated the master image (installed Adobe Reader in it) and applied it to the pool.
5. Logged in to VD01. 7zip in place. And Adobe Reader too.
6. Created a new desktop based on the same master image (VD02). Adobe Reader is present. 7zip is not.
Software removal
1. Logged in to VD01. Removed Adobe Reader.
2. Updated the master image (installed several Windows updates in the VD-template) and applied it to the pool.
3. Logged in to VD01. 7zip in place, Adobe Reader removed. Updates are present.
4. In VD02, Adobe Reader is in place. Updates are present. 7zip is not.
5. Created a new desktop VD03. The same picture as in VD02.
Damn amazing! It remains to understand how he does it. Well, I will not beat around the bush and whip up intrigue.
Technically, PvD is two disks in one. The first is what we see in the form of a P drive: inside a virtual desktop. Profile data is redirected to it, and there is nothing unusual here. The second is the virtual vhd-disk UserData.vhd, which lies on the first one. It is also mounted in the system, although it is not visible in the explorer. And the record is redirected to it at the object (not block) level.
When first used on PvD, information about objects is copied from the main image, which is located here: C: \ CitrixPvD \ Settings \ Inventory. Further in Inventory the data about the changes made by the user and links to them are recorded.
After updating the master image, before turning it off and removing the snapshot for use in the pool, you need to update the Inventory on it. If you forget, the system will remind you when you try to turn it off.
After the distribution of the new master image, virtual desktops re-read the Inventory of the new image when they first start and compare it with the PvD entries. In the course of this process, it is determined what is new and what should be redirected.
This procedure leads to the fact that the first user login to the system after updating the master image can take a long time (10-15 minutes, depending on the number of changes made). At first, without knowing the details of the operation of this mechanism, I spoiled several desktops, impatiently rebooting them at this moment. Well, that in a test environment.
At the same time, if it turns out that objects previously installed by the user and stored in PvD appeared in the master image, they will be cleaned out of PvD in order to save space, and the links to them will be replaced with those that lead to the main image. In other words, if I would install 7zip in the master image in the examples above, VD01 would remove it from PvD and start using the one that is common to all. Subject to the coincidence of versions.
I have not tested different versions of scenarios with version conflicts.
Some PvD details and limitations.
- All hypervisors supported by XenDesktop are supported — Hyper-V, VMware ESXi, and of course Xen.
- Only client-side guest operating systems are supported (Windows 7-10).
- No administrator rights are required to work in the guest OS (although the user will not be able to customize a little without local administrator rights).
- Cannot be used for software isolation. For example, it will not work with PvD to launch two different versions of MS Office or Internet Explorer. To solve this problem, you need to use other technologies. But if someone needs to use Office 2003 instead of the one installed in the main image of 2013, then it’s quite an option.
- Not compatible with applications using 0-level and network stack drivers (miniports / protocol drivers). They should be put in the main image.
- OS updates should also not be installed on PvD to avoid conflicts.
- With guest OS antivirus, in principle, is compatible, but there may be nuances. And problems.
- You should not backup / restore from inside the OS, since the backup agent cannot determine which part of the data belongs to the main image and which part to the PvD. When recovering, all data will be recorded in PvD, simply because the entire record is redirected there. Backup and recovery should be done at the hypervisor level and from his side.
Management and settings (quite a bit, did not have much practice)
The minimum size of PvD is 3 GB. The maximum is limited by what the storage system supports.
By default, profile data (drive P :) and OS data (UserData.vhd) distribute space utilization on a 50/50 basis. You can change this ratio by changing the following registry key:
HKEY_LOCAL_MACHINE \ Software \ Citrix \ personal vDisk \ Config
Value: PercentOfPvDForApps
By default, 50 is set. If corrected to 80, 80% of the space will be reserved for applications, and 20% for profile data.
You can generally prevent profile redirection on PvD (for example, if you are using Roaming Profiles):
"HKLM \ Software \ Citrix \ personal vDisk \ Configuration"
Value: "EnableUserProfileRedirection"
0: Profile is not directed to the PvD
1: Profile is redirected to the PvD
PvD can be reset to its original state either from the Desktop Director, or from the desktop itself using the command:
C:\Program Files\citrix\personal vdisk\bin\ctxpvd –s reset
(in command line from administrator)
Reset does not affect the user profile. In fact, just UserData.vhd is replaced by the original empty template, taken from here: C: \ ProgramData \ Citrix \ personal vDisk.
Finally, a small abstract conclusion. The error "
Failed to load reg hive [\ Device \ IvmVhdDisk00000001 \ CitrixPvD \ Settings \ RingCube .dat]. " Suggests that the PvD solution is based on the development of RingCube's
vDesk , which was
purchased by Citrix in 2011 for $ 46.67 million.
And as a final summary, I note that the decision is, of course, very interesting and makes the life of a VDI administrator much more convenient. Although it can hardly be considered a panacea - although the support of “almost all standard software” is claimed, various scenarios need to be checked and possible version conflicts or problems with individual software cannot be ruled out. And what in our [IT] world can be considered a panacea?
As I said, the article was two years late - by the time I found information about the mechanisms of PvD work, I changed jobs and lost the ability to write articles in general, due to the extremely high workload. During this time, new technologies for connecting custom applications to VDI have appeared - VMware has
applied App Volumes, Citrix has launched
Unidesk ... But these are slightly different stories.
Now I have changed jobs again, moved away from virtualization, but I was tormented by the feeling of an unfinished business ...
Thanks for attention! Even though I closed my own gestalt with this article, I hope that someone else will be useful, or at least interesting.