Enable Auto-start VM feature on Xenserver

To Re-enable the VM autostart feature for the pool object:

xe pool-param-set uuid=UUID_OF_THE_POOL other-config:auto_poweron=true

To Set the following parameter for VMs for which you wish to have automatically starting:

xe vm-param-set uuid=UUID_OF_THE_VM other-config:auto_poweron=true

There was an SR backend failure. status: non-zero exit

There was an SR backend failure.
status: non-zero exit
stdout:
stderr: Traceback (most recent call last):
File "/opt/xensource/sm/LVMSR", line 1985, in ?
SRCommand.run(LVHDSR, DRIVER_INFO)
File "/opt/xensource/sm/SRCommand.py", line 307, in run
sr = driver(cmd, cmd.sr_uuid)
File "/opt/xensource/sm/SR.py", line 136, in __init__
self.load(sr_uuid)
File "/opt/xensource/sm/LVMSR", line 196, in load
self._undoAllJournals()
File "/opt/xensource/sm/LVMSR", line 1046, in _undoAllJournals
self._handleInterruptedCoalesceLeaf()
File "/opt/xensource/sm/LVMSR", line 807, in _handleInterruptedCoalesceLeaf
cleanup.gc_force(self.session, self.uuid)
File "/opt/xensource/sm/cleanup.py", line 2543, in gc_force
sr.scanLocked(force)
File "/opt/xensource/sm/cleanup.py", line 1287, in scanLocked
self.scan(force)
File "/opt/xensource/sm/cleanup.py", line 2092, in scan
self._handleInterruptedCoalesceLeaf()
File "/opt/xensource/sm/cleanup.py", line 2170, in _handleInterruptedCoalesceLeaf
self._undoInterruptedCoalesceLeaf(uuid, parentUuid)
File "/opt/xensource/sm/cleanup.py", line 2213, in _undoInterruptedCoalesceLeaf
parent.deflate()
File "/opt/xensource/sm/cleanup.py", line 934, in deflate
lvhdutil.deflate(self.sr.lvmCache, self.fileName, self.getSizeVHD())
File "/opt/xensource/sm/cleanup.py", line 991, in getSizeVHD
self._loadInfoSizeVHD()
File "/opt/xensource/sm/cleanup.py", line 1002, in _loadInfoSizeVHD
self._sizeVHD = vhdutil.getSizePhys(self.path)
File "/opt/xensource/sm/vhdutil.py", line 210, in getSizePhys
ret = ioretry(cmd)
File "/opt/xensource/sm/vhdutil.py", line 94, in ioretry
errlist = http://errno.EIO, errno.EAGAIN)
File "/opt/xensource/sm/util.py", line 277, in ioretry
return f()
File "/opt/xensource/sm/vhdutil.py", line 93, in <lambda>
return util.ioretry(lambda: util.pread2(cmd),
File "/opt/xensource/sm/util.py", line 178, in pread2
return pread(cmdlist, quiet = quiet)
File "/opt/xensource/sm/util.py", line 171, in pread
raise CommandException(rc, str(cmdlist), stderr.strip())
util.CommandException: 22

My VMs went down finally. I rebooted and one of my SR was broken and couldn't be repaired. When I tried to connect it, I was getting the same error message again and again.

The root cause of my issue appears to be the coalesce process was interrupted at some point during cleanup of deleted snapshots. This broke the SR, and then most likely started filling up the logs.

To fix the issue we determined what VHD was causing the failure by reviewing
tail -f SMlog

Then by renaming the VG that had the word "leaf" in it

lvrename /dev/VG_XenStorage-3386db8b-02d5-a76c-18b9-242fd6766643/leaf_368e2e6a-c8bd-49a3-a3f7-14bc070cb373_dd279484-4c7e-4155-9120-8023d364fb86 /dev/VG_XenStorage-3386db8b-02d5-a76c-18b9-242fd6766643/leaf_368e2e6a-c8bd-49a3-a3f7-14bc070cb373_dd27.bak

From this point we repaired the SR which caused the coalesce process to finish whatever it needed and cleanup. The SR came online and my problems were solved.

This was a very strange issue. Hope this information helps someone else who gets stuck!

Thanks to this post

Changing the Pool Master in Citrix XenServer pool

To change the pool master in Citrix Xenserver 6.2, follow the below procedure:

You can do this only from command line.

Step 1: List your XenServer hosts:

# xe host-list

Using the list above, you can note down the uuid of the xenserver host which will be designated as the new pool master.

Step 2: Now designate a new pool master by supplying the uuid associated with the desired host:

# xe pool-designate-new-master host-uuid=<uuid>

Note: You’ll probably lose connection to the pool at this point, but that’s normal behavior.

Step 3: Once XenCenter reconnects, it will ask you to connect with the new pool master.

Step 4: Also you can check the new pool master my typing the following command

# xe pool-list

Free tool to backup VMs on Xenserver Host

Few months back, I came across a fantastic software to backup Xenserver virtual machines without any downtime. It is Xackup from Fungusware. I am using this tool in my production environment. It works fine without any issues.
The features are

1. It can Backup, Restore or Migrate VMs from Xenserver Hosts.
2. It takes a snapshot of the VM and then exports the VM in compressed format to the storage. After the backup process, it automatically deletes the snapshot file from the server.
3. It takes the differential backup. So it saves space on storage end.
4. Email alerts let us know the status and the whole background process of the backup and restoration.
5. It can migrate or (or clone) a Virtual machine between XenServers without having to use an intermediary storage medium.
6. You can schedule your Virtual Machines to be backed up on a given schedule
7. Xackup attempts to keep you informed of its progress at all times.

It uses Simple mechanism as follows:


It don’t use any propriety storage formats, backups are stored as compressed archives and use the standard XenServer methods to do all the work. That means if something should happen to go wrong, we always have the ability to manually intervene and make sure your VMs are always safe.

Assign more than 8 vCPUs a VM on XenServer 6

XenServer supports more than 8 virtual CPUs in a guest, but the XenCenter GUI interface imposes a hard limit of 8. If you want to use more than 8 VCPUs for a guest, you must do so via the ‘xe’ command line:

xe vm-param-set  uuid=your_vms_uuid platform:cores-per-socket=4

xe vm-param-set uuid=your_vms_uuid VCPUs-at-startup=16

xe vm-param-set uuid=your_vms_uuid VCPUs-max=16

To find ‘your_vms_uuid’, you can use:

xe vm-list name-label=VMname

Where “VMname” is the human readable name you assigned in XenCenter.
It is not recommended to use more that 8 vCPUs. More vCPUs does not automatically equal more performance, especially if there are multiple VMs running on this XenServer instance. Also realize that a HT CPU does not equal a full extra CPU.


About the only scenario in which it is necessary to assign all of your physical CPUs over to a single guest if you’re doing 1:1 virtualization of an application that has been proven capable of scaling well to the number of CPUs you’re trying to use. Otherwise you’re just causing additional CPU scheduling overhead in the hypervisor.

To recover VMs from Failed Xenserver host:

1). First you have to figure out which server in the environment has failed. To do this, you’ll want to run the command,

 xe host-list params=uuid,name-label,host-metrics-live

  Any servers that come back with “host-metrics-live = false” have failed. Take note of the UUID of any failed servers

