Proxmox или голое KVM: что выбрать и когда

MAATRIX

Вы арендовали или подняли сервер под виртуализацию и упёрлись в развилку: ставить Proxmox VE с его веб-интерфейсом и готовыми инструментами, или настраивать KVM напрямую через libvirt — без панели, только virsh и XML-конфиги. Обе схемы работают на одном и том же гипервизоре KVM/QEMU внутри, разница не в «движке», а в слое управления вокруг него. Разберём, что вы реально теряете и приобретаете в каждом варианте, и как выбрать осознанно, а не методом «поставлю то, про что видел статью».

Что вообще сравниваете

Proxmox VE — это дистрибутив на базе Debian с уже собранным стеком: веб-интерфейс на 8006 порту, кластерная файловая система pmxcfs в /etc/pve/, свои обёртки qm (управление VM) и pct (управление LXC-контейнерами) поверх libvirt-подобной логики — на деле Proxmox не использует libvirt вообще, а работает с QEMU напрямую через свои Perl-скрипты и хранит конфиги VM в простых текстовых файлах вида /etc/pve/qemu-server/<vmid>.conf.

Голый KVM — это тот же QEMU/KVM, но управление идёт через libvirt (демон libvirtd + утилита virsh) или вовсе без него, прямыми вызовами qemu-system-x86_64. На практике «голым KVM» почти всегда называют именно связку KVM + libvirt, потому что чистый QEMU без libvirt неудобен даже для одиночного сервера — теряется декларативное описание VM в XML, снапшоты через API, автозапуск при перезагрузке хоста.

Ключевое отличие не в возможностях гипервизора (они идентичны — тот же QEMU под капотом), а в том, сколько инфраструктуры управления вам нужно построить самому и с оглядкой на чью терминологию потом придётся всё объяснять новым людям в команде.

Табличное сравнение верхнего уровня:

Установка и первые шаги

С Proxmox вы получаете рабочую точку входа за 15-20 минут: скачиваете ISO, ставите как обычную ОС, после перезагрузки веб-интерфейс уже доступен на https://<IP>:8006. Создание VM — мастер из пяти шагов: выбрать ISO, диск, память, CPU, сеть. Через минуту у вас VM с VNC-консолью прямо в браузере, без дополнительных пакетов.

С голым KVM на свежем Debian/Ubuntu порядок действий другой:

apt install qemu-kvm libvirt-daemon-system libvirt-clients virtinst bridge-utils
systemctl enable --now libvirtd

Дальше нужно поднять сетевой мост вручную (Proxmox делает это при установке автоматически, создавая vmbr0):

# /etc/network/interfaces
auto br0
iface br0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports enp1s0
    bridge-stp off
    bridge-fd 0

Создание VM — одной командой через virt-install:

virt-install \
  --name vm1 \
  --memory 4096 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/vm1.qcow2,size=40 \
  --cdrom /var/lib/libvirt/images/debian-12.iso \
  --network bridge=br0 \
  --graphics vnc,listen=0.0.0.0 \
  --os-variant debian12

Дальше управление тем же virsh:

virsh list --all
virsh start vm1
virsh shutdown vm1
virsh console vm1

Разница по времени на первую VM — минуты у Proxmox против 30-60 минут у голого KVM, если вы делаете это впервые и разбираетесь с мостами и XML. Если это не первый раз — разница почти стирается, потому что вы уже знаете, что писать.

Снапшоты, бэкапы и мониторинг: из коробки против руками

Здесь расхождение самое ощутимое в ежедневной эксплуатации. В Proxmox снапшот — это кнопка «Snapshot» в интерфейсе или команда:

qm snapshot 101 before-upgrade
qm rollback 101 before-upgrade

Бэкап по расписанию настраивается в разделе Datacenter → Backup: выбираете VM, хранилище, окно времени, режим (snapshot/suspend/stop) — и vzdump дальше делает всё сам, включая ротацию старых копий.

В голом KVM снапшот через libvirt делается так:

virsh snapshot-create-as vm1 before-upgrade --disk-only --atomic

Обратите внимание — без флага --disk-only для дисков в формате qcow2 с внешним снапшотом вам придётся вручную сливать (blockcommit) цепочку слоёв, иначе диск будет расти и тормозить (это тот же механизм copy-on-write, что описан в статье про copy-on-write в qcow2 — грабля одинаковая что в Proxmox, что в libvirt, просто Proxmox прячет часть сложности за интерфейсом).

Бэкап в голом KVM — это ваш собственный скрипт, обычно на основе virsh dumpxml + qemu-img convert или rsync дисков при остановленной VM, плюс cron/systemd timer для расписания. Мониторинг состояния хоста и VM (CPU, память, диск на уровне гипервизора) в Proxmox есть из коробки — графики RRD прямо в интерфейсе за последние часы/дни/недели/годы. В голом KVM это libvirt-метрики через virsh domstats, которые нужно самостоятельно завести в Zabbix/Prometheus (exporter libvirt-exporter или скрипт-обвязка).

Итог по этому пункту прямой: если снапшоты и бэкапы вам нужны часто и разным людям в команде — Proxmox экономит реальные часы каждую неделю. Если бэкапы у вас уже настроены отдельным инструментом (Borg, Restic) поверх файловой системы хоста, а не средствами гипервизора — разница менее критична.

Кластеризация и высокая доступность

Proxmox из коробки умеет объединять несколько узлов в кластер (pvecm create, pvecm add) с общим хранилищем конфигурации через pmxcfs, живой миграцией VM между узлами (qm migrate) и HA-группами, которые сами перезапускают VM на другом узле при падении хоста.

В голом KVM живая миграция тоже есть на уровне libvirt и работает штатно:

virsh migrate --live vm1 qemu+ssh://host2/system

