KVM, Xen oder LXC: Was läuft auf Ihrem VPS?

Was Ihr VPS-Tarif tatsächlich bietet

KVM, Xen und LXC sind die drei Virtualisierungsfamilien, auf denen ein VPS-Tarif basiert. Die Wahl ist kein Detail im Rack des Anbieters. Sie entscheidet darüber, ob Sie einen eigenen Kernel erhalten. Aus dieser einen Tatsache ergibt sich alles, was für Käufer relevant ist: Module laden, Swap steuern, verschachtelte Virtualisierung ausführen, ob /proc Ihren Server oder den eines anderen beschreibt und ob sich Steal Time überhaupt messen lässt.

Vollvirtualisierung (KVM und Xen HVM) gibt jedem Mandanten einen Kernel und eine virtuelle Maschine. Paravirtualisiertes Xen stellt Ihnen ebenfalls einen Kernel bereit. Dieser weiß jedoch, dass er ein Gast ist, und bittet den Hypervisor, privilegierte Aufgaben für ihn auszuführen. Ein Container-Tarif (LXC oder die Produktlinie OpenVZ und Virtuozzo) stellt Ihnen ein Dateisystem und eine Reihe von Namespaces auf dem Kernel des Anbieters bereit. Alle drei werden unter denselben drei Buchstaben verkauft.

KVM vs. Xen vs. LXC: jeweils ein eigener Kernel oder ein gemeinsam genutzter Kernel

Bei KVM und Xen bezeichnet uname -r Ihren Kernel. Sie können einen anderen Kernel installieren, ein Modul darin laden und in diesen Kernel booten. Keine dieser Änderungen wirkt sich auf einen anderen Mandanten aus. Bei einem Container-Tarif bezeichnet uname -r den Kernel des Providers, der auf dem Host läuft und von allen anderen Containern auf diesem Rechner gemeinsam genutzt wird. Sie können ihn nicht ändern. apt install linux-image-generic entpackt dann Dateien, die niemals gebootet werden.

Dieser eine Unterschied ist wichtiger als jedes Datenblatt. Lesen Sie den restlichen Leitfaden als Folge dieses Unterschieds.

Vollständige Virtualisierung: KVM und Xen HVM

KVM (kernel-based virtual machine) ist ein Modul im Linux-Kernel, das einen gewöhnlichen Linux-Host mithilfe der in der CPU integrierten Intel-VT-x- oder AMD-V-Instruktionen in einen Hypervisor verwandelt. QEMU stellt die virtuelle Hardware dafür bereit: Festplatte, Netzwerkkarte und serielle Konsole. Xen verwendet ein anderes Design. Xen ist ein eigener Hypervisor und wird vor Linux gestartet. Eine privilegierte Steuerungsdomäne namens dom0 führt den Verwaltungs-Stack aus. Jeder Mandant ist eine domU. Xen HVM (hardware virtual machine) verwendet dieselben CPU-Erweiterungen wie KVM, normalerweise mit paravirtualisierten Treibern für Festplatte und Netzwerk, weil emulierte Hardware langsam ist. Diese Kombination wird als PVHVM bezeichnet.

Für einen Mandanten verhalten sich beide Systeme nahezu identisch. Sie erhalten einen Kernel, einen Bootloader, ein echtes Blockgerät, ein funktionierendes modprobe, ein echtes /proc, eigenen Swap und einen Neustart, der tatsächlich wieder bootet. Wenn der Anbieter das Einbinden eines ISO-Abbilds erlaubt, können Sie eine Distribution installieren, die er nicht anbietet.

Dafür müssen Sie bei der Auslastungsdichte Abstriche machen. Ihre 4 GB sind Ihrer Maschine fest zugewiesen und können nicht an einen Nachbarn verliehen werden, während Ihre Maschine untätig ist. Außerdem bringt jeder Gast einen QEMU-Prozess, eigene Seitentabellen und einen eigenen Seiten-Cache mit. Wegen dieser Kosten ist ein KVM-Tarif teurer als ein Container-Tarif mit denselben angegebenen Werten.

Paravirtualisiertes Xen und wie Sie es erkennen

Xen PV entstand, bevor Prozessoren Virtualisierungsanweisungen unterstützten. Statt privilegierte Anweisungen abzufangen, wird der Gastkernel so angepasst, dass er den Hypervisor direkt aufruft. Xen PV läuft ohne VT-x. Genau dafür wurde es 2005 entwickelt. pygrub oder pvgrub lädt den Kernel aus Ihrem eigenen Disk-Image. Es ist also Ihr Kernel, muss aber mit Unterstützung für PV-Gäste gebaut worden sein.

