Эксперты в подборе IT-оборудования
Запускаете десятую виртуальную машину командами на Ubuntu и ловите себя на мысли, что должен быть способ проще. Обычно с этого и начинается знакомство с Proxmox VE - платформой, которая берёт на себя всё то, что в чистом Ubuntu приходится собирать из libvirt, скриптов и собственной памяти.
Разберём, чем Proxmox отличается от Ubuntu с KVM, как перенести туда существующие машины и - подробно - как гонять виртуалки между узлами Proxmox, потому что именно на этом чаще всего спотыкаются.
Вопрос справедливый. Ubuntu с установленным KVM отлично справляется с виртуализацией. Libvirt, virsh, virt-manager - инструментарий мощный и проверенный временем. Так зачем городить огород с Proxmox?
Всё дело в масштабе и удобстве управления. Если у вас две-три виртуалки для тестирования, Ubuntu хватит за глаза. Но когда виртуальных машин становится десять, двадцать, пятьдесят - начинается весёлое. Где запущена вот эта машина? Сколько ресурсов она потребляет? Как быстро создать её клон? А если нужно мигрировать на другой сервер?
Proxmox VE построен на базе Debian, что делает его родственником Ubuntu по духу. Внутри - тот же KVM для полноценных виртуальных машин и LXC для контейнеров. Разница в том, что поверх всего этого накинут продуманный веб-интерфейс и куча автоматизации, которую в обычном Ubuntu пришлось бы собирать самостоятельно.
Proxmox VE бесплатен, и подписка не отключает функции - она даёт доступ к enterprise-репозиторию и техподдержку. Без подписки система обновляется из бесплатного репозитория no-subscription, и при первом входе веб-интерфейс показывает напоминание о её отсутствии.
Актуальная ветка на середину 2026 года - Proxmox VE 9. Версия 9.0 вышла 5 августа 2025 года и переехала на Debian 13 «Trixie»; к лету 2026 ветка дошла до 9.2. Из заметного для практики: снимки на «толстых» LVM поверх общего хранилища (актуально для тех, у кого SAN по iSCSI или Fibre Channel), расширение существующих массивов RAIDZ в ZFS и переработанный мобильный веб-интерфейс.
Давайте посмотрим на реальные сценарии:
| Сценарий | Ubuntu + KVM | Proxmox VE |
|---|---|---|
| 1-5 виртуальных машин для разработки | Отлично подходит | Избыточно |
| 10+ виртуальных машин в продакшене | Управление усложняется | В самый раз |
| Нужна живая миграция без простоя | Сложная настройка | Из коробки |
| Кластер из нескольких серверов | Требует ручной настройки | Встроенная поддержка |
| Резервное копирование и восстановление | Свои скрипты | Proxmox Backup Server |
Первый вопрос, который задают чаще остальных: можно ли поставить Proxmox прямо на работающий Ubuntu, не трогая систему?
Короткий ответ - нет, так делать не стоит. Proxmox VE рассчитан на Debian и официально поддерживается только на нём. Пакеты встают и на Ubuntu, но дальше начинаются расхождения: своё ядро Proxmox конфликтует с ядром Ubuntu, отличается схема сетевых настроек, а часть пакетов тянет зависимости не тех версий. Формально это возможно, практически - вы получите систему, которую никто не поддерживает и которую нечем чинить, когда она сломается.
Рабочих вариантов три:
Отдельно про Ubuntu Desktop: желание превратить рабочую машину в гипервизор понятно, но результат тот же - официальной поддержки нет. Для домашней лаборатории проще отдать под Proxmox отдельный диск и загружаться с него.
Важный момент перед установкой - сетевая конфигурация. Proxmox использует Linux bridge для сетевых подключений виртуальных машин. Если раньше вы работали со стандартными сетевыми интерфейсами Ubuntu, придётся немного перестроиться. Ничего сложного, просто другой подход.
После установки веб-интерфейс доступен по адресу https://ваш-ip:8006. Никаких SSH-сессий для рутинных операций: создать виртуальную машину - пара кликов, посмотреть загрузку ресурсов - графики в реальном времени.
Теперь про технологии виртуализации. Proxmox поддерживает два типа:
KVM (Kernel-based Virtual Machine) - полноценная виртуализация. Каждая машина запускает собственное ядро операционной системы, изолирована от соседей и может нести любую ОС: Windows, Linux, BSD. Производительность близка к железу за счёт аппаратной виртуализации процессора.
LXC (Linux Containers) - контейнеры уровня ядра. Контейнер делит ядро с хостом, поэтому внутри может быть только Linux, зато нет накладных расходов на эмуляцию железа и на второе ядро в памяти. Запускается за секунды, диска и оперативной памяти просит заметно меньше - насколько именно, зависит от нагрузки.
Выбор между ними простой. Нужна Windows, своё ядро или модули ядра - KVM. Разворачиваете обычный линуксовый сервис и хотите плотнее упаковать хост - LXC.
Создание виртуальной машины в Proxmox начинается с загрузки ISO-образа. Заливаете образ Ubuntu Server или любой другой ОС в хранилище через веб-интерфейс или по SSH. Дальше - мастер создания ВМ, где выбираете количество ядер, объём памяти, размер диска.
Особенность Proxmox - гибкость в настройке виртуального железа. Можно эмулировать разные типы процессоров, выбрать контроллер дисков (VirtIO для производительности, SATA или IDE для совместимости со старыми системами), добавить несколько сетевых интерфейсов. Всё это без правки конфигов вручную.
Сразу после установки гостевой системы стоит поставить в неё qemu-guest-agent - небольшую службу, через которую гипервизор общается с гостем. Без неё Proxmox не знает IP-адреса машины, не может корректно её погасить из интерфейса и делает снимки без согласования с файловой системой гостя. В Ubuntu ставится одной командой:
apt install qemu-guest-agent
После установки агента не забудьте включить его в настройках самой ВМ (вкладка Options → QEMU Guest Agent) - без этой галочки служба внутри гостя работает, а гипервизор её не спрашивает.
Шаблоны и клонирование - вещь, которую начинаешь ценить после первого же использования. Установили Ubuntu, настроили как надо, превратили в шаблон. Теперь клон разворачивается за полминуты. Нужно десять одинаковых машин для тестирования - пожалуйста.
Перенос с Ubuntu + KVM на Proxmox проще, чем кажется. Libvirt хранит диски в формате qcow2, который Proxmox понимает напрямую. Копируете файл диска на сервер Proxmox, создаёте машину с нужными параметрами и подключаете диск командой qm importdisk. Чаще всего система заводится с первого раза.
Нюансы возникают с сетью и драйверами. Если на старой системе стоял адаптер e1000, а в Proxmox вы выбрали VirtIO, внутри гостя имя интерфейса поменяется, и статические настройки сети слетят. Ubuntu обычно переживает это нормально, но доступ к консоли лучше держать под рукой - через веб-интерфейс он есть всегда.
Для переезда с VMware ESXi с версии Proxmox VE 8.2 есть штатный мастер импорта. Добавляете в Datacenter → Storage → Add → ESXi адрес хоста ESXi или vCenter с логином и паролем, после чего Proxmox видит содержимое хранилища и забирает машину целиком, конвертируя диски на лету и перенося большую часть настроек. Мастер проверялся с ESXi от 6.5 до 8.0.
Ручной путь через qemu-img никуда не делся и остаётся запасным вариантом, когда доступа к API ESXi нет: конвертируете VMDK в нужный формат и подключаете диск к созданной машине. В обоих случаях внутри гостя останутся VMware Tools - их лучше удалить до переезда, а после включения поставить qemu-guest-agent.
С Windows-гостями есть отдельная тонкость: если системный диск переключить на VirtIO сразу, система не найдёт загрузочный том и упадёт в синий экран. Драйверы VirtIO ставят заранее, ещё на старом гипервизоре, либо подключают диск сначала на SATA, ставят драйверы в работающей системе и только потом переключают.
Это самая частая практическая задача и одновременно та, где больше всего подводных камней. Разберём по сценариям, потому что от конфигурации зависит и способ, и время простоя.
Идеальный случай. Если диски машины лежат на хранилище, которое видят оба узла - Ceph, NFS, iSCSI с LVM, - переносить нужно только оперативную память и состояние процессора. Диск никуда не едет.
qm migrate 100 pve2 --online
Здесь 100 - идентификатор машины, pve2 - имя узла-приёмника, а --online означает живую миграцию, то есть без выключения. Память копируется на второй узел в фоне, пока машина работает; в самом конце происходит короткая пауза на переключение, обычно доли секунды. Сервисы внутри её не замечают.
Без флага --online машина будет погашена, перенесена и запущена на новом узле. Это быстрее и надёжнее, если простой в пару минут допустим.
Общего хранилища нет, диски лежат на локальных SSD каждого узла. Так живёт большинство небольших кластеров, и здесь нужен дополнительный флаг:
qm migrate 100 pve2 --online --with-local-disks --targetstorage local-lvm
Флаг --with-local-disks разрешает переносить вместе с машиной содержимое её дисков, а --targetstorage указывает, в какое хранилище на приёмнике их положить. Если хранилища на узлах называются одинаково, параметр можно опустить.
Такая миграция идёт настолько долго, насколько велики диски и узка сеть: сто гигабайт по гигабитному каналу - это порядка пятнадцати-двадцати минут в идеальных условиях. Машина всё это время работает.
Чтобы копирование дисков не задушило продакшен-трафик, скорость ограничивают:
qm migrate 100 pve2 --online --with-local-disks --bwlimit 100000
Значение задаётся в килобайтах в секунду, то есть 100000 - это примерно 100 МБ/с.
Если узлы соединены не одним линком, трафик миграции правильно увести в отдельную подсеть, чтобы он не конкурировал с трафиком виртуальных машин и с кластерным обменом:
qm migrate 100 pve2 --online --migration_network 10.10.10.0/24
Постоянную настройку удобнее прописать один раз в файле /etc/pve/datacenter.cfg, тогда флаг не понадобится в каждой команде.
Отдельный случай: два независимых сервера Proxmox, объединять их в кластер вы не хотите или не можете. Для этого есть команда qm remote-migrate:
qm remote-migrate 100 100 \
'apitoken=PVEAPIToken=root@pam!migrate=СЕКРЕТ,host=10.0.0.5,fingerprint=AB:CD:...' \
--target-bridge vmbr0 --target-storage local-lvm --online
Первое число - идентификатор машины у вас, второе - какой она получит на приёмнике. Дальше идёт строка подключения: API-токен, созданный на принимающем сервере, его адрес и отпечаток TLS-сертификата (посмотреть можно в Datacenter → Certificates или командой pvenode cert info).
Про эту команду важно знать три вещи, иначе миграция сорвётся на середине:
Параметры --target-bridge и --target-storage лучше указывать всегда: если на приёмнике нет объекта с тем же именем, ошибка вылезет уже в процессе переноса.
Когда remote-migrate спотыкается о разные хранилища или снимки, остаётся способ, которым переносили машины задолго до появления живой миграции: резервная копия, перенос файла, восстановление.
vzdump 100 --storage local --mode snapshot
Копируете получившийся файл на второй сервер и восстанавливаете:
qmrestore /var/lib/vz/dump/vzdump-qemu-100-2026_08_26-10_15_03.vma.zst 100
Способ безразличен к типам хранилищ, переживает разные версии Proxmox и оставляет исходную машину нетронутой, пока вы не убедитесь, что копия завелась. Платой идёт простой на время бэкапа и восстановления. Если у вас настроен Proxmox Backup Server, перенос сводится к восстановлению из общего репозитория на нужный узел.
Общая механика живой миграции и её ограничения разобраны отдельно в материале про технологию Live Migration, а перенос физических серверов в виртуальные - в статье про конвертацию физических серверов в виртуальные.
Proxmox поддерживает много вариантов хранения. Локальные диски, сетевые NAS по NFS или iSCSI, распределённые системы вроде Ceph. Выбор зависит от задачи.
Для домашней лаборатории или небольшого офиса локального хранилища на SSD хватит за глаза. Быстро, просто, надёжно при наличии RAID. Нужна отказоустойчивость на уровне файловой системы - настраиваете ZFS прямо в Proxmox: он даёт сжатие, моментальные снимки и контроль целостности данных. ZFS требователен к оперативной памяти, и это стоит закладывать при расчёте конфигурации.
Ceph - выбор для тех, кто строит кластер из нескольких серверов. Данные реплицируются между узлами, упал один сервер - остальные продолжают работать. Настройка Ceph требует внимания к деталям и минимум трёх узлов, зато закрывает и общее хранилище для миграции, и отказоустойчивость сразу.
| Тип хранилища | Скорость | Отказоустойчивость | Сложность настройки |
|---|---|---|---|
| Локальный диск (ext4) | Высокая | Без RAID - риск | Просто |
| ZFS на локальных дисках | Высокая | Встроенная | Средняя |
| NFS/iSCSI от NAS | Средняя | Зависит от NAS | Средняя |
| Ceph (кластер) | Средняя | Очень высокая | Сложная |
Отдельный вопрос - формат дисков, и здесь распространено вредное упрощение «конвертируйте всё в raw, он быстрее». Разница в скорости между raw и qcow2 по оценке разработчиков QEMU держится в районе пяти процентов, а вот в возможностях разница принципиальная. Правило простое и зависит от того, где лежит диск:
Резервное копирование в Proxmox - отдельная песня. Proxmox Backup Server встраивается в веб-интерфейс, даёт инкрементальные копии и дедупликацию. Настроили расписание - забыли про ручное копирование дисков.
Proxmox изначально задумывался как кластерная платформа. Объединяете несколько серверов - получаете единую точку управления: все узлы видны в одном интерфейсе, машины мигрируют между серверами, хранилище объединяется.
Высокая доступность (HA) в Proxmox работает так: для критичных машин настраивается политика, и при падении узла они автоматически запускаются на другом. Простой измеряется минутами, а не часами ручного вмешательства.
Но кластер требует аккуратности. Нужна надёжная сеть между узлами, желательно выделенная под кластерный обмен, продуманная архитектура хранилища и понимание кворума. Кворум - это правило, по которому кластер решает, кто из узлов имеет право работать: голосов должно быть больше половины. Отсюда практическое следствие - кластер из двух узлов без арбитра нежизнеспособен: при обрыве связи оба узла теряют большинство и блокируются. Лечится добавлением третьего голоса, для которого хватает совсем слабой машины.
Требования к железу под узлы кластера разбирали в материале про системные требования Proxmox.
Proxmox - это Ubuntu?
Нет, и здесь кроется путаница, из-за которой вопрос вообще возникает. Система и репозитории у Proxmox - Debian (ветка 9 стоит на Debian 13 «Trixie»), а вот ядро собирается на основе ядра Ubuntu LTS с собственными патчами. Причин две: ядро Ubuntu свежее, чем в стабильном Debian, и в нём есть поддержка ZFS. Отсюда и ощущение родства с Ubuntu - оно ограничено ядром.
Можно ли поставить Proxmox на Ubuntu Desktop?
Официально нет, и в продакшене так делать не стоит. Для знакомства проще запустить Proxmox в виртуальной машине или выделить под него отдельный диск.
Можно ли запустить одну виртуальную машину сразу на двух серверах?
Нет. В любой момент машина работает на одном узле. HA не запускает вторую копию, а перезапускает машину на другом узле, если первый отказал. Одновременный запуск одного диска двумя гипервизорами приведёт к разрушению файловой системы.
Нужен ли qemu-guest-agent?
Практически всегда. Без него не видно IP-адресов гостя, корректное выключение из интерфейса не работает, а снимки делаются без согласования с файловой системой внутри машины.
Proxmox и Ubuntu - союзники, а не конкуренты. Большинство админов так и делают: ставят Proxmox на железо, а внутри крутят виртуалки с Ubuntu Server под реальные сервисы.
Если сводить всё к практическому итогу, порядок такой. Proxmox ставится на голое железо или на чистый Debian, но не поверх Ubuntu. Гостям сразу ставится qemu-guest-agent. Формат диска выбирается под хранилище, а не по привычке. А прежде чем понадобится переносить машины между узлами, стоит заранее договориться с собой о типе процессора в настройках ВМ и о единой версии Proxmox на всех узлах - это две самые частые причины, по которым миграция срывается в самый неподходящий момент.
Как Proxmox выглядит на фоне других платформ - в сравнении гипервизоров 2026. Управление машинами из командной строки разобрано в статье про запуск и остановку ВМ Proxmox через CLI, а расчёт ресурсов под будущие виртуалки - в материале про планирование CPU, RAM и хранилища.
Подбираете железо под кластер Proxmox?
Инженеры ITTELO помогут собрать узлы с одинаковыми процессорами и запасом под живую миграцию, подскажут по хранилищу и сети между узлами, соберут и протестируют конфигурацию под задачу перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
