Виртуалка не стартует после сбоя питания: диагностика

MAATRIX

Свет мигнул, сервер ушёл в аварийное отключение, а после включения одна или несколько виртуалок просто не поднимаются — зависают на загрузке, падают в recovery shell или гипервизор вовсе не может их запустить. Это не редкость: внезапное обесточивание — не то же самое, что плановая перезагрузка, и последствия у него принципиально другие. Ниже — постмортем-разбор, как диагностировать проблему по уровням: от гостевой файловой системы до самого хранилища хоста, RAID-массива и ZFS-пула.

Почему аварийное отключение питания хуже плановой перезагрузки

При штатном reboot или shutdown ядро успевает синхронизировать кеши, закрыть файловые дескрипторы и корректно размонтировать файловые системы — журнал ФС фиксирует, что все транзакции завершены. При обрыве питания ничего этого не происходит: данные, которые лежали в page cache и ещё не были сброшены на диск (fsync), теряются, а файловая система может оказаться в промежуточном состоянии — часть журнальной записи есть, часть нет.

Это касается сразу двух уровней:

• Гостевая ФС внутри VM — то, что видит операционная система виртуалки (ext4, XFS, NTFS и так далее).
• Хранилище хоста — то, на чём физически лежит файл или том виртуального диска (qcow2-образ, LVM-том, ZFS zvol, RBD-объект в Ceph).

Повреждение может случиться на любом из этих уровней независимо, а иногда — на обоих сразу. Поэтому диагностику стоит вести именно в таком порядке: сначала посмотреть, что происходит на экране самой VM, потом спускаться на уровень хоста.

Шаг 1: диагностика через консоль VM, а не по сети

Первая и самая частая ошибка — пытаться зайти на подвисшую VM по SSH и удивляться, что она "недоступна". Если виртуалка зависла на этапе загрузки ядра или на автоматической проверке файловой системы, сетевой стек внутри гостевой ОС ещё не поднялся — SSH туда просто не достучится, а факт "не пингуется" ничего не говорит о причине.

Открывайте именно консоль гипервизора — это виртуальный аналог монитора и клавиатуры, подключённых напрямую к VM, и через неё видно, что происходит на экране, даже если сеть внутри гостя не работает вообще.

В Proxmox это делается через веб-интерфейс:

# в браузере: Datacenter -> Node -> VM -> Console
# или из консоли хоста, если веб недоступен:
qm terminal <VMID>

В libvirt/KVM без панели:

virsh console <domain-name>
# для графической консоли (VNC/SPICE) через virt-viewer:
virt-viewer <domain-name>

Типичная картина на экране при повреждении гостевой ФС из-за незавершённой записи в момент отключения питания — система доходит до этапа монтирования корня и зависает на автоматической проверке файловой системы, либо явно падает в аварийный режим восстановления с приглашением ввести пароль root для ручного fsck:

[FAILED] Failed to mount /.
[DEPEND] Dependency failed for Local File Systems.
Give root password for maintenance
(or press Control-D to continue):

Если видите такую картину — это почти наверняка незавершённая транзакция журналируемой ФС (ext4 c журналом не гарантирует нулевые потери данных, только целостность структуры) или битые метаданные из-за того, что запись обрывалась ровно в момент коммита. Дальше в консоли (не по SSH) входите под root и запускаете проверку вручную:

# для ext4 — обычно достаточно журнала, но при сомнениях делаем полную проверку
fsck.ext4 -y /dev/sda1
# для XFS журнал воспроизводится автоматически при монтировании,
# принудительная проверка делается отдельно и требует размонтированного раздела
xfs_repair /dev/sda1

Флаг -y у fsck отвечает "да" на все вопросы автоматически — это ускоряет процесс, но если диск подозрителен физически (а не только логически), лучше сначала снять образ, а не чинить на живую (принцип тот же, что при восстановлении после сбоя диска — сначала спасаем данные, потом чиним).

Шаг 2: если консоль пуста или гипервизор не может запустить VM

Другая ситуация — VM вообще не стартует, гипервизор сразу выдаёт ошибку при попытке запуска, консоль не показывает загрузку ОС гостя. Здесь проблема не внутри гостевой системы, а на уровне файла или тома виртуального диска на хосте.

