Der Ton lässt sich nicht virtualisieren

Rechts von mir steht ein zweiter Bildschirm, und darauf läuft Windows mit einer RTX 4090, die felsenfest davon überzeugt ist, allein auf einer Maschine zu sitzen. Sie ist es nicht. Links auf demselben Laptop läuft mein eigentliches Leben weiter: Mail, Office, der ganze Kram, den ich nicht für eine Gaming-Session unterbrechen will.

Ich wollte nicht wählen müssen. Kein Dual-Boot, bei dem meine Infrastruktur für Stunden offline geht, nur weil ich schneiden oder spielen will. Stattdessen: eine GPU, die komplett und exklusiv in eine virtuelle Maschine wandert, ein zweiter Monitor, der direkt an dieser VM hängt, und ein Windows, das von jedem Update-Nerv und jeder Telemetrie befreit ist, die ich loswerden konnte. Der Rechner sollte sich anfühlen wie zwei Rechner, ohne zwei Rechner zu sein.

Der erste Erfolgsmoment war fast unspektakulär. Ich hatte den TianoCore-Bootscreen auf dem externen Monitor erwartet und ihn tatsächlich bekommen, dann Windows, dann, nach ein paar bangen Sekunden mit “Microsoft Basic Display Adapter” statt echtem NVIDIA-Treiber: Auflösung in nativer Pracht. Keine schwarzen Bildschirme, kein Ada-Lovelace-Fluch, den ich aus den Foren kannte. // Der Moment, in dem man merkt, dass die Stunden Recherche vorher tatsächlich irgendwas gebracht haben.

Dann kam Code 43. Der Geräte-Manager zeigte die 4090 mit einem gelben Warndreieck, trotz gefälschter Hypervisor-Signatur und echtem VBIOS-Dump. Der Grund war so banal wie lehrreich: NVIDIAs mobile Treiber bestehen auf einem Akku. Ein Laptop hat einen, eine VM nicht, und der Treiber verweigert sich, sobald er keinen findet. Die Lösung war, der virtuellen Maschine einen Akku zu erfinden: eine ACPI-Tabelle, die einen vollen, angeschlossenen Akku simuliert, wo physisch keiner existiert. Nach dem nächsten Neustart war der Fehler weg. Ich habe der Maschine buchstäblich eine Lüge über ihre eigene Hardware erzählt, damit sie funktioniert.

Die nächste Etappe war unsexy, aber am Ende die mit den größten Zahlen: Die Windows-Platte lief auf emulierter SATA, statt auf virtio, dem viel schnelleren Weg zur echten NVMe darunter. Ein direkter Wechsel hätte mit ziemlicher Sicherheit in einem Bluescreen geendet, weil Windows den nötigen Treiber zwar kennt, ihn aber nie als Boot-Dienst registriert, wenn man ihn nicht vorher sauber einführt. Also erst einen zweiten, harmlosen Controller dazugeben, Windows den Treiber im laufenden Betrieb lernen lassen, verifizieren, dass er als Boot-Start-Dienst registriert ist, und erst dann die eigentliche Systemplatte umhängen. Am Ende: sequenzielles Lesen von 972 auf 2201 Megabyte pro Sekunde, wahlfreier Zugriff von 12.000 auf 36.000 IOPS. Plus 207 Prozent, ohne neue Hardware, nur weil ich der Platte den richtigen Bus gegeben habe.

Bei der CPU-Zuteilung habe ich mir selbst ein Bein gestellt. Ich wollte den Host auf ein paar Kerne beschränken, damit die VM den Rest exklusiv bekommt, also habe ich per Cgroup dem system.slice die Kerne entzogen. Die laufende Maschine starb sofort, ohne dass ich sie heruntergefahren hätte. Der Grund: Der Verwaltungsdienst, der die VM selbst am Leben hält, hängt unter genau diesem system.slice, und eine Cgroup kann ihrem eigenen Elternteil nie mehr Ressourcen zugestehen, als das Elternteil hat. Ich hatte der Hausverwaltung den Strom abgestellt, um im eigenen Zimmer Strom zu sparen. // Danach: nur noch user.slice einschränken, system.slice in Ruhe lassen, komme was wolle.

Freigegebene Ordner zwischen Host und Gast klangen nach dem einfachsten Teil des ganzen Projekts. Die Geräte für die Dateifreigabe waren im Windows-Geräte-Manager längst als “OK” gelistet, trotzdem tauchte kein einziges Laufwerk auf. Der fehlende Baustein war ein separates Dateisystem-Framework, ohne das der mitgelieferte Treiber ein Gerät ohne Funktion bleibt. Nach der Installation zeigte sich eine zweite Überraschung: Der mitgelieferte Dienst mountet automatisch genau eine Freigabe, die zuerst gefundene. Für jede weitere braucht es einen eigenen, von Hand angelegten Windows-Dienst mit eigenen Kommandozeilen-Parametern. Kein Fehler, einfach eine Design-Entscheidung, die nirgends dokumentiert war, bis ich sie aus einer Fehlermeldung im Eventlog herauslesen musste.

