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

Der Hypervisor übernimmt die direkte Kontrolle darüber, 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 das Eigentum an den physischen CPUs liegt beim Hypervisor.

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

Nein. Diese Anzeige zeigt, ob die Virtualisierungserweiterungen der CPU (Intel VT-x/AMD-V) in der Firmware aktiviert sind. Ob tatsächlich ein Hypervisor läuft, sehen Sie an „A hypervisor has been detected“ in systeminfo oder an Win32_ComputerSystem.HypervisorPresent.

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 ohne jeden Zusammenhang mit jemandem läuft, der 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 Virtualisierungserweiterungen der CPU ausschließlich nutzt, kann ein Drittanbieter-Hypervisor nicht auf die herkömmliche Weise 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.

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

22. Aug 2026 02:00 · Go Komura · Windows, Virtualisierung, Hyper-V, Hypervisor, SLAT, VMBus

Öffnen Sie die Systeminformationen (msinfo32) unter Windows 11, und Sie sehen oft „Wird ausgeführt“ im Feld „Virtualisierungsbasierte Sicherheit“ — auch auf einem Rechner, auf dem Sie nie eine VM angelegt haben.

Was das bedeutet, ist die folgende Tatsache. Auf diesem PC läuft das Host-Windows selbst bereits auf einem Hypervisor. „Virtualisierung“ ist keine Technik mehr nur für Leute, die in Hyper-V Manager VMs anlegen. Unter Windows 11 ist virtualisierungsbasierte Sicherheit (VBS) auf Konfigurationen, die die Bedingungen erfüllen — etwa eine Neuinstallation auf kompatibler Hardware¹ — standardmäßig aktiviert, und sowohl WSL2 als auch Windows Sandbox bauen auf demselben Windows-Hypervisor auf. Unter dem Windows, das Sie jeden Tag nutzen, liegt bereits eine weitere Softwareschicht.

Diese Reihe „Die Tiefen der Windows-Virtualisierung“ folgt dem, was in dieser Schicht geschieht, und beginnt bei den Grundlagen.

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

Teil 1 (dieser Artikel): Der Hypervisor und Partitionen
Wir verfolgen, wo das Host-Windows landet, wenn Sie Hyper-V aktivieren.
Teil 2: Speicher, den selbst der Kernel nicht sieht — VBS, HVCI und Credential Guard
Wir verfolgen, wohin Windows Geheimnisse legt, die weder ein Administrator noch der Kernel lesen kann.
Teil 3: Virtuelle Maschinen, die in Sekunden starten — WSL2, Windows Sandbox und Container
Wir verfolgen anhand der gemeinsamen Nutzung von Speicher und Abbildern, warum WSL2 und Sandbox leicht sind, obwohl eine volle VM schwer ist.

Die Frage, die Teil 1 beantwortet, ist nur eine.

Wenn Sie Hyper-V aktivieren, wo landet das Host-Windows?

Zielgruppe sind Entwickler und Betreiber, die Hyper-V, WSL2 oder Windows Sandbox nutzen und von der Mechanik her verstehen wollen, was darunter läuft. Voraussetzungen sind x64 Windows 10/11 oder aktuelles Windows Server (die Behandlung von Ringen, VT-x/AMD-V und EPT/RVI in diesem Artikel setzt x64 voraus; Arm64 nutzt einen anderen Mechanismus wie Exception Levels). Erforderlicher Hintergrund ist etwa die Unterscheidung zwischen Kernelmodus und Benutzermodus; Sie brauchen keine VM-Betriebserfahrung und kein Wissen über Hypervisor-Entwicklung. Die Schwierigkeit ist mittel. Wir behandeln den Begriff der CPU-Virtualisierungserweiterungen, gehen aber nicht in Befehlssatzdetails.

1. Zuerst das Fazit

Wenn Leute Hyper-V hören, stellen sie sich vielleicht „VM-laufende 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, die zwischen Hardware und Betriebssystem sitzt, isolierte Ausführungsumgebungen namens „Partitionen“ anlegt und den Zugriff auf die Hardware vermittelt.² Die, in die das Host-Windows geht, ist die Root-Partition; die, in die VMs gehen, sind Child-Partitionen. Die Root-Partition wird besonders behandelt (sie hat direkten Zugriff auf physische Geräte und hält den Verwaltungsstack), aber in dem Sinn, dass 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 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 es sich nach dem Aktivieren nicht 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 nehmen wir dieses eine Diagramm entlang dreier Achsen auseinander: CPU, Speicher und Geräte-I/O.

