Команда qm shutdown 100 отправлена, но виртуальная машина в Proxmox продолжает висеть в статусе running — типичный признак того, что гостевая ОС игнорирует сигнал ACPI или агент QEMU Guest Agent не отвечает. Веб-интерфейс при этом может показывать крутящийся индикатор задачи «VM 100 - Shutdown», которая завершается по таймауту с ошибкой. Ситуация неприятная, особенно когда нужно перезагрузить сам гипервизор или применить новые настройки к ВМ.
Хорошая новость: проблема почти всегда решается штатными средствами Proxmox VE, без риска для данных на хосте. Ниже разберём, почему виртуалка отказывается выключаться, как корректно завершить её принудительно и что настроить, чтобы зависания при shutdown не повторялись.
Почему виртуальная машина в Proxmox не выключается
Штатное выключение ВМ в Proxmox VE работает через отправку гостевой системе сигнала ACPI shutdown — аналог короткого нажатия кнопки питания на физическом компьютере. Если гостевая ОС зависла, перегружена или в ней отключена обработка ACPI-событий, сигнал просто игнорируется. Гипервизор при этом честно ждёт ответа, и задача выключения «зависает» до истечения таймаута.
Вторая частая причина — отсутствие или неработающий QEMU Guest Agent. Если в настройках ВМ включена опция QemuAgent, но сам агент в гостевой системе не установлен или его служба остановлена, Proxmox не может передать команду выключения внутрь машины. Возможная причина также кроется в заблокированном диске ВМ: при проблемах с хранилищем (недоступный NFS, переполненный LVM) процесс виртуалки может зависнуть в состоянии ожидания ввода-вывода.
- 🔌 Гостевая ОС не обрабатывает ACPI-сигнал (зависла или служба отключена)
- 🤖 QEMU Guest Agent включён в настройках, но не работает внутри гостя
- 💾 Проблемы с хранилищем — диск ВМ недоступен, процесс в D-state
- ⏱️ Слишком короткий таймаут shutdown в конфигурации ВМ
Диагностика: что проверить в первую очередь
Прежде чем принудительно «дергать» виртуалку, стоит понять, жив ли гость внутри. Откройте консоль ВМ через веб-интерфейс: если система реагирует на ввод — попробуйте выключить её штатно изнутри (shutdown now в Linux или через меню «Пуск» в Windows). Это самый безопасный путь, исключающий повреждение файловой системы гостя.
Проверить состояние машины и задачи можно из консоли самого гипервизора:
qm status 100
qm agent 100 ping
Если qm agent ping возвращает ошибку — агент не отвечает, и надеяться на «мягкое» выключение через него бессмысленно. Команда qm status покажет, в каком состоянии находится ВМ: running, paused или stopped. Дополнительно посмотрите лог задачи выключения в веб-интерфейсе (двойной клик по задаче в нижней панели) — там видно, на каком этапе всё застопорилось.
Мягкое выключение: shutdown с таймаутом
Стандартная команда выключения выглядит так:
qm shutdown 100 --timeout 120Параметр --timeout задаёт время ожидания в секундах, после которого Proxmox сам перейдёт к принудительной остановке. Без него задача может ждать значительно дольше. В веб-интерфейсе аналогичное действие — кнопка Shutdown в контекстном меню ВМ, а таймаут настраивается в разделе Options → Start/Shutdown.
Если гость периодически «задумывается» при выключении из-за долгой остановки служб (например, баз данных), увеличение таймаута — правильное решение, а не костыль. Windows-гости нередко тянут с завершением из-за установки обновлений, и прерывать этот процесс принудительно крайне нежелательно.
Принудительная остановка: qm stop и kill
Когда мягкие методы исчерпаны, используйте qm stop — аналог выдергивания шнура питания:
qm stop 100Команда немедленно завершает процесс виртуальной машины. Все несохранённые данные в госте будут потеряны, а файловая система при следующей загрузке, скорее всего, потребует проверки. Именно поэтому qm stop — крайняя мера после неудачного shutdown, а не способ выключения по умолчанию.
⚠️ Внимание: принудительная остановка ВМ с активной базой данных (MySQL, PostgreSQL, MS SQL) может привести к повреждению таблиц. Если внутри гостя крутится СУБД, сначала попробуйте зайти в консоль и остановить службы вручную.
В редких случаях даже qm stop не помогает — процесс qemu завис в непрерываемом состоянии из-за недоступного хранилища. Тогда на хосте можно найти PID процесса и завершить его вручную:
ps aux | grep "kvm.*id 100"
kill -9 <PID>
После этого убедитесь, что снят lock-файл ВМ: qm unlock 100 — иначе машина не запустится снова, ругаясь на блокировку конфигурации.
☑️ Порядок действий при зависшей ВМ
Сравнение способов выключения ВМ
| Метод | Команда | Безопасность данных | Когда применять |
|---|---|---|---|
| Выключение изнутри гостя | shutdown в ОС | Максимальная | Гость отвечает в консоли |
| ACPI shutdown | qm shutdown 100 | Высокая | Штатное выключение |
| Через Guest Agent | qm agent 100 shutdown | Высокая | Агент установлен и работает |
| Принудительная остановка | qm stop 100 | Риск потери данных | Shutdown не срабатывает |
| Завершение процесса | kill -9 PID | Риск повреждения ФС | qm stop не помогает |
Настройка QEMU Guest Agent для надёжного выключения
Чтобы выключение работало стабильно, установите и включите QEMU Guest Agent в гостевой системе. В Linux это пакет qemu-guest-agent из штатного репозитория, в Windows — драйвер из состава VirtIO Drivers. После установки включите опцию агента в настройках ВМ: Hardware → Options → QEMU Guest Agent (или галочка в зависимости от версии интерфейса).
Проверка работоспособности агента выполняется командой qm agent 100 ping — успешный ответ означает, что Proxmox может управлять гостем изнутри: корректно выключать, делать заморозку ФС при снапшотах и получать информацию о сети. Точные названия пунктов меню и пакетов зависят от версии Proxmox VE и гостевой ОС, поэтому при расхождениях сверяйтесь с официальной документацией вашей версии.
⚠️ Внимание: не включайте опцию QEMU Guest Agent в настройках ВМ до установки агента в госте. Иначе Proxmox будет пытаться связаться с несуществующим агентом, и задачи shutdown/backup станут завершаться с ошибками по таймауту.
Дополнительно
как включить обработку ACPI в Linux-госте:В некоторых минимальных установках Linux демон acpid отсутствует, и гость не реагирует на ACPI shutdown. Установите пакет acpid (или убедитесь, что systemd-logind обрабатывает события питания) и перезапустите службу. После этого команда qm shutdown начнёт корректно завершать систему.
Профилактика зависаний при выключении
Чтобы проблема не повторялась, настройте адекватные таймауты в разделе Options → Start/Shutdown каждой ВМ: для «тяжёлых» гостей с базами данных — больше, для лёгких контейнероподобных машин — меньше. Следите и за здоровьем хранилища: зависания процессов qemu в D-state почти всегда указывают на проблемы с дисковой подсистемой или сетевым хранилищем, а не на саму виртуалку.
Регулярно обновляйте гостевые агенты и проверяйте после обновлений Proxmox, что связка «гипервизор — агент» работает. Если ВМ критична, настройте мониторинг состояния через qm status по расписанию — это позволит заметить зависшую задачу выключения до того, как она сорвёт плановую перезагрузку хоста.
Часто задаваемые вопросы
Почему задача Shutdown висит и завершается с ошибкой timeout?
Гостевая ОС не ответила на ACPI-сигнал за отведённое время. Либо система зависла, либо не настроена обработка ACPI, либо таймаут слишком мал для медленного гостя. Увеличьте --timeout и проверьте консоль ВМ.
Чем qm stop отличается от qm shutdown?
qm shutdown — корректное выключение через ACPI или агент, с сохранением данных. qm stop — мгновенное завершение процесса, эквивалент отключения питания, с риском потери несохранённых данных.
ВМ не запускается после принудительной остановки, пишет про lock. Что делать?
Выполните qm unlock <ID> — команда снимает блокировку конфигурации, оставшуюся после аварийного завершения. Перед этим убедитесь, что процесс qemu действительно завершён.
Обязательно ли ставить QEMU Guest Agent?
Не обязательно, но настоятельно полезно: без агента выключение идёт только через ACPI, снапшоты делаются без заморозки ФС, а информация о госте недоступна. Для продуктивных ВМ агент — фактический стандарт.
qm stop не помогает, ВМ всё равно висит. Что дальше?
Найдите PID процесса qemu-кvm для этой ВМ через ps aux и завершите его командой kill -9. Затем выполните qm unlock. Если процесс в D-state и не убивается — проблема в хранилище: проверяйте доступность дисков и сетевых шар, в тяжёлых случаях потребуется перезагрузка хоста.