KVM vs Xen vs LXC: jak sprawdzić wirtualizację VPS

Co faktycznie oferuje plan VPS

KVM, Xen oraz LXC to trzy rodziny wirtualizacji, na których opierają się plany VPS, a wybór między nimi nie jest jedynie kwestią techniczną infrastruktury dostawcy. Decyduje on o tym, czy użytkownik otrzymuje własne jądro systemu. Wszystkie kluczowe dla nabywcy aspekty wynikają z tego jednego faktu: ładowanie modułów, zarządzanie swap, uruchamianie wirtualizacji zagnieżdżonej, to czy /proc opisuje własny serwer czy serwer innego użytkownika, oraz czy czas steal time jest w ogóle mierzalny.

Pełna wirtualizacja (KVM oraz Xen HVM) zapewnia każdemu użytkownikowi własne jądro oraz maszynę wirtualną. Parawirtualizacja Xen również udostępnia jądro, jednak jest ono świadome bycia gościem i zleca hiperwizorowi wykonywanie operacji uprzywilejowanych. Plan oparty na kontenerach (LXC lub rodzina OpenVZ i Virtuozzo) dostarcza system plików oraz zestaw przestrzeni nazw (namespaces) działających na jądrze systemu dostawcy. Wszystkie trzy rozwiązania są sprzedawane pod tym samym skrótem.

KVM a Xen a LXC: własne jądro czy współdzielone jądro

W przypadku KVM oraz Xen, uname -r definiuje używane jądro systemu. Można zainstalować inne jądro, załadować do niego moduł i wykonać restart. Żadne z tych działań nie wpływa na innych użytkowników. W planach opartych na kontenerach, uname -r definiuje jądro dostawcy, działające na hoście i współdzielone ze wszystkimi innymi kontenerami na tej maszynie. Nie można go zmienić, a apt install linux-image-generic rozpakuje pliki, które nigdy się nie uruchomią.

Ta pojedyncza różnica jest ważniejsza niż jakakolwiek specyfikacja techniczna. Dalszą część tego przewodnika należy czytać przez pryzmat jej konsekwencji.

Pełna wirtualizacja: KVM oraz Xen HVM

KVM (kernel-based virtual machine) to moduł wewnątrz jądra Linux, który przekształca zwykły host z systemem Linux w hiperwizor, wykorzystując instrukcje Intel VT-x lub AMD-V wbudowane w procesor. QEMU dostarcza otaczający go wirtualny sprzęt: dysk, kartę sieciową oraz konsolę szeregową. Xen ma inną architekturę. Xen jest samodzielnym hiperwizorem i uruchamia się przed systemem Linux. Uprzywilejowana domena sterująca, zwana dom0, obsługuje stos zarządzania, a każdy klient to domU. Xen HVM (hardware virtual machine) wykorzystuje te same rozszerzenia procesora co KVM, zazwyczaj ze sterownikami parawirtualizacyjnymi dla dysku i sieci, ponieważ emulowany sprzęt jest wolny. Takie połączenie nazywane jest PVHVM.

Z punktu widzenia klienta oba rozwiązania działają niemal identycznie. Użytkownik otrzymuje jądro, program rozruchowy, rzeczywiste urządzenie blokowe, działające modprobe, pełnoprawne /proc, własną przestrzeń wymiany (swap) oraz możliwość wykonania restartu, który faktycznie uruchamia system ponownie. Jeśli dostawca umożliwia podpięcie pliku ISO, można zainstalować dystrybucję, która nie znajdowała się w standardowej ofercie.

Ceną za to jest mniejsza gęstość upakowania maszyn. Przydzielone 4 GB pamięci RAM jest zarezerwowane dla danej maszyny i nie może zostać użyczone sąsiadowi, gdy zasoby pozostają bezczynne. Każdy gość utrzymuje proces QEMU, własne tablice stron oraz własną pamięć podręczną stron. Ten koszt sprawia, że plany KVM są wyżej wyceniane niż plany oparte na kontenerach o tych samych parametrach.

Parawirtualizacja Xen i sposoby jej rozpoznawania

Xen PV powstał przed wprowadzeniem instrukcji wirtualizacji w procesorach. Zamiast przechwytywać instrukcje uprzywilejowane, jądro gościa jest modyfikowane w celu bezpośredniego wywoływania hypervisora. Działa ono bez wsparcia VT-x, co było głównym założeniem w 2005 roku. Jądro jest ładowane z obrazu dysku przez pygrub lub pvgrub, więc jest to własne jądro użytkownika, ale musi być skompilowane z obsługą gościa PV.