2. Von der CPU — Ein weiteres Privileg unter den Ringen

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 OS-Kernel, 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 OS-Kernel, die Ring 0 verlangen
    accDescr: Sowohl Host- als auch Gast-Kernel 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 Steuerung der physischen CPU"]
    k2["Gast-Kernel（nimmt Ring 0 an）"] --> want
    want --> conflict["Herkömmliche Ringe 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. Virtualisierungserweiterungen — Ein Modus, der dem Hypervisor vorbehalten ist

Was dieses Problem löst, sind die Virtualisierungserweiterungen der CPU (Intel VT-x/AMD-V). Hyper-V verlangt einen Prozessor, der dieses Merkmal hat.² Virtualisierungserweiterungen fügen 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 Gast-Kernel 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 Gast-Kernel und Apps laufen auf Ring 0 und Ring 3 im Gastmodus; gewöhnliche Speicherzugriffe gehen über SLAT-Übersetzung durch, während konfigurierte Intercepts 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 Steuerung）"]
    exitEv --> hvp["Hypervisor behandelt es"]
    hvp --> entry["Rückkehr zum Gast über VM Entry"]
    entry --> guest

Abbildung 3: Das Gast-Betriebssystem 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 Page Fault 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-Server-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, während bei Typ-1-Hyper-V die Reihenfolge umgekehrt ist und das Host-Betriebssystem selbst auf der Schicht eine Stufe darunter sitzt.

Auf einer Boot-Zeitachse betrachtet sieht die Änderung, die beim Aktivieren geschieht, 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 Ähnliches starten danach
    poweron["Einschalten und Boot-Start"] --> bhv["Hypervisor startet zuerst"]
    bhv --> broot["Host-Windows startet als Root-Partition"]
    broot --> blater["VMs, VBS, WSL2 und so weiter starten darauf"]
    broot -.-> feel["Die Nutzererfahrung bleibt gleich"]

Abbildung 5: Die Umkehrung der Reihenfolge ist bereits fertig, bevor der Anmeldebildschirm erscheint, und das Host-Betriebssystem kommt von Anfang an auf dem Hypervisor hoch.

3. Partitionen — Die Einheit der Isolierung

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 Ähnliches leben im Windows innerhalb der Root-Partition, nicht im Hypervisor. Hyper-V unter Windows Server hat eine Konfiguration, die ein bestimmtes PCIe-Gerät direkt einer Child-Partition zuweist (Discrete Device Assignment); in dem Fall lässt die Root dieses Gerät los (das gibt es unter Client-Windows nicht).⁴
Der Virtualisierungs-Verwaltungsstack. VMMS (Virtual Machine Management Service), das Anlegen, Starten und Stoppen von VMs steuert, und der Worker-Prozess pro VM (vmwp.exe) laufen im Benutzermodus in der Root-Partition.⁵ Diese gehören zu den VM-Verwaltungsmerkmalen von Hyper-V, können also auf einem Host fehlen, auf dem der Hypervisor nur 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).²

Dieser Entwurf hat einen Grund. Legen Sie jeden Gerätetreiber in den Hypervisor selbst, wird der Hypervisor riesig und die Zahl der Fehler und Angriffseingänge wächst. Der Hypervisor beschränkt sich auf die minimale Arbeit, CPUs und Speicher zu vermitteln, und überlässt die Pflege 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 normalerweise nur virtuelle Geräte, und unter Discrete Device Assignment auf Windows Server greift sie auf das zugewiesene Gerät direkt 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 nur virtuelle Geräte sichtbar"]
    end
    vmms -->|Anlegen und verwalten über Hypercalls| childp
    hv2["Hypervisor（beschränkt sich auf Vermittlung von CPU und Speicher）"] --- rootp
    hv2 --- childp

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

3.2. Die Welt, gesehen aus einer Child-Partition

Das Gast-Betriebssystem in einer Child-Partition kann physische Hardware in der üblichen Konfiguration virtueller Geräte 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 erscheint, und virtuelle Geräte. Anfragen 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 behandelt dagegen der Hypervisor direkt, ohne über die Root zu gehen. Was die Root vermittelt, ist Geräte-I/O, nicht jede physische Ressource.

