Жила-была у меня машина с XenServer 6.5 на борту и несколькими массивами из SATA-дисков. В последнее время перестало хватать быстродействия SATA и было решено заменить один массив на SAS-диски. Для этих целей был найден RAID-контроллер Adaptec 3805 (знаю, что старье, зато халява).
После успешного создания RAID-массива из SAS-дисков(каюсь, использовал адаптековский raid) и добавления оного как lvm-storage, начал перенос одного из образов виртуальных машин на него. В процессе созерцания прогресса переноса закралось подозрение о неладном, так как изменился тон звучания сервера. А когда сервер ушел в самостоятельную перезагрузку, я начал понемногу седеть… И окончательно меня добило то, что после перезагрузки я не нашел переносимый образ ни в одном из хранилищ, а само новое хранилище отображается со статусом «не доступно».
После непродолжительной прогулки для успокоения нервов и чашки кофе я закатал рукава (ага, на футболке то) и начал думать как восстановить образ…
Для начала, естественно, полез в логи и увидел, что при создании хранилища из массива SAS произошла ошибка:
Ошибка означает, что хранилище не доступно. Я решил проверить физические тома lvm через pvdisplay и не увидел созданного тома на SAS-массиве. pvs тоже не обнаружил тома.
Это означало, что хранилище, на самом деле, не создалось. Точнее создался объект хранилища в XenServer, но при этом он не был связан с физическим хранилищем. Почему XenServer так себя повел, и, тем более, позволил перенести образ в это хранилище, я так и не выяснил.
Получается, что образ на SAS-массиве можно даже не искать, так как физически на него ничего не переносилось. Значит нужно пробовать восстанавливать образ с хранилища, на котором он был изначально.
Поиск в интернете на тему восстановления логических томов LVM задал начальный вектор раскопок.
LVM хранит свою текущую конфигурацию в /etc/lvm/backup/ и, в обычных условиях, архив старых конфигураций в виде бинарных файлов, в /etc/lvm/archive/. UUID хранилища XenServer соответствует имени LVM VolumeGroup. Но, оказывается, в XenServer этот самый архив отключен:
Дальнейшие поиски показали, что lvm хранит архив всех конфигураций VolumeGroup в начальных секторах этих самых VolumeGroup. Так как у меня хранилище расположено на отдельном массиве, то просматриваю начало этого массива:
Если видно что-то похожее на конфиги, то можно снять дамп этих секторов для более удобного чтения (в моем случае архив занимал 100Мб):
Так же дамп можно снять через команду lvmdump.
В дампе ищу конфиг, дата которого предшествует моменту пропажи образа:
Из этого конфига нужна только запись, соответствующая пропавшему образу (та запись, которая отсутствует в текущем конфиге в /etc/lvm/backup/<Соответствующий VG>, в моем случае VHD-6bdf21c1-cc52-45d1-ab9e-56bd7aa9bc89). Переписываю ее в текущую конфигурацию и даю LVM команду восстановить VG из бэкапа:
Проверяю, что Logical Volume подхватился:
Если сейчас сделать поиск по хранилищу (через XenCenter или xe sr-scan), то XenServer успешно затрет эту запись и все придется делать заново. Как я понял, XenServer не видит у себя VDI (образа диска) с UUID, соответствующем UUID нашему восстановленному Logical Volume.
XenServer, при использовании lvm, хранит образы дисков напрямую в Logcal Volume. Точнее Logical Volume это и есть VHD-образ. Поэтому я предположил, что можно заставить XenServer увидеть образ, скопировав его поверх другого, такого же размера.
Для копирования раздела активирую разделы в этом VG:
Теперь есть доступ к разделу LVM, значит можно скопировать этот раздел с помощью dd:
После того, как скопированный образ добавился в виртуальной машине, а так же после того, как машина стартанула с этого образа, моему счастью не было предела!
Однако не все так радужно. Нужно было еще выключить сервер, чтобы вытащить глючный контроллер. А когда я его включил образ снова пропал! Получается, что XenServer при запуске сверяет UUID образа в LVM c UUID в своей базе и, если они не совпадают, образ удаляется.
Пока ковырял LVM заметил, что при переносе образа из одного хранилища в другое так же меняется и его UUID и, исходя из этого, предположил, что можно окончательно воскресить образ, просто скопировав переписанный через dd образ в другое хранилище. Это должно обновить UUID в образе, сопоставив его в UUID в базе. Повторяем все процедуры заново, после чего переносим образ на временно созданное для этого хранилище, добавляем к виртуальной машине и пробуем ее запустить. Запуск проходит нормально.
Перезагружаем сервер, трясущимися от нетерпения и усталости руками проверяем список образов и… образ на месте! Счастью нет предела и, довольный собой, я удаляюсь в закат…
После успешного создания RAID-массива из SAS-дисков(каюсь, использовал адаптековский raid) и добавления оного как lvm-storage, начал перенос одного из образов виртуальных машин на него. В процессе созерцания прогресса переноса закралось подозрение о неладном, так как изменился тон звучания сервера. А когда сервер ушел в самостоятельную перезагрузку, я начал понемногу седеть… И окончательно меня добило то, что после перезагрузки я не нашел переносимый образ ни в одном из хранилищ, а само новое хранилище отображается со статусом «не доступно».
После непродолжительной прогулки для успокоения нервов и чашки кофе я закатал рукава (ага, на футболке то) и начал думать как восстановить образ…
Для начала, естественно, полез в логи и увидел, что при создании хранилища из массива SAS произошла ошибка:
Error code: SR_BACKEND_FAILURE_47
Ошибка означает, что хранилище не доступно. Я решил проверить физические тома lvm через pvdisplay и не увидел созданного тома на SAS-массиве. pvs тоже не обнаружил тома.
Это означало, что хранилище, на самом деле, не создалось. Точнее создался объект хранилища в XenServer, но при этом он не был связан с физическим хранилищем. Почему XenServer так себя повел, и, тем более, позволил перенести образ в это хранилище, я так и не выяснил.
Получается, что образ на SAS-массиве можно даже не искать, так как физически на него ничего не переносилось. Значит нужно пробовать восстанавливать образ с хранилища, на котором он был изначально.
Поиск в интернете на тему восстановления логических томов LVM задал начальный вектор раскопок.
LVM хранит свою текущую конфигурацию в /etc/lvm/backup/ и, в обычных условиях, архив старых конфигураций в виде бинарных файлов, в /etc/lvm/archive/. UUID хранилища XenServer соответствует имени LVM VolumeGroup. Но, оказывается, в XenServer этот самый архив отключен:
/etc/lvm/lvm.conf
# Configuration of metadata backups and archiving. In LVM2 when we
# talk about a 'backup' we mean making a copy of the metadata for the
# *current* system. The 'archive' contains old metadata configurations.
# Backups are stored in a human readeable text format.
backup {
# Should we maintain a backup of the current metadata configuration?
# Use 1 for Yes; 0 for No.
# Think very hard before turning this off!
backup = 1
# Where shall we keep it?
# Remember to back up this directory regularly!
backup_dir = "/etc/lvm/backup"
# Should we maintain an archive of old metadata configurations.
# Use 1 for Yes; 0 for No.
# On by default. Think very hard before turning this off.
archive = 0
# Where should archived files go?
# Remember to back up this directory regularly!
archive_dir = "/etc/lvm/archive"
# What is the minimum number of archive files you wish to keep?
retain_min = 10
# What is the minimum time you wish to keep an archive file for?
retain_days = 30
}
# talk about a 'backup' we mean making a copy of the metadata for the
# *current* system. The 'archive' contains old metadata configurations.
# Backups are stored in a human readeable text format.
backup {
# Should we maintain a backup of the current metadata configuration?
# Use 1 for Yes; 0 for No.
# Think very hard before turning this off!
backup = 1
# Where shall we keep it?
# Remember to back up this directory regularly!
backup_dir = "/etc/lvm/backup"
# Should we maintain an archive of old metadata configurations.
# Use 1 for Yes; 0 for No.
# On by default. Think very hard before turning this off.
archive = 0
# Where should archived files go?
# Remember to back up this directory regularly!
archive_dir = "/etc/lvm/archive"
# What is the minimum number of archive files you wish to keep?
retain_min = 10
# What is the minimum time you wish to keep an archive file for?
retain_days = 30
}
Дальнейшие поиски показали, что lvm хранит архив всех конфигураций VolumeGroup в начальных секторах этих самых VolumeGroup. Так как у меня хранилище расположено на отдельном массиве, то просматриваю начало этого массива:
# hexdump -C /dev/md1 | less
Если видно что-то похожее на конфиги, то можно снять дамп этих секторов для более удобного чтения (в моем случае архив занимал 100Мб):
# dd if=/dev/md1 of=dump.conf bs=100M count=1
Так же дамп можно снять через команду lvmdump.
В дампе ищу конфиг, дата которого предшествует моменту пропажи образа:
Конфигурация
VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191 {
id = "TprMi6-z1OR-BGcz-uReP-if22-6122-tfu0zP"
seqno = 5
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192 # 4 Megabytes
max_lv = 0
max_pv = 0
metadata_copies = 0
physical_volumes {
pv0 {
id = "0gexgQ-urcH-GZd0-iehs-ne0y-6JYz-ZTGbna"
device = "/dev/md1" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 473571375 # 225.816 Gigabytes
pe_start = 20608
pe_count = 57806 # 225.805 Gigabytes
}
}
logical_volumes {
MGT {
id = "Znwuly-qcgx-AHbd-1qg9-Jjp8-eogk-N5ASme"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1
segment1 {
start_extent = 0
extent_count = 1 # 4 Megabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0
]
}
}
VHD-6bdf21c1-cc52-45d1-ab9e-56bd7aa9bc89 {
id = "yLMfFb-9yOk-vf1N-FTmz-5NiL-F5lx-NNmkuN"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1
segment1 {
start_extent = 0
extent_count = 12827 # 50.1055 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 1
]
}
}
}
}
Из этого конфига нужна только запись, соответствующая пропавшему образу (та запись, которая отсутствует в текущем конфиге в /etc/lvm/backup/<Соответствующий VG>, в моем случае VHD-6bdf21c1-cc52-45d1-ab9e-56bd7aa9bc89). Переписываю ее в текущую конфигурацию и даю LVM команду восстановить VG из бэкапа:
vgcfgrestore -f /etc/lvm/backup/VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191 -v VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191
Проверяю, что Logical Volume подхватился:
# lvdisplay
--- Logical volume ---
LV Name /dev/VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191/MGT
VG Name VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191
LV UUID Znwuly-qcgx-AHbd-1qg9-Jjp8-eogk-N5ASme
LV Write Access read/write
LV Status available
# open 0
LV Size 4.00 MB
Current LE 1
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
--- Logical volume ---
LV Name /dev/VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191/VHD-6bdf21c1-cc52-45d1-ab9e-56bd7aa9bc89
VG Name VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191
LV UUID yLMfFb-9yOk-vf1N-FTmz-5NiL-F5lx-NNmkuN
LV Write Access read/write
LV Status available
# open 0
LV Size 50.11 GB
Current LE 1
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
Если сейчас сделать поиск по хранилищу (через XenCenter или xe sr-scan), то XenServer успешно затрет эту запись и все придется делать заново. Как я понял, XenServer не видит у себя VDI (образа диска) с UUID, соответствующем UUID нашему восстановленному Logical Volume.
XenServer, при использовании lvm, хранит образы дисков напрямую в Logcal Volume. Точнее Logical Volume это и есть VHD-образ. Поэтому я предположил, что можно заставить XenServer увидеть образ, скопировав его поверх другого, такого же размера.
Для копирования раздела активирую разделы в этом VG:
# vgchange -ay VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191
Теперь есть доступ к разделу LVM, значит можно скопировать этот раздел с помощью dd:
# dd if=/dev/VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191/VHD-6bdf21c1-cc52-45d1-ab9e-56bd7aa9bc89 of=image.vhd bs=100M
После того, как скопированный образ добавился в виртуальной машине, а так же после того, как машина стартанула с этого образа, моему счастью не было предела!
Однако не все так радужно. Нужно было еще выключить сервер, чтобы вытащить глючный контроллер. А когда я его включил образ снова пропал! Получается, что XenServer при запуске сверяет UUID образа в LVM c UUID в своей базе и, если они не совпадают, образ удаляется.
Пока ковырял LVM заметил, что при переносе образа из одного хранилища в другое так же меняется и его UUID и, исходя из этого, предположил, что можно окончательно воскресить образ, просто скопировав переписанный через dd образ в другое хранилище. Это должно обновить UUID в образе, сопоставив его в UUID в базе. Повторяем все процедуры заново, после чего переносим образ на временно созданное для этого хранилище, добавляем к виртуальной машине и пробуем ее запустить. Запуск проходит нормально.
Перезагружаем сервер, трясущимися от нетерпения и усталости руками проверяем список образов и… образ на месте! Счастью нет предела и, довольный собой, я удаляюсь в закат…