Oznaki pracy w tym środowisku: lscpu raportuje typ wirtualizacji jako para zamiast full, plik /sys/hypervisor/type istnieje i wskazuje na Xen, a dyski są typu xvda zamiast vda lub sda. Narzędzia odczytujące tablice SMBIOS lub DMI nie znajdują żadnych danych, ponieważ gość PV nie posiada firmware'u, który mógłby je opublikować.

Koszt tego rozwiązania to trwała utrata możliwości wirtualizacji zagnieżdżonej. Gość PV nigdy nie otrzymuje dostępu do rozszerzeń wirtualizacji procesora, więc wewnątrz niego nie może działać żaden hypervisor. Sam Xen nie jest martwy. Xen PV to konkretny element, który stracił na znaczeniu, a kierunek rozwoju projektu przesunął się w stronę PVH oraz HVM. Jeśli oferta zawiera hasło "Xen", należy dopytać o jego typ. HVM to standardowy, nowoczesny VPS. PV to plan, który powinien być wyceniony niżej.

VPS kontenerowy: LXC i linia OpenVZ

VPS kontenerowy to zestaw przestrzeni nazw Linux (odrębne widoki identyfikatorów procesów, punktów montowania, interfejsów sieciowych, nazwy hosta i użytkowników) oraz cgroups (grupy kontrolne, czyli limity zasobów narzucane przez jądro systemu) działający na jądrze dostawcy. Twój init jest procesem na hoście. Twój ls działa bezpośrednio na jądrze hosta, bez emulacji i bez dodatkowego szeregowania zadań. Dlatego kontenery są szybkie i pozwalają na duże zagęszczenie.

Nazwy widoczne w ofertach to LXC, kontenery Proxmox VE (które są oparte na LXC), OpenVZ oraz Virtuozzo. OpenVZ 7 i Virtuozzo to komercyjni spadkobiercy tej samej koncepcji.

Cztery aspekty ulegają zmianie:

• Moduły. modprobe nie załaduje żadnego modułu. Jeśli WireGuard, ZFS lub konkretny moduł netfilter nie znajdują się już w jądrze dostawcy, nie będziesz mógł z nich korzystać.
• sysctl. Większość /proc/sys jest dostępna tylko do odczytu. Sieć stanowi odrębną przestrzeń nazw, więc net.ipv4.ip_forward i powiązane pliki są zazwyczaj zapisywalne. Parametry systemowe, takie jak vm.swappiness lub fs.file-max, należą do hosta.
• Zagnieżdżone kontenery. Docker wewnątrz kontenera LXC działa tylko wtedy, gdy dostawca włączył obsługę zagnieżdżania (nesting), a sterownik pamięci masowej na to pozwala. Przetestuj to przed zakupem, zamiast zakładać, że będzie działać.
• Wersja jądra. Dziedziczysz harmonogram aktualizacji dostawcy, w tym wymuszone restarty.

Jak sprawdzić zakupioną wersję

Uruchom poniższe polecenia na serwerze i przeanalizuj wyniki łącznie. Żadne pojedyncze polecenie nie daje jednoznacznej odpowiedzi.

systemd-detect-virt
systemd-detect-virt -c
lscpu | grep -iE 'hypervisor|virtualization'
uname -r
ls /lib/modules/$(uname -r) 2>/dev/null | head -n 3
cat /sys/hypervisor/type 2>/dev/null

systemd-detect-virt wypisuje jeden krótki identyfikator ze stałego słownika. Po stronie maszyny wirtualnej wynik obejmuje kvm, qemu, xen, amazon oraz vmware. Po stronie kontenera wynik obejmuje lxc, lxc-libvirt, openvz, docker oraz systemd-nspawn. W przypadku braku wykrycia środowiska polecenie wypisuje none i kończy działanie z kodem wyjścia innym niż zero. Forma -c odpowiada wyłącznie dla technologii kontenerowych, więc każda odpowiedź inna niż none w tym przypadku rozstrzyga kwestię, niezależnie od zapewnień na stronie sprzedawcy.

