Die Tiefen der Windows-Virtualisierung (Teil 1) — Wo läuft Ihr Windows eigentlich? Hypervisor und Partitionen

Sie haben nie eine einzige VM angelegt, und doch zeigt die Systeminformation (msinfo32) unter Windows 11 „Virtualisierungsbasierte Sicherheit: Wird ausgeführt“. Was bedeutet diese Anzeige?

Auf diesem PC läuft das Host-Windows selbst bereits auf einem Hypervisor. Unter Windows 11 ist VBS auf Konfigurationen, die die Bedingungen erfüllen — etwa eine Neuinstallation auf kompatibler Hardware —, standardmäßig aktiviert, und diese Grundlage wird genutzt, auch wenn Sie nie eine VM anlegen.¹ WSL2 und Windows Sandbox nutzen denselben Windows-Hypervisor.

Teil 1 erklärt wo das Host-Windows landet, wenn Sie Hyper-V aktivieren, anhand der Rollenteilung bei CPU, Speicher und Geräte-E/A. Es ist die Folge, die zuerst die Sicht „VM-Software sitzt auf Windows“ zurechtrückt.

„Die Tiefen der Windows-Virtualisierung“ — Alle 3 Teile

Wir betrachten denselben Windows-Hypervisor in der Reihenfolge Grundlage → Sicherheitsisolierung → Anwendung auf leichte VMs.

Voraussetzungen für diesen Artikel

Wie Sie diesen Artikel lesen

