Wenn später kein Riegel mehr dazu kommt: Was behält der Host?

Zwei getrennte Rechnungen

Der Prozessor dieser Maschine hat 32 Kerne und 64 Threads. RAM wird bei der Bestellung als 128GB oder 256GB DDR4-3200 ECC RDIMM gewählt. Die zwei Größen sind zwei Maschinen. Nach der Installation kommt kein Modul dazu. Threads lassen sich über die Zeit zwischen Gästen teilen. Speicherseiten entstehen durch Überbuchung nicht von selbst. Zwei Rechnungen stehen zuerst: eine für Threads, eine für festes RAM. Beide beginnen mit dem Abzug dessen, was der Host behält.

Platten sind eine dritte Rechnung. Standard sind 2×1TB NVMe, ohne Hardware-RAID, jede Platte direkt angebunden. Wie Systemplatte und Gastplatten auseinandergehen, steht in Proxmox auf zwei direkt angebundenen NVMe. Eine richtige Aufteilung macht aus 128GB keine 256GB.

Bandbreite und Adressen ändern die RAM-Stufe nicht. Wie eine zusätzliche Adresse mit der enthaltenen zusammenzählt, steht in Zusätzliche IPv4 und die enthaltene Adresse. Diese Notiz klärt nur Kerne und RAM.

Threads, die der Host behält

64 Threads kommen von 32 physischen Kernen, zwei SMT-Threads je Kern. Ein SMT-Thread ist ein unvollständiger Kern. Eine Datenbank, ein Kompilierlauf oder ein Gast, der selbst virtuelle Maschinen ausführt, nimmt Budget in physischen Kernen. Gäste, die meist auf das Netz warten, teilen sich Threads.

Der Host behält Threads für Oberfläche, Netz und Speicher. Ohne ZFS bleiben 4 Threads, also 2 Kerne. Nutzt ein Pool ZFS, bleiben 8 Threads, also 4 Kerne, damit Scrub und Prüfsummen noch Raum haben. Proxmox hat keinen Schalter namens Host-Reserve. Die CPU-Affinität jeder virtuellen Maschine meidet diese Threads. Ohne ZFS nutzen Gäste 4-63 und lassen 0–3 frei. Mit ZFS nutzen sie 8-63 und lassen 0–7 frei. Die Nummern laufen von 0 bis 63. Ein Gast ohne diese Grenze belegt die reservierten Threads, deshalb erhält jeder Gast dieselbe Affinität. Host-Prozesse dürfen weiter alle Threads nutzen.

vCPUs, die gleichzeitig ausgelastet sind, bleiben in den übrigen Threads: 60 ohne ZFS, 56 mit ZFS. Seiten-Gäste dürfen darüber summieren, weil sie nicht alle voll laufen. Jeder Gast, der dauerhaft ausgelastet ist, zählt seine vCPUs als Kerne von 32. Die Grenze liegt bei 30 Kernen ohne ZFS und bei 28 mit ZFS. Beide RAM-Stufen nutzen denselben Prozessor. Die Maschine mit 256GB bringt keine zusätzlichen Kerne.

Eine Datenbank mit 8 vCPUs zählt als 8 Kerne. Ohne ZFS hält der Host bereits 2 Kerne, also bleiben 22 Kerne für andere dauerhaft ausgelastete Gäste. Zehn Seiten mit je 2 vCPUs summieren sich auf 20 Threads und können neben dieser Datenbank stehen. Eine Datenbank mit 16 vCPUs plus vier Gäste mit je 8 ausgelasteten vCPUs ergibt 48 Kerne, über 30. Die ausgelasteten vCPUs werden zuerst gekürzt. Die Maschine mit 256GB hat weiter 32 Kerne.

Nach der Installation zeigt lscpu die Zahl der NUMA-Knoten. Dieser 7543P ist ein Einzelprozessorsystem, und die Knotenzahl kann trotzdem über eins liegen. Dann bleiben RAM und vCPUs einer Datenbank auf einem Knoten. Bei einem Knoten entfällt eine knotenübergreifende Platzierung.

RAM, das der Host behält

Die Proxmox-Dokumentation lässt beim Zuweisen von Gastspeicher mindestens 1GB für den Host frei. Das ist die Untergrenze. Diese Maschine führt mehrere Gäste gleichzeitig, und der Knoten trägt außerdem Oberfläche, Protokolle und Seitencache. Das Budget lässt weitere 8GB für den Knoten, zugewiesen an keinen Gast.

