This feature is only supported when using XenServer with Citrix Virtual Desktops.
Intellicache is not supported for VMs using a GFS2 SR.
Using XenServer with IntelliCache makes hosted Virtual Desktop Infrastructure deployments more cost-effective by enabling you to use a combination of shared storage and local storage. It is of particular benefit when many Virtual Machines (VMs) all share a common OS image. The load on the storage array is reduced and performance is enhanced. In addition, network traffic to and from shared storage is reduced as the local storage caches the primary image from shared storage.
IntelliCache works by caching data from a VMs parent VDI in local storage on the VM host. This local cache is then populated as data is read from the parent VDI. When many VMs share a common parent VDI, a VM can use the data read into the cache from another VM. Further access to the primary image on shared storage is not required.
A thin-provisioned, local SR is required for IntelliCache. Thin provisioning is a way of optimizing the use of available storage. This approach allows you to make more use of local storage instead of shared storage. It relies on on-demand allocation of blocks of data. In other approaches, all blocks are allocated up front.
Thin Provisioning changes the default local storage type of the host from LVM to EXT4. Thin Provisioning must be enabled in order for Citrix Virtual Desktops local caching to work properly.
Thin Provisioning allows the administrator to present more storage space to the VMs connecting to the Storage Repository (SR) than is available on the SR. There are no space guarantees, and allocation of a LUN does not claim any data blocks until the VM writes data.
Thin-provisioned SRs may run out of physical space, as the VMs within can grow to consume disk capacity on demand. IntelliCache VMs handle this condition by automatically falling back to shared storage when the local SR cache is full. Do not mix traditional virtual machines and IntelliCache VMs on the same SR, as IntelliCache VMs can grow quickly in size.
IntelliCache must be enabled either during host installation or be enabled manually on a running host using the CLI.
We recommend that you use a high performance local storage device to ensure the fastest possible data transfer. For example, use a Solid State Disk or a high performance RAID array. Consider both data throughput and storage capacity when sizing local disks. The shared storage type, used to host the source Virtual Disk Image (VDI), must be NFS or EXT3/EXT4 based.
To enable IntelliCache during host installation, on the Virtual Machine Storage screen, select Enable thin provisioning. This option selects the host’s local SR to be the one to be used for the local caching of VM VDIs.
To delete an existing LVM local SR, and replace it with a thin-provisioned EXT3/EXT4 SR, enter the following commands.
These commands remove your existing local SR, and VMs on the SR are permanently deleted.
localsr=`xe sr-list type=lvm host=hostname params=uuid --minimal`
pbd=`xe pbd-list sr-uuid=$localsr params=uuid --minimal`
xe pbd-unplug uuid=$pbd
xe pbd-destroy uuid=$pbd
xe sr-forget uuid=$localsr
sed -i "s/'lvm'/'ext'/" /etc/firstboot.d/data/default-storage.conf
rm -f /var/lib/misc/ran-storage-init
systemctl restart storage-init.service
xe sr-list type=ext
To enable local caching, enter the following commands:
xe host-disable host=hostname
localsr=`xe sr-list type=ext host=hostname params=uuid --minimal`
xe host-enable-local-storage-caching host=hostname sr-uuid=$localsr
xe host-enable host=hostname
VM behavior with Intellicache
The VDI flag
on-boot dictates the behavior of a VM VDI when the VM is booted and the VDI flag
allow-caching dictates the caching behavior.
The values to use for these parameters depends on the type of VM you are creating and what its intended use is:
For shared or randomly allocated machines:
- Set the
- Set the
xe vdi-param-set uuid=vdi_uuid on-boot=reset allow-caching=true <!--NeedCopy-->
On VM boot, the VDI is reverted to the state it was in at the previous boot. All changes while the VM is running are lost when the VM is next booted. New VM data is written only to local storage. There are no writes to shared storage. This approach means that the load on shared storage is reduced. However the VM cannot be migrated between hosts.
Select this option if you plan to deliver standardized desktops to which users cannot make permanent changes.
- Set the
For static or dedicated machines:
- Set the
- Set the
xe vdi-param-set uuid=vdi_uuid on-boot=persist allow-caching=true <!--NeedCopy-->
On VM boot, the VDI is in the state it was left in at the last shutdown. New VM data is written to both local and shared storage. Reads of cached data do not require I/O traffic to shared storage so the load on shared storage is reduced. VM migration to another host is permitted and the local cache on the new host is populated as data is read.
Select this option if you plan to allow users to make permanent changes to their desktops.
- Set the
For VMs whose VDIs are located on a GFS2 SR, the VM on-boot behavior is different to VMs with VDIs on other types of SRs. For VDIs on a GFS2 SR, the on-boot option is applied on VM shutdown, not on VM boot.
Implementation details and troubleshooting
Q: Is IntelliCache compatible with live migration and High Availability?
A: You can use live migration and High Availability with IntelliCache when virtual desktops are in Private mode, that is when
A VM cannot be migrated if any of its VDIs have caching behavior flags set to
allow-caching=true. Migration attempts for VMs with these properties fail.
Q: Where does the local cache live on the local disk?
A: The cache lives in a Storage Repository (SR). Each host has a configuration parameter (called local-cache-sr) indicating which (local) SR is to be used for the cache files. Typically, this SR is an EXT3/EXT4 type SR. When you run VMs with IntelliCache, you see files inside the SR with names
uuid.vhdcache. This file is the cache file for the VDI with the given UUID. These files are not displayed in XenCenter – the only way of seeing them is by logging into dom0 and listing the contents of
Q: How do I specify a particular SR for use as the cache?
A: The host object field
local-cache-sr references a local SR. You can view its value by running the following command:
xe sr-list params=local-cache-sr,uuid,name-label
This field is set either:
After host installation, if you have chosen “Enable thin provisioning” option in the host installer, or
xe host-enable-local-storage-caching host=host sr-uuid=sr. The command requires the specified host to be disabled. Shut down the VMs when you use this command.
The first option uses the EXT3/EXT4 type local SR and is created during host installation. The second option uses the SR that is specified on the command-line.
These steps are only necessary for users who have configured more than one local SR.
Q: When is the local cache deleted?
A: A VDI cache file is only deleted when the VDI itself is deleted. The cache is reset when a VDI is attached to a VM (for example on VM start). If the host is offline when you delete the VDI, the SR synchronization that runs on startup garbage collects the cache file.
The cache file is not deleted from the host when a VM migrates to a different host or is shut down.