My experiences with XenClient 2.1 – part six:findings, issues and observations
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 4 – Performance tests
Part 5 – Image management using Synchroniser
Part 6 – Findings, issues and observations (this post)
- 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.
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.
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.
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.
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:
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:
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.
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”:
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:
Given the only option available was “Shutdown” I had little choice. Upon commencing the shutdown process, the OS VM crashed with this BSOD:
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.
Leave a comment
You must be logged in to post a comment.