lscpu podaje dostawcę hypervisora i określa, czy typ wirtualizacji to full czy para, co pozwala odróżnić Xen HVM od Xen PV. Polecenie /sys/hypervisor/type istnieje tylko w środowisku Xen.

Weryfikacja /lib/modules jest często pomijana, a jest najbardziej bezpośrednia. Jeśli katalog dla uruchomionej wersji jądra nie istnieje lub jest pusty, mimo że system ewidentnie działa na tym jądrze, oznacza to, że jądro nie pochodzi z Twojego systemu plików. Pochodzi ono z hosta, a jego drzewo modułów nigdy nie zostało zainstalowane w Twoim obrazie. Jest to kontener.

Dla uzyskania niezależnej, dodatkowej opinii, sudo apt install -y virt-what && sudo virt-what uruchamia testy wykrywania jako dedykowane narzędzie. Wymaga uprawnień root i nie wypisuje żadnych informacji w przypadku pracy na fizycznym sprzęcie (bare metal).

Dlaczego /proc wskazuje błędne dane o maszynie w kontenerze

W przypadku gościa KVM lub Xen, /proc/meminfo stanowi rozliczenie pamięci przydzielonej przez hypervisor, prowadzone przez własne jądro systemu. Dane te dotyczą maszyny wirtualnej i nie informują o stanie hosta. Jest to podstawowe założenie wirtualizacji.

W kontenerze nie występuje drugie jądro odpowiedzialne za to rozliczenie, dlatego /proc odnosi się do /proc hosta. LXCFS to niewielki system plików, który nadpisuje niektóre z tych plików, aby odpowiadały limitom cgroup; obejmuje on /proc/cpuinfo, /proc/meminfo, /proc/stat, /proc/uptime, /proc/swaps, /proc/diskstats oraz /sys/devices/system/cpu/online. Proxmox montuje go domyślnie. Wielu mniejszych dostawców tego nie robi, przez co free -m raportuje całkowitą pamięć hosta, nproc może wykazywać wszystkie rdzenie maszyny, a uptime wskazuje czas pracy hosta.

Nie jest to problem wyłącznie kosmetyczny, ponieważ oprogramowanie dobiera parametry pracy na podstawie tych plików. nginx z flagą worker_processes auto zlicza widoczne rdzenie. make -j$(nproc) na hoście z 64 rdzeniami i limitem 2 rdzeni uruchomi 64 kompilatory. JVM lub baza danych, która dobiera rozmiar pamięci podręcznej na podstawie MemTotal, wybierze wartość, której cgroup nie zaakceptuje, co doprowadzi do przerwania procesu przez jądro po osiągnięciu limitu. Informacja o tym przerwaniu trafia do dziennika jądra hosta, do którego użytkownik nie ma dostępu.

Wiarygodne dane znajdują się w cgroup, a nie w /proc:

cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/cpu.max

Są to ścieżki cgroup v2, stosowane w aktualnych dystrybucjach. memory.max odczytujące max oznacza brak limitu na tym poziomie. cpu.max wyświetla kwotę i okres w mikrosekundach, zatem 200000 100000 oznacza dwa rdzenie czasu procesora na okres. Na starszych hostach z cgroup v1 te same wartości znajdują się w /sys/fs/cgroup/memory/memory.limit_in_bytes oraz /sys/fs/cgroup/cpu/cpu.cfs_quota_us.

Swap i kwestia jego własności

W środowiskach KVM i Xen swap należy do użytkownika. Jest to plik lub partycja na dysku, a stronicowanie obsługuje własne jądro systemu.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
swapon --show

Polecenie swapon --show powinno teraz wyświetlić plik wraz z jego rozmiarem i priorytetem. Jeśli swapon odrzuci plik, należy utworzyć go za pomocą dd if=/dev/zero of=/swapfile bs=1M count=2048, ponieważ pliki prealokowane z niezapisanymi zakresami (extents) są odrzucane przez niektóre systemy plików. Należy dodać /swapfile none swap sw 0 0 do /etc/fstab, w przeciwnym razie swap zniknie po następnym restarcie.

W kontenerze nic z powyższych nie należy do użytkownika. swapon wymaga uprawnień, których nieposiadający przywilejów kontener nie posiada, więc próba utworzenia własnego pliku wymiany kończy się błędem uprawnień i nie dociera do dysku. To, co w planach określa się mianem swap, jest ustawieniem cgroup na hoście, memory.swap.max w ramach cgroup v2, wspieranym przez urządzenia wymiany samego hosta. Starsze plany OpenVZ oferowały przydział "vswap", który zachowywał się bardziej jak kredyt na nagłe skoki zapotrzebowania niż jak dysk. Można odczytać limit, ale nie posiada się kontroli nad urządzeniem, które się pod nim znajduje.

