How to reclaim free space in XenServer 6.5 storage?

Question

XenServer

I can’t understand if this is a bug or a feature: in XenServer (6.2/6.5) when creating a snapshot, an additional file (VDI) is created in the storage, the main file of the hard disk goes into read-only state and all changes are written to the new one. After deleting a snapshot, the new file does not merge with the main one. And if there are a lot of changes, then the storage space tends to zero.
That is, we get, for example, the following structure:
/var/log/SMlog

Jun  8 21:50:40 xenserver SMGC: [10978] SR 4dd9 ('Local storage') (6 VDIs in 4 VHD trees): 
Jun  8 21:50:40 xenserver SMGC: [10978]         *16e48cdf(20.000G/11.147G)
Jun  8 21:50:40 xenserver SMGC: [10978]             7b74266a(20.000G/13.474G)
Jun  8 21:50:40 xenserver SMGC: [10978]         0a24b7f4(8.000M/8.016M)
Jun  8 21:50:40 xenserver SMGC: [10978]         *ea207baf(20.000G/3.309G)
Jun  8 21:50:40 xenserver SMGC: [10978]             69e56b11(20.000G/45.500K)
Jun  8 21:50:40 xenserver SMGC: [10978]         2d966d57(20.000G/3.528G)

where files 16e48cdf... ea207baf... are base copies, and 7b74266a... and 69e56b11... are children, respectively.
I read the citrix forums, and as I understand it, in versions 5.5 / 5.6 there was a plugin for merging VDI. How to be in versions 6.2 / 6.5 I can’t understand ... Maybe someone met this problem or knows how to solve it?

Answer 1

On one of the servers, the disk splicing process is still running. After deleting the snapshot, I see in the logs:
And as a result I get three files instead of six:

Jun  8 23:16:45 xenserver-sam SMGC: [22019] SR 8181 ('Local storage') (3 VDIs in 3 VHD trees): 
Jun  8 23:16:45 xenserver-sam SMGC: [22019]         a3977b82[VHD](40.000G//40.086G|ao)
Jun  8 23:16:45 xenserver-sam SMGC: [22019]         976a77c4[VHD](80.000G//80.164G|ao)
Jun  8 23:16:45 xenserver-sam SMGC: [22019]         28960e01[VHD](80.000G//80.164G|ao)

But on another server after scanning in the logs the following:

Jun  8 21:50:40 xenserver SMGC: [10978] SR 4dd9 ('Local storage') (6 VDIs in 4 VHD trees): 
Jun  8 21:50:40 xenserver SMGC: [10978]         *16e48cdf(20.000G/11.147G)
Jun  8 21:50:40 xenserver SMGC: [10978]             7b74266a(20.000G/13.474G)
Jun  8 21:50:40 xenserver SMGC: [10978]         0a24b7f4(8.000M/8.016M)
Jun  8 21:50:40 xenserver SMGC: [10978]         *ea207baf(20.000G/3.309G)
Jun  8 21:50:40 xenserver SMGC: [10978]             69e56b11(20.000G/45.500K)
Jun  8 21:50:40 xenserver SMGC: [10978]         2d966d57(20.000G/3.528G)

And in the end:

Jun  8 21:50:40 xenserver SMGC: [10978] No work, exiting
Jun  8 21:50:40 xenserver SMGC: [10978] In cleanup
Jun  8 21:50:40 xenserver SMGC: [10978] SR 4dd9 ('Local storage') (6 VDIs in 4 VHD trees): no changes

And in this case, I do not understand how to start the fusion. Only the method of moving VDI to another storage and returning back works. But no matter how it is not an option to pull discs all the time with your hands.
Well, on the third server the situation is as follows: there
was one main and two child:

Jun  8 23:28:03 xenserver1 SMGC: [28474] SR e24f ('Local storage') (4 VDIs in 2 VHD trees): showing only VHD trees that changed:
Jun  8 23:28:03 xenserver1 SMGC: [28474]         *05c089e7(130.000G/127.223G)
Jun  8 23:28:03 xenserver1 SMGC: [28474]             *6b610561(130.000G/4.411G)
Jun  8 23:28:03 xenserver1 SMGC: [28474]             bbe7cfff(130.000G/8.319G)

After deleting the snapshot, the fusion started and ended up like this:

Jun  8 23:29:00 xenserver1 SMGC: [32318] SR e24f ('Local storage') (3 VDIs in 2 VHD trees): 
Jun  8 23:29:00 xenserver1 SMGC: [32318]         *05c089e7(130.000G/127.223G)
Jun  8 23:29:00 xenserver1 SMGC: [32318]             bbe7cfff(130.000G/8.319G)

And after a new storage scan we get:

Jun  8 23:29:00 xenserver1 SMGC: [32318] No work, exiting
Jun  8 23:29:00 xenserver1 SMGC: [32318] In cleanup
Jun  8 23:29:00 xenserver1 SMGC: [32318] SR e24f ('Local storage') (3 VDIs in 2 VHD trees): no changes

I don't understand where the logic is. Why is there a child file left in the latter case?