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.

Dealing with a customer issue, setting up a XenServer pool to connect via the software iSCSI initiator to a pair of partnered synchronously replicated Datacore SanMelody iSCSI servers.  It setup fine following the datacore guidelines, we could shut down one of the SAN nodes fine and XenServers would failover to the secondary path quickly and vm’s would continue running without a blip.  The issue was that on reboots of the XenServers they would only attach to the SR via the lun path mapped in the gui, also when you went in and did your sendtargets to the secondary path and logged on to the second SAN node from the cli, the XenCenter gui would still reflect only 1 of 1 paths connected, when clearly “multipath -l” showed both paths.

The resolution to both issues was editing /etc/rc.local and adding the following to the end of the script.   The mpathcount.py seems to trigger after the XenServers are up so they come up as 1 of 1 paths, and then switch to 2 of 2 paths around 10 seconds later, you could tweak the second sleep counter down if your uptight about those things

sleep 30

iscsiadm –m discovery –t st –p

iscsiadm –m node –L all

service multipathd restart

sleep 30

/opt/xensource/sm/mpathcount.py