Host-Plattform und Hardwarebasis

Die Installation ist noch keine Hostfreigabe

Ein Virtualisierungshost ist nicht bereit, nur weil sich eine Hypervisorrolle installieren ließ oder ein VM-Prozess starten kann. Produktive Eignung entsteht aus einer Kette: Der Workload benötigt bestimmte Funktionen, Hardware und Firmware stellen sie bereit, Kernel und Treiber aktivieren sie, die Virtualisierungssoftware erkennt sie und der Managementpfad kann sie sicher betreiben. Jede Übergabe kann erfolgreich aussehen, obwohl die nächste scheitert. ``text Workloadvertrag → Plattform- und CPU-Funktion → Firmwarefreigabe → Kernel, Treiber und Gerät → Hypervisor und Management → Platzierung und Betriebsabnahme `` Ein Prozessor kann Hardwarevirtualisierung unterstützen, während sie im UEFI deaktiviert ist. Ein IOMMU kann aktiv sein, während das gewünschte Gerät mit weiteren Funktionen in derselben Isolationsgruppe liegt. Ein Host kann genügend Gesamtspeicher besitzen, aber keine Reserve für Hostdienste und den gleichzeitigen Start aller zugesagten VMs. Ein erreichbares Managementinterface kann über genau denselben Uplink laufen, dessen Änderung es unzugänglich macht. Behandle die Hostfreigabe deshalb als Admission Gate mit Artefakten, nicht als Bauchgefühl. Das Gate beantwortet: Welche Fähigkeit wird benötigt? Wo ist sie belegt? Welche gemeinsame Fehlerdomäne entsteht? Welche Abweichung ist akzeptiert? Wie bleibt der Host bei einer fehlgeschlagenen Änderung erreichbar? Erst danach darf eine Workloadklasse platziert werden.

Vom Workloadbedarf rückwärts prüfen

Beginne nicht mit dem Datenblatt des Servers, sondern mit dem benötigten Betriebsvertrag. Eine gewöhnliche Server-VM verlangt andere Fähigkeiten als ein Gast, der selbst virtualisieren soll, ein geschützter Gast oder eine VM mit direkt zugewiesener GPU oder NIC. Microsoft weist ausdrücklich darauf hin, dass einzelne Hyper-V-Funktionen zusätzliche Hardwarevoraussetzungen besitzen. Eine allgemeine Plattformfreigabe ist daher kein Beweis für jede Sonderfunktion. Zerlege Anforderungen in drei Klassen. Erforderlich bedeutet: Ohne diese Fähigkeit startet der Workload nicht oder verletzt seinen Supportvertrag. Betrieblich erforderlich bedeutet: Der Workload könnte starten, wäre aber nicht in der geforderten Verfügbarkeit, Wartbarkeit oder Sicherheit betreibbar. Optional bedeutet: Die Funktion verbessert einen Aspekt, ist aber kein Freigabekriterium. Diese Trennung verhindert, dass Komfortmerkmale einen unnötig engen Hardwarevertrag erzeugen. Für jede erforderliche Fähigkeit notierst du einen Nachweis und einen negativen Test. „CPU unterstützt Virtualisierung“ braucht beispielsweise den Beleg, dass die konkrete Firmwareeinstellung aktiv und für das laufende Betriebssystem sichtbar ist. „Gerät kann durchgereicht werden“ braucht nicht nur eine Modellnummer, sondern IOMMU-Unterstützung, tatsächliche Gruppengrenze, passenden Treiberzustand und einen Plan für Hostbindung, Wartung und Recovery. Das Ergebnis ist eine kleine Matrix aus Workloadklasse, benötigter Fähigkeit, prüfender Quelle, erwarteter Ausgabe und Freigabestatus. Erst diese Matrix erlaubt eine reproduzierbare Platzierung auf mehreren Hosts.

CPU, SLAT und Firmware bilden eine gemeinsame Voraussetzung

