Citrix Provisioning Post-Imaging Validation and vDisk Assignment

Study guide

Technical reference and lesson notes

After a Citrix Provisioning imaging task completes, the next step is to validate that the vDisk was created successfully, confirm that the master target device is no longer locking the vDisk, and prepare the image for use by target devices.

This stage is important because the imaging wizard may report success, but the administrator still needs to confirm that the vDisk exists in the store, appears correctly in the vDisk pool, is assigned to the proper device collection, and is configured with the correct access mode and write cache settings.

In a normal Citrix Provisioning workflow, the master target device is used to create the vDisk. After the image is created, the master device should be shut down or reconfigured so it no longer keeps the vDisk locked. Once the image is ready, it can be assigned to target devices that boot from the network.

Purpose

The purpose of this process is to move from a successfully captured image to a usable Citrix Provisioning vDisk that can be assigned to devices in a collection.

At this point, the administrator should be validating the following items:

The vDisk exists in the PVS store.

The vDisk appears in the vDisk pool.

The master target device is no longer locking the vDisk.

The target device is configured to boot from the network.

The vDisk is assigned to the correct target device or device collection.

The vDisk is placed in the correct access mode.

The write cache location is selected correctly.

Citrix describes vDisks as images that are deployed by assigning them to one or more devices, and when the device starts, it boots from the assigned vDisk. Citrix also documents the two common boot modes as Private Image mode and Standard Image mode.

Step 1: Confirm the Imaging Task Completed Successfully

After the imaging process finishes, confirm that the task completed successfully. In the instructor’s lab, the imaging process completed and the vDisk was created.

The first validation step is to open the Citrix Provisioning Server and browse to the PVS store location. The store should now contain the newly created vDisk files.

Depending on the version and configuration, you may see files associated with the vDisk and write cache behavior. The key point is that the vDisk should now physically exist in the store location and should also appear in the Citrix Provisioning Console.

Step 2: Review the vDisk in the vDisk Pool

Next, open the Citrix Provisioning Console and browse to the vDisk pool.

The newly created vDisk should be visible. If the master device is still powered on or still connected to the vDisk, the vDisk may appear locked. This is expected during certain stages of the imaging process.

A lock generally means that a device currently has the vDisk open. In the lab example, the instructor noted that the lock was normal because the master device was still on.

Step 3: Shut Down the Master Target Device

After confirming the vDisk exists, shut down the master target device.

This is important because the master device may still be holding a lock on the vDisk. Once the master device is shut down, refresh the vDisk pool in the Provisioning Console. The lock should clear after the device fully powers off and the connection is released.

If the lock remains, refresh the console again and verify that the master VM is actually powered off. In a lab, there can be a short delay before the lock disappears.

Step 4: Change the Master Device Boot Order

After the vDisk is created, the target device should be configured to boot from the network if it will be used as a streamed target device.

In the transcript, the instructor shuts down the master device and changes the boot order so the machine boots from the network instead of directly from its local disk. This is a critical step in a PVS workflow because a target device using Citrix Provisioning needs to locate the Provisioning Server and boot from the assigned vDisk.

Citrix notes that after a target device is created, it must be configured to boot from the network, have a vDisk assigned, and have bootstrap information available so it can boot from the assigned virtual disk.

Step 5: Create or Verify the Target Device in the Collection

After the vDisk is available, go to the appropriate device collection in the Citrix Provisioning Console.

From the collection, create or verify the target device object. In the instructor’s example, the device is created inside the desktop collection. This allows Citrix Provisioning to track the target device and assign the correct vDisk.

Citrix device collections are used to create and manage logical groups of target devices. This makes administration easier because actions can be performed at the collection level instead of managing each target device individually.

When creating a target device manually, the administrator typically right-clicks the device collection and selects the option to create a device. Citrix documents this workflow as adding target devices to the database from the device collection.

Step 6: Assign the vDisk to the Target Device or Collection

Once the target device exists in the collection, assign the newly created vDisk.

The vDisk can be assigned to an individual target device or to devices within a collection. If more than one vDisk is assigned, the target may display a list of available disks during boot.

For a clean lab or production workflow, confirm that the correct vDisk is assigned and that the device is expected to boot from that image.

Step 7: Review the vDisk Properties

After the vDisk is created, review the vDisk properties.

Important items to check include:

