Skip to content
Jan 1 / The Architect

My experiences with XenClient 2.1 – part six:findings, issues and observations

Introduction

I know this is the final part of the series, and I’m publishing it before I’ve finished parts four and five, however I was collecting all my issues and observations into a single post rather that dispersing them throughout, and as there was enough content generated from the first three blog posts, it’s probably of interest to readers to publish this sooner.

I will keep coming back and updating this final part as I discover new, or fix existing issues.

Part 1 – installation and management GUI

Part 2 – Creating and configuring a Windows 7 VM

Part 3 – Hardware compatibility

Part 4 – Performance tests

Part 5 – Image management using Synchroniser

Part 6 – Findings, issues and observations (this post)

General observations

  • 3D graphics performance (once the GPU has been mapped through to the VM) is great. I’ve watched 1080p movies with no noticeable glitches due to being run under XenClient.
  • Battery performance does suffer somewhat, even when only running a single VM. I suspect this is because the lower-power states of the hardware and CPU are not being utilised due to Dom0 needing to be constantly active, whereas under native OS, these would be initiated frequently to save battery power when the OS is not at high utilisation. The mismatch of the battery display inside the VM (see below) that does not reflect the true status also means greater chance of losing work due to running out of juice. I suspect further work can be done to bring the battery usage more in-line with native OS when using single-VM only.
  • It would be good to have the option to background-sync a VM to the Sychroniser whilst still being able to use it. Being locked out of my VM due to it having to synchronise is a real pain point.

Issues and glitches

Can’t fully-synchronise VHD

Whilst working on the yet-to-be-published part five, I’ve made several attempts to upload my VM to the Synchroniser, but it keeps getting “stuck” near completion.

The GUI has both Cancel and Pause buttons, but these are both disabled when the problem occurs and the upload hangs.

XenClient - stuck image upload (no cancel or pause)

As one can’t use the VM whilst the upload is in process, I’m effectively locked out of my OS completely. The only resolution is to reboot XenClient and abort the upload.

I will continue to try overnight uploads (limited upstream bandwidth on consumer broadband links means uploading a 15Gb VHD is slooooow) and report back any further developments once I start work on part 5.

Disconnected WiFi on resume

When I resume the laptop from suspend (i.e. open the lid) , XenClient (and thus my Windows 7 VM)  is not automatically reconnected to my WiFi network. I have to CTRL+0 to enter receiver, enter the admin password, then CTRL+1 to return to the VM to get XenClient to reconnect to my WiFi.

This issue alone makes XenClient system unusable as my main system as I frequently close my laptop and move it around the house, thus suspending the OS.

I can’t afford to configure the power options to “do nothing” on lid closure as this would kill battery life.

Occurrences: every time I suspend

Compounding issue: can’t unlock receiver

The disconnected WiFi is now an even bigger problem as I can’t unlock the Receiver client until several minutes after resuming the laptop. To demonstrate this, I recorded a short video:

Incorrect battery state indicator inside VMs

I’ve noticed several instances when the battery “%” as reported inside the VM is different from the “real” battery capacity. This means one can be fooled into thinking you have more time to work than is actually the case, and then suffer from an unexpected shutdown when the battery is drained.

XenClient battery usage bug - shown in VM
XenClient - real battery status in Receiver

Whilst working, being able to glance at the battery status icon in the system tray to see how much battery life remains is essential when on the road to judge how much time you have left before having to hook up to the mains to recharge. Having to jump back into the XenClient receiver to get an accurate reading is unacceptable.

Occurrences: four times so far.

Complete loss of WiFi

XenClient has twice lost connection to my WiFi and would not reconnect. I tried disabling and re-enabling Wireless networking but this did not help.

Rebooting XenClient once resulted in a “white screen hang” on shut-down, and I had to forcibly power-cycle to recover.

Occurrences: four times so far.

Shared WiFi

Because WiFi networking is provided to the VM via Shared mode only, it uses a different IP addressing scheme from the rest of the PCs on my home network.

XenClient - WiFi IP addressing

XenClient WiFi IP settings (172.16.26.x)

vs

XenClient - normal WiFi IP settings

Normal WiFi IP settings (192.168.1.x)

 

This causes problems with name resolution to other devices on my home network, and adding networked printers, as this screenshot shows when trying to add my office HP Printer:

XenClient - Cant add HP WiFi printer