Für Hyper-V nennt Microsoft unter anderem einen 64-Bit-Prozessor mit Second Level Address Translation, VM-Monitor-Mode-Erweiterungen, aktivierte hardwaregestützte Virtualisierung sowie hardwaregestützte Data Execution Prevention. Intel bezeichnet zentrale Funktionen häufig mit VT-x, EPT, XD und VT-d; bei AMD begegnen dir AMD-V, NPT, NX und AMD-Vi. Die Bezeichnungen sind nicht vollständig austauschbar: CPU-Virtualisierung, zweite Adressübersetzung, Ausführungsschutz und I/O-Übersetzung erfüllen unterschiedliche Aufgaben. Drei Ebenen müssen übereinstimmen. Erstens muss das konkrete Prozessormodell die Funktion implementieren. Zweitens muss die Serverfirmware sie aktivieren und dem Betriebssystem bereitstellen. Drittens muss das laufende Hostsystem sie erkennen und nutzen. Nach einem Firmwareupdate oder Mainboardtausch darfst du nicht annehmen, dass Einstellungen erhalten blieben. Prüfe sie erneut gegen den freigegebenen Baselinewert. Unter Windows liefert systeminfo.exe einen Abschnitt zu den Hyper-V-Anforderungen. Wenn dort alle Anforderungen mit „Yes“ erscheinen, sind die von Microsoft genannten Grundvoraussetzungen sichtbar. Unter Linux liefern Werkzeuge wie lscpu einen CPU- und Topologieüberblick; der entscheidende Plattformtest muss zusätzlich prüfen, ob KVM und die benötigten Geräteknoten tatsächlich nutzbar sind. ``powershell systeminfo.exe ` `bash lscpu ls -l /dev/kvm virt-host-validate qemu ` Ein einzelnes Flag aus /proc/cpuinfo` ersetzt diese Kette nicht. Es sagt ohne Firmware-, Kernel- und Berechtigungskontext zu wenig über die produktive Nutzbarkeit aus.

Werkzeuge liefern Evidenz, keine pauschale Zertifizierung

virt-host-validate prüft laut Libvirt, ob ein Host passend für bekannte Hypervisortreiber konfiguriert ist. Ohne Argumente untersucht es alle unterstützten Treiber; mit qemu beschränkst du die Prüfung auf QEMU-relevante Voraussetzungen. Ein erfolgreicher Lauf endet mit Status 0, ein Fehlschlag mit einem von null verschiedenen Status. Das macht das Werkzeug für ein automatisiertes Gate geeignet – sofern das Skript den Exitcode wirklich auswertet. ``bash if virt-host-validate qemu; then printf '%s\n' 'QEMU-Hostprüfung erfolgreich' else printf '%s\n' 'Host nicht freigeben' >&2 exit 1 fi ` Das Ergebnis gilt für die geprüfte Technologie und den aktuellen Systemzustand. Es zertifiziert weder das Servermodell für deinen Hersteller-Support noch Kapazität, Netzdesign, Storagepfade oder jede optionale Workloadfunktion. Windows systeminfo.exe besitzt dieselbe Grenze: Die allgemeinen Hyper-V-Voraussetzungen können erfüllt sein, obwohl Discrete Device Assignment oder eine andere Spezialfunktion zusätzliche Hardwaremerkmale verlangt. Speichere für ein Admission Gate mindestens Hostidentität, Firmwareversion, Betriebssystem- und Hypervisorversion, Prüfzeitpunkt, vollständiges Ergebnis und Exitstatus. Ein kopierter grüner Ausschnitt ohne Befehl und Hostbezug ist keine belastbare Evidenz. Bei einer Warnung oder Abweichung braucht es eine benannte Entscheidung: beheben, mit dokumentierter Einschränkung akzeptieren oder die betroffene Workloadklasse sperren. Der Validator darf nicht mit || true` neutralisiert werden, nur damit eine Pipeline grün erscheint.

Kapazität umfasst immer auch den Host selbst

