XenClient can work with the Synchronizer service to get the latest VM images. Synchronizer is the hub for publishing VMs and assigning them to users and their devices. XenClient connects to Synchronizer to download new or updated VMs based on what the Synchronizer administrator has specified.
The model requires an administrator to upload a VM image to Synchronizer. Later, a user authenticates with Synchronizer and downloads the assigned VMs. Currently, the assignment of a user to Synchronizer is a one time event. It appears to be impossible to reassign the laptop to a different user or connect to a different Synchronizer.
Synchronizer is a XenServer VM that handles the management and delivery of the XenClient VMs. It is possible to avoid using Synchronizer by installing Windows locally to XenClient from media. However, this can be time consuming and is not centrally managed by administrators.
Synchronizer uses HTTPS for its transport for syncing content. This makes it much easier to support with existing networks.
Given that XenClient images can be several gigabytes in size, it can take some time to bring down new images. There is some intelligence about reducing the bandwidth requirements but this cannot address all cases easily.
For a good overview of how to deploy Synchronizer, please read the PoC Guide. It is 52 pages long and gives some good tips.
It is in the PoC that I found a solution to problem I had.
The problem was this. I wanted to fix a problem with offline login to a domain with XenClient. This is a common request based on what happened after the release of XenClient 1.0. This only happens with Dynamic mode where the changes for the session are discarded during reboot. It became obvious that we needed to save something that we currently were not keeping.
There are two image modes in XenClient, Static and Dynamic. Static mode is intended for deploying once. Any updates would happen from existing tools and processes. Dynamic mode allows for updating from Synchronizer.
With Dynamic mode, Administrators can update the VM and make it available to existing XenClient machines. This allows for an easy way to manage VM content centrally. However it means that users cannot keep changes made to the Windows volume and cannot install their own applications. Luckily, they can keep changes to their user directory. Users that experiment with installing will find that installation appears to work until they reboot. After reboot, the changes will vanish.
Before continuing, it is important to mention that Dynamic mode is considered experimental from the current XenClient 1.0 release. This just means that it is not ready for prime-time use.
In order to setup XenClient for test, it was necessary to use Synchronizer. Luckily I have a XenServer installation in my office. It was not too hard to install Synchronizer into XenServer. Once working, it was then possible to assign the laptop XenClient install to use Synchronizer with the administrator role. The instructions can be found on page 18 of the PoC.
I had already installed a copy of Windows 7 from media on the laptop. It was then possible to upload the Windows 7 VM to Synchronizer. Please review the PoC starting on page 34 for the process of registering XenClient with Synchronizer.
This is where I made a bad assumption. The model of how things work in my mind suggested that if I downloaded a new VM with this existing Windows 7 VM that it would act like a Dynamic mode session. In other words, I expected that it would automatically switch my VM to be Dynamic. This would mean that it would automatically destroy changes to the system disk.
However, when I went to test this, it would always remember things it should not have and it worked. It took some time to realize why it was doing this and why the model I had was wrong.
If you download the VM as a new VM in XenClient, it thinks that you are still the author of the VM. If it thinks this, it will not discard the changes and therefore will not act like a pure Dynamic mode should.
In order to stop this from happening, it would be necessary to either use another laptop with a regular user or find a way to change the user on my existing laptop. Since I do not have a second laptop to run XenClient, it was necessary to change the user.
Doing this turned out to be a problem. There was nothing in the documentation about how to do this. The only obvious answer was re-installing XenClient. That did not seem like a good option since I did not want to lose information. Having seen the PoC, it triggered a memory of an appendix talking about how to de-register with Synchronizer.
These directions were not quite related to my problem (switching to a different Synchronizer) but did solve the problem of switching users.
Using the trick of getting a Command Line Interface (CLI) with Ctrl-Shift-t while using Citrix Receiver for XenClient, the /etc/bed-deregister command can be run. Before running this, you should understand that it is about to blast all your VM data. Initially I cared about this but decided that since the VM lived in Synchronizer that it did not matter.
XenClient just needed to be reconfigured to use a different user after this. Then it was possible to duplicate the original problem. The VM was in a real Dynamic image mode. Using some tools it was possible to find the missing registry entries that were not being saved and finally offline login was possible with Dynamic mode.
All of this information is really intended for administrators experimenting with XenClient and publishing Dynamic mode VMs.
Live near Brisbane, Australia. Software developer currently focused on iOS and Android. Avid Google Local Guide
Red Circle Blog 