virtualization.info

virtualization.info already reported about several aspects (features, GA availability and strategy) of the new Citrix client hypervisor launched two weeks ago at Synergy 2010 (see event coverage).

Now, while additional feedbacks about the release candidate are being published by early adopters, and while Citrix is busy answering VMware on the value of client hypervisors for BYOC models, we are able to share additional details about its internals.

During the conference in fact, Ian Pratt (Chairman of Xen.org and Vice President of Advanced Virtualization Products at Citrix) and Tom James (Desktop Virtualization Manager of Business Client Platform Division at Intel) shared interesting details about the XenClient and Synchronizer internals.

About XenClient

The client hypervisor doesn’t just run the end-user virtual machines. It also run a lightweight additional one called Service VM, where all Citrix management components are installed. They include the interface to switch from one virtual desktop to another, the control panel, the Citrix Receiver and Synchronizer agents (if available).
XenClient can run more than one Service VM, and it’s probably here that Citrix looks for extensibility by third parties. Security vendors like McAfee, for example, may deploy their out of band security servers as Service VMs.

Besides the Service VM, there’s a Control Domain, which is responsible for direct access to physical hardware and chipset capabilities (like the Intel vPro features).
Part of physical components, like the GPU, can be exposed to the virtual desktops through Intel VT-d technology but there’s a severe limitation: only one virtual machine per time, the nominated VM, can have direct access to the GPU.
This means that while one virtual desktop will have near native graphic performance, the other (or the others) will have worse rendering, solely relying on para-virtualized graphic drivers.
Despite this direct GPU access for one virtual desktop, the Control Domain will still decide where and how pixels must be rendered on screen. This is done to prevent hacking attacks through the GPU, like screen scraping or pixel injection.

PortICA is being used to expose the applications of one virtual desktop on another through the seamless window technology.
As virtualization.info reported in a previous article, there’s no direct connection between virtual desktops and all traffic has to pass through the networking layer. Anyway PortICA traffic will not.
It’s not clear if Citrix is allowing its flow across an internal virtual switch that is not exposed to the physical network or in other ways.

XenClient features a so-called Secure Keyboard.
All keyboard activities are directed to the Control Domain which routes them only on the currently active virtual desktop. This is done to avoid keyboard attacks like key injection and keylogging from non-active VMs.

The Control Domain also owns the USB host controller.
All virtual desktops have a para-virtualized driver that emulates their own USB host controller, and the Once a new USB device is connected to the laptop, the Control Domain will check and apply security policyt to it, then it will forward the USB messages from its controller to the emulated ones.

XenClient will leverage Intel Trusted Execution Technology (TXT), which is part of Intel vPro, to verify its integrity and recognize any manipulation in its configuration states.
The configuration states are encrypted. The encryption key is sealed in the Trusted Computing Platform, and released only if the checksum matches.

About Synchronizer

Citrix Synchronizer comes as a virtual appliance for XenServer.
It listens to a single HTTPs port and features a web-based administration interface.
The authentication to this interface can be done using a local user database or a remote Microsoft Active Directory directory service.

Every time something changes in XenClient virtual desktops, a live snapshot is being taken in the background and sent back to the Synchronizer (it’s not clear with which frequency the whole thing happens).
Snapshots are taken leveraging block level differencing and compression to reduce the size as much as possible.
Synchronizer receives these snapshots from XenClient in the form of VHDs. Over time, multiple VHDs of the same virtual desktop are merged together in the background.