Hypervisor, Hostkernel, Managementagenten, Storage- und Netztreiber benötigen CPU und Arbeitsspeicher, bevor eine einzige VM Ressourcen erhält. Microsoft fordert für Hyper-V ausreichend Speicher für den Host und alle gleichzeitig betriebenen VMs. Eine Summenrechnung, die den Hostbedarf ausblendet, ist deshalb keine gültige Freigabe. Ebenso beweist freier RAM im Leerlauf nicht, dass Bootspitzen, Wartung, Migration oder ein ausgefallener Nachbarhost abgefangen werden können. Trenne vier Größen: physisch vorhanden, für Firmware oder Host reserviert, für VMs zugesagt und als betriebliche Reserve frei gehalten. Der genaue Reservenwert hängt von Plattform, Workload und Verfügbarkeitsziel ab; dieses Grundlagenmodul setzt keinen universellen Prozentsatz. Es fordert jedoch, dass die Reserve ausdrücklich benannt, gemessen und vor der Platzierung geschützt wird. Bei CPU gilt dasselbe Prinzip. Die Zahl virtueller CPUs ist keine Zahl physischer Kerne. Der Scheduler teilt Ausführungszeit zu, und gleichzeitige Spitzen können sich überlagern. Für die Hostfreigabe brauchst du ein Topologieinventar und ein Kapazitätsbudget, noch keine vorschnelle feste Bindung jeder vCPU. NUMA-Knoten, Sockel und logische CPUs beeinflussen spätere Platzierungsentscheidungen; ihr Vorhandensein sollte daher als Baseline erfasst werden. Die konkrete Leistungsoptimierung gehört in eine getrennte, messwertgetriebene Änderung. Ein Admission Gate beantwortet mindestens: Bleibt der Host unter der vorgesehenen Start- und Spitzenlast steuerbar? Existiert Reserve für Management und Recovery? Welche Workloads dürfen bei einem Teilausfall zusätzlich aufgenommen werden? Wer darf das Budget ändern? Ohne diese Antworten ist „genug Hardware“ nicht prüfbar.

Netzwerk, Storage und Management als Hostpfade baselinen

Der Host verbindet virtuelle Geräte mit realen Pfaden. Vor der ersten VM muss deshalb bekannt sein, welche physischen Ports, Bridges oder Switches Management-, VM-, Storage- und gegebenenfalls Migrationsverkehr tragen. Dass ein Link „up“ ist, beweist weder das richtige VLAN noch Ende-zu-Ende-Erreichbarkeit, MTU-Konsistenz oder Redundanz. Die Hostbaseline hält Zuordnung, erwartete Adresse, Route und vorgesehenen Ausfalltest fest. Unter Linux geben lesende Befehle einen Ausgangspunkt: ``bash ip -br link ip -br address ip route show lsblk -o NAME,TYPE,SIZE,MODEL,SERIAL `` Die Ausgabe ist Inventar, noch kein Funktionstest. Prüfe Management aus dem vorgesehenen Adminnetz, Storage gegen den konkreten Zielpfad und VM-Netze mit einem kontrollierten Testport oder einer Test-VM. Ein Test aus demselben Hostnetz kann eine externe Firewall- oder Uplinkgrenze umgehen und dadurch fälschlich Sicherheit vermitteln. Plane außerdem den Wiederherstellungszugang. Wenn die einzige Managementverbindung über denselben virtuellen Switch läuft, den du gerade änderst, kann ein kleiner Konfigurationsfehler den Rückweg abschneiden. Eine unabhängige Out-of-Band-Konsole oder ein dokumentierter lokaler Zugriff begrenzt dieses Risiko. Ihre Existenz reicht nicht: Identität, Berechtigung, Erreichbarkeit und Funktionsprobe gehören in die Abnahme. Für Storage notierst du Bootmedium, VM-Datenträgerpfade, Multipath- oder Redundanzdesign und die Hostreaktion beim Ausfall eines Pfads. Die tiefe Auslegung folgt in späteren Modulen. Hier zählt, dass kein unbekannter einzelner Port die gemeinsame Fehlerdomäne aller VMs bildet.

