Tag Archives: hyper-v

PVS vs MCS – Part 4: Deployment


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

So far, the latest analysis between Machine Creation Services and Provisioning Services included within XenApp and XenDesktop 7.9 has only focused on how Machine Creation Services has improved, but what about Provisioning Services?  Has anything been improved?

Most definitely! Especially around simplifying the deployment of Provisioning Services.

Hyper-V

Previously, Provisioning Services supported Hyper-V, or to be more specific, with generation 1 Hyper-V virtual machines. However, generation 1 Hyper-V virtual machines do not support PXE boot unless the VM utilizes the legacy network adapter.  Unfortunately, the legacy network adapter is not as efficient as the standard (synthetic) network adapter.

To get Provisioning Services to work with Hyper-V while taking advantage of the optimized synthetic network adapter, each virtual machine would require two separate network adapters. This configuration gets confusing, including the use of multiple IP addresses.

With the XenApp and XenDesktop 7.9 release, Provisioning Services supports Hyper-V generation 2 virtual machines.  And unlike generation 1 VMs, generation 2 VMs support PXE booting with the standard (synthetic) network adapter.

Now, each virtual machine only requires a single NIC. This is a huge improvement in simplicity.

Boot Options

Booting a PVS target device is easy in a lab environment where you have total control over DHCP and can easily set DHCP options 66 and 67 to the Provisioning Services TFTP server and boot file. But when we move into production, the network team is rarely as accommodating.

This led many of us to deploy the Boot Device Manager (BDM), which is a small boot file deployed as an .ISO file and attached to each target device. This worked great as we no longer required the configuration of those pesky DHCP options.

However, the BDM file was considered a 2-stage boot process because even though this BDM file contained the boot image, it did not contain the Provisioning Services boot drivers needed to complete the process and sign into the Provisioning Services server.  This meant we still needed a TFTP server. It meant we still needed TFTP IP helpers if we spanned multiple subnets.

Did you know that the BDM file was improved. It is now a single-stage BDM file. The ISO file attached to the target machines contains the boot file and the Provisioning Services boot drivers, eliminating the need for the Provisioning Services TFPT server.

Again, simplifying initial deployment.

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

SimpleI consider it to be even. Although Provisioning Services requires us to install the Provisioning Services server, the process is straight forward.  The complexity with Provisioning Services deployment was for Hyper-V environments and setting up the DHCP/TFTP options.

With the support for Gen 2 virtual machines on Hyper-V and a single stage boot device manager, the world of Provisioning Services is much easier to deploy.

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

Advertisements

Sizing XenApp Windows 2012R2 Virtual Machines


I guess I’m not done yet.

Last week, I posted the latest recommendations on sizing Windows 10 and Windows 7 virtual machines for a XenDesktop environment.  I received a few replies from people asking for any updates regarding Windows 2012R2.

Unfortunately, when we discuss Windows 2012R2 and XenApp, the recommendations are not as straightforward as Windows 10 and Windows 7.

  1. Because Windows 2012R2 will do session virtualization (where many users share the same VM but get a separate session) it makes sizing CPU and RAM more difficult.
  2. Because we can publish multiple resources from the same VM, we can have a mix of light, medium and heavy users on the same VM at the same time.
  3. Because each VM will host multiple users, our VMs will be sized larger when compared to Windows 10 and Windows 7. To size correctly, we need to align our recommendations with the nuances of the hardware.

Let’s take a look at the latest recommendations before we go into more detail.

Win12RwSizingvCPU

For vCPU, you notice it is based on NUMA.  What is NUMA?  I recommend you read these two blogs by Nick Rintalan.

  1. An intro to NUMA
  2. A Discussion about Cluster on Die

To summarize, you get the best physical server density when you have the same number of vCPU for your XenApp VMs with either the number of cores within a NUMA node or 1/2 of a NUMA node.  If you go with 1/2 of a NUMA node, then you will just have two times as many VMs.

Cluster on Die is a little more complex as newer hardware chips don’t have equal sized NUMA nodes across cores.  Cluster on Die is a BIOS option that balances cores equally by creating clusters of cores.

RAM

Sizing RAM is also a little different than when comparing it to Windows 10 and Windows 7. With session virtualization, like XenApp, all users share the same OS instance. Users also share the same application instances. The OS and app instances only consume RAM once. That is a huge reduction in overall RAM usage, which is why the RAM recommendations are significantly lower than the desktop OS.

Of course, the amount of RAM you allocate is going to be based on the specifics of your applications.

PVS RAM Cache

Just like with Windows 10 and Windows 7 recommendations, the PVS RAM cache is extremely valuable in a Windows 2012R2 XenApp environment.  With PVS RAM Cache, we see huge reductions in IOPS for Windows 2012R2.

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

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

XenDesktop 7.7 and Windows 10


The other day, I was able to share the latest single server density results when running Windows 7 on XenDesktop 7.7. We looked at a range of parameters like:

      • PVS vs MCS
      • PVS Disk Cache vs RAM Cache
      • Citrix Policies: Very High Definition vs High Server Scalability vs Optimized for WAN
      • Windows 7 optimizations

Once that testing was complete, we moved onto the next version… Windows 10. An again, looking at the exact same parameters.

First, we look at Microsoft Hyper-V 2012R2

