Xen local SR, LVM, VHD

Текст пока альфа-версии. Поток разума)
Сперва вспомним матчасть:
как найти uuid ВМ по ее имени
xe vm-list name-label=

как получить параметры ВМ по ее uuid
xe vm-param-list uuid=

как найти все VBD, VDI для ВМ по ее имени
xe vbd-list vm-name-label=
получим свойство vdi-uuid для каждого из VBD

как найти LVM-группу, соответствующую SR:
VG Name = "VG_XenStorage-" + sr-uuid
vgdisplay -v VG Name - получим список LVM дисков
Free PE / Size 1309 / 5.11 GB - покажет сколько свободного места на SR.
Тут видим проблему, решение которой приведет нас в будущем к еще большим проблемам. Но пока мы этого не знаем)
Цифра отличается от точго что пишет XenCenter и от суммы всех в_дисков, т.е. происходит утечка места на SR, предположительно при создании/удалении

в_дисков.
как найти LVM том(диск) , соответствующий xen VDI диску:
1 вариант:
LV Name = "/dev/" + VG Name + "/VHD-" + vdi_uuid
LV Status = NOT available кстати не говорит от том, что этот диск не используется
2 вариант:
lvdisplay-v LV Name

получить список всех VDI для SR
xe vdi-list sr-uuid=2bc17aca-6728-11a7-91d2-9249a10d9a11|grep '^uuid ( RO)'
получить список всех LV для LVMG

но можно и проще. получаем список всех VDI для SR как есть, и сравниваем по именам со списком дисков для SR в XenCenter . Те VDI, которые остались не

именованы , являются лишними. Начинаем их убивать (выяснилось позднее: этот шаг приводит к невозможности назначить любой диск VDI на этом SR любой VM.

SR становится практически бесполезным и нечитаемым)

xe vdi-destroy uuid=c1f7b670-374c-44a8-85e2-814d9c50a9ec
но VHD может и не убиться, если он уже убит, тогда просто отцепляем его запись:
xe vdi-forget uuid=c1f7b670-374c-44a8-85e2-814d9c50a9ec
потом убиваем собсно LVD
[root@xenserver1 ~]# umount /dev/VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11/VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec
umount: /dev/VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11/VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec: not mounted
[root@xenserver1 ~]# lvremove -d /dev/VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11/VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec
обычно LVD успешно убивается и место высвобождается, типа так:
Do you really want to remove active logical volume "хххххххх"? [y/n]: y
Logical volume "хххххххх" successfully removed