Dann kam der Ton. Ich wollte ein USB-Audio-Interface, einen Recorder mit drei Audio-Interfaces für verschiedene Samplerate-Modi, in die VM durchreichen. Der Kernel-Treiber am Host wollte sich partout nicht lösen, egal ob ich das Gerät im laufenden Betrieb einsteckte oder von Anfang an in die Konfiguration schrieb. Wenn ich das manuell erzwang, kam die eigentliche Enttäuschung erst danach: libusb_set_interface_alt_setting: -5 NOT_FOUND, dreimal, einmal je Audio-Interface. Das Gerät blieb für Windows unsichtbar, komplett unabhängig davon, ob ich es dynamisch anhängte oder fest in der Konfiguration verankerte.

Ich habe daraufhin die naheliegendste Reparatur getestet, einen dokumentierten QEMU-Schalter, der USB-Resets beim Verbindungsaufbau unterdrückt, in der Annahme, genau so ein Reset würde das Scheitern auslösen. Exakt derselbe Fehler, unverändert. Und dann fand ich den Satz, der die Sache endgültig einordnete, aus einem fremden Forum, über ein komplett anderes Profi-Audio-Interface, das sogar über einen kompletten, eigenen PCI-Controller durchgereicht wurde, dem eigentlich robustesten aller Passthrough-Wege: Es blieb genauso kaputt. Die Zeitkritik dieser Geräte verträgt sich schlicht nicht mit der Art, wie eine virtuelle Maschine USB emuliert. Kein Konfigurationsfehler, keine fehlende Fleißarbeit meinerseits, eine strukturelle Grenze der Technik selbst.

Ich habe lange gesucht, ob es dafür wenigstens einen Patch gibt, irgendwo im Upstream, an dem gerade gearbeitet wird. Es gibt einen, aber er behebt einen anderen Fehler, einen Absturz beim schnellen Ab- und Anstecken, nicht das stille Scheitern, das mich betrifft. Und selbst der lag zum Zeitpunkt meiner Suche noch unfertig in der Review-Schleife.

Also bleibt eine Lücke, mit der ich leben muss. Für alles, was Bild, Rechenleistung, Speicher und geteilte Ordner betrifft, hat sich das Setup als das erwiesen, was ich wollte: zwei Rechner in einem, ohne Kompromiss. Für robusten Ton bleibt am Ende doch nur ein klassisches Dual-Boot als Ausweichoption, weniger elegant, aber ehrlich genug, um es aufzuschreiben, statt es zu verschweigen.

---

Update (17. Juli 2026)

Eine Ergänzung zur Windows-10-Maschine oben, die im ersten Text fehlte: Die Benchmarks sahen brauchbar aus, aber ein Punkt blieb ungelöst. Die RTX 4090 lief in der VM nie über ihr 80-Watt-Power-Limit hinaus, weit unter dem, was die GPU nativ leisten würde. Genau der Punkt, der zusätzlich zum Ton für natives Dual-Boot statt Virtualisierung spricht.

Trotzdem bin ich nicht zu Dual-Boot gewechselt, sondern habe eine zweite, eigenständige VM gebaut: Windows 11, gleiche RTX 4090, gleiches Thunderbolt-Dock, kein Ersatz für die erste Maschine. Der Grund ist ökonomisch, nicht technisch. Im BIOS des Laptops liegt eine echte, legitime Windows-11-Lizenz. Für Windows 10 hätte ich zusätzlich rund 47 Euro für eine alte, auslaufende Edition ausgegeben, nur um dieselbe Zoom-Baustelle in einer anderen VM zu haben. Diese Entscheidung hat ihren eigenen Preis: Windows 11 bringt eigene Zicken mit, allen voran ein spürbar unzuverlässiges unbeaufsichtigtes Setup, wie der Rest dieses Updates zeigt.

Am Zoom-Recorder selbst habe ich nichts repariert. Ich habe ihn in der neuen VM nicht noch einmal getestet, vermutlich dieselbe strukturelle Grenze bei isochronen USB-Streams, aber das ist eine Vermutung, keine Messung.

