Introduction

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:

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

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.

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

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

now thinks our VM is legitimate:

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:

3D Graphics

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

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)

DirectX functions are now supported:

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

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:

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

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

Webcam

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

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:

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:

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.

These are then available for use within the VM:

 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.