Nested Virtualization – uruchamianie hypervisora wewnątrz maszyny wirtualnej

Nested Virtualization to technologia pozwalająca uruchomić maszynę wirtualną wewnątrz innej maszyny wirtualnej.

Czyli zamiast klasycznej architektury:

Hardware
   |
   v
Hypervisor
   |
   +---- VM
   +---- VM
   +---- VM

otrzymujemy:

Physical Hardware
        |
        v
   L0 Hypervisor
        |
        v
      VM L1
        |
   +----+----+
   |         |
  VM L2     VM L2

L0 to fizyczny hypervisor, L1 to pierwsza warstwa VM, która sama zachowuje się jak host wirtualizacyjny, a L2 to VM uruchomiona wewnątrz L1.

Po co stosuje się Nested Virtualization?

Najczęstsze zastosowania to:

• testowanie hypervisorów,
• laboratoria edukacyjne,
• testowanie Hyper-V,
• testowanie KVM,
• środowiska CI/CD,
• testowanie Kubernetes,
• laboratoria cyberbezpieczeństwa,
• development infrastruktury cloud,
• symulowanie całych centrów danych.

Przykład:

Proxmox
   |
   +-- Ubuntu VM
          |
          +-- KVM
                |
                +-- VM
                +-- VM

Dzięki temu na jednym fizycznym serwerze można zbudować całe laboratorium wirtualizacyjne.

Klasyczna wirtualizacja

Normalnie mamy:

CPU
 |
 v
Hypervisor
 |
 +---- VM1
 +---- VM2
 +---- VM3

Hypervisor bezpośrednio korzysta z mechanizmów wirtualizacji procesora.

Przykładowo:

Intel VT-x
AMD-V

Nested Virtualization

W nested virtualization wygląda to inaczej:

Physical CPU
     |
     v
Hypervisor L0
     |
     v
VM L1
     |
   Hypervisor
     |
     v
VM L2

L0 musi przekazać VM L1 możliwość korzystania z odpowiednich mechanizmów sprzętowej wirtualizacji.

Co oznacza L0, L1 i L2?

To bardzo przydatny sposób myślenia o nested virtualization.

L0

Pierwszy hypervisor działający bezpośrednio na sprzęcie:

Hardware
   |
Hypervisor L0

Przykłady:

• Proxmox/KVM,
• Hyper-V,
• VMware ESXi.

L1

VM uruchomiona na L0, która sama działa jako hypervisor:

L0
 |
 +-- VM L1
       |
     Hypervisor

L2

VM uruchomiona przez hypervisor znajdujący się w L1:

L0
 |
 +-- L1 Hypervisor
       |
       +-- L2 VM

Przykład: Proxmox → KVM → VM

Możemy mieć:

Physical Server
       |
       v
   Proxmox VE
       |
       v
    Ubuntu VM
       |
       v
      KVM
       |
   +---+---+
   |       |
  VM1     VM2

Proxmox jest L0.

Ubuntu jest L1.

KVM jest hypervisorem działającym wewnątrz L1.

VM1 i VM2 są L2.

Nested Virtualization w Hyper-V

Microsoft Hyper-V również obsługuje nested virtualization.

Schemat:

Physical Server
      |
      v
Hyper-V
      |
      v
Windows Server VM
      |
      v
Hyper-V
      |
   +--+--+
   |     |
  VM1   VM2

Jest to bardzo przydatne w laboratoriach Microsoft.

Można np. stworzyć:

Physical Host
      |
   Hyper-V
      |
  Lab VM
      |
   Hyper-V
      |
 +----+----+
 |         |
 DC        Server

Nested Virtualization w KVM

W przypadku KVM mechanizm może wyglądać tak:

Hardware
   |
KVM L0
   |
VM L1
   |
KVM L1
   |
VM L2

Procesor musi udostępnić L1 odpowiednie możliwości wirtualizacyjne.

Na Intel będzie to związane z VMX/VT-x, a na AMD z SVM/AMD-V.

Jak to działa na CPU?

Bez nested virtualization:

Guest VM
   |
   v
Virtual CPU
   |
   v
Hypervisor
   |
   v
Physical CPU

Przy nested virtualization:

L2 Guest
   |
   v
L1 Hypervisor
   |
   v
L0 Hypervisor
   |
   v
Physical CPU

Problem polega na tym, że L1 hypervisor musi otrzymać możliwość wykonywania operacji związanych z wirtualizacją CPU.

VMCS i nested virtualization

Na Intel VT-x istotną rolę odgrywa VMCS (Virtual Machine Control Structure).

W uproszczeniu:

L0
 |
 +-- VMCS dla L1
 |
 +-- VMCS dla L2

