Skip to content
Dec 31 / The Architect

My experiences with XenClient 2.1 – part three – Hardware compatibility


This is the third part of a series on posts on XenClient:

Part 1 – installation and management GUI

Part 2 – Creating and configuring a Windows 7 VM

Part 3 – Hardware compatibility (this post)

Part 4 – Performance tests

Part 5 – Image management using Synchroniser

Part 6 – Findings, issues and observations

Click on any of the screenshot thumbnails for the full size versions.

Exposing built-in hardware

By default only some of the native hardware (such as CPU) is exposed to the VM. Any USB or PCI devices that are detected by XenClient can be assigned to one VM at a time. You can also choose to expose certain aspects of the host (BIOS strings and asset tags for example) through to the VM so that OEM software that checks the model will still install OK inside the VM.

Let’s see what a native VM sees hardware-wise:

XenClient - hardware detected inside a VM

  • As you can see there are Citrix-specific drivers for:
  • Disc
  • Mouse
  • Network devices
  • Sound
  • Storage

and some additional system devices





By default, the VM is as you would expect, quite generic looking. There is no way that you could identify that the OS is running on Lenovo hardware.

XenClient system information defaults

This causes a problem when trying to install any drivers that check the BIOS and Manufacturer strings before installing, as they would not detect that the underlying hardware is actually a Lenovo. To expose this information, we need to check the third option on the Advanced tab

XenClient VM with OEM data exposed to VM

Let’s check if the vendors “auto-detection” tool on their driver download site

now thinks our VM is legitimate:

XenClient - hardware detection within a VM

Once the Fingerprint reader is assigned to the VM, and we’ve installed the relevant drivers, we can then use the reader for authentication to the VM:

XenClient supporting Lenovo fingerprint reader

3D Graphics

By default, the VM uses a generic Citrix graphics driver that does not support any 3D capabilities:

XenClient - native Xen graphics driver

Configuring the 3D pass through the VM in the XenClient Receiver GUI, the video card changes from the Citrix Xen Display driver to the native driver (once you have installed the correct native drivers of course)

XenClient - exposing 3D graphics

DirectX functions are now supported:

XenClient - DirectX 3D support with native 3D passthrough

This means we can also use the native Intel utility to configure advanced graphics settings:

XenClient 3D graphics properties

Intel AMT

The X220 provides remote management facilities as part of the vPro chipset, and XenClient allows the AMT chip to be assigned to a single VM to allow the same remote management features to the VM as you would with native hardware. This is the last option under “Advanced” tab in the VM properties:

XenClient - VM Advanced options

Once enabled inside Receiver, the hardware then shows up inside the VM:

XenClient - Intel AMT hardware showing in VM

Installing the Lenovo/Intel AMT drivers, these then show up correctly:

XenClient - Intel AMT hardware showing in VM with drivers


The Lenovo X220 ships with an integrated webcam that we can assign to the VM. Assigning this to the VM

XenClient - webcam

And allows us to use applications such as Sykpe that use the camera functionality. However, I couldn’t get Skype to open the camera, and every time I tried to use it the Camera device disappeared from device manager. More on this in my findings post coming soon.

USB hardware

USB mass storage

When you insert a USB device, it is automatically assigned to the “active” VM and presented to the OS via plug’n’play. Let’s try something basic like a USB pen drive:

XenClient - inserting USB pendrive

This makes the user experience as “native” as possible as you don’t have to jump into the XenClient receiver to assign the device, even with multiple VMs running.

If you do wish to assign a USB device to a different VM, you first have to disconnect it from the original active one using Receiver:

XenClient - re-assign USB pen drive

USB composite device

Let’s try something more challenging – a USB composite device that consists of Mass storage, Smart card reader and smart card on a single device.

XenClient - USB composite device and Smart card

These are then available for use within the VM:

XenClient - Smart card devices

 Other USB device

As I’m publishing this part of the blog on New Years Eve, here’s a special hardware test to end this post (and the year!)

This concludes the look at the hardware exposed to the VM by the XenClient Hypervisor.

In the next instalment I’ll be running some performance tests on my VM under various CPU configurations.

Leave a comment

You must be logged in to post a comment.