The vDisk size.

The block size.

The access mode.

The cache type.

The vDisk assignment.

In the transcript, the instructor reviews the vDisk properties to confirm the size and block size. This is a useful validation step because it confirms that the vDisk was created as expected and gives the administrator visibility into the storage characteristics of the disk.

Step 8: Configure the vDisk Access Mode

After imaging, the vDisk may need to be placed into the correct mode.

For shared use by multiple target devices, the vDisk should typically be placed into Standard Image mode. Standard Image mode is read-only from the perspective of the base image, and each target device uses a write cache location for its changes. Citrix describes Standard Image mode as multi-device, read-only access with write cache options.

This is one of the major benefits of Citrix Provisioning. Multiple devices can boot from the same clean image while their individual writes are redirected to cache.

Step 9: Select the Write Cache Location

After setting the vDisk mode, select the write cache type.

The instructor discusses several options, including cache on the server, cache on device hard disk, and cache in device RAM with overflow to hard disk.

For most modern deployments, cache in device RAM with overflow to hard disk is usually the preferred design because it gives good performance while still providing disk overflow if the RAM cache fills. However, this requires a local disk on the target device.

If you choose a cache option that uses the target device hard disk, the VM normally needs an additional disk attached. In a virtual environment, that means editing the VM hardware and adding another virtual disk. That disk can then be used as the write cache location.

Step 10: Add a Second Disk if Using Local Disk Cache

If the design requires write cache on the target device hard disk or RAM with overflow to hard disk, the target VM needs a local disk available for that purpose.

In VMware, this would typically involve editing the VM settings and adding another hard disk to the master or template. The instructor explains that this is not performed in the lab, but shows where it would be done.

This additional disk can be used for the PVS write cache and, depending on the design, may also be used for other high-write locations such as logs or temporary data. If redirecting logs or other write-heavy paths, those changes should be handled carefully and tested before production use.

Lab Note: Cache on Server

In the instructor’s lab, cache on the server is used for demonstration purposes. This is acceptable for a lab, but it is generally not the best production design because it pushes write activity back to the Provisioning Server and increases network and server-side storage I/O.

For production, the better design is usually to keep write cache activity close to the target device by using RAM with overflow to local disk.

Validation Checklist

Use the following checklist after imaging a vDisk:

Validation Item	Expected Result
Imaging task completed	Imaging reports successful completion
vDisk exists in store	New vDisk files are present in the PVS store
vDisk appears in vDisk pool	vDisk is visible in the Citrix Provisioning Console
Master device lock cleared	Lock disappears after the master device is shut down
Boot order changed	Target device is configured to boot from the network
Target device exists	Device object is created in the correct collection
vDisk assigned	New vDisk is assigned to the target device or collection
Access mode configured	vDisk is placed in the correct mode, usually Standard Image
Write cache selected	Cache type matches the intended design
Local cache disk available	Additional disk exists if using local disk cache or overflow

Common Issues

vDisk Still Shows as Locked

If the vDisk still shows as locked, confirm that the master target device is shut down. Then refresh the vDisk pool. If the lock still remains, verify that no other device is connected to the vDisk.

Target Device Does Not Boot from the vDisk

Confirm that the device is set to boot from the network. Also verify that the target device exists in the correct collection, has the correct MAC address, and has the correct vDisk assigned.

Cache Configuration Is Missing or Incorrect

Review the vDisk properties and confirm that the access mode and cache type are configured correctly. If the cache type requires a local disk, verify that the target VM has an additional disk attached and that the disk is available to the operating system.

Server Cache Is Being Used Unexpectedly

If the environment is using cache on the Provisioning Server unintentionally, review the vDisk cache settings. Server-side cache can increase network utilization and server disk I/O, so it should usually be avoided unless there is a specific lab or design reason.

Conclusion

After a Citrix Provisioning imaging task completes, the work is not finished until the vDisk is validated, unlocked, assigned, and configured for the correct boot and cache behavior.

The main workflow is to confirm the vDisk exists in the store, shut down the master device to release the lock, configure the target device to boot from the network, create or verify the target device in the collection, assign the vDisk, set the correct access mode, and choose the appropriate write cache location.

For production designs, Standard Image mode with a properly sized write cache is usually the goal. In most modern environments, cache in device RAM with overflow to local disk provides the best balance between performance and stability.