Вложенная виртуализация: запустить гипервизор внутри VPS

MAATRIX

Вы арендовали VPS для тестового стенда, попытались поднять внутри неё Proxmox или голый KVM — и либо виртуалка второго уровня не стартует вовсе, либо стартует, но работает мучительно медленно. Это не баг конкретно вашей конфигурации: вложенная виртуализация требует явной поддержки сразу на трёх независимых уровнях, и если хотя бы один провален — дальше можно не копать. Разберём, что именно проверять, как включить то, что зависит от вас, и честно — почему это решение для тестов и обучения, а не для продакшна.

Зачем вообще запускать гипервизор внутри виртуалки

Смысл не в том, чтобы «сэкономить» на железе для боевой нагрузки — там нужен физический сервер. Вложенная виртуализация закрывает другие, вполне рабочие задачи:

• Тестирование и разработка инфраструктуры виртуализации. Вы пишете Ansible-роль для разворачивания Proxmox-кластера или тестируете скрипт автоматической установки KVM-гипервизора — и хотите прогонять это раз в день, а не бронировать физический сервер под каждый прогон.
• Изолированные учебные лаборатории. Курс по администрированию виртуализации, где каждому студенту нужна своя песочница с правами root на гипервизор — но выдавать физические серверы десяткам студентов дорого и медленно.
• CI/CD-системы, тестирующие сборки, которым нужна виртуализация. Пайплайн собирает установочный ISO и должен проверить, что он реально ставится и загружается в виртуальной машине — раннеру нужен собственный KVM.
• Демонстрации и PoC. Показать заказчику, как будет выглядеть архитектура с гипервизором, не разворачивая для одной презентации выделенный сервер.

Во всех этих сценариях важна функциональная корректность и изоляция, а не производительность виртуалок второго уровня. Если ваша цель — реальная продакшн-нагрузка на VM внутри Proxmox, вложенная виртуализация в VPS — не тот инструмент, и об этом честно в конце статьи.

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

Путаница почти всегда возникает потому, что люди проверяют только один уровень и не понимают, почему остальные два всё портят. Уровней ровно три, и они независимы:

Если уровень 1 в порядке (а на любом железе моложе десяти лет он почти всегда в порядке), но уровень 2 не включён провайдером — вы не получите вложенную виртуализацию, сколько бы модулей ни грузили на уровне 3. И наоборот: даже при полностью проброшенной виртуализации на уровне 2, если внутри гостя не включён nested, /dev/kvm для второго уровня просто не появится.

Уровень 1 и 2: то, что скрыто от вас как от арендатора

Физический процессор хоста вы не видите и не контролируете — это железо провайдера. Практически на любом современном сервере (Intel Xeon Scalable, AMD EPYC последних поколений) VT-x/AMD-V присутствуют, это стандарт индустрии. Реальная проблема почти всегда не здесь.

Ключевой и самый неочевидный барьер — уровень 2: внешний гипервизор, который управляет самой вашей VPS-виртуалкой (тот, что вы вообще не видите как арендатор), должен явно пробросить флаги виртуализации внутрь гостевого CPU. В терминах KVM/QEMU это означает выставить в конфигурации виртуальной машины режим CPU host-passthrough (или явно перечислить флаги vmx/svm) вместо стандартного эмулированного CPU-профиля.

Многие облачные провайдеры и хостеры не делают этого по умолчанию, и на то есть причины:

• Изоляция и безопасность. Проброс VT-x/AMD-V расширяет поверхность атаки — потенциальный побег из гостевой VM через баги в эмуляции виртуализации теоретически опаснее, чем без него.
• Производительность и «шумные соседи». Некоторые платформы виртуализации ограничивают набор доступных CPU-флагов ради предсказуемой миграции виртуалок между узлами кластера (live migration) — с проброшенным host-passthrough мигрировать VM на узел с другим процессором становится сложнее или невозможно.
• Просто не тестировали. На части платформ (особенно бюджетных OpenVZ/LXC-подобных VPS или облаках на базе Xen HVM без явной поддержки) вложенная виртуализация не поддерживается архитектурно в принципе.

Отсюда практический вывод: вложенная виртуализация — это в первую очередь вопрос к провайдеру, а не только к настройкам внутри вашей ОС. Прежде чем проектировать стенд, нужно прямо спросить у хостинга (через тикет или документацию тарифа), поддерживает ли их платформа проброс nested-виртуализации для арендуемых VPS, и на каких именно тарифах/гипервизорах. Если провайдер отвечает «не поддерживаем» или вообще не понимает вопроса — дальше пробовать бессмысленно, ищите тариф или провайдера, где это явно заявлено.

Проверить со своей стороны, дошёл ли флаг до вас, можно изнутри VPS одной командой:

cat /proc/cpuinfo | grep -E 'vmx|svm'

Если вывод пуст — уровень 2 не пройден, и это железный тупик именно на этой VPS/тарифе, а не то, что можно «донастроить». Если vmx (Intel) или svm (AMD) присутствует в флагах — переходите к уровню 3.

Отдельно стоит закрепить: это в принципе не то же самое, что «Docker в Docker». Контейнеры (Docker, LXC) используют пространства имён ядра хоста и не эмулируют CPU — там нет требования к VT-x/AMD-V вообще. Речь именно про полноценные гипервизоры (KVM, Proxmox, VirtualBox с аппаратным ускорением, VMware Workstation) и их собственные виртуальные машины внутри уже виртуальной VPS.

Уровень 3: включаем nested внутри самой VPS

Это единственный уровень, который полностью в ваших руках — при условии, что уровень 2 пройден. Первым делом проверьте, загружен ли модуль KVM и в каком он режиме:

lsmod | grep kvm
cat /sys/module/kvm_intel/parameters/nested   # для Intel
cat /sys/module/kvm_amd/parameters/nested     # для AMD

Ответ Y или 1 — вложенная виртуализация на уровне модуля ядра включена. N или 0 — нужно перегрузить модуль с нужным параметром:

# Intel
modprobe -r kvm_intel
modprobe kvm_intel nested=1

# AMD
modprobe -r kvm_amd
modprobe kvm_amd nested=1

Если модуль занят (используется работающими виртуалками или сервисом libvirt), modprobe -r откажет — сначала остановите libvirtd/запущенные VM. Чтобы настройка пережила перезагрузку, закрепите параметр постоянно:

cat <<'EOF' > /etc/modprobe.d/kvm-nested.conf
options kvm_intel nested=1
options kvm_amd nested=1
EOF

(лишняя строка для чужой архитектуры не мешает — просто игнорируется).

Дальше стоит проверить сам факт присутствия устройства и корректность окружения целиком:

ls -la /dev/kvm
apt install -y cpu-checker   # на Debian/Ubuntu
kvm-ok

kvm-ok явно скажет, может ли текущее окружение выполнять аппаратно ускоренную виртуализацию, и если нет — укажет причину (часто это именно «KVM acceleration can NOT be used», что снова указывает на непройденный уровень 2, а не на локальную настройку).

Практика: поднимаем KVM или Proxmox второго уровня

Когда /dev/kvm доступен и nested=1 подтверждён, дальше это обычная установка гипервизора — но с двумя нюансами, характерными именно для вложенного сценария.

Для голого KVM/libvirt на Debian/Ubuntu:

apt install -y qemu-kvm libvirt-daemon-system virtinst bridge-utils
systemctl enable --now libvirtd
virt-host-validate   # покажет конкретные проблемы окружения, если они остались

Для полноценного Proxmox VE внутри VPS — устанавливается поверх Debian по стандартной схеме (добавление репозитория Proxmox и pveversion после установки пакетов), устройство пойдёт по накатанной как на «первую виртуалку» на обычном железе — сам процесс подробно разбирался в статье про установку Proxmox VE с нуля.

Два практических нюанса, которые всплывают именно во вложенном сценарии:

1. Сеть. Виртуалки второго уровня обычно подключают через мост (bridge) на внешний виртуальный интерфейс VPS. Многие облачные виртуальные коммутаторы по умолчанию блокируют смену MAC-адреса и promiscuous-режим на портах гостя — а мосту для внутренних VM это необходимо. Симптом: бридж настроен правильно, а виртуалка внутри вообще не получает сетевой трафик. Это тот же класс проблем, что разбирался в статье про мосты и VLAN в Proxmox и пропадающий доступ — только источник блокировки на уровень выше: не сам Proxmox, а виртуальный свитч провайдера вашей VPS. Решается либо включением promiscuous/MAC-spoofing на внешнем интерфейсе (если провайдер это позволяет в панели), либо переходом на NAT вместо моста для тестового стенда.
2. Диск. У вложенных VM образы дисков (qcow2/raw) лежат поверх файловой системы VPS, которая сама уже виртуальный диск внешнего гипервизора. Это двойной слой блочного I/O — используйте virtio для дисков и сети внутри вложенных VM (не эмулированные IDE/e1000), это ощутимо снижает накладные расходы по сравнению с эмуляцией по умолчанию.

Честно про производительность: где это не годится

Здесь важно не приукрашивать. Каждый дополнительный уровень виртуализации добавляет накладные расходы — это виртуализация виртуализации, и она не бесплатна ни при каких настройках:

• Виртуалки второго уровня перехватывают и обрабатывают привилегированные инструкции дважды: сначала внутренний гипервизор эмулирует их для своей VM, затем это транслируется через уровень внешнего гипервизора, который управляет самой VPS. Даже с аппаратным ускорением (VT-x/AMD-V проброшены) полностью бесплатным это не становится.
• Сильнее всего страдают I/O-интенсивные и сетевые нагрузки — двойной стек virtio (внутренний гипервизор → внешний гипервизор → физическое железо) означает лишние переключения контекста на каждой операции.
• Планирование CPU и распределение памяти (в том числе баллонинг — механизм, которым внешний гипервизор забирает память обратно у VPS под нагрузкой, подробнее в статье про ballooning памяти) теперь работает в два слоя одновременно, что увеличивает джиттер и непредсказуемость таймингов.
• Точные цифры накладных расходов честно назвать нельзя — они сильно зависят от типа нагрузки, конкретного железа хоста и настроек провайдера. Ориентировочно речь о существенных, легко заметных на глаз потерях (наблюдаемо — двузначные проценты и выше на I/O-нагрузках), а не о погрешности в пределах шума. Общий разбор того, где виртуализация в принципе теряет производительность даже без вложенности, — в статье «Где виртуализация теряет производительность»; вложенный сценарий добавляет к этому ещё один полный слой сверху.

Практический вывод простой: вложенная виртуализация хороша для тестирования, обучения и CI, где важна функциональная корректность, а не скорость. Для реальной продакшн-нагрузки на Proxmox/KVM — тестового стенда мало, здесь нужна честная производительность без дополнительного слоя эмуляции. В этом случае разумнее сразу арендовать выделенный сервер и поднять гипервизор прямо на голом железе — без вложенности, без непредсказуемых лимитов чужого внешнего гипервизора и без вопроса «а поддерживает ли это вообще провайдер». Сравнение подходов — в статье «VPS или выделенный сервер: что выбрать».

Частые вопросы