Обзор гипервизора Proxmox

Что такое Proxmox VE

Proxmox Virtual Environment, или Proxmox VE, — это открытая платформа виртуализации на базе Debian. Она объединяет гипервизор KVM для полноценных виртуальных машин и LXC для системных Linux-контейнеров, а также добавляет веб-интерфейс, кластерное управление, сеть, хранилища, высокую доступность и резервное копирование.

Вопреки расхожему мнению, хоть он и ставится поверх Debian, Proxmox VE нельзя называть гипервизором второго типа. Гипервизоры Type 2, например VirtualBox или VMware Workstation, работают как обычные приложения поверх настольной операционной системы. В Proxmox аппаратная виртуализация реализована модулем KVM непосредственно в ядре Linux, хоть операционная система и является системой общего назначения. Такие гипервизоры иногда называют гибридными. Сама платформа обычно устанавливается на физический сервер с помощью bare-metal ISO или набора пакетов на Debian.

Если вам нужен именно подбор процессора, оперативной памяти, накопителей, RAID-контроллера или HBA и сетевых адаптеров, переходите в отдельный материал — «Как выбрать сервер для Proxmox». Здесь разберём саму платформу: как она устроена, что умеет и где у неё есть ограничения.

И да, это статья из цикла. В блоге Сервер Молл также есть:

• обзор VMware ESXi;

• обзор Microsoft Hyper-V;

• обзор KVM.

Так что заваривайте что-нибудь вкусное — начинаем :)

Используйте эту часть статьи как шпаргалку — можно добавить страницу в закладки с помощью Ctrl + D :)

• Installing Proxmox VE — установка платформы с официального ISO-образа или поверх поддерживаемой версии Debian, требования к загрузке, файловой системе и сетевой конфигурации.

• Proxmox VE Administration Guide — основное руководство по работе с платформой. Здесь описаны виртуальные машины QEMU/KVM и контейнеры LXC, управление хостом, сетями и хранилищами, создание кластеров, настройка HA, Ceph, SDN, резервного копирования, брандмауэра, пользователей, прав доступа и уведомлений.

• Package Repositories — настройка enterprise-, no-subscription- и test-репозиториев. Для производственной системы Proxmox рекомендует enterprise-репозиторий с действующей подпиской. No-subscription доступен бесплатно, но его обновления проходят меньший цикл проверки.

• Upgrade from 8 to 9 — официальная инструкция по переходу с Proxmox VE 8 на Proxmox VE 9. Перед обновлением необходимо установить последние пакеты текущей ветки, проверить узел утилитой pve8to9, изучить известные ограничения и создать проверенные резервные копии ВМ, контейнеров и конфигурации.

• Proxmox VE API Documentation — интерактивное описание REST API для автоматизации управления узлами, виртуальными машинами, контейнерами, хранилищами, пользователями и кластерными ресурсами.

Документация обновляется вместе с платформой, поэтому перед выполнением команд проверяйте, что открытая инструкция соответствует установленной основной версии Proxmox VE. Для ветки 9.2.x следует использовать актуальную документацию Proxmox VE 9, а не сохранённые руководства для версий 7 или 8.

Возможности и преимущества Proxmox

Во-первых, Proxmox не идеален — кто-то сомневался? :)

Во-вторых, это не просто бесплатная веб-панель над QEMU. Proxmox VE объединяет в одном интерфейсе большинство функций, которые необходимы для небольшой виртуальной среды или полноценного кластера:

• создание и клонирование ВМ и контейнеров;

• шаблоны и Cloud-Init;

• снапшоты на совместимых хранилищах;

• живая миграция виртуальных машин;

• кластерное управление;

• автоматический перезапуск гостевых систем через HA;

• локальные и сетевые хранилища;

• управление ZFS и Ceph;

• Linux Bridge, bonding, VLAN и SDN;

• роли пользователей и разграничение доступа;

• встроенный брандмауэр;