flowchart TB
    accTitle: Die Welt, gesehen aus einer Child-Partition
    accDescr: Was das Gast-Betriebssystem sieht, sind virtuelle Prozessoren, ein der Partition privater Speicherraum und virtuelle Geräte; Anfragen an virtuelle Geräte werden über VMBus und Ähnliches an die Root-Partition weitergeleitet, CPU-Zeit und Speicherübersetzung behandelt der Hypervisor direkt, und in einer Discrete-Device-Assignment-Konfiguration auf Windows Server werden nur zugewiesene Geräte direkt angesprochen
    gos2["Gast-OS（Child）"] --> vcpu["Virtuelle Prozessoren"]
    gos2 --> rest{"Speicher oder Geräte?"}
    rest --> gpa2["Privater Speicherraum"]
    rest --> vdev2["Virtuelle Geräte"]
    vdev2 --> rootx["Weitergeleitet an die Root"]
    rootx -.-> vbus["Über VMBus und Ähnliches"]
    gos2 -.-> phys2["Phys. CPU, RAM, Geräte"]
    phys2 -.-> hid["Nicht direkt sichtbar"]
    phys2 -.-> dda2["DDA: zugewiesene Geräte"]
    dda2 -.-> ddaN["Windows Server"]
    vcpu ~~~ phys2

Abbildung 7: In der üblichen Konfiguration virtueller Geräte 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, ist, dass für eine App, die auf dem Host-Windows läuft, diese Struktur fast transparent ist. Win32-API-Aufrufe und die Behandlung von Page Faults verarbeitet weiterhin der Windows-Kernel innerhalb 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 gewinnt eine weitere Stufe

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 („The Moment a Virtual Address Becomes Physical RAM“). In einer virtualisierten Umgebung kommt unter dieser Übersetzung eine weitere Stufe hinzu, und es gibt drei Arten von Adressen.

Adresse	Abkürzung	Wer sie verwaltet
Gast-Virtuelladresse	GVA	Die Seitentabelle des Gast-OS
Gast-Physikadresse	GPA	Die Adresse, die das Gast-OS für „physisch“ hält
System-Physikadresse	SPA	Der Hypervisor (der tatsächliche Ort im RAM)

Das Gast-Betriebssystem übersetzt GVA nach GPA mit seiner eigenen Seitentabelle. Die GPA, die der Gast sieht, ist jedoch keine echte physische Adresse; sie ist ein privater Speicherraum, der jeder Partition gehört.² GPA auf den tatsächlichen Ort im RAM (SPA) abzubilden ist die Aufgabe des Hypervisors.

4.2. SLAT — Zweistufige Übersetzung in Hardware

Wenn Sie diese Übersetzung der zweiten Stufe allein in Software tun, muss der Hypervisor jede Aktualisierung der Gast-Seitentabelle einzeln verfolgen, was aus Leistungssicht nicht realistisch ist. Also 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 64-Bit-Prozessor mit SLAT.⁴

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

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

SLAT ist kein Merkmal, das nur für die Ausführungseffizienz von VMs existiert. 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 Übersetzung der zweiten Stufe hält. Das wird zu einem roten Faden der ganzen Reihe, also merken Sie sich nur einen Punkt: „der Eigentümer der Übersetzungstabellen ist der Hypervisor“.

5. Vom Geräte-I/O — VMBus und zwei Arten von Geräten

5.1. Die Grenzen emulierter Geräte

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

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

Abbildung 9: Dieses Hin und Zurück 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 für Virtualisierung entworfen ist

Also 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 wohnt, Geräteanfragen vom Child entgegennimmt und sie an den Geräte-/Backend-Stack auf der Root-Seite brückt. Eine Anfrage kann ein physisches Gerät erreichen oder von einem Backend auf der Host-Seite behandelt werden, etwa einer virtuellen Festplatte oder einem virtuellen Switch.
VSC (Virtualization Service Consumer): ein synthetischer Gerätetreiber, der ins Gast-Betriebssystem auf der Seite der Child-Partition geht. Er sendet Anfragen über VMBus an den VSP.

Nehmen wir eine Speicheranfrage des Gast-Betriebssystems als Beispiel, sieht der Ablauf so aus. Das WriteFile der Gast-App steigt den I/O-Stack des Gast-Kernels hinab und erreicht unten den VSC (statt echter Hardware). Der VSC legt die Anfrage auf VMBus und übergibt sie dem VSP in der Root-Partition, und der VSP lässt die Anfrage in den I/O-Stack auf der Root-Seite fließen. In einer Konfiguration mit virtueller Festplatte (VHDX) wird dieses Schreiben als Schreiben in eine VHDX-Datei auf dem Host behandelt und erreicht schließlich den physischen Datenträger. Dieser Ansatz heißt Enlightened I/O (I/O, das sich der Virtualisierung bewusst ist) und hebt die Effizienz, indem er die Geräteemulationsschicht umgeht.²