Но всё, что вокруг — распределённое хранилище конфигов, автоматический failover, кворум узлов — нужно собирать самому: Pacemaker+Corosync для кворума, Ceph или NFS для общего хранилища дисков, свои скрипты для решения «этот узел упал, где теперь поднимать VM». Это не невозможно, это ровно тот объём работы, который Proxmox уже сделал за вас и оттестировал на тысячах инсталляций.

Если вам нужен один сервер без задач кластеризации — этот пункт вообще не имеет значения для выбора. Если в перспективе планируется несколько узлов с автоматическим переключением — Proxmox экономит недели инженерной работы на старте.

Гибкость, автоматизация и интеграция в существующий IaC

Здесь чаша весов может качнуться в обратную сторону. Если в вашей компании уже есть зрелый пайплайн на Ansible/Terraform, написанный под чистый libvirt — модуль community.libvirt в Ansible, провайдер dmacvicar/libvirt в Terraform — то Proxmox добавляет вам не удобство, а необходимость переписывать эти роли под Proxmox API (pvesh, REST на 8006 порту, отдельный Terraform-провайдер bpg/proxmox или Telmate/proxmox) и держать в голове две параллельные модели конфигурации.

Пример Terraform-ресурса под голый libvirt:

resource "libvirt_domain" "vm1" {
  name   = "vm1"
  memory = 4096
  vcpu   = 2
  disk {
    volume_id = libvirt_volume.vm1_disk.id
  }
  network_interface {
    bridge = "br0"
  }
}

Тот же ресурс под Proxmox выглядит принципиально иначе — со своими полями clone, agent, disk { datastore_id } и привязкой к конкретному узлу кластера по имени. Если ваша автоматизация уже написана и работает под libvirt на других площадках, перенос под Proxmox — это не правка пары строк, а фактически новый набор ролей.

Также голый KVM даёт более тонкий контроль над XML-описанием VM — например, специфичные флаги QEMU для передачи PCI-устройств (GPU passthrough), CPU pinning под NUMA-топологию, кастомные модели дисков. В Proxmox всё это тоже доступно, но часть настроек либо скрыта за интерфейсом, либо требует правки конфига руками в обход GUI (qm set 101 --args), что уже полшага в сторону той же сложности, только вперемешку со специфичным для Proxmox форматом.

Терминология и слой абстракции: что вы теряете при переходе на Proxmox

Специфика Proxmox — это не только удобство, но и словарь, который вам придётся выучить и который нигде за пределами Proxmox не пригодится: vmid, storage.cfg, pmxcfs, различие между qm и pct, свой формат бэкапа .vma.zst. Если завтра вы захотите мигрировать на голый KVM или другой гипервизор — этот словарь и формат конфигов не переносятся напрямую, нужна конвертация.

С другой стороны, у голого libvirt XML — открытый, документированный формат, который понимают virt-manager, oVirt, часть облачных платформ и который проще прочитать человеку, не работавшему конкретно с Proxmox. Если для вас важна переносимость знаний команды между разными инфраструктурами — это аргумент в пользу голого KVM.

Честно предупредим: переход от Proxmox к голому KVM (или обратно) — это не смена одной настройки, а реальный перенос VM с конвертацией конфигов и проверкой дисков. Из Proxmox диски обычно лежат в формате qcow2/raw и переносятся физически без проблем, а вот описание VM (сеть, CPU, диски) нужно пересобирать в libvirt XML заново — автоматической конвертации qm.conf → libvirt XML в общем случае нет. Подробный разбор процесса и типичных граблей с драйверами и сетью — в статье про миграцию между гипервизорами, а если переезжаете именно с Proxmox на новое железо без смены платформы управления — в статье про переезд с Proxmox на другое железо. Поэтому выбор между Proxmox и голым KVM стоит делать один раз и осознанно на старте, а не как временное решение «пока разберёмся».

Критерии выбора: кому что подходит

Сведём в практические критерии, а не абстрактные плюсы-минусы.

Proxmox — явно лучший выбор, если:

• В команде нет глубокой экспертизы именно в libvirt/QEMU, и нужна рабочая платформа быстро, а не после недели чтения документации.
• Бэкапы, снапшоты и мониторинг нужны часто и разным людям — не только тому, кто настраивал сервер изначально.
• В перспективе (не обязательно сразу) планируется несколько узлов с живой миграцией и HA.
• Важна визуальная консоль для сотрудников без опыта работы через SSH/virsh.
• Вопрос выбора между гипервизорами вообще не единственный — вы также сравниваете, например, KVM с LXC-контейнерами по изоляции и плотности, тогда стоит заодно посмотреть на статью KVM или LXC: что выбрать для сервера, потому что Proxmox одинаково удобно управляет обоими типами виртуализации из одного интерфейса.

Голый KVM — оправдан, если:

• У вас уже есть зрелая автоматизация (Ansible/Terraform) под чистый libvirt, и переписывать её под Proxmox API — чистые лишние трудозатраты без выигрыша.
• Нужна максимальная прозрачность конфигурации — видеть ровно тот XML, который QEMU реально исполняет, без дополнительного слоя перевода.
• Сервер один, без задач кластеризации, а снапшоты/бэкапы уже закрыты другим инструментом на уровне ОС.
• Требуется тонкая настройка, которую Proxmox либо не даёт через GUI, либо даёт с оговорками (сложный PCI passthrough, специфичные модели устройств).

Если сомневаетесь — начните с Proxmox: он не мешает при необходимости зайти в тот же конфиг руками через SSH и qm set --args, а обратный путь (с голого KVM на Proxmox) требует переноса VM в любом случае, так что нет смысла откладывать удобство на потом, если оно вам скорее всего понадобится.

Частые вопросы