L0 musi kontrolować stan wirtualizacji również wtedy, gdy L1 próbuje zarządzać L2.

To jeden z powodów, dla których nested virtualization jest bardziej skomplikowana niż zwykła wirtualizacja.

EPT i nested virtualization

W Intel środowisko często wykorzystuje również:

EPT – Extended Page Tables

Pozwalają one mapować:

Guest Virtual Address
        |
        v
Guest Physical Address
        |
        v
Host Physical Address

Przy nested virtualization pojawia się kolejna warstwa translacji:

L2 Virtual
     |
     v
L2 Physical
     |
     v
L1 Physical
     |
     v
L0 Physical

Dlatego nested virtualization wymaga dodatkowej pracy zarówno od CPU, jak i hypervisora.

Wydajność

Nested virtualization jest zwykle wolniejsza niż klasyczna wirtualizacja.

Porównanie:

Normal:

Hardware
   |
Hypervisor
   |
VM

vs.

Nested:

Hardware
   |
L0
   |
L1
   |
L2

Każda dodatkowa warstwa może zwiększyć:

• narzut CPU,
• opóźnienia,
• zużycie pamięci,
• złożoność I/O.

Czy L2 będzie działać tak samo szybko jak L1?

Nie.

Przykładowo:

L1 VM
→ bardzo dobra wydajność

L2 VM
→ dodatkowy narzut

Szczególnie może to być widoczne przy:

• intensywnym I/O,
• storage,
• sieci,
• dużej liczbie operacji VM exit,
• nested hypervisor workloads.

Dlatego nested virtualization jest przede wszystkim świetnym rozwiązaniem laboratoryjnym, a nie domyślną architekturą dla produkcyjnych workloadów.

Nested Virtualization a sieć

Możemy mieć kilka warstw wirtualnego networkingu:

L2 VM
 |
vNIC
 |
L1 Virtual Switch
 |
L1 vNIC
 |
L0 Virtual Switch
 |
Physical NIC

Czyli:

L2
 ↓
L1
 ↓
L0
 ↓
Physical Network

Może to być szczególnie interesujące w laboratoriach sieciowych.

Nested Virtualization a storage

Podobnie wygląda storage:

L2 VM
 |
Virtual Disk
 |
L1 Hypervisor
 |
Virtual Disk
 |
L0 Hypervisor
 |
Physical Storage

Mamy więc kilka warstw:

L2 filesystem
      ↓
L2 virtual disk
      ↓
L1 storage
      ↓
L1 virtual disk
      ↓
L0 storage
      ↓
Physical SSD

Dlatego wydajność storage może być wyraźnie niższa niż w klasycznej VM.

Nested Virtualization + Kubernetes

To bardzo popularny scenariusz laboratoryjny.

Przykład:

Physical Server
       |
    Proxmox
       |
   Ubuntu VM
       |
   Kubernetes
       |
 +-----+-----+
 |     |     |
 VM    VM    VM

Można dzięki temu testować:

• Kubernetes,
• KVM,
• container orchestration,
• networking,
• storage,
• HA.

Nested Virtualization + Kubernetes + KVM

Jeszcze ciekawszy przypadek:

Physical Server
       |
    Proxmox
       |
      VM
       |
   Kubernetes
       |
    KubeVirt
       |
      KVM
       |
   +---+---+
   |       |
  VM      VM

To pozwala testować platformy, które uruchamiają VM wewnątrz klastra Kubernetes.

Nested Virtualization w chmurze

Cloud provider może udostępnić VM z włączonymi funkcjami nested virtualization:

Cloud Hardware
      |
Cloud Hypervisor
      |
Cloud VM
      |
Customer Hypervisor
      |
Customer VM

Dzięki temu użytkownik może uruchomić własny hypervisor bez dostępu do fizycznego serwera.

Problem z bezpieczeństwem

Nested virtualization zwiększa złożoność systemu:

L2
 |
L1
 |
L0
 |
Hardware

Każda warstwa może zawierać:

• kernel,
• hypervisor,
• sterowniki,
• emulację urządzeń,
• mechanizmy wirtualizacji.

Więcej warstw oznacza większą powierzchnię błędów.

Dlatego w środowisku produkcyjnym należy bardzo dokładnie kontrolować:

✔ uprawnienia
✔ izolację
✔ IOMMU
✔ networking
✔ dostęp do management
✔ aktualizacje hypervisorów

Nested Virtualization a PCI Passthrough

Tutaj pojawia się istotne ograniczenie.

Możemy mieć:

L0
 |
PCI Device
 |
L1 VM
 |
L2 VM