Daran erkennen Sie eine solche Umgebung: lscpu meldet als Virtualisierungstyp para statt full, /sys/hypervisor/type ist vorhanden und nennt Xen, und Ihre Datenträger heißen xvda statt vda oder sda. Werkzeuge, die SMBIOS- oder DMI-Tabellen auslesen, finden keine entsprechenden Daten. Ein PV-Gast verfügt über keine Firmware, die diese Tabellen bereitstellt.

Der dauerhafte Nachteil ist verschachtelte Virtualisierung. Ein PV-Gast bekommt die Virtualisierungserweiterungen der CPU nie präsentiert. Daher kann kein Hypervisor darin ausgeführt werden. Xen selbst ist nicht veraltet. Speziell Xen PV hat an Bedeutung verloren, und das Projekt konzentriert sich inzwischen auf PVH und HVM. Wenn ein Angebot nur „Xen“ nennt, fragen Sie nach, welche Variante gemeint ist. HVM ist ein normaler moderner VPS. Bei PV sollten Sie einen niedrigeren Preis ansetzen.

Container-VPS: LXC und die OpenVZ-Linie

Ein Container-VPS besteht aus Linux-Namespaces (separaten Ansichten von Prozess-IDs, Mounts, Netzwerkschnittstellen, Hostnamen und Benutzern) sowie cgroups (Control Groups, den Ressourcenbeschränkungen des Kernels), die auf dem Kernel des Providers ausgeführt werden. Ihr init ist ein Prozess auf dem Host. Ihr ls läuft direkt auf dem Kernel des Hosts, ohne Emulation und ohne einen zweiten Scheduler dazwischen. Deshalb sind Container schnell und erlauben eine hohe Dichte.

Auf einer Bestellseite finden Sie die Bezeichnungen LXC, Proxmox VE-Container (diese verwenden LXC), OpenVZ und Virtuozzo. OpenVZ 7 und Virtuozzo sind die kommerziellen Nachfolger derselben Idee.

Für Sie ändern sich vier Dinge:

• Module. modprobe wird nichts einfügen. Wenn WireGuard, ZFS oder ein bestimmtes netfilter-Modul nicht bereits im Kernel des Providers vorhanden ist, können Sie es nicht verwenden.
• sysctl. Der größte Teil von /proc/sys ist schreibgeschützt. Das Netzwerk ist ein echter Namespace, daher sind net.ipv4.ip_forward und die zugehörigen Schnittstellen normalerweise beschreibbar. Systemweite Einstellungen wie vm.swappiness oder fs.file-max gehören zum Host.
• Verschachtelte Container. Docker innerhalb eines LXC-Containers funktioniert nur, wenn der Provider Nesting aktiviert und der Storage-Treiber dies unterstützt. Testen Sie dies vor dem Kauf, statt es einfach anzunehmen.
• Die Kernelversion. Sie übernehmen den Upgrade-Zeitplan des Providers, einschließlich der Reboots.

Woran Sie erkennen, welche Variante Sie gekauft haben

Führen Sie diese Befehle auf dem System aus und werten Sie die Ergebnisse gemeinsam aus. Kein einzelner Befehl liefert eine sichere Entscheidung.

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 gibt einen kurzen Bezeichner aus einem festen Wertebereich aus. Die Systemseite umfasst kvm, qemu, xen, amazon und vmware. Die Containerseite umfasst lxc, lxc-libvirt, openvz, docker und systemd-nspawn. Wenn nichts erkannt wird, gibt der Befehl none aus und wird mit einem Fehlerstatus beendet. Die Variante -c liefert nur für Container-Technologien eine Antwort. Jede Antwort außer none klärt die Frage daher unabhängig davon, was auf der Verkaufsseite stand.

lscpu nennt den Anbieter des Hypervisors und gibt an, ob es sich um vollständige oder paravirtualisierte Virtualisierung handelt. Damit lässt sich Xen HVM von Xen PV unterscheiden. /sys/hypervisor/type ist nur unter Xen vorhanden.