• резервное копирование по расписанию;

• интеграция с Proxmox Backup Server;

• API и средства автоматизации.

У открытой платформы есть приятная сторона: вы контролируете ОС и можете интегрировать собственный мониторинг, сетевые службы и инструменты автоматизации. Но у этой свободы есть и обратная сторона. PVE можно поставить почти на любой «калькулятор», а затем долго выяснять, почему хранилище тормозит, сеть теряет пакеты, а драйвер сетевой карты ломается после обновления ядра.

Поэтому фраза «если Debian установился, значит сервер подходит для Proxmox» верна только для первого запуска. Для рабочей системы важны не только совместимые драйверы, но и предсказуемая работа контроллеров, накопителей, сетевых адаптеров, прошивок и средств удалённого управления.

Системные требования Proxmox VE

Здесь нужно отделить официальный минимум для установки от практической конфигурации для рабочей нагрузки. Универсального требования вроде «Proxmox нужно 32 ГБ памяти» не существует: платформа, гостевые системы, ZFS и Ceph потребляют ресурсы по-разному.

Официальный минимум

Для установки и тестового запуска необходимы:

• 64-битный процессор Intel или AMD;

• Intel VT-x или AMD-V для полноценных KVM-машин;

• не менее 2 ГБ оперативной памяти для ОС и служб Proxmox VE;

• дополнительная память для всех ВМ и контейнеров;

• накопитель для установки системы;

• совместимый сетевой адаптер.

Для PCIe Passthrough дополнительно требуются Intel VT-d или AMD-Vi и корректная поддержка IOMMU со стороны процессора, системной платы и прошивки.

В официальных требованиях к установке Proxmox VE также приводится ориентир около 1 ГБ дополнительной памяти на каждый терабайт используемого хранилища при работе с ZFS или Ceph. Это не универсальная формула расчёта сервера. Фактическое потребление зависит от размера ARC, числа дисков и OSD, объёма метаданных, характера операций и настроек системы.

Практическая конфигурация

В рабочей среде ресурсы нужно считать отдельно:

1. Память хоста. Она необходима Debian, службам Proxmox, файловому кэшу, мониторингу и операциям резервного копирования.

2. Память гостевых систем. Складывается из реального потребления всех одновременно работающих ВМ и контейнеров. Нельзя просто умножить объём выделенной памяти на количество ВМ, если используется ballooning, но и рассчитывать на постоянное переподписывание памяти опасно.

3. Ресурсы хранилища. ZFS использует память под ARC, а Ceph — для OSD, MON, MGR и других служб. Эти потребители рассчитываются отдельно.

4. Резерв на отказ. Для HA-кластера нужно учитывать не только обычную загрузку, но и ситуацию, когда один узел недоступен, а его гостевые системы должны запуститься на оставшихся серверах.

5. Пиковую нагрузку. Средняя загрузка процессора или дисков мало говорит о поведении во время закрытия месяца в 1С, резервного копирования, антивирусной проверки или массового входа пользователей.

Оперативную память лучше выбирать с ECC, хоть это и не является требованием для работы ZFS, но более стабильная работа за счёт коррекции ошибок является приоритетной. Для загрузочных дисков и критичных хранилищ — использовать отказоустойчивую конфигурацию. Для интенсивной записи предпочтительны серверные SSD с защитой от потери питания.

Отдельно проверьте сетевые адаптеры и HBA. Отсутствие строгого HCL у Proxmox не означает, что любые потребительские контроллеры одинаково хорошо переживут несколько лет обновлений ядра.

Хранилища: локальные диски, ZFS, Ceph, NFS и iSCSI

Proxmox VE поддерживает локальные и сетевые хранилища. Правильный вариант зависит не от количества красивых пунктов в веб-интерфейсе, а от требований к производительности, доступности и восстановлению.

Локальные LVM и LVM-thin

