Назад | Перейти на главную страницу

Восстановление потерянного LVM VG

Я пытаюсь восстановить группу томов на виртуальной машине, которая каким-то образом была повреждена.

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.

Надеюсь, это поможет. Пожалуйста, дополните свой вопрос своими выводами, и я обновлю свой ответ, если это необходимо.