но так может и не случиться, например получим ответ: Can't remove open logical volume "VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec"
это значит, что LVD держит какой-то процесс. смотрим, кто держит динамический диск:
lvdisplay /dev/VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11/VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec
--- Logical volume ---
LV Name /dev/VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11/VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec
VG Name VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11
LV UUID hrl6YB-wo8m-i90b-wunL-Kp6A-gGPo-W3Cd8y
LV Write Access read only
LV Status available
# open 1
LV Size 29.24 GB
Current LE 7486
Segments 5
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 251:5
ага, одна ссылка, надо узнать что за процесс
fuser /dev/VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11/VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec
/dev/VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11/VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec: 12202
видим что PID 12202 , кто это?
[root@xenserver1 ~]# ps ax|grep 12202
12202 ? SL 0:00 tapdisk /var/run/tap/tapctrlwrite3 /var/run/tap/tapctrlread3
а tapdisk это библиотека доступа к блочным устройствам самого xen`a, см. http://www.xen.org/files/summit_3/XenSummitBlockTalk.pdf
прибиваем процесс. при этом LVD удаляется сам, но место не высвобождается.
Вроде есть альтернатива , команда для LV , деактивирующая его: lvchange -an , не тестировал.
Свободное место на хранилище постоянно смотрим командой
vgdisplay -v VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11|more
Alloc PE / Size 42908 / 167.61 GB
Free PE / Size 14750 / 57.62 GB
пробуем перечитать хранилище командой xe sr-scan uuid=, место освободилось.
чтобы проверить, что используемое на хранилище место соответствует используемым VHD на SR, сравним в списка:
получить список всех VDI для SR
xe vdi-list sr-uuid=2bc17aca-6728-11a7-91d2-9249a10d9a11|grep '^uuid ( RO)'
из этого списка переносим в excel имя диска и его размер, суммируем размеры.
получить список всех LV для LVMG
vgdisplay -v VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11|more
или командой lvs, она лаконичнее.
в итоге
у нас получилось, что списки совпадают, но итоговый размер по списку меньше того, что занято на диске из вывода команды vgdisplay.
dmsetup info VG_XenStorage--2bc17aca--6728--11a7--91d2--9249a10d9a11-VHD--c1f7b670--374c--44a8--85e2--814d9c50a9ec
lvdisplay /dev/VG_XenStorage-2bc17aca-6728-11a7-91d2-9249a10d9a11/VHD-c1f7b670-374c-44a8-85e2-814d9c50a9ec
после долгих мытарств и экспериментов, после которых нагнулись почти все диски на локальном SR выяснилось, что:
LV c названием "base copy" не являются лишними, несмотря на то, что на них не указывают записи xe VDI. Это основные части виртуальных дисков, которые

образуются при операциях Fast Clone, Snapshot. При этом VDI указывает на разностный LV, а тот уже использует LV "base copy" как основную информацию диска.

Вообще это стандартный режим работы LVM Snapshot.
Когда LV используется, напрямую или опосредованно как LV "base copy" , его "держит" специальный процесс tapdisk. Это можно посмотреть так:
[root@xenserver1 ~]# fuser /dev/VG_XenStorage-210d867d-c6fb-2609-624a-f3151adf7d6b/VHD-1cec624e-1c5e-4b2c-9497-5c0acf08c0e3
/dev/VG_XenStorage-210d867d-c6fb-2609-624a-f3151adf7d6b/VHD-1cec624e-1c5e-4b2c-9497-5c0acf08c0e3: 14613
[root@xenserver1 ~]# ps ax|grep 14613
1645 pts/4 S+ 0:00 grep 14613
14613 ? SL 0:00 tapdisk /var/run/tap/tapctrlwrite4 /var/run/tap/tapctrlread4
а вот все задействованные диски. Это совпадает с количеством примапленных дисков у работающих VM в XenCenter.
[root@xenserver1 ~]# ps ax|grep tapdisk
1649 pts/4 S+ 0:00 grep tapdisk
6019 ? SL 0:14 tapdisk /var/run/tap/tapctrlwrite1 /var/run/tap/tapctrlread1
6061 ? SL 0:00 tapdisk /var/run/tap/tapctrlwrite2 /var/run/tap/tapctrlread2
6439 ? SL 0:00 tapdisk /var/run/tap/tapctrlwrite3 /var/run/tap/tapctrlread3
14613 ? SL 0:00 tapdisk /var/run/tap/tapctrlwrite4 /var/run/tap/tapctrlread4
[root@xenserver1 ~]# ls -l /var/run/tap/
total 0
prwxr-xr-x 1 root root 0 Oct 29 11:35 tapctrlread1
prwxr-xr-x 1 root root 0 Oct 29 11:35 tapctrlread2
prwxr-xr-x 1 root root 0 Oct 29 11:36 tapctrlread3
prwxr-xr-x 1 root root 0 Oct 29 17:37 tapctrlread4
prwxr-xr-x 1 root root 0 Oct 29 16:15 tapctrlread5
prwxr-xr-x 1 root root 0 Oct 29 11:35 tapctrlwrite1
prwxr-xr-x 1 root root 0 Oct 29 11:35 tapctrlwrite2
prwxr-xr-x 1 root root 0 Oct 29 11:36 tapctrlwrite3
prwxr-xr-x 1 root root 0 Oct 29 17:37 tapctrlwrite4
prwxr-xr-x 1 root root 0 Oct 29 16:15 tapctrlwrite5
вот эти файлы - видимо флаги работы с дисками, но что за атрибут файла "p"? Знаю атрибуты "l" = "link," "d" = "directory.","b" или "c" =Device file. а "p"?
Ааа, это "named pipe", т.е. программа tapdisk использует 2 именованных канала, один для ввода, другой для вывода, один канал направлен видимо в сторону LV

диска, а другой - в сторону Xen VM, которая использует диск.

диски
a3da1eac-060d-4759-8a1d-a326796403e3
c1f7b670--374c--44a8--85e2--814d9c50a9ec