flowchart TB
    accTitle: I/O-Pfad für ein synthetisches Gerät
    accDescr: Eine I/O-Anfrage von einer App in der Child-Partition erreicht den VSC durch den Gast-Kernel, überquert VMBus zum VSP in der Root-Partition und kann auf dem I/O-Stack der Root-Seite, in den der VSP brückt, über einen physischen Gerätetreiber ein echtes Gerät erreichen oder von einem Backend auf der Host-Seite wie einer virtuellen Festplatte oder einem virtuellen Switch behandelt werden
    app["App in der Child-Partition"] --> gk["I/O-Stack des Gast-Kernels"]
    gk --> vsc["VSC（synthetischer Gerätetreiber）"]
    vsc -->|VMBus| vsp["VSP（Seite der Root-Partition）"]
    vsp --> rio["I/O-Stack der Root-Seite"]
    rio --> pdrv["Physischer Gerätetreiber"]
    rio --> hb["Backend auf der Host-Seite（virtuelle Festplatte, virtueller Switch und so weiter）"]
    pdrv --> dev["Physisches Gerät"]

Abbildung 10: Mit einem synthetischen Gerät überquert Gast-I/O über VMBus zur Root-Partition und erreicht über den Stack der Root-Seite ein echtes Gerät oder ein Backend auf der Host-Seite.

Mit anderen Worten hängt es, ob Datenträger-I/O oder Netzwerkbetrieb einer VM schnell ist, nicht nur von der Gast-Seite ab, sondern auch vom Zustand des I/O-Stacks und der Gerätetreiber auf der Seite der Root-Partition. Der Grund, warum Beobachtung auf der Host-Seite unverzichtbar ist, wenn Sie ein Leistungsproblem einer VM untersuchen, ist, dass der Pfad tatsächlich durch den Host geht.