HVwin10

Second, we look at Citrix XenServer 6.5 SP1

xswin10

What do you notice?

Between XenServer & Hyper-V… Not much

Between MCS and PVS… Not much as the 5-6% gains in MCS would be offset by increased storage costs due to lack of RAM Caching capabilities

Between the different policies… Around a 7-8% improvement

Between OS optimizations… Around a 7% improvement

The last part I find very interesting.

If you recall, I recently posted a blog (Windows 10 Optimization: The Results) showing that the Optimized OS config, based on the numerous Windows 10 optimizations, showed a 20% improvement in density. As we look at this expanded series of tests, what I now see is something rather interesting. Simply utilizing the Citrix policy templates, we achieve 1/2 of that density gain.

And I can tell you from experience that implementing the Citrix policies are much easier than working through all of those Windows 10 optimizations

So my advice, definitely use the Citrix policy templates as your starting point. If you want to know more about them, I suggest the following:

Server Specs:

      • Processors: Dual Intel Xeon E5-2697 (12 cores each)
      • RAM: 384 GB
      • Workload: Knowledge Worker
      • VM Specs: 2vCPU, 4 GB RAM

 

Daniel (Follow @djfeller)

XenApp Best Practices

XenApp Videos

 

 

 

 

 

 

XenDesktop 7.7 and Windows 7


We recently completed a massive round of testing looking at many of the different deployment configurations we can do with a Windows 7 desktop in XenDesktop 7.7. We wanted to look at how different factors might impact single server scalability.

  • PVS vs MCS
  • PVS Disk Cache vs RAM Cache
  • Citrix Policies: Very High Definition vs High Server Scalability vs Optimized for WAN
  • Windows 7 optimizations

Each test was conducted utilizing the same, knowledge worker workload.

Win7

 

xs

As you see, each test builds upon the previous test while only modifying a single parameter. As I’ve gone through the initial results, some things quickly popped out at me:

  1. Machine Creation Services, from a purely single server scalability perspective, shows some impressive numbers.
  2. Enabling the RAM Cache feature within Provisioning Services gave us a 9% gain in server density.
  3. Every hypervisor tested showed similar percent changes between the different tests.
  4. There was little difference between High Server Scalability and Optimized for WAN because the items within the policy were not a significant part of the tested workload.
  5. Switching from the Citrix Very High Definition User Experience Policy to the Citrix High Server Scalability Policy improved server density by a whopping 30%.

Why did we see such a gain when moving to the High Server Scalability policy? Because the Very High Definition User Experience policy utilizes the H.264 codec, which gives the user a great experience, but at the cost of CPU utilization. When we switch to the High Server Scalability policy, we utilize the latest ThinWire technology. We are able to reduce CPU utilization while increasing server density by changing the way the system encodes the data.

In addition, these policies also modify how items are compressed, how many frames per second are transmitted, plus many more.

To learn more about the Citrix policies, check out the following blogs:

  1. Why you should care about the new HDX ThinWire
  2. HDX Policy Templates

Stay tuned for Windows 10 on XenDesktop 7.7

Server Specs:

  • Processors: Dual Intel Xeon E5-2697 (12 cores each)
  • Workload: Knowledge Worker
  • VM Specs: 2vCPU, 4 GB RAM

Daniel ()
XenApp & XenDesktop Best Practices
XenApp & XenDesktop Videos

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).

042914_1620_1.png

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


Sizing XenDesktop 7 App Edition VMs


In the Mobilizing Windows applications for 500 users design guide, we made the recommendation to allocate 8vCPUs for each virtual XenDesktop 7 App Edition host (formerly known as XenApp). Spreading this out across a server with two Intel Xeon E5-2690 @2.9GHz processors and 192 GB of RAM, we were yielding about 200 users per physical server and roughly 50 users per virtual server.

Of course, the design guide is the end result of a lot of testing by the Citrix Solutions Lab. During the tests, we had the Solutions Lab compare many (and I mean many) different configurations where they changed the number of vCPU, RAM size, and RAM allocation (dynamic/static) as well as a few other things. We ended up with the following:

A few interesting things:

  1. Dynamic vs static RAM in Hyper-V appeared to have little, if any, impact on overall scalability. The only time when the RAM allocation had a negative impact was when not enough RAM was allocated (no surprise there).
  2. The 8vCPU and the 4vCPU configurations resulted in very similar user concurrency levels. Get ready… The battle is about to begin as to whether we should use 8 or 4 vCPU. (Is anyone else besides me having flashbacks to 2009?)

A few years ago, we debated about using 2vCPU or 4vCPU for XenApp 5 virtual machines. A few years later, the debate is resurfacing but this time, the numbers have doubled: 4 or 8. Here is what you should be thinking about… VMs are getting bigger because the hardware is getting faster, RAM is getting cheaper and the hypervisors are getting better (Nick Rintalan provided a pretty good overview on some of the reasoning for this during his discussion on NUMA cores in his XenApp Scalability v2013 Part 2 blog). The whole point is that none of this is new. It has been going on for a long time and will continue to do so.

The hypervisor helped us reduce our physical footprint by allowing us to better utilize our physical hardware. Now, with better technology, we are able to reduce our virtual footprint because the technology is able to support larger VM sizes.

Daniel – Lead Architect