Статус unknown у виртуальной машины или контейнера в веб-интерфейсе Proxmox VE почти всегда означает, что гипервизор не может корректно опросить состояние гостевой системы — чаще всего из-за зависшей блокировки (lock) в конфигурации, недоступного хранилища или проблем кластерной синхронизации. При этом значок ВМ в панели становится серым, а кнопки запуска и остановки перестают реагировать либо выдают ошибку.
Проблема не означает, что данные виртуальной машины потеряны. В большинстве случаев диски и конфигурация остаются на месте, а задача администратора — найти, что именно мешает Proxmox получить статус: снять зависший лок, восстановить доступ к стораджу или устранить сбой кворума кластера. Ниже разберём диагностику по шагам — от безопасных проверок до ручного снятия блокировки.
Что означает статус unknown в Proxmox VE
Proxmox определяет состояние ВМ и контейнеров через службы qemu-server (для KVM-машин) и pve-container (для LXC). Если служба не может получить ответ — например, конфигурационный файл заблокирован или хранилище, на котором лежит конфиг, недоступно, — интерфейс показывает unknown вместо привычных running или stopped.
Типичный признак: в журнале задач (панель Task History внизу веб-интерфейса) видны завершённые с ошибкой операции, а при попытке запуска появляется сообщение вида VM is locked или ошибка таймаута. Это указывает, что предыдущая операция — миграция, бэкап, создание снапшота — завершилась аварийно и оставила блокировку в конфигурации.
- 🔒 Зависший lock — прерванная миграция, бэкап или снапшот оставили отметку блокировки в конфиге ВМ.
- 💾 Недоступное хранилище — NFS, iSCSI или Ceph-диск отвалился, и Proxmox не может прочитать конфигурацию.
- 🖧 Проблемы кластера — потерян кворум, и
pmxcfsперевёл файловую систему конфигураций в режим только для чтения. - ⚙️ Сбой служб — демоны
pvedaemon,pveproxyилиpvestatdостановлены или зависли.
Быстрая диагностика: с чего начать
Прежде чем что-либо менять, откройте SSH-сессию к узлу и проверьте фактическое состояние машины командами. Для виртуальной машины с ID 100:
qm status 100Для LXC-контейнера команда аналогична, только используется pct status 100. Если команда возвращает ошибку блокировки или таймаута — причина подтверждена. Параллельно стоит посмотреть содержимое конфигурационного файла /etc/pve/qemu-server/100.conf (для контейнеров — /etc/pve/lxc/100.conf): наличие строки вида lock: backup или lock: migrate прямо указывает на источник проблемы.
Также проверьте состояние ключевых служб:
systemctl status pvedaemon pveproxy pvestatd pve-clusterСнятие зависшей блокировки (lock)
Наиболее частая причина — зависшая блокировка, оставшаяся после аварийно прерванной задачи резервного копирования или миграции. Пока lock присутствует в конфигурации, Proxmox блокирует любые операции с машиной, а статус может отображаться как unknown. Сначала убедитесь, что соответствующий процесс действительно не выполняется: проверьте список задач через ps aux | grep vzdump или диспетчер задач в веб-интерфейсе.
Если процесс мёртв, снимите блокировку штатной командой:
qm unlock 100Для контейнера используется pct unlock 100. После выполнения обновите страницу веб-интерфейса — статус должен вернуться к stopped или running. Если команда сообщает, что блокировки нет, но статус не меняется, причина лежит глубже: в хранилище или кластерной файловой системе.
⚠️ Внимание: никогда не снимайте lock, пока реально идёт процесс бэкапа или миграции. Принудительное снятие блокировки во время активной операции может повредить диск виртуальной машины или привести к рассинхронизации данных.
☑️ Порядок безопасного снятия блокировки
Проблемы с хранилищем
Если конфигурация ВМ ссылается на диск, размещённый на сетевом хранилище, а это хранилище недоступно, Proxmox не сможет собрать полную информацию о машине. Проверьте состояние стораджей в разделе Datacenter → Storage — проблемный будет помечен как неактивный. С командной строки статус виден через pvesm status.
Для NFS проверьте, смонтирована ли шара и отвечает ли сервер. Для Ceph — состояние кластера командой ceph -s. После восстановления доступа к хранилищу статус ВМ обычно нормализуется сам, без дополнительных действий. Если хранилище вышло из строя окончательно, потребуется восстановление дисков из резервной копии на другой сторадж.
Потеря кворума и сбои pmxcfs
В кластере из нескольких узлов конфигурации хранятся в распределённой файловой системе pmxcfs, смонтированной в /etc/pve. Если кластер теряет кворум — например, из двух узлов выключился один, — файловая система переходит в режим только для чтения, и любые изменения конфигурации становятся невозможны. Статусы ВМ при этом могут отображаться некорректно.
Проверить состояние кворума можно командой:
pvecm statusВ выводе ищите строку Quorate: Yes. Если кворума нет, а второй узел недоступен надолго, на оставшемся узле можно временно установить ожидаемое число голосов: pvecm expected 1. Это вернёт возможность управлять виртуальными машинами до восстановления второго узла.
⚠️ Внимание: команда pvecm expected 1 — аварийная мера. После возвращения узла в строй убедитесь, что кластер синхронизировался, иначе возможны конфликты конфигураций и «раздвоение» виртуальных машин (split-brain).
| Причина | Как проверить | Решение |
|---|---|---|
| Зависший lock | qm status ID, строка lock в конфиге | qm unlock ID |
| Недоступное хранилище | pvesm status | Восстановить доступ к стораджу |
| Потеря кворума | pvecm status | pvecm expected 1 или вернуть узел |
| Зависшие службы | systemctl status pvedaemon | Перезапуск служб |
| Битый конфиг ВМ | Чтение файла в /etc/pve/qemu-server/ | Ручное исправление конфигурации |
Перезапуск служб и крайние меры
Если блокировки нет, хранилище доступно, а статус остаётся unknown — перезапустите службы Proxmox. Это безопасно для работающих виртуальных машин: сами гостевые системы продолжат работу, перезапускается только управляющий слой:
systemctl restart pvedaemon pveproxy pvestatdВ редких случаях помогает только перезагрузка самого узла. Перед этим обязательно мигрируйте или корректно выключите работающие ВМ, если статус позволяет ими управлять. После перезагрузки проверьте журналы journalctl -u pve-cluster и общий системный лог на предмет ошибок, которые мешали службам стартовать.
Что делать, если конфигурационный файл ВМ повреждён
Откройте файл /etc/pve/qemu-server/ID.conf в текстовом редакторе и сравните его с конфигом заведомо рабочей машины. Удалите явно битые строки (обрывки параметров, дубли lock). Синтаксис простой: пары «ключ: значение», по одной на строку. После правки выполните qm status ID — если конфиг валиден, статус восстановится. Перед редактированием сделайте копию файла.
Профилактика: как избежать повторения
Чтобы проблема не возвращалась, стоит выстроить несколько простых привычек в администрировании Proxmox. Во-первых, не прерывайте задачи бэкапа и миграции принудительно — если задача «зависла», дождитесь таймаута или разберитесь с причиной через логи. Во-вторых, следите за свободным местом на хранилищах: переполненный сторадж — частый источник аварийных завершений задач.
- 📋 Регулярно проверяйте Task History на предмет задач со статусом ошибки.
- 📊 Настройте мониторинг состояния кворума и хранилищ.
- 🔄 Обновляйте Proxmox VE штатно через
apt update && apt dist-upgrade— часть багов с блокировками исправляется в обновлениях.
Частые вопросы
Можно ли удалить lock вручную, отредактировав конфиг?
Да, можно удалить строку lock: из файла конфигурации в /etc/pve/qemu-server/, но штатная команда qm unlock предпочтительнее — она безопаснее и не требует ручного редактирования. Ручное удаление оправдано, только если команда по какой-то причине не работает.
Виртуальная машина работает, но статус unknown — это опасно?
Сама гостевая система при этом обычно продолжает работать нормально. Опасность в другом: вы теряете возможность управлять ВМ через Proxmox (остановка, миграция, бэкап), поэтому причину стоит устранить как можно скорее.
Поможет ли перезагрузка сервера?
Иногда да: перезагрузка снимает зависшие блокировки и перезапускает службы. Но это крайняя мера — сначала выполните диагностику через qm status и попробуйте qm unlock. Перезагрузка без выяснения причины может привести к повторению ситуации.
Status unknown появился после обновления Proxmox — что делать?
Проверьте, не прервалось ли обновление: выполните apt --fix-broken install и убедитесь, что все пакеты настроены. Затем перезапустите службы управления. Если проблема сохраняется, изучите вывод journalctl -xe на предмет ошибок конкретных пакетов.