Citrix Provisioning Services is one of those components I love to sit down and play with to try and make operations such as vDisk booting faster. Since the release of Citrix PVS 7.7 there has been a few great enhancements that we can easily implement today to achieve better all-round performance with vDisks and Target Device VMs.
One of the first things we can make use of are VHDX vDisks. VHDX first came to the world in Windows Server 2012 Hyper-V. Citrix PVS historically used the VHD format for vDisks and brought out support for VHDX with PVS 7.7. The VHDX format has several advantages over VHD such as better performance, protection against file corruption and larger disk size limits.
The second improvement is support for UEFI Virtual Machines. UEFI is the replacement to traditional BIOS machines and is supported on Operating Systems running Windows Server 2012 and Windows 8 upwards. UEFI support was introduced to PVS in version 7.7 and allows for faster vDisk boots by making use of gigabit network speeds. Previously with Hyper-V running PVS 7.6 and below, older OS i.e. Windows Server 2008 R2 had to be created as a Generation 1 Virtual Machine. This required using the Legacy NIC, capped at 100Mbps to PXE boot in to a vDisk.With Hyper-V 2012 R2 and PVS 7.7+ you can use Generation 2 VMs with a Synthetic NIC to PXE boot. Not only do you have this NIC advantage but UEFI is also enabled on Generation 2 VMs for faster boot! Keep in mind that UEFI is only supported on Windows Server 2012, Windows 8 OS and above. To read more about Generation 1 VMs with Citrix read https://jgspiers.com/citrix-pvs-synthetic-nic-streaming-with-hyper-v/
The third is ReFS v2. ReFS (Resilient File System) was originally introduced with Windows Server 2012 to overcome some of the issues that exist with NTFS. When comparing performance against NTFS there wasn’t a great deal of difference. ReFS v2 was released with Windows Server 2016 and provides better provisioning (creation) and merging performance. Take for example merging checkpoints (snapshots) and backups that use checkpoints, or when you create a fixed VHDX, these operations benefit largely from ReFS. PVS 7.11 is Server 2016 ready and does support ReFS for your vDisk stores. Using ReFS to support your vDisk stores gives insanely quick merging vDisk times.
So, how about some examples of these optimisations?
Firstly, let’s compare UEFI vs BIOS machine boots to PVS vDisks. The below machine WS2012R2NonUEFIVHD is a Hyper-V Generation 1 machine that uses both BIOS to boot and boots in to a VHD formated vDisk.
And WS2012R2UEFIVHDX is a Generation 2 UEFI enabled machine and boots in to a VHDX formatted vDisk. 
The Generation 1 machine has two vNICs added. One Legacy NIC for the boot process and a Synthetic NIC which takes over streaming once the Virtual Machine is running off the vDisk stream. 
Just to confirm the UEFI machine needs to have Secure Boot disabled as PVS cannot support Secure Boot enabled machines (unless you are using XenApp 7.12+). Also these two Virtual Machines will use a BDM ISO to receive the bootstrap. The UEFI machine has a UEFI enabled BDM ISO which is a supported boot method in PVS 7.9+.
The first boot shows the BIOS machines booting in to a VHD vDisk. 24 seconds, not too bad at all. 
12 seconds for the UEFI machine booting in to a VHDX vDisk! That is half the time than the BIOS machine took. Notice the throughput is also twice as much.
Next we can look towards ReFS for vDisk merging times. On a Windows Server 2016 box with an unformatted partition that will act as your PVS vDisk store, choose ReFS as the file system when formatting the partition.
Now we have storage partitioned with ReFS, and vDisks will be placed on this storage.
The first test is merging a 2GB differencing disk to the base vDisk using NTFS storage. Both VHDX and VHD vDisks do not experience much of a difference in merging times, VHDX being slightly faster.
The second test is merging a 2.7GB differencing disk to the base vDisk on ReFS storage. The VHDX version is much quicker than the VHD vDisk. The time it took to merge a VDHX disk was an incredible 4 seconds! The time is took for the VHD disk was 2 minutes. 
4 seconds merge time for VHDX disk. 
Also, read up on this blog post https://www.citrix.com/blogs/2016/01/12/turbo-charging-boot-times-with-pvs-7-7/ from Nick Rintalan which explains how using 2vCPUs on PVS 7.7+ Target Devices can again boost performance due to the PVS driver now being multi-threaded. By simply adding a second vCPU to my Target Device I was able to shave another 3 seconds off boot time and down to single digits.
Jared Hamilton
September 10, 2019Hey George!
I know this is quite an old post so hopefully, you monitor and will respond! First off thank you very much for what you contribute to the community. It is people like you for whom I have learned very much from.
I wanted to inquire if you have tested using REFS for the target devices write cache disk and if that has provided any performance gains? I am just starting to research the subject as we are doing many Windows 10 deployments using PVS. Please let me know. Thanks again!!!
George Spiers
September 29, 2019Hey – Write Cache disks do not work on ReFS yet.
Michael
March 25, 2021We are using ReFS for several months now, but currently we are facing big performance issues when merging or booting images. At the beginning it took only few seconds for merging an image and now it takes several minutes. Have you ever experienced something like that?
OS: Server 2019
PVS 1912 LTSR CU2
Thomas
January 5, 2024Hello George,
While the post about ReFS may be a bit dated, I hope you’re still keeping an eye on responses. 🙂
I’d like to share something regarding my PVS system:
Here’s the scenario:
Our customer utilizes two Windows Server 2022 machines, each with its own system disk, and a 900 GB disk dedicated to storing vhdx and avhdx files (Citrix PVS).
On the first server, new VHDX/AVHDX files are consistently created or modified on the 900 GB volume. Subsequently, a script is executed on the first server to copy these vhdx/avhdx files to the second server.
While the files are identical on both servers, there’s an interesting observation:
On the first server, where the VHDX files are initially created, disk space is calculated as follows:
vDisk Folder (770 GB –> 72 Files)
ReFS Volume of the vDisk (900 GB –> 401 GB free space) – we’re not using Deduplication
Conversely, on the second server, where the VHDX files are received:
vDisk Folder (770 GB –> 72 Files)
ReFS Volume of the vDisk (900 GB –> 119 GB free space) – Deduplication is not in use
I’m not very familiar with ReFS, but is it considered normal for the free space to be significantly higher on the first PVS Server?
We only initiate the creation of new vDisks or the generation of new merged bases exclusively on the first PVS Server.