Elsewhere

I wasn’t aware of this until yesterday when I took a leap of faith and tried it out. I had to update my Machine Catalog with a new image but in the last step of the update my two options are to either reboot all my VMs now and update them, or wait for the next shutdown. The latter is what I want but I don’t have the Citrix Connector for SCCM (nor do my VMs have SCCM agent installed on them).

My delivery groups are set to reboot every weekend and since that was a few hours after I was doing the update above, I chose to go with updating on next shutdown. Then I took a look today and sure enough when the machines rebooted they picked up the new image. Nice!

Anyways, turns out this is well known info. Found this forum post where someone confirms this, as well as a blog post on how someone’s scripted this. Looks like this only happens if you reboot the VMs from Citrix. So a reboot from within Windows (or whatever OS you are running) won’t update. It has to be initiated from Citrix.

Launch the imaging wizard. (No need for snapshots as we are capturing to a new vDisk)

The wizard will ask for a Target Device name. This can be different from the name of the machine/ VM. This is a PVS representation of the device.

Give a vDisk name too.

Upon creation this vDisk will be in private mode – which means only 1 machine can boot off it, and the disk is read/write.

Power off the VM.

If this VM will be used as the Master Target Device going forward, delete or remove the original hard disk. And go to the device object in PVS and change the “Boot from” to vDisk.

Alternatively: If this VM will not be used as the Master Target Device, create a new VM (maybe give it the same name as the Master Target Device in PVS) and put its MAC address to the Master Target Device in PVS. Also change the “Boot from” to vDisk.

Note: If the “Boot from” is not changed to vDisk the VM will try to boot from the local disk and fail if it’s not present.

Power on the VM. It will boot from the vDisk now (which is still in private mode). Make any more changes if required. Example domain join and add more applications etc. Whatever changes we make now will be written to the vDisk.

When everything is finalized power off the VM.

Convert the vDisk to standard mode. This means multiple machines can boot off it and the disk is read only (the writes will be made to a write-cache disk).

Note: the VM must be powered off to be able to change the disk type. There has to be no connections to the vDisk.

Now create a template based on the hardware specs you want for your VMs. Memory, CPU, etc. This template won’t have any storage. It will network boot.

From PVS console launch the XenDesktop Setup wizard. At one point it will ask for the template & vDisk we created above.

Quick note on the disk options.

With MCS we had the option of choosing random or static. Within random we had the option of using RAM as a cache. And within static we had the option of (a) using a personal vDisk or (b) a dedicated VM or (c) discarding changes.

With PVS our options are again random or static. No sub-options within random (i.e. no RAM cache etc). And within static the only options are (a) personal vDisk or (b) discard changes.

That’s all. New VMs will be created that can stream from the above vDisk. And AD accounts will be created for them.

Note these are very rough/ brief. These really are rough notes to myself as I am trying to make organize my mind.

In case of PVS: Master Target Device – this is the VM whose image is used to create a virtual hard disk (vDisk). This vDisk is what PVS uses to stream to its VMs.

Unlike MCS, the Master Target Device does not have to be a VM. PVS works against both VMs and physical machines. It does not care about the compute; all it does is look at the machine and create a vDisk by capturing its contents. You network boot into the machine you want to capture, and PVS creates an image by streaming its contents to the PVS server to create a vDisk.

The Master Target Device or its disk can be removed after vDisk creation.

Components of the Provisioning Services target device software include an imaging wizard to capture the image, a NIC filter driver used for streaming images from the PVS server to the target devices (remember: the target device software is not used only for capturing the image – i.e. the master target device, but also by the target devices after an OS is loaded), a virtual disk to store the OS and applications (again, used by the target devices). There’s also a system tray utility.

MCS creates a snapshot of the master VM you specify, but if you specify a snapshot it will not create another one.

This snapshot is used to create to create a full clone. A full snapshot, so to say.

This way the image used by the catalog is independent of the master VM.

During the preparation of this full snapshot an “instruction disk” is attached to the VM that is temporarily created using the full snapshot. This disk enables DHCP on all interfaces of the full snapshot; does some KMS related tasks; and runs vDisk inventory collection if required.

This full snapshot is stored on each storage repository that is used by Desktop Studio.

This full snapshot is shared by all VMs on that storage repository.

Each storage repository will also have an identity disk (16 MB) per VM.

Each storage repository will also have a delta/ difference disk per VM.

Important to keep in mind: if the master image in the catalog is updated, existing VMs do not automatically start using it upon next reboot. Only newly created dedicated VMs use the new image.

The delta disk is deleted when the master image is updated and existing VMs are made to use the new image (basically, new VMs are created and the delta disk starts from scratch; user customizations are lost).

Better to use desktop management tools (of the OS) to keep dedicated VMs up to date coz of the above issue.

If I choose Random then I get the option to allocate some of my RAM towards a cache, and also create a disk cache. RAM cache means all data is written to RAM first and then to disk as RAM fills up. And disk cache is like the Write Cache disk in PVS – you can specify a separate disk (maybe local to the host, or SSD storage) where data is written to.

Important to keep in mind here that the actual VM disk will not have any data written to it. All data writes either goes to the RAM cache or Disk cache. First RAM cache, then Disk cache. Both are optional; best to have both (or at least don’t do RAM cache only unless you have oodles or RAM!).

Read this post – it’s a good one. Also, check out the official post from Citrix introducing this feature in XenDesktop 7.9. MCS (Machine Creation Services) that makes use of RAM or Disk cache is known as MCSIO (Machine Creation Services Storage Optimization (beats me how that acronym works! :p)).

MCS VMs have two disks apart from the OS base disk – an identity disk and a delta disk. MCSIO VMs too have the identity disk and delta disk, but the delta disk is only used for maintenance tasks. Hence my comment above that when using either of these cache options, the size you allocate for these is your write cache/ delta disk.

If I choose static I have three further options.

If I go with static + save changes to a personal vDisk, I don’t get the option for cache disk etc. I can only choose my vDisk letter and size.

If I go with static + create a dedicated VM, again I don’t get any option for cache disk; I can only choose the copy mode (i.e. a linked clone or a full clone).

If I go with static + discard all changes, then I get the option for cache disk and RAM allocation towards cache. Basically, static + discard is similar to random. You are not storing any changes, so it makes sense to use cache (RAM and/ or write cache).

In the case of Server OS, I don’t have any choices (it’s always random) and I get the option for cache disk and RAM allocation.