Der ZFS-ARC steht getrennt, und die echte Obergrenze wird zuerst gelesen. Legt das Installationsmedium das System auf ZFS, schreiben Proxmox VE 8.1 und später eine ARC-Grenze von etwa 10 Prozent des RAM, höchstens 16GB, nach /etc/modprobe.d/zfs.conf. Zehn Prozent von 128GB sind etwa 12,8GB, unter der Kappe. Zehn Prozent von 256GB liegen über 16GB, die Kappe ist also 16GB. Diese Grenze bleibt auf der Host-Seite. Frühe VE-8-Medien und ein Pool, der erst nach der Installation entsteht, können ohne diese Grenze dastehen.

Ein später angelegter Pool fällt auf den ZFS-Standard zurück, etwa die Hälfte des RAM. Ab ZFS 2.3 kann der Standard 62,5 Prozent erreichen. Auf 128GB gehen dadurch etwa 64GB weg, bevor ein Gast existiert. Zuerst die Grenze setzen, dann Gäste anlegen.

c_max in /proc/spl/kstat/zfs/arcstats wird gelesen. Die Einheit ist Byte. Geteilt durch 1024 dreimal ergibt GiB. Fehlt die Datei, ist ZFS nicht geladen und der ARC ist 0. Für eine neue Grenze steht zfs_arc_max in zfs.conf. Der Wert ist GiB mal 1024 hoch drei. Für etwa 10 Prozent von 128GB sind 12GiB 12884901888. Auf der 256GB-Maschine ist die ARC-Grenze 16GiB, 17179869184. Auf beiden Größen liegt diese Grenze über dem ARC-Mindestwert, etwa 1/32 des RAM, deshalb genügt diese eine Zeile. Danach update-initramfs -u und ein Neustart des Knotens. Vor dem Neustart entstehen keine Gäste auf der neuen Zahl.

Die harte Obergrenze für festes Gast-RAM ist physisches RAM minus ARC-Grenze minus 8GB.

Ballooning ersetzt kein Speichermodul. Proxmox leiht RAM nur, wenn das Minimum unter dem Maximum liegt, und nur solange die Host-Nutzung unter dem Ziel bleibt, standardmäßig 80 Prozent. Bei Knappheit holt es das RAM zurück. Eine Datenbank und jeder Gast, der selbst virtuelle Maschinen ausführt, setzen Minimum gleich Maximum, damit der Cache bleibt. Seiten dürfen eine Spanne behalten. Shares bleiben beim Standard 1000. KSM führt nur gleiche Seiten zusammen. Aus 128GB werden dadurch keine 256GB. KSM bleibt außerhalb des Budgets.

Pläne, die in 128GB passen

Die Vergleiche unten gelten ohne ZFS und mit einer harten Grenze von 120GB. Festes RAM bedeutet: Minimum gleich Maximum. vCPUs von Seiten zählen nicht als dauerhaft ausgelastet.

Alle vier bleiben bei oder unter 120GB, und die ausgelasteten Kerne bleiben unter 30. Der Rest ist größer als 8GB, deshalb können sie ohne ZFS auf 128GB bleiben. Weitere Seiten passen, solange jede klein ist und nicht alle gleichzeitig voll laufen. Die Grenze in diesen Zeilen ist die RAM-Summe. Bei den Kernen ist noch Raum.

Acht ausgelastete Kerne plus die 2 Kerne des Hosts liegen weit unter 32. Mit ZFS liegt die harte Grenze bei etwa 107GB. Die Zeile mit 96GB hat noch etwa 11GB und kann auf 128GB bleiben. Die Zeile mit 104GB hat etwa 3GB übrig, das ist eng, also wechselt der Plan auf 256GB.

Pläne, die 256GB brauchen

Die ersten drei Zeilen liegen über 120GB, deshalb trägt 128GB ohne ZFS sie nicht. Die vierte Zeile ist 112GB. Sie liegt unter 120GB, lässt aber nur 8GB übrig und gilt deshalb als eng: 256GB. Ohne ZFS liegt die harte Grenze von 256GB bei 248GB. Alle vier Zeilen passen, und jede lässt mehr als 8GB frei.