Wirtualizacja zagnieżdżona i myląca flaga procesora

Wirtualizacja zagnieżdżona oznacza uruchomienie hiperwizora wewnątrz VPS: gościa QEMU, środowiska Vagrant lub laboratorium wirtualizacji zagnieżdżonej z własnymi maszynami wirtualnymi. Muszą zostać spełnione dwa warunki. Dostawca musi włączyć obsługę zagnieżdżania na hoście, a gość musi otrzymać dostęp do rozszerzeń wirtualizacji procesora.

lscpu | grep -i virtualization
ls -l /dev/kvm
sudo apt install -y cpu-checker && sudo kvm-ok

Na gościu KVM z włączonym zagnieżdżaniem istnieje /dev/kvm, a kvm-ok wprost informuje, czy można użyć akceleracji. W przypadku Xen HVM jest to technicznie możliwe, choć rzadko oferowane. W Xen PV jest to niemożliwe.

W kontenerze test kończy się niepowodzeniem w pouczający sposób. /proc/cpuinfo jest plikiem hosta, więc flaga vmx lub svm jest obecna i jest prawdziwa: fizyczny procesor pod spodem rzeczywiście posiada te instrukcje. Mimo to nie należą one do użytkownika. W przestrzeni nazw nie ma /dev/kvm, nie można załadować modułu kvm_intel, a odczytana flaga opisuje maszynę, na której użytkownik jest gościem, a nie maszynę, którą zarządza. Jest to najjaskrawszy przykład ogólnej zasady. W kontenerze /proc opisuje przestrzeń nazw i otaczający ją sprzęt, a nie serwer, którego użytkownik jest właścicielem.

AES-NI oraz funkcje procesora udostępniane przez plan

AES-NI (advanced encryption standard new instructions) to zestaw instrukcji procesora, dzięki którym szyfrowanie AES jest kilkukrotnie szybsze niż w przypadku obliczeń programowych. Terminacja TLS, szyfrowanie dysków, SSH oraz potoki kopii zapasowych korzystają z tego rozwiązania.

W środowisku KVM to, co widzi system gościa, zależy od modelu procesora skonfigurowanego przez dostawcę dla QEMU. Przy użyciu trybu host passthrough widoczne są rzeczywiste flagi. W przypadku modelu generycznego, takiego jak qemu64, lub celowo wybranej starszej bazy, aby umożliwić migrację gości między różnymi hostami, flaga aes może być nieobecna, a OpenSSL po cichu przełączy się na implementację programową.

lscpu | grep -ow aes | head -n 1
openssl speed -evp aes-128-gcm
env OPENSSL_ia32cap='~0x200000000000000:~0x20000000000:~0x0:~0x0:~0x0' openssl speed -evp aes-128-gcm

Trzecie polecenie to przykład z dokumentacji OpenSSL dotyczący wyłączania tych instrukcji wewnątrz biblioteki: czyści ono bit AES-NI oraz bit VAES, pozostawiając resztę bez zmian. Porównaj oba wyniki przepustowości. Jeśli wartości są zbliżone, oznacza to, że szybka ścieżka nie była wykorzystywana, a prawidłowe sprawdzenie AES-NI na VPS jest warte poświęcenia pięciu minut przed wyborem planu.

Kontener nie posiada warstwy modelu procesora, więc flagi w /proc/cpuinfo są rzeczywistymi flagami hosta i mają bezpośrednie zastosowanie. Jest to realna zaleta planów kontenerowych i jedyny przypadek w tym przewodniku, w którym współdzielone jądro działa na Twoją korzyść.

Skąd bierze się steal time i dlaczego kontenery go nie wykazują

Steal time to czas, w którym wirtualny procesor był gotowy do pracy, ale nie mógł jej podjąć, ponieważ hiperwizor obsługiwał w tym momencie inny proces. Wartość ta pojawia się jako st w narzędziach top i vmstat oraz jako ósme pole w linii cpu w pliku /proc/stat.

