As you might have read, I recently ran a few XenServer PVS Accelerator tests to determine a starting point for the cache size. This initial investigation looked at Windows 10 and Windows 2012R2 for boot and logon operations.
Looking back, I determined that I want to include three additional items
- Impact of a larger cache size – Increase from 2GB to 4GB RAM cache
- Impact of applications
- Impact of Windows 2016
Before I get into the results, let me explain the graphs.
- The blue, green and orange line denotes boot, logon and steady state operations. The first time those colors appear depicts the first VM; the second time the colors appear depicts the second VM. These colors are linked to the axis on the right showing percent of cache used.
- The solid red area graph depicts the amount of network traffic sent from the Provisioning Services server to the host. The line should initially be large and then diminish as the cache is used. It is linked to the left axis with bytes per second.
With that understanding out of the way, let’s look at the results.
Continue reading “XenServer PVS Accelerator Sizing – Part 2”
How large should we make our PVS Accelerator cache? Too large and we waste resources. Too small and we lose the performance.
Let’s take a step back and recall our best practice for sizing the RAM on Provisioning Services. We would typically say allocate 2GB of RAM for each vDisk image the server provides. This simple recommendation gives the PVS server enough RAM to cache portions of the image in Windows system cache, which reduces local read IO. So for a PVS server delivering
- 1 image: we would allocate 2GB of RAM (plus 4GB more for the PVS server itself)
- 2 images: we would allocate 4GB of RAM (plus 4GB more for the PVS server itself)
- 4 images: we would allocate 8GB of RAM (plus 4GB more for the PVS server itself)
Let’s now focus on the XenServer portion of PVS Accelerator. If we use RAM as our PVS Accelerator cache, how many GB should we allocate?
Continue reading “XenServer PVS Accelerator Cache Sizing”
The title is correct. We can improve user logon time by implementing PVS accelerator in XenServer 7.1.
This actually makes perfect sense.
We already showed that PVS Accelerator drastically improves VM boot times because portions of the master vDisk image are cached locally. Booting a VM equates to roughly 80% reads and 20% writes. VMs using the same image are reading the same blocks of data. Due to this similarity, we are able to see huge network utilization reductions by using the PVS Accelerator cache. These reductions in the network utilization translates into faster boot times.
But what about logon time?
Continue reading “Improving Logon Time with PVS Accelerator”
An interesting new feature was included with the XenServer 7.1 release: Provisioning Services Accelerator.
In a single sentence,
PVS Accelerator overcomes PVS server and network latency by utilizing local XenServer RAM/Disk resources to cache blocks of a PVS vDisk to fulfill local target VM requests.
Take a look at the demo video to see:
Continue reading “Provisioning Services Accelerator”
As Q said in the final episode of Star Trek: The Next Generation, “All good things must come to an end” and after 6 previous blogs focusing on deciding between Provisioning Services and Machine Creation Services, it is time to end. As I explained, over the past 5 years, improvements were made to Provisioning Services and Machine Creation Services. While Provisioning Services simplified deployment and maintenance, Machine Creation Services improved performance and delivery capabilities. Five years ago, if someone had to decide between the two, most likely the answer would be Provisioning Services. But now in 2016, because of the … Continue reading PVS vs MCS – Part 7: Summary
This is part of a series comparing Provisioning Services and Machine Creation Services Part 1: Resource Delivery Options Part 2: Scalability Part 3: Storage Optimization Part 4: Deployment Part 5: On-going Maintenance Part 6: Architecture Part 7: Summary In the previous blogs comparing PVS with MCS, I focused on functionality within each technology, but this time I’m focusing on how easy is it to manipulate. Consider the following: A single XenApp/XenDesktop (including Machine Creation Services) architecture can span multiple geographical sites. A single Provisioning Services architecture can span multiple geographical sites. However, having a single XenApp/XenDesktop/Provisioning Services farm span across … Continue reading PVS vs MCS – Part 6: Architecture
This is part of a series comparing Provisioning Services and Machine Creation Services Part 1: Resource Delivery Options Part 2: Scalability Part 3: Storage Optimization Part 4: Deployment Deploying Machine Creation Services is extremely easy as there is nothing to deploy. Deploying Provisioning Services is easier with Hyper-V Gen2 VM support and the single-stage Boot Device Manager. This sounds great, but what about on-going maintenance? (something many fail to consider) Overall, the update process for both imaging technologies are simple to perform through the respective consoles. However, with Provisioning Services, there have historically been some special considerations in order to … Continue reading PVS vs MCS – Part 5: On-Going Maintenance