Author Archive

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.

From time to time I have found it necessary to change the PNAgent configuration globally for end users, or for particular users.  This is pretty easy to do using a combination of login scripts and registry merges. The difficult thing in recent years has been the changing of the location of the configuration options based on the version of the client or XenApp plugin you were dealing with.

I stumbled across this the other day and hope it will help somebody else as much as it has helped me.

registry locations that control PN Agent