Die Prüfung mit /lib/modules wird häufig übersprungen, ist aber am direktesten. Fehlt das Verzeichnis für die Version des laufenden Kernels oder ist es leer, obwohl das System diesen Kernel offensichtlich verwendet, stammt der Kernel nicht aus Ihrem Dateisystem. Er stammt vom Host, und sein Modulbaum wurde nie in Ihrem Image installiert. Das bedeutet, dass es sich um einen Container handelt.

Für eine unabhängige zweite Prüfung führt sudo apt install -y virt-what && sudo virt-what die Erkennungstests als dediziertes Tool aus. Dafür sind root-Rechte erforderlich. Auf Bare Metal gibt das Tool überhaupt nichts aus.

Warum /proc den falschen Rechner in einem Container beschreibt

Bei einem KVM- oder Xen-Gast ist /proc/meminfo die Abrechnung des eigenen Kernels für den Arbeitsspeicher, den der Hypervisor zugewiesen hat. Diese Angabe gilt für Ihren Rechner und sagt nichts über den Host aus. Genau das ist der Zweck einer virtuellen Maschine.

In einem Container gibt es keinen zweiten Kernel, der diese Abrechnung durchführt. Daher ist /proc das /proc des Hosts. LXCFS ist ein kleines Dateisystem, das einige dieser Dateien so anpasst, dass sie zu Ihren cgroup-Limits passen. Es deckt /proc/cpuinfo, /proc/meminfo, /proc/stat, /proc/uptime, /proc/swaps, /proc/diskstats und /sys/devices/system/cpu/online ab. Proxmox bindet es standardmäßig ein. Viele kleinere Anbieter tun das nicht. Dann meldet free -m den gesamten Arbeitsspeicher des Hosts, nproc kann jeden Kern des Rechners melden und uptime gibt an, wie lange der Host bereits läuft.

Das ist nicht nur ein kosmetisches Problem, weil Software ihre Größe anhand dieser Dateien festlegt. nginx zählt mit worker_processes auto die sichtbaren Kerne. make -j$(nproc) startet auf einem Host mit 64 Kernen und einem Kontingent von 2 Kernen 64 Compiler. Eine JVM oder eine Datenbank, die anhand von MemTotal die Cache-Größe festlegt, wählt einen Wert, den Ihre cgroup nicht zulässt. Der Kernel beendet den Prozess, sobald dieser das Limit erreicht. Dieser Abbruch wird im Kernel-Log des Hosts protokolliert. Sie können dieses Log nicht lesen.

Die maßgeblichen Werte stehen in der cgroup, nicht in /proc:

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

Das sind Pfade von cgroup v2, wie sie aktuelle Distributionen verwenden. Wenn memory.max max liest, ist auf dieser Ebene kein Limit gesetzt. cpu.max gibt ein Kontingent und eine Zeitperiode in Mikrosekunden aus. 200000 100000 entspricht daher zwei CPU-Kernen pro Periode. Auf einem älteren Host mit cgroup v1 stehen dieselben Werte unter /sys/fs/cgroup/memory/memory.limit_in_bytes und /sys/fs/cgroup/cpu/cpu.cfs_quota_us.

Swap und wer es tatsächlich besitzt

Bei KVM und Xen gehört der Swap Ihnen. Er liegt als Datei oder Partition auf Ihrer Festplatte, und Ihr Kernel übernimmt das Paging.

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

swapon --show sollte die Datei jetzt mit ihrer Größe und Priorität auflisten. Wenn swapon die Datei ablehnt, erstellen Sie sie stattdessen mit dd if=/dev/zero of=/swapfile bs=1M count=2048, weil eine vorab reservierte Datei mit nicht geschriebenen Extents auf einigen Dateisystemen abgelehnt wird. Fügen Sie /swapfile none swap sw 0 0 zu /etc/fstab hinzu. Andernfalls ist der Swap nach dem nächsten Reboot nicht mehr aktiviert.

In einem Container gehört Ihnen davon nichts. swapon benötigt eine Capability, die ein unprivilegierter Container nicht besitzt. Deshalb schlägt das Erstellen einer eigenen Swap-Datei wegen fehlender Berechtigungen fehl, bevor überhaupt auf die Festplatte zugegriffen wird. Was der Tarif als Swap bezeichnet, ist eine cgroup-Einstellung auf dem Host: memory.swap.max unter cgroup v2. Sie verwendet die eigenen Swap-Geräte des Hosts. Ältere OpenVZ-Tarife boten ein Kontingent namens „vswap“ an. Dieses verhielt sich eher wie ein Burst-Guthaben als wie ein Datenträger. Sie können die Obergrenze auslesen. Das darunterliegende Gerät kontrollieren Sie nicht.

