What does PVS-Accelerator Accelerate?
One of the new features of XenServer 7.1, as mentioned here previously, is PVS Accelerator. While Citrix already have Project Accelerator a free tool to assist with virtualisation project delivery - this is different. PVS Accelerator came from Project Diamond, part of Citrix's Better Together strategy, the PVS and XenServer teams developed a way to assist with simplifying and enhancing Citrix XenApp and XenDesktop deployments.
From the PVS documentation:
PVS-Accelerator enables a PVS proxy to reside in Dom0 (XenServer's Control Domain) on a XenServer host where streaming of a PVS vDisk is cached at the proxy before being forwarded to the VM. Using the cache, subsequent booting (or any IO requests) of the VM on the same host can be streamed from the proxy rather than streaming from the server over the network. Using this model, more local resources on the XenServer host are consumed, but streaming from the server over the network saves resources, effectively improving performance.
That's a lot of words for sure. I like Dan Feller's succinct sentence:
At a base level you'll need XenServer 7.1 (with the associated supplemental pack) and Provisioning Service 7.13 for this feature and this feature is only available in XenServer.
What is the impact on your services by deploying the PVS Accelerator? What should you watch out for - could something go wrong?
Citrix PVS Accelerator - How Does It Work?
At a base level you'll need XenServer 7.1 (with the associated supplemental pack) and Provisioning Service 7.13 for this feature and this feature is only available in XenServer.
1. Your XenServer hosted VM boots, with the request to the PVS service going through the host's vSwitch which passes it onto the PVS Accelerator
2. The PVS Accelerator checks to see if it has a copy of the data held locally. The data store is a proprietary format – in essence it’s a combination of the disk blocks together with a bitmap that indicates whether a block is available in the cache. The storage size could be up to 2TB as a file, if you're using Memory only note given the control domain memory is restricted to 64G, which would leave up to 60GB for memory cache. Citrix recommends that you allocate at least 5GB of cache space per vDisk version that will be actively used on.
3. If the data is held locally, it is passed back to the VM via the vSwitch - no need to communicate with the PVS server
4. If the data is not held locally, the request is passed to the PVS server. When the data is returned it is saved in the PVS Accelerator's cache.
5. The PVS server will read the data from disk (or more likely the file cache) and pass the data back.
Net impact should be lower network utilisation, faster boot times and a higher provisioning services server density. Arguably this is going to be of greater advantage where you haven't got 10Gbe networking dedicated to image delivery - but that in itself is common.
There's a video on this here
PVS Accelerator Setup
You may have upgraded to 7.1; but to enable PVS Accelerator functionality, you'll need the supplemental pack. Instructions for configuring the PVS Accelerator are here for PVS, and here for XenServer.
There appeared to be no need to reboot a XS host to enable the new functionality. However the PVS Accelerator can either use Control Domain RAM and disk (Cache on SR and Memory), or Control Domain RAM only (Cache in Memory only). You'll need at least 4GB RAM configured to enable the functionality - so it may be that you need to reboot your hosts to Increase Dom0 RAM (which is now available in the XenCenter) before you can fully deploy this new feature.
You'll note you can have different cache sizes for each host: for a PVS site hosts within the pool don't all have to have the same cache configuration. If you want to change the values, you need to shutdown the VMs that are using the existing cache. For notes on cache storage considerations see KB CTX220742
PVS Accelerator Deployment
Enabling the functionality is simply a matter of checking the "Enable PVS Accelerator for all VMs" option while running the deployment wizard.
What you may want to be wary of - for the first configuration, once you've assigned a link in your PVS environment to the configuration (as shown) below, it doesn't appear to be a simple process to change that: be descriptive with your site names to avoid confusion.
What you will notice, once the configuration is correct, is that as the VMs boot, each VMs cache status changes (as shown below). If this is not happening; validate you checked the Enable PVS Accelerator option, and that the Control Domain RAM is at least 4GB.
PVS Accelerator Impact
This is from the perspective of the PVS server (2vcpu, 8GB RAM) running a 1GB NIC to a XenServer host. This is a Windows 7 image. I'm testing time to boot (i.e. I'm booting 50 VMs at the same time and then waiting until all VMs report that the management agents are available). I'm either using RAM directly, or I'm using a local disk resource (in this case an Atlantis SiM volume)
If we look at disk IO for the streaming service - this is it with no cache:
Fairly steady - for those who want to know, cache utilisation was in the 93-95%. This is the same graph using cache
Some initial activity, then it pretty much drops off. However, note the scale changes here. If we put the scale on the "before" graph to be the same we get this:
Which is jolly interesting.
PVS Accelerator - Is it useful?
If we consider this in the context of PVS Accelerator overcoming network latency - absolutely. With cache enabled there is a significant drop in network utilisation and disk I/O on the PVS host at a cost of some disk space, and memory on each of your XenServer hosts. If you haven't yet moved to a dedicated 10Gbe network for your PVS hosts, this functionality is going to help drive performance for VMs - shown here to be especially helpful during boot.
That still leaves a consideration of "what is the general impact"from a user experience point of view?". PVS Accelerator isn't going to write I/O demand on the PVS instances, so testing with I/O meter and expecting a drop in I/O for a VDI IOMeter test won't give significant changes. That said, Dan Feller has done some testing on this showing improvement of logon times with PVS Accelerator, which looks helpful, although I've not had a chance to look at that directly. If I've got a lot of activity for PVS enabling this is going to drive extra measurable performance likely without spending any additional money on infrastructure.
There's wider consideration of "how many images do I need to cater for" in terms of sizing and locating the cache, and understanding that there will be some Dom0 RAM used to which may reduce density depending on how much you've reserved (you're going to take a couple GB so its not going to be massive per host, but still, something to consider).
That said, from the figures shown, definitely worth making the change as you test out your XS performance. I'd be interested to hear other's findings.