Это относительно простой вариант для одного узла. LVM-thin поддерживает тонкое выделение пространства и снапшоты. Локальные диски дают предсказуемую задержку и не зависят от сети, но данные остаются привязаны к конкретному серверу.

Перенос ВМ между узлами возможен с миграцией локальных дисков, однако он создаёт дополнительную нагрузку на сеть и занимает больше времени, чем миграция при общем хранилище.

ZFS

ZFS объединяет программный RAID, контроль целостности, снапшоты, сжатие и управление пулами. Это удобный вариант для локального хранилища, особенно если администратору нужен прямой контроль над дисками.

Есть несколько важных ограничений:

• ZFS не следует размещать поверх аппаратного RAID с собственным кэшем;

• система должна видеть физические диски напрямую;

• как следствие, желательно использовать HBA в IT Mode;

• рекомендуется ECC-память;

• для SLOG и специальных устройств нужны накопители серверного класса с защитой от потери питания;

• снапшот не заменяет резервную копию;

• заполненный пул и неудачная схема vdev могут резко ухудшить производительность.

Репликация ZFS между узлами помогает хранить копии виртуальных дисков, но она асинхронная. Это не то же самое, что общее синхронное хранилище: при аварии можно потерять изменения, появившиеся после последней успешной репликации.

Ceph

Ceph создаёт распределённое хранилище из дисков нескольких серверов и хорошо интегрирован с Proxmox VE. Такой вариант подходит для гиперконвергентного кластера, где вычисления и хранение распределены между одними и теми же узлами.

Но Ceph очень чувствителен к архитектуре:

• требуется минимум три узла, предпочтительно близких по конфигурации;

• важны задержка и стабильность сети, а не только заявленная пропускная способность;

• для Ceph-трафика рекомендуется отдельная сеть от 10 Гбит/с;

• небольшое число OSD ограничивает параллелизм и усложняет восстановление;

• медленный или неисправный накопитель может влиять на весь кластер;

• сама работа с Ceph, особенно восстановление при полном или частичном сбое требует наличия необходимых компетенций у команды сопровождения;

• восстановление после отказа создаёт дополнительную нагрузку на сеть и диски.

Для пары небольших серверов Ceph чаще добавляет сложность, чем надёжность. Здесь тот самый случай, когда кнопка «Install Ceph» в веб-интерфейсе не заменяет проектирование.

NFS и iSCSI

NFS и iSCSI позволяют подключить внешнюю СХД или файловый сервер как общее хранилище. Это упрощает миграцию ВМ между узлами, поскольку виртуальные диски уже доступны всем серверам кластера.

При этом отказоустойчивость зависит от самой СХД, контроллеров, коммутаторов и сетевых путей. Один NAS с одним сетевым интерфейсом не становится высокодоступным только потому, что к нему подключён кластер Proxmox.

Сеть в Proxmox VE

Для базовой конфигурации Proxmox использует стандартный сетевой стек Linux. Веб-интерфейс позволяет создавать:

• Linux Bridge;

• VLAN-интерфейсы;

• bonding;

• маршрутизируемые сети;

• программно определяемые сети;

• зоны и виртуальные сети SDN;

• правила встроенного брандмауэра.

На тестовом сервере все виды трафика могут проходить через один интерфейс. В рабочем кластере лучше развести хотя бы логически, а при высокой нагрузке и физически:

• управление узлами;

• трафик виртуальных машин;

• Corosync;

• live migration;

• резервное копирование;

• Ceph или доступ к внешней СХД.

Особенно чувствителен Corosync: ему важны низкая задержка и отсутствие потерь. Забитый резервным копированием сетевой интерфейс может создать проблемы с членством узлов в кластере и quorum.

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

Несколько узлов Proxmox VE можно объединить в кластер и управлять ими из одного веб-интерфейса. Конфигурация синхронизируется между серверами, а ВМ и контейнеры можно переносить с одного узла на другой.

