Working in a lab and building those oh-so-clean systems is a nice way to work. Everything is generic, there are no GPOs we cannot change or systems we can’t power off and most of all we get to control the use-cases for each and every technology in our toolbox. It’s stress, and thought, free. We can demonstrate anything and always show it’s the way forward for a million different reasons.
Working in the real world (where you and I live) is much more challenging. Every customer is different and despite most wanting to virtualise something or other, even one way of tackling a problem that will suit the requirements 95% of the time sometimes needs to be viewed from a different angle and approached in a totally new way.
This was the case at a recent customer who is going through a desktop virtualisation project with XenDesktop. In fact it’s been a project that has taken several months to scope out and put into pilot and with this has come an interesting requirement that I’d like to share with you.
Using XenDesktop, the plan was to give the users a Windows 7 desktop with applications delivered in by App-V, XenApp, and having a few core apps installed into the gold build. The pilot continued in this direction for some time and the users were very happy with the speed and performance of the desktops. But at the 11th hour a new requirement came up that changed everything.
The customer uses an application to show to someone exactly how many units of alcohol they have consumed by inputting what they’ve drank over the last few days or weeks. This is visualised in the form of a slowly filling pint glass. The more units you’ve thrown back, the more the glass is filled and the more you should start to think if that park bench is really where you want to wake up on a Saturday morning. A pretty simple app, right? Well if I told you that the application was written so that pint glass used DirectX on-tap you can start to see why this wouldn’t work with a traditional XenDesktop Windows 7 desktop.
At this point, I was considering a pint myself as the usual way to give a VHD based desktop access to Direct3D applications is to bond a GPU to it as we do in XenServer or to use a BladePC as the virtual desktop. This is great for the type of person who uses high-end apps like AutoCAD, GIS apps or Call of Duty (ok, may be not all that productive), but for an app that just pulls a good pint it’s probably overkill. It would also be very expensive as this application would have a reasonable concurrency across the estate. This meant that Windows 7 with GPUs was a non-starter.
This was how my train of thought chugged along: We need to deliver an application to lots of people… needs to be from one place… needs to have the same five-star user experience… needs to be able to scale… needs to access a GPU for this little application…
The answer for the first four requirements is certainly XenApp but did you know it also has the rather wonderful ability to use any DirectX compatible graphics card and more importantly share it out to multiple users? Not a lot of people know this.
For the testing I couldn’t use the customers application which in fairness is pretty small as far as footprint goes so I figured lets have a bit more fun and see how far we could push XenApp using a GPU. Another problem was that I didn’t have any servers free in my lab so I found a 3 and a half year old HP desktop with 4GB of RAM with an Intel Core 2 Q9300 CPU running at 2.5GHz and a four year old nVidia FX 1700 graphics card. Not what you’d call a server class test bed at all and certainly not cutting edge – you can pick up the GPU for £250 in the UK – but if we can get a reasonably intensive application to work on an underpowered system you can bet that a half decent server will easily cope with the pint glass application.
After I removed Windows XP from the workstation and put 2008 R2 SP1 on and updated the nVidia drivers I installed XenApp 6.5 and added the following entry to the registry:
Under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook\AppInit_Dlls\Multiple Monitor Hook subkey create the EnableWPFHook key with a key type of REG_DWORD and set its value to 1. And that’s it. More details on this can be found here
What this does is move all of the DirectX, Direct3D and Windows Presentation Foundation rendering to the server’s GPU so we aren’t thrashing the CPU and can use the GPU to take care of all of those DirectX calls. The benefit of doing it this way is that the application and thus the users can share the GPU just as they would share the CPU if it was a normal XenApp server. So you get all that consolidation, security, centralisation and performance but for much more fancy applications. Or one that draws a pint glass.
Anyway, that’s the background. Let me show you what it looks like in action.
I’ve ran two tests. One is showing the application running on my Macbook Pro over my home ADSL via a Citrix Access Gateway. I’m using the latest Receiver for Mac that you can get from Citrix.com. Keep an eye on the bandwidth monitor down in the bottom right of the screen.
The second video is the same application (the same session actually, thanks to workspace control) but this time I’m using it from within in Windows 7 VM running on XenDesktop 5.5, just how the customer will run it. I’ve enabled Adaptive Display which has helped to knock off over 25% of bandwidth consumption and as you’ll see, the user experience is extremely good. Again we’re using the same connection, same Macbook Pro and the same Access Gateway. At the 2:20 mark I bring up the network monitor and you can you can see the reduction in bandwidth consumption just by using Adaptive Display.
Impressive stuff, I hope you’ll agree! If you’ve any questions about this test or if you’ve had similar success yourself please fill out the comments below as I’m be keen to hear your own experiences.
Anyway, I’m off for a lemonade.