Эксперты в подборе IT-оборудования
Веб-интерфейс Proxmox завис - браузер крутит колёсико, сессия не отвечает. А вам нужно перезапустить конкретную ВМ прямо сейчас. SSH на хост открыт, и вот тут начинается настоящая работа.
Именно в таких ситуациях понимаешь, зачем вообще учить команды управления виртуальными машинами через консоль. Не ради красоты, а ради контроля - когда GUI не вариант, CLI не подводит.
Весь жизненный цикл ВМ в Proxmox закрывается через одну утилиту - qm. Это фронтенд к QEMU/KVM, через который вы создаёте, правите, мигрируете машины и управляете снапшотами. Но прежде чем управлять машинами через CLI, стоит убедиться, что хост отвечает системным требованиям Proxmox к аппаратным ресурсам. Веб-интерфейс те же операции выполняет через API Proxmox, так что результат у консоли и у браузера один и тот же.
Синтаксис прямолинейный: qm <команда>
Посмотреть список всех ВМ и их текущие состояния:
qm list
Вывод будет примерно таким:
VMID NAME STATUS MEM(MB) BOOTDISK(GB) PID
100 web-prod running 4096 50.00 12345
101 db-staging stopped 8192 100.00 0
102 test-runner running 2048 20.00 67890
Уже этого достаточно, чтобы скомбинировать с grep или awk - например, вытащить только остановленные машины или отфильтровать по шаблону имени. Статус конкретной ВМ:
qm status 100
Команды управления ВМ в Proxmox образуют чёткую иерархию действий. Вот таблица с описанием того, что реально происходит на уровне гостя:
| Команда | Что происходит | Когда использовать |
|---|---|---|
| qm start 100 | Запуск ВМ | Холодный старт остановленной машины |
| qm shutdown 100 | ACPI poweroff, гостевая ОС завершает работу | Штатное выключение с сохранением данных |
| qm stop 100 | Мгновенная остановка, аналог отключения питания | Зависшая ВМ, не реагирующая на shutdown |
| qm reset 100 | Жёсткая перезагрузка (аналог reset на корпусе) | Перезапуск без ожидания graceful shutdown |
| qm suspend 100 | Приостановка ВМ, состояние сохраняется в RAM | Краткое обслуживание хоста |
| qm resume 100 | Возобновление из приостановки | После обслуживания |
Разница между shutdown и stop - принципиальная, и её стоит понять один раз, чтобы не наступать на грабли.
qm shutdown посылает гостевой ОС событие ACPI poweroff. Windows корректно закрывает открытые файлы, Linux размонтирует файловые системы, базы данных делают checkpoint. Процесс занимает время - от нескольких секунд до минуты - зато данные в безопасности.
qm stop - это буквально выдернуть вилку из розетки у физического сервера. QEMU-процесс убивается немедленно. Никакого graceful shutdown, никаких уведомлений гостевой ОС. Файловые системы без журналирования получат fsck при следующем старте. PostgreSQL запустит recovery. Это инструмент для экстренных ситуаций, а не для повседневного использования.
qm stop убивает QEMU-процесс на уровне хоста - гостевая ОС даже не узнаёт, что её выключили. Журналирование в Linux и VSS в Windows существуют именно для таких случаев.
Отдельно про таймаут. У qm shutdown он по умолчанию 180 секунд: если за это время гость не погас, операция завершится ошибкой вида «VM quit/powerdown failed - got timeout». Чаще всего причина не в зависании, а в том, что гостевая ОС не понимает ACPI-сигнал: в Linux не установлен обработчик, в Windows выключение заблокировано диалогом «сохранить изменения». Ждать дольше можно флагом --timeout, но правильнее разобраться, почему гость не реагирует.
Практика хорошей эксплуатации - это всегда «лесенка» действий, а не сразу stop. Вот рабочий алгоритм:
Логировать остановки стоит хотя бы простым выводом в файл - особенно если в инфраструктуре есть ВМ с базами данных или сервисами без репликации.
VMID=101
echo "[$(date '+%Y-%m-%d %H:%M:%S')] Shutting down VM $VMID" >> /var/log/vm-operations.log
qm shutdown $VMID
echo "[$(date '+%Y-%m-%d %H:%M:%S')] VM $VMID shutdown initiated" >> /var/log/vm-operations.log
Дежурный администратор через полгода скажет вам спасибо - или вы сами скажете спасибо своему прошлому себе, когда будете разбирать инцидент и смотреть, кто и когда что останавливал.
Пункт «посмотреть, что происходит внутри гостя» звучит просто ровно до момента, когда веб-интерфейс недоступен. Способов попасть в машину с хоста три, и они решают разные задачи.
qm terminal 100 подключает к последовательной консоли гостя. Это самый удобный вариант для Linux-машин, но он не работает «из коробки»: у ВМ должно быть настроено последовательное устройство.
qm set 100 -serial0 socket
После этого машину нужно полностью остановить и запустить заново - qm reset не подойдёт, QEMU должен переинициализировать устройство. Дополнительно гостевая ОС должна выводить консоль в этот порт: в Linux это правится в GRUB через console=ttyS0. Без этих двух шагов команда просто не подключится, и выглядеть это будет как «не работает».
Из qm terminal выходят сочетанием Ctrl+O. Отсюда неочевидная ловушка: в редакторе nano Ctrl+O - это «сохранить файл», и попытка сохранить конфиг прямо в консоли выбросит вас из сессии вместо сохранения. Привыкайте сохранять в nano через Ctrl+X с подтверждением.
qm monitor 100 открывает монитор самого QEMU - низкоуровневый интерфейс к процессу виртуальной машины. Он нужен редко: посмотреть состояние виртуальных устройств, извлечь образ из виртуального привода, разобраться с зависшей операцией снапшота.
Осторожно: команда quit в мониторе QEMU не закрывает сессию, а завершает процесс QEMU, то есть выключает виртуальную машину как по qm stop. Чтобы просто выйти из монитора, используйте Ctrl+C.
noVNC - графическая консоль из веб-интерфейса. Единственный вариант, если гость Windows или если нужно попасть в загрузчик и BIOS машины. Работает без настройки последовательного порта, но требует живого веб-интерфейса.
Практическое правило: для Linux-гостей заранее включайте serial0 на всех машинах, где может понадобиться аварийный доступ. Настроить это на работающей машине в спокойное время - десять минут, а во время аварии, когда GUI лежит, сделать это уже нельзя: нужен полный перезапуск ВМ.
Вот где CLI по-настоящему выигрывает у веб-морды. Допустим, нужно выключить все тестовые ВМ перед обновлением хоста. Через GUI это - открыть каждую машину, нажать Shutdown, подтвердить, перейти к следующей. В CLI:
qm list | awk 'NR>1 && $3=="running" {print $1}' | while read vmid; do
echo "Shutting down VM $vmid..."
qm shutdown "$vmid"
done
Или более осторожный вариант - с ожиданием подтверждения остановки каждой машины:
for vmid in $(qm list | awk 'NR>1 && $3=="running" {print $1}'); do
echo "Stopping VM $vmid"
qm shutdown "$vmid"
# Ждём до 90 секунд
for i in $(seq 1 18); do
sleep 5
status=$(qm status "$vmid" | awk '{print $2}')
[ "$status" = "stopped" ] && break
echo " Still running after $((i*5))s..."
done
if [ "$(qm status "$vmid" | awk '{print $2}')" != "stopped" ]; then
echo " Force stopping VM $vmid"
qm stop "$vmid"
fi
done
Такие скрипты легко встраиваются в Ansible playbook или cron-задачи для ночных регламентных окон. Это уже не «администрирование руками», а автоматизация с аудит-трейлом.
qm suspend 100 сохраняет текущее состояние ВМ в RAM и останавливает выполнение. Машина не отвечает на сетевые запросы, но при qm resume 100 продолжает работу с той же точки - как будто ничего не было.
Это удобно для коротких операций обслуживания хоста, когда перезапускать ВМ нет смысла. Время простоя минимальное.
Есть нюанс: suspend хранит состояние в оперативной памяти хоста. Если хост по какой-то причине перезагружается - приостановленные ВМ теряют своё состояние и потребуют холодного старта. Для долгосрочного сохранения состояния есть другой инструмент - снапшоты с сохранением RAM, но это уже отдельная тема.
Ещё один момент, про который забывают: сетевые сессии внутри приостановленной ВМ могут оборваться, если пауза затянулась. TCP-таймауты никто не отменял - коннекты к БД, SSH-сессии, активные запросы к API могут потребовать переустановки после resume. Для stateless-сервисов это не проблема, для stateful - планируйте заранее.
Перед qm suspend убедитесь, что на хосте достаточно свободной RAM. Состояние ВМ с 16 ГБ оперативки займёт около 16 ГБ на хосте - плюсом к тому, что уже занято другими машинами.
После перезагрузки хоста машины по умолчанию не поднимаются - это надо включить явно:
qm set 100 --onboot 1
Дальше начинается то, ради чего этот механизм и существует. Если в инфраструктуре есть зависимости - контроллер домена, база данных, приложение, - поднимать их одновременно бессмысленно: приложение стартует раньше базы и упадёт. Порядок задаётся так:
qm set 100 --startup order=1,up=60
qm set 101 --startup order=2,up=30
qm set 102 --startup order=3
order - очередь запуска, машины с меньшим номером стартуют раньше. Машины без указанного order поднимаются последними.
А вот up - параметр, который понимают неправильно чаще всего.
up=60 задерживает не эту машину, а следующую за ней. Proxmox запускает машину с order=1, ждёт 60 секунд и только потом берётся за order=2. Это не «подождать минуту перед стартом контроллера домена», а «дать контроллеру домена минуту подняться, прежде чем стартовать базу».
Параметр down работает симметрично при выключении и задаёт, сколько секунд ждать остановки машины, прежде чем переходить к следующей. Выключение идёт в обратном порядке: последняя запущенная гасится первой. Это ровно то поведение, которое нужно: приложение останавливается раньше базы, база раньше контроллера домена.
Проверить, что получилось, можно в конфиге машины:
qm config 100 | grep -E 'onboot|startup'
Большинство администраторов Proxmox знают qm start и qm stop. Немногие знают про hookscript - и зря.
Hookscript - это скрипт, который Proxmox вызывает на определённых этапах жизненного цикла ВМ: перед стартом, после остановки, перед миграцией, до и после бэкапа. Привязывается к конкретной машине:
qm set 100 --hookscript local:snippets/myhook.sh
Скрипт получает два аргумента: VMID и фазу (pre-start, post-start, pre-stop, post-stop и так далее).
Что можно с этим делать:
Hookscript должен быть исполняемым файлом в директории /var/lib/vz/snippets/ на хосте или в соответствующем пуле хранилища. Простой пример для Telegram-уведомления:
#!/bin/bash
VMID=$1
PHASE=$2
TOKEN="ваш_токен"
CHAT_ID="ваш_chat_id"
if [ "$PHASE" = "post-start" ]; then
curl -s -X POST "https://api.telegram.org/bot${TOKEN}/sendMessage" \
-d "chat_id=${CHAT_ID}&text=VM ${VMID} started on $(hostname)"
fi
После создания скрипта не забудьте сделать его исполняемым через chmod +x и зарегистрировать хранилище snippets, если оно ещё не добавлено. Это делается через pvesm или в веб-интерфейсе в разделе Datacenter → Storage.
Hookscript - один из тех инструментов, которые кажутся избыточными до первого серьёзного инцидента. После того как вы один раз не поймёте, почему ВМ запустилась в три ночи без видимой причины, желание настроить аудит событий появляется само собой.
Здесь есть важное ограничение, о которое спотыкаются регулярно: qm работает только с машинами своего узла. Флага, который переключил бы её на соседнюю ноду, у неё нет. Если выполнить qm start 101 на узле, где машины 101 нет, команда честно ответит, что такой конфигурации не существует.
Машинами всего кластера с любого узла управляет pvesh - консольный клиент к API Proxmox. Тот же API использует и веб-интерфейс, поэтому доступно всё то же самое:
pvesh create /nodes/pve-node2/qemu/101/status/start
Остановка и штатное выключение устроены симметрично:
pvesh create /nodes/pve-node2/qemu/101/status/shutdown
pvesh create /nodes/pve-node2/qemu/101/status/stop
Чтобы не выяснять вручную, на каком узле живёт каждая машина, список всего кластера берут одной командой:
pvesh get /cluster/resources --type vm
В выводе есть и VMID, и имя узла - этого достаточно, чтобы скрипт обслуживания сам разобрался, куда обращаться, и запускался с любой ноды кластера. Второй рабочий вариант, если писать через API не хочется: определить узел этой же командой и зайти на него по SSH, а дальше работать привычной qm.
О том, как машины переезжают между узлами и что при этом ломается, подробно разобрано в статье про совместную работу Ubuntu и Proxmox и миграцию виртуальных машин.
Отдельная задача, которую путают с остановкой ВМ: погасить или перезагрузить сам сервер Proxmox. Команды здесь обычные линуксовые, выполняются на узле по SSH:
shutdown -h now
reboot
Главное - понимать, что при этом происходит с гостями. Proxmox не бросает их: при остановке узла отрабатывает служба pve-guests, которая сначала отменяет запущенные задания резервного копирования, а затем штатно гасит все работающие машины и контейнеры. Порядок и задержки берутся из тех самых параметров order и down, что описаны выше, и выключение идёт в обратном порядке запуска.
Из этого следуют две практические вещи.
Первое: выключение хоста может подвиснуть. Если какая-то ВМ не реагирует на ACPI, узел будет ждать её таймаут, и «быстрая перезагрузка» растянется на несколько минут. Перед плановыми работами разумнее погасить тяжёлые машины заранее своим скриптом и убедиться по qm list, что все они в состоянии stopped, - тогда сам хост уйдёт в перезагрузку за секунды.
Второе: --onboot определяет, что поднимется обратно. Машины без этого флага после перезагрузки останутся выключенными, и обнаружится это обычно утром.
В кластере добавляется ещё один слой. Узел с настроенной высокой доступностью при выключении не просто гасит гостей: HA-ресурсы, в зависимости от политики выключения, могут быть перенесены на другие узлы, а после возвращения узла в строй - вернуться обратно. Если вы гасите узел для обслуживания, а не выводите его насовсем, стоит заранее посмотреть, что настроено в политике, чтобы кластер не начал массово мигрировать машины в неподходящий момент.
Отдельно про удалённое выключение. Штатных способов ровно два - SSH на узел и кнопка Shutdown в веб-интерфейсе. Если нужен гарантированный доступ к серверу, когда операционная система уже не отвечает, это задача не Proxmox, а IPMI или iDRAC на самом железе - и настраивать их надо до того, как они понадобятся.
ВМ не реагирует на shutdown. Гость завис, qm status 100 показывает running, но из машины нет ответа. Алгоритм: подключиться через qm terminal 100 или noVNC, попробовать разобраться изнутри. Если гость полностью мёртв - qm stop 100, затем проверка журналов после перезапуска.
Зависание бэкапа или восстановления. Иногда операции снапшота подвешивают ВМ в промежуточном состоянии, и qm status показывает paused. В этом случае - qm resume 100, а если не помогает, посмотреть процессы на хосте через ps aux | grep 100 и разбираться с QEMU-процессом напрямую.
После qm stop гость не запускается. Чаще всего это fsck на следующем старте, если файловая система без журналирования. Запустить ВМ, дать проверке отработать. Если диск был в консистентном состоянии - всё пройдёт нормально. Если нет - придётся восстанавливать из бэкапа, и здесь критически важно иметь заранее настроенную систему резервирования Proxmox Backup Server.
Не открывается веб-интерфейс. Тот самый сюжет, с которого начинался разговор. Отвечает за него служба pveproxy, и лечится это обычно с первого раза:
systemctl status pveproxy
systemctl restart pveproxy
Если после перезапуска интерфейс всё ещё не поднимается, стоит проверить свободное место на разделе с /var - переполненный диск роняет службы Proxmox одними из первых, - а также systemctl status pve-cluster, потому что без него веб-интерфейс не стартует. Виртуальные машины при этом продолжают работать: падение интерфейса не останавливает гостей, и чинить его можно спокойно.
Регламент для дежурного персонала. Хорошая практика - зафиксировать в операционных инструкциях чёткое правило: жёсткая остановка через qm stop применяется только после согласования или при наступлении заранее описанных условий. Это убирает самодеятельность в ночных дежурствах и даёт понятный аудит-трейл.
Веб-интерфейс Proxmox - отличный инструмент для разовых операций, визуального контроля и работы с незнакомой инфраструктурой. Он нагляден, интуитивен и не требует запоминания синтаксиса.
CLI выигрывает там, где нужна повторяемость и автоматизация:
| Задача | GUI | CLI |
|---|---|---|
| Запустить одну ВМ вручную | Удобно | Можно, но избыточно |
| Выключить 20 ВМ по расписанию | Больно | Один скрипт |
| Аудит-трейл всех операций | Сложно | Легко через логирование |
| Интеграция с Ansible и CI/CD | Нет | Да |
| Работа при недоступном GUI | Нет | Да |
| Hookscript и тонкая настройка | Нет | Да |
Инвестиция в освоение CLI окупается при первом же плановом обслуживании кластера - когда вместо двух часов кликов в браузере уходит пять минут на скрипт.
Proxmox через CLI - это не хардкор ради хардкора. Это нормальный инструментарий администратора, который понимает, что делает, и осознанно выбрал подходящий гипервизор для своих задач. Hookscript, массовые скрипты, работа с кластером через API - всё это доступно прямо сейчас, без дополнительных плагинов и лицензий. Веб-морда никуда не денется, но знать, что за ней, полезно.
Как собрать под узлы отказоустойчивое хранилище - в материале про RAID в Proxmox. Как Proxmox выглядит на фоне ESXi, Hyper-V и чистого KVM - в сравнении гипервизоров 2026.
Собираете узлы под Proxmox или расширяете кластер?
Инженеры ITTELO подберут конфигурацию под вашу нагрузку и число виртуальных машин, помогут с дисковой подсистемой и сетью между узлами, соберут и протестируют сервер под задачу перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
Кластер серверов Proxmox · +7 (800) 551-80-12 · info@ittelo.ru
