Я пытаюсь восстановить группу томов на виртуальной машине, которая каким-то образом была повреждена.
Lv-root каким-то образом утерян из VG, и VG показала, что первоначально выделенное пространство было свободным.
На виртуальной машине мы не могли использовать vgcfgrestore
команда. Однако мы могли использовать его на хосте, и VG был восстановлен, включая все LV.
Однако теперь при попытке загрузить виртуальную машину «Группа томов не найдена» отображается и не загружается.
pvs
показывает привод однако vgs
возвращается /run/lvm/lvmetad.socket connect failed no such file or directory
Что будет следующим шагом?
pvscan
показывает
относительно комментариев:
Вот конфигурация диска виртуальной машины из pastebin, упомянутого в комментариях к вопросу:
<devices>
<emulator>/usr/bin/kvm</emulator>
<disk type='block' device='disk'>
<driver name='qemu' type='raw'/>
<source dev='/dev/mars_ssd/myUnivativ'/>
<target dev='hda' bus='ide'/>
<address type='drive' controller='0' bus='0' unit='0'/>
</disk>
<disk type='block' device='cdrom'>
<driver name='qemu' type='raw'/>
<target dev='hdc' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='1' unit='0'/>
</disk>
[...non-disk devices after this point...]
Информация в конфигурации виртуальной машины указывает на диск виртуальной машины. /dev/sda
на самом деле /dev/mars_ssd/myUnivativ
на хосте, то есть VG mars_ssd
, LV myUnivativ
. (Да, я знаю, что конфигурация виртуальной машины говорит hda
вместо того sda
- очевидно, предполагается, что виртуальная машина будет использовать старые драйверы IDE.)
Если mars_ssd
У VG хоста есть какие-либо проблемы, вы должны сначала исправить их на уровне хоста.
Поскольку /dev/mars_ssd/myUnivativ
LV содержит образ диска виртуальной машины, у него есть таблица разделов и собственный уровень LVM.
Поскольку кажется, что корневая файловая система виртуальной машины находится внутри поврежденной группы VG, исправить ее внутри виртуальной машины будет сложно. Возможно, вам будет легче исправить это, если вы сможете использовать все инструменты, доступные на хосте.
Так:
sudo losetup -f
на хосте для определения первого бесплатного /dev/loop*
устройство. Я назову это /dev/loopN
.sudo losetup /dev/loopN /dev/mars_ssd/myUnivativ
для настройки устройства петли для диска виртуальной машины. Теперь вы можете получить доступ к образу диска виртуальной машины, как к обычному целодисковому устройству, даже если это действительно LV на хосте.sudo kpartx -a /dev/loopN
. Он создаст устройства для разделов на образе диска виртуальной машины и сделает их доступными как обычные устройства разделов, названные как /dev/mapper/loopNpP
, где P - номер раздела.Теперь вы можете смонтировать любой раздел в образе диска виртуальной машины на уровне хоста: поскольку PV виртуальной машины был указан как /dev/sda5
на хосте в образе диска будет как минимум два раздела. Вы можете просмотреть разделы с помощью sudo fdisk -l /dev/loopN
, затем смонтируйте любые интересные разделы, например sudo mount /dev/mapper/loopNp1 /mnt
.
Ты даже можешь бежать pvscan
или vgscan
и выберите группы томов виртуальной машины на уровне хоста - если их имена не конфликтуют с именами хоста. Если вы найдете работоспособную VG, вы можете активировать ее с помощью sudo vgchange -ay
а затем смонтируйте его как обычно.
На этом этапе вы также можете использовать любые инструменты для восстановления файлов, если захотите.
Перед повторным запуском виртуальной машины отмените все действия, которые вы сделали для доступа к образу диска виртуальной машины на уровне хоста:
sudo vgchange -an <name of VM's VG>
если бы вы их активировалиsudo kpartx -d /dev/loopN
sudo losetup -d /dev/loopN
.Надеюсь, это поможет. Пожалуйста, дополните свой вопрос своими выводами, и я обновлю свой ответ, если это необходимо.