2) Then try to restart the service for the failed host by executing this command on the failed host using Putty

 service xapi restart

 3) Second, you must determine which VM’s were running on that failed server. You can do this by running the command,

 xe vm-list is-control-domain=false resident-on=UUID_of_failed_host 

4) Once you’ve determined which VM’s were running, you need to reset their power state in order to get them to move onto another server. To do this, run the command,

 xe vm-reset-powerstate uuid=UUID_of_failed_vm –force –multiple


You should see the VM’s in question now show up as halted in the Xencenter console. Restart each of the VM’s, and they should now boot up onto surviving pool member servers.

Note:


To do this, the VMs should be in shared storage.

To recover a pool from a failed pool Master:

To check whether pool master pool master has failed:

If you’ve tried to connect to the pool from the Xencenter console, and  if it fails – then your pool master is down.

Verify this by connecting to the xenserver host using putty and issue a command like “xe host-list” to see if you get a response.

If you get an error message like ““Cannot perform operation as the host is running in emergency mode” – then your Pool master is almost certainly down.

Solution:

Step 1:
               Try restarting the toolstack using this command
               Service xapi restart

Step 2:
               Try rebooting the Pool master to bring it online.

Step 3:
               Now the member XenServer hosts will accept only the pool-emergency commands, because the members try to reconnect for sixty seconds and then each member puts itself into emergency mode. So we are telling the pool members where the pool master is

 xe pool-emergency-reset-master master-address=<new_master_hostname>

