VirtIO – jak działa parawirtualizacja urządzeń w maszynach wirtualnych
VirtIO to standardowy mechanizm parawirtualizowanych urządzeń używany wirtualizacji Linux/KVM, QEMU, Proxmox i wielu innych platformach.
Zamiast emulować prawdziwy sprzęt, hypervisor udostępnia VM wydajne, uproszczone urządzenie zaprojektowane specjalnie dla środowiska wirtualnego.
Najprościej:
VM
|
v
VirtIO Device
|
v
QEMU / Hypervisor
|
v
Physical Hardware
VirtIO jest jednym z podstawowych powodów, dla których nowoczesne VM mogą osiągać bardzo dobrą wydajność bez konieczności stosowania PCI Passthrough.
Po co powstało VirtIO?
Klasyczna emulacja sprzętu wygląda np. tak:
VM
|
v
Emulated Intel NIC
|
v
QEMU
|
v
Physical NIC
VM myśli, że korzysta z prawdziwej karty Intel, a QEMU musi emulować jej zachowanie.
To zapewnia kompatybilność, ale generuje dodatkowy narzut.
VirtIO upraszcza ścieżkę:
VM
|
v
virtio-net
|
v
QEMU / Host
|
v
Physical NIC
Guest OS wie, że pracuje w środowisku wirtualnym i korzysta ze specjalnego sterownika VirtIO.
VirtIO jest standardem
VirtIO nie oznacza jednego urządzenia.
To rodzina urządzeń:
virtio-net
virtio-blk
virtio-scsi
virtio-fs
virtio-rng
virtio-balloon
virtio-console
virtio-gpu
Każde odpowiada za inną funkcję.
VirtIO Network
virtio-net zapewnia wirtualną kartę sieciową.
Schemat:
VM
|
virtio-net
|
v
Virtual Switch
|
v
Physical NIC
|
v
Network
To bardzo popularna konfiguracja w KVM i Proxmox.
VirtIO Block
virtio-blk udostępnia VM wirtualne urządzenie blokowe.
VM
|
virtio-blk
|
QEMU
|
Virtual Disk
|
Physical Storage
Guest OS widzi je jako urządzenie blokowe.
VirtIO SCSI
Alternatywą jest:
virtio-scsi
Jest szczególnie użyteczne w bardziej rozbudowanych konfiguracjach storage.
Schemat:
VM
|
VirtIO SCSI Controller
|
+---- Disk 1
+---- Disk 2
+---- Disk 3
Pozwala wygodnie obsługiwać wiele dysków i funkcje związane z hotplugiem.
VirtIO vs emulowany SATA
Przykładowo:
Emulated SATA
VM
|
SATA Controller
|
QEMU
|
Disk
vs.
VirtIO
VM
|
virtio-scsi
|
QEMU
|
Disk
VirtIO zwykle oznacza mniejszy narzut i lepszą wydajność w środowisku wirtualnym.
VirtIO-FS
virtio-fs pozwala udostępniać katalog pomiędzy hostem a VM.
Schemat:
Host
|
/shared
|
v
virtio-fs
|
v
VM
|
/mnt/shared
Jest szczególnie przydatne wtedy, gdy VM musi pracować na danych znajdujących się na hoście.
VirtIO RNG
virtio-rng udostępnia VM źródło entropii.
Host
|
Random Number Generator
|
v
virtio-rng
|
v
Guest OS
Może być istotne podczas startu systemu oraz operacji kryptograficznych.
VirtIO Balloon
virtio-balloon umożliwia dynamiczne zarządzanie pamięcią VM.
Schemat:
Host
|
+---- VM1
|
+---- VM2
|
+---- VM3
Hypervisor może współpracować z guestem w celu odzyskiwania części nieużywanej pamięci.
Mechanizm nie jest jednak tym samym co zwykłe „dynamiczne RAM” i powinien być rozpatrywany w kontekście konkretnego workloadu.
VirtIO Console
virtio-console zapewnia wirtualny kanał komunikacyjny między hostem a guestem.
Może być używany np. do:
Host
|
virtio-console
|
VM
i komunikacji związanej z usługami wirtualizacji.
VirtIO GPU
Istnieje również virtio-gpu, które zapewnia wirtualną grafikę.
VM
|
virtio-gpu
|
QEMU
|
Host GPU
To jednak zupełnie inny model niż:
PCI Passthrough
gdzie fizyczna karta jest przekazywana bezpośrednio do VM.
VirtIO i Virtqueues
Jednym z najważniejszych elementów architektury VirtIO są virtqueues.
Można je uprościć do:
Guest Driver
|
v
Virtqueue
|
v
Host / Device Backend
Virtqueue jest mechanizmem przekazywania buforów pomiędzy guestem a urządzeniem.
Dzięki temu nie trzeba emulować całego zachowania fizycznego urządzenia.
Split vs Packed Virtqueue
W nowoczesnym VirtIO spotkasz dwa modele kolejek:
Split Virtqueue
oraz:
Packed Virtqueue
Historycznie używany jest przede wszystkim model split, natomiast packed został zaprojektowany m.in. w celu zmniejszenia narzutu i liczby operacji związanych z obsługą kolejki.
Schematycznie:
Guest
|
v
Virtqueue
|
v
VirtIO Device
VirtIO i DMA
VirtIO może korzystać z mechanizmów DMA, ale sposób mapowania pamięci zależy od konkretnej implementacji i platformy.
W nowoczesnym środowisku wirtualizacyjnym istotną rolę mogą odgrywać:
IOMMU
DMA
vIOMMU
Przy czym VirtIO nie jest tym samym co PCI Passthrough.
VirtIO vs PCI Passthrough
To jedno z najważniejszych porównań.
VirtIO
VM
|
VirtIO
|
Hypervisor
|
Physical Device
PCI Passthrough
VM
|
VFIO
|
Physical PCIe Device
VirtIO zapewnia większą abstrakcję.
PCI Passthrough daje bardziej bezpośredni dostęp do sprzętu.
VirtIO vs SR-IOV
Podobnie wygląda porównanie z SR-IOV.
VirtIO:
VM
|
virtio-net
|
Host
|
NIC
Natomiast:
SR-IOV:
VM
|
VF
|
NIC
W uproszczeniu:
| Cecha | VirtIO | SR-IOV |
|---|---|---|
| Wydajność | bardzo dobra | bardzo wysoka |
| Elastyczność | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Wymaga specjalnego NIC | ❌ | ✅ |
| Virtual switch | ✅ | ograniczona ścieżka danych |
| Migracja VM | łatwiejsza | trudniejsza |
| Zarządzanie | prostsze | bardziej złożone |
VirtIO w KVM/QEMU
Typowy stos wygląda tak:
Guest OS
|
VirtIO Driver
|
VirtIO Device
|
QEMU
|
KVM
|
Linux Kernel
|
Hardware
Warto zauważyć, że KVM i VirtIO rozwiązują różne problemy.
KVM
→ wirtualizacja CPU
QEMU
→ model VM i urządzenia
VirtIO
→ wydajne urządzenia parawirtualne
VirtIO w Proxmox
W Proxmox VE VirtIO jest bardzo często najlepszym wyborem dla standardowych VM.
Przykładowa maszyna:
VM
|
+-- CPU
|
+-- RAM
|
+-- virtio-scsi disk
|
+-- virtio-net NIC
|
+-- virtio-rng
Zamiast emulować:
Intel e1000
LSI SCSI
SATA
można korzystać z urządzeń VirtIO.
VirtIO w Windows
Linux ma bardzo dobrą obsługę VirtIO.
Windows również może korzystać z VirtIO, ale wymaga odpowiednich sterowników.
Przykładowo:
Windows VM
|
+-- VirtIO Network Driver
|
+-- VirtIO Storage Driver
W środowisku Proxmox często korzysta się z obrazu VirtIO ISO, zawierającego sterowniki dla Windows.
VirtIO i Linux
W Linuxie sterowniki VirtIO są częścią kernela.
Możemy zobaczyć urządzenia:
lspci
Przykładowo:
Virtio network device
Virtio block device
Virtio SCSI
Moduły mogą mieć nazwy:
virtio
virtio_pci
virtio_net
virtio_blk
virtio_scsi
VirtIO Networking
Typowa ścieżka sieciowa w Proxmox może wyglądać tak:
VM
|
virtio-net
|
v
tap/vnet
|
v
vmbr0
|
v
Physical NIC
|
v
Network
To daje bardzo dobry kompromis pomiędzy wydajnością a elastycznością.