Zwanzig Gäste zu 8GB mit je 2 vCPUs summieren sich auf 40 Threads. Das liegt noch in den 60 übrigen Threads. Die Grenze ist das RAM. Eine Datenbank, die 128GB fest will, lässt auf der Maschine mit 128GB keinen Platz für die 8GB des Knotens. Die Grenze von 248GB auf der Maschine mit 256GB trägt sie, mit 120GB frei.

Eine Datenbank mit 64GB plus ein verschachtelter Host mit 48GB ergibt 112GB. Gegen 120GB bleiben 8GB, also wechselt der Plan auf 256GB. Liegt die Systemplatte schon auf ZFS, liegt die Grenze bei etwa 107GB, und 112GB sind bereits darüber. Die 48GB des verschachtelten Hosts zählen einmal, als Ganzes, auf der physischen Maschine. Die kleinen Gäste darin kommen nicht extra dazu und nicht ein zweites Mal.

Beide Stufen nutzen einen AMD EPYC 7543P, 32 Kerne / 64 Threads, 2,8–3,7 GHz, 256MB L3. RAM ist DDR4-3200 ECC RDIMM. 128GB kosten $462 im Monat. 256GB kosten $595 im Monat. Der Unterschied ist $133. Die Stufe mit 256GB ergänzt RAM. Die Kernzahl bleibt 32. Die Maschinen stehen in Tokio, Japan. Proxmox VE 8 und 9 sind ohne Aufpreis für das System wählbar. Die Standardplatten sind 2×1TB NVMe, ohne Hardware-RAID, jede direkt angebunden, nutzbar ist die Summe. Bandbreite ist 250M, 1G oder 2G, zum Monatsaufpreis $0, $255 oder $745, jeweils ohne Transfergrenze, und sie ändert die RAM-Rechnung nicht. Eine IPv4 ist enthalten. Weitere Adressen kosten $2 je Stück, bis zu 255 zusätzlich. Der fällige Betrag ist die Monatssumme mal die Zahl der Monate. Monat, Quartal, Halbjahr und Jahr haben keinen Rabatt. Eine Einrichtungsgebühr gibt es nicht. Der Knoten wird über SSH verwaltet.

Ein Gast, der Gäste ausführt

Verschachtelte Virtualisierung gilt für einen Gast, der selbst KVM oder ein weiteres Proxmox ausführt. Gewöhnliche Seiten und Datenbanken brauchen sie nicht. Danach verbrauchen innere Gäste RAM und vCPUs des äußeren Gasts, und der äußere Gast verbraucht die physische Maschine. Alle drei Ebenen werden abgezogen.

svm auf dem Host prüfen

Auf dem Knoten läuft grep -m1 svm /proc/cpuinfo. Ausgabe bedeutet, dass der Prozessor AMDs Flag svm zeigt. Ohne Ausgabe erhalten innere Gäste keine Hardwarehilfe. Der Plan endet dort.

Den Nested-Parameter lesen

cat /sys/module/kvm_amd/parameters/nested ergibt 1, wenn die Host-Seite schon aktiv ist. Der Wert 0 bedeutet: zuerst alle Gäste herunterfahren. /etc/modprobe.d/kvm-amd.conf anlegen oder ergänzen, mit options kvm-amd nested=1. Der Modulname in dieser Zeile trägt einen Bindestrich. Der sysfs-Pfad nutzt einen Unterstrich. Beide Namen sind dasselbe Modul. Stehen schon Zeilen in der Datei, wird angehängt. Die Datei wird nicht überschrieben. Danach startet der Knoten neu.

Der äußere Gast nutzt host als CPU

Auf dem Knoten läuft qm set 101 --cpu host. 101 wird durch die Nummer des äußeren Gasts ersetzt. Dieselbe Einstellung ist Hardware, Prozessor, Typ: host. Nach der Änderung den Gast vom Knoten herunterfahren und wieder starten, damit QEMU mit host-CPU neu entsteht. Ein Neustart im Gastsystem übernimmt den neuen Typ nicht.

Nach dem Start läuft die svm-Prüfung im Gast. Ausgabe bedeutet, dass innere Gäste Hardwarehilfe nutzen können. Ein äußerer Gast mit 8 vCPUs gibt allen inneren Gästen diese 8, keine zusätzlichen physischen Kerne. Drei innere Gäste mit je 4 vCPUs summieren sich auf 12, schon über den äußeren 8. Die innere Ebene ist überbucht. Die physischen 32 Kerne wachsen nicht.

Das äußere RAM einmal abziehen

Ein äußerer Gast mit 48GB muss festes RAM der inneren Gäste plus den Anteil des äußeren Systems innerhalb dieser 48GB halten. Drei innere Gäste zu 8GB ergeben 24GB. Das äußere System behält 8GB. 48GB decken das. Ein weiterer innerer Gast mit 32GB macht 24+32+8 = 64, über 48. Zuerst den äußeren Gast vergrößern. Diese Vergrößerung kommt aus dem physischen Budget: aus 48GB werden 64GB, und die Differenz geht erneut von der physischen Grenze ab.

Diese Ebene kommt auf die frühere Tabelle. Ohne ZFS und mit 120GB Grenze ergeben eine Datenbank mit 64GB plus dieser äußere Gast mit 48GB zusammen 112GB, mit 8GB Rest, also wechselt der Plan auf 256GB. Die 24GB im äußeren Gast stecken bereits in den 48GB. Verschachtelung passt zu einem Labor und zu wenigen kleinen Gästen in einem äußeren Gast. Die innere Ebene wird nicht in der Dichte der physischen Maschine gefüllt. RAM, das der äußere Gast schon hat, geht nicht zusätzlich an andere Gäste auf dem Knoten.

Die Rechnung vor der Bestellung schließen

Das Budget zählt Gäste, die zusammen an sind, nicht jeden Gast, der einmal in der Woche lief. Ein Kompiliergast, der tagsüber aus ist, bleibt aus der Tagessumme. Läuft er nachts mit der Datenbank, ist die Nacht eine zweite Summe. Beide Summen müssen in die harte Grenze passen, mit mehr als 8GB Rest, bevor 128GB die Bestellung ist. Eine Summe nur für den Tag, die die Nacht auslässt, geht nach der Installation das RAM aus, und ein Modul kommt nicht dazu.

1. Festlegen, ob die Systemplatte ZFS ist. Wenn ja, die ARC-Grenze einrechnen. Wenn nein, ist der ARC 0. Ein später angelegter Pool erhält zuerst eine Grenze von etwa 10 Prozent und höchstens 16GB.
2. Der Knoten behält 8GB. Ohne ZFS meidet die Affinität 0–3. Mit ZFS meidet sie 0–7.
3. Das feste RAM der Gäste addieren, die gleichzeitig laufen. Ein verschachtelter Host zählt einmal, als Ganzes. Innere Gäste kommen nicht noch einmal dazu.
4. Die Summe bleibt auf 128GB, wenn sie in der harten Grenze liegt und die Grenze minus Summe mehr als 8GB ergibt. Sonst wird 256GB bestellt.
5. Dauerhaft ausgelastete vCPUs als Kerne addieren. Die Grenze ist 30 ohne ZFS und 28 mit ZFS. Darüber fügt keine RAM-Stufe Kerne hinzu.
6. Proxmox VE 8 oder 9 wählen. System- und Gastplatten wie in der Plattennotiz trennen. Nach SSH auf den Knoten svm, den Nested-Parameter und den ARC mit den Befehlen oben prüfen.

Eine Tagesgruppe: Datenbank fest 64GB und 8 vCPUs, Minimum ebenfalls 64GB; vier Apps zu 8GB; zwei Seiten zu 4GB. Die RAM-Summe ist 104GB. Ohne ZFS liegt die Grenze bei 120GB, also bleiben 16GB, mehr als 8GB, und die Bestellung bleibt bei 128GB. Die Datenbank ist 8 Kerne, der Host 2, Apps und Seiten sind nicht dauerhaft ausgelastet. Mit ZFS liegt die Grenze bei etwa 107GB, etwa 3GB bleiben, und die Bestellung wechselt auf 256GB. Ist die Datenbank selbst auf 128GB fest, liegt schon dieser eine Gast über 120GB, also lautet die Bestellung 256GB. Ohne ZFS liegt die Grenze von 256GB bei 248GB. Eine Datenbank mit 128GB plus die ursprünglichen 40GB aus Apps und Seiten ergeben 168GB, mit 80GB frei.

Die Kernrechnung ist auf beiden Stufen gleich. Die RAM-Rechnung ist es nicht. Passen Summe und Rest nicht in 128GB, lautet die Bestellung auf die Maschine mit 256GB.