SSD Nodes Learn
Посібники Matt ConnorВід Matt Connor · Оновлено 2026-07-24

Чи можна запустити Proxmox на VPS

Перевірте підтримку nested virtualization за допомогою kvm-ok. Дізнайтеся, чи прокинув провайдер vmx або svm прапорці для запуску гостьових VM у Proxmox.

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

Вкладена віртуалізація (nested virtualization) — це запуск гіпервізора всередині віртуальної машини: ваш VPS вже є гостьовою машиною, а ви хочете, щоб він сам міг хостити гостьові системи. Це працює лише тоді, коли гіпервізор вашого провайдера спеціально прокидає розширення віртуалізації CPU у ваш екземпляр — перевірте /proc/cpuinfo на наявність прапорця vmx (Intel) або svm (AMD). Якщо жоден із них не з'явився, жодні налаштування всередині VPS не допоможуть.

Важливе зауваження: Docker не потребує вкладеної віртуалізації. Контейнери використовують ядро вашого VPS і ніколи не звертаються до /dev/kvm. Якщо ваша мета — «запустити кілька сервісів у контейнерах на моєму сервері», у вас вже є все необхідне. Вкладена віртуалізація потрібна, якщо вам потрібне друге ядро — наприклад, для лабораторії Proxmox, гостьової системи Windows, мікровіртуальних машин Firecracker, емулятора Android, тестового середовища Kubernetes з реальними VM або CI-runnerів, які завантажують образи VM.

Що саме вкладається (nesting)

Три рівні:

  • 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, яка має відповідний прапор — <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 існує у режимі 660 як root:kvm. Якщо прапорець присутній, але вузол пристрою відсутній, завантажте модуль вручну та перевірте лог ядра:

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

Видалення модуля неможливе, поки запущена VM, тому спочатку вимкніть гостьів.

Чому більшість VPS-хостингів вимикають цю функцію

  • Live migration. Надання вам vmx означає передачу моделі CPU з цим прапорцем. Якщо гостьова ОС залежить від цих функцій CPU, її неможливо безпечно мігрувати на машину, де CPU не має цих функцій. Хостинг, який переміщує клієнтів між вузлами (nodes), втрачає цю можливість, як тільки вмикає nesting.
  • Attack surface. Шляхи nested VMX/SVM є одними з найскладніших ділянок коду у рівні віртуалізації ядра, що підтверджується історією CVE.
  • L0 may not be KVM. Якщо systemd-detect-virt виводить vmware, xen або microsoft, правила nesting визначаються цим стеком, а не KVM.

Якщо на вашому instance немає цього прапорця: зверніться до підтримки (деякі вмикають його для окремих VM), оберіть тарифний план із підтримкою nesting або перейдіть на dedicated server. Далі в цьому посібнику припускається, що ви маєте root-доступ на машині, де цей прапорець активовано.

Запуск L2 guest за допомогою 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'

Графічна сесія не потрібна. Серійне встановлення триває певний час, тому запускайте його у постійному 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-адреси. Це призводить до двох наслідків.

Бридж (Bridging) L2-гостей у публічну мережу зазвичай не працює. Якщо ви налаштуєте br0 на публічному NIC і призначите гостю окрему MAC-адресу, ви побачите, що ARP-запити надсилаються, але відповіді не приходять — комутатор провайдера скидає кадри від MAC-адреси, яку він вам не видавав. Якщо ви спостерігаєте такий симптом, припиніть налагодження мосту; це особливість роботи механізму.

Замість цього використовуйте NAT-мережу. libvirt постачає default: virbr0, 192.168.122.0/24 та DHCP-аренди 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 на відстань одного приватного стрибка. Налаштовуйте фаєрвол максимально обмежено — лише 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 — посилання з застарілих блогів призводить до помилки встановлення.

Проблема не у пакетах. Proxmox потребує vmbr0, з'єднаного з фізичним NIC, що призводить до обмеження MAC-фільтрації, описаного вище. Для VPS підходить схема з NAT або маршрутизацією vmbr0 без прив'язки до фізичного порту. Гостьові системи мають перебувати в приватній мережі, а для публічного доступу використовуйте правила DNAT або reverse proxy на хості. Якщо публічні сервіси — це контейнери, а не VM, Traefik для декількох додатків з одного Docker Compose файлу виконує те саме завдання з автоматичним отриманням сертифікатів. Спочатку зробіть snapshot /etc/network/interfaces: неправильне налаштування bridge заблокує доступ до машини, консоль якої може бути недоступна.

Продуктивність: чесний аналіз