Nested-Virtualisierung und das CPU-Flag, das täuscht

Nested-Virtualisierung bedeutet, einen Hypervisor innerhalb Ihres VPS auszuführen: einen QEMU-Gast, eine Vagrant-Box oder ein Labor für Nested-Virtualisierung mit eigenen VMs. Zwei Bedingungen müssen gleichzeitig erfüllt sein. Der Provider muss Nested-Virtualisierung auf dem Host aktivieren, und Ihrem Gast müssen die Virtualisierungserweiterungen der CPU angezeigt werden.

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

Bei einem KVM-Gast mit aktivierter Nested-Virtualisierung ist /dev/kvm vorhanden. kvm-ok zeigt eindeutig an, ob Beschleunigung verwendet werden kann. Unter Xen HVM ist dies technisch möglich, wird aber nur selten angeboten. Unter Xen PV ist es nicht möglich.

In einem Container schlägt die Prüfung auf aufschlussreiche Weise fehl. /proc/cpuinfo ist die Datei des Hosts. Deshalb ist das Flag vmx oder svm vorhanden, und es ist tatsächlich korrekt: Die physische CPU unterhalb Ihres Systems unterstützt diese Befehle wirklich. Sie stehen Ihnen trotzdem nicht zur Verfügung. In Ihrem Namespace gibt es kein /dev/kvm. Sie können das Modul kvm_intel nicht laden. Das ausgelesene Flag beschreibt den Rechner, auf dem Ihr Gast läuft, nicht einen Rechner, den Sie kontrollieren. Dies ist das deutlichste Beispiel für die allgemeine Regel. In einem Container beschreibt /proc den Namespace und die umgebende Hardware, nicht einen Server, der Ihnen gehört.

AES-NI und die CPU-Features, die Ihr Tarif bereitstellt

AES-NI (Advanced Encryption Standard New Instructions) ist ein Satz von CPU-Instruktionen, die AES-Verschlüsselung mehrmals schneller machen als dieselbe Berechnung in Software. TLS-Terminierung, Festplattenverschlüsselung, SSH und Backup-Pipelines nutzen diese Instruktionen.

Bei KVM hängt die für den Gast sichtbare CPU vom CPU-Modell ab, das der Anbieter für QEMU konfiguriert hat. Mit Host-Passthrough sehen Sie die tatsächlichen Flags. Bei einem generischen Modell wie qemu64 oder bei einer absichtlich alten Basis, die Gästen die Migration zwischen unterschiedlichen Hosts ermöglichen soll, kann das Flag aes fehlen. OpenSSL verwendet dann unbemerkt den Softwarepfad.

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

Der dritte Befehl stammt aus dem OpenSSL-Handbuch. Er deaktiviert diese Instruktionen innerhalb der Bibliothek: Das AES-NI-Bit und das VAES-Bit werden gelöscht, während die übrigen Einstellungen unverändert bleiben. Vergleichen Sie die beiden Durchsatzwerte. Liegen sie nahe beieinander, wurde der schnelle Pfad wahrscheinlich von Anfang an nicht verwendet. Dann lohnt es sich, vor der Buchung eines Tarifs fünf Minuten für eine korrekte Prüfung von AES-NI auf einem VPS einzuplanen.

Ein Container hat kein eigenes CPU-Modell. Die Flags in /proc/cpuinfo sind daher die tatsächlichen Flags des Hosts und gelten auch für Sie. Das ist ein echter Vorteil von Container-Tarifen. In diesem Leitfaden ist dies der einzige Punkt, an dem sich der gemeinsam genutzte Kernel zu Ihren Gunsten auswirkt.

Woher Steal Time kommt und warum ein Container keinen hat

Steal Time ist die Zeit, in der Ihre virtuelle CPU ausführungsbereit war, aber nicht ausgeführt wurde, weil der Hypervisor einen anderen Gast ausführte. Sie erscheint als st in top und vmstat sowie als achtes Feld der cpu-Zeile in /proc/stat.

Ein Gast kann diese Zeit nicht selbst messen, weil er währenddessen nicht ausgeführt wird. Der Hypervisor muss sie ihm mitteilen. KVM schreibt eine laufende Gesamtsumme in eine Speicherseite, die der Gast über seine paravirtualisierte clock-Schnittstelle registriert. Xen verwaltet dafür einen Laufzeitstatusbereich pro vCPU. Der angezeigte Wert stammt also direkt vom Hypervisor. Deshalb ist er vorhanden und kann als verlässlich betrachtet werden.

