For those of us who have been excited about the new features in XenServer 5.5 there are definitely some new caveats to struggle through.

One of the exciting new features is snapshotting of virtual machines along with cloning those snaphots quickly into virtual machines. one of the downsides of this feature is the storage requirements. As of now the snapshots are written to the same volume as the virtual machine it is being snapped from.

Pay attention to the volume sizes, and snapshot sizes in the narrative below

VM size: 24GB

Pre-vm storage : 631.1GB used/1156.6GB total

VM installed

pre-snap: 655.1GB used/1156.6GB total 645.1GB allocated
snapshot of 24GB VM taken
snapsize 75.6MB according to snapshot tab
post-snap: 679.1GB used/1156.6GB total 645.1GB allocated

So based on this when you snap it is virtually nothing size-wise according to the snapshot tab and total allocated, but your used space does take up the full vm size so that you can’t over allocate. This is the error we got when snapping.
based on this We will need double the vm size to take the snap then.

VM created from snapshot
Post-deploy from snap: 703.1GB used/1156.6GB total 669.1GB allocated

In addtion

If I delete the snapshot my used space doesn’t change at all, the space isn’t reclaimed. But if I retake a snapshot my used space does not go up. If you want to be technical it went from 703.1GB to 703.2GB.

Not sure if this is a bug or a feature but it is clear that the snapshotting in XenServer is clearly in its infancy stage.

Next up:

Some strategies for working around this.

It is summer after all….
Thanks to the XenApp Blog for the Scripts

In all seriousness I find it hilarious after 15 years in this industry that we are still doing this.  Take a PC and all it’s bloatedness and strip it down to the bare minimum software needed to run the XenApp WI and Web client.  Lock it down and you have yourself a nice windows based Kiosk.

Why windows you say? Well all of the enhancements to the XenApp client are going to go against the Win32 client to take advantage of the local hardware.

I could see great use of this in libraries, Schools etc where there is a fair amount of commodity hardware, and a server based application/desktop delivery initiative on going.

While you could do something similar with the XenDesktop Embedded Receiver Client this is much more flexible.

It looks like DataCore has followed through on their promises to release a storage Link adapter for XenServer. An official Citrix release notification can be read Here.

So what exactly is StorageLink? Storage Link is a set of technologies that “allows the user to perform storage management tasks directly out of the Citrix StorageLink user interface. It unifies management of virtual machines and DataCore virtual storage into one single console, whether you’re using XenServer or Hyper-V. It offers both FC SAN and iSCSI support.”.

This is a long winded way of Citrix enabling advanced storage manipulation inside of it’s console.  This goes along with the Xen philosophy of relying on vendors to write advanced features instead of writing them into their product. This has been touted by Citrix for a while as a way of optimizing their code for Hypervisor performance while creating a conduit for advanced features to be taken advantage of by ISV’s.

We have yet to implement this feature for any customers but may be compelled to do so soon.  Feedback to follow.

Anyone out there doing this yet?