Настройка автозапуска VM и LXC в Proxmox VE
Пошаговая настройка автозапуска виртуальных машин и LXC-контейнеров в Proxmox VE, порядка запуска, задержек и таймаутов остановки.
После перезагрузки узла Proxmox VE виртуальные машины и LXC-контейнеры не обязаны запускаться автоматически. Для постоянных сервисов автозапуск лучше настроить заранее, а зависимые системы запускать в правильной последовательности.
В этой инструкции рассматривается только автозапуск VM и LXC, порядок старта, задержки и таймауты остановки.
Подходит для: Proxmox VE 8 и 9
Уровень сложности: начальный
Время выполнения: около 10–15 минут
Требуемый доступ: права управления VM и LXC
Что будет настроено
После выполнения инструкции можно будет:
- включить автозапуск VM;
- включить автозапуск LXC;
- задать порядок запуска;
- настроить задержку между гостевыми системами;
- задать таймаут корректного завершения;
- проверить поведение после перезагрузки узла.
Когда нужен автозапуск
Автозапуск рекомендуется для:
- DNS;
- контроллеров домена;
- баз данных;
- reverse proxy;
- мониторинга;
- VPN;
- production-приложений;
- инфраструктурных сервисов.
Для тестовых VM и временных контейнеров автозапуск обычно не требуется.
Проверка текущих настроек VM
На узле Proxmox VE:
qm config VM_ID |
grep -E '^(onboot|startup):'
Пример:
qm config 100 |
grep -E '^(onboot|startup):'
Если параметр отсутствует, автозапуск не настроен явно.
Проверка текущих настроек LXC
pct config CT_ID |
grep -E '^(onboot|startup):'
Пример:
pct config 200 |
grep -E '^(onboot|startup):'
Включение автозапуска VM через веб-интерфейс
Откройте:
VM → Options
Найдите:
Start at boot
Нажмите:
Edit
Установите:
Yes
Сохраните.
Включение автозапуска LXC через веб-интерфейс
Откройте:
CT → Options
Найдите:
Start at boot
Установите:
Yes
Включение автозапуска VM через CLI
qm set VM_ID --onboot 1
Пример:
qm set 100 --onboot 1
Проверьте:
qm config 100 |
grep '^onboot'
Ожидаемый результат:
onboot: 1
Включение автозапуска LXC через CLI
pct set CT_ID --onboot 1
Пример:
pct set 200 --onboot 1
Проверьте:
pct config 200 |
grep '^onboot'
Отключение автозапуска
Для VM:
qm set VM_ID --onboot 0
Для LXC:
pct set CT_ID --onboot 0
Настройка порядка запуска
Параметр:
order
определяет последовательность запуска.
Чем меньше число, тем раньше запускается объект.
Пример логики:
10 — DNS и инфраструктурные сервисы
20 — базы данных
30 — приложения
40 — reverse proxy
50 — вспомогательные сервисы
Одинаковый order означает, что объекты могут запускаться без строгой последовательности между собой.
Настройка Startup order через веб-интерфейс
Откройте:
VM или CT → Options → Start/Shutdown order
Укажите:
Start order
Startup delay
Shutdown timeout
Сохраните.
Настройка порядка VM через CLI
qm set VM_ID --startup order=20
Пример:
qm set 100 --startup order=20
Проверьте:
qm config 100 |
grep '^startup'
Настройка порядка LXC через CLI
pct set CT_ID --startup order=20
Пример:
pct set 200 --startup order=20
Задержка после запуска
Параметр:
up
задаёт паузу в секундах после запуска объекта перед переходом к следующему.
Пример:
qm set 100 --startup order=20,up=30
Это означает:
- VM запускается с order 20;
- Proxmox ждёт 30 секунд;
- затем переходит к следующему объекту.
Для LXC:
pct set 200 --startup order=10,up=20
Таймаут остановки
Параметр:
down
задаёт максимальное время ожидания корректного завершения.
Пример:
qm set 100 --startup order=20,up=30,down=120
Для LXC:
pct set 200 --startup order=10,up=20,down=60
Если гостевая система не завершилась за это время, Proxmox может перейти к следующему этапу shutdown.
Пример зависимой инфраструктуры
Допустим, используются:
CT 200 — DNS
VM 100 — PostgreSQL
VM 101 — приложение
VM 102 — reverse proxy
Настройки:
pct set 200 --onboot 1 --startup order=10,up=20,down=60
qm set 100 --onboot 1 --startup order=20,up=60,down=180
qm set 101 --onboot 1 --startup order=30,up=30,down=120
qm set 102 --onboot 1 --startup order=40,up=10,down=60
Что означает порядок остановки
При выключении узла порядок обычно применяется в обратной последовательности.
Сначала останавливаются сервисы с большим order, затем — с меньшим.
В приведённом примере:
reverse proxy → приложение → база данных → DNS
Это логично, потому что зависимые приложения завершаются раньше инфраструктурных сервисов.
Проверка всех VM
Показать автозапуск VM:
for vmid in $(qm list | awk 'NR>1 {print $1}'); do
echo "VM $vmid"
qm config "$vmid" |
grep -E '^(name|onboot|startup):'
echo
done
Проверка всех LXC
for ctid in $(pct list | awk 'NR>1 {print $1}'); do
echo "CT $ctid"
pct config "$ctid" |
grep -E '^(hostname|onboot|startup):'
echo
done
Проверка startup-конфигурации через API
Список VM:
pvesh get /nodes/NODE_NAME/qemu
Список LXC:
pvesh get /nodes/NODE_NAME/lxc
Для конкретной VM:
pvesh get /nodes/NODE_NAME/qemu/VM_ID/config
Проверка QEMU Guest Agent
Для корректного shutdown VM желательно использовать QEMU Guest Agent.
В настройках VM:
Options → QEMU Guest Agent
Должно быть:
Enabled
Внутри Ubuntu или Debian:
systemctl status qemu-guest-agent --no-pager
Проверка с узла:
qm agent VM_ID ping
Проверка shutdown VM
Запустите тест:
qm shutdown VM_ID
Проверьте:
qm status VM_ID
Запустите снова:
qm start VM_ID
Если shutdown не работает, проверьте Guest Agent и ACPI внутри гостевой ОС.
Проверка shutdown LXC
pct shutdown CT_ID
Проверьте:
pct status CT_ID
Запустите:
pct start CT_ID
Ручной тест последовательности
Полную последовательность можно проверить в окно обслуживания.
Сначала зафиксируйте состояние:
qm list
pct list
Перезагрузите узел:
reboot
После запуска проверьте:
qm list
pct list
Проверка журнала после загрузки
journalctl -b |
grep -iE 'starting|start all|qemu|lxc'
Проверьте ошибки:
journalctl -b -p err --no-pager
Проверка времени запуска сервисов
Внутри VM:
uptime
Проверьте время запуска приложения:
systemctl status SERVICE_NAME --no-pager
Для зависимого сервиса проверьте журнал:
journalctl -u SERVICE_NAME -b --no-pager
Автозапуск не гарантирует готовность приложения
Параметр up=30 означает только ожидание 30 секунд после запуска VM или LXC.
Он не проверяет, что:
- база данных принимает подключения;
- DNS отвечает;
- приложение прошло healthcheck;
- сеть полностью готова;
- mount point подключён.
Для сложных систем зависимости должны дополнительно обрабатываться внутри гостевой ОС.
Зависимости внутри systemd
Внутри Linux можно использовать:
After=
Requires=
Wants=
в systemd unit.
Это надёжнее, чем полагаться только на фиксированную задержку.
Например, приложение должно уметь повторять подключение к базе данных после её запуска.
Автозапуск в кластере
В обычном кластере VM запускается на том узле, где она зарегистрирована.
Если используется High Availability, управлением запуска занимается HA stack.
Не следует одновременно полагаться на ручную startup-логику и HA без понимания приоритетов.
Проверка HA
ha-manager status
Если VM или LXC добавлены в HA, их запуск и перенос управляются кластером.
Настройка HA требует отдельной статьи.
Startup delay для всего узла
На уровне Datacenter можно задавать общую задержку запуска после загрузки узла.
Проверьте:
Datacenter → Options
Параметры могут включать startup delay для guest systems.
Используйте это, если после загрузки хоста требуется время на:
- подключение NFS;
- запуск Ceph;
- инициализацию сети;
- появление внешнего storage.
Проверка storage перед автозапуском
pvesm status
Если storage с дисками VM недоступен, автозапуск завершится ошибкой.
Для NFS:
mount |
grep /mnt/pve
Для ZFS:
zpool status
Типичные проблемы
VM не запустилась после reboot
Проверьте:
qm config VM_ID |
grep -E '^(onboot|startup)'
Проверьте storage:
pvesm status
Проверьте журнал:
journalctl -b |
grep -i "VM_ID"
LXC не запустился автоматически
Проверьте:
pct config CT_ID |
grep -E '^(onboot|startup)'
Запустите вручную:
pct start CT_ID
Посмотрите ошибку:
journalctl -u pve-container@CT_ID -n 100 --no-pager
Порядок запуска не соблюдается
Проверьте, что у каждого объекта задан уникальный order.
Пример:
order=10
order=20
order=30
Приложение стартует раньше базы данных
Увеличьте up для базы данных и настройте retry-логику приложения.
Не полагайтесь только на задержку Proxmox.
Shutdown узла длится слишком долго
Проверьте down и корректность завершения гостевых систем.
Для VM:
qm shutdown VM_ID
Для LXC:
pct shutdown CT_ID
Исправьте Guest Agent или systemd shutdown внутри гостя.
VM зависает при shutdown
Проверьте:
qm agent VM_ID ping
Проверьте внутри гостя:
systemctl status qemu-guest-agent --no-pager
Безопасный порядок настройки
- Определить критичные сервисы.
- Построить зависимости.
- Назначить order.
- Включить onboot.
- Настроить up и down.
- Проверить ручной shutdown.
- Проверить ручной start.
- Проверить storage.
- Выполнить тестовую перезагрузку.
- Проверить сервисы и журналы.
Быстрый набор команд
Включить VM:
qm set VM_ID --onboot 1
Включить LXC:
pct set CT_ID --onboot 1
Настроить VM:
qm set VM_ID --startup order=20,up=30,down=120
Настроить LXC:
pct set CT_ID --startup order=10,up=20,down=60
Проверить:
qm config VM_ID |
grep -E '^(onboot|startup)'
pct config CT_ID |
grep -E '^(onboot|startup)'
Итог
После выполнения инструкции:
- включён автозапуск VM и LXC;
- настроен порядок запуска;
- добавлены задержки;
- настроены таймауты остановки;
- проверена работа Guest Agent;
- выполнен тест после перезагрузки узла;
- рассмотрены зависимости сервисов.
Правильная startup-схема должна учитывать не только запуск VM и LXC, но и фактическую готовность приложений внутри них.