ale przekazanie tego samego urządzenia przez kilka warstw może być problematyczne.

Przykładowo:

Physical GPU
     |
    VFIO
     |
    L1
     |
    VFIO ?
     |
    L2

Nie każde urządzenie i każda platforma obsługują taki scenariusz.

Dlatego nested virtualization najlepiej działa z urządzeniami wirtualnymi, a nie z przypadkowym „przepychaniem” fizycznego sprzętu przez wszystkie warstwy.

Nested Virtualization a SR-IOV

Podobny problem może wystąpić z SR-IOV.

Schemat:

Physical NIC
     |
    SR-IOV
     |
    VF
     |
    L1
     |
    L2

Możliwości zależą od platformy i sposobu udostępniania urządzenia.

W praktyce klasyczne VirtIO jest często znacznie prostsze:

L2
 |
VirtIO
 |
L1
 |
VirtIO
 |
L0
 |
NIC

Nested Virtualization a Live Migration

Im więcej warstw, tym bardziej skomplikowana jest migracja:

L0 Host A
   |
   L1 Hypervisor
      |
      L2 VM

przeniesienie całego środowiska oznacza zachowanie stanu:

L1 + L2

Dlatego nested hypervisor może ograniczać możliwości prostego live migration.

Nested Virtualization – idealne zastosowania

Najbardziej sensowne:

Laboratorium

Proxmox
 |
 +-- Hyper-V Lab
 |     |
 |    VM
 |
 +-- KVM Lab
       |
      VM

Nauka

Możesz bez dodatkowego sprzętu testować:

Hyper-V
KVM
VMware
Kubernetes
OpenStack

Development

Developer Laptop
      |
      v
VM
      |
      v
Kubernetes / KVM

CI/CD

Pipeline może tworzyć tymczasowe VM:

CI Runner
   |
   v
L1 VM
   |
   v
L2 Test VM

Nested Virtualization – czego unikać?

Nie jest to idealny wybór dla:

❌ wymagających baz danych
❌ bardzo szybkiego storage
❌ low-latency networking
❌ HPC
❌ GPU production workloads
❌ maksymalnie wydajnych aplikacji

Jeżeli możesz uruchomić workload bezpośrednio na L1, zazwyczaj będzie to prostsze i wydajniejsze.

Najprostszy przykład

Załóżmy serwer:

AMD EPYC
   |
   v
Proxmox
   |
   v
Ubuntu VM

W Ubuntu włączamy KVM.

Następnie:

Ubuntu VM
   |
   v
KVM
   |
   +---- VM1
   +---- VM2
   +---- VM3

Mamy więc:

Hardware
    ↓
Proxmox (L0)
    ↓
Ubuntu (L1)
    ↓
KVM (L1 Hypervisor)
    ↓
VM1/VM2/VM3 (L2)

Pełna architektura

                         PHYSICAL HARDWARE
                                |
                                v
                         CPU VT-x / AMD-V
                                |
                                v
                         HYPERVISOR L0
                                |
                 +--------------+--------------+
                 |                             |
              VM L1                         VM L1
                 |                             |
           Hypervisor L1                Applications
                 |
        +--------+--------+
        |        |        |
      VM L2    VM L2    VM L2
        |        |        |
       App      App      App

Nested Virtualization vs zwykła VM

Najważniejsze do zapamiętania

Nested Virtualization

Hardware
   ↓
L0 Hypervisor
   ↓
L1 VM
   ↓
L1 Hypervisor
   ↓
L2 VM

Najważniejsza idea: L1 nie jest już zwykłą maszyną wirtualną — otrzymuje możliwość działania jak hypervisor i może tworzyć własne VM.

W praktyce Nested Virtualization jest świetnym narzędziem do budowania laboratoriów bez kupowania kolejnych serwerów. Na jednym Proxmoxie możesz na przykład postawić Hyper-V, a w nim kolejne maszyny Windows/Linux, albo uruchomić KVM i testować kolejne warstwy infrastruktury. Ceną jest dodatkowy narzut wydajności i większa złożoność.

Polecane wpisy

Jak skonfigurować passthrough urządzeń PCI do maszyny wirtualnej?

🛠️ Jak skonfigurować passthrough urządzeń PCI do maszyny wirtualnej? 🔍 Czym jest PCI passthrough? Wirtualizacja pozwala uruchamiać wiele systemów operacyjnych Czytaj dalej

Historia Wirtualizacji: Od Mainframe’ów po Chmurę

📜 Historia Wirtualizacji: Od Mainframe'ów po Chmurę Wirtualizacja to technologia, która całkowicie zrewolucjonizowała świat IT. Jej historia sięga czasów, kiedy Czytaj dalej