Смотрите лог гипервизора первым делом:

# Proxmox / QEMU
journalctl -u qemu-server@<VMID> -n 200
tail -100 /var/log/pve/tasks/*/UPID:*

# чистый libvirt
virsh dominfo <domain-name>
journalctl -u libvirtd -n 200

Частые сообщения в этом сценарии — Could not open backing file, Image is corrupt, qcow2: Image is not in cleanly closed state. Последнее — прямое указание, что образ был открыт на запись в момент отключения и не был корректно закрыт.

Для qcow2-образов есть встроенная проверка консистентности:

qemu-img check /var/lib/vz/images/<VMID>/vm-<VMID>-disk-0.qcow2

Если утилита находит "leaked clusters" или ошибки в таблице L2 — это повреждение метаданных самого образа, не гостевой ФС. Их иногда можно почистить флагом -r all, но перед этим обязательно снимите копию файла образа — исправление перезаписывает структуру, и при ошибке в самой процедуре можно потерять то, что ещё оставалось читаемым:

cp vm-<VMID>-disk-0.qcow2 vm-<VMID>-disk-0.qcow2.bak
qemu-img check -r all vm-<VMID>-disk-0.qcow2

Шаг 3: тонкие тома и LVM — отдельная точка отказа

Если диски VM лежат не как файлы qcow2, а как LVM-тома (частая схема для скорости — меньше накладных расходов файловой системы хоста), проверяйте состояние самих томов до того, как разбираться с содержимым:

# видит ли LVM том вообще, нет ли пометок partial/inactive
lvs -a -o +lv_health_status
vgs
pvs

# если том помечен как partial — часть физического тома недоступна
lvchange -ay /dev/vg_data/vm-101-disk-0

Тонкие тома (thin LVM) особенно чувствительны к резкому отключению: у thin pool есть собственные метаданные (карта распределения блоков), и при обрыве питания в момент их обновления пул может уйти в состояние, требующее ручного вмешательства:

# состояние thin pool, ищите Data% и Metadata% использования и предупреждения
lvs -a -o +data_percent,metadata_percent vg_data/thinpool
# проверка метаданных thin pool (требует деактивации тома!)
lvconvert --repair vg_data/thinpool

Здесь важна честная оговорка: lvconvert --repair не гарантирует восстановление без потерь — он чинит структуру метаданных пула, но данные внутри повреждённых блоков это не восстанавливает. Если это боевая нагрузка, а не тестовый стенд, привычнее и надёжнее поднять VM из бэкапа, а повреждённый том разбирать уже не под давлением "надо запустить прямо сейчас".

Шаг 4: RAID-массив — не ушёл ли он в деградированное состояние

Скачок или обрыв питания иногда роняет не только запись на диск, но и сам диск из массива — контроллер видит недостоверный ответ от устройства в момент скачка напряжения и помечает его как failed, даже если физически диск исправен. Проверяйте статус массива сразу, до попыток чинить что-либо внутри VM — если деградирован массив, симптомы внутри гостя будут вторичными.

Для программного RAID (mdadm):

cat /proc/mdstat
mdadm --detail /dev/md0

Строка [UU_] вместо [UUU] в выводе /proc/mdstat — явный признак, что один диск выпал из массива. Для аппаратных контроллеров команда зависит от производителя:

# LSI / Broadcom (MegaRAID)
megacli -LDInfo -Lall -aAll
# или через storcli
storcli /c0 show

Если массив в состоянии degraded, но данные ещё доступны (запас избыточности не исчерпан), сначала убедитесь, что новых отказов нет, и только потом занимайтесь виртуалками — потому что если сейчас начать интенсивный rebuild под нагрузкой от стартующих VM, деградированный массив может не выдержать. Подробнее о том, что происходит с контроллером в момент отказа и почему rebuild — самый рискованный этап, разобрано в статье как работает RAID-контроллер при отказе диска, а частую цепочку ошибок при неправильной замене диска — в статье заменили диск и потеряли массив.

Шаг 5: ZFS-пул — проверяем, а не предполагаем

Если хранилище на хосте — ZFS (частый выбор именно из-за устойчивости к сбоям питания благодаря copy-on-write и транзакционной модели записи), есть соблазн решить "раз это ZFS, значит точно всё в порядке" и сразу переходить к разбору VM. Соблазн понятный, но неверный: устойчивость ZFS к нарушенным транзакциям снижает вероятность повреждения, а не исключает её полностью — особенно если в системе не было честного sync write для критичных операций или если сбой пришёлся на процесс scrub/resilver.

Проверка обязательна, а не опциональна:

zpool status -v

Смотрите на строку состояния каждого пула:

• ONLINE без пометок — пул здоров, ошибок при чтении/записи/чексуммах нет.
• DEGRADED — один из vdev выпал (аналог degraded RAID), пул работает, но без резерва.
• errors: No known data errors в конце вывода — хороший знак, значит на уровне блоков чексуммы сходятся.
• Ненулевые счётчики CKSUM/READ/WRITE напротив конкретного диска — там были ошибки, ZFS их исправил за счёт избыточности (если она была), но диск стоит присмотреть отдельно.

Если пул ONLINE и ошибок нет, а VM всё равно не стартует — значит проблема не в целостности блочного хранилища, а либо в гостевой ФС (возвращайтесь к шагу 1), либо в самом файле/датасете, на котором лежит образ или zvol:

# для датасетов, где лежат образы VM — проверка снапшотов и текущего состояния
zfs list -t all -r rpool/data
# принудительный scrub, если ошибок в статусе нет, но есть сомнения
zpool scrub rpool
zpool status rpool  # проверить прогресс и результат после завершения

Учтите, что scrub — это фоновая проверка чтением, она может занять часы на больших пулах и создаёт дополнительную нагрузку на диски, так что запускать его "на всякий случай" в момент, когда нужно быстро поднять сервис, не всегда уместно — сначала оцените, есть ли реальные признаки проблемы (ошибки в zpool status, странности в логах), а не гоняйте scrub вслепую.

Практический порядок действий при инциденте

Когда всё это складывается в один инцидент — сервер обесточился, включился, VM не стартуют — реальная последовательность действий выглядит так:

Пятый пункт стоит держать в голове с самого начала: если инцидент влияет на боевой сервис, время на "docopy" и ручной ремонт метаданных может обойтись дороже, чем поднять актуальный бэкап и разбираться с повреждённым диском уже не под давлением. Регулярная тренировка именно такого сценария восстановления описана в статье восстановление виртуалки из образа: репетиция аварии — если такая репетиция уже проводилась, среднее время на реальное восстановление будет ощутимо меньше, чем при первой попытке "по ходу дела".

Как снизить вероятность повторения

Полностью исключить повреждения при аварийном отключении питания нельзя — но можно резко снизить их вероятность и частоту:

• ИБП с корректным автоматическим завершением работы. Ключевое слово здесь — "корректным": просто продлить работу сервера от батареи до её полной разрядки, после чего всё равно случится жёсткое отключение, не решает проблему, а лишь отодвигает её на несколько минут. Правильная схема — ИБП по USB/сети сообщает серверу (через nut, apcupsd или аналог) о переходе на батарею, и по установленному порогу заряда инициируется штатное завершение работы хоста и всех гостевых VM до того, как батарея сядет полностью.
• Журналируемые файловые системы везде, где это возможно — и внутри VM, и на хосте. Non-journaled ФС (например, ext2 без журнала) восстанавливаются после сбоя питания заметно дольше и с большей вероятностью потери данных.
• Отдельное журналирование и метаданные с резервированием на уровне хранилища хоста — ZFS с включённой избыточностью (mirror/raidz), либо RAID с батарейным или флеш-кешем на контроллере (BBU/CacheVault), который сохраняет незаписанные данные кеша при потере питания.
• Частые снапшоты состояния VM перед плановыми работами и регулярные бэкапы образов — если восстановление повреждённой ФС или тома окажется невозможным или слишком долгим, откат к последней рабочей точке будет быстрее любого ручного ремонта.

Резервный блок питания внутри самого сервера (когда он есть) защищает от отказа одного БП, но не от отключения электричества в здании или на вводе — это разные уровни отказоустойчивости, и подменять один другим не стоит; разница разобрана в статье резервный блок питания и отказоустойчивость.

Частые вопросы