Virtual disks
Virtual disks are managed throughout their lifecycle. Full image lifecycle takes a virtual disk from creation, through deployment and subsequent updates, and finally to retirement. The lifecycle of a virtual disk consists of four stages:
- Creating
- Deploying
- Updating
- Retiring
Creating a virtual disk
Creating a virtual disk includes:
- preparing the master target device for imaging
- creating and configuring a virtual disk file where the virtual disk resides
- imaging the master target device to that file
These steps result in a new base virtual disk image. This process can be performed automatically, using the Imaging Wizard, or manually. You can also create a common image for use with a single target platform or for use with multiple targets. For details, see Creating vDisks.
Deploying a virtual disk
After a virtual disk base image is created, it is deployed by assigning it to one or more devices. A device can have multiple virtual disk assignments. When the device starts, it boots from an assigned virtual disk. There are two boot mode options; Private Image mode (single device access, read/write), and standard image mode (multiple devices, write cache options). For more details, see Prerequisites for deploying vDisks later in this article.
Updating a virtual disk
It is often necessary to update an existing virtual disk so that the image contains the most current software and patches. Updates can be made manually, or the update process can be automated using virtual disk Update Management features. Each time a virtual disk is updated a new version is created. Different devices can access different versions based on the type of target device and version classification. A maintenance device can have exclusive read/write access to the newest maintenance version. Test devices can have shared read-only access to versions classified as test versions. Production devices can have shared read-only access to production versions. Versions are created and managed from the vDisk Versioning Dialog. An update can also be the result of merging versions. For more details on updating virtual disks, see Updating virtual disks.
Retiring a virtual disk
Retiring a virtual disk is the same as deleting. The entire VHDX chain including differencing and base image files, properties files, and lock files, are deleted. For details, see Retiring or deleting virtual disks.
Note:
In addition to those virtual disk tasks performed within a disk’s lifecycle, there are also other virtual disk maintenance tasks that can be performed. These include importing or exporting the virtual disk, backing-up vDisks, replicating, and load balancing.
Prerequisites for deploying virtual disks
Virtual disks are configured before being deployed. Configuration tasks include:
- Selecting the virtual disk access mode and if applicable, the write cache mode. See Selecting the write cache destination for standard virtual disk images).
- Configuring the virtual disk for Microsoft Volume Licensing. For details, see Configuring a virtual disk for Microsoft Volume Licensing.
- Enabling Active Directory machine account password management, if applicable.
- More settings:
- Enabling or disabling the streaming of this virtual disk to assigned target devices. For details, see the vDisk Properties dialog.
- Providing virtual disk identification information. For details, see identification information in the vDisk Properties dialog.
Selecting the write cache destination for standard virtual disk images
Citrix Provisioning supports several write cache destination options. The write cache destination for a virtual disk is selected on the General tab, which is available from the virtual disk File Properties dialog.
Considerations and requirements
- Consider the impact of using the server-side persistent write cache. Persistent cache is only used where unauthorized users have access to a machine. Ensure that machines are not shared among users.
- When selecting cache on local hard drive, ensure that the hard-disk drive is formatted with NTFS for Window devices, with a minimum of 500 MB.
- When selecting cache on the target device RAM and standard image mode, the registry setting WcMaxRamCacheMB (a DWORD) in the BNIStack Parameters determines the max size of the RAM write cache. If the registry entry does not exist, then the default value used is 3584 MB.
- Citrix Provisioning version 7.7 only supports the use of Microsoft System Center Configuration Manager (ConfigMgr) Client as follows:
| ConfigMgr Client | Cache on device hard drive | Cache in device RAM with overflow on hard disk | Cache in device RAM |
|---|---|---|---|
| ConfigMgr 2012 | Supported | Supported | Not supported |
| ConfigMgr 2012 SP1 | Supported | Supported | Not supported |
| ConfigMgr 2012 R2 | Supported | Supported | Not supported |
| ConfigMgr Client | Cache on server | Cache on server persisted | Cache on device hard drive persisted |
|---|---|---|---|
| ConfigMgr 2012 | Not supported | Not supported | Not supported |
| ConfigMgr 2012 SP1 | Not supported | Not supported | Not supported |
| ConfigMgr 2012 R2 | Not supported | Not supported | Not supported |
The following sections describe all valid write cache destination options.
Note:
Provisioning Services version 7.12 introduced Linux streaming. When using this feature, consider that caching options on a Linux target device are the same on a Windows device. For more information about Linux streaming, see Installation.
Cache on device hard drive
Write cache can exist as a file in NTFS format, or on the target-device’s hard drive. This option frees up the server. It does not process write requests because it does not have the finite limitation of RAM.
The hard drive does not require any additional software to enable this feature.
Note:
The write cache file is temporary unless the virtual disk mode is set to Private Image mode.
Important:
The virtual disk cache type field Cache on device hard drive is deprecated and will be removed in a future release. Citrix recommends using one of the other available cache types. For more information, see the Deprecation article.
Cache on device hard drive persisted (experimental phase only)
The same as Cache on device hard drive, except cache persists. This write cache method is an experimental feature and is supported only for NT6.1 or later. This method also requires a different bootstrap. To click the correct bootstrap from the console, right-click on the provisioning server, select Configure Bootstrap. On the General tab, click the Bootstrap file option, then choose CTXBP.BIN. Citrix recommends that the local HDD (client side) drive has enough free space to store the entire virtual disk.
Important:
The virtual disk cache type field Cache on hard drive persisted is deprecated and will be removed in a future release. Citrix recommends using one of the other available cache types. For more information, see the Deprecation article.
Cache in device RAM
Write cache can exist as a temporary file in the target device’s RAM. It provides the fastest method of disk access since memory access is always faster than disk access.
Cache in device RAM with overflow on hard disk
Write cache uses the VHDX differencing format:
- When RAM is zero, the target device write cache is only written to the local disk.
- When RAM is not zero, the target device write cache is written to RAM first. When RAM is full, the least recently used block of data is written to the local differencing disk to accommodate newer data on RAM. The amount of RAM specified is the non-paged kernel memory that the target device consumes.
Compared to “Cache on device hard drive” cache mode, the VHDX block format has a faster file expansion rate. The local disk free space is reconsidered to accommodate the streaming workload. To ensure target device reliability in a high demand workload, Citrix recommends that local disk free space is larger than virtual disk capacity size.
When the local disk is out of space, the target device virtual disk I/O goes in to a pause state. It waits for more local disk free space to become available. This condition has a negative impact on the workload continuity. Citrix recommends allocating enough local disk free space.
The amount of RAM specified does not change the local disk free space requirement. The more RAM assigned, the more virtual disk I/Os temporarily saved in RAM cache before all data gets flushed back to the VHDX file. The RAM reduces the initial VHDX expansion rate.
Cache on a server
Write cache can exist as a temporary file on a provisioning server. The Provisioning server handles all writes, which can increase disk I/O and network traffic.
For extra security, the server can be configured to encrypt write cache files. Since the write-cache file does exist on the hard drive between reboots, the data is encrypted in the event a hard drive is stolen.
Cache on server persistent
This cache option allows for the saving of changes between reboots. Using this option, after rebooting, a target device is able to retrieve changes made from previous sessions that differ from the read only virtual disk image. If a virtual disk is set to Cache on server persistent, each target device that accesses the virtual disk automatically has a device-specific, writable disk file created. Any changes made to the virtual disk image are written to that file, which is not automatically deleted upon shutdown.
The file name uniquely identifies the target device by including the target device’s MAC address and disk identifier. A target device can be assigned to multiple vDisks and therefore have multiple cache files associated to it.
To restore a virtual disk that uses Cache Persistent on Server, be sure to back up all virtual disk files and associated user cache files before making changes.
The benefits of using this cache option include:
- Saves target device specific changes that are made to the virtual disk image.
- Same benefits as standard image mode.
The drawbacks of using this cache option include:
- The cache file is available so long as the file remains valid. Any changes made to the virtual disk force the cache file to be marked invalid. For example, if the virtual disk is set to Private Image Mode, all associated cache files are marked invalid.
Note:
Cache files that are marked as invalid are not deleted. Periodically, these files are manually deleted.
Invalidating changes include:
- Placing a virtual disk in maintenance
- Virtual disk is placed in private image mode
- Mapping the drive from the Citrix Provisioning console
- Changing the location of the write cache file
- Using the automatic update
Tip:
Consider the impact of using a server-side persistent write cache. Persistent cache is only used where unauthorized users have access to a machine. Ensure that machines are not shared among users.
In this article
- Creating a virtual disk
- Deploying a virtual disk
- Updating a virtual disk
- Retiring a virtual disk
- Prerequisites for deploying virtual disks
- Selecting the write cache destination for standard virtual disk images
- Cache on device hard drive
- Cache on device hard drive persisted (experimental phase only)
- Cache in device RAM
- Cache in device RAM with overflow on hard disk
- Cache on a server
- Cache on server persistent