Note:
This command instructs a slave member XenServer host to reset its master address to the new value and attempt to connect to it. This command should not be run on master hosts.

And then force the failed pool master to reboot as a pool master using the following command.

 xe pool-emergency-transition-to-master uuid=<host_uuid>

 If the master comes back up at this point, it re-establishes communication with its members, the members leave emergency mode, and operation returns to normal.

However if the master is really dead, choose one of the remaining members and run the command on any member server:

 xe pool-emergency-transition-to-master uuid=<host_uuid>

 Note:

This command instructs a member XenServer host to become the pool master. This command is only accepted by the XenServer host if it has transitioned to emergency mode, meaning it is a member of a pool whose master has disappeared from the network and could not be contacted for some number of retries.

Note that this command may cause the password of the host to reset if it has been modified since joining the pool.

Once it has become the master, issue the below command and the members will now point to the new pool master:

 xe pool-recover-slaves

 Note:

This command instructs the pool master to try and reset the master address of all members currently running in emergency mode.


 To recover VMs from Failed pool master:

1). First you have to figure out which server in the environment has failed. To do this, you’ll want to run the command,

 xe host-list params=uuid,name-label,host-metrics-live

  Any servers that come back with “host-metrics-live = false” have failed. Take note of the UUID of any failed servers

 2) Then try to restart the service for the failed host by executing this command on the failed host using Putty

 service xapi restart

3) Second, you must determine which VM’s were running on that failed server. You can do this by running the command,

xe vm-list is-control-domain=false resident-on=UUID_of_failed_host


 4) Once you’ve determined which VM’s were running, you need to reset their power state in order to get them to move onto another server. To do this, run the command,

xe vm-reset-powerstate uuid=UUID_of_failed_vm –force –multiple


 You should see the VM’s in question now show up as halted in the Xencenter console. Restart each of the VM’s, and they should now boot up onto surviving pool member servers.

 Note:

               To do this, the VMs should be in shared storage.

Service XAPI is unresponsive:

Step 1: First, you need to find out process PID (process id)

Use ps command or pidof command to find out process ID (PID). 

Or

 service xapi status will also give the output

Step #2: kill process using PID (process id)

Above command tell you PID xapi process. Now kill process using this PID:

# kill <pid>

OR

# kill -9 <PID>

Where -9 is special Kill signal, which will kill the process forcefully.

Internal error: Failure(“The ballooning daemon is not running”)

If you’re finding issues starting VM’s on your Citrix XenServers due to ballooning issues as mentioned below:

$ xe vm-start name-label=vmname

The server failed to handle your request, due to an internal error. The given message may give details useful for debugging the problem.
message: Failure(“The ballooning daemon is not running”)

Then try this command then restart VM to find it working.


$ xe-toolstack-restart

How to stop a hanged VM on Xenserver?

One of my development server was not accessible. It’s a VM under Xenserver and trying to fix things through XenCenter was quite a deadend. The console was not accessible from XenCenter, there was only a blank white screen. 

When the VM was being forced to shutdown, it gave an error message

“Another operation involving the object is currently in progress class: VM“.

There’s some discussion and proposed solution from on internet. Here’s quote from one of the post that finally fix it for me (you need to login to server’s shell to execute the below command):


1 – Type “xe vm-list” to get the uuid of the VM that is hung

2 – Type “list_domains” to list the domain uuid’s so you can determine the domain # of the VM above by matching the uuids from this output with the uuid for your VM from the previous command.

3 – Type “/opt/xensource/debug/destroy_domain -domid XX” where XX is the domain number from the previous command

4 – Type “xe vm-reboot uuid=XXXX –force” where XXXX is the uuid from the first vm-list command for your VM. (name-label may work but didn’t work this time for me so I used the uuid)

No Sound in windows VMs on Xenserver

To enable sound for windows VMs on Xenserver, the following settings have to be changed:

1. Go to control panel > administrative tools > terminal services > terminal services configuration, enter the “rdp-tcp” properties where you set various parameters of the RDP role offered by the TS.
2.  Go to the “Client settings” tab and UNTICK audio. By default, “ticked” options mean “disable”. So, remove the “disable” tick from audio, log off, re-logon and voila!
3.  Enable ‘Windows audio’ service in services.msc
4.  Enable audio in mstsc setting while connecting from client.

OR

1. Go to the sound control panel (Start-> (Settings->) Control Panel-> Sounds and Audio Devices)
2. Select Audio tab.
3. Select Microsoft RDP Audio Driver for the default playback device, if not already specified.
4. Check the “Use only default devices” checkbox at the bottom of the dialog.
5. Click the Voice tab.
6. Select Microsoft RDP Audio Driver for the default playback device, if not already specified.
7. Save settings by clicking on OK button.

Hotplug vCPUs to a VM in Xenserver:

To hotplug vCPUs to a VM in Xenserver, check whether updated xenserver tools are installed in the VM and then use the following command,

 vm-vcpu-hotplug new-vcpus=<new_vcpu_count> uuid=<uuid of the VM>

You can dynamically adjust the number of VCPUs available to a running paravirtual Linux VM within the number bounded by the parameter VCPUs-max.

Windows VMs always run with the number of VCPUs set to VCPUs-max and must be rebooted to change this value.

Note:

To find ‘your_vms_uuid’, you can use:


xe vm-list name-label=VMname

Backing up metadata of pooled installations

In a pool scenario, the master host provides an authoritative database which is synchronously mirrored by all the slave hosts in the pool. This provides a degree of built-in redundancy to a pool; the master can be replaced by any slave since each of them has an accurate version of the pool database.

Please refer to the XenServer Administrator’s Guide for more information on how to transition a slave into becoming a master host.

This level of protection may not be sufficient; for example, if your shared storage containing the VM data is backed up in multiple sites, but your local server storage (containing the pool metadata) is not. 

To fully recreate a pool given just a set of shared storage, you must first backup the xe pool-dump-database against the master host, and archive this file.

# xe pool-dump database file-name= /raja/backups/my_backup

 To subsequently restore this backup on a brand new set of hosts

1. Install a fresh set of XenServer hosts from the installation media, or via PXE.
2. Use the xe pool-restore-database on the host designated to be the new master.
3. Run the xe host-forget command on the new master to remove the old slave machines.
4. Use the xe pool-join command on the slave hosts to connect them to the new cluster.

Note:

Removing a xenserver host from a pool will delete all the user data on local HDD of that host.

XenServer 5.6 with XenCenter 5.6 is not showing the “Used Memory”:

1. At the XenServer console, select Network and Management Interface. If using SSH to connect to your XenServer or using XenCenter Console (tab), type xsconsole to access the following configuration:

2. Select Network Time (NTP).

3. Type in the password for the root user account.

4. Select Add an NTP Server (Optionally, select Remove All NTP Servers, then proceed to add new NTP servers).

5. Enter the IP address of the NTP server. (Hint: If not currently known, you can use nslookup on the Windows command line to get the IP address of your NTP server.)

6. Once the new time server has been accepted, validate that NTP is running by exiting to the XenServer command line, by selecting Quit in the xsconsole.

7. Verify the Network Time Protocol (NTP) is running on your XenServer, by using service ntpd status.

8. Ensure the new time source is accessible by cycling the network time protocol daemon, using service ntpd restart.

If there are errors, see if the time server is accessible using the ping command. Ping the server and ensure you have network connectivity and TCP port 123open. If ping fails, there is a networking problem outside the XenServer that must be addressed.

Advanced

To synchronize the hardware clock using the Network Time Protocol daemon, the following file, /etc/sysconfig/ntpd must be edited. Change the following line:

- from -

SYNC_HWCLOCK=no
- to -
SYNC_HWCLOCK=yes

How to Change NTP Source on XenServer:

1. At the XenServer console, select Network and Management Interface. If using SSH to connect to your XenServer or using XenCenter Console (tab), type xsconsole to access the following configuration:

2. Select Network Time (NTP).

3. Type in the password for the root user account.

4. Select Add an NTP Server (Optionally, select Remove All NTP Servers, then proceed to add new NTP servers).

