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

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?

Working on a project for a customer. Doing an exchange 2003 to 2007 migration and when you open up the exchange 2007 management console you get a bunch of errors that look pretty ominous. They are validation errors that state the path cannot be the root directory!

After looking into it a little deeper it turns out the customers exchange 2003 storage groups, transaction logs, and databases were stored on different drives but were in the root path of those drives.  Apparently Exchange 2007 is not to keen on that.

The following is what it looked like from the Exchange 2003 console.

I guess the moral of the story is I could move the transaction logs, databases, system paths on the 2003 ide to please the 2007 Mgt console….Or I could just ignore ignore it until the 2003 server is retired.  Since all messaging is flowing properly, I choose the latter…

Scott

I came across this great utility on another website that I know I will be adding to my tool set, and I am sure other might find useful.

Richard Garthshagen has it on his site.

This tool will give you all you need to know about the servers in your cluster just by passing it the VC info.

Thanks Richard for an awesome tool!

Scott

Some interesting pieces of information are starting to trickle out about Citrix’s upcoming release of Feature pack 2 for XenApp.

Harry Labana is writing about a new feature being developed for this release known as “VM hosted apps”. Seamless applications beyond Terminal Services, does it help?

What this means is that Citrix is going to be giving you the ability to publish applications which are actually being delivered from a windows xp/vista/7 hosted virtual machine, and not from a server 2003/2008 .

What does this gain you.  For instance you have an application that does NOT work on server 200x, or will not legally be able to be delivered on server 2003, or supported.  You now have a way of delivering the application and having all the same advantages you have when using XenApp,  Centralized, secured, seamless, dynamic.

I think this is awesome. This is a serious competitive advantage that addresses a real pain point in server based application delivery.

Where it is going to get cloudy/confusing is the use case for full blown desktop virtualization (XenDesktop), and the use case for vm hosted APPs.  Is this going to start to eat into the licensing sales for XenDesktop?

I am super excited to get this in and start testing…..

 Loading ...