Но сам факт создания кластера ещё не делает инфраструктуру отказоустойчивой.

Quorum

Кластер использует Corosync и принимает решения большинством голосов. Для надёжного quorum Proxmox рекомендует не менее трёх узлов.

Двухузловая конфигурация возможна, например с внешним QDevice, но она требует особенно аккуратного проектирования. Просто отключать проверку quorum, чтобы «кластер снова заработал», опасно: при разделении сети оба узла могут начать считать себя основными, так называемый Split Brain, выход из которого тоже необходимо проводить крайне аккуратно, во избежание коллизий и потери данных.

HA

HA Manager контролирует выбранные ВМ и контейнеры. Если узел действительно вышел из строя и кластер сохранил quorum, гостевые системы могут быть запущены на другом сервере.

Здесь есть важное различие:

• live migration переносит работающую ВМ при плановом обслуживании с минимальным перерывом;

• HA после отказа обычно означает обнаружение проблемы, изоляцию неисправного узла и перезапуск ВМ на другом сервере.

То есть HA уменьшает простой, но не гарантирует его полное отсутствие.

Live migration

Живая миграция KVM-машин требует совместимых процессоров, достаточной пропускной способности сети и доступности дисков на целевом узле.

Официально online migration поддерживается между узлами с процессорами одного производителя. Даже внутри Intel или AMD набор инструкций может различаться между поколениями. Если виртуальной машине передан CPU типа host, она может использовать все возможности конкретного процессора, но переезд на более старый или несовместимый узел станет проблемой.

Для неоднородного кластера выбирают наиболее свежую (чтобы поддерживался максимум инструкций) общую модель виртуального CPU, которую поддерживают все целевые узлы. В Proxmox VE 9.2 пользовательскими CPU-моделями можно управлять через интерфейс, но совместимость всё равно нужно проверять под реальной нагрузкой.

Работающие LXC-контейнеры не поддерживают полноценную live migration. При переносе используется остановка, миграция и повторный запуск контейнера.

Резервное копирование и Proxmox Backup Server

В Proxmox VE есть встроенный инструмент vzdump, который создаёт резервные копии виртуальных машин и контейнеров по расписанию. Копии можно хранить на локальном диске, NFS, CIFS или другом поддерживаемом хранилище.

Для более развитой системы резервного копирования используется отдельный Proxmox Backup Server, или PBS. Он интегрируется с PVE и поддерживает:

• инкрементную передачу данных;

• дедупликацию;

• сжатие;

• проверку целостности;

• шифрование на стороне клиента;

• политики хранения;

• восстановление отдельных файлов;

• синхронизацию хранилищ резервных копий.

PBS желательно размещать вне основного кластера. Если резервные копии лежат на тех же дисках, контроллерах и узлах, что и рабочие ВМ, авария может уничтожить и оригинал, и возможность восстановления.

И да: снапшот — не резервная копия. Он зависит от исходного хранилища и предназначен прежде всего для кратковременного отката. Полноценная резервная копия должна пережить потерю узла или хранилища, а её восстановление нужно периодически проверять.

Лицензирование, репозитории и поддержка

Исходный код Proxmox VE распространяется по лицензии GNU AGPLv3. Платформу можно скачать, установить и использовать без покупки лицензии, причём функциональность веб-интерфейса, KVM, LXC, кластера, HA и резервного копирования искусственно не ограничивается.

Но называть Proxmox VE «абсолютно бесплатным» всё же неправильно. Есть опция коммерческой подписки, которая предоставляет:

• доступ к enterprise-репозиторию;

• обновления, прошедшие дополнительное тестирование;

• официальную техническую поддержку в зависимости от уровня подписки;

• доступ к системе обращений Proxmox.

Есть два основных варианта репозиториев.

Enterprise repository предназначен для производственных систем, требует действующей подписки и содержит более тщательно протестированные пакеты.

No-subscription repository доступен бесплатно и не требует ключа подписки. Обновления попадают туда раньше и проходят меньший цикл проверки, поэтому сам Proxmox не рекомендует этот репозиторий для критичных производственных систем.

Это не означает, что no-subscription непременно нестабилен. Но организация, использующая его в рабочей среде, сама принимает риски, должна тестировать обновления на отдельном узле или стенде и заранее готовить план отката.

Преимущества и ограничения Proxmox VE

К сильным сторонам платформы относятся:

• открытый исходный код и отсутствие функционально урезанной community-редакции;

• KVM и LXC в одном интерфейсе;

• встроенное управление кластером и HA;

• поддержка локальных и сетевых хранилищ;

• интеграция с ZFS, Ceph и Proxmox Backup Server;

• веб-интерфейс без отдельного сервера управления;

• API и удобная автоматизация;

• возможность начать с одного узла и постепенно расширить инфраструктуру;

• меньше зависимость от проприетарного стека одного поставщика.

Но есть и ограничения:

• нет универсального HCL уровня крупных проприетарных платформ;

• совместимость конкретных RAID-контроллеров, HBA, сетевых карт и прошивок нужно проверять самостоятельно;

• поддержка стороннего оборудования зависит от его производителя и драйверов Linux;

• Ceph требует достаточного числа узлов, быстрых накопителей и правильно спроектированной сети;

• ZFS нельзя бездумно устанавливать поверх аппаратного RAID;

• живая миграция зависит от совместимости процессоров;

• LXC-контейнеры не поддерживают live migration;

• переход между крупными версиями требует подготовки и проверки совместимости;

• обновления ядра, QEMU, Ceph и ZFS сначала следует тестировать;

• отсутствие подписки означает отсутствие официального канала поддержки Proxmox.

Proxmox подходит для лабораторий, офисной виртуализации, хостинга, инфраструктурных служб, удалённых площадок, частных облаков и гиперконвергентных кластеров. Но чем выше требования к доступности, тем меньше проект должен опираться на настройки «по умолчанию».

Proxmox, VMware, Hyper-V или XCP-ng

Сравнивать платформы только по цене лицензии неправильно. Нужно учитывать управление, экосистему, поддержку, требования к оборудованию, миграцию, резервное копирование и компетенции команды.

Что изменилось у бесплатного ESXi

Бесплатный VMware ESXi нельзя описывать как полноценную бесплатную замену коммерческому vSphere и тем более сравнивать с полнофункциональном Proxmox. Компания Broadcom (а теперь VMware принадлежит им) убирало бесплатный ESXi на несколько лет. На текущий, 2026 год,  для актуальной ESXi 8.0 Update 3e доступна бесплатная лицензия, но она рассчитана прежде всего на домашние лаборатории и тестовые среды.

В ней отсутствуют:

• управление через vCenter;

• vMotion;

• DRS;

• vSphere HA;

• VADP-бэкапы;

• полноценный управляющий API;

• официальная поддержка Broadcom.

Кроме того, бесплатная лицензия ограничивает виртуальную машину восемью vCPU и поддерживает до двух физических процессоров на хост. Эти условия зафиксированы в официальной базе знаний Broadcom.

Поэтому сравнение «Proxmox бесплатный, ESXi тоже есть бесплатный» без перечисления ограничений вводит читателя в заблуждение.

Что произошло с Hyper-V Server

Hyper-V как технология не исчез: роль Hyper-V продолжает развиваться в актуальных версиях Windows Server, включая Windows Server 2025.

Завершилась именно отдельная бесплатная продуктовая ветка Microsoft Hyper-V Server. Последней её версией стала Hyper-V Server 2019. Основная поддержка этой редакции закончилась 9 января 2024 года, расширенная продолжается до 9 января 2029 года — это указано в Microsoft Lifecycle.

Для новых внедрений обычно рассматривают роль Hyper-V в лицензируемом Windows Server, Azure Local или другой актуальный сценарий Microsoft. Поэтому называть Hyper-V Server безусловно бесплатной современной альтернативой Proxmox уже нельзя.

Какой сервер нужен для Proxmox

Сервер HPE DL385 Gen11 8SFF

• Добавить в сравнение
• Добавить в избранное

Новый

Размер:

2U

CPU:

2 x 4th Generation AMD EPYC 9004

RAM:

DDR5 DIMM 24 слотов (6144 GB)

HDD:

до 8 HDD 2.5'' SFF

5 лет гарантии

Бесплатная доставка

Цена базы:

от 202 440 ₽

7 035 ₽/мес в лизинг

от 165 934 ₽

+ 36 506 НДС

• Добавить в сравнение
• Добавить в избранное

КП за час Сконфигурировать

% выгодное предложение % выгодно

Сервер DELL R750 8SFF

• Добавить в сравнение
• Добавить в избранное

Новый

Размер:

2U

CPU:

2 x 3rd Generation Intel Xeon Scalable

RAM:

DDR4 DIMM 32 слотов (8192 GB)

HDD:

до 8 HDD 2.5'' SFF

5 лет гарантии

Бесплатная доставка

Цена базы:

от 207 000 ₽

7 193 ₽/мес в лизинг

от 169 672 ₽

+ 37 328 НДС

• Добавить в сравнение
• Добавить в избранное

КП за час Сконфигурировать

Если коротко, сервер должен соответствовать не столько требованиям самой платформы, сколько профилю размещённых на ней ВМ и контейнеров.

При выборе учитывают:

• количество и типы гостевых систем;

• реальное потребление CPU и памяти;

• требования к частоте ядра и числу физических ядер;

• общий объём RAM и резерв на отказ узла;

• IOPS, задержку и объём хранилища;

• выбранную схему: аппаратный RAID, ZFS, Ceph или внешняя СХД;

• скорость сетей ВМ, миграции, резервного копирования и хранилища;

• необходимость PCIe Passthrough, GPU или высокоскоростных сетевых адаптеров;

• возможность расширения через год или два;

• N+1-резерв для HA-кластера.

Для одного тестового узла подойдёт почти любой современный x86-64 сервер. Для рабочей системы важны ECC-память, отказоустойчивые загрузочные диски, серверные накопители, резервные блоки питания и удалённое управление.

Для ZFS нужен прямой доступ к накопителям через HBA. Для Ceph — минимум три подходящих узла и быстрая отдельная сеть. Для общей СХД — резервные сетевые пути и отказоустойчивость самой системы хранения.

Подробный расчёт CPU, RAM, дисков, RAID/HBA и сети вынесен в отдельную статью — «Сервер для Proxmox: советы и рекомендации по выбору». Такое разделение важно: текущая страница отвечает на запрос «что такое Proxmox VE», а связанный материал — на запрос «какое железо выбрать».

Подытожим

Proxmox VE — не гипервизор второго типа и не просто оболочка над QEMU. Это открытая полноценная платформа виртуализации на базе Debian, в которой KVM отвечает за аппаратную виртуализацию, QEMU — за виртуальное оборудование и процесс ВМ, а LXC — за системные Linux-контейнеры.

Актуальная ветка Proxmox VE 9.2.x объединяет кластерное управление, HA, динамическую балансировку, SDN, ZFS, Ceph, встроенные резервные копии и интеграцию с Proxmox Backup Server.

Платформу можно использовать без подписки, при необходимости  enterprise-репозиторий и официальная поддержка оплачиваются отдельно. Для лаборатории достаточно одного узла и no-subscription repository. Для критичной производственной среды нужны протестированные обновления, резервное копирование, совместимое оборудование и заранее спроектированная отказоустойчивость.

И главное: Proxmox действительно нетребователен к самому факту запуска. Но хорошая виртуальная инфраструктура начинается не с кнопки установки, а с расчёта нагрузки, хранилища, сети и сценария отказа.