Nested virtualization — запуск гипервизора внутри уже работающей виртуальной машины. Например: физический сервер → KVM ВМ → второй уровень KVM с собственными ВМ. Технически требует передачи CPU-флагов VMX/SVM в гостевую ВМ и аппаратной поддержки со стороны процессора.
Как работает
Для включения nested virtualization на KVM хост должен экспортировать флаг vmx (Intel) или svm (AMD) в гостевую ВМ: modprobe kvm_intel nested=1. В конфигурации ВМ (libvirt XML) устанавливается <cpu mode='host-passthrough'/> или явно прописываются флаги vmx/svm.
Производительность nested virtualization существенно ниже bare-metal: каждый VM-exit из вложенной ВМ проходит два уровня обработки. Накладные расходы составляют 20–50% для CPU-интенсивных задач. Для I/O-операций потери ещё больше.
Основные применения: тестирование конфигураций Proxmox, vSphere, Kubernetes без физического железа; разработка облачных платформ; CI/CD-системы, которым нужна изоляция уровня ВМ (например, GitLab CI с Docker executor в ВМ).
История
Поддержка nested virtualization появилась в ядре Linux с KVM в 2011 году (AMD-V) и 2012 году (Intel VMX). VMware поддержала nested virtualization для ESXi в 2013 году. К 2020-м nested virtualization поддерживается большинством облачных провайдеров (AWS, Azure, GCP, Hetzner) как опциональная функция.
На что обращать внимание
Не все хостинг-провайдеры разрешают nested virtualization на VPS — уточняйте заранее. На AWS функция включается для инстансов .metal и ряда других типов. Для production-задач nested virtualization не рекомендуется из-за потерь производительности — используйте bare-metal сервер или Cloud VPS с прямым доступом к CPU.
Включение Nested Virtualization
На KVM: cat /sys/module/kvm_intel/parameters/nested. Включить: <cpu mode="host-passthrough"/> в конфиге QEMU/libvirt. На Proxmox VE — чекбокс Host CPU. После включения в гостевой ВМ видны флаги vmx или svm в /proc/cpuinfo.
Производительность nested virtualization
ВМ внутри ВМ работает на 30–70% медленнее по CPU. Для production-нагрузок неприемлема. Дисковые операции замедляются ещё сильнее при вложенных виртуальных дисках.
Применение в CI/CD и обучении
Тестирование Kubernetes-кластеров в CI/CD (Minikube/kind внутри CI-runner). Обучающие среды. Тестирование гипервизоров без физического железа. Vagrant с VirtualBox или KVM внутри CI-раннера — стандартный паттерн.
Практическое использование nested virtualization
Тестирование Kubernetes через kind (Kubernetes IN Docker) в CI-раннере на VPS. kind создаёт кластер в Docker-контейнерах. Для GitHub Actions self-hosted runner на KVM-VPS — вложенная виртуализация опциональна: kind работает без неё через Docker-контейнеры.
Случаи обязательного использования
Тестирование Kubernetes-кластеров: kubeadm init внутри ВМ требует nested virtualization (для crictl). Docker в Docker (DinD) — работает без nested, но менее безопасно. Безопасный DinD: docker:dind образ для CI. Тестирование гипервизоров (установка KVM в ВМ) — только с nested virtualization.