I have had this problem from Xenserver 5.5 through 6.02 and a total change in hardware. The only sure way to fix this is to copy the server to a new storage repository and delete the old VM. Our main servers run at about 2% cpu, so waiting for a background process like coalesce to finish is not an issue.
/usr/bin/vhd-util scan -f -a -p -c -m VHD-* -l `/usr/sbin/vgdisplay|grep Name|awk '{print $3}'`
gets me a list of all the chains, as Mr. Ferrao indicates above. If you redirect that list to a file, then you will see what I call "good" chains and "bad" chains.
A good chain:
vhd=VHD-7c12552c-96fb-413f-8cc7-4cb7a6a1bd88 capacity=8589934592 size=4777312256 hidden=1 parent=none
vhd=VHD-f9a91117-0062-473b-89f9-95030f57b736 capacity=8589934592 size=8615100416 hidden=0 parent=VHD-7c12552c-96fb-413f-8cc7-4cb7a6a1bd88
vhd=VHD-1d070bb9-1dda-4e13-a732-9bbc3e7e0af2 capacity=8589934592 size=4236247040 hidden=1 parent=VHD-7c12552c-96fb-413f-8cc7-4cb7a6a1bd88
vhd=VHD-6f9b7573-0ef5-44d9-bde9-47587f78fc86 capacity=8589934592 size=8388608 hidden=0 parent=VHD-1d070bb9-1dda-4e13-a732-9bbc3e7e0af2
vhd=VHD-f15cc2d8-d1ee-4b11-9853-5c84cab81715 capacity=8589934592 size=2646605824 hidden=1 parent=VHD-1d070bb9-1dda-4e13-a732-9bbc3e7e0af2
vhd=VHD-32266eef-6665-4aac-83c5-5e1ab0c01861 capacity=8589934592 size=8388608 hidden=0 parent=VHD-f15cc2d8-d1ee-4b11-9853-5c84cab81715
vhd=VHD-a910a28c-a484-48ae-86fb-8a53eab7db65 capacity=8589934592 size=2176843776 hidden=1 parent=VHD-f15cc2d8-d1ee-4b11-9853-5c84cab81715
vhd=VHD-ecf62cd9-a76f-4a28-a27d-6a1f7b464554 capacity=8589934592 size=8388608 hidden=0 parent=VHD-a910a28c-a484-48ae-86fb-8a53eab7db65
vhd=VHD-1ec4deff-f04f-4272-9edc-78b0f9fd9cff capacity=8589934592 size=2122317824 hidden=1 parent=VHD-a910a28c-a484-48ae-86fb-8a53eab7db65
vhd=VHD-026f73b5-8600-47ee-ada1-3628b4a04a19 capacity=8589934592 size=8388608 hidden=0 parent=VHD-1ec4deff-f04f-4272-9edc-78b0f9fd9cff
vhd=VHD-4659cef9-64a3-4fca-bf54-3bcc23665c36 capacity=8589934592 size=8615100416 hidden=0 parent=VHD-1ec4deff-f04f-4272-9edc-78b0f9fd9cff
I realize that the box is wrapping the lines here, so not obvious, but there is normally a hidden and unhidden line, then another hidden, unhidden line (hidden=1 or hidden=0) Only the hidden=0 lines can be seen in XenCenter as snapshots. However, the vms that are building towards a "chains too long" status look different:
vhd=VHD-970758dc-a396-4503-ae24-ebf093759947 capacity=19864223744 size=19633537024 hidden=1 parent=none
vhd=VHD-9ef661b3-d20e-401a-be01-d4a020960c17 capacity=19864223744 size=1769996288 hidden=1 parent=VHD-970758dc-a396-4503-ae24-ebf093759947
vhd=VHD-00864374-1fa2-4492-9c1c-0e6fdf89de7a capacity=19864223744 size=3133145088 hidden=1 parent=VHD-9ef661b3-d20e-401a-be01-d4a020960c17
vhd=VHD-101649bf-13af-4ba2-948d-d7db192ca7ad capacity=19864223744 size=1950351360 hidden=1 parent=VHD-00864374-1fa2-4492-9c1c-0e6fdf89de7a
vhd=VHD-83dca990-f158-41bc-b32b-69f8f8862c15 capacity=19864223744 size=3233808384 hidden=1 parent=VHD-101649bf-13af-4ba2-948d-d7db192ca7ad
vhd=VHD-8cb96357-c872-40e2-adb2-aa1bbe613dca capacity=19864223744 size=1610612736 hidden=1 parent=VHD-83dca990-f158-41bc-b32b-69f8f8862c15
vhd=VHD-84dca005-af4b-4615-88cb-124977b13c8e capacity=19864223744 size=3468689408 hidden=1 parent=VHD-8cb96357-c872-40e2-adb2-aa1bbe613dca
vhd=VHD-b0904a6f-c169-4d6b-816d-9d775600535d capacity=19864223744 size=1925185536 hidden=1 parent=VHD-84dca005-af4b-4615-88cb-124977b13c8e
vhd=VHD-e268d580-a245-4960-a13f-9a9c252fc9e8 capacity=19864223744 size=3980394496 hidden=1 parent=VHD-b0904a6f-c169-4d6b-816d-9d775600535d
vhd=VHD-ac706540-ba7c-4eba-b919-aa88784ae796 capacity=19864223744 size=1933574144 hidden=1 parent=VHD-e268d580-a245-4960-a13f-9a9c252fc9e8
vhd=VHD-96a39f51-5c1a-4234-974e-7de91b4e49f2 capacity=19864223744 size=3170893824 hidden=1 parent=VHD-ac706540-ba7c-4eba-b919-aa88784ae796
vhd=VHD-32b1d67c-1011-460b-ac5d-5d83ade7e5f2 capacity=19864223744 size=1673527296 hidden=1 parent=VHD-96a39f51-5c1a-4234-974e-7de91b4e49f2
vhd=VHD-81f9dda9-e26d-49bb-97f3-72cbb9a4c4bf capacity=19864223744 size=19910361088 hidden=0 parent=VHD-32b1d67c-1011-460b-ac5d-5d83ade7e5f2
Again, I don't know if this will come out without wrapping, but notice that the lines are all hidden, hidden, hidden etc. instead of hidden, unhidden, hidden,unhidden etc. as in the first example.
I made a set of scripts to add and subtract each set of hidden, unhidden lines, and if the hiddens start to add up beyond 5 or 6, it emails me. I don't know how much trouble it is in your case to run the line above and look at the resulting list of chains twice a week, but I find that a 3 second glance immediately shows me double-stepped (good) chains vs singly indented lines for the "bad" chains. (We run about 35 vms on a pool of 2 machines, so not a big operation.)
How to work back from the "bad" chain to see what server belongs to it: A simple manual way is to copy out the "bad" chain(s) and run a script on them. I run this:
#!/bin/bash
TODAY=`date +"%m.%d.%y"`
IFS='
'
filearray=(`cat $1`)
hidcnt=0
for lin in ${filearray[@]}
do
echo $lin|grep "hidden=0" >NULL
if [ ${PIPESTATUS[1]} == "0" ];
then
matchstr=$(echo $lin|awk '{print $1}'|awk -F"-" '{print $6}')
echo "vhd search string=" $matchstr
/var/log/namefromchain.sh $matchstr
fi
done
which calls namefromchain.sh, which is:
xe vbd-list|grep -B1 $1|grep vm-name-label|awk -F"RO): " '{print $2}'
I can't remember why they are two separate scripts, but I'm not very experienced at this stuff. You will have to take the warts off and adapt to your situation, but the concepts are there.