Xen / KVM / QEMU (wsparcie open-source hypervisorów)

Zgodność z Xen/KVM/QEMU oznacza wsparcie sprzętu dla tych otwartoźródłowych hypervisorów, wykorzystywanych w wirtualizacji.

Trzy elementy stosu wirtualizacji open source

Xen, KVM i QEMU są powiązanymi, ale odrębnymi elementami środowiska wirtualizacji. Xen jest hypervisorem typu 1, uruchamianym bezpośrednio na sprzęcie. Udostępnia maszynom wirtualnym izolowane domeny, w tym uprzywilejowaną domenę dom0, która zwykle zapewnia sterowniki oraz narzędzia zarządzające. KVM, czyli Kernel-based Virtual Machine, jest modułem jądra Linuksa wykorzystującym mechanizmy wirtualizacji procesora. Po załadowaniu modułów kvm oraz odpowiedniego modułu producenta procesora, takiego jak kvm-intel albo kvm-amd, system Linux może działać jako hypervisor.

QEMU jest emulatorem i wirtualizatorem sprzętu. W konfiguracji z KVM QEMU dostarcza między innymi emulowane chipsety, kontrolery dysków, karty sieciowe, firmware oraz urządzenia prezentowane gościowi, natomiast KVM wykonuje uprzywilejowane instrukcje procesora z użyciem sprzętowej wirtualizacji. Samo QEMU może również emulować procesor programowo, lecz taki tryb jest zwykle znacznie wolniejszy od wykonania wspieranego przez KVM. Zgodność komputera z tym stosem zależy więc nie tylko od nazwy procesora, ale także od ustawień firmware, jądra systemu, sterowników i konfiguracji urządzeń.

Rozszerzenia procesora wymagane przez hypervisor

Podstawowym warunkiem wydajnej wirtualizacji x86 jest obecność rozszerzeń sprzętowych Intel VT-x albo AMD-V. W systemach Intel funkcja ta może być opisywana w ustawieniach UEFI jako Intel Virtualization Technology, a w systemach AMD jako SVM Mode lub AMD-V. Jeżeli funkcja jest wyłączona w firmware, system operacyjny może wykrywać odpowiedni procesor, lecz KVM nie będzie mógł wykorzystać sprzętowego trybu wirtualizacji. W Linuksie obecność flag procesora można sprawdzić w pliku /proc/cpuinfo, a dostępność akceleracji KVM często weryfikuje się narzędziem kvm-ok z pakietu cpu-checker, jeżeli jest ono dostępne w danej dystrybucji.

Ważne są także funkcje związane z zarządzaniem pamięcią i przerwaniami, między innymi EPT w procesorach Intel oraz NPT w procesorach AMD. Ułatwiają one translację adresów używanych przez system gościa i ograniczają koszt obsługi pamięci wirtualnej. W przypadku przekazywania urządzenia bezpośrednio do maszyny wirtualnej potrzebne są mechanizmy IOMMU: Intel VT-d albo AMD-Vi. Sama obecność IOMMU nie gwarantuje jeszcze poprawnego passthrough. Znaczenie ma również podział urządzeń na grupy IOMMU, obsługa przez sterownik hosta oraz możliwość odłączenia urządzenia od hosta i przypisania go do gościa.

Kompatybilność urządzeń i systemu gościa

Procesor z VT-x lub AMD-V jest niezbędny do akcelerowanej wirtualizacji, ale nie rozwiązuje wszystkich problemów sprzętowych. Istotna jest ilość dostępnej pamięci RAM, liczba rdzeni, możliwości kontrolera dysków oraz przepustowość urządzeń wejścia-wyjścia. Maszyna wirtualna może korzystać z emulowanych urządzeń zgodnych z popularnymi kontrolerami, na przykład virtio dla dysku i sieci, albo z urządzeń przekazanych bezpośrednio przez PCI passthrough. Sterowniki virtio muszą być dostępne w systemie gościa; bez nich gość może nie rozpoznać wirtualnego dysku lub interfejsu sieciowego.

Xen obsługuje różne modele uruchamiania gości, w tym wirtualizację sprzętową oraz parawirtualizację. KVM z QEMU może prezentować gościowi między innymi procesor o modelu ograniczonym do wspólnego zestawu funkcji albo model bardziej zbliżony do procesora hosta. Wybór wpływa na przenośność konfiguracji między komputerami oraz dostępność określonych instrukcji CPU. Przy migracji maszyny wirtualnej między hostami nie powinno się zakładać, że każdy model procesora zapewni identyczny zestaw funkcji. W praktyce trzeba porównać flagi CPU, wersję hypervisora, model urządzeń wirtualnych i wymagania systemu gościa.

Rozpoznawanie problemów z uruchomieniem wirtualizacji

Brak możliwości uruchomienia Xen albo KVM może wynikać z wyłączonej funkcji w UEFI, ograniczeń firmware, niezaładowanych modułów jądra lub uruchomienia hypervisora wewnątrz innej maszyny wirtualnej bez włączonej wirtualizacji zagnieżdżonej. W Linuksie przydatne są polecenia lsmod | grep kvm, lscpu oraz dmesg, ale ich wynik trzeba interpretować w kontekście konkretnego procesora i jądra. QEMU może działać bez KVM, lecz komunikat o niedostępnej akceleracji oznacza przejście do emulacji programowej, a nie pełną zgodność z wydajnym trybem wirtualizacji.

Diagnostyka powinna obejmować również aktualność UEFI, ustawienia IOMMU, mapowanie grup PCI, sterowniki urządzeń oraz stan nośnika danych. Objawy takie jak zawieszanie gościa, błędy podczas startu, brak sieci albo niedostępny dysk nie muszą oznaczać uszkodzenia procesora. Mogą wskazywać na niezgodny model urządzenia wirtualnego, brak sterownika virtio, konflikt z urządzeniem używanym przez hosta albo niewystarczające zasoby pamięci i procesora. Przy ocenie zgodności Xen/KVM/QEMU należy zatem sprawdzić cały łańcuch: sprzęt, firmware, system hosta, hypervisor, QEMU, sterowniki oraz konfigurację systemu gościa.