flowchart TB
    accTitle: Emulierte Geräte gegenüber synthetischen Geräten
    accDescr: Ein emuliertes Gerät ahmt echte Hardware nach, sodass Inbox-Gasttreiber funktionieren, ist aber langsam; ein synthetisches Gerät ist ein eigens gebauter Treiber, der VMBus voraussetzt, und ist schnell
    dev2{"Gerät, das der Child-Partition gezeigt wird"} --> emu["Emuliertes Gerät"]
    dev2 --> syn["Synthetisches Gerät"]
    emu -.-> emuP["Ahmt echte Hardware nach; Kompatibilität zuerst"]
    emuP -.-> emuC["Braucht Eingriff bei jedem I/O; 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 OS-Installation, und synthetische Geräte tragen die Leistung im Alltag.

6. Warum das nicht das Problem anderer ist, auch wenn Sie nie eine VM nutzen

Die Struktur bisher mag wie „eine Geschichte für Leute, die VMs aufstellen“ aussehen. Wie die Eröffnung sagte, ist der Hypervisor auf aktuellem Windows jedoch Teil des Alltags.

Virtualisierungsbasierte Sicherheit (VBS). Sie nutzt den Windows-Hypervisor, um eine isolierte Umgebung anzulegen, und bringt dort Sicherheitsmerkmale unter. 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.⁷ Beide behandelt Teil 3.

flowchart TB
    accTitle: Alltagsmerkmale, die auf demselben Hypervisor sitzen
    accDescr: Nicht nur Hyper-V-VMs, sondern auch VBS, das auf Geräten, die Bedingungen wie eine Neuinstallation erfüllen, 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（Standard bei Neuinstallation）"]
    base --> f3["WSL2"]
    base --> f4["Windows Sandbox"]
    f2 -.-> daily["Warum es auf PCs ohne VM läuft"]

Abbildung 12: Es gibt eine Grundlage, und an dieser Abbildung zerbricht die Annahme „Virtualisierung ist eine Geschichte für Leute, die VMs nutzen“.

Noch etwas, worauf Leute in der Praxis oft treten, ist die Koexistenz mit Virtualisierungssoftware von Drittanbietern. Weil der Hypervisor die Virtualisierungserweiterungen der CPU ausschließlich nutzt, können VirtualBox und Ähnliches in einer Umgebung, in der der Windows-Hypervisor läuft, nicht auf die herkömmliche Weise laufen (die Weise, die selbst die Virtualisierungserweiterungen der CPU nutzt). Dafür ist eine öffentliche API namens Windows Hypervisor Platform vorgesehen, 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 Leistungs- und Merkmalsunterschiede, die mit dem Wechsel der Modi kommen, werden manchmal als „nachdem ich Hyper-V (oder VBS) aktiviert habe, hat sich die Virtualisierungssoftware anders verhalten“ beobachtet.

flowchart TB
    accTitle: Wer die CPU-Virtualisierungserweiterungen besitzt, und der Pfad für Virtualisierungssoftware von Drittanbietern
    accDescr: Während der Windows-Hypervisor läuft, besitzt er die CPU-Virtualisierungserweiterungen ausschließlich; Virtualisierungssoftware von Drittanbietern, die WHP unterstützt, läuft darüber über die Windows Hypervisor Platform, während Umsetzungen, die WHP nicht unterstützen, nicht laufen können oder merkmalsbegrenzt sind
    vt["CPU-Virtualisierungserweiterungen（VT-x/AMD-V）"] --> hvon{"Läuft der Windows-Hypervisor?"}
    hvon -->|Nein| direct["Drittanbietersoftware kann sie direkt nutzen"]
    hvon -->|Ja| own["Der Hypervisor hat ausschließliche Nutzung"]
    own --> whp["Windows Hypervisor Platform"]
    whp --> third["WHP-fähige Drittanbietersoftware läuft darauf"]
    third -.-> nowhp["Nicht fähige Umsetzungen können nicht laufen oder sind begrenzt"]

Abbildung 13: Es gibt einen Eigentümer der Virtualisierungserweiterungen, und die einzige Drittanbietersoftware, die koexistieren kann, während der Hypervisor läuft, ist Software, die die öffentliche API (WHP) unterstützt.

7. Selbst nachsehen

Sie können auf Ihrem eigenen Rechner bestätigen, ob ein Hypervisor läuft.

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

# Whether we are running on top of a hypervisor
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

# VBS status (same source as "Virtualization-based security" 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 Vorsicht. Alles, was HypervisorPresent Ihnen sagt, ist „ob wir auf einem Hypervisor laufen“; es unterscheidet nicht Root von Child. Führen Sie es auf Windows innerhalb einer VM aus, gibt es trotzdem True zurück, als Child-Partition. Ist es auf Windows auf einem physischen PC True, liegt dieses Windows in der Root-Partition — Sie lesen es zusammen mit der Ausführungsumgebung.

Als Nächstes der Klassiker von einer Eingabeaufforderung.

systeminfo

Schauen Sie auf „Hyper-V Requirements“ am Ende der Ausgabe. Auf einem Rechner, auf dem der Hypervisor noch nicht läuft, sind die einzelnen Anforderungen — SLAT-Unterstützung, ob Virtualisierungserweiterungen aktiviert sind, und so weiter — aufgelistet. Auf einem Rechner, auf dem der Hypervisor bereits läuft, erhalten Sie statt der Anforderungen eine einzige Zeile: „A hypervisor has been detected. Features required for Hyper-V will not be displayed.“⁴ Diese eine Zeile ist daher eine Aussage, dass Ihr Windows auf irgendeinem Hypervisor läuft. Wie bei HypervisorPresent müssen Sie sie als „innerhalb der Root-Partition“ auf einem physischen PC oder „als Child-Partition“ innerhalb einer VM lesen.

Auch wenn jede systeminfo-Anforderung „Yes“ ist, bedeutet das nur, dass die Hardware-Seite bereit ist. Das Hyper-V-Merkmal selbst gibt es auf den Editionen Pro, Enterprise und Education, und nicht auf Home.¹⁰

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

flowchart TB
    accTitle: Wie Sie prüfen, ob der Hypervisor läuft
    accDescr: Sagt systeminfo, ein Hypervisor wurde erkannt, laufen Sie auf einem Hypervisor（innerhalb der Root-Partition auf einem physischen PC）; erscheint die Liste Hyper-V Requirements, läuft er noch nicht, also prüfen Sie jede Anforderung wie SLAT, VM Monitor Mode Extensions und DEP, aber alle Yes bedeutet nur, dass die Hardware-Seite bereit ist, und das Hyper-V-Merkmal hat außerdem eine Editionsanforderung
    start2["systeminfo ausführen"] --> q1{"Anforderungsfeld?"}
    q1 -->|Detected| running["Hypervisor läuft"]
    running -.-> runN["Innerhalb der Root"]
    runN -.-> runN2["auf einem physischen PC"]
    q1 -->|Listed| notyet["Läuft noch nicht"]
    notyet --> q2{"Alle Anforderungen Yes?"}
    q2 -->|Alle Yes| can["Hardware-Seite ist bereit"]
    can -.-> ed["Braucht Pro / Ent / Edu"]
    q2 -->|Einige No| uefi["UEFI/BIOS-Punkte prüfen"]

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

8. Drei Fehldeutungen, die Sie in der Praxis vermeiden

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

Auch wenn Sie das Hyper-V-Merkmal (die Verwaltungswerkzeuge und die VM-Ausführungsumgebung) nicht aktiviert haben, läuft der Windows-Hypervisor, wenn VBS aktiviert ist. Wenn Sie ein Treiberkompatibilitätsproblem, einen Leistungstest oder Ärger mit Virtualisierungssoftware von Drittanbietern untersuchen, prüfen Sie HypervisorPresent und den Laufzustand von VBS — nicht, ob das Merkmal 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). Beurteilen Sie den Laufzustand des Hypervisors anhand von „A hypervisor has been detected“ in systeminfo. Umgekehrt: Sagt der Task-Manager „Deaktiviert“, können Sie auch Hyper-V oder WSL2 nicht aktivieren, also prüfen Sie 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 Windows-Features den Installationszustand und systeminfo oder HypervisorPresent den Laufzustand; jedes beantwortet eine andere Frage
    q3{"Welche Frage?"}
    q3 --> fw{"Firmware oder Windows?"}
    q3 --> c3["Läuft der Hypervisor?"]
    fw --> a3["Firmware-Erweiterungen?"]
    fw --> b3["Hyper-V-Merkmal an?"]
    a3 -.-> a3t["Task-Manager CPU-Bereich"]
    b3 -.-> b3t["Windows-Features-UI"]
    c3 -.-> c3t["systeminfo"]
    c3 -.-> c3tp["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 Gast-Betriebssystems“

I/O 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 Host-seitigem 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 Gast-Betriebssystems läuft weiter auf Ring 0, und nur als Intercepts 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-I/O wird vom Pfad synthetischer Geräte VSC→VMBus→VSP beherrscht, und die Leistung hängt auch vom I/O-Stack 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 bestätigen.

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, I/O 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 + Child-Partitionen"] --> hvS["Hypervisor"]
    hvS --> cpuS["CPU: VPs planen"]
    hvS --> memS["Speicher: SLAT"]
    cpuS -.-> cpuN["VM Exit bei Intercept"]
    memS -.-> memN["Zweistufige Übersetzung"]
    memS ~~~ devS
    devS["Geräte: VMBus-I/O"] --> vspS["VSP der Root-Seite behandelt"]
    devS -.-> devN["Emuliert / DDA: andere"]

Abbildung 16: CPU-Planung und Speicherübersetzung behandelt der Hypervisor direkt (VM Exits nur bei Eingriff), und I/O 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

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.

Quellen

Microsoft Learn, Silicon assisted security. Dazu, dass VBS Hardware-Virtualisierung nutzt, um den Secure Kernel vom gewöhnlichen Betriebssystem zu isolieren, und dazu, dass VBS und HVCI auf Geräten, die die Voraussetzungen erfüllen, bei einer Neuinstallation von Windows 11 standardmäßig aktiviert sind. ↩ ↩² ↩³
Microsoft Learn, Hyper-V Architecture. Dazu, dass der Hypervisor Partitionen als Isolierungseinheit bereitstellt; dazu, dass die Root-Partition Child-Partitionen über die Hypercall-API anlegt; dazu, dass Partitionen in einem privaten virtuellen Speicherraum ohne direkten Zugriff auf physische Prozessoren laufen; zu den Rollen von VMBus, VSP, VSC und Enlightened I/O; sowie dazu, dass Hardware-Virtualisierungserweiterungen (Intel VT/AMD-V) erforderlich sind. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²
Microsoft Learn, Hyper-V architecture (Performance Tuning). Dazu, dass Hyper-V ein Typ-1-Hypervisor ist, die Root-Partition physische I/O-Geräte besitzt und VMBus hochleistungsfähige Kommunikation zwischen Partitionen bereitstellt, die gemeinsamen Speicher nutzt. ↩ ↩²
Microsoft Learn, System requirements for Hyper-V on Windows and Windows Server. Dazu, dass ein 64-Bit-Prozessor mit SLAT und VM Monitor Mode Extensions erforderlich sind; dazu, dass Sie die Erfüllung der Anforderungen im Feld „Hyper-V Requirements“ von systeminfo bestätigen können; dazu, dass „A hypervisor has been detected“ angezeigt wird, während ein Hypervisor läuft; sowie dazu, dass Discrete Device Assignment ein bestimmtes Gerät direkt einer Child-Partition zuweisen kann. ↩ ↩² ↩³ ↩⁴
Microsoft Learn, Appendix B: Hyper-V Architecture and Feature Overview. Dazu, dass VMMS (Virtual Machine Management Service) den Zustand von VMs in Child-Partitionen verwaltet und für jede VM ein Worker-Prozess (VMWP) im Benutzermodus in der Root-Partition startet. ↩
Microsoft Learn, Comparing WSL Versions. Dazu, dass WSL2 einen echten Linux-Kernel in einer leichten Utility-VM ausführt, und zu Vorsichtshinweisen zur gemeinsamen Nutzung mit aktuellem VMware und VirtualBox. ↩
Microsoft Learn, Windows Sandbox architecture. Dazu, dass Windows Sandbox eine leichte Windows-Umgebung ist, die Containertechnik mit Isolierung durch den Hypervisor verbindet. ↩
Microsoft Learn, Windows Hypervisor Platform. Dazu, dass eine Benutzermodus-API bereitsteht, damit ein Virtualisierungsstack eines Drittanbieters Partitionen auf dem Windows-Hypervisor anlegen und verwalten kann. ↩
Microsoft Learn, Enable Hotpatch for Azure Arc-enabled servers. Dazu, dass Sie den Laufzustand von VBS (virtual secure mode) über VirtualizationBasedSecurityStatus auf der Klasse Win32_DeviceGuard bestätigen können. ↩
Microsoft Learn, Install Hyper-V. Dazu, dass Hyper-V unter Windows 10/11 Pro oder Enterprise und Ähnlichem aktivierbar ist und auf der Home-Edition nicht installierbar ist. ↩

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

Die Tiefen der Windows-Virtualisierung (Teil 3) — Virtuelle Maschinen, die in Sekunden starten: Warum WSL2, Windows Sandbox und Container so leicht sind

Warum starten WSL2 und Windows Sandbox in Sekunden und fühlen sich so leicht an? Dieser Artikel erklärt die Mechanismen, von dynamischen ...

Artikel lesen

Die Tiefen der Windows-Virtualisierung (Teil 2) — Speicher, den selbst der Kernel nicht sieht: Wie VBS, HVCI und Credential Guard funktionieren

Bei einer Neuinstallation auf kompatibler Hardware ist VBS standardmäßig aktiviert und nutzt Hypervisor und SLAT, um Isolierung stärker a...

Artikel lesen

Die Win32-Thread-Pool-API — Nebenläufigkeit ohne eigene Threads, über CreateThreadpoolWork

Verstreuen Sie CreateThread-Aufrufe über Ihren nativen Code? Dieser Artikel erklärt die in Vista neu entworfene Win32-Thread-Pool-API — d...

Artikel lesen

Named Pipes in der Praxis — Windows' Standard-IPC von Entwurf bis Sicherheit

Ein Praxisleitfaden zu Named Pipes, der Standard-Prozesskommunikation unter Windows. Der Artikel ordnet anhand von Primärquellen die Wahl...

Artikel lesen

Was bedeutet Windows' „Speicherauslastung“ eigentlich? — Working Set, Private Bytes, Commit und die Auslagerungsdatei richtig lesen

Der Speicherwert im Task-Manager, Working Set, Private Bytes und Commit sind nicht dasselbe. Dieser Artikel erklärt das Verhältnis von vi...

Artikel lesen

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Windows-App-Entwicklung

Geschäftsanwendungen, Geräteintegration und Kommunikationstools von den Anforderungen bis zur Umsetzung.

Leistung ansehen Kontakt

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 übernimmt die direkte Kontrolle darüber, 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 das Eigentum an den physischen CPUs liegt beim Hypervisor.
Bedeutet „Virtualisierung: Aktiviert“ im Task-Manager, dass Hyper-V läuft?: Nein. Diese Anzeige zeigt, ob die Virtualisierungserweiterungen der CPU (Intel VT-x/AMD-V) in der Firmware aktiviert sind. Ob tatsächlich ein Hypervisor läuft, sehen Sie an „A hypervisor has been detected“ in systeminfo oder an Win32_ComputerSystem.HypervisorPresent.
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 ohne jeden Zusammenhang mit jemandem läuft, der 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 Virtualisierungserweiterungen der CPU ausschließlich nutzt, kann ein Drittanbieter-Hypervisor nicht auf die herkömmliche Weise 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.

Profil ansehen Kontakt

Öffentliche Links

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

Zurück zum Blog

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

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

1. Zuerst das Fazit

2. Von der CPU — Ein weiteres Privileg unter den Ringen

2.1. Eine Wiederholung des Ringschutzes

2.2. Virtualisierungserweiterungen — Ein Modus, der dem Hypervisor vorbehalten ist

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

3. Partitionen — Die Einheit der Isolierung

3.1. Rollen, die nur die Root-Partition hat

3.2. Die Welt, gesehen aus einer Child-Partition

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

4.1. Drei Arten von Adressen

4.2. SLAT — Zweistufige Übersetzung in Hardware

5. Vom Geräte-I/O — VMBus und zwei Arten von Geräten

5.1. Die Grenzen emulierter Geräte

5.2. VMBus und VSP/VSC — Ein schneller Pfad, der für Virtualisierung entworfen ist

6. Warum das nicht das Problem anderer ist, auch wenn Sie nie eine VM nutzen

7. Selbst nachsehen

8. Drei Fehldeutungen, die Sie in der Praxis vermeiden

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

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

8.3. „Wenn die VM langsam ist, ist es ein Problem des Gast-Betriebssystems“

9. Zusammenfassung

Weiterführende Artikel

Zugehörige Beratungsfelder

Quellen

Die Tiefen der Windows-Virtualisierung (Teil 3) — Virtuelle Maschinen, die in Sekunden starten: Warum WSL2, Windows Sandbox und Container so leicht sind

Die Tiefen der Windows-Virtualisierung (Teil 2) — Speicher, den selbst der Kernel nicht sieht: Wie VBS, HVCI und Credential Guard funktionieren

Die Win32-Thread-Pool-API — Nebenläufigkeit ohne eigene Threads, über CreateThreadpoolWork

Named Pipes in der Praxis — Windows' Standard-IPC von Entwurf bis Sicherheit

Was bedeutet Windows' „Speicherauslastung“ eigentlich? — Working Set, Private Bytes, Commit und die Auslagerungsdatei richtig lesen

Verwandte Themen

Technische Windows-Themen

Leistungen zu diesem Thema

Windows-App-Entwicklung

Häufige Fragen

Autorenprofil

Go Komura

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

1. Zuerst das Fazit

2. Von der CPU — Ein weiteres Privileg unter den Ringen

2.1. Eine Wiederholung des Ringschutzes

2.2. Virtualisierungserweiterungen — Ein Modus, der dem Hypervisor vorbehalten ist

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

3. Partitionen — Die Einheit der Isolierung

3.1. Rollen, die nur die Root-Partition hat

3.2. Die Welt, gesehen aus einer Child-Partition

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

4.1. Drei Arten von Adressen

4.2. SLAT — Zweistufige Übersetzung in Hardware

5. Vom Geräte-I/O — VMBus und zwei Arten von Geräten

5.1. Die Grenzen emulierter Geräte

5.2. VMBus und VSP/VSC — Ein schneller Pfad, der für Virtualisierung entworfen ist

6. Warum das nicht das Problem anderer ist, auch wenn Sie nie eine VM nutzen

7. Selbst nachsehen

8. Drei Fehldeutungen, die Sie in der Praxis vermeiden

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

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

8.3. „Wenn die VM langsam ist, ist es ein Problem des Gast-Betriebssystems“

9. Zusammenfassung

Weiterführende Artikel

Zugehörige Beratungsfelder

Quellen

Verwandte Artikel

Die Tiefen der Windows-Virtualisierung (Teil 3) — Virtuelle Maschinen, die in Sekunden starten: Warum WSL2, Windows Sandbox und Container so leicht sind

Die Tiefen der Windows-Virtualisierung (Teil 2) — Speicher, den selbst der Kernel nicht sieht: Wie VBS, HVCI und Credential Guard funktionieren

Die Win32-Thread-Pool-API — Nebenläufigkeit ohne eigene Threads, über CreateThreadpoolWork

Named Pipes in der Praxis — Windows' Standard-IPC von Entwurf bis Sicherheit

Was bedeutet Windows' „Speicherauslastung“ eigentlich? — Working Set, Private Bytes, Commit und die Auslagerungsdatei richtig lesen

Verwandte Themen

Technische Windows-Themen

Leistungen zu diesem Thema

Windows-App-Entwicklung

Häufige Fragen

Autorenprofil

Go Komura