Вкладена віртуалізація (Nested) повільніша за однорівневу. Причина специфічна: витрати ресурсів пов'язані не з доступом до пам'яті, а з виходами (exits). За наявності EPT/NPT рівень L0 підтримує тіньові таблиці сторінок (shadow page tables) для L2, тому звичайне читання пам'яті відбувається на апаратній швидкості. Основні витрати створює кожна операція, що переводить систему з режиму гостя (guest mode) — I/O, переривання таймера, MMIO, міжпроцесорні переривання. Це відбувається тому, що вихід L2 обробляється рівнем L0 і може бути переданий назад через L1. Робота, обмежена потужністю CPU з даними в RAM, майже не відрізняється від нативної; у завданнях, де переважають системні виклики (syscalls), мережеві пакети та дискове 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 не надає вам розширення, і жодні налаштування в guest це не змінять.

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 acceleration на хості, який не може його забезпечити. Виправте вкладеність (nesting) або вимкніть цей параметр і використовуйте емуляцію.

Android emulator: x86_64 emulation currently requires hardware acceleration! знову /dev/kvm — зазвичай через групу.

Помилок немає, але все працює надзвичайно повільно. QEMU без прапорця accelerator використовує TCG (програмний емулятор). Це працює коректно, але повільно — завантаження, яке тривало секунди, перетворюється на хвилини. Передайте -accel kvm явно, щоб QEMU видавав помилку замість тихої емуляції.

Гостьова ОС зникає під час роботи. Перевірте dmesg на наявність Out of memory: Killed process ... qemu-system-x86_64. Гостьова ОС рівня L2 — це процес у L1, і OOM killer обробляє її як будь-який інший процес. RAM для 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 відчуває затримки першим. Гіпервізор з кількома гостьовими машинами має обмежений обсяг RAM — вкладені VM не можуть використовувати overcommit для виходу за межі фіксованого виділення пам'яті. Якщо лабораторна середа стає занадто великою, рішенням є не збільшення вкладеного стека, а виділений сервер, де ви є L0 і ці обмеження не діють.

FAQ

Чи потрібна вкладена віртуалізація (nested virtualization) для запуску Docker на VPS?

Ні. Контейнери використовують ядро вашого VPS і ніколи не відкривають /dev/kvm. Звичайний екземпляр без прапорців vmx або svm дозволяє стабільно працювати Docker та Docker Compose. Вкладена віртуалізація потрібна лише тоді, коли вам потрібне друге ядро: наприклад, для лабораторії Proxmox, гостьової ОС Windows, мікроVM Firecracker, емулятора Android або CI-раннерів, які завантажують образи VM.

Як перевірити, чи підтримує мій VPS вкладену віртуалізацію?

Запустіть grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u, а потім kvm-ok з пакета cpu-checker. Якщо вкладена віртуалізація доступна, команда виведе vmx (Intel) або svm (AMD). kvm-ok повідомить про KVM acceleration can be used, а наявність /dev/kvm з групою kvm та режимом 660 підтвердить підтримку. Для цього питання ігноруйте /sys/module/kvm_intel/parameters/nested — цей файл описує ваш власний модуль KVM, а не те, що гіпервізор провайдера передав вам.

Чому більшість VPS-провайдерів вимикають вкладену віртуалізацію?

Надання vmx означає передачу гостьовій ОС моделі CPU з відповідним прапорцем. Гостьова ОС, що залежить від цих функцій CPU, не може бути перенесена методом live-migration на вузол, де CPU не має цих функцій. Провайдери, які використовують переміщення клієнтів між вузлами для балансування навантаження, відмовляються від цієї функції. Код VMX/SVM для вкладеної віртуалізації також має довгу історію вразливостей CVE. Деякі хостинг-провайдери увімкнуть її за запитом для окремої VM, інші ж розглядають вкладену віртуалізацію як платну функцію.

У моїй вкладеній VM немає мережі в публічному бриджі. У чому проблема?

Комутатор провайдера відкидає кадри від MAC-адреси, яку він вам не видавав. Тому гостьова ОС рівня L2, підключена через bridge до публічного NIC, надсилає ARP-запити, але не отримує відповідей. Не витрачайте час на налагодження br0 — використовуйте NAT-мережу libvirt default (virbr0, 192.168.122.0/24), призначте гостьовій ОС статичну адресу та публікуйте зовнішній трафік через reverse proxy або правило DNAT на самому VPS.

Наскільки повільнішою є вкладена VM?

Продуктивність залежить від кількості виходів з VM (VM exits), а не від швидкості доступу до пам'яті. При активних EPT/NPT звичайні операції читання та запису всередині L2 виконуються на апаратній швидкості. Проте операції I/O, переривання таймера, MMIO та IPI обробляються на рівні L0 і можуть передаватися назад через L1. Робота, обмежена потужністю CPU, з даними в RAM, майже не відрізняється від нативної; навантаження, пов'язані з системними викликами, мережею та диском, відчутно сповільшуються на кожному рівні. Використовуйте пристрої virtio всюди та cache=none для дисків гостьової ОС, після чого ви зможете виміряти продуктивність вашого конкретного навантаження.

#nested-virtualization#kvm#proxmox#vps#qemu#libvirt