Ошибка «VM is locked» или «Configuration file locked» в Proxmox VE появляется при попытке запустить, остановить или изменить виртуальную машину, которую гипервизор считает занятой другой операцией. Чаще всего блокировка остаётся после прерванного бэкапа, миграции, снапшота или аварийного завершения задачи, и веб-интерфейс перестаёт отвечать на действия с этой VM.
Стандартный способ снять такую блокировку — команда qm unlock <VMID> в консоли узла. Однако перед её выполнением стоит убедиться, что зависшая задача действительно завершилась, иначе принудительное снятие lock может повредить конфигурацию или диск виртуальной машины. Ниже разберём причины блокировки, безопасный порядок диагностики и альтернативные методы.
Почему виртуальная машина блокируется
Proxmox использует механизм lock для защиты конфигурации VM от одновременных изменений. Когда запускается задача — резервное копирование, миграция, создание снапшота, клонирование — в конфигурационный файл виртуальной машины добавляется параметр lock: с типом операции. Пока этот параметр присутствует, другие действия с VM запрещены.
В штатной ситуации блокировка снимается автоматически по завершении задачи. Проблема возникает, когда процесс завершается аварийно: служба pvescheduler или pvedaemon перезапущена, узел перезагружен, сетевое хранилище отвалилось посреди бэкапа. Задача умерла, а флаг блокировки остался.
- 🔒 Прерванный бэкап через vzdump — самая частая причина зависшего lock
- 🔄 Незавершённая миграция VM на другой узел кластера
- 📸 Сбой при создании или откате снапшота
- ⚡ Перезагрузка узла во время выполнения задачи с виртуальной машиной
Диагностика: что проверить перед снятием блокировки
Сначала посмотрите список активных задач в веб-интерфейсе Proxmox — панель Task History внизу страницы узла. Если задача по нужной VM ещё выполняется или висит в статусе running, снимать блокировку принудительно рано: дождитесь завершения или остановите задачу штатно.
Затем проверьте конфигурацию виртуальной машины через SSH на узле:
cat /etc/pve/qemu-server/<VMID>.conf | grep lockЕсли в выводе присутствует строка вида lock: backup или lock: migrate, значит блокировка действительно записана в конфигурацию. Дополнительно проверьте, не осталось ли работающих процессов, связанных с этой VM:
ps aux | grep <VMID>Обратите внимание на процессы vzdump и qm. Если процесс жив, лучше сначала корректно завершить его, а уже потом снимать lock.
⚠️ Внимание: принудительное снятие блокировки во время реально выполняющегося бэкапа или миграции может привести к повреждению диска виртуальной машины и рассинхронизации конфигурации в кластере. Всегда проверяйте, что задача завершена, до выполнения
qm unlock.
Основной способ: команда qm unlock
Когда вы убедились, что зависшая задача мертва, подключитесь к узлу по SSH и выполните команду разблокировки, подставив идентификатор своей виртуальной машины:
qm unlock <VMID>Например, для VM с идентификатором 101 команда будет выглядеть как qm unlock 101. Утилита удалит параметр lock из конфигурационного файла, и виртуальная машина сразу станет доступна для управления через веб-интерфейс — перезапускать службы не требуется.
☑️ Безопасное снятие блокировки VM
После снятия блокировки попробуйте запустить VM и проверьте её работоспособность. Если машина не стартует, посмотрите журнал задачи запуска — там обычно указана конкретная причина, например недоступность диска на хранилище.
Альтернативные методы разблокировки
Если команда qm unlock по какой-то причине недоступна или нужно действовать вручную, существуют другие варианты. Один из них — прямое редактирование конфигурационного файла VM. Откройте файл /etc/pve/qemu-server/<VMID>.conf в текстовом редакторе и удалите строку, начинающуюся с lock:, после чего сохраните изменения.
В кластерной конфигурации каталог /etc/pve является общей репликируемой файловой системой (pmxcfs), поэтому редактировать файл можно с любого узла. Однако делать это стоит аккуратно: ошибка в конфигурации может сделать VM недоступной для менеджера виртуальных машин.
Ещё один вариант — остановка зависшего процесса вручную. Если vzdump продолжает висеть, найдите его PID и завершите через kill, а уже затем снимайте lock. В отдельных случаях помогает перезапуск служб управления на узле.
Перезапуск служб Proxmox при зависании
Иногда помогает перезапуск служб pvedaemon, pveproxy и pvestatd командами systemctl restart pvedaemon pveproxy pvestatd. Это не затрагивает работающие виртуальные машины, но может сбросить зависшие задачи управления. Однако сам параметр lock в конфигурации VM таким способом не удаляется — его всё равно нужно снимать через qm unlock или редактирование файла.
Сравнение способов снятия блокировки
| Метод | Когда применять | Риск |
|---|---|---|
qm unlock <VMID> |
Стандартный случай зависшего lock | Минимальный при проверке задач |
| Редактирование .conf вручную | Если qm недоступен или повреждён | Средний — риск синтаксической ошибки |
| Завершение процесса vzdump | Зависший бэкап держит блокировку | Средний — возможен битый бэкап |
| Перезапуск служб pve* | Завис интерфейс управления узлом | Низкий, но lock не снимается |
⚠️ Внимание: при ручном редактировании конфигурации в кластере не редактируйте одновременно один и тот же файл с разных узлов. Файловая система pmxcfs реплицирует изменения, и конфликт версий может привести к непредсказуемому состоянию конфигурации.
Разблокировка при зависшей миграции в кластере
Отдельный сценарий — миграция, прерванная на полпути, когда VM числится на одном узле, а её диски или процесс частично остались на другом. В этом случае простого qm unlock может оказаться недостаточно: сначала определите, на каком узле реально находится конфигурация и работает ли процесс QEMU.
Проверьте статус VM на обоих узлах командой qm status <VMID>. Если процесс QEMU жив на целевом узле — дождитесь завершения или завершите его штатно. Если процесса нет нигде, снимите lock и убедитесь, что конфигурация находится на исходном узле, прежде чем запускать машину заново.
Запускать одну и ту же VM одновременно на двух узлах категорически нельзя — это гарантированное повреждение файловой системы гостевой ОС из-за параллельной записи на диск.
Профилактика зависших блокировок
Полностью исключить зависшие lock невозможно, но снизить их частоту реально. Основная мера — не прерывать задачи бэкапа и миграции принудительно и не перезагружать узел, пока в Task History есть активные операции с виртуальными машинами.
Полезно настроить мониторинг задач резервного копирования: Proxmox умеет отправлять уведомления о результатах бэкапов на почту, если настроен почтовый адрес в параметрах узла. Так вы быстрее узнаете о зависшем или упавшем задании, а не обнаружите блокировку случайно через несколько дней.
- 📧 Настройте уведомления о результатах бэкапов
- 🕐 Планируйте обслуживание узлов вне окон резервного копирования
- 💾 Следите за свободным местом на хранилище бэкапов — его нехватка частая причина обрыва vzdump
- 🔍 Периодически проверяйте конфигурации VM на забытые параметры lock
⚠️ Внимание: если блокировки появляются регулярно без видимых причин, проверьте состояние дисковой подсистемы и сетевых хранилищ узла. Повторяющиеся зависания задач — типичный симптом проблем с NFS, Ceph или локальными дисками, а не самой системы блокировок.
Частые вопросы
Что делает команда qm unlock?
Команда удаляет параметр lock из конфигурационного файла виртуальной машины, снимая запрет на операции с ней. Она не завершает процессы и не отменяет задачи — только убирает флаг блокировки, поэтому важно заранее убедиться, что связанная задача действительно завершена.
Опасно ли снимать блокировку принудительно?
Если зависшая задача мертва — нет, это штатная процедура. Риск возникает, только когда lock снимают во время реально работающего бэкапа или миграции: возможны повреждение диска VM и рассинхронизация данных в кластере.
qm unlock не помогает, VM всё равно не запускается. Что проверить?
Посмотрите журнал задачи запуска в веб-интерфейсе — там указана конкретная ошибка. Типичные причины: недоступное хранилище с диском VM, повреждённый конфигурационный файл, нехватка ресурсов на узле или остаточный процесс QEMU, который нужно завершить вручную.
Как разблокировать контейнер LXC, а не виртуальную машину?
Для контейнеров LXC используется отдельная утилита — pct. Проверьте конфигурацию контейнера в /etc/pve/lxc/<CTID>.conf на наличие параметра lock и при необходимости удалите его вручную, предварительно убедившись, что задачи с контейнером завершены. Команда qm unlock к контейнерам не применяется.
Можно ли снять блокировку через веб-интерфейс?
Штатной кнопки снятия lock в веб-интерфейсе Proxmox нет — разблокировка выполняется через консоль узла по SSH или через встроенную веб-консоль Shell, доступную в интерфейсе узла. Там же выполняется команда qm unlock <VMID>.