Почему Proxmox для этого проекта? Гипервизор — это основа, которая делает платформу масштабируемой и гибкой: каждая роль (узел ИИ, общие сервисы, стенд POC) добавляется, изолируется или развивается, не затрагивая остальные. Он даёт реальную экономию времени — при повреждении сервер полностью переклонируется за несколько минут из шаблона или снимка, вместо полной переустановки. И он расширяет возможности: сосуществование Linux и Windows на одной машине, включая один или несколько клиентов Windows для потребления сервисов ИИ, с выделением GPU по запросу.
📦 Версия и возможности
ЭлементЗначение
Proxmox VE9.2.2
Ядро PVE6.17
ВиртуализацияKVM + QEMU
UEFI ВМOVMF
Legacy BIOSSeaBIOS
Паравиртуальные драйверыVirtIO
📋 Доступные шаблоны
ИмяОСРольСтатус
WIN11-CUDAWindows 11 ProDesktop + GPU passthrough🟢 В работе
Ubuntu Desktop-CUDAUbuntu Desktop 24.04GPU passthrough / CUDA / Docker🟢 В работе
WIN11-baseW11-debloat-sysprepРабочая станция для dev/test ИИ🟢 В работе
Ubuntu Server-CUDAUbuntu Server 24.04Серверы AI-CORE + GPU passthrough + CUDA / Docker🟢 В работе
Ubuntu ServerUbuntu Server 24.04Функциональные серверы без потребности в GPU🟢 В работе
🔄 Статус и порядок запуска ВМ

Эта команда выводит напрямую из Proxmox список ВМ с их текущим состоянием, политикой автозапуска (onboot) и порядком восстановления (startup) — не путая мгновенное состояние (running / stopped) с постоянной конфигурацией.

bash — статус + порядок запуска
for vmid in $(qm list | awk 'NR > 1 {print $1}'); do
    config=$(qm config "$vmid")

    name=$(awk -F': ' '/^name:/ {print $2}' <<< "$config")
    status=$(qm status "$vmid" | awk '{print $2}')
    onboot=$(awk -F': ' '/^onboot:/ {print $2}' <<< "$config")
    startup=$(awk -F': ' '/^startup:/ {print $2}' <<< "$config")

    [ -z "$onboot" ] && onboot=0
    [ -z "$startup" ] && startup="-"

    printf '%-6s %-30s status=%-8s onboot=%-2s startup=%s\n' \
        "$vmid" "$name" "$status" "$onboot" "$startup"
done
очищенный фрагмент — порядок восстановления: VM215 (10) → VM210 (20) → VM300 n8n (30) → VM205 (40)
205    205-Ubuntu-Nextcloud           onboot=1  startup=order=40,up=30,down=60
210    210-IA-CORE-CUDA               onboot=1  startup=order=20,up=30,down=60
215    215-IA-Services                onboot=1  startup=order=10,up=60,down=60
260    260-W11-CUDA-Ollama            onboot=0  startup=-
300    300-n8n                        onboot=1  startup=order=30,up=30,down=60
…      environnements à la demande    onboot=0  startup=-
Как читать: ВМ с onboot=1 восстанавливаются в порядке возрастания startup — VM215 (сервисы · PostgreSQL/pgvector) → VM210 (узел ИИ) → VM300 (n8n) → VM205 (Nextcloud) — чтобы зависимости были готовы раньше своих потребителей. Альтернативные GPU-окружения остаются вне автозапуска. Полная инвентаризация хранится во внутренней эксплуатационной документации.
🎯 Применённые компетенции
  • Администрирование Proxmox VE (веб-интерфейс + CLI)
  • Создание, настройка и управление ВМ KVM/QEMU
  • Управление хранилищем ZFS через Proxmox
  • Создание переиспользуемых системных шаблонов
  • Снимки Proxmox (vzdump) — пока не независимое резервное копирование
  • Клонирование ВМ для быстрого развёртывания
  • Диагностика гипервизора (логи, консоль VNC)
🧪 Опыт — пересборка шаблона (VM130)

Клонирование старого шаблона выявило остаточное имя хоста. Клон был исправлен и проверен, после чего универсальный шаблон был пересобран из официального ISO, чтобы явно контролировать его содержимое. ВМ сборки была очищена перед конвертацией: идентичность машины, имя хоста, SSH-ключи, сеть, состояние Cloud-Init и журналы были очищены.

Полный проверочный клон подтвердил инициализацию Cloud-Init, генерацию собственной идентичности, сеть, DNS, SSH, гостевой агент и сохранность после перезагрузки. Старый шаблон был заменён только после этой проверки; происхождение ZFS было проверено перед удалением ставшего избыточным кандидата — чтобы сохранить независимость ВМ.

♻️ Жизненный цикл и типы шаблонов

Ценность шаблона не в скорости клонирования, а в контроле над тем, что он передаёт (система, идентичность, сеть, доступ, инициализация). Сборка, проверка и замена — три отдельные операции: старый шаблон остаётся доступным, пока его замена и проверочный клон не удовлетворят всем критериям.

жизненный цикл шаблона
Source système vérifiée
        │
        ▼
VM temporaire de construction
        │ installation et configuration du socle
        ▼
Neutralisation
        │ identités, réseau, secrets et journaux
        ▼
Template temporaire
        │
        ▼
Clone de validation
        │ contrôles fonctionnels et d'indépendance
        ▼
Template validé
        │
        ├── clone complet → VM applicative
        └── template dérivé → socle spécialisé
Тип основыОжидаемое содержимоеИсключённые элементы
Универсальный серверминимальная система, Cloud-Init, SSH, гостевой агентприложение, секрет, бизнес-конфигурация
Специализированный серверуниверсальная основа + обоснованные общие зависимостиданные, специфичные для одной ВМ
CUDA / GPUпроверенные драйверы и инструменты GPUприложения, не связанные с GPU
Windowsподготовленная система, драйверы VirtIO, механизм обобщенияидентичность и учётная запись исходной ВМ
Специализированный шаблон не должен делать универсальный шаблон зависимым от своих компонентов; приложения обычно устанавливаются уже в клонах.
🐛 Опыт — диагностика PCIe

Встроенное устройство PCIe периодически исчезало. Диагностика позволила отличить реальное отсутствие на шине от простой ошибки драйвера, последовательно проверив интерфейс, модули, перечисление PCIe, родительский порт и повторное сканирование. Полное обесточивание восстановило устройство; повторение отслеживается перед возможным условным обновлением прошивки.

Связанные страницы

Ссылки и источники

КатегорияРесурсURL
Официальная документацияProxmox VE Administration Guidepve.proxmox.com/pve-docs
Репозиторий GitHubproxmox/pve-managergithub.com/proxmox/pve-manager
Используемая версияProxmox VE 9.2.2 — KVM/QEMU · OVMF · VirtIO—
ЛицензияAGPLv3 (Community Edition)gnu.org/licenses/agpl-3.0
Содержимое этой страницыПубликуется под CC BY-SA 4.0creativecommons.org/licenses/by-sa/4.0