Die folgende Wissenskarte ist eine Übersicht der Beziehungen. Beim ersten Lesen folgen Sie dem Text ab Abschnitt 1, das Gesamtbild.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (22 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

1. Zuerst das Fazit

Wenn Leute Hyper-V hören, stellen sie sich vielleicht „VM-Software vor, die auf Windows sitzt“. Die tatsächliche Struktur ist umgekehrt.

Ab dem Moment, in dem Sie Hyper-V aktivieren und neu starten, steuert der Hypervisor die physischen CPUs und den Speicher, und das Host-Windows läuft darauf als erste, privilegierte Partition — die „Root-Partition“.

Ein Hypervisor ist eine dünne Softwareschicht zwischen Hardware und Betriebssystem. Er legt isolierte Ausführungsumgebungen namens „Partitionen“ an und vermittelt den Zugriff auf die Hardware.² Das Host-Windows geht in die Root-Partition, VMs gehen in Child-Partitionen.

Die Root-Partition wird besonders behandelt (sie hat direkten Zugriff auf physische Geräte und hält den Verwaltungsstack), aber insofern sie die physischen CPUs nicht direkt steuert, steht sie an derselben Stelle wie eine Child-Partition.

flowchart TB
    accTitle: Gesamtstruktur nach aktiviertem Hyper-V
    accDescr: Der Hypervisor sitzt direkt auf der physischen Hardware, und darüber sitzen die Root-Partition, die das Host-Windows hält, und die Child-Partitionen, die VMs halten
    hw["Physische Hardware"] --> hv["Hypervisor"]
    hv --> root["Root-Partition (Host-Windows)"]
    hv --> child1["Child-Partitionen (VMs)"]
    root -.-> stack["Hält den Virtualisierungs-Verwaltungsstack und Gerätetreiber"]

Abbildung 1: Hyper-V ist nicht „VM-Software auf Windows“, sondern eine Schicht, die unter Windows geht, und das Host-Betriebssystem selbst läuft in der Root-Partition.

Sie könnten denken: „Wenn sich vor und nach dem Aktivieren nichts anders anfühlt, hat eine so große Umkehrung wirklich stattgefunden?“ Sie hat. Genau deshalb fällt diese Struktur meist nicht auf. In diesem Artikel zerlegen wir dieses eine Diagramm von drei Seiten: CPU, Speicher und Geräte-E/A.

2. Von der CPU — Noch ein Privileg unter den Ringen

In der CPU-Diskussion unterscheiden wir die Ringe, die Kernel und Anwendungen trennen, von den Ausführungsmodi, die Hypervisor und Gäste trennen. Die Frage dieses Abschnitts lautet: Der Gastkernel läuft ebenfalls auf Ring 0 — warum kommt es nicht zum Zusammenstoß?

2.1. Eine Wiederholung des Ringschutzes

x64-CPUs haben Privilegstufen (Ringe), und Windows führt den Kernelmodus auf Ring 0 und den Benutzermodus auf Ring 3 aus. Anwendungen können Hardware nicht direkt berühren, weil privilegierte Befehle von Ring 3 aus nicht ausführbar sind.

Wie also bringen Sie mehrere Betriebssystemkerne, die jeweils auf Ring 0 laufen, sicher auf derselben physischen CPU unter? Jeder Kernel ist unter der Annahme geschrieben, „ich steuere die CPU“. Geben Sie allen Ring 0, stoßen sie zusammen; verweigern Sie ihn, laufen sie nicht.

flowchart TB
    accTitle: Das Problem mehrerer Betriebssystemkerne, die Ring 0 verlangen
    accDescr: Sowohl Host- als auch Gastkernel sind unter der Annahme voller Autorität auf Ring 0 geschrieben, sodass die herkömmliche Ringleiter allein sie nicht sicher auf derselben physischen CPU unterbringen kann
    k1["Host-Kernel (nimmt Ring 0 an)"] --> want["Verlangt die Steuerung der physischen CPU"]
    k2["Gastkernel (nimmt Ring 0 an)"] --> want
    want --> conflict["Herkömmliche Ringe allein können das nicht versöhnen"]
    conflict --> need["Ein Vermittler über Ring 0 ist nötig"]

Abbildung 2: Die Ringleiter wurde unter der Annahme eines einzigen Betriebssystems gebaut; mehrere Kernel unterzubringen braucht ein weiteres Privileg darüber.

2.2. Virtualisierungsunterstützung — Ein Modus, der dem Hypervisor vorbehalten ist

Was dieses Problem löst, ist die Virtualisierungsunterstützung der CPU (Intel VT-x/AMD-V). Hyper-V verlangt einen Prozessor, der dieses Merkmal hat.² Die Virtualisierungsunterstützung fügt auf einer Achse getrennt von den herkömmlichen Ringen einen „Ausführungsmodus für den Hypervisor“ und einen „Ausführungsmodus für Gäste“ hinzu. Es ist ein noch stärkeres Privileg als Ring 0, manchmal mit dem Spitznamen „Ring −1“.

• Der Gastkernel läuft weiterhin auf Ring 0, wie bisher. Keine Umschreibung ist nötig.
• Dieser Ring 0 ist jedoch „Ring 0 innerhalb des Gastmodus“ und steuert nicht die physische CPU als Ganzes.
• Trifft der Gast auf eine bestimmte Operation, die Eingreifen des Hypervisors verlangt (ein als Intercept konfigurierter Befehl oder eine Ausnahme oder Verletzung), übergibt die CPU die Steuerung automatisch an den Hypervisor (ein VM Exit). Wenn der Hypervisor die Behandlung beendet, kehrt er zum Gast zurück (ein VM Entry). Gewöhnliche Speicherzugriffe gehen ohne VM Exit durch, solange die SLAT-Übersetzung gelingt.

Unterbrechungen funktionieren genauso. Partitionen berühren physische Prozessoren nicht direkt; der Hypervisor empfängt Unterbrechungen und leitet sie an jede Partition.²

flowchart TB
    accTitle: Der Ablauf von Gastausführung und VM Exit
    accDescr: Der Gastkernel und Apps laufen auf Ring 0 und Ring 3 im Gastmodus; gewöhnliche Speicherzugriffe gehen über SLAT-Übersetzung durch, während als Intercept konfigurierte Operationen und Ausnahmen einen VM Exit auslösen, der die Steuerung an den Hypervisor übergibt, der dann über VM Entry zum Gast zurückkehrt
    guest["Ausführung im Gastmodus (inkl. Ring-0-Kernel)"] --> op{"Eingriff nötig? (konfigurierte Intercepts/Ausnahmen)"}
    op -->|Nein| cont["Weiter ausführen"]
    op -->|Ja| exitEv["VM Exit (CPU übergibt die Steuerung)"]
    exitEv --> hvp["Hypervisor behandelt es"]
    hvp --> entry["Rückkehr zum Gast über VM Entry"]
    entry --> guest

Abbildung 3: Das Gastbetriebssystem läuft weiter auf Ring 0 ohne Umschreibung, und die CPU ruft den Hypervisor nur bei Bedarf.

Dieses Hin und Zurück ähnelt stark dem Ablauf, den wir in der Speicherreihe verfolgt haben — „beim Seitenfehler in den Kernel eintreten, dann zum selben Befehl zurückkehren“. Die CPU fängt die Steuerung über einen Ausnahme- oder Übergangsmechanismus ab, lässt einen höherstufigen Verwalter entscheiden und kehrt dann zurück. In den Tiefen von Windows erscheint diese Form immer wieder.

2.3. Typ 1 und Typ 2 — Der Unterschied ist, wo es sitzt

Hypervisoren werden grob in Typ 1 (Bare-Metal), der direkt auf der Hardware läuft, und Typ 2 (hosted), der auf einem Host-Betriebssystem läuft, geteilt. Hyper-V ist Typ 1.³ VirtualBox und VMware Workstation (wenn eigenständig ausgeführt) werden als Typ 2 eingeordnet.

Bei Typ 1 neigen Leute dazu, sich „eine nur für Server gedachte Konfiguration ohne Host-Betriebssystem“ vorzustellen, aber Hyper-V ist anders. Das Host-Windows verschwindet nicht — es „zieht um“ in die Root-Partition. Wenn Sie Hyper-V aktivieren und neu starten, startet der Hypervisor beim Booten zuerst, und das Host-Windows kommt dann als Root-Partition darauf hoch.

flowchart TB
    accTitle: Der Unterschied zwischen Typ-1- und Typ-2-Hypervisoren
    accDescr: Bei Typ 2 sitzt das Host-Betriebssystem auf der Hardware und der Hypervisor und die VMs sitzen auf dem Host-Betriebssystem, während bei Typ-1-Hyper-V der Hypervisor direkt auf der Hardware sitzt und das Host-Betriebssystem selbst in die Root-Partition darüber geht
    subgraph t2 ["Typ 2 (hosted)"]
        hw2["Hardware"] --> hostos["Host-OS"]
        hostos --> hv2["Hypervisor"]
        hv2 --> vm2["VM"]
    end
    subgraph t1 ["Typ 1 (Hyper-V)"]
        hw1["Hardware"] --> hv1["Hypervisor"]
        hv1 --> root1["Root-Partition (Host-OS)"]
        hv1 --> vm1["VM"]
    end
    vm2 ~~~ hw1

Abbildung 4: Bei Typ 2 sitzt der Hypervisor auf dem Host-Betriebssystem, bei Typ-1-Hyper-V ist die Reihenfolge umgekehrt und das Host-Betriebssystem selbst sitzt auf der Schicht eine Stufe darunter.

Auf einer Boot-Zeitachse sieht die Änderung beim Aktivieren so aus.

flowchart TB
    accTitle: Boot-Reihenfolge nach aktiviertem Hyper-V
    accDescr: Nach dem Einschalten startet der Hypervisor beim Booten zuerst, das Host-Windows kommt dann als Root-Partition darauf hoch, und VMs, VBS und dergleichen starten danach
    poweron["Einschalten und Boot-Beginn"] --> bhv["Hypervisor startet zuerst"]
    bhv --> broot["Host-Windows startet als Root-Partition"]
    broot --> blater["VMs, VBS, WSL2 und so weiter starten darüber"]
    broot -.-> feel["Die Nutzererfahrung bleibt unverändert"]

Abbildung 5: Die Umkehrung der Reihenfolge ist schon vor dem Anmeldebildschirm abgeschlossen, und das Host-Betriebssystem kommt von Anfang an auf dem Hypervisor hoch.

3. Partitionen — Die Einheit der Isolierung

Schauen wir uns Partitionen genauer an, die „Kästen“ im Gesamtbild. Was wir hier trennen wollen, ist die Vermittlung von CPU und Speicher, die der Hypervisor direkt übernimmt, von der Geräte-E/A, die normalerweise die Root-Partition vermittelt.

3.1. Rollen, die nur die Root-Partition hat

Eine Partition ist eine logische Isolierungseinheit, die der Hypervisor bereitstellt.² Nicht jede Partition ist jedoch gleich. Es gibt Dinge, die nur die Root-Partition hat.

Direkter Zugriff auf physische Geräte

Gerätetreiber für Datenträger, NICs, GPUs und dergleichen leben im Windows innerhalb der Root-Partition, nicht im Hypervisor. Hyper-V auf Windows Server hat eine Konfiguration, die ein bestimmtes PCIe-Gerät direkt einer Child-Partition zuweist (Discrete Device Assignment); in dem Fall gibt die Root dieses Gerät ab (unter Client-Windows ist das nicht verfügbar).⁴

Der Virtualisierungs-Verwaltungsstack

VMMS (Virtual Machine Management Service), der das Anlegen, Starten und Stoppen von VMs steuert, und der Worker-Prozess, der für jede VM startet (vmwp.exe), laufen im Benutzermodus in der Root-Partition.⁵ Das sind Teile der VM-Verwaltung von Hyper-V, sie können also auf einem Host fehlen, auf dem nur der Hypervisor für VBS oder WSL2 läuft.

Das Recht, Child-Partitionen anzulegen

Die Root-Partition legt Child-Partitionen über die Hypercall-API an (die Aufrufschnittstelle in den Hypervisor).²

Dieses Design hat einen Grund. Würden Sie jeden Gerätetreiber in den Hypervisor selbst stecken, würde der Hypervisor riesig und die Zahl der Fehler und Angriffsflächen wüchse. Der Hypervisor beschränkt sich auf die minimale Arbeit, CPUs und Speicher zu vermitteln, und überlässt die Betreuung der Geräte dem Windows in der Root-Partition. Diese Rollenteilung hält Hyper-V dünn.

flowchart TB
    accTitle: Rollenteilung zwischen Root-Partition und Child-Partitionen
    accDescr: Die Root-Partition hält den Virtualisierungs-Verwaltungsstack und physische Gerätetreiber und legt Child-Partitionen über Hypercalls an; eine Child-Partition sieht in der üblichen Konfiguration nur virtuelle Geräte, und unter Discrete Device Assignment auf Windows Server greift sie direkt auf das zugewiesene Gerät zu
    subgraph rootp ["Root-Partition"]
        vmms["VMMS und Worker-Prozesse"]
        drv["Physische Gerätetreiber"]
    end
    subgraph childp ["Child-Partition"]
        gos["Gast-OS"]
        vdev["In der üblichen Konfiguration sind nur virtuelle Geräte sichtbar"]
    end
    vmms -->|Per Hypercall anlegen und verwalten| childp
    hv2["Hypervisor (beschränkt sich auf die Vermittlung von CPU und Speicher)"] --- rootp
    hv2 --- childp

Abbildung 6: Gerätetreiber und Verwaltungsstack auf die Seite der Root-Partition zu legen hält den Hypervisor selbst dünn.

3.2. Die Welt, wie sie eine Child-Partition sieht

Das Gastbetriebssystem in einer Child-Partition kann physische Hardware in der üblichen virtuellen Gerätekonfiguration nicht direkt sehen (die einzige Ausnahme ist ein über Discrete Device Assignment auf Windows Server zugewiesenes Gerät, wie im vorigen Abschnitt beschrieben). Was es sehen kann, sind virtuelle Prozessoren, ein Speicherraum, der ihm eigen zu gehören scheint, und virtuelle Geräte. Anforderungen an virtuelle Geräte werden über VMBus oder den Hypervisor an die Root-Partition weitergeleitet.²

Die Zuteilung von CPU-Zeit und die Speicherübersetzung über SLAT übernimmt dagegen der Hypervisor direkt, ohne den Umweg über die Root. Was die Root vermittelt, ist Geräte-E/A, nicht jede physische Ressource.

flowchart TB
    accTitle: Die Welt, wie sie eine Child-Partition sieht
    accDescr: Was das Gastbetriebssystem sieht, sind virtuelle Prozessoren, ein der Partition privater Speicherraum und virtuelle Geräte; Anforderungen an virtuelle Geräte werden über VMBus und dergleichen an die Root-Partition weitergeleitet, CPU-Zeit und Speicherübersetzung übernimmt der Hypervisor direkt, und in einer Discrete-Device-Assignment-Konfiguration auf Windows Server wird nur auf die zugewiesenen Geräte direkt zugegriffen
    gos2["Gast-OS in der Child-Partition"] --> vcpu["Virtuelle Prozessoren"]
    gos2 --> gpa2["Privater Speicherraum"]
    gos2 --> vdev2["Virtuelle Geräte"]
    vdev2 -->|"Über VMBus und dergleichen"| rootx["Weiterleitung an die Root-Partition"]
    gos2 -.->|Nicht direkt sichtbar| phys2["Physische CPUs, RAM und echte Geräte"]
    phys2 -.-> dda2["In einer DDA-Konfiguration (Windows Server) nur direkter Zugriff auf zugewiesene Geräte"]
    vcpu ~~~ phys2

Abbildung 7: In der üblichen virtuellen Gerätekonfiguration ist alles, was der Gast sieht, ein virtuelles Fenster, und der Weg zum Physischen geht durch einen Vermittler; nur ein über DDA auf Windows Server zugewiesenes Gerät ist die Ausnahme.

Was hier zählt: Für eine App, die auf dem Host-Windows läuft, ist diese Struktur fast durchsichtig. Win32-API-Aufrufe und die Behandlung von Seitenfehlern verarbeitet weiterhin der Windows-Kernel in der Root-Partition, wie bisher. Der Hypervisor greift nur ein, wenn ein konfigurierter Intercept oder eine Ausnahme getroffen wird.

4. Vom Speicher — Die Adressübersetzung bekommt eine weitere Stufe

Beim Speicher trennen wir die Adresse, die der Gast für „physisch“ hält, von der tatsächlichen Lage im RAM. Behalten Sie die Reihenfolge GVA → GPA → SPA und wer jede Übersetzung verwaltet.

4.1. Drei Arten von Adressen

In Teil 1 der Speicherreihe haben wir den Ablauf verfolgt, mit dem eine virtuelle Adresse über die Seitentabelle in eine physische Adresse übersetzt wird („Der Moment, in dem eine virtuelle Adresse zu physischem RAM wird“). In einer virtualisierten Umgebung kommt unter dieser Übersetzung eine weitere Stufe hinzu, und es gibt drei Arten von Adressen.

Das Gastbetriebssystem übersetzt GVA nach GPA mit der eigenen Seitentabelle. Die GPA, die der Gast sieht, ist jedoch keine echte physische Adresse; sie ist ein privater Speicherraum, der jeder Partition zugeordnet ist.² GPA auf die tatsächliche Lage im RAM (SPA) abzubilden ist Aufgabe des Hypervisors.

4.2. SLAT — Zweistufige Übersetzung in Hardware

Würde diese zweite Übersetzungsstufe allein in Software erledigt, müsste der Hypervisor jede Aktualisierung der Gast-Seitentabelle einzeln verfolgen, was aus Leistungssicht nicht realistisch ist. Deshalb stellt die CPU einen Mechanismus bereit, der die Übersetzungstabellen der zweiten Stufe in Hardware durchläuft. Das ist SLAT (Second Level Address Translation); Intel EPT (Extended Page Tables) und AMD RVI sind die Umsetzungen.

Aktuelles Hyper-V verlangt einen SLAT-fähigen 64-Bit-Prozessor.⁴

flowchart TB
    accTitle: Zweistufige Adressübersetzung über SLAT
    accDescr: Eine Gast-Virtuelladresse wird von der Seitentabelle des Gastbetriebssystems in eine Gast-Physikadresse übersetzt, dann weiter von SLAT, das der Hypervisor verwaltet, in eine System-Physikadresse, und erreicht den tatsächlichen RAM
    gva["Gast-Virtuelladresse (GVA)"] -->|Seitentabelle des Gast-OS| gpa["Gast-Physikadresse (GPA)"]
    gpa -->|"SLAT (EPT/RVI-Übersetzungstabellen)"| spa["System-Physikadresse (SPA)"]
    spa --> ram["Physischer RAM"]
    gpa -.-> note["Eine Schicht, die der Gast lediglich für physisch hält"]

Abbildung 8: Unter der Seitentabelle des Gastes sitzt eine weitere, vom Hypervisor verwaltete Übersetzungstabelle, und die CPU durchläuft beide in Hardware.

SLAT ist kein Merkmal, das nur der Ausführungseffizienz von VMs dient. Das VBS, das wir in Teil 2 sehen, nutzt die Eigenschaft, „pro Privilegstufe eine andere SLAT-Übersetzungstabelle haben zu können“, als Material für eine Sicherheitsgrenze. Der Grund, warum Sie Speicher anlegen können, den selbst der Kernel nicht sieht, ist, dass der Hypervisor diese zweite Übersetzungsstufe hält. Das ist ein roter Faden der ganzen Reihe, merken Sie sich daher nur einen Punkt: „Der Verwalter der Übersetzungstabellen ist der Hypervisor“.

5. Von der Geräte-E/A — VMBus und zwei Arten von Geräten

Geräte-E/A nimmt einen anderen Weg als CPU-Zeit und Speicherübersetzung. Wir vergleichen die Methode, die echte Hardware nachahmt, mit der Methode, die einen eigens für die Virtualisierung gedachten Pfad nutzt.

5.1. Die Grenzen emulierter Geräte

Der klassische Weg, einer Child-Partition ein Gerät zu zeigen, besteht darin, echte Hardware (etwa einen alten IDE-Controller) vollständig in Software nachzuahmen. Die Kompatibilität ist hoch, weil die mitgelieferten Treiber des Gastbetriebssystems unverändert funktionieren, aber bei jedem Zugriff des Gastes auf einen E/A-Port entsteht ein VM Exit, und die Leistung skaliert nicht.

flowchart TB
    accTitle: Warum E/A zu einem emulierten Gerät langsam ist
    accDescr: Jedes Mal, wenn der Gast einen E/A-Port bedient, geht die Steuerung über einen VM Exit auf die Hypervisor-Seite, das Gerät wird in Software nachgeahmt, und die Steuerung kehrt zum Gast zurück, sodass sich der Hin-und-zurück-Weg wiederholt und langsam ist
    gio["Gast bedient einen E/A-Port"] --> vex["Ein VM Exit tritt auf"]
    vex --> emu2["Das Gerät wird in Software nachgeahmt"]
    emu2 --> back["Rückkehr zum Gast über VM Entry"]
    back -->|Wiederholt sich bei der nächsten Portoperation| gio

Abbildung 9: Dieser Hin-und-zurück-Weg läuft hinter einem einzigen Datenträgerzugriff viele Male, und der Preis der Kompatibilität wird in Leistung bezahlt.

5.2. VMBus und VSP/VSC — Ein schneller Pfad, der Virtualisierung voraussetzt

Deshalb hat Hyper-V einen Mechanismus „synthetischer Geräte“, der unter der Annahme von Virtualisierung entworfen ist. Es gibt drei Akteure.²

• VMBus: ein logischer Kommunikationskanal zwischen Partitionen. Er stellt schnelle Kommunikation zwischen Partitionen bereit, die gemeinsamen Speicher nutzt.³
• VSP (Virtualization Service Provider): ein Dienst, der auf der Seite der Root-Partition sitzt, Geräteanforderungen vom Child entgegennimmt und sie an den Geräte-/Backend-Stack der Root-Seite weiterreicht. Eine Anforderung kann ein physisches Gerät erreichen oder von einem hostseitigen Backend wie einer virtuellen Festplatte oder einem virtuellen Switch behandelt werden.
• VSC (Virtualization Service Consumer): ein synthetischer Gerätetreiber, der ins Gastbetriebssystem auf der Child-Seite geht. Er sendet Anforderungen über VMBus an den VSP.

Beispiel: Wie WriteFile eines Gastes den Host erreicht

Eine Speicheranforderung des Gastbetriebssystems fließt in dieser Reihenfolge.

1. Das WriteFile der Gast-App steigt den E/A-Stapel des Gastkernels hinab.
2. Unten erreicht es den VSC statt echter Hardware.
3. Der VSC legt die Anforderung auf VMBus und übergibt sie dem VSP in der Root-Partition.
4. Der VSP lässt die Anforderung in den E/A-Stapel der Root-Seite fließen. In einer Konfiguration mit virtueller Festplatte (VHDX) wird sie als Schreiben in die VHDX-Datei auf dem Host behandelt und erreicht schließlich den physischen Datenträger.

Dieser Ansatz heißt Enlightened I/O (E/A, die um Virtualisierung weiß) und steigert die Effizienz, indem er die Geräteemulationsschicht umgeht.²

flowchart TB
    accTitle: E/A-Pfad eines synthetischen Geräts
    accDescr: Eine E/A-Anforderung einer App in der Child-Partition erreicht den VSC über den Gastkernel, überquert VMBus zum VSP in der Root-Partition, und auf dem E/A-Stapel der Root-Seite, in den der VSP weiterreicht, kann sie über einen physischen Gerätetreiber ein echtes Gerät erreichen oder von einem hostseitigen Backend wie einer virtuellen Festplatte oder einem virtuellen Switch behandelt werden
    app["App in der Child-Partition"] --> gk["E/A-Stapel des Gastkernels"]
    gk --> vsc["VSC (synthetischer Gerätetreiber)"]
    vsc -->|VMBus| vsp["VSP (Seite der Root-Partition)"]
    vsp --> rio["E/A-Stapel der Root-Seite"]
    rio --> pdrv["Physischer Gerätetreiber"]
    rio --> hb["Hostseitiges Backend (virtuelle Festplatte, virtueller Switch und so weiter)"]
    pdrv --> dev["Physisches Gerät"]

Abbildung 10: Bei einem synthetischen Gerät überquert die E/A des Gastes über VMBus zur Root-Partition und erreicht über den Stack der Root-Seite ein echtes Gerät oder ein hostseitiges Backend.

Ob die Datenträger-E/A oder das Netzwerk einer VM schnell ist, hängt also nicht nur von der Gastseite ab, sondern auch vom Zustand des E/A-Stapels und der Gerätetreiber auf der Seite der Root-Partition. Der Grund, warum hostseitige Beobachtung bei der Untersuchung eines Leistungsproblems einer VM unverzichtbar ist, liegt darin, dass der Pfad tatsächlich über den Host geht.

flowchart TB
    accTitle: Emulierte Geräte gegenüber synthetischen Geräten
    accDescr: Ein emuliertes Gerät ahmt echte Hardware nach, sodass die mitgelieferten Treiber des Gastes funktionieren, ist aber langsam; ein synthetisches Gerät ist ein eigens gebauter Treiber, der VMBus voraussetzt und schnell ist
    dev2{"Der Child-Partition gezeigtes Gerät"} --> emu["Emuliertes Gerät"]
    dev2 --> syn["Synthetisches Gerät"]
    emu -.-> emuP["Ahmt echte Hardware nach; Kompatibilität zuerst"]
    emuP -.-> emuC["Braucht bei jeder E/A einen Eingriff; langsam"]
    syn -.-> synP["Um VMBus herum entworfen; schnell"]
    synP -.-> synC["Verlangt einen passenden Treiber im Gast"]

Abbildung 11: Von den zwei Arten virtueller Geräte tragen emulierte Geräte die Kompatibilität direkt nach der Betriebssysteminstallation, und synthetische Geräte tragen die Leistung im Alltag.

6. Warum das auch ohne VM niemanden fremd angeht

6.1. VBS, WSL2 und Sandbox nutzen dieselbe Grundlage

Die Struktur bisher mag wie „eine Geschichte für Leute, die VMs aufsetzen“ wirken. Wie die Einleitung sagte, ist der Hypervisor unter heutigem Windows jedoch Teil des Alltags.

• Virtualisierungsbasierte Sicherheit (VBS). Sie nutzt den Windows-Hypervisor, um eine isolierte Umgebung anzulegen, und nimmt dort Sicherheitsfunktionen auf. Unter Windows 11 ist sie standardmäßig aktiviert, wenn Bedingungen wie eine Neuinstallation auf kompatibler Hardware erfüllt sind.¹ Einzelheiten stehen in Teil 2.
• WSL2. Es führt einen echten Linux-Kernel in einer leichten Utility-VM aus.⁶
• Windows Sandbox. Eine wegwerfbare Windows-Umgebung, isoliert durch den Hypervisor.⁷ Beides behandeln wir in Teil 3.

flowchart TB
    accTitle: Alltagsfunktionen, die auf demselben Hypervisor sitzen
    accDescr: Nicht nur Hyper-V-VMs, sondern auch VBS, das auf Geräten mit Bedingungen wie einer Neuinstallation standardmäßig aktiviert ist, plus WSL2 und Windows Sandbox, bauen alle auf demselben Windows-Hypervisor auf
    base["Windows-Hypervisor"] --> f1["Hyper-V-VMs"]
    base --> f2["VBS (bei Neuinstallation und Ähnlichem standardmäßig aktiviert)"]
    base --> f3["WSL2"]
    base --> f4["Windows Sandbox"]
    f2 -.-> daily["Warum es auch auf PCs ohne VM läuft"]

Abbildung 12: Es gibt eine Grundlage, und an diesem Diagramm zerfällt die Annahme „Virtualisierung ist eine Geschichte für Leute, die VMs nutzen“.

6.2. Koexistenz mit Virtualisierungssoftware von Drittanbietern

Noch etwas, das in der Praxis oft vorkommt, ist die Koexistenz mit Virtualisierungssoftware von Drittanbietern. Weil der Hypervisor die Virtualisierungsunterstützung der CPU ausschließlich nutzt, können VirtualBox und dergleichen in einer Umgebung, in der der Windows-Hypervisor läuft, nicht auf die herkömmliche Weise laufen (die Weise, die selbst die Virtualisierungsunterstützung der CPU nutzt).

Dafür steht eine öffentliche API namens Windows Hypervisor Platform bereit, und ein Virtualisierungsstack eines Drittanbieters kann laufen, indem er auf dem Windows-Hypervisor sitzt.⁸ Aktuelles VirtualBox/VMware kann dank dieses Mechanismus mit WSL2 koexistieren, aber die Leistungs- und Funktionsunterschiede beim Wechsel der Betriebsart werden manchmal als „nachdem ich Hyper-V (oder VBS) aktiviert habe, verhält sich die Virtualisierungssoftware anders“ beobachtet.

flowchart TB
    accTitle: Wer die CPU-Virtualisierungsunterstützung besitzt, und der Pfad für Virtualisierungssoftware von Drittanbietern
    accDescr: Während der Windows-Hypervisor läuft, besitzt er die CPU-Virtualisierungsunterstützung ausschließlich; Virtualisierungssoftware von Drittanbietern, die WHP unterstützt, läuft über die Windows Hypervisor Platform darauf, während Implementierungen ohne WHP-Unterstützung nicht laufen oder funktionsbeschränkt sind
    vt["CPU-Virtualisierungsunterstützung (VT-x/AMD-V)"] --> hvon{"Läuft der Windows-Hypervisor?"}
    hvon -->|Nein| direct["Software von Drittanbietern kann sie direkt nutzen"]
    hvon -->|Ja| own["Der Hypervisor hat die ausschließliche Nutzung"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["WHP-fähige Software von Drittanbietern läuft darauf"]
    third -.-> nowhp["Nicht fähige Implementierungen laufen nicht oder sind beschränkt"]

Abbildung 13: Es gibt einen Besitzer der Virtualisierungsunterstützung, und die einzige Software von Drittanbietern, die koexistieren kann, während der Hypervisor läuft, ist Software, die die öffentliche API (WHP) unterstützt.

7. Selbst nachschauen

Ob auf Ihrem PC ein Hypervisor läuft, können Sie selbst prüfen.

7.1. Hypervisor und VBS mit PowerShell prüfen

Zuerst eine Prüfung, die Sie ohne Administratorrechte ausführen können.

# Ob wir auf einem Hypervisor laufen
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

# VBS-Status (dieselbe Quelle wie „Virtualisierungsbasierte Sicherheit“ in msinfo32)
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus

VirtualizationBasedSecurityStatus gibt den Laufzustand von VBS als Zahl zurück (2 ist „Wird ausgeführt“).⁹

Eine Warnung. HypervisorPresent sagt nur „ob wir auf einem Hypervisor laufen“; Root und Child unterscheidet es nicht. Führen Sie es auf Windows in einer VM aus, kommt trotzdem True zurück, als Child-Partition. Ist es auf Windows auf einem physischen PC True, sitzt dieses Windows in der Root-Partition; Sie lesen es zusammen mit der Ausführungsumgebung.

7.2. In systeminfo „läuft“ von „Voraussetzungen“ unterscheiden

Als Nächstes der Klassiker aus der Eingabeaufforderung.

systeminfo

Schauen Sie am Ende der Ausgabe auf „Hyper-V-Anforderungen“. Auf einem Rechner, auf dem der Hypervisor noch nicht läuft, werden die einzelnen Anforderungen wie SLAT-Unterstützung und ob die Virtualisierungsunterstützung aktiviert ist einzeln aufgelistet. Auf einem Rechner, auf dem der Hypervisor bereits läuft, steht statt der Anforderungen eine einzige Zeile: „Ein Hypervisor wurde erkannt. Features, die für Hyper-V erforderlich sind, werden nicht angezeigt.“⁴

Diese eine Zeile ist daher die Aussage, dass Ihr Windows auf irgendeinem Hypervisor läuft. Wie bei HypervisorPresent müssen Sie sie auf einem physischen PC als „in der Root-Partition“ und in einer VM als „als Child-Partition“ lesen.

Selbst wenn jede systeminfo-Anforderung „Ja“ ist, heißt das nur, dass die Hardware-Seite bereit ist. Das Hyper-V-Feature selbst ist auf den Editionen Pro, Enterprise und Education verfügbar und fehlt auf Home.¹⁰

7.3. Wenn Sie auf dem Bildschirm prüfen, unterscheiden Sie, welchen Punkt Sie prüfen

In der GUI prüfen Sie in msinfo32 unter „Systemübersicht“ die Zeile „Virtualisierungsbasierte Sicherheit“. Beachten Sie, dass „Virtualisierung: Aktiviert“ im CPU-Bereich des Task-Managers nur zeigt, ob die Virtualisierungsunterstützung in der Firmware aktiviert ist, was von der Frage, ob ein Hypervisor läuft, getrennte Information ist.

flowchart TB
    accTitle: Wie Sie prüfen, ob der Hypervisor läuft
    accDescr: Sagt systeminfo, ein Hypervisor wurde erkannt, laufen Sie auf einem Hypervisor (auf einem physischen PC in der Root-Partition); erscheint die Liste der Hyper-V-Anforderungen, läuft er noch nicht, also prüfen Sie jede Anforderung wie SLAT, VM-Monitor-Mode-Erweiterungen und DEP, aber lauter Ja heißt nur, dass die Hardware-Seite bereit ist, und das Hyper-V-Feature hat zusätzlich eine Editionsanforderung
    start2["systeminfo ausführen"] --> q1{"Was zeigt das Feld Hyper-V-Anforderungen?"}
    q1 -->|Ein Hypervisor wurde erkannt| running["Hypervisor läuft (auf einem physischen PC in der Root)"]
    q1 -->|Die Anforderungen werden aufgelistet| notyet["Hypervisor läuft noch nicht"]
    notyet --> q2{"Alle Anforderungen Ja?"}
    q2 -->|Alle Ja| can["Die Hardware-Seite ist bereit"]
    can -.-> ed["Hyper-V braucht außerdem Pro/Enterprise/Education"]
    q2 -->|Einige Nein| uefi["Die betreffenden Punkte in UEFI/BIOS und dergleichen prüfen"]

Abbildung 14: Das Feld „Hyper-V-Anforderungen“ in systeminfo dient zugleich als Prüfung des Laufzustands und als Prüfung der Voraussetzungen.

8. Drei Fehldeutungen, die Sie in der Praxis vermeiden sollten

8.1. „Wir haben Hyper-V nicht aktiviert, also hat Virtualisierung mit unseren PCs nichts zu tun“

Auch wenn Sie das Hyper-V-Feature (die Verwaltungswerkzeuge und die VM-Ausführungsumgebung) nicht aktiviert haben, läuft der Windows-Hypervisor, wenn VBS aktiviert ist. Wenn Sie ein Treiberkompatibilitätsproblem, eine Leistungsprüfung oder Ärger mit Virtualisierungssoftware von Drittanbietern untersuchen, prüfen Sie HypervisorPresent und den Laufzustand von VBS, nicht ob das Feature aktiviert ist.

8.2. „Der Task-Manager sagt ‚Virtualisierung: Aktiviert‘, also läuft Hyper-V“

Diese Anzeige betrifft die Firmware-Einstellung (ob VT-x/AMD-V verfügbar ist). Den Laufzustand des Hypervisors beurteilen Sie anhand von „Ein Hypervisor wurde erkannt“ in systeminfo. Umgekehrt: Sagt der Task-Manager „Deaktiviert“, können Sie auch Hyper-V und WSL2 nicht aktivieren, prüfen Sie also zuerst die UEFI/BIOS-Einstellungen.

flowchart TB
    accTitle: Drei Prüfungen, die leicht zu verwechseln sind
    accDescr: Das Virtualisierungsfeld des Task-Managers zeigt die Firmware-Einstellung, die Liste der Windows-Funktionen den Installationszustand, und systeminfo oder HypervisorPresent den Laufzustand; jedes beantwortet eine andere Frage
    q3{"Was möchten Sie wissen?"} --> a3["Ist die Virtualisierungsunterstützung in der Firmware aktiviert?"]
    q3 --> b3["Wurde das Hyper-V-Feature installiert?"]
    q3 --> c3["Läuft der Hypervisor gerade?"]
    a3 -.-> a3t["CPU-Bereich des Task-Managers"]
    b3 -.-> b3t["Der Dialog Windows-Funktionen"]
    c3 -.-> c3t["systeminfo und HypervisorPresent"]

Abbildung 15: Das sind drei unabhängige Fragen, und die anderen zwei aus einer beliebigen Anzeige zu folgern ist eine Fehldeutung.

8.3. „Wenn die VM langsam ist, ist es ein Problem des Gastbetriebssystems“

E/A synthetischer Geräte überquert VMBus zum VSP in der Root-Partition und geht durch den Geräte-/Backend-Stack der Root-Seite (physische Treiber plus Verarbeitung von virtuellem Switch und virtueller Festplatte). Beobachten Sie nur Zähler innerhalb des Gastes, finden Sie einen Engpass nicht, der in hostseitigem Speicher oder einer NIC sitzt. Das Prinzip bei Leistungsproblemen von VMs ist, von beiden Seiten zu beobachten: dem Gast und dem Host (der Root-Partition).

9. Zusammenfassung

• Wenn Sie Hyper-V aktivieren, läuft der Hypervisor direkt auf der Hardware und das Host-Windows als Root-Partition.²
• Der Kernel des Gastbetriebssystems läuft weiter auf Ring 0, und nur als Intercept konfigurierte Operationen plus Ausnahmen werden über einen VM Exit an den Hypervisor übergeben. Gewöhnliche Speicherzugriffe gehen über SLAT-Übersetzung durch.
• Nur die Root-Partition hält physische Gerätetreiber und den Virtualisierungs-Verwaltungsstack und legt Child-Partitionen über Hypercalls an.²
• Speicher wird zu einer zweistufigen Übersetzung GVA→GPA→SPA, und die zweite Stufe behandelt SLAT (EPT/RVI) in Hardware. Aktuelles Hyper-V verlangt SLAT.⁴
• Geräte-E/A wird vom Pfad synthetischer Geräte VSC→VMBus→VSP beherrscht, und die Leistung hängt auch vom E/A-Stapel der Host-Seite ab.²
• Unter Windows 11 ist es, weil VBS auf Geräten, die Bedingungen wie eine Neuinstallation erfüllen, standardmäßig aktiviert ist, nicht ungewöhnlich, dass der Hypervisor auch auf einem PC läuft, der nie eine VM nutzt.¹ Den Laufzustand können Sie mit HypervisorPresent und systeminfo prüfen.

Das Gesamtbild von Teil 1 verdichtet sich in dieses eine Diagramm.

flowchart TB
    accTitle: Das Gesamtbild von Teil 1
    accDescr: Der Hypervisor sitzt unter der Root-Partition und den Child-Partitionen; CPUs werden durch Planen virtueller Prozessoren zugeteilt (VM Exits nur bei konfigurierten Intercepts und Ausnahmen), Speicher wird durch zweistufige SLAT-Übersetzung vermittelt, E/A synthetischer Geräte wird über VMBus weitergeleitet und vom VSP der Root-Partition behandelt, und emulierte Geräte und Discrete Device Assignment haben andere Pfade
    up["Root-Partition und Child-Partitionen"] --> hvS["Hypervisor"]
    hvS --> cpuS["CPU: teilt virtuelle Prozessoren zu"]
    hvS --> memS["Speicher: zweistufige Übersetzung über SLAT"]
    hvS --> devS["Geräte: synthetische E/A über VMBus weitergeleitet"]
    cpuS -.-> cpuN["VM Exit nur bei Eingriff"]
    devS --> vspS["Behandelt vom VSP der Root-Seite"]
    devS -.-> devN["Emulierte Geräte und DDA nehmen andere Pfade"]

Abbildung 16: CPU-Planung und Speicherübersetzung übernimmt der Hypervisor direkt (VM Exits nur bei Eingriff), und E/A synthetischer Geräte vermittelt die Root-Partition (der VSP) jenseits von VMBus.

Weiter in Teil 2, „Speicher, den selbst der Kernel nicht sieht — VBS, HVCI und Credential Guard“.

Wir nehmen den roten Faden dieses Artikels auf, dass der Hypervisor die SLAT-Übersetzungstabellen hält, und verfolgen, wie Windows „Speicher anlegt, den weder ein Administrator noch der Kernel lesen kann“.

Weiterführende Artikel

• Die Tiefen des Windows-Speichers (Teil 1) — Der Moment, in dem eine virtuelle Adresse zu physischem RAM wird: Ein Seitenfehler von Anfang bis Ende
• Was bedeutet Windows’ „Speicherauslastung“ eigentlich? — Working Set, Private Bytes, Commit und die Auslagerungsdatei richtig lesen
• Wie Sie mit Windows Sandbox die App-Validierung beschleunigen
• Windows-Prozessorzeitplanung – Hintergrunddienste und P-/E-Kerne

Zugehörige Beratungsfelder

KomuraSoft LLC übernimmt den Entwurf von Validierungsumgebungen für Windows-Anwendungen, Leistungsuntersuchungen in virtualisierten Umgebungen sowie die Analyse von Kompatibilitätsproblemen bei Treibern und Peripherie.

• Windows-Anwendungsentwicklung
• Fehleruntersuchung und Ursachenanalyse
• Weiternutzung und Migration von Altbeständen
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Wenn Sie Hyper-V aktivieren, wo läuft das Host-Windows eigentlich?

Der Hypervisor steuert unmittelbar, wie physische CPUs und Speicher zugeteilt werden, und das Host-Windows läuft in einer besonderen Partition, der Root-Partition. Die Steuerung physischer Geräte übernehmen normalerweise Treiber auf der Seite der Root-Partition. Die Root-Partition hält die Gerätetreiber und den Virtualisierungs-Verwaltungsstack, aber die Herrschaft über die physischen CPUs liegt beim Hypervisor.

Bedeutet „Virtualisierung: Aktiviert“ im Task-Manager, dass Hyper-V läuft?

Nein. Diese Anzeige zeigt, ob die Virtualisierungsunterstützung der CPU (Intel VT-x/AMD-V) in der Firmware aktiviert ist. Ob tatsächlich ein Hypervisor läuft, sehen Sie an der Meldung „Ein Hypervisor wurde erkannt“ in systeminfo oder an HypervisorPresent von Win32_ComputerSystem.

Warum läuft der Hypervisor, obwohl ich nie eine VM angelegt habe?

Unter Windows 11 ist virtualisierungsbasierte Sicherheit (VBS) auf Geräten, die die Bedingungen erfüllen — etwa eine Neuinstallation auf kompatibler Hardware — standardmäßig aktiviert, und VBS baut auf dem Windows-Hypervisor auf. Dasselbe gilt, wenn Sie WSL2 oder Windows Sandbox nutzen. Es ist nicht ungewöhnlich, dass der Hypervisor unabhängig davon läuft, ob jemand VMs nutzt.

Was ist SLAT, und warum ist es für Hyper-V erforderlich?

SLAT (Second Level Address Translation) ist der Mechanismus, mit dem die CPU Gast-Physikadressen in tatsächliche Physikadressen übersetzt; Intel EPT und AMD RVI sind die Umsetzungen. Ohne ihn müsste der Hypervisor die Übersetzungstabellen in Software pflegen, was aus Leistungssicht nicht realistisch ist; aktuelles Hyper-V behandelt es daher als harte Anforderung.

Wenn ich Hyper-V aktiviere, hören VirtualBox und VMware auf zu funktionieren?

Weil der Hypervisor die Virtualisierungsunterstützung der CPU ausschließlich nutzt, kann ein Hypervisor eines Drittanbieters auf die herkömmliche Weise nicht mehr laufen. Aktuelles VirtualBox und VMware haben jedoch einen Modus, der auf dem Windows-Hypervisor läuft (über die Windows Hypervisor Platform), sodass aktuelle Versionen beider koexistieren können.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.