Чи можна запустити Proxmox на VPS
Перевірте підтримку nested virtualization командою kvm-ok за одну хвилину: прапорець vmx або svm визначає, чи запустяться KVM і Proxmox та які помилки з’являться.
Коротка відповідь
Nested virtualization — це гіпервізор, який працює всередині віртуальної машини: ваш VPS уже є гостьовою системою, а ви хочете розміщувати в ньому власні гостьові системи. Це працює лише тоді, коли гіпервізор провайдера явно надає вашому інстансу розширення віртуалізації процесора. Перевірте /proc/cpuinfo на наявність прапорця vmx (Intel) або svm (AMD). Якщо немає жодного з них, жодні налаштування всередині VPS не допоможуть.
Спочатку важливо уточнити одне: Docker для цього не потрібен. Контейнери використовують спільне ядро VPS і не взаємодіють із /dev/kvm. Якщо ваша реальна мета — «запустити кілька сервісів у контейнерах на моєму сервері», у вас уже є все необхідне. Nested virtualization потрібна, якщо ви хочете використовувати окреме ядро, лабораторне середовище Proxmox, гостьову систему Windows, мікровіртуальні машини Firecracker, емулятор Android, тестове середовище Kubernetes зі справжніми віртуальними машинами або CI runners, які завантажують образи віртуальних машин.
Що саме вкладається
Три рівні:
- L0 — гіпервізор провайдера на фізичному сервері. Ви не маєте до нього доступу.
- L1 — ваш VPS. Для L0 це лише гостьова система.
- L2 — VM, яку ви хочете запустити всередині свого VPS.
Апаратна віртуалізація — це VT-x (прапорець vmx) і EPT на Intel, а також AMD-V / SVM (svm) і RVI/NPT на AMD. Гіпервізор використовує ці інструкції, щоб переходити в гостьовий режим і дозволяти CPU одночасно проходити дві таблиці сторінок.
Жоден із цих механізмів не був розроблений для повторного входу, тому вкладена віртуалізація емулюється: коли L1 виконує інструкцію VMX, виникає trap до L0, який від імені L1 підтримує тіньові структури для L2. KVM робить це ефективно, але додаткову роботу під час кожного exit виконує саме L0. Тому провайдер має явно дозволити цю функцію.
Для прискореної L2 мають одночасно виконуватися дві умови:
- Модуль KVM у L0 завантажено з параметром
nested=1. - L0 надає вашому VPS модель CPU, яка містить цей прапорець:
<cpu mode='host-passthrough'/>у libvirt,cpu: hostу Proxmox,-cpu hostу raw 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 створити вкладений рівень L3. Цей параметр нічого не говорить про те, чи дозволив L0 вкладену віртуалізацію для вашого VPS. На це відповідають /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-хостингів вимикають цю функцію
- Жива міграція. Надання вам
vmxозначає відкриття моделі CPU, яка містить цей прапорець. Гостьову систему, що залежить від цих функцій CPU, не можна безпечно перенести на машину без відповідних можливостей процесора. Хостинг, який звільняє вузли, мігруючи клієнтів, втрачає цю можливість одразу після ввімкнення nested virtualization. - Поверхня атаки. Шляхи nested VMX/SVM належать до найскладніших ділянок коду в шарі віртуалізації ядра. Історія CVE це підтверджує.
- L0 може бути не KVM. Якщо
systemd-detect-virtвиводитьvmware,xenабоmicrosoft, правила nested virtualization визначаються цим стеком, а не KVM.
Немає прапорця у вашому екземплярі? Зверніться до служби підтримки: деякі провайдери вмикають його для окремих VM. Також можна вибрати тариф, у документації якого заявлена підтримка nested virtualization, або перейти на виділений сервер. Далі передбачається, що ви маєте 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'Графічний сеанс не потрібен. Встановлення через послідовну консоль триває певний час, тому запустіть його всередині постійної shell-сесії: той самий процес роботи з 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 для диска й мережевого інтерфейсу — не формальність: емуляція пристроїв IDE та e1000 спричиняє значно частіші переходи до гіпервізора, ніж черги virtio, а під час вкладеної віртуалізації кожен такий перехід відбувається двічі.
Мережа: те, що часто пропускають у посібниках
Ваш VPS має одну публічну IP-адресу та працює за мережевою інфраструктурою, яка фільтрує невідомі MAC-адреси. З цього випливають два наслідки.
Підключення L2-гостьових систем до публічної мережі через bridge зазвичай не працює. Розмістіть br0 на публічному NIC, призначте гостьовій системі власну MAC-адресу — і побачите, що ARP-запити виходять, але відповіді не надходять: комутатор провайдера відкидає кадри з MAC-адреси, яку він вам не виділяв. Якщо спостерігаєте саме таку ознаку, припиніть налагоджувати bridge: причина полягає в цьому механізмі.
Використовуйте 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) або через self-hosted 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, тому встановлюється на VPS з Debian через додавання репозиторію pve-no-subscription і пакета proxmox-ve. Рядки репозиторію та keyring візьміть із поточної офіційної документації Proxmox. URL, скопійований зі старого допису в блозі, може зламати встановлення. Перш ніж витрачати вечір на налаштування мережі нижче, варто визначити, чи доцільно взагалі розгортати Proxmox на орендованому обладнанні. У порівнянні вартості та можливостей Proxmox-сервера вдома й орендованого VPS це питання розглянуто з урахуванням витрат на електроенергію та обладнання.
Пакети — не найскладніша частина. Proxmox очікує, що vmbr0 буде об’єднано в bridge із фізичним NIC, що одразу призводить до описаної вище проблеми з фільтрацією MAC-адрес. На VPS працює схема з NAT або маршрутизованим vmbr0 без підключеного фізичного порту, гостьовими системами в приватному діапазоні та правилами DNAT або reverse proxy на хості для публічних сервісів. Якщо публічні сервіси працюють у контейнерах, а не у VM, Traefik для маршрутизації кількох застосунків з одного Docker Compose-файлу виконує те саме завдання та автоматично отримує сертифікати. Спочатку створіть snapshot /etc/network/interfaces: неправильне визначення bridge може заблокувати доступ до машини, консоль якої може бути вам недоступна.
Продуктивність без прикрас
Вкладена віртуалізація повільніша за однорівневу. Причина конкретна, а не розмита: затрати виникають не під час доступу до пам’яті, а під час виходів із гостьового режиму. Якщо доступні EPT/NPT, L0 підтримує тіньові таблиці сторінок для L2, а звичайне читання пам’яті виконується на швидкості апаратного забезпечення. Витратними є операції, які залишають гостьовий режим: введення-виведення, переривання таймера, MMIO та міжпроцесорні переривання. Вихід L2 обробляє L0, після чого він може бути переданий назад через L1. Обчислення, обмежені продуктивністю CPU, над даними, які вже перебувають у RAM, майже не відрізняються від нативного виконання. Для операцій, де основні витрати припадають на системні виклики, пакети та дискове введення-виведення, вплив рівнів помітний.
Тому використовуйте 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. На фізичному сервері увімкніть параметр VT-x/SVM у firmware. Усередині VPS це означає, що L0 не надає розширення, і жодна команда в гостьовій системі цього не змінить.
modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. CPU, який бачить ваше ядро, не має vmx. Це знову рішення на рівні L0.
Could not access KVM kernel module: Permission denied. Причина в правах, а не в апаратному забезпеченні. ls -l /dev/kvm має показувати групу kvm і режим 660. Додайте себе до цієї групи та запустіть нову login 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 на хості, який не може його надати. Налаштуйте nested virtualization або вимкніть цей параметр і погодьтеся на емуляцію.
Емулятор Android: 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 обробляє її так само, як будь-який інший процес. Оперативна пам’ять L2 виділяється з фіксованого обсягу L1, без запозичення пам’яті з хоста.
Експлуатація: резервні копії, оновлення, обмеження
Резервні копії. Копіювання qcow2 запущеної гостьової системи призводить до пошкодження образу. Або virsh shutdown guest1 і скопіюйте образ, або створіть зовнішній snapshot (virsh snapshot-create-as guest1 snap1 --disk-only --atomic), щоб операції запису перенаправлялися в overlay, доки ви копіюєте статичну базу, а потім об’єднайте зміни за допомогою virsh blockcommit. Зберігайте копії за межами VPS: snapshot на тому самому диску не захищає ні від чого.
Оновлення. apt full-upgrade встановлює нові модулі kvm_intel/kvm_amd, але запущене ядро продовжує використовувати старі модулі, доки ви не перезавантажите систему. Залишайте попередню версію ядра встановленою та повторно запускайте kvm-ok після кожної зміни ядра: якщо хост завантажиться без vmx, для відновлення роботи буде достатньо вибрати інший запис під час завантаження.
Межі масштабування. Одна публічна IP-адреса означає, що кожен сервіс L2 доступний із зовнішньої мережі через проксі або правило DNAT на L1. Жива міграція недоступна. За конкуренції за CPU першою починає втрачати продуктивність вкладений шлях виходу. Гіпервізор із кількома гостьовими системами працює на машині, оперативну пам’ять якої вже розподілено, а вкладені VM не можуть компенсувати фіксований обсяг пам’яті за допомогою overcommit. Коли лабораторне середовище переростає ці межі, рішенням є не ще один рівень вкладення, а окрема машина, де ви працюєте на рівні L0 і ці обмеження не застосовуються.
FAQ
Чи потрібна вкладена віртуалізація, щоб запускати Docker на VPS?
Ні. Контейнери спільно використовують kernel вашого VPS і ніколи не відкривають /dev/kvm, тому звичайний instance без прапора vmx або svm без проблем запускає Docker і Docker Compose. Вкладена віртуалізація потрібна лише тоді, коли ви хочете запустити другий kernel: лабораторне середовище Proxmox, гостьову систему Windows, мікровіртуальні машини Firecracker, емулятор Android або CI runners, які завантажують образи VM.
Як перевірити, чи підтримує мій VPS вкладену віртуалізацію?
Виконайте grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u, а потім kvm-ok з пакета cpu-checker. Працездатний instance виведе vmx (Intel) або svm (AMD), kvm-ok повідомить про KVM acceleration can be used, а /dev/kvm існуватиме з group kvm і mode 660. Не враховуйте /sys/module/kvm_intel/parameters/nested у цьому питанні: цей файл описує ваш власний модуль KVM, а не те, що hypervisor провайдера відкрив для вас.
Чому більшість VPS-провайдерів вимикає вкладену віртуалізацію?
Відкриття vmx означає надання guest CPU model, яка містить цей прапор. Guest, що залежить від цих CPU features, не можна live-migrate на машину, CPU якої їх не підтримує. Провайдер, який звільняє вузли, переміщуючи між ними клієнтів, втрачає таку можливість. Шляхи виконання коду для вкладених VMX/SVM також мають тривалу історію CVE. Деякі host усе ще вмикають цю функцію для окремої VM на запит, а інші вказують nesting як можливість тарифного плану.
У моєї вкладеної VM немає мережі через публічний bridge. У чому проблема?
Switch провайдера відкидає кадри з MAC-адреси, яку він вам не виділяв. Тому L2 guest, підключений bridge до публічного NIC, надсилає ARP, але не отримує відповіді. Не витрачайте час на налагодження br0. Використовуйте NAT default libvirt (virbr0, 192.168.122.0/24), призначте guest статичну lease, а публічні сервіси опублікуйте через reverse proxy або правило DNAT на самому VPS.
Наскільки повільнішою є вкладена VM?
Витрати припадають на VM exits, а не на доступ до пам’яті. Якщо EPT/NPT активні, звичайні операції читання та запису всередині L2 виконуються зі швидкістю hardware. Водночас I/O, переривання таймера, MMIO та IPI обробляються на L0 і можуть передаватися назад через L1. CPU-bound робота з даними, які вже перебувають у RAM, майже не відрізняється від native виконання. Workload із великою кількістю syscall, пакетів і дискових операцій відчуває накладні витрати кожного рівня. Використовуйте virtio devices всюди та cache=none на guest disks, а потім виміряйте продуктивність власного workload.