Was sich stattdessen geändert hat: das Ziel. Statt weiter gegen ein Drei-Interfaces-Profi-Gerät anzurennen, das QEMU strukturell nicht bedienen kann, läuft der Ton jetzt einfach über die Audiobuchse der Dockingstation, die ohnehin schon an derselben PipeWire-Brücke hängt, über die auch der VM-Ton auf den Host kommt. Kein Passthrough, kein Treiber, nur der Host-Audioausgang auf die Dock-Buchse gestellt. Das klingt nicht nach einem Recorder mit drei Samplerate-Modi, aber es klingt gut genug für das, wofür ich in der VM tatsächlich Ton brauche. Manchmal ist Zielverschiebung ehrlicher, als ein Ziel mit Gewalt zu erzwingen, das die Technik nicht hergibt.

Der erste Stolperstein kam noch vor der eigentlichen Windows-Installation. Ich wollte von einer virtuellen CD-ROM booten, emuliert über denselben SATA-Bus wie zuvor die Windows-10-Platte, und QEMU stürzte dabei zuverlässig ab. Ein Coroutine-Crash in der AHCI/ATAPI-Emulation, reproduzierbar bei jedem Versuch, offenbar ein Bug in QEMU 10.2.2 selbst und nicht in meiner Konfiguration. Die Lösung war unspektakulär: CD-ROM-Laufwerke auf virtio-scsi umstellen, den kaputten AHCI-Codepfad komplett umgehen. Danach bootete das Installationsmedium ohne ein einziges weiteres Problem.

Weil die Zielplatte für Windows 11 ebenfalls an virtio-scsi hängt, brauchte das Setup-Programm einen Treiber, den es von Haus aus nicht kennt. Statt bei jeder Installation manuell auf “Treiber laden” zu klicken und eine Diskette virtuell einzulegen, habe ich den vioscsi-Treiber direkt ins Installationsabbild eingebettet: per wimlib in boot.wim und install.wim hinein, über die DRIVERS-Registry-Hive-Methode. Seitdem sieht Windows-Setup die Zielplatte von der ersten Sekunde an, ohne dass ich eingreifen muss.

Zwischendurch hatte ich mich auf eine falsche Fährte verrannt. SecureBoot und TPM 2.0, beide für Windows 11 Pflicht, standen bei mir länger im Verdacht, die Bildprobleme zu verursachen. Waren sie nicht. Beide laufen inzwischen sauber, und der eigentliche Übeltäter war die ganze Zeit der AHCI-Bug aus dem ersten Absatz. Eine Vermutung, die sich als falsch herausstellt, ist auch ein Ergebnis, nur ein unbequemeres.

Der unangenehmste Fund kam fast am Ende der Installationskette. Die Autounattend-Antwortdatei sollte die Zielplatte automatisch partitionieren, zeigte aber auf die falsche physische Platte. Grund: Ein durchgereichter USB-SD-Kartenleser vom Thunderbolt-Dock belegte in Windows’ Geräteliste einen niedrigeren Disk-Index als die eigentliche 100-Gigabyte-Zielplatte. Windows verweigerte zu Recht das automatische Löschen einer Platte, die es als extern und USB-angebunden erkannt hatte. Gefunden habe ich das, ohne die VM überhaupt zu starten: Setup-Logs direkt aus der virtuellen Festplattendatei gelesen, per NBD-Loop-Mount vom Host aus.

Zum Schluss noch eine kleine, aber lohnende Korrektur: der virtuellen Platte per SCSI-Eigenschaft explizit gesagt, dass sie eine SSD ist, kein Rotationswert, keine bewegten Teile. Ohne den Hinweis hätte Windows automatisch eine Defragmentierung dafür eingeplant, für eine Platte, die in Wirklichkeit eine Datei auf NVMe-Speicher ist.

Aktueller Stand: Die Windows-11-Installation läuft testweise. Kein “Problem gelöst”, eher eine zweite Baustelle mit eigenen Stolpersteinen, ein paar davon inzwischen ausgeräumt. Beim Ton ist es kein Sieg über das ursprüngliche Problem, eher ein Waffenstillstand: der Zoom-Recorder bleibt draußen, die Dock-Buchse reicht für den Alltag.

---

VFIO Kernel-Framework, das PCI-Geräte direkt und exklusiv einer VM zuteilt, ohne Emulationsschicht dazwischen.

IOMMU-Gruppe Geräte, die eine Plattform nur gemeinsam isolieren kann. Teilt sich das Zielgerät die Gruppe mit unverzichtbarer Hardware, ist Passthrough riskant bis unmöglich.

Isochroner USB-Transfer Übertragung mit garantierter, aber nicht wiederholbarer Zeitscheibe, üblich bei Audio/Video. Verpasst, ist das Paket verloren, kein Retry.

Code 43 Windows-Fehlercode für verweigerten Gerätebetrieb, oft durch Umgebungsprüfungen, die eine VM nicht erfüllt.