Ein hoher Steal-Wert bedeutet, dass der Host überbucht ist und die benachbarten Gäste zu diesem Zeitpunkt stark ausgelastet sind. Er zeigt das Verhältnis zwischen verkauften vCPUs und physischen Kernen unmittelbar. Steal Time zu messen, um einen lauten Nachbarn zu erkennen, ist die einzige Messung, mit der Sie feststellen können, ob ein Tarif tatsächlich so groß ist, wie es seine Beschreibung verspricht.

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

In einem Container ändert sich diese Spalte nicht, weil sich zwischen Ihnen und dem Scheduler kein Hypervisor befindet. Ihre Prozesse warten gemeinsam mit den Prozessen aller anderen Mandanten als normale Tasks im CPU-Scheduler des Hosts. Überlastung zeigt sich dadurch, dass die Arbeit einfach länger dauert. Es gibt keinen Zähler, der die Ursache benennt. Das nächstliegende Gegenstück ist die Drosselung durch ein Quota: Wenn der Anbieter cpu.max setzt, zählt /sys/fs/cgroup/cpu.stat die nr_throttled-Zeiträume und throttled_usec Mikrosekunden, die auf das nächste Quota-Fenster gewartet wurde. Das erfasst ausschließlich Ihr eigenes Quota und niemals die Konkurrenz durch benachbarte Mandanten. Eine Einschränkung gilt: Wenn der Container-Host des Anbieters selbst eine virtuelle Maschine ist, kann in /proc/stat ein Steal-Wert erscheinen. Dieser gehört dann zu diesem Host und nicht zu Ihnen.

Überselling und warum der Container-Tarif günstiger ist

Die ehrliche Antwort ist kurz. Ein Container-Tarif kostet weniger, weil der Anbieter dieselbe Maschine mit mehr Kunden teilt.

Beim Arbeitsspeicher ist der Unterschied am größten. Der Arbeitsspeicher eines KVM-Gasts ist diesem fest zugewiesen. Ein Host mit 256 GB bietet daher ungefähr 256 GB für Gäste an, abzüglich des Overheads. Das Speicherlimit eines Containers ist dagegen eine Obergrenze und keine Reservierung. Speicher, den ein Container nicht verwendet, steht den anderen sofort zur Verfügung. Der Anbieter kann daher Limits verkaufen, deren Summe ein Mehrfaches des physischen Arbeitsspeichers beträgt, und liegt damit fast immer richtig. Nichts daran ist vorgetäuscht. Das funktioniert, solange nicht zu viele Kunden gleichzeitig aktiv sind. Dann funktioniert es für alle nicht mehr.

CPU-Ressourcen werden bei jedem Tariftyp übersoldet, auch bei KVM, indem mehr vCPUs als vorhandene Kerne verkauft werden. Festplattenspeicher wird fast überall per Thin Provisioning bereitgestellt. Container erhöhen die Dichte zusätzlich: ein Kernel, ein Page Cache und kein eigener QEMU-Prozess pro Gast. Dadurch kann ein Host ein Mehrfaches an Kunden aufnehmen.

Was Sie dafür aufgeben, ist Isolation. Das ist ein realer technischer Zielkonflikt und keine Schreckensgeschichte. Sie teilen sich einen Kernel. Ein Kernel-Fehler betrifft daher alle gemeinsam, und ein Ausbruch aus einem Container führt direkt auf den Host. Für den Ausbruch aus einer virtuellen Maschine ist dagegen ein Fehler im Hypervisor erforderlich. Das ist ein deutlich kleineres und schwerer angreifbares Ziel. Außerdem sind Sie an den Zeitplan des Anbieters für Kernel-Upgrades und Reboots gebunden. Wenn einer dieser Punkte für Sie relevant ist, lesen Sie vor einer Entscheidung allein nach dem Preis wie sicher VPS-Hosting wirklich ist.

Welches sollten Sie kaufen?

