The New XenApp – Reducing IOPS to 1

As we all know, IOPS are the bane of any application and virtualization project. If you don’t have enough, users will suffer. If you have too many, you probably spent too much money and your business will suffer. So we are always trying to find ways to more accurately estimate IOPS requirements as well as finding ways to reduce the overall number.

About 5 months ago, I blogged about IOPS for Application Delivery in XenDesktop 7.0. In the blog, I explained that for the XenApp workload, Machine Creation Services, when used in conjunction with Windows Server 2012 Hyper-V, required a significantly fewer number of IOPS than Provisioning Services. With the release of the 7.5 edition of XenApp and XenDesktop, I wanted to see what the latest numbers were on Windows Server 2012R2 Hyper-V while using the same LoginVSI medium workload. In addition, after reading Miguel Contreras’s blog on “Turbo Charging IOPS“, I wanted to see what impact the Provisioning Services “Ram Cache with Overflow to Disk” option would have on the results.

If you aren’t familiar with this caching option, it is fairly new and recently improved and I suggest you read Miguel’s blog “Turbo Charging IOPS“, to learn more. But essentially, we use RAM for the PVS write cache that will move portions to disk as RAM gets consumed, thus overcoming stability issues you would have with just a RAM Cache only option as the cache filled up. For this test, we allocated 2GB per XenApp VM. We only have 7 XenApp 7.5 VMs on the host, requiring 14GB total.

The results are impressive (at least to me they are).


On average, each XenApp 7.5 user requires 1 IOPS. If you want to be safe and go with the 95th Percentile, you have roughly 2 IOPS per user. We were able to achieve this without any complex configurations. We were able to achieve this without adding any new hardware to our servers. We were able to achieve this by literally flipping a switch within Provisioning Services. This is done with a little RAM and spinning disks only, no SSDs.

Some of you might also be wondering why MCS is lower than PVS (Disk Cache). This is one of the intrinsic benefits of MCS when deploying a Windows 2012R2 XenApp server on Windows Server 2012R2 Hyper-V. MCS is able to take advantage of the larger block sizes within the new .VHDX files, thus reducing IOPS requirements.

I keep hearing people say that Citrix needs to show some love to Provisioning Services as it is such a great product. I think the RAM Cache with Overflow to Disk helps.

Coming soon… VDI workloads as well as other hypervisors.

Virtual Feller’s virtual thoughts


One Imaging Solution to Rule Them All

As we all know, a single image management solution is extremely important in the VDI world. We will have hundreds or thousands of desktops that must be built and maintained. Image management is even more important when we have stateless desktops because we want our desktop to be reset to its original state after each user session. If you are doing stateless desktops without some form of image management in order to keep the desktops identical on initial startup, people would think you are crazy (and I think you would be).

What about RDS-based (session virtualization) implementations? I don’t hear much discussion on the need for image management with session virtualization. Is it because it is simply a common sense requirement that everyone already does or is it because people believe that you can get by without it?

Just in case it’s the latter, that’s take a trip in the “Wayback machine” (sorry, just saw Mr. Peabody and Sherman with my kids) to the 1990s and remember the world of WinFrame and MetaFrame and a world without single image management. We would build MetaFrame servers with Ghost, automated scripts and other deployment tools. They worked great. They let us build servers without having to sit in front of a screen all day hitting Next, Next, Next and did I mention Next. Deployment was easy. And then, a week or two later, you would start to hear the user complaints…

My app worked correctly yesterday, but it doesn’t today

Why is this different than it was yesterday?

Where did my add-on go?

This sucks. I hate it.

It all came down to a single reason, although our servers were built identically, they start to take on a unique persona once the server is turned on. And when users start connecting and doing things (work), the servers change more and more. Eventually, you begin to hear the users and life is no longer good if you are the IT Admin.

This was a major issue for every organization, which is why we have Provisioning Services. Regardless if your server is physical or virtual, they will be identical because Provisioning Services delivers a single image to every target. And Provisioning Services makes sure those targets remain consistent because on startup, each target starts at a clean state.

There are also some organizations that will want to extend their session virtualization environment to include VDI desktops. It only makes sense that your enterprise image management solution should be able to handle physical and virtual VDI, physical and virtual RDS and any other combination.

Before single image management solutions like Provisioning Services and Machine Creation Services came around, a user’s computing workspace was like a box of chocolates, you never knew what you were going to get.

Virtual Feller’s virtual thoughts