Firmware und Treiber sind Teil der Plattformversion

Zwei Hosts mit gleicher CPU-Modellbezeichnung sind nicht automatisch gleichwertig. UEFI-Einstellungen, Microcode, Gerätefirmware, Kernel, Hypervisorpakete und Treiber bilden gemeinsam die ausführbare Plattform. Unterschiede können sichtbare CPU-Funktionen, Gerätetreiber, IOMMU-Gruppen oder das Verhalten beim Neustart verändern. Für einen gemeinsam betriebenen Hostpool braucht es deshalb eine definierte Baseline und einen Bericht über Abweichungen. Eine Baseline ist mehr als „aktuell“. Sie nennt freigegebene Versionen und Einstellungen, die gegen Hersteller- und Plattformanforderungen geprüft wurden. Vor einem Update sicherst du Iststand und Konfiguration, prüfst die Auswirkung auf Workloadklassen, hältst Recoveryzugang sowie Rückweg bereit und aktualisierst zuerst einen begrenzten Host. Nach dem Reboot wiederholst du dieselben Hardware-, Netz-, Storage- und Hypervisorprüfungen. Erst dann darf der nächste Host folgen. Besonders wichtig ist die Reihenfolge in einem Cluster oder Hostpool. Entferne beziehungsweise evakuiere Workloads nur, wenn verbleibende Hosts die Last und Fehlerreserve tragen. Ein Firmwareupdate auf allen Hosts gleichzeitig beseitigt den Vergleichs- und Rückfallpunkt. Ein Update nur auf einem Host kann vorübergehend eine Kompatibilitätsgrenze erzeugen; diese Abweichung muss in der Platzierung sichtbar sein. Melde einen Host erst dann als bereit, wenn nicht nur der Updatejob, sondern die Betriebsabnahme erfolgreich ist. „Installation abgeschlossen“ ist ein Prozesssignal. VM-Start, Managementzugang, Netzwerk, Storage, relevante CPU-Funktionen und gegebenenfalls Gerätezuteilung sind die Dienstsignale.

Direkter Gerätezugriff verschiebt die Isolationsgrenze

Bei PCI-Passthrough oder Discrete Device Assignment nutzt eine VM Hardware direkter als bei einem emulierten oder paravirtualisierten Gerät. Das kann Latenz senken oder Spezialfunktionen verfügbar machen, bindet den Workload aber enger an Host, Slot, Firmware und Gerät. Live-Migration und automatisches Failover können eingeschränkt sein, wenn das Ziel kein gleichwertiges, vorbereitetes Gerät besitzt oder die Plattform diese Bewegung nicht unterstützt. Die Sicherheitsgrenze ist nicht automatisch ein einzelner PCI-Eintrag. Linux VFIO verwendet IOMMU-Gruppen als kleinste Einheit, die von anderen Geräten isolierbar ist. Topologie, Multifunktionsgeräte und Bridges können mehrere Funktionen in derselben Gruppe zusammenfassen. Vor dem Binden eines Geräts prüfst du deshalb die gesamte Gruppe: ``bash device='0000:65:00.0' readlink /sys/bus/pci/devices/$device/iommu_group ls -l /sys/bus/pci/devices/$device/iommu_group/devices `` Wenn weitere hostkritische Geräte in derselben Gruppe liegen, ist die gewünschte Zuweisung nicht einfach isoliert. Das Aufheben eines Hosttreibers kann Netz-, Storage- oder Managementfunktionen des Hosts entfernen. Der Linux-Kernel beschreibt außerdem einen unsicheren VFIO-Modus ohne IOMMU-Schutz; seine bloße Verfügbarkeit ist kein Ersatz für eine sichere Isolationsarchitektur. Der Änderungsplan nennt Gerät und Gruppe, aktuellen Hosttreiber, Ziel-VM, Recoveryzugang, Auswirkungen auf Migration und HA sowie den Rückweg. Nach der Zuweisung prüfst du sowohl den Gast als auch den Host: Der Gast muss das Gerät erwartungsgemäß nutzen, während keine unbeabsichtigte Hostfunktion oder Nachbarfunktion verschwunden ist.

