Tag Archives: Provisioning Server

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

Advertisements

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

Sizing Windows 10 and Windows 7 Virtual Machines


After reviewing all of the scalability tests we conducted over the past few months, I thought it was time to revisit the recommendations for sizing Windows 10 virtual machines.  I also reached out to Nick Rintalan to see if this is in line with what is currently being recommended for production environments (if you disagree, blame him 🙂 ).

Win10Sizing

A few things you will notice

  1. Windows 7 and Windows 10 recommendations are similar.  Microsoft’s resource allocation for both operating systems are similar.  The Windows 10 and Windows 10 scalability tests resulted in similar numbers.
  2. Density – Experience: For some of the recommendations, there are 2 numbers. The first is if you are more concerned with server density and the second is if you are more concerned with the user experience.  What I find curious is if you have a heavy workload, are you as concerned with server density?
  3. PVS RAM Cache: Using the RAM cache will drastically reduce storage IOPS.  This will be critical to providing a good user experience and will be taken from the total allocated RAM.  The RAM column takes the RAM Cache numbers into account.
  4. Hypervisor: There is no hypervisor identified.  Testing showed minor differences between XenServer, Hyper-V and vSphere.

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

Microsoft Windows 10, Citrix XenDesktop and Logon Time


How long does your Windows 10 logon take?

Logging into my lab, my logons felt long. True I’m not using server-level hardware that you would see in production, but my logon times felt too long because I don’t have logon scripts, complex group policy preferences, or even massive profiles. After reading the Rule of 30 blog by Nick Rintalan, I decided to investigate. I was interested in knowing if all of the Windows 10 optimizations I previously blogged about would have an impact

  1. Default apps
  2. Services
  3. Scheduled tasks
  4. User Interface
  5. Runtime
  6. Release
  7. ICA

My first test was looking at the default Windows 10 install with Provisioning Services. It took 73.5 seconds to log in. So much for the Rule of 30.

I went ahead and permanently removed many of the default Windows 10 apps. I got a login time of 67 seconds. Not bad, 8% improvement.

Time to optimize and disable many Windows 10 services. Another drop of 6% reducing my login time to 62.5 seconds.

Scheduled tasks, user interface and runtime had no effect. This isn’t surprising. Runtime optimizations would only impact the user’s interactive portion of the session. Scheduled tasks don’t run constantly. They only run from a trigger resulting from an action or a time of day.

Next, I enabled Citrix User Profile Management (UPM) and saw a 29% improvement in logon time! Wow. Before I enabled UPM, the system used local profiles, which were deleted on each session logoff. Each time the user logged in, the system had to create a new profile for the user. This is time consuming. Enabling UPM gives the user a roaming profile, which is faster than a local profile.

And finally, because I love talking about Provisioning Services, I thought I would enable the RAM Cache with Disk Overflow. I didn’t really think it would have an impact, but that couldn’t be further from the truth. Provisioning Services RAM Cache dropped logon times by another 18%!

By optimizing my OS, profiles and using Provisioning Service RAM Cache, my logon times went from 73 seconds down to 36. Not bad.

Provisioning Services Read Cache


As you can see, I’ve spoken numerous time about the Provisioning Services RAM Cache with Disk Overflow capability.

  1. Windows 10 IOPS
  2. Video Proof
  3. Reducing IOPS to 1
  4. Read/Write Ratios
  5. XenDesktop 7.5 IOPS
  6. Digging deeper into IOPS
  7. ESG Spotlight on IOPS

So yes, I like talking about this topic.  But now, I’m going to talk about something very slightly different… Cache 🙂

While I was working on capturing some images for my Citrix Synergy 2016 Tech Update session, I saw something interesting.

I started my lab, started my Provisioning Services server and launched a Windows 10 virtual desktop.  According to the Provisioning Services agent on my virtual desktop, the desktop took almost 60 seconds to boot (Just so you know, I’m working on 7200RPM spinning disks in my meager home lab, so 60 seconds is expected).

First time boot

I then started a second Windows 10 VM, using the same Provisioning Service images.  Now look at the Provisioning Services agent.

Cached boot

 

Instead of an almost 60 second boot time on the first VM, the second VM booted in 14 seconds! WHAT?

Look even closer at the two images.  Look at the disk throughput.  4,400KB/sec vs 18,000KB/sec.

Sorry, but my cheap disks are not that fast. So what gives?

When you boot a Provisioning Services-based VM, the VM requests the disk image from the Provisioning Services server.  The Provisioning Services server reads portions of the disk and streams it across the network.  As the Provisioning Services server reads portions of the disk image, Windows automatically stores this information in RAM (system cache), if enough RAM is available.

So when we boot subsequent target devices that use the same disk image, we get a massive boost in performance as Provisioning Services uses the information in RAM instead of reaching out to slower storage.

As i said before, Cache is Good!

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