Tag Archives: pvs

XenServer PVS Accelerator Sizing – Part 2


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

  1. Impact of a larger cache size – Increase from 2GB to 4GB RAM cache
  2. Impact of applications
  3. 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

Advertisements

XenServer PVS Accelerator Cache Sizing


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)

Easy.

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

Improving Logon Time with PVS Accelerator


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

Provisioning Services 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

PVS vs MCS – Part 7: Summary


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 overall improvements in both solutions, the decision will mostly focus on a few core concepts explained in the previous blogs:

Five years ago, I created a decision tree helping you select the most appropriate solution.  Developing these previous six blogs helped me do the same thing based on the latest advancements.

CompareDid I miss any criteria?  Let me know

Daniel (Follow on Twitter @djfeller)
XenApp Advanced Concept Guide
XenApp Best Practices
XenApp Videos

 

 

PVS vs MCS – Part 6: Architecture


This is part of a series comparing Provisioning Services and Machine Creation Services

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 multiple geographical sites might not always be the correct architecture.

Imagine you have two major data centers, each hosting virtual desktops/apps.  You have XenApp and XenDesktop hosts in each data center.  Do you define zones for each data center and implement a single XenApp/XenDesktop environment or do you deploy two environments: one for each data center?

The correct answer is based on the unique characteristics of the organization and their risk tolerance. Risk sensitive organizations will want to reduce the size of their failure domain, resulting in two separate environments. If there is a catastrophic failure, it only impacts a portion of the environment.

If you follow this path, you need to devise a plan on how to replicate the master images between sites.

  • With Machine Creation Services, the admin must work in the hypervisor and export/import the master image  to the different sites and resource pools.
  • With Provisioning Services, the admin simply copies the image file to the other site. In fact, this is the same process many Provisioning Services admins already use to keep images synchronized across multiple servers. And to streamline this process, many admins create simple scripts to copy images when changes are detected.

Even though it is possible to keep images synchronized across multiple sites if you are using Machine Creation Services or Provisioning Services, I believe the simplicity of copying Provisioning Services image files gives it an edge for this criteria.

Sites

Daniel (Follow on Twitter @djfeller)
XenApp Advanced Concept Guide
XenApp Best Practices
XenApp Videos

PVS vs MCS – Part 5: On-Going Maintenance


This is part of a series comparing Provisioning Services and Machine Creation Services

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 update the Boot Device Manager file as well as updating the Provisioning Services Agent that we must take into account.

Boot Device Manager

If you assign the BDM file to each virtual machine, you need to ask yourself how you update the file if your Provisioning Services infrastructure changes?

Before the XenApp and XenDesktop 7.9 release, this often meant the admin must update each virtual machine. This is not a very good admin experience.  That experience drastically changed.

With three clicks of the mouse totaling about 15 seconds of time, the admin can update all target devices with an updated BDM file.

BDM Update

Provisioning Services Agent Update

Next, we have to concern ourselves with updating the Provisioning Services Agent contained within our master image file.  Unfortunately, treating an agent update like any other update to the image would result in a non-responsive system.

To utilize a PVS image, the virtual machine requires a constant network connection, but updating the PVS agent will result in the network going offline as the network drivers are updated.  Once the network drops, the VM can no longer function and the update never completes.

Historically, this process meant we had to do a process called reverse imaging where we take the network-streamed image file and rebuild a traditional virtual machine based on storage. This removed the constant network connection requirement, and allows the admin to update the agent successfully.

Although reverse imaging does work, it isn’t a very efficient admin experience for updating the PVS Agent. In the 7.9 release, the admin experience changed.

With 7.9, updating the PVS agent follows the same process as other updates. Look at how updating the PVS agent has changed over the past few PVS releases, taken from docs.citrix.com.

Updates

The image is too small to read the details, but look at the differences in the length of this process. The number of steps in this process has quickly decreased from multiple pages to just 2 lines.

Image Life Cycle

Certain organizations require image updates to go through multiple user acceptance testing deployment stages of

  • Development: Phase for the admin to make the necessary changes to the image
  • Test: Deployment to a small group of users to validate implemented changes
  • Production: Deployment too all users

The entire process should be accomplished without impacting the current production users.

Machine Creation Services image life cycle focuses on Development and Production.

Provisioning Services image life cycle focuses on Development, Test and Production.

Fast Image Update/Rollback

In addition to the image life cycle process, certain organizations require the ability to quickly roll out new updates and instantaneously rollback to a previous version. Unfortunately, mistakes will be made in an image update potentially resulting in issues for the users, requiring the admin to roll back to a previous version until the issue can be resolved.

If the issue impacts a mission critical component for the organization, the admin will need to roll back as fast as possible.

Machine Creation Services can roll out new image updates and rollback to previous versions. However, this process, is not instantaneous as a new version of the image must get cloned from the correct VM snapshot. The cloning process can take some time to complete.  The speed of this process is based on the underlying storage subsystem as well as any optimizations utilized within the hypervisors (VAAI/ODX as examples).

Provisioning Services, on the other hand, is able to rollout/rollback changes in the time it takes to reboot the virtual machines by using the vDisk version wizard.

Summary

So where does that leave us in the Machine Creation Services and Provisioning Services comparison?

UpdatesProvisioning Services does edge out Machine Creation Services with the ability to instantaneously update/rollback images and having a more traditional life cycle process focusing on development, test and production phases.

Daniel (Follow on Twitter @djfeller)
XenApp Advanced Concept Guide
XenApp Best Practices
XenApp Videos