Управление виртуальными машинами Proxmox через CLI: запуск и остановка
- Утилита qm: один инструмент, всё управление
- Запуск, остановка и всё между ними
- Алгоритм безопасного выключения
- Массовые операции через скрипты
- Приостановка ВМ: когда stop — слишком радикально
- Hookscript: то, о чём молчит документация
- Работа в кластере
- Типичные аварийные сценарии
- CLI vs веб-интерфейс: честный разбор
Веб-интерфейс Proxmox завис — браузер крутит колёсико, сессия не отвечает. А вам нужно перезапустить конкретную ВМ прямо сейчас. SSH на хост открыт, и вот тут начинается настоящая работа.
Именно в таких ситуациях понимаешь, зачем вообще учить команды управления виртуальными машинами через консоль. Не ради красоты, а ради контроля — когда GUI не вариант, CLI не подводит.
Утилита qm: один инструмент, всё управление
Весь жизненный цикл ВМ в Proxmox закрывается через одну утилиту — qm. Это не просто обёртка для запуска и остановки: qm — фронтенд к QEMU/KVM, через который вы создаёте, правите, мигрируете машины и управляете снапшотами. Но прежде чем управлять машинами через CLI, важно убедиться, что хост отвечает системным требованиям Proxmox к аппаратным ресурсам. Веб-интерфейс 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
Запуск, остановка и всё между ними
Команды управления ВМ в Proxmox образуют чёткую иерархию действий. Вот полная таблица с описанием того, что реально происходит на уровне гостя:
| Команда | Что происходит | Когда использовать |
|---|---|---|
|
qm start |
Запуск ВМ | Холодный старт остановленной машины |
|
qm shutdown |
ACPI poweroff → гостевая ОС завершает работу | Штатное выключение с сохранением данных |
|
qm stop |
Мгновенная остановка, аналог отключения питания | Зависшая ВМ, не реагирующая на shutdown |
|
qm reset |
Жёсткая перезагрузка (аналог reset на корпусе) | Перезапуск без ожидания graceful shutdown |
|
qm suspend |
Приостановка ВМ (состояние сохраняется в RAM) | Краткое обслуживание хоста |
|
qm resume |
Возобновление из приостановки | После обслуживания |
Разница между shutdown и stop — принципиальная, и её стоит понять один раз, чтобы не наступать на грабли.
qm shutdown
qm stop
Алгоритм безопасного выключения
Практика хорошей эксплуатации — это всегда «лесенка» действий, а не сразу stop. Вот рабочий алгоритм:
- Отправить qm shutdown
и засечь время - Подождать 60–120 секунд, проверить статус через qm status
- Если ВМ всё ещё running — проверить, что происходит внутри гостя (подключиться через qm terminal
или VNC) - Если гость завис намертво — применить qm stop
с пониманием последствий - Зафиксировать факт жёсткой остановки в операционном журнале
Логировать остановки стоит хотя бы через простой bash-вывод в файл — особенно если в инфраструктуре есть ВМ с базами данных или сервисами без репликации.
# Пример простого логирования остановки
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
Дежурный администратор через полгода скажет вам спасибо — или вы сами скажете спасибо своему прошлому себе, когда будете разбирать инцидент и смотреть, кто и когда что останавливал.
Массовые операции через скрипты
Вот где CLI по-настоящему выигрывает у веб-морды. Допустим, нужно выключить все тестовые ВМ перед обновлением хоста. Через GUI это — открыть каждую машину, нажать Shutdown, подтвердить, перейти к следующей. В CLI:
# Получить VMID всех запущенных ВМ и выключить их
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" | grep -oP '(?<=status: )\w+')
[ "$status" = "stopped" ] && break
echo " Still running after ${#i}*5s..."
done
if [ "$(qm status "$vmid" | grep -oP '(?<=status: )\w+')" != "stopped" ]; then
echo " Force stopping VM $vmid"
qm stop "$vmid"
fi
done
Такие скрипты легко встраиваются в Ansible playbook или cron-задачи для ночных регламентных окон. Это уже не «администрирование руками», а автоматизация с аудит-трейлом.
Приостановка ВМ: когда stop — слишком радикально
qm suspend
Это удобно для коротких операций обслуживания хоста, когда перезапускать ВМ нет смысла: например, заменить планку памяти в безгорячей замене (если шасси позволяет) или переключить кабель. Время простоя минимальное.
Есть нюанс: suspend хранит состояние в оперативной памяти хоста. Если хост по какой-то причине перезагружается — suspended ВМ теряют своё состояние и потребуют холодного старта. Для долгосрочного сохранения состояния есть другой инструмент — snapshots с сохранением RAM-состояния, но это уже отдельная тема.
Ещё один момент, про который забывают: сетевые сессии внутри suspended ВМ могут оборваться, если пауза затянулась. TCP-таймауты никто не отменял — коннекты к БД, SSH-сессии, активные запросы к API могут потребовать переустановки после qm resume. Для stateless-сервисов это не проблема, для stateful — планируйте это заранее.
Hookscript: то, о чём молчит документация
Большинство администраторов Proxmox знают qm start и qm stop. Немногие знают про hookscript — и зря.
Hookscript — это скрипт, который Proxmox вызывает на определённых этапах жизненного цикла ВМ: перед стартом, после остановки, перед миграцией, до/после бэкапа. Привязывается к конкретной ВМ:
qm set
Скрипт получает два аргумента: VMID и фазу (pre-start, post-start, pre-stop, post-stop, pre-migrate, и т.д.).
Что можно с этим делать:
- Отправлять уведомления в Telegram или Slack при старте/остановке конкретных ВМ
- Делать pre-backup проверки: убедиться, что БД в консистентном состоянии перед снапшотом
- Монтировать/размонтировать NFS-шары только когда ВМ активна
- Логировать все операции с ВМ в централизованную систему
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 в Proxmox, если оно ещё не добавлено. Это делается через pvesm или в веб-интерфейсе в разделе Datacenter → Storage.
Hookscript — один из тех инструментов, которые кажутся избыточными до первого серьёзного инцидента. После того как вы один раз не поймёте, почему ВМ запустилась в три ночи без видимой причины, желание настроить аудит событий появляется само собой.
Это не экзотика — это нормальная практика для инфраструктур, где важна прозрачность операций.
Работа в кластере
Если Proxmox развёрнут в кластере, CLI-команды работают прозрачно через любой узел. Не нужно SSH-ить на конкретную ноду, где живёт ВМ — можно управлять с управляющего узла:
# Запустить ВМ 101, которая живёт на ноде pve-node2
qm start 101 --node pve-node2
Для просмотра всех ВМ кластера используйте pvesh:
pvesh get /cluster/resources --type vm
Это особенно полезно при написании скриптов автоматизации: не нужно динамически определять, на какой ноде живёт каждая ВМ — команда сама разберётся. Можно написать один скрипт обслуживания, который запускается на любом узле кластера и корректно управляет всеми машинами — независимо от того, где они физически размещены. Для небольших кластеров (3–5 нод) это избавляет от необходимости поддерживать отдельные скрипты для каждого хоста.
Типичные аварийные сценарии
ВМ не реагирует на shutdown. Гость завис, qm status показывает running, но из машины нет ответа. Алгоритм: подключиться через qm terminal
Зависание backup/restore. Иногда операции снапшота подвешивают ВМ в промежуточном состоянии. qm status может показывать странные статусы вроде paused. В этом случае — qm resume
После qm stop гость не запускается. Чаще всего — fsck на следующий старт, если файловая система без journaling. Запустить ВМ, дать fsck отработать. Если диск был в консистентном состоянии — всё пройдёт нормально. Если нет — придётся восстанавливать из бэкапа, и здесь критически важно иметь заранее настроенную систему резервирования Proxmox Backup Server.
Регламент для дежурного персонала. Хорошая практика — зафиксировать в операционных инструкциях чёткое правило: жёсткая остановка через qm stop применяется только после согласования или при наступлении заранее описанных условий (ВМ не реагирует более N минут, shutdown завис, нет ответа на консоли). Это убирает самодеятельность в ночных дежурствах и даёт понятный аудит-трейл.
CLI vs веб-интерфейс: честный разбор
Веб-интерфейс Proxmox — отличный инструмент для разовых операций, визуального контроля и работы с незнакомой инфраструктурой. Он нагляден, интуитивен и не требует запоминания синтаксиса.
CLI выигрывает там, где нужна повторяемость и автоматизация:
| Задача | GUI | CLI |
|---|---|---|
| Запустить одну ВМ вручную | Удобно | Можно, но избыточно |
| Выключить 20 ВМ по расписанию | Больно | Один скрипт |
| Аудит-трейл всех операций | Сложно | Легко через logging |
| Интеграция с Ansible/CI/CD | Нет | Да |
| Работа при недоступном GUI | Нет | Да |
| Hookscript и тонкая настройка | Нет | Да |
Инвестиция в освоение CLI окупается при первом же плановом обслуживании кластера — когда вместо двух часов кликов в браузере уходит пять минут на скрипт.
Proxmox через CLI — это не хардкор ради хардкора. Это нормальный инструментарий администратора, который понимает, что делает и осознанно выбрал подходящий гипервизор для своих задач. Hookscript, массовые скрипты, прозрачная работа в кластере — всё это доступно прямо сейчас, без дополнительных плагинов и лицензий. Веб-морда никуда не денется, но знать, что за ней — полезно.