VirtIO i Linux Bridge
Przykładowo:
vmbr0
|
+---------+---------+
| | |
VM1 VM2 VM3
| | |
virtio virtio virtio
NIC NIC NIC
Każda VM posiada własną wirtualną kartę.
VirtIO i Open vSwitch
W bardziej zaawansowanych środowiskach VirtIO może współpracować również z:
Open vSwitch
Schemat:
VM
|
virtio-net
|
Open vSwitch
|
Physical NIC
To pozwala budować bardziej zaawansowane topologie sieciowe.
VirtIO multiqueue
W przypadku szybkich kart sieciowych jedna kolejka może stać się ograniczeniem.
VirtIO może korzystać z wielu kolejek:
VM
|
virtio-net
|
+------+------+------+
| | | |
Q1 Q2 Q3 Q4
| | | |
CPU1 CPU2 CPU3 CPU4
Dzięki temu ruch może być rozłożony na wiele CPU.
To jest szczególnie istotne przy:
10 GbE
25 GbE
40 GbE
100 GbE
oraz przy workloadach generujących dużą liczbę pakietów.
VirtIO i vhost
W Linux/KVM często spotkasz:
vhost-net
Jego celem jest przeniesienie części obsługi virtio-net z procesu QEMU do kernela.
Schemat:
VM
|
virtio-net
|
v
vhost-net
|
v
Linux
|
v
NIC
Może to zmniejszyć narzut związany z przetwarzaniem pakietów w QEMU.
vhost-user
W bardziej zaawansowanych rozwiązaniach istnieje również:
vhost-user
W tym modelu backend VirtIO może znajdować się poza kernelem, np. w aplikacji użytkownika.
Jest to często spotykane w zaawansowanych dataplane’ach i rozwiązaniach wykorzystujących DPDK.
Schemat:
VM
|
VirtIO
|
vhost-user
|
DPDK application
|
NIC
VirtIO i wydajność
VirtIO jest kompromisem:
Wydajność
PCI Passthrough ██████████
SR-IOV ██████████
VirtIO █████████
Emulation ██████
Natomiast pod względem elastyczności często wygląda to odwrotnie:
Elastyczność
VirtIO ██████████
Emulation █████████
SR-IOV ██████
PCI Passthrough ████
To oczywiście obraz poglądowy, a nie benchmark.
Dlaczego VirtIO jest tak popularne?
Ponieważ rozwiązuje bardzo ważny problem:
Jak uzyskać wysoką wydajność bez uzależniania VM od konkretnego fizycznego urządzenia?
Odpowiedzią jest:
VirtIO
VM nie musi wiedzieć:
czy host ma Intel NIC,
AMD NIC,
Mellanox,
Broadcom,
Guest widzi:
virtio-net
a host może mieć praktycznie dowolny kompatybilny sprzęt.
VirtIO a migracja VM
To ogromna zaleta.
Przykład:
Host A
|
VM
|
virtio-net
|
Live Migration
|
v
Host B
|
VM
|
virtio-net
Urządzenie jest wirtualne, więc nie musi istnieć identyczna fizyczna karta na obu hostach.
Dlatego VirtIO bardzo dobrze pasuje do:
HA
Clusters
Live Migration
Cloud
Proxmox
OpenStack
VirtIO w chmurze
VirtIO jest szeroko wykorzystywane wirtualizacyjnych platformach cloud.
Typowy model:
Cloud VM
|
+-- virtio-net
|
+-- virtio-blk/scsi
|
+-- virtio-rng
Dzięki temu dostawca chmury nie musi emulować klasycznych urządzeń dla każdej VM.
VirtIO a bezpieczeństwo
VirtIO zapewnia abstrakcję urządzenia, ale nadal istnieje granica:
Guest
|
VirtIO Driver
|
QEMU / Backend
|
Host
Dlatego bezpieczeństwo zależy również od:
- kernela,
- QEMU,
- sterowników,
- konfiguracji hypervisora,
- izolacji VM,
- mechanizmów sandboxingu.
Błąd w obsłudze urządzenia wirtualnego może potencjalnie stać się elementem ataku typu VM escape.
VirtIO – pełna architektura
PHYSICAL HOST
|
+---------+---------+
| |
KVM QEMU
| |
| +------+------+
| | |
| virtio-net virtio-scsi
| | |
+------------+-------------+
|
Guest VM
|
+------------+------------+
| |
Network Driver Storage Driver
| |
virtio-net virtio-scsi
VirtIO vs trzy główne modele
Można to zapamiętać bardzo prosto:
EMULATION
VM
|
Virtual Intel NIC
|
QEMU
|
NIC
VIRTIO
VM
|
virtio-net
|
QEMU / vhost
|
NIC
PCI PASSTHROUGH
VM
|
VFIO
|
Physical NIC
A pomiędzy VirtIO i passthrough znajduje się często:
SR-IOV
VM
|
VF
|
Physical NIC
Najważniejsze do zapamiętania
VirtIO
→ parawirtualizowane urządzenia dla VM
virtio-net
→ sieć
virtio-blk
→ dyski blokowe
virtio-scsi
→ kontroler storage
virtio-fs
→ współdzielenie filesystemu
virtio-rng
→ źródło entropii
virtio-balloon
→ współpraca przy zarządzaniu pamięcią
vhost-net
→ wydajniejszy backend sieciowy w kernelu
vhost-user
→ backend VirtIO w userspace
Jeżeli PCI Passthrough jest podejściem „daj VM prawdziwe urządzenie”, a SR-IOV jest podejściem „daj VM sprzętową Virtual Function”, to VirtIO jest podejściem „daj VM szybkie urządzenie zaprojektowane specjalnie dla wirtualizacji”.
I właśnie dlatego VirtIO jest zazwyczaj najlepszym domyślnym wyborem dla zwykłych VM w KVM/Proxmox, gdy nie potrzebujesz maksymalnej wydajności PCI Passthrough ani SR-IOV.






