Virtualisierungshost

Proxmox VE Dedicated Server: AMD-V und NPT verfügbar

Proxmox VE 8 und 9 sind unter den kostenlosen Betriebssystemen aufgeführt.

Prozessorfunktionen direkt auf dem Host nutzen

Der AMD EPYC 7543P ist ein Single-Socket-Prozessor mit 32 Kernen und 64 Threads. Er unterstützt AMD-V (SVM) und Nested Page Tables (NPT). Der gesamte Server steht einem einzelnen Kunden zur Verfügung. Innerhalb dieser Ressourcen lassen sich virtuelle Maschinen erstellen und CPU, Arbeitsspeicher und Speicher zentral verwalten.

SVM stellt die Prozessorvirtualisierung bereit; NPT übernimmt die Übersetzung der Speicheradressen virtueller Maschinen. Beide Funktionen sind wichtige Voraussetzungen für KVM-VMs, garantieren aber keine bestimmte Anwendungsleistung. Wie schnell eine VM läuft, hängt außerdem von der Ressourcenzuweisung, dem Festplattenzugriff und der Auslastung des Servers ab.

  • Vor dem Deployment auf dem Host die Flags svm und npt prüfen, wenn die Workloads Hardwarevirtualisierung benötigen.
  • 64 Threads sind nicht dasselbe wie 64 physische Kerne. Bei der vCPU-Konfiguration physische Kerne und logische Threads unterscheiden und die Thread-Anzahl nicht als Anzahl unabhängiger Kerne behandeln.
  • Die Prozessorressourcen lassen sich auf dem Host insgesamt einteilen. Auch Hostdienste sowie Speicher- und Netzwerkaufgaben benötigen Reserven; daher sollten nicht alle Ressourcen gleichzeitig vollständig ausgelastet werden.
Prozessorfunktionen prüfen

Position des Felds „CPU flags“

flags : … svm … npt …
svm
AMD-V-Hardwarevirtualisierung
npt
Unterstützung für Nested Page Tables
Prozessorressourcen
32C / 64T

Die Abbildung zeigt nur die zu prüfenden Felder. Sie ist kein Prüfprotokoll eines bereitgestellten Servers. Maßgeblich sind die Informationen, die das Hostsystem ausliest.

Die Prozessorflags lassen sich auf dem Host mit grep -m1 '^flags' /proc/cpuinfo prüfen.
Hardware EPYC 7543P

AMD-V (SVM) und NPT

Host Proxmox VE 8 / 9

KVM verwaltet die VM-Ressourcen

Testumgebung KVM oder Hyper-V in einer VM

Installation, Netzwerk und Automatisierung testen

Mit jeder zusätzlichen Ebene müssen CPU-, Arbeitsspeicher- und Festplattenbedarf in die Ressourcenplanung desselben Hosts einfließen.

Nested Virtualisierung für Tests und Experimente

KVM oder Hyper-V innerhalb einer Proxmox-VM eignet sich zum Testen von Virtualisierungsplattformen, Betriebssystem-Deploymentskripten und mehrstufigen Netzwerkkonfigurationen. Die Virtualisierungsunterstützung des physischen Prozessors bedeutet nicht automatisch, dass sie auch in der VM verfügbar ist. Hostmodule und VM-CPU-Konfiguration müssen getrennt geprüft werden.

  • Zuerst die Hostmodule prüfen. /sys/module/kvm_amd/parameters/nested auslesen und feststellen, ob Nested Virtualisierung im KVM-AMD-Modul aktiviert ist. Ausgabe und Modulverhalten hängen auch von der verwendeten Kernelversion ab.
  • Dann den VM-CPU-Typ prüfen. Sollen Prozessorfunktionen an den Gast weitergereicht werden, lässt sich in Proxmox der CPU-Typ host auswählen. Vor der Änderung die betreffende VM herunterfahren und die Flags im Gast nach dem Start erneut prüfen.
  • Zum Schluss die innere Umgebung testen. Im Gast prüfen, ob die benötigten Funktionen sichtbar sind, und anschließend KVM installieren oder Hyper-V aktivieren. Anforderungen an Betriebssystemversion und Funktionen der inneren Umgebung separat abgleichen.