5. Enter the IP address of the NTP server. (Hint: If not currently known, you can use nslookup on the Windows command line to get the IP address of your NTP server.)

6. Once the new time server has been accepted, validate that NTP is running by exiting to the XenServer command line, by selecting Quit in the xsconsole.

7. Verify the Network Time Protocol (NTP) is running on your XenServer, by using service ntpd status.

8. Ensure the new time source is accessible by cycling the network time protocol daemon, using service ntpd restart.

If there are errors, see if the time server is accessible using the ping command. Ping the server and ensure you have network connectivity and TCP port 123 open. If ping fails, there is a networking problem outside the XenServer that must be addressed.

Advanced

To synchronize the hardware clock using the Network Time Protocol daemon, the following file, /etc/sysconfig/ntpd must be edited. Change the following line:

- from -

SYNC_HWCLOCK=no
- to -
SYNC_HWCLOCK=yes

How to delete Orphaned VHDs from Xenserver SR?

Step 1: scan your SR for orphaned VHDs

vhd-util scan -f -m “VHD-*” -l “VG_XenStorage-<uuid_of_SR>” –p

for example:
[root@MytestCase]# vhd-util scan -f -m “VHD-*” -l “VG_XenStorage-99dfb8a9-2dcc-b610-45ca-2010fb0e475b” -p
vhd=VHD-75fa7730-091d-4d6b-bcae-79ae11efa79d capacity=21474836480 size=21525168128 hidden=1 parent=none
vhd=VHD-7ec19bd2-1c86-44c0-83f1-aab4c8bd7e41 capacity=26843545600 size=26902265856 hidden=1 parent=none
vhd=VHD-902f17f1-c254-4cde-8519-a004b8721581 capacity=64424509440 size=64558727168 hidden=1 parent=none
vhd=VHD-94bc9c71-6e33-4281-9c1d-9ecd6f1da4c0 capacity=16106127360 size=16143876096 hidden=1 parent=none
vhd=VHD-975c1983-449c-4021-9843-3a6f5d36f564 capacity=21474836480 size=21525168128 hidden=1 parent=none
vhd=VHD-cb0d1245-2445-455f-bb17-3331172def32 capacity=21474836480 size=21525168128 hidden=1 parent=none
vhd=VHD-d5c21ed0-3970-4ac9-8ce8-70a90f7ce147 capacity=16106127360 size=16143876096 hidden=1 parent=none
vhd=VHD-d6a48e7f-307c-4053-a2f2-f05e6abcab49 capacity=16106127360 size=16143876096 hidden=1 parent=none
vhd=VHD-fc646534-658a-4550-b7e8-f13c6fbfe935 capacity=16106127360 size=16143876096 hidden=1 parent=none
vhd=VHD-6a0e604d-439f-4ec5-85f1-090574cd8cce capacity=26843545600 size=26902265856 hidden=0 parent=none

Step 2: 

Make a full copy of the VM and delete the old VM. Then check whether the chain is removed from the SR. this process will remove the VHD chain whereas step 3 should be used to remove the Orphan VHDs

Step 3: 

if step 2 does not reclaim space, then try to remove the Orphan VHD

lvremove /dev/VG_Xenstorage-<uuid_of_SR>/VHD-uuid

For Ex:
[root@XENH3-TEST VG_XenStorage-3a490822-9d03-50ae-01a2-07e8d877bb17]# lvremove /dev/VG_XenStorage-3a490822-9d03-50ae-01a2-07e8d877bb17/VHD-b21c101c-8f66-4202-842a-eb7173bee109
  /dev/sdb: read failed after 0 of 4096 at 0: Input/output error
  /dev/sde: read failed after 0 of 4096 at 0: Input/output error
  Logical volume “VHD-b21c101c-8f66-4202-842a-eb7173bee109″ successfully removed

Note:

The above happens only if the VHD do not have a Symbolic link to it. you can check this by the following command

/dev/ VG_XenStorage-<uuid of ur SR># ls -l

Step 4: 

Change the hidden VHD to unhidden

vhd-util set -f hidden -v 0 -n <path to vhd file>

Note: to find out the path, type ls –l in /dev/ VG_XenStorage-<uuid of ur SR>

For Ex:

vhd-util set -f hidden -v 0 -n  /dev/mapper/VG_XenStorage–99dfb8a9–2dcc–b610–45ca–2010fb0e475b-VHD–6a0e604d–439f–4ec5–85f1–090574cd8cce

Now you will be able to see the VHD in the XenCenter.

Step 4: 

Now attach the disk to any VM, modify its size and start the VM
Now the disk which was used by dom 0 will be used by the VM


Step 5: 

Now stop the VM, then deattach the disk and finally delete it

How to install XenServer Tools on a Ubuntu VM?

Installing XenTools on Ubuntu is very easy;

1. attach the XenTools cdrom by selecting VM-> Install XenServer Tools in Xencenter
2. Then become root by issuing “sudo su“, then enter your password.
3. Mount the iso by issuing “mount /dev/cdrom /mnt“.
4. If your Ubuntu install is i386, issue:

“dpkg -i /mnt/Linux/xe-guest-utilities*i386.deb“

On amd64:

“dpkg -i /mnt/Linux/xe-guest-utilities*amd64.deb“

Unmount the cdrom by issuing “umount /mnt”

You will then notice that Suspend and XenMotion functionality will be enabled.
This concludes the steps needed to install a fully functional Ubuntu 10.04 server VM on XenServer 5.6.  

Note:

               If you are facing any issue with mounting the CD-ROM with \mnt directory of the VM, then you can manually copy the Linux tools from the Xentools.iso to the Linux VM using the WinSCP.

How to install XenServer Tools on a Redhat VM?

Installing XenTools on Red Hat is very easy;

1. Attach the XenTools cdrom by selecting VM-> Install XenServer Tools in Xencenter
2. Then login as root and enter your password.
3. Mount the iso by issuing “mount /dev/xvdd /mnt“.
4. Then type the command, cd /mnt/Linux/
5. If your redhat install is i386, issue:

“rpm -Uhv xe**x86.rpm“

On amd64:

“rpm -Uhv xe**x86_64.rpm“

Unmount the cdrom by issuing “umount /mnt”

You will then notice that Suspend and XenMotion functionality will be enabled.
This concludes the steps needed to install a fully functional Redhat server VM on XenServer.

Note:


If you are facing any issue with mounting the CD-ROM with \mnt directory of the VM, then you can manually copy the Linux tools from the Xentools.iso to the Linux VM using the WinSCP.

Creating VMs from templates or using FAST clone Method in XenServer creates a Link to the Original Disk

Whenever you create a VM from a template in XenServer, it actually generates a FAST CLONE of the disk.

This could have a storage impact because this process will generate a linked VHD clone disk. This means that the VM created from a template will have its disk linked to the template’s disk. If you have an operational process that creates VMs from templates, over time this could create a long linkage tree!

Limitations:

1. When this is done excessively, performance could degrade. 
2. Also if the link breaks anywhere, then all the VMs under the Linkage tree will lose its data.

Workaround from Citrix:

XenServer has a built-in limitation of 30 linked clones to avoid this issue (from the XenServer Administrators guide):

When cloning VMs based on a single VHD template, each child VM forms a chain where new changes are written to the new VM, and old blocks are directly read from the parent template. If the new VM was converted into a further template and more VMs cloned, then the resulting chain will result in degraded performance. XenServer supports a maximum chain length of 30, but it is generally not recommended that you approach this limit without good reason. If in doubt, you can always “copy” the VM using XenServer or the vm-copy command, which resets the chain length back to zero.

Mitigation

As the Admin guide snippet indicates, when excessive linking could be a concern, use the full copy method. To create a new template that is based on an existing template, perform the following for new templates:

 Right click template -> copy -> full copy as shown below;

Useful Commands

 Command 1:

A good way to determine if you have an excessive tree of cloned VHDs is using the vhd-util scan command:

# vhd-util scan -f -m “VHD-*” -l VG_XenStorage-<UUID_of_StorageRepository> -p

This will list all of the VHDs in your Storage Repository.  The “-p” switch is awesome because it will display the disks in a hierarchical structure:

From this output you can see which disks are fast clones of others.  The hidden column tells us which disks will be displayed in XenCenter when you look at the disks in a Storage Repository.

For kicks, you can use the xe vbd-list command to map the disks back to VMs:
#xe vbd-list vdi-uuid=<UUID_of_disk>

