XenServer – Setting virtual disks names based on the VM names
One of the worst things you can have in XenServer, is some wize-guy performing a ‘forget storage’ on a storage device still holding virtual disks related to VMs. As XenServer database is internal (for the whole pool) and not per-VM, all references to this virtual disks disappear, and you remain with bunch of VMs without disks, and later on, when the recovered from the shock and restored the SR, with a bunch of virtual disks you have no clue as to where they belong. Why? Because we are lazy, and we tend to skip the part where you can (or is it – should?) define a custom name for your virtual disks so you would know later on (for example – in the case specified above) where they belong(ed).
To solve this annoying issue, and to save time for Citrix XenServer admins, I have created a script which resets the VDI (virtual disk object) names to the name of the VM+ the logical position of the virtual disk (example: xvda, hdb, etc), related to the VM. That way, it will become very easy to identify the disks in case of such annoying micro-catastrophy (micro because no data is lost, just where it belongs…).
The script can be called manually, and since we’re lazy people, and we will forget to handle it manually every said interval, and will accumulate virtual machines with “Template of XYZ” virtual disks, it can be called from cron. When called manually, it asks the user to proceed by pressing ‘Enter’. If called from cron, it just runs.
Enjoy!
#!/bin/bash
# This script will reset the names of the virtual disks used for each VM to a standard name, based on the VM name
# and the disk position
# It is meant to solve problems where due to 'forget storage' operations or the likes
# virtual disk associations disappear, and you face many disks having the same name
#
# Written by Ez-Aton: http://run.tournament.org.il
if [ -t 1 ]
then
echo "This script will reset *all* VM disks to a name constructed of the VM and the disk name (xvda, hdb, etc)"
echo "This operation is not reversible, however, it can be called repeatedly"
echo "If you want this script to skip a said virtual disk, make sure its name includes the name of the VM"
echo "For example 'vm1 the real important data disk' for a disk used by vm1."
echo "Note that the name is case sensitive, and it is very important that to match the name using upper/lower case letters as needed"
echo "To abort, press Ctrl+C"
echo "To proceed, press Enter"
read abc
fi
VM_LIST=`xe vm-list is-control-domain=false --minimal | tr , ' '`
for i in $VM_LIST
do
# Resetting several parameters, so we have a clean start
VM_NAME=""
VBD_LIST=""
VDI_LIST=""
# We iterate through all existing VMs, to get both their names, and their disks
VM_NAME="`xe vm-param-get uuid=$i param-name=name-label`"
if [ -z "$VM_NAME" ]
then
# We have a problem with empty VM names, so we will use the VMs uuid
VM_NAME=$i
fi
VBD_LIST=`xe vbd-list vm-uuid=$i --minimal | tr , ' '`
for j in $VBD_LIST
do
# Resetting several parameters, so we have a clean start
VDI_UUID=""
DEV_NAME=""
# We iterate through all existing VBDs to reset the VDI nane
VDI_UUID=`xe vbd-param-get uuid=$j param-name=vdi-uuid`
if [ "$VDI_UUID" == "" ]
then
# This is a virtual CDROM
continue
fi
DEV_NAME=`xe vbd-param-get uuid=$j param-name=device`
VDI_NAME=`xe vbd-param-get uuid=$j param-name=vdi-name-label`
# Test if the name was reset in the past or manually
TGT_NAME="$VM_NAME $DEV_NAME"
if [[ "$TGT_NAME" = "$VDI_NAME" ]]
then
# There is nothing to do
echo "Name already includes VM name, so nothing to do"
else
# Here we reset the VDI name
echo xe vdi-param-set uuid=$VDI_UUID name-label="$TGT_NAME"
xe vdi-param-set uuid=$VDI_UUID name-label="$TGT_NAME"
fi
done
done
Great post!
I will definately start using this….
But, unfortunately, the damage has been done. The wize-guy in this case tried to move some storage repos to a different subnet and thought that forget and re-attach would work…. it does…. but now I’m looking at a large number of No Name virtual disks…. Do you have any clue on how to overcome this “annoying issue” as you call it? My users, unlike my operator, will start comming in in about 8 hours….. Nothing vital is lost, but I would like my servers back online….
Unfortunately (and sorry for the delay. I do not approve comments on a daily basis), your main option is to start booting servers with the disks, one after the other. Eventually, you will identify these disks, the hard way.
An alternative you can use, assuming (and this is a far-fetched assumption) that you enabled the pool backup in the xsconsole, is to recover metadata from this backup. Recover all Vms, will create a set of duplicate VMs, but this time – with a disk attached, as well as some (most, if not all) of its details.
Good luck!
Ez
Thank you… thank you… thank you! Saves a ton of time having to rename disks after deploying massive amounts of VMs from a template.