Xenserver

For the past two months we’ve been trying to migrate a bunch (90 or so) VMs from XenServer to ESXi … However for some reason on some of them, the Converter Service would crash. VMware Converter crashing due to rsintcor32.dll Up till Monday, I had no idea why. I decided to look into the error once again, and this time decided just to Google the failing module… And guess what ? Out came this Citrix forum post regarding the failing module. So, after knowing that rsintcor32.dll belongs to the Citrix System Monitoring Agent service (well, I could have guessed that from the DLLs path 😛) I decided to simply stop the service. ...

Well, what annoyed me in the past was that I had to patch each XenServer patch by patch (no bulk applying) and when used in combination with UCS blades (especially if those have >250GB RAM), it takes ages to keep a pool up-to-date. So I ended up writing yet another script (I know why I hate Citrix XenServer … the XenCenter GUI is lacking sooooo much) which will download new patches from a directory on a HTTP server and then print the lines necessary to apply the patches to all hosts in a pool. ...

Well, today I ended up writing a short script that’ll give me a list of VMPPs with the VMs that are associated to it. 1 2 3 4 5 6 7 8 9 10 11 12 #!/bin/bash # Get a list of VMPPs for vmpp in `xe vmpp-list params=uuid --minimal | sed "s/,/ /g"`; do VMPP_NAME=`xe vmpp-list params=name-label uuid=$vmpp --minimal` for vm in `xe vmpp-list params=VMs --minimal uuid=$vmpp | sed -e "s/;//g" -e "s/,//g"`; do VM=`xe vm-list params=name-label uuid=$vm --minimal` echo "$VMPP_NAME: $VM" done done

As the title pretty much tells, I’ve been working on fixing the Root-Disk-Multipathing feature of our XenServer installations. Our XenServer boot from a HA-enabled NetApp controller, however we recently noticed that during a controller fail-over some, if not all, paths would go offline and never come back. If you do a cf takeover and cf giveback in short succession, you’ll end up with a XenServer host that is unusable, as the Root-Disk would be pretty much non-responsive. ...

Well, we had some issues with XenServers “automated” metadata backup, so I decided - with the help of one of our consultants - to automate it on our own to an external target. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 #!/bin/bash # Crontab entry for each server: # 02 5 * * * root /usr/local/sbin/xen-pool-backup.sh # Get the pool name POOL_NAME="$( xe pool-list | grep name-label | awk '{ print $4 }' )" HOST_UUID="$( xe host-list hostname=`hostname` | grep "uuid ( RO)" | awk '{ print $5 }' )" DAILY_GENERATIONS=7 WEEKLY_GENERATIONS=4 NFS_MOUNT="nfs.home.barfoo.org:/srv/xenbackup" NFS_LOCAL="/tmp/backup-mount/$POOL_NAME" # Figure out if we're the pool master POOL_MASTER="$( xe pool-list | grep master | awk '{ print $4 }' )" if [ "$POOL_MASTER" == "$HOST_UUID" ] ; then # Only the pool master should backup the pool database, as this is the only # one who has a authoritive pool database # Create the necessary directory and mount the NFS volume mkdir -p ${NFS_LOCAL%/*} mount -t nfs $NFS_MOUNT ${NFS_LOCAL%/*} mkdir -p $NFS_LOCAL if [ -f $NFS_LOCAL/daily.$DAILY_GENERATIONS.gz ]; then rm -f $NFS_LOCAL/daily.$DAILY_GENERATIONS.gz fi OLD_DAILY="$( echo "scale=0; $DAILY_GENERATIONS - 1" | bc )" for OLD in $( seq $OLD_DAILY -1 1 ); do if [ -f $NFS_LOCAL/daily.$OLD.gz ] ; then NEW="$( echo "scale=0; $OLD+1" | bc )" # Save the time stamp somewhere touch $NFS_LOCAL/.timestamp -r $NFS_LOCAL/daily.$OLD.gz mv $NFS_LOCAL/daily.$OLD.gz $NFS_LOCAL/daily.$NEW.gz # Restore the date touch $NFS_LOCAL/daily.$NEW.gz -r $NFS_LOCAL/.timestamp fi done [ -f $NFS_LOCAL/daily.0.gz ] && mv $NFS_LOCAL/daily.0.gz $NFS_LOCAL/daily.1.gz xe pool-dump-database file-name=$NFS_LOCAL/daily.0 gzip -9 $NFS_LOCAL/daily.0 [ -f $NFS_LOCAL/.timestamp ] && rm $NFS_LOCAL/.timestamp umount ${NFS_LOCAL%/*} rm -rf ${NFS_LOCAL%/*} fi With that, I have at least a daily backup - and in combination with our daily TSM backup, I have at least month long history of metadata backups.