The UUID of the disk is what is displayed in the output from vhd-util scan.

 Command 2:

You can also use this command to determine the VDIs that is dependent on parent VHD.

 # vhd-util scan -f -m “VHD-*” -l VG_XenStorage-<UUID_of_StorageRepository> -p | grep parent=VHD

Xenserver does not reclaim space after deleting VDI or Snapshot.

The exact cause for the above error has already been mentioned in my another blog

http://sysadmino.blogspot.com/2014/03/creating-vms-from-templates-or-using.html 

To Solve this issue, do the following steps

Step 1: scan your SR for orphaned VHDs

vhd-util scan -f -m “VHD-*” -l “VG_XenStorage-<uuid_of_SR>” –p

for example:

[root@MytestCase]# vhd-util scan -f -m “VHD-*” -l “VG_XenStorage-99dfb8a9-2dcc-b610-45ca-2010fb0e475b” -p

vhd=VHD-75fa7730-091d-4d6b-bcae-79ae11efa79d capacity=21474836480 size=21525168128 hidden=1 parent=none

vhd=VHD-7ec19bd2-1c86-44c0-83f1-aab4c8bd7e41 capacity=26843545600 size=26902265856 hidden=1 parent=none

vhd=VHD-902f17f1-c254-4cde-8519-a004b8721581 capacity=64424509440 size=64558727168 hidden=1 parent=none

vhd=VHD-94bc9c71-6e33-4281-9c1d-9ecd6f1da4c0 capacity=16106127360 size=16143876096 hidden=1 parent=none

vhd=VHD-975c1983-449c-4021-9843-3a6f5d36f564 capacity=21474836480 size=21525168128 hidden=1 parent=none

vhd=VHD-cb0d1245-2445-455f-bb17-3331172def32 capacity=21474836480 size=21525168128 hidden=1 parent=none

vhd=VHD-d5c21ed0-3970-4ac9-8ce8-70a90f7ce147 capacity=16106127360 size=16143876096 hidden=1 parent=none

vhd=VHD-d6a48e7f-307c-4053-a2f2-f05e6abcab49 capacity=16106127360 size=16143876096 hidden=1 parent=none

vhd=VHD-fc646534-658a-4550-b7e8-f13c6fbfe935 capacity=16106127360 size=16143876096 hidden=1 parent=none

vhd=VHD-6a0e604d-439f-4ec5-85f1-090574cd8cce capacity=26843545600 size=26902265856 hidden=0 parent=none

Step 2: Make a full copy of the VM and delete the old VM. Then check whether the chain is removed from the SR. this process will remove the VHD chain whereas step 3 should be used to remove the Orphan VHDs

Step 3: if step 2 does not reclaim space, then try to remove the Orphan VHD

lvremove /dev/VG_Xenstorage-<uuid_of_SR>/VHD-uuid

For Ex:

[root@XENH3-TEST VG_XenStorage-3a490822-9d03-50ae-01a2-07e8d877bb17]# lvremove /dev/VG_XenStorage-3a490822-9d03-50ae-01a2-07e8d877bb17/VHD-b21c101c-8f66-4202-842a-eb7173bee109

  /dev/sdb: read failed after 0 of 4096 at 0: Input/output error

  /dev/sde: read failed after 0 of 4096 at 0: Input/output error

  Logical volume “VHD-b21c101c-8f66-4202-842a-eb7173bee109″ successfully removed

Note:

The above happens only if the VHD do not have a Symbolic link to it. you can check this by the following command

/dev/ VG_XenStorage-<uuid of ur SR># ls -l

Step 4: Change the hidden VHD to unhidden

vhd-util set -f hidden -v 0 -n <path to vhd file>

Note: to find out the path, type ls –l in /dev/ VG_XenStorage-<uuid of ur SR>

For Ex:

vhd-util set -f hidden -v 0 -n  /dev/mapper/VG_XenStorage–99dfb8a9–2dcc–b610–45ca–2010fb0e475b-VHD–6a0e604d–439f–4ec5–85f1–090574cd8cce

Now you will be able to see the VHD in the XenCenter.

Step 5: Now attach the disk to any VM, modify its size and start the VM

Now the disk which was used by dom 0 will be used by the VM

Step 6: Now stop the VM, then deattach the disk and finally delete it