Hyper-V R2 service pack 1, Dynamic Memory, RemoteFX and virtual desktops

This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I have to admit that I’ve tuned out a bit on the virtualisation front over the last year.  It seems that some vendors are ramming VDI down our throats as the answer to everything; meanwhile others are confusing virtualisation with “the cloud”.  I’m also doing less hands-on work with technology these days too and I struggle to make a business case to fly over to Redmond for the MVP Summit so I was glad when I was invited to join a call and take a look at some of the improvements Microsoft has made in Hyper-V as part of Windows Server 2008 R2 service pack 1.

Dynamic memory

There was a time when VMware criticised Microsoft for not having any Live Migration capabilities in Hyper-V but we’ve had them for a while now (since Windows Server 2008 R2).  Then there’s the whole device drivers in the hypervisor vs. drivers in the parent partition argument (I prefer hardware flexibility, even if there is the occasional bit of troubleshooting required, over a monolithic hypervisor and locked-down hardware compatibility list).  More recently the criticism has been directed at dynamic memory and I have to admit Microsoft didn’t help themselves with this either: first it was in the product, then it was out; and some evangelists and Product Managers said dynamic memory allocation was A Bad Thing:

“Sadly, another “me too” feature (dynamic memory) has definitely been dropped from the R2 release. I asked Microsoft’s Jeff Woolsey, Principle Group Program Manager for Hyper-V, what the problem was and he responded that memory overcommitment results in a significant performance hit if the memory is fully utilised and that even VMware (whose ESX hypervisor does have this functionality) advises against it’s use in production environments. I can see that it’s not a huge factor in server consolidation exercises, but for VDI scenarios (using the new RDS functionality), it could have made a significant difference in consolidation ratios.”

In case you’re wondering, at my notes from when this feature was dropped from Hyper-V in the R2 release candidate (it was previously demonstrated in the beta). Now that Microsoft has dynamic memory working it’s apparently A Good Thing (Microsoft’s PR works like that – bad when Microsoft doesn’t have it, right up to the point when they do…).

To be fair, it turns out Microsoft’s dynamic memory is not the same as VMware’s – it’s all about over-subscription vs. over commitment. Whereas VMware will overcommit memory and then de-duplicate to reclaim what it needs, Microsoft takes the approach of only providing each VM with enough memory to start up, monitoring performance and adding memory as required, and taking it back when applications are closed.

As for those consolidation ratio improvements: Michael Kleef, one of Microsoft’s Technical Program Managers in the Server and Cloud Division has found that dynamic memory can deliver a 40% improvement in VDI density (Michael also spoke about this at TechEd Europe last year).  Microsoft’s tests were conducted using the Login Virtual Session Indexer (LoginVSI) tool which is designed to script virtual workloads and is used by many vendors to test virtualised infrastructure.

It turns out that, when implementing VDI solutions, disk I/O is the first problem, memory comes next, and only after that is fixed will you hit a processor bottleneck. Instead of allocating 1GB of RAM for each Windows 7 VM, Microsoft used dynamic memory with a 512MB VM (which is supported on Hyper-V).  There’s no need to wait for an algorithm to compute where memory can be reclaimed – instead the minimum requirement is provided, and additional memory is allocated on demand – and Microsoft claims that other solutions rely on weakened operating system security to get to this level of density.  There’s no need to tweak the hypervisor either.

Microsoft’s tests were conducted using HP and Dell servers with 96GB of RAM (the sweet spot above which larger DIMMS are required and so the infrastructure cost rises significantly).  Using Dell’s reference architecture for Hyper-V R2, Microsoft managed to run the same workload on just 8 blades (instead of 12) using service pack 1 and dynamic memory, without ever exhausting server capacity or hitting the limits of unacceptable response times.

Dynamic memory reclamation uses Hyper-V/Windows’ ability to hot-add/remove memory with the system constantly monitoring itself for virtual machines under memory pressure (expanding using the configured memory buffer) or with excess memory, after which they become candidates to remove memory (not immediately in case the user restarts an application).  Whilst it’s particularly useful in a VDI scenario, Microsoft say it also works well with web workloads and server operating systems, delivering a 25-50% density improvement.

More Windows 7 VMs per logical CPU

Dynamic memory is just one of the new virtualisation features in Windows Server 2008 R2 service pack 1.  Another is a new support limit of 12 VMs per logical processor for exclusively Windows 7 workloads (it remains at 8 for other workloads).  And Windows 7 service pack 1 includes the necessary client side components to take advantage of the server-side improvements.

RemoteFX

The other major improvement in Windows Server 2008 R2 service pack 1 is RemoteFX.  This is a server-side graphics acceleration technology.  Due to improvements in the Remote Desktop (RDP) protocol, now at version 7.1, Microsoft is able to provide a more efficient encode/decode pipeline, together with enhanced USB redirection including support for phones, audio, webcams, etc. – all inside an RDP session.

Most of the RemoteFX benefits apply to VDI scenarios but one part also benefits session virtualisation (previously known as Terminal Services) – that’s the RDP encode/decode pipeline which Microsoft says is a game changer.

Microsoft has always claimed that Hyper-V’s architecture makes it scalable. With no device drivers inside the hypervisor (native device drivers only exist on the parent partition) and a VMBus used for communications between virtual machines and the parent partition.  Using this approach, virtual machines can now use a virtual GPU driver to provide the Direct3D or DirectX capabilities that are required for some modern applications – e.g. certain Silverlight or Internet Explorer 9 features.  Using the GPU installed in the server, RemoteFX allows VMs to request content via the virtual GPU and the VMBus, render using the physical GPU and pass the results back to the VM again.

The new RemoteFX encode/decode pipeline uses a render, capture and compress (RCC) process to render on the GPU but to encode the protocol using either the GPU, CPU or an application-specific integrated circiut (ASIC).  Using an ASIC is analogous to TCP offloading in that there is no work required by the CPU.  There’s also a decode ASIC – so clients can use RDP 7.1 in an ultra-thin client package (a solid state ASIC) with RemoteFX decoding.

Summary

Windows 7 and Windows Server 2008 R2 service pack is mostly a rollup of hotfixes but it also delivers some major virtualisation improvements that should help Microsoft to establish itself as a credible competitor in the VDI space. Of course, the hypervisor is just one part of a complex infrastructure and Microsoft still relies on partners to provide parts of the solution – but by using products like Citrix Xen Desktop as a session broker, and tools from Appsense for user state virtualisation, it’s finally possible to deliver a credible VDI solution on the Microsoft stack.

One thought on “Hyper-V R2 service pack 1, Dynamic Memory, RemoteFX and virtual desktops

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.