XenDesktop 7.6 VDA CPU & Memory Footprint

If you install the Citrix XenDesktop 7.6 Virtual Desktop Agent (VDA) on a small Windows 7 VM, you may be in for a big surprise, and not a good one. This article documents issues I have experienced and how to work around them.

Starting Point

I started with Windows 7 x64 in a Generation 1 VM on Windows 8.1 Client Hyper-V. The machine had 1 vCPU, Dynamic Memory enabled, startup RAM, and minimum RAM were both at 512 MB. I had used this configuration for quite some time without any problems. Method of access: RDP (using Royal TS).

Then I installed the VDA from the XenDesktop 7.6 ISO in Remote PC mode, not choosing HDX 3D Pro.

Gray Screen After Logon

When I tried to log on after the mandatory reboot all I got was a gray screen surrounded by black:

XenDesktop 7.6 VDA gray screen with black border

The session was not dead at all, it showed as active in Citrix Studio and I could log the user off from there. But the desktop never appeared.

I noticed high CPU usage of ctxgfx.exe. If I am not mistaken that is the process responsible for H.264-encoding the display graphics. Apparently that task is a bit much for a single vCPU. To get the VDA to play nicely two policy settings are required:

  • Desktop Composition Redirection: disabled
  • Legacy Graphics Mode: Enabled

Black Border Around Desktop

With those two policy settings in place things were much better: I was able to actually see the desktop and interact with it:

XenDesktop 7.6 VDA desktop with black border

However, the black border remained.

As it turned out this issue is documented in CTX200073. The root cause of the black border is that the Citrix WDDM display driver tries to allocate 128 MB of memory during system startup. If that fails, you get the black border.

In my case, the proposed solution from the Citrix KB article does not apply. There is simply not enough RAM available during boot. Increasing the Startup RAM of the VM from 512 MB to 1024 MB fixed the problem.

Citrix VDA Memory Usage

I took this as an opportunity to take a closer look at the VDA’s memory usage. Our uberAgent monitoring product has a useful dashboard for this task. It displays all the running applications along with their CPU/memory/disk/network footprint. Take a look at this screenshot where the red arrows highlight applications that are part of the XenDesktop 7.6 Virtual Desktop Agent:

XenDesktop 7.6 VDA memory usage

The total RAM footprint of the VDA is a whopping 374 MB (a few minutes after boot). That is huge! And this does not even include drivers running in kernel space!

Conclusion

I remember talking with Citrix’s Juliano Maldaner at BriForum Amsterdam 2007 about the planned new architecture (then only a concept, now called FMA). One of the goals was to separate workers and controllers and not install the full product on the workers but only a light-weight agent. Well, that may not have worked out, after all. Installing XenApp 6.5 probably increases the memory footprint less than installing the XenApp/XenDesktop 7.6 VDA.

Comments

Related Posts

Persistent VDI in the Real World - Storage

Persistent VDI in the Real World - Storage
This is the second article in a multi-part series about building and maintaining an inexpensive scalable platform for VDI in enterprise environments. Previously in this Series I started this series by defining requirements. Without proper requirements, everything else is moot. Remember that we are looking at running typical enterprise desktop workloads, we are trying to centralize desktops and our primary desktop hosting technology is multi-user Windows, aka RDS/XenApp.
Citrix/Terminal Services/Remote Desktop Services

Solved: Citrix Desktop Service Fails to Start, Logs Event 1006

Solved: Citrix Desktop Service Fails to Start, Logs Event 1006
I am sure you all love XenDesktop VDAs that just won’t register. Although this is becoming less and less of a problem I had another case recently. Checking the Obvious When a XenDesktop VDA is unregistered the first thing I do is check if the VM is actually turned on. With that out of the way I turn to the application event log, looking for entries with the source Citrix Desktop Service. This usually tells you what the problem is. Not this time, however. Apparently the Citrix Desktop Service (aka WorkstationAgent) ran into some error during startup. It logged the following event with ID 1006 and stopped:
Citrix/Terminal Services/Remote Desktop Services

Latest Posts