Spezialfunktionen erzeugen Platzierungsregeln

Eine Workload mit Passthrough, besonderem CPU-Modell, geschützter Startkette oder verschachtelter Virtualisierung gehört nicht in denselben abstrakten Pool wie eine Standard-VM, solange nicht alle Zielhosts den Vertrag erfüllen. Das heißt nicht zwingend, dass jeder Host identisch sein muss. Es heißt, dass die zulässige Zielmenge explizit und maschinenlesbar sein muss. Kennzeichne Fähigkeiten positiv, zum Beispiel iommu-group-gpu-a-ready oder nested-virt-approved, statt nur ungeeignete Hosts auszuschließen. Eine positive Regel lässt sich beim Hinzufügen neuer Hosts sicherer auswerten: Ohne belegtes Label erhält der Host keine Spezialworkload. Das Label selbst braucht Herkunft, Prüfzeitpunkt und Ablaufbedingung. Nach Firmware-, Treiber- oder Hardwareänderungen wird es entzogen, bis das Admission Gate erneut grün ist. Platzierung ist nur eine Hälfte. Für Wartung und Ausfall braucht jede Spezialklasse einen Recoveryvertrag. Kann die VM ausgeschaltet auf einen anderen Host verschoben werden? Existiert dort ein gleichwertiges freies Gerät? Muss ein externer Dienst übernehmen? Ist längere Wiederherstellungszeit akzeptiert? Eine VM mit lokaler Spezialhardware kann funktional korrekt, aber bewusst nicht hochverfügbar sein. Diese Einschränkung muss vor Produktion vereinbart sein, nicht erst während eines Hostausfalls. Automatisierung darf den Vertrag erzwingen, aber ihn nicht erfinden. Ein Scheduler-Label ersetzt keine IOMMU-Gruppenprüfung oder Herstellerfreigabe. Es transportiert nur ein bereits belegtes Ergebnis in die Platzierungsentscheidung.

Hostevidenz muss vergleichbar und erneuerbar sein

Eine einmalige Abnahme altert. Firmwareupdate, Hardwaretausch, Kernelwechsel, Treiberupdate oder geänderte Verkabelung können genau die Fähigkeit verändern, auf der eine Platzierungsentscheidung beruht. Verknüpfe jeden Nachweis deshalb mit stabiler Hostidentität, Erfassungszeitpunkt und einer Bedingung, bei der er ungültig wird. Ein Screenshot ohne Seriennummer oder ein Testergebnis ohne Version lässt sich später nicht sicher zuordnen. Ein nützlicher Freigabebericht trennt vier Arten von Evidenz. Inventar beschreibt, was vorhanden und sichtbar ist: CPU-Modell, Firmwarestand, RAM, PCI-Geräte, NICs und Storagepfade. Funktionsprüfung belegt eine konkrete Nutzung, etwa den erfolgreichen QEMU-Hostcheck oder Erreichbarkeit über das vorgesehene Managementnetz. Betriebsvertrag nennt Reserve, zulässige Workloadklassen und bekannte Einschränkungen. Recoverynachweis zeigt, dass Konsole, Rückweg und Wiederaufnahme praktisch funktionieren. Keine dieser Kategorien ersetzt die anderen. Speichere die Baseline so, dass ein Vorher-Nachher-Vergleich möglich ist. Nach einer Änderung vergleichst du nicht nur, ob Befehle erfolgreich enden, sondern ob Geräte, Pfade, Gruppenzuordnungen und freigegebene Funktionen unerwartet abweichen. Eine neue Abweichung sperrt die betroffene Fähigkeit; sie wird nicht durch ein pauschales „Host online“ überschrieben. Dadurch bleibt ein Fähigkeitslabel eine überprüfbare Aussage statt eines dauerhaften Versprechens.

Arbeitsbeispiel: GPU-Host ohne verlorenen Managementpfad