Whilst a “techie” could find a way round this issue, it would be a “showstopper” issue for a regular user wishing to use XenClient as a regular work system, as the ability to Bridge WiFi connections to utilise the same IP subnet and utilise an office printer is essential.

Can’t use the webcam

When I assigned the integrated webcam to a VM, it immediately showed up in device manager:

XenClient - webcam

However as soon as I tried to use it (using Skype as a test application) the VM appeared to lose connectivity to it, and it then disappeared from device manager again until I rebooted the VM.

I recorded a short video showing this behaviour.

Rebooting both the VM and the entire system did not resolve the problem.

Occurrences: fully repeatable

Mysterious errors on the messages.log

When troubleshooting issues, it’s useful to drop into the shell and view the messages.log file, however the following errors are being logged every second in the messages.log meaning its harder to find “real” errors.

XenClient messages.log output after lost connection to Wifi

Occurrences: fully repeatable.

Universal remote not assignable to VM (new 05/02/12)

I use a Logitech Harmony Remote to control my AV kit, and wanted to make some tweaks to my configuration. It’s programmed by USB, so I decided to try it out on my XenClient setup.

The device is recognised by XenClient, but can’t be assigned to a VM as it’s taken on some special kind of status as a “secure platform device”:

XenClient - Connecting a Harmony Remote

 VM marked as “Asleep” (new: 04/05/12)

Resuming my laptop from standby one morning I was greeting with an unusual error in XenClient receiver:

I then noticed that I couldn’t select my VM and it had changed to an unusual status:

XenClient - Strange VM status

Given the only option available was “Shutdown” I had little choice. Upon commencing the shutdown process, the OS VM crashed with this BSOD:

XenClient - rebooting VM

 

 

 

In summary

In the 2.1 release of XenClient there are a mixture of minor glitches (IP addressing, battery status) that can be worked around, and more serious ones (no WiFi on resume from standby, failing webcam) that would prevent me from recommending XenClient being used in a production environment.

Once I’ve completed the final two posts (Synchroniser and Performance) I’ll hopefully be able to make further assessments of XenClient  as a Type-1 Hypervisor to replace your main client operating system.

If anyone from the XenClient team happens to be reading this, I’m happy to help troubleshoot any of the issues I’ve reported here to improve the product in the next release.

 

2 Comments

Leave a comment
  1. peterblum / Jan 3 2012

    Hi Niel,

    Thanks for the excellent blog posts on XenClient. The XenClient team is reading them and we would love to connect up with you on some of the issues you have been seeing. Drop me an e-mail and I’ll get you connected up with someone on our team.

    Peter Blum
    Director of Product Management and Marketing, Citrix XenClient

  2. mikkoj / Jan 8 2012

    Well, I have to admit that there is a real potential in Xenclient 2.x, but it is lacking some basic features which would be needed in corporate environment and has some glitches as well which MUST be repaired (hopefully soon).

    We are working with some high secure environments, which – need management though (so no XT).

    Starting from the glitches:

    1. Errors, errors, errors …”background operation failed”,”Error”,”Unknown error”, all kinds of errors without any noticeable reason.
    2. Login issues while changing domain password.
    3. 3G / Mobile Broadband connectivity…useless? To bridge it like WLAN would do the trick.
    4. Power control in Image does “nothing”? While you deploy image to user and set power control to individually control VM power – well, it controls both – VM and HOST
    5. Screen refresh on dom-0/client would be good to get rid of the “ghosts” sometimes on screen.

    Then what is needed:

    A. Synchronizer really to work!
    B. Being able to “push” images towards client
    C. Being able to re-certify client; e.g. cleaning user setup on host and being able to re-init it.
    D. Being able to use multiple accounts in single system (mapped to AD via Synchronizer).
    F. NTP enablement & setting
    G. Smartcard / certificate authentication torwards AD domain CA/PKI
    H: Did I mention already the need to push configuration & re-validate local configuration?
    I. Being able to connect synchronizer during Xenclient 2.1 installation via WLAN (not possible) now.
    J. Logging facilities –> push local/client critical & informational messages directly to synchronizer, at least on parts what client is performing with VMs.
    K. Customization controls; e.g own background (automatic management) etc.
    L. Ability to control amount of bandwidth is used for backup etc.

    Thanks,

    Mikko/Secproof (mikkoj@secproof.com)

Leave a comment

You must be logged in to post a comment.