System gość nie jest w stanie samodzielnie zmierzyć tego czasu, ponieważ nie wykonuje żadnych operacji, gdy czas ten jest odbierany. Informację musi przekazać hiperwizor. KVM zapisuje sumaryczny czas w stronie pamięci zarejestrowanej przez gościa za pośrednictwem interfejsu parawirtualnego zegara, natomiast Xen utrzymuje dla tego celu obszar stanu dla każdego vCPU. Odczytywana wartość jest bezpośrednim raportem hiperwizora, dlatego istnieje i jest wiarygodna.

Wysoka wartość steal time oznacza, że host jest przeciążony, a sąsiednie maszyny wirtualne są w danej chwili aktywne. Jest to widoczny wskaźnik stosunku liczby sprzedanych vCPU do fizycznych rdzeni procesora, a odczytywanie steal time w celu wykrycia obciążającego sąsiada to jedyny pomiar, który pozwala zweryfikować, czy wydajność planu jest zgodna z deklaracjami dostawcy.

vmstat 1 5
cat /sys/fs/cgroup/cpu.stat

W kontenerze ta kolumna pozostaje niezmienna, ponieważ między procesami a schedulerem nie ma hiperwizora. Procesy kontenera są kolejkowane obok procesów innych użytkowników jako zwykłe zadania w schedulerze procesora hosta. Rywalizacja o zasoby objawia się po prostu dłuższym czasem wykonywania zadań, bez licznika wskazującego przyczynę. Najbliższym odpowiednikiem jest ograniczanie przydziału (quota throttling): gdy dostawca ustawia cpu.max, wówczas /sys/fs/cgroup/cpu.stat zlicza okresy nr_throttled oraz mikrosekundy throttled_usec spędzone w oczekiwaniu na kolejne okno przydziału. Dotyczy to wyłącznie własnego limitu, a nie rywalizacji z sąsiadami. Uwaga: jeśli host kontenerów sam jest maszyną wirtualną, wartość steal może pojawić się w /proc/stat, jednak odnosi się ona do tego hosta, a nie bezpośrednio do kontenera.

Overselling, czyli dlaczego plan kontenerowy jest tańszy

Szczera odpowiedź jest krótka. Plan kontenerowy kosztuje mniej, ponieważ dostawca współdzieli tę samą maszynę z większą liczbą użytkowników.

Pamięć RAM to obszar, w którym różnica jest największa. Pamięć RAM gościa KVM jest dla niego zarezerwowana, więc na hoście z 256 GB sprzedaje się mniej więcej 256 GB pamięci dla gości, po odjęciu narzutu. Limit pamięci kontenera jest sufitem, a nie rezerwacją. Pamięć, której kontener nie używa, jest natychmiast dostępna dla innych. Dzięki temu dostawca może sprzedać limity sumujące się do wartości kilkukrotnie przewyższających fizyczną pamięć RAM i w większości przypadków działa to poprawnie. Nic nie jest udawane. Mechanizm działa, dopóki zbyt wielu najemców nie obciąży systemu jednocześnie – wtedy przestaje działać dla wszystkich.

Procesor jest przesycony w każdym typie planu, wliczając w to KVM, poprzez sprzedaż większej liczby vCPU niż dostępna liczba rdzeni. Przestrzeń dyskowa jest niemal wszędzie przydzielana w trybie thin provisioning. Kontenery zwiększają gęstość upakowania: jedno jądro, jedna pamięć podręczna stron (page cache), brak procesu QEMU dla każdego gościa, dzięki czemu host może obsłużyć kilkukrotnie więcej najemców.

To, z czego rezygnujesz, to izolacja. Jest to realny kompromis inżynieryjny, a nie straszenie użytkowników. Współdzielisz jądro, więc błąd w jądrze jest wspólnym problemem, a ucieczka z kontenera prowadzi bezpośrednio na hosta. Ucieczka z maszyny wirtualnej wymaga błędu w hypervisorze, co jest znacznie mniejszym i trudniejszym celem do zaatakowania. Dziedziczysz również harmonogram aktualizacji jądra i restartów dostawcy. Jeśli cokolwiek z tego ma dla Ciebie znaczenie, przeczytaj jak bezpieczny jest hosting VPS w rzeczywistości przed podjęciem decyzji wyłącznie na podstawie ceny.

Co wybrać przy zakupie