Kaufen Sie KVM, wenn Sie einen eigenen Kernel benötigen: für WireGuard- oder ZFS-Module, eine bestimmte Kernel-Version, verschachtelte Virtualisierung, echte Kontrolle über den Swap oder eine Grenze, die Sie einem Auditor erklären können. Wählen Sie einen Container-Tarif, wenn Sie gewöhnliche Dienste mit begrenztem Budget betreiben, der Kernel des Anbieters aktuell ist und Sie bestätigt haben, dass die benötigten Funktionen bereits einkompiliert sind. Behandeln Sie Xen HVM für die meisten Zwecke wie KVM und klären Sie diese Frage vor dem Kauf, wenn noch Xen PV angeboten wird.

Zwei Varianten fallen aus diesem Schema heraus. Firecracker-MicroVMs geben jedem Mandanten einen echten Kernel mit Startkosten nahe denen eines Containers. Das ist das Modell, das Serverless-Plattformen verwenden. Incus-Systemcontainer ermöglichen es Ihnen, das Containermodell selbst auf von Ihnen kontrollierter Hardware auszuführen. Das unterscheidet sich davon, einen solchen Container als Dienst angeboten zu bekommen. Wenn die Begriffe das Problem sind, erklären was ein VPS tatsächlich ist und der Unterschied zwischen einem VPS, einer VM und einer VPC die Begriffe, die dieser Leitfaden voraussetzt.

FAQ

Woran erkenne ich, ob mein VPS unter KVM oder in einem Container läuft?

Führen Sie systemd-detect-virt -c aus. Jede Antwort außer none bedeutet, dass Sie sich in einem Container befinden, unabhängig vom Produktnamen des Tarifs. Prüfen Sie dies zusätzlich auf zwei weitere Arten, da die Erkennung verfälscht werden kann. lscpu nennt den Hypervisor-Hersteller und gibt an, ob es sich um eine vollständige Virtualisierung oder um Paravirtualisierung handelt. ls /lib/modules/$(uname -r) fehlt in einem Container oder ist leer, weil der laufende Kernel vom Host stammt und sein Modulverzeichnis nie in Ihrem Dateisystem installiert wurde. sudo virt-what liefert eine unabhängige Antwort von einem Tool, das ausschließlich für diese Frage geschrieben wurde.

Warum zeigt free -m deutlich mehr Arbeitsspeicher an, als mein Tarif umfasst?

Sie verwenden einen Container-Tarif ohne eingebundenes LXCFS. Daher ist /proc/meminfo die Datei des Hosts, und free meldet den Arbeitsspeicher des Hosts korrekt. Ihre tatsächliche Obergrenze wird durch die cgroup festgelegt. Lesen Sie /sys/fs/cgroup/memory.max für das Limit und /sys/fs/cgroup/memory.current für die aktuelle Nutzung. Auf einem älteren Host mit cgroup v1 verwenden Sie stattdessen /sys/fs/cgroup/memory/memory.limit_in_bytes. Konfigurieren Sie jeden Dienst, der die Größe eines Caches oder eines Worker-Pools anhand dieses Werts festlegt, statt anhand von free.

Kann ich Docker oder WireGuard auf einem LXC-VPS ausführen?

Manchmal. Das hängt jedoch nicht von etwas ab, das Sie installieren. Beide Anwendungen sind auf den Kernel des Providers angewiesen, da Sie darin kein Modul laden können. WireGuard funktioniert, wenn das Modul bereits auf dem Host vorhanden ist und Ihnen zur Verfügung gestellt wird. Andernfalls ist die Userspace-Implementierung wireguard-go die Ausweichlösung. Für Docker muss der Provider Verschachtelung erlauben. Außerdem wird ein Storage-Treiber benötigt, der innerhalb eines Containers funktioniert. Fragen Sie vor dem Kauf nach. Alternativ testen Sie dies in einem Tarif, den Sie ohne Weiteres kündigen können.

Warum meldet mein Container-VPS niemals Steal Time?

Steal Time gibt es nur, wenn ein Hypervisor eine virtuelle CPU einplant. Der Wert wird gemeldet, weil dieser Hypervisor die Zahl in eine Speicherseite schreibt, die Ihr Kernel liest. Ein Container hat keinen Hypervisor unter sich. Ihre Prozesse sind normale Tasks im Scheduler des Hosts. Bei einer Überlastung dauern die Vorgänge daher einfach länger, ohne dass ein Zähler darauf hinweist. Lesen Sie stattdessen /sys/fs/cgroup/cpu.stat. nr_throttled und throttled_usec zählen die Zeit, die Ihre cgroup auf ihr nächstes CPU-Quota-Zeitfenster gewartet hat. Das ist das, was dem Steal-Zustand in einem Container am nächsten kommt.