Если вы видите аналогичную ошибку в логах Proxmox, и не можете запустить свои виртуалки, я помогу устранить. О решении проблемы описано в статье.
Aug 04 12:14:34 pve pvedaemon[1117]: <root@pam> end task UPID:pve:0000072F:000028D7:6A71AD78:qmstart:102:root@pam: activating LV ‘pve/data’ failed: Check of pool pve/data failed (status:64). Manual repair required!
Aug 04 12:14:42 pve pvestatd[1094]: activating LV ‘pve/data’ failed: Check of pool pve/data failed (status:64). Manual repair required!
Разбор реального инцидента: после перезапуска ни одна виртуальная машина и контейнер на ноде Proxmox не стартовали, история задач заполнилась ошибками активации LV. Ниже — точная причина, диагностика и рабочее решение без переустановки.
1. Симптомы
В веб-интерфейсе Proxmox при попытке запустить любую виртуальную машину или контейнер задача завершается ошибкой, а в Task History появляется строка со статусом:
Error: activating LV 'pve/data' failed: Check of pool pve/data failed (status:...)Характерный признак: ошибка одинаковая для всех VM и CT на ноде, а не для одной конкретной машины. Это указывает на проблему на уровне общего хранилища, а не отдельного диска.
В логе кластера (Cluster log) она разворачивается подробнее:
qmstart:102:root@pam: activating LV 'pve/data' failed: Check of pool pve/data failed (status:...)
2. Причина ошибки
Диски всех VM и контейнеров в Proxmox по умолчанию хранятся в LVM thin-pool с именем pve/data. Он состоит из двух логических томов:
data_tdata— сами данные (содержимое дисков VM);data_tmeta— метаданные: карта того, какие блоки данных кому принадлежат, дерево снапшотов, список свободных блоков.
Перед каждой активацией пула LVM запускает утилиту thin_check, которая проверяет целостность data_tmeta. Если метаданные повреждены, проверка завершается с ненулевым кодом, и LVM намеренно отказывается активировать пул — это защитный механизм, чтобы не продолжать работу с неконсистентной картой данных и не повредить их ещё сильнее.
Точная ошибка в логах
В подробном выводе (lvchange -ay -vvvv) это выглядит так: /usr/sbin/thin_check failed: 64, далее Check of pool pve/data failed (status:64). Manual repair required!
Что чаще всего приводит к повреждению метаданных
| Причина | Как проверить |
|---|---|
| Аварийное выключение хоста (сбой питания, hard reset, kernel panic) в момент записи метаданных | journalctl --list-boots, поиск незапланированных перезагрузок |
| Проблемы физического диска или контроллера, отключённый кэш записи без защиты от потери питания | smartctl -a /dev/sdX |
| Переполнение пула (Data% или Meta% доходили до 100%) в прошлом | История алертов Proxmox / lvs -a -o+lv_health_status |
Несовместимость версии thin_check после обновления пакетов | thin_check --version |
3. Диагностика
Все команды выполняются на самом хосте Proxmox (не внутри виртуальной машины), через SSH или локальную консоль.
Шаг 1. Посмотреть состояние логических томов
bashcopy
root@pve:~# lvs -a -o+lv_health_statusЕсли столбцы Data% и Meta% у data пустые, а в Attr нет буквы a на пятой позиции (например twi---tz-- вместо twi-aotz--) — пул неактивен.
Шаг 2. Попытаться активировать вручную и получить точный код ошибки
root@pve:~# lvchange -ay -vvvv pve/data 2>&1 | tail -60
В выводе нужно найти строки вида:
Executing: /usr/sbin/thin_check -q /dev/mapper/pve-data_tmeta
/usr/sbin/thin_check failed: 64
Check of pool pve/data failed (status:64). Manual repair required!
Код 64 и фраза Manual repair required! — прямое указание LVM на то, что метаданные повреждены и нужна ручная репарация.
Перед восстановлением: пул данных неактивен, а столбцы Data% / Meta% пусты.
4. Исправление
Перед началом
Операция в большинстве случаев безопасна и не трогает содержимое дисков VM напрямую, но полностью исключить риск нельзя. Если есть возможность — сделайте бэкап критичных машин перед репарацией.
Восстановление метаданных thin-pool выполняется одной командой:
root@pve:~# lvconvert --repair pve/data
WARNING: LV pve/data_meta0 holds a backup of the unrepaired metadata. Use lvremove when no longer required.Предупреждение про data_meta0 — это норма, а не ошибка. LVM создаёт новый исправленный том метаданных, а старые (повреждённые) сохраняет отдельно на случай, если понадобится анализ.
Активировать пул
root@pve:~# lvchange -ay pve/dataЕсли команда завершилась без вывода и без ошибок — пул успешно активирован.
5. Проверка результата
root@pve:~# lvs -a -o+lv_health_status
LV VG Attr LSize Pool Origin Data% Meta% Health
data pve twi-aotz-- <348.82g 38.11 1.42Attr вида twi-aotz-- (буква a на пятой позиции) означает, что пул активен. Заполненные Data% и Meta% с адекватными значениями и пустой столбец Health подтверждают, что проблем нет.
- до Check of pool pve/data failed (status:64) thin_check не проходит проверку метаданных, пул не активируется, VM не стартуют.
- команда lvconvert —repair pve/data Метаданные пересобраны, повреждённая копия сохранена в data_meta0.
- после Attr: twi-aotz— · Data% 38.11 · Meta% 1.42 Пул активен, VM запускаются штатно.
Теперь можно запускать виртуальные машины через веб-интерфейс либо командой:
root@pve:~# qm start 102
После того как всё стабильно заработало.
Проверьте целостность данных внутри самих VM (репарация метаданных LVM не гарантирует 100% целостность файловой системы гостевой ОС), и через несколько дней стабильной работы удалите резервную копию повреждённых метаданных: lvremove pve/data_meta0.
6. Как избежать повторения
- ИБП (UPS) для хоста — самая частая причина повреждения метаданных thin-pool это аварийное выключение без штатного shutdown.
- Мониторинг заполненности пула — держите
Data%иMeta%ниже 80%, переполнение в момент записи может повредить метаданные. - Проверка дисков — периодически смотрите
smartctl -a /dev/sdXна предмет деградации. - Регулярные бэкапы — встроенный Backup в Proxmox снимает риск того, что повреждение окажется невосстановимым.
7. Похожие формулировки этой же ошибки
Если вы искали проблему по одной из следующих строк — речь о том же инциденте:
Error: activating LV 'pve/data' failed: Check of pool pve/data failed (status:...)/usr/sbin/thin_check failed: 64Check of pool pve/data failed (status:64). Manual repair required!activating LV 'pve/data' failed: Check of pool pve/data failedприqmstart- VM/CT не запускаются сразу после перезагрузки ноды Proxmox с ошибкой активации LV
8. Частые вопросы
Почему в Proxmox все виртуальные машины сразу перестают запускаться?
Диски всех VM и контейнеров обычно лежат на одном thin-pool. Если повреждены его метаданные, LVM не активирует пул целиком — поэтому ошибка одинаковая для всех машин сразу.
Что означает ошибка thin_check failed: 64?
Код 64 — сигнал, что thin_check нашёл несогласованность в метаданных thin-pool и не подтвердил их корректность. LVM блокирует активацию и просит ручной репарации.
Безопасна ли команда lvconvert —repair для данных на дисках VM?
Она работает с метаданными пула, а не с содержимым дисков напрямую, и в большинстве случаев проходит без потерь. Старые метаданные не удаляются, а сохраняются отдельно (LV с суффиксом _meta0). Бэкап важных машин перед операцией всё же желателен.
Что делать, если lvconvert —repair тоже завершается с ошибкой?
Это говорит о более серьёзном повреждении. Нужно смотреть точный вывод команды, проверять свободное место в volume group и состояние физических дисков (smartctl), а при необходимости — восстанавливать VM из резервных копий.
Как предотвратить повторное повреждение thin-pool?
ИБП для хоста, мониторинг заполненности пула ниже 80%, проверка дисков через smartctl и регулярные бэкапы виртуальных машин.