Wybierz KVM, jeśli potrzebujesz własnego jądra systemu: modułów WireGuard lub ZFS, konkretnej wersji jądra, zagnieżdżonej wirtualizacji, pełnej kontroli nad swap lub izolacji, którą można wykazać audytorowi. Wybierz plan kontenerowy, jeśli uruchamiasz standardowe usługi przy ograniczonym budżecie, jądro dostawcy jest aktualne, a wymagane funkcje są w nim już skompilowane. Traktuj Xen HVM jako odpowiednik KVM w większości zastosowań i zawsze weryfikuj ofertę, jeśli usługa jest nadal sprzedawana jako Xen PV.

Dwa rozwiązania wykraczają poza ten podział. Mikromaszyny Firecracker zapewniają każdemu użytkownikowi własne jądro systemu przy czasie uruchamiania zbliżonym do kontenera; jest to technologia wykorzystywana przez platformy typu serverless. Kontenery systemowe Incus pozwalają na samodzielne wdrożenie modelu kontenerowego na własnym sprzęcie, co różni się od korzystania z gotowej usługi. Jeśli problemem jest terminologia, artykuły czym faktycznie jest VPS oraz różnica między VPS, VM a VPC wyjaśniają pojęcia, które ten przewodnik uznaje za znane.

FAQ

Jak sprawdzić, czy mój VPS to KVM czy kontener?

Uruchom systemd-detect-virt -c. Każda odpowiedź inna niż none oznacza, że działasz wewnątrz kontenera, niezależnie od nazwy planu. Potwierdź to na dwa dodatkowe sposoby, ponieważ mechanizmy wykrywania bywają mylące. lscpu wskazuje dostawcę hypervisora oraz określa, czy wirtualizacja jest pełna, czy parawirtualizacja. ls /lib/modules/$(uname -r) jest puste lub nie istnieje w kontenerze, ponieważ używany kernel pochodzi z hosta, a jego drzewo modułów nigdy nie zostało zainstalowane w Twoim systemie plików. sudo virt-what dostarcza niezależną odpowiedź z narzędzia stworzonego wyłącznie do tego celu.

Dlaczego free -m pokazuje znacznie więcej pamięci, niż przewiduje mój plan?

Korzystasz z planu kontenerowego bez zamontowanego LXCFS, więc /proc/meminfo jest plikiem hosta, a free rzetelnie raportuje pamięć hosta. Twoim rzeczywistym limitem jest cgroup. Odczytaj /sys/fs/cgroup/memory.max, aby poznać limit, oraz /sys/fs/cgroup/memory.current, aby sprawdzić bieżące zużycie, lub /sys/fs/cgroup/memory/memory.limit_in_bytes na starszym hoście z cgroup v1. Skonfiguruj każdą usługę, która ustala rozmiar pamięci podręcznej lub puli procesów roboczych na podstawie tej wartości, a nie na podstawie free.

Czy mogę uruchomić Docker lub WireGuard na VPS typu LXC?

Czasami, ale nigdy dzięki samodzielnej instalacji. Oba rozwiązania zależą od kernela dostawcy, ponieważ nie można do niego załadować własnego modułu. WireGuard działa, gdy moduł jest już obecny na hoście i udostępniony użytkownikowi, a implementacja userspace wireguard-go stanowi rozwiązanie zapasowe, gdy moduł jest niedostępny. Docker wymaga, aby dostawca zezwolił na zagnieżdżanie (nesting) oraz wymaga sterownika pamięci masowej, który działa wewnątrz kontenera. Zapytaj przed zakupem lub przetestuj usługę w ramach okresu, z którego możesz zrezygnować.

Dlaczego mój kontenerowy VPS nigdy nie raportuje steal time?

Steal time istnieje tylko wtedy, gdy hypervisor planuje wirtualny procesor (vCPU) i jest raportowany, ponieważ hypervisor zapisuje tę wartość w stronie pamięci odczytywanej przez Twój kernel. Kontener nie posiada pod sobą hypervisora. Twoje procesy są zwykłymi zadaniami w harmonogramie hosta, więc rywalizacja o zasoby objawia się wydłużonym czasem wykonywania operacji bez licznika, który mógłby to wskazać. Zamiast tego sprawdź /sys/fs/cgroup/cpu.stat: nr_throttled oraz throttled_usec zliczają czas, w którym Twoja cgroup oczekiwała na kolejne okno przydziału CPU, co jest najbliższym odpowiednikiem steal time w kontenerze.