Nested Setups eignen sich zur Funktionsprüfung. Ihre Leistung sollte nicht als Grundlage für die Kapazitätsplanung einer einzelnen produktiven VM dienen. Änderungen an Modulparametern können laufende VMs beeinträchtigen. Vorher die Konfiguration sichern und einen geeigneten Zeitpunkt für den erforderlichen Betriebsstopp einplanen; Module nicht während laufender Workloads direkt neu laden.

Vier Laufwerksschächte, direkte Anbindung

Standardmäßig sind zwei 1-TB-NVMe-Laufwerke verbaut, mit insgesamt 2 TB Rohkapazität. Optional können zwei 2-TB-NVMe-Laufwerke ergänzt werden. Alle Laufwerke sind einzeln direkt angebunden und nicht an einen Hardware-RAID-Controller angeschlossen.

Schacht 01 · Standard 1TB NVMe Direkt angebunden
Schacht 02 · Standard 1TB NVMe Direkt angebunden
Schacht 03 · Optional 2TB NVMe Direkt angebunden
Schacht 04 · Optional 2TB NVMe Direkt angebunden
Gestrichelte Umrandungen kennzeichnen optionale Laufwerke, nicht bereits installierte Festplatten. Zur Auswahl stehen 0, 1 oder 2 zusätzliche Laufwerke.

2 TB Rohkapazität, kein RAID-1

Die beiden Standardlaufwerke bilden keinen Hardware-Spiegel. Software-RAID, ZFS-Mirror und externe Datensicherungen richten Kunden selbst ein. Werden die beiden Laufwerke als separate Datenträger genutzt, liegt auch die Verantwortung für den entsprechenden Datenschutz bei ihnen.

Für Redundanz empfiehlt sich bei der Proxmox-Installation ein ZFS-Mirror. Dabei die ausgewählten Laufwerke sorgfältig prüfen. Im Mirror stehen bei zwei 1-TB-Laufwerken vor Dateisystem- und sonstigem Overhead etwa 1 TB zur Verfügung. Virtuelle Festplatten sollten daher nicht weiter mit 2 TB geplant werden.

Bei der Installation oder dem Neuaufbau eines Speicherpools können Daten auf den ausgewählten Laufwerken gelöscht werden. Vorher sicherstellen, dass sich die Sicherung wiederherstellen lässt. Laufwerke anhand ihrer Kapazität und tatsächlichen Kennzeichnung identifizieren und nicht allein nach ihrer Reihenfolge auswählen.

Ein Mirror schützt hauptsächlich vor dem Ausfall eines einzelnen Laufwerks, ersetzt aber keine Datensicherung. Versehentliches Löschen, beschädigte Daten im Gast und Fehler bei der Kontoverwaltung können auch die gespiegelten Daten betreffen. Eine separate Sicherung mit geprüftem Wiederherstellungsprozess bleibt daher erforderlich.

Die erste IPv4-Adresse bleibt dem Host vorbehalten

Eine dedizierte IPv4-Adresse ist inklusive; bis zu 255 weitere lassen sich hinzufügen. Jede zusätzliche Adresse kostet $1.7 pro Monat. Die Anzahl richtet sich danach, wie viele VMs oder Dienste einen eigenen öffentlichen Zugang benötigen. Nicht jede VM braucht zwangsläufig eine eigene öffentliche IP-Adresse.

Die erste Adresse in der Adressliste des Control Panels bleibt dem Host vorbehalten und wird auch für SSH verwendet. Die übrigen Adressen lassen sich den entsprechenden VMs über eine Bridge zuweisen. Bridge-, Routing- und Gastnetzwerkeinstellungen müssen anhand der bereitgestellten Informationen eingerichtet werden. Gateway oder Netzmaske nicht schätzen.

  • Adresszuweisungen dokumentieren. Für jede zugewiesene Adresse den VM-Namen, den Verwendungszweck und den Ort der Konfiguration im System festhalten. So lässt sich vermeiden, dass zwei VMs dieselbe Adresse verwenden.
  • Den Verwaltungszugang sichern. Vor Änderungen an der Host-Bridge die bestehende Netzwerkkonfiguration speichern und sicherstellen, dass die Verwaltungsadresse erhalten bleibt. Anschließend die externe Erreichbarkeit der VMs einzeln prüfen.
  • Zugriffsgrenzen separat festlegen. Eine dedizierte IPv4-Adresse sorgt nicht automatisch für Zugriffsschutz. Firewall und Verwaltungszugänge von Host und Gästen müssen entsprechend dem Einsatzzweck konfiguriert werden.

250 Mbps sind inklusive; 1 Gbps und 2 Gbps stehen optional zur Auswahl. Alle drei Bandbreitenoptionen sind ohne Traffic-Limit. Die VMs teilen sich die Bandbreite des Servers. Mehr IP-Adressen erhöhen die verfügbare Ausgangsbandbreite nicht.

Adresszuweisungen im Überblick

Zuordnungen der Listenreihenfolge nach dokumentieren; echte Verbindungsdaten werden nicht angezeigt.

Erste Adresse
Proxmox-HostFür Verwaltung und SSH reserviert
Zusätzliche Adresse
VM mit öffentlichem ZugangEinzeln konfigurieren und zuordnen
Serverbandbreite
Gewählte OptionGemeinsam von Host und VMs genutzt
Ob VMs in einem privaten Netzwerk eine eigene öffentliche IPv4-Adresse benötigen, hängt vom Zugang und der Netzwerkarchitektur ab.

Arbeitsspeicher planen, VM-Dichte festlegen

Zur Auswahl stehen 128GB und 256GB DDR4-3200 ECC. Nach der Bereitstellung lässt sich der Arbeitsspeicher auf dem bestehenden Server nicht aufrüsten. Ein Wechsel auf eine andere Größe erfordert eine neue Bestellung. Deshalb sollten Host, ZFS-Cache, VMs und erwartetes Wachstum bereits vor der Bestellung berücksichtigt werden.

AMD EPYC 7543P · 128GB

Geeignet für Deployments mit klar definiertem Ressourcenbedarf, überschaubarer VM-Anzahl und kontrolliertem Speicherbedarf pro VM. Zuerst Reserven für Host und Storage einplanen, dann jeder VM den tatsächlich benötigten Arbeitsspeicher zuweisen, statt den verfügbaren Speicher einfach gleichmäßig nach VM-Anzahl aufzuteilen.

  • Grundbedarf und Lastspitzen der VMs dokumentieren, nicht nur die zugewiesenen Höchstwerte.
  • Bei ZFS Cache und Speicheroperationen in die Hostplanung einbeziehen.
  • Reserven für Datensicherung, Wiederherstellung und temporäre Tests einplanen.

AMD EPYC 7543P · 256GB

Geeignet für VMs mit höherem Speicherbedarf, größere Datenbank-Caches oder mehrere gleichzeitig laufende Testumgebungen. Mehr Arbeitsspeicher ändert weder Prozessor noch Standardlaufwerke. CPU-Zuteilung und Festplattenzugriffe müssen weiterhin mitgeplant werden.

  • Arbeitsspeicher nach Diensten aufschlüsseln und dauerhafte Lasten von temporären Testumgebungen unterscheiden.
  • Ressourcenkonflikte bei gleichzeitiger Sicherung oder Wiederherstellung mehrerer VMs prüfen.
  • Für Datenbanken mit großem Arbeitsspeicher und verschachtelte VMs separate Ressourcengrenzen festlegen.

Vier Bereiche in die Planung einbeziehen

Arbeitsspeicherbudget des Servers = Hostdienste + ZFS-Cache + Arbeitsspeicherbedarf der VMs + Betriebsreserve

Eine allgemeingültige Zahl dafür, wie viele VMs auf einem Host laufen können, gibt es nicht. Die Anforderungen von Gastbetriebssystemen, Datenbankpuffern, Container-Workloads und Nested Tests unterscheiden sich. Eine Überbelegung des Arbeitsspeichers ersetzt keine physische Kapazität. Vor dem Produktivbetrieb die Lastspitzen mit realen Workloads prüfen und erst dann über weitere VMs entscheiden.

Den Server passend zu den Hostressourcen planen

Zuerst Arbeitsspeichergröße, Festplattenredundanz und Bedarf an öffentlichen IP-Adressen festlegen. Anschließend die Optionen auf der Konfigurationsseite prüfen. Proxmox VE 8 und 9 stehen als kostenlose Betriebssysteme zur Auswahl.