Можно ли запустить Proxmox на VPS

Краткий ответ

Вложенная виртуализация — это работа гипервизора внутри виртуальной машины. Ваш VPS уже является гостевой системой, а вы хотите запускать внутри него другие гостевые системы. Это работает только в том случае, если гипервизор вашего провайдера намеренно передает расширения виртуализации CPU вашей инстанции. Проверьте наличие флага vmx (Intel) или svm (AMD) с помощью команды /proc/cpuinfo. Если ни один из флагов не обнаружен, никакие настройки внутри VPS не помогут.

Важное уточнение: Docker не требует этих функций. Контейнеры используют ядро вашего VPS и не взаимодействуют с /dev/kvm. Если ваша цель — «запуск нескольких сервисов в контейнерах на сервере», у вас уже есть все необходимое. Вложенная виртуализация необходима, если вам требуется второе ядро — например, для лаборатории Proxmox, гостевой системы Windows, микровиртуальных машин Firecracker, эмулятора Android, тестовой среды Kubernetes с реальными ВМ или CI-раннеров, загружающих образы ВМ.

Что именно вкладывается друг в друга

Три уровня:

• L0 — гипервизор провайдера на физическом оборудовании. У вас нет к нему доступа.
• L1 — ваш VPS. Для L0 это обычная гостевая ОС.
• L2 — виртуальная машина, которую вы хотите запустить внутри вашего VPS.

Аппаратная виртуализация включает VT-x (флаг vmx) и EPT на Intel, а также AMD-V / SVM (svm) и RVI/NPT на AMD. Гипервизор использует эти инструкции для перехода в гостевой режим и для одновременного обхода процессором двух таблиц страниц.

Ни одна из технологий не проектировалась для рекурсивного использования, поэтому вложенность эмулируется: когда L1 выполняет инструкцию VMX, происходит перехват (trap) к L0, который поддерживает теневые структуры для L2 от имени L1. KVM справляется с этим хорошо, но L0 выполняет дополнительную работу при каждом выходе (exit) — именно поэтому провайдер должен включить эту функцию принудительно.

Для ускоренной работы L2 должны соблюдаться два условия:

1. Модуль KVM в L0 загружен с флагом nested=1.
2. L0 предоставляет вашему VPS модель процессора, содержащую этот флаг — <cpu mode='host-passthrough'/> в libvirt, cpu: host в Proxmox, -cpu host в чистом QEMU. Обычная эмулируемая модель (qemu64, kvm64) скрывает vmx, даже если вложенность включена глобально.

Проверьте ваш VPS за одну минуту

# 1. Are you in a VM, and under what?
systemd-detect-virt          # kvm, vmware, xen, microsoft, or "none" on metal

# 2. Does the CPU expose the extensions to you?
grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u
lscpu | grep -i -E 'virtual|hypervisor'

# 3. The definitive check
sudo apt update && sudo apt install -y cpu-checker
kvm-ok

# 4. The device node the whole stack depends on
ls -l /dev/kvm

Рабочий экземпляр выводит vmx или svm, kvm-ok сообщает KVM acceleration can be used, а /dev/kvm существует в режиме root:kvm 660. Если флаг присутствует, но узел устройства отсутствует, загрузите модуль вручную и проверьте лог ядра:

sudo modprobe kvm_intel     # or kvm_amd
sudo dmesg | tail -n 20

Один файл часто цитируют, но его часто понимают неверно:

cat /sys/module/kvm_intel/parameters/nested   # Y or N

Внутри вашего VPS это настройка вашего модуля KVM; она определяет, может ли гостевая ОС уровня L2 использовать вложенную виртуализацию третьего уровня. Это не говорит о том, включена ли вложенная виртуализация для вас на уровне L0 — на это отвечают /proc/cpuinfo и kvm-ok. Параметр nested — это настройка, которую вы устанавливаете на устройстве, находящемся в вашей полной собственности:

echo 'options kvm_intel nested=1' | sudo tee /etc/modprobe.d/kvm-nested.conf
sudo modprobe -r kvm_intel && sudo modprobe kvm_intel

Удаление модуля невозможно, пока запущена виртуальная машина, поэтому сначала завершите работу гостевых ОС.

Почему большинство VPS-хостингов отключают эту функцию

• Live migration. Предоставление вам vmx означает передачу модели CPU с данным флагом. Гостевая ОС, зависящая от этих функций CPU, не может быть безопасно перенесена на машину, где CPU не поддерживает их. Хостинг, который переносит клиентов между узлами для разгрузки системы, теряет эту возможность при включении вложенной виртуализации.
• Поверхность атаки. Пути вложенной виртуализации VMX/SVM являются одними из самых сложных участков кода в слое виртуализации ядра и имеют историю уязвимостей CVE.
• L0 может быть не KVM. Если systemd-detect-virt выводит vmware, xen или microsoft, правила вложенной виртуализации определяются этим стеком, а не KVM.

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

Запуск L2 гостевой системы с помощью libvirt

sudo apt install -y qemu-system-x86 libvirt-daemon-system virtinst ovmf
sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt,kvm "$USER"   # log out and back in

virt-install \
  --name guest1 \
  --memory 2048 \
  --vcpus 2 \
  --cpu host-passthrough \
  --disk path=/var/lib/libvirt/images/guest1.qcow2,size=20,format=qcow2,bus=virtio \
  --network network=default,model=virtio \
  --os-variant debian13 \
  --location https://deb.debian.org/debian/dists/trixie/main/installer-amd64/ \
  --graphics none \
  --console pty,target_type=serial \
  --extra-args 'console=ttyS0,115200n8'

Графическая сессия не требуется. Установка через serial-интерфейс занимает длительное время, поэтому запускайте процесс в постоянном shell: тот же workflow в tmux, который поддерживает сессии Claude Code на VPS позволяет сохранить доступ к консоли virt-install при разрыве SSH-соединения. Если --os-variant debian13 отклонена, ваша osinfo-db устарела — запустите osinfo-query os и выберите существующее имя. --cpu host-passthrough пробрасывает vmx внутрь L2; это необходимо только в случае, если L2 требует вложенной виртуализации. Для безопасной загрузки гостевой системы используйте virsh autostart guest1.

Шина virtio для диска и NIC не является декоративной: эмулируемые устройства IDE и e1000 вызывают прерывания (trap) в гипервизоре гораздо чаще, чем очереди virtio, а при вложенной виртуализации каждое прерывание обрабатывается дважды.

Сети: то, что пропускают в руководствах

Ваш VPS имеет один публичный IP-адрес и находится за сетевой фабрикой, которая фильтрует неизвестные MAC-адреса. Это приводит к двум последствиям.

L2-мост (bridging) гостевых систем в публичную сеть обычно не работает. Если вы назначите br0 на публичный NIC и присвоите гостевой системе собственный MAC-адрес, вы увидите исходящие ARP-запросы, на которые не будет ответов. Коммутатор провайдера отбрасывает кадры от MAC-адреса, который не был вам выдан. Если вы столкнулись с такой проблемой, не отлаживайте мост; это особенность работы механизма.

Используйте NAT-сеть. В комплекте libvirt идет default: virbr0, 192.168.122.0/24 и аренда адресов dnsmasq; исходящее соединение работает сразу. Для входящих соединений завершайте TLS на L1 и используйте проксирование — пути к сертификатам ниже взяты из выпуска сертификата Let's Encrypt с помощью Certbot на Nginx:

server {
    listen 443 ssl;
    server_name lab.example.com;

    ssl_certificate     /etc/letsencrypt/live/lab.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/lab.example.com/privkey.pem;

    location / {
        proxy_pass http://192.168.122.50:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Сначала назначьте гостевой системе статический адрес (virsh net-edit default), чтобы адрес в этом proxy_pass не менялся.

Интерфейсы управления должны быть закрыты от интернета: VNC на порту 5900 и веб-интерфейс Proxmox на порту 8006 должны работать на loopback-интерфейсе. Доступ к ним осуществляется через SSH-туннель (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) или через собственный WireGuard VPN в VPS, что делает всю подсеть 192.168.122.0/24 доступной через один приватный прыжок. Настройте узкий доступ в firewall — только sudo ufw allow 22,80,443/tcp, ничего больше. Если у гостевых систем пропадает исходящая связь сразу после включения ufw, причиной обычно является DEFAULT_FORWARD_POLICY="DROP" в /etc/default/ufw — установите значение ACCEPT и перезагрузите ufw.

Proxmox на VPS

Proxmox VE 9 базируется на Debian 13. Для установки на Debian VPS необходимо добавить репозиторий pve-no-subscription и пакет proxmox-ve. Используйте строки репозитория и ключа (keyring) из актуальной документации Proxmox — использование URL из старых статей приводит к ошибке установки.

Проблемы с пакетами не являются основной сложностью. Proxmox требует наличия моста vmbr0, подключенного к физическому сетевому интерфейсу (NIC), что приводит к невозможности работы из-за фильтрации по MAC-адресам. Для VPS подходит вариант с NAT или маршрутизацией через vmbr0 без привязки к физическому порту. В этом случае гостевые системы находятся в частном диапазоне, а для публичного доступа на хосте используются правила DNAT или reverse proxy. Если публичные сервисы реализованы в виде контейнеров, а не VM, Traefik для нескольких приложений из одного Docker Compose файла выполняет те же функции маршрутизации и автоматически выпускает сертификаты. Сначала сделайте snapshot /etc/network/interfaces: некорректное определение моста может привести к потере доступа к машине, если у вас нет доступа к её консоли.

Производительность: честный обзор

Вложенная виртуализация (Nested) работает медленнее, чем одноуровневая. Причина не в распределенном характере нагрузки, а в конкретном механизме: затраты вызваны не доступом к памяти, а выходами (exits). При использовании EPT/NPT уровень L0 поддерживает теневые таблицы страниц для L2, поэтому обычное чтение памяти происходит на аппаратной скорости. Основные накладные расходы возникают при каждой операции, которая приводит к выходу из гостевого режима: I/O, прерывания таймера, MMIO, межпроцессорные прерывания. Это происходит потому, что выход L2 обрабатывается уровнем L0 и может быть передан обратно через L1. Вычисления, ограниченные мощностью CPU и работающие с данными в RAM, по производительности близки к нативным; в задачах, где преобладают системные вызовы, сетевой трафик и дисковый I/O, влияние уровней виртуализации заметно.

Таким образом: повсеместно используйте устройства virtio. Ваш файл qcow2 находится на диске, который уже виртуализирован провайдером. Это два слоя тонкого резервирования (thin-provisioning), где cache=none на гостевом диске предотвращает одновременное хранение одних и тех же блоков в двух кэшах страниц. Здесь нет результатов бенчмарков: измеряйте производительность вашей собственной рабочей нагрузки на вашем собственном экземпляре.

Режимы сбоев и отображаемые строки

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used от kvm-ok. Либо модуль не загружен, либо флаг не экспортирован. Сначала проверьте /proc/cpuinfo.

kvm: disabled by bios в dmesg. На bare metal включите переключатель VT-x/SVM в firmware. Внутри VPS это означает, что L0 не предоставляет вам расширения; настройки внутри гостевой ОС это не исправят.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. У процессора, который видит ядро, нет vmx — это снова решение на уровне L0.

Could not access KVM kernel module: Permission denied. Проблема в правах доступа, а не в оборудовании. ls -l /dev/kvm должен показывать группу kvm и режим 660; добавьте себя в эту группу и перезапустите shell, так как членство в группе не применяется к уже запущенной сессии.

kvm: Device or resource busy при запуске QEMU. Другой модуль гипервизора занимает CPU: выполните lsmod, найдите vboxdrv или модули VMware наряду с kvm_intel и выгрузите ненужный модуль.

/var/run/libvirt/libvirt-sock: No such file or directory от virsh. Демон остановлен: sudo systemctl enable --now libvirtd.

Proxmox: KVM virtualisation configured, but not available. У гостевой ОС включено KVM-ускорение на хосте, который не может его предоставить. Настройте вложенную виртуализацию (nesting) или снимите флаг, чтобы использовать эмуляцию.

Android emulator: x86_64 emulation currently requires hardware acceleration! Снова /dev/kvm — обычно проблема в группах.

Ошибок нет, но всё работает крайне медленно. Если у QEMU не указан флаг ускорителя, он переключается на TCG (программный эмулятор). Это корректно, но медленно: загрузка, занимавшая секунды, будет длиться минуты. Передайте -accel kvm явно, чтобы QEMU завершался с ошибкой вместо скрытой эмуляции.

Гостевая ОС исчезает во время работы. Проверьте dmesg на наличие Out of memory: Killed process ... qemu-system-x86_64. Гостевая ОС уровня L2 является процессом в L1, и OOM killer обрабатывает её как любой другой процесс. Оперативная память L2 выделяется из фиксированного объема L1 — заимствование ресурсов у хоста невозможно.

Эксплуатация: резервное копирование, обновление, ограничения

Резервное копирование. Копирование файла qcow2 работающей гостевой системы приведет к повреждению образа. Либо используйте virsh shutdown guest1 для копирования, либо создайте внешний снимок (virsh snapshot-create-as guest1 snap1 --disk-only --atomic). При использовании снимка новые данные записываются в overlay, что позволяет копировать неизменяемый базовый образ, после чего его можно объединить с помощью virsh blockcommit. Переносите копии на другой VPS — снимок на том же диске не обеспечивает защиты.

Обновление. apt full-upgrade устанавливает новые модули kvm_intel/kvm_amd, но работающее ядро использует старые модули до перезагрузки. Сохраняйте предыдущее ядро установленным и запускайте kvm-ok после каждого изменения ядра: если хост загрузится без vmx, вам останется только один пункт в меню загрузки, чтобы восстановить работоспособность.

Пределы масштабирования. Один публичный IP-адрес означает, что каждый сервис L2 взаимодействует с внешним миром через прокси или правило DNAT на уровне L1. Функция Live migration недоступна. При высокой нагрузке на CPU путь выхода из вложенной виртуализации (nested exit path) страдает в первую очередь. Гипервизор с несколькими гостевыми системами потребляет всю доступную RAM — вложенные VM не могут преодолеть ограничения фиксированного объема памяти за счет overcommit. Если лабораторная среда разрастается, решением является не увеличение вложенности стека, а выделенный сервер, где вы являетесь L0 и данные ограничения не действуют.

FAQ

Do I need nested virtualization to run Docker on a VPS?

No. Containers share your VPS kernel and never open /dev/kvm, so a plain instance with no vmx or svm flag runs Docker and Docker Compose fine. Nesting only matters when you want a second kernel: a Proxmox lab, a Windows guest, Firecracker microVMs, an Android emulator, or CI runners that boot VM images.

How do I check whether my VPS supports nested virtualization?

Run grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u, then kvm-ok from the cpu-checker package. A usable instance prints vmx (Intel) or svm (AMD), kvm-ok reports KVM acceleration can be used, and /dev/kvm exists with group kvm and mode 660. Ignore /sys/module/kvm_intel/parameters/nested for this question — that file describes your own KVM module, not what the provider's hypervisor exposed to you.

Why do most VPS providers disable nested virtualization?

Exposing vmx means handing the guest a CPU model that carries the flag, and a guest that depends on those CPU features cannot be live-migrated onto a machine whose CPU lacks them — a provider that drains nodes by moving customers around gives that up. The nested VMX/SVM code paths also carry a long CVE history. Some hosts still enable it per-VM on request, and others document nesting as a plan feature.

My nested VM has no network on the public bridge. What is wrong?

The provider's switch drops frames from a MAC address it never leased you, so an L2 guest bridged onto the public NIC sends ARP and hears nothing back. Stop debugging br0 — use libvirt's NAT default network (virbr0, 192.168.122.0/24), give the guest a static lease, and publish anything public through a reverse proxy or DNAT rule on the VPS itself.

How much slower is a nested VM?

The cost lands on VM exits, not on memory access. With EPT/NPT active, ordinary reads and writes inside L2 run at hardware speed, while I/O, timer interrupts, MMIO and IPIs are handled by L0 and may be bounced back through L1. CPU-bound work over data already in RAM looks close to native; syscall-, packet- and disk-heavy workloads feel every layer. Use virtio devices everywhere and cache=none on guest disks, then measure your own workload.