Как вернуть свободное пространство в хранилище XenServer 6.5?

Question

[Argenon]

Не могу понять, это баг или фича: в XenServer (6.2/6.5) при создании снапшота, в хранилище создается дополнительный файл (VDI), основной файл жесткого диска переходит в состояние read-only и все изменения пишутся в новый. После удаления снапшота, не происходит слияния нового файла с основным. И если изменений достаточно много, то место в хранилище стремится к нулю.

То есть мы получаем, например, следующую структуру:
/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)

где файлы 16e48cdf... ea207baf... являются базовыми копиями (base copy), а 7b74266a... и 69e56b11... дочерними соответственно.

Почитал форумы цитрикса, и как я понял, в версиях 5.5/5.6 существовал плагин для слияния VDI. Как быть в версиях 6.2/6.5 не могу понять... Может кто-то встречался с этой проблемой или знает как ее решить?

Answer 1

[Argenon]

На одном из серверов все-таки запускается процесс сращения дисков. После удаления снапшота я вижу в логах:

Coalescing parent *3018f340[VHD](80.000G//184.000M|ao)

И в результате получаю три файла вместо шести:

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)

Но на другом сервере после сканирования в логах следующее:

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)

И в конце:

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

И как в таком случае запустить сращение я не понимаю. Работает только метод перемещения VDI в другое хранилище и возврат обратно. Но как бы это не вариант все время руками тягать диски.

Ну и на третьем сервере ситуация такая:
был один основной и два дочерних:

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)

После удаления снапшота запустилось сращение и в итоге стало так:

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)

И после нового сканирования хранилища получаем:

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

Не пойму где логика. Почему в последнем случае остался дочерний файл?