vDisk Types, Creation Flow, and Imaging Wizard Basics

Study guide

Technical reference and lesson notes

The big idea is that a vDisk acts like the hard disk for a target device, but instead of every machine having its own fully independent disk, the operating system image is stored centrally on a Citrix Provisioning Server or shared storage location. Target devices then boot from that vDisk across the network.

In modern Citrix Provisioning, vDisks are commonly based on VHDX files. The vDisk can also have an associated PVP properties file, and when versioning is used, additional differencing disks can exist as part of the vDisk chain. Citrix documents that a vDisk can be shared by multiple target devices in Standard Image mode or assigned to one target device in Private Image mode.

Private Image Mode

Private Image mode means the vDisk is read/write and only one target device should boot from it.

This is similar to a normal PC hard drive. If you install software, make changes, edit the registry, patch Windows, or modify the operating system, those changes are written directly into the vDisk.

This mode is useful when you are building, repairing, updating, or directly modifying the image. It is not the normal mode you would use to stream one image to a large number of production machines.

In real terms, Private Image mode is for controlled maintenance or image preparation. You would not want 100 or 300 target devices all booting the same vDisk in Private Image mode because they would all need write access to the same disk image, which defeats the purpose of PVS.

Standard Image Mode

Standard Image mode means the vDisk is read-only and can be streamed to many target devices.

This is where PVS becomes powerful. Instead of maintaining hundreds of individual operating system disks, you maintain one central image and stream it to many machines. Each target device sees the vDisk as its boot disk, but because the vDisk is read-only, any writes that Windows needs to make are redirected to a write cache. Citrix explains that Standard Image mode uses a read-only vDisk and each target device builds a write cache for operating system writes.

The important concept is this:

When a machine boots from a Standard Image vDisk, it starts from a clean shared image. Changes made during that session normally go to write cache. Depending on the cache type, those changes may be discarded after reboot.

That is why Standard Image mode is so useful for pooled VDI, classroom computers, labs, kiosks, and other environments where you want machines to return to a known-good state after reboot.

Write Cache and Persistence

In Standard Image mode, Windows still needs somewhere to write temporary data, logs, profile activity, application changes, updates, and normal operating system writes. Since the vDisk itself is read-only, those writes go into a write cache.

The lecture mentions that writes are discarded after reboot unless persistent cache is configured. That is the correct high-level idea, but the exact behavior depends on which write cache option is selected.

Citrix supports several write cache destinations, including cache on the target device hard drive, cache in RAM, RAM with overflow to disk, cache on server, and persisted cache options in older configurations.

For most modern PVS VDI designs, one of the most common production patterns is cache in device RAM with overflow on hard disk, assuming the target devices have enough RAM and a local/cache disk available.

Dynamic vs Static vDisk Creation

The slide mentions two types of vDisk sizing: dynamic and static.

A dynamic disk grows as data is written to it. This saves storage up front because the disk does not immediately consume the full maximum size.

A static or fixed-size disk reserves the full amount of storage immediately. This can be more predictable from a storage performance and capacity planning perspective, but it consumes all allocated space right away.

For a lab, dynamic is usually easier and more storage-friendly. For production, the choice depends on storage design, performance requirements, operational standards, and how the environment is backed up or replicated.

Basic vDisk Creation Flow

The lecture walks through a simplified image creation process. Cleaned up into proper Citrix terms, the workflow looks like this:

First, you create your master target device. This is the machine that contains the operating system, applications, patches, configurations, and, if you are building Citrix Virtual Apps and Desktops workloads, the Citrix VDA.

Next, you install the Citrix Provisioning target device software on the master machine. Citrix documentation describes this as part of preparing the master target device for imaging.

Then you run the Citrix Provisioning Imaging Wizard from inside the master machine. The wizard connects to the PVS farm, prompts for the Provisioning Server name, the store, the target device information, and the vDisk configuration. Citrix states that the Imaging Wizard is used from the master target device to create the new vDisk.

During the wizard, you can choose to optimize the disk for Citrix Provisioning. This matters because Citrix notes that optimization reduces I/O and improves write cache functionality.

After that, the master machine is shut down. You then adjust the boot order so the network adapter is first, or at least above the local hard disk, depending on the intended boot method. In PVS, the target device is configured so that it can boot from the assigned vDisk.

When the machine powers back on, it PXE boots or otherwise contacts the PVS boot infrastructure, finds its assigned vDisk, and begins streaming the image from PVS.

Why the Boot Order Matters

The master machine initially boots from its local hard disk because that is where Windows is installed before the image is captured.

After the image is created and assigned in PVS, the target device needs to boot from the network so it can receive its bootstrap information and stream the vDisk.

That is why the lecture says to change the BIOS boot order and move the NIC up. In a VMware lab, this usually means making sure the VM can PXE boot from the network. In a production environment, the actual boot method could involve PXE, Boot Device Manager, ISO boot, or UEFI-compatible boot configuration depending on the environment design.

Where the VDA Fits In

The slide says to include “VDA if you want to create XenDesktop.” In current Citrix terminology, XenDesktop is now part of Citrix Virtual Apps and Desktops.

If this image will be used for Citrix desktops or published apps, then yes, the Citrix VDA needs to be installed in the master image before it is streamed to target devices.

That matters because PVS is only responsible for streaming the operating system image. The VDA is what allows the machine to register with the Citrix Delivery Controller and accept user sessions.

So the relationship is:

PVS streams the image.

The VDA registers the machine with Citrix Virtual Apps and Desktops.

The Delivery Controller brokers user access to the machine.

Practical Admin Takeaway

For your lab, the important thing to master is the lifecycle.

You build a master machine.

You install the PVS target device software.

You install the VDA if this will be a Citrix desktop/server image.

You run the Imaging Wizard.

You create the vDisk in the PVS store.

You optimize the image.

You shut down the master.

You configure the target to boot from PVS.

You stream the image.

You switch the vDisk into Standard Image mode when it is ready to be shared by multiple machines.

This is the core PVS workflow. Once you understand this, the next level is learning versioning, write cache design, replication, target device collections, bootstrap delivery, and troubleshooting target boot failures.

What to Remember for PVS Mastery

Private Image mode means one device, read/write access, and direct changes to the vDisk.

Standard Image mode means many devices, read-only access, and writes redirected to cache.

The Imaging Wizard is the main tool used to capture a master target device into a vDisk.

The master image should be optimized before being used in production.

For Citrix Virtual Apps and Desktops, the VDA belongs inside the master image.

PVS does not eliminate the need for proper image management. It centralizes image management so you can update one image and stream it to many devices.