Ich habe neulich das Experiment gemacht, eine Windows Server VM unter KVM auf einem TrueNAS-Scale-Storage-System produktiv an den Start zu bringen. Dabei gab es eine Reihe von Stolpersteinen aus den Weg zu räumen. Einzelheiten dazu teile ich mit diesem Beitrag, falls jemand vor ähnlichen Herausforderungen steht.
Anmerkung: Dieses Blog ist eigentlich auf M365 und Azure sowie Cloud Native Szenarien spezialisiert, beziehungsweise aus dieser Historie entstanden; später kamen verstärkt KI-Dienste hinzu. Trotzdem spielen Windows-Server als Workload-Typ in fast jedem Szenario eine wichtige Rolle. Auch ich betreibe demzufolge Windows Server sowohl On Prem als auch in der Cloud.
Vorgeschichte
Für diesen Beitrag gab es ein konkretes Szenario. In dem müssen sie sich aber nicht zwingend wiederfinden. Es mag auch andere Gründe für ein solches Experiment geben. Bekanntlich sind VMware/ESXi und Hyper-V nicht die einzig möglichen Hypervisor für Enterprise-Windows-Workloads. Ab und an gibt es gute Gründe, auf den im Linux-Kernel verbauten und damit kostenfreien Type-1-Hypervisor KVM zurückzugreifen, auch wenn es nicht primär um die gerade bei VMware seit Jahren steigenden Kosten geht.
Wer hingegen den professionellen Einsatz von KVM erwägt und dabei Unterstützung und Support benötigt, sollte auf jeden Fall auf Proxmox VE zurückgreifen. Wer trotzdem nicht vom Scratch aufsetzen will, findet in den Linux-basierten Betriebssystemen vieler Storage-Lösungen wie Synology, Qnap oder TrueNAS Scale ebenfalls die Möglichkeit, virtuelle Maschinen auf solchen Systemen zu betreiben.
Nun aber zum eigentlichen Szenario:
Für den produktiven Betrieb meiner im Unternehmensalltag benötigten virtuellen Maschinen betreibe ich einen Hyper-V-basierten Windows Server Failover Cluster mit zwei Knoten und einem iSCSI-basierten Shared-Storage als CSV (liegt auf dem Synology). Auf eine Hyper Converged Infrastruktur (HCI) mit Storage Spaces Direct (S2D) und SMB Multi-Channeling habe ich bewusst verzichtet, weil meine Netzwerkkarten nicht RDMA fähig sind. Sämtliche Netzwerkkommunikationspfade zwischen den Hosts sind nicht „direct connected“, sondern „ge-switcht“. Für meine rund 20 Workloads ist die Performance durchaus ausreichend, zumal das Synology-System mit Full-Flash-SSD-Speicher und entsprechenden NVMe-Cache gut bestückt ist.
Zur Sicherung der virtuellen Maschinen verwende ich „Veeam Backup&Replication 12“ (heute Veeam Data Platform). Da es keine gute Idee ist, die Sicherungssoftware in Form einer virtuellen Maschinen auf demselben System zu betreiben, dass von dieser gesichert werden soll, läuft auf meinem Synology-System ebenfalls eine Windows-Server-VM unter KVM, die allerdings als Domain Controller konfiguriert ist.
Da das Storage System im Gegensatz zu meinem Hyper-V-Cluster 24/7 betrieben wird, bot sich so für mich eine kostengünstige Optionen zum Betrieb kritischer Dienste. Ein zweiter Domain Controller läuft auf einem zweiten Synology-System. Nun ist es zweifelsohne überhaupt keine gute Idee und Microsoft rät auch vehement davon ab, nicht DC-affine Workloads wie VM Backup auf Domain-Controllern zu betreiben. Ich hatte es wegen knapper Ressourcen aber trotzdem so gelöst. Die Option, weitere Virtual Maschinen (nur für Veeam) auf den Synology-Storage System zu betreiben, viel daher aus, zumal die bestehenden Ressourcen in erster Linie als Speicherdienste dienen (iSCSI und NFS).
Jetzt zum eigentlichen Problem:
Ich betreibe meine Veeam-Lösung mit einem von Veeam für MCTs (Microsoft Certified Trainer) oder VCIs (VMware Certified Instructor) kostenfreien NFR-Key. Dieser war nun abgelaufen und ich wollte ihn erneuern. Erneuern bedeutet bei Veeam, man lädt die neue produktive Version des Produktes (jetzt wie Veeam Data Plattformen) herunter und erhält per Mail den zugehörigen Key. Der muss allerdings jeweils zur Version passen.
In meinem Fall passte er nicht mehr zu Veeam Back and Replication 12, so dass ich gezwungen war, eine Neuinstallation vorzunehmen. Das ist im Prinzip insofern unproblematisch, weil man bei Veeam problemlos die bestehende Konfiguration sichern kann. Hierbei stellte sich allerdings heraus, dass die Systemanforderungen an die neue Veeam-Version von der bisherigen Synology-VM nicht erfüllt werden konnten. Veeam braucht mindestens 8 CPUs und 16 GB RAM und (letzteres hätte ich noch realisieren können) unterstützt aber nicht mehr (bzw. verweigert) die Installation auf einem Domain Controller.
Zum Glück hatte ich noch ein komplett einsatzbereites und mit ausreichend Ressourcen bestücktes TrueNAS-System „im Gefrierschrank“, welches ich im Rahmen meiner Trainertätigkeit für Labor-Umgebungen nutze. Ich hatte das System erst im Frühjahr 2026 zu Demozwecken aufgebaut. So stand dem Experiment nichts im Wege. Ein eigenständiges, vom Haupt-Cluster entkoppeltes Backup-Ziel zu schaffen, schien mir ein logischer Ausweg für das oben skizzierte Szenario.
Doch auf dem Papier schnell erdacht, stellt sich bald heraus, dass die Realität im Maschinenraum von QEMU und ZFS ein paar Stolpersteine bereithält von der Einordnung der korrekten Begriffe der CPU-Topologie, über die Tücken von VNC-Konsolen bis hin zu den Eigenheiten des TrueNAS-Webinterfaces.
TrueNAS CPU-Mechanik
Die Reise beginnt an dem Punkt, an dem man die Windows Server VM anlegt und den virtuellen Prozessoren eine logische Heimat geben möchte. Hier stolperte auch ich über eine Eigenheit der Benutzeroberfläche, die selbst erfahrene Administratoren in die Irre führen kann. In der TrueNAS-Nomenklatur fehlt schlicht und einfach das Wort „Sockel“. Stattdessen blickt man auf ein unscheinbares Feld namens „vCPUs“, gefolgt von „Kernen“ und „Threads“. Wer sich auf diese Bezeichnungsweise verlässt und hier eine 8 einträgt, weil die VM schließlich 8 Kerne bekommen soll, tappt geradewegs in die klassische Hypervisor-Falle.
In der zugrundeliegenden KVM/QEMU-Logik repräsentiert dieses oberste vCPU-Feld keineswegs die Gesamtzahl der logischen Prozessoren, sondern exakt die Anzahl der virtuellen Prozessorsockel. Trägt man dort eine 8 ein, kombiniert mit 8 Kernen, glaubt das Betriebssystem im Inneren, es sitze auf einer wuchtigen Enterprise-Maschine mit 8 physischen Sockeln und insgesamt 64 logischen Prozessoren. Das Ergebnis ist ernüchternd: Windows Server Standard oder Datacenter verweigert die Mitarbeit auf den ungesicherten Sockeln oder läuft in Lizenz- und Scheduler-Limits, weil der Hypervisor die Last über künstliche Grenzen hinweg verteilt.
Die Lösung ist simpel. Das vCPU-Feld muss auf 1, die Kerne auf 8 und die Threads auf 1 gestellt werden. Erst dann versteht der Windows-Kernel, dass er auf genau einem einzigen Sockel mit acht echten Kernen arbeitet.
Doch wer nun glaubt, dass eine einfache Korrektur im Webinterface und ein anschliessender Neustart über das Startmenü des Gastes das Problem aus der Welt schaffen, wird schnell eines Besseren belehrt. Der QEMU-Prozess auf dem Debian-Unterbau von TrueNAS ist in diesem Punkt extrem hartnäckig. Beim herkömmlichen Warmstart behält der Emulator die initialisierte ACPI-MADT-Tabelle im Arbeitsspeicher bei, und die korrigierten Parameter verpuffen wirkungslos.
Erst wenn die VM im Betriebssystem sauber heruntergefahren, im TrueNAS-Dashboard der Zustand explizit auf gestoppt gesetzt und die Maschine per Kaltstart wiedererweckt wird, generiert der Hypervisor die XML-Domain-Beschreibung frisch. Wer diesen harten Neustart scheut, wundert sich im Task-Manager des Windows-Servers andernfalls vergebens über das Ausbleiben der gewünschten Topologie.
Hat man die Hardware-Hürde genommen, stellt sich unweigerlich die Frage nach dem Storage-Unterbau. TrueNAS baut auf ZFS auf, und wer hier das falsche Fundament wählt, zahlt den Preis später in Form von schlechten Latenzen. Ein ZVOL als blockbasiertes Laufwerk, das über VirtIO-Block an die VM durchgereicht wird, ist die beste Wahl für das Systemlaufwerk.
Die Blockgröße (volblocksize) legen Sie beim Erstellen fest, später lässt sie sich nicht mehr ändern. Der Standard von 16 Kilobytes ist für ein NTFS-Laufwerk mit 4-Kilobyte-Clustern ein guter Ausgangspunkt, 32 oder 64 Kilobytes sind ebenfalls sinnvoll. Je größer der Block, desto häufiger muss ZFS bei kleinen Schreibvorgängen den ganzen Block lesen, ändern und neu schreiben. Das kostet etwas Leistung und erhöht den Schreibaufwand der SSDs. Auf einem RAIDZ-Pool sollten Sie außerdem sehr kleine Blöcke vermeiden, weil sie Platz verschwenden.
Sobald die SSDs summen und das Betriebssystem installiert ist, folgt der nächste Frustmoment im Admin-Alltag: Die integrierte VNC-Konsole des TrueNAS-Webinterfaces. Für die allererste IP-Vergabe mag sie taugen, doch wer länger als fünf Minuten darin arbeitet, verzweifelt an falschen Tastaturlayouts, bei denen das @-Zeichen oder der Bindestrich auf wundersame Weise verschwinden, während die Bildwiederholrate an eine Diashow erinnert.
Der Wechsel zur RDP ist hier der logische Ausweg. Sobald die Netzwerkkarte konfiguriert und die Domänenmitgliedschaft vollzogen ist, sollte RDP aktiviert und die Firewall-Regel freigegeben werden. Erst dann fühlt sich die virtuelle Maschine wie ein vollwertiger Server an, bei dem man reibungslos per Zwischenablage Skripte und Passwörter übertragen kann.
Apropos Webinterface: Wer intensiv auf TrueNAS Scale arbeitet, stolpert schnell über das per Default extrem kurze Session-Timeout von 5 Minuten. Die Suche nach der vermeintlichen GUI-Kachel führt ins Leere, denn iXsystems hat diese Logik tief in den Bereich der erweiterten Systemeinstellungen („System / Erweiteter Einstellungen“) unter der Kachel für den „Access Settings“ (Zugang) vergraben.
VirtIO-Treiber
Die CPU-Topologie stimmt, das zvol ist angelegt, die Konsole zeigt ein Bild. Nun soll Windows Server 2025 auf die virtuelle Maschine. Wer jetzt die Installation startet und durch die ersten Dialoge klickt, steht beim Schritt „Wo möchten Sie Windows installieren?“ vor einer leeren Liste. Windows sieht keine Festplatte. Der Grund liegt in einer Entscheidung, die man vorher in der TrueNAS-Oberfläche getroffen haben sollte, bzw. nicht getroffen hat, falls man hier nichts sieht.
TrueNAS bietet für virtuelle Laufwerke zwei Modi an: „AHCI“ und „VirtIO“. AHCI emuliert einen klassischen SATA-Controller. Jedes Windows kennt ihn von Haus aus, deshalb empfiehlt die Dokumentation AHCI für Windows-VMs. Der Preis dafür ist der Aufwand der Emulation, denn der Hypervisor spielt jede Hardware-Bewegung nach.
VirtIO geht den anderen Weg. Das Gastsystem weiß, dass es virtuell läuft, und spricht über eine schlanke Schnittstelle direkt mit dem Hypervisor. Das spart Rechenzeit und senkt die Latenz, besonders bei vielen kleinen Zugriffen. Für einen Backup-Server, der den ganzen Tag Daten schreibt, ist das ein echter Gewinn. Das ist vergleichbar mit den paravirtualisierten Device-Treibern von VMware (VMware Tools), bzw. den Guest Integration Services von Hyper-V.Die Gegenleistung verlangt aber der Gast: Windows bringt keinen VirtIO-Treiber mit. Ohne Treiber bleibt die Platte unsichtbar, und ohne sichtbare Platte kein Windows. Die Treiber stellt das Fedora-Projekt als ISO-Abbild bereit, es heißt „virtio-win“. Die stabile Version genügt für diesen Zweck. Man lädt sie herunter und legt sie dorthin, wo auch die anderen Installationsmedien liegen. Bei mir ist das ein Dataset, das auf dem NAS für ISO-Dateien freigegeben ist. Von dort kann TrueNAS die Datei später als virtuelles Laufwerk einhängen.
In der TrueNAS-Oberfläche öffnet man die Geräte der VM. Änderungen daran sind nur bei gestoppter VM möglich. Drei Einstellungen sind wichtig:
- Das Laufwerk (Disk) bekommt den Modus „VirtIO“ statt „AHCI“.
- Die Netzwerkkarte (NIC) bekommt den Adaptertyp „VirtIO“ statt „Intel e82545 (e1000)“. Auch hier gilt: Windows kennt den Treiber nicht, die Karte wird nach der Installation zunächst unbekannt sein.
- Die Windows-Server-ISO hängt als „virtuelles CD-ROM-Gerät“ mit der Gerätereihenfolge 1000. Dieser Wert setzt das Gerät an die erste Stelle der Startreihenfolge, die VM bootet also vom Installationsmedium.
Die Falle mit den drei ISO-DateienIch wollte natürlich clever sein und gleich beim ersten Durchlauf alle drei relevanten ISOs als virtuelle CD-ROM einhängen, also das Installations-ISO für Windows Server, das nicht bootfähige Installations ISO für Veeam, sowie das Fedora-ISO mit den VirtIO-Treibern.
TrueNAS nimmt in der GUI auch klaglos drei CD-ROM-Geräte, d. h. die GUI zeigte sie brav in der Liste, es gibt keine Warnung und keine Fehlermeldung. Im Gast kommen allerdings nur zwei davon an, also die ersten beiden in der Device-Hierarchie. Dummerwiese war bei mit die VirtIO-ISO während der Installation also doch nicht dabei und die Liste der möglichen Installations-Devices blieb leer, weil der Treiber, der sie hätte füllen können, unerreichbar im Hintergrund schlummerte.
Zur Installationszeit gehören also nur zwei Medien in die VM: die Windows-ISO zum Booten und die VirtIO-ISO für den Treiber. Nach dem „Nach-Installieren“ der übrigen paravirtualisierten Treiber entweder vom Installer der ISO oder direkt aus dem Geräte-Manager heraus mit „Nach neuer Hardware suchen“ und „Treiber aktualisieren“ (siehe unten), wäre ohnehin an Reboot fällig gewesen. Die Veeam-ISO hätte ich also zu diesem Zeitpunkt noch gar nicht brauchen können. Doch gehen wir noch einen Schritt zurück.
Windows installieren mit VirtIO-Treibern
Nach dem Start bootet die VM vom Windows-Medium. Hier wählen Sie wie üblich Sprache und Edition, akzeptieren die Lizenzbedingungen und wählt die benutzerdefinierte Installation. Auf der Seite für das Ziellaufwerk ist die Liste leer. Hier wählen Sie dann „Treiber laden“ und danach „Durchsuchen“. Im Dateidialog wählen Sie das Laufwerk mit der VirtIO-ISO und navigieren zum Ordner viostor\2k25\amd64. Das Kürzel 2k25 steht für Windows Server 2025, viostor für den Block-Treiber, den ein VirtIO-Laufwerk braucht. Das Setup bietet daraufhin den Red-Hat-VirtIO-Treiber an.
Mit dem Bestätigen erscheint die virtuelle Festplatte in der Liste. Bleibt die Treiberliste leer, hilft häufig der Ordner amd64\2k25 auf demselben Medium, der dieselben Treiber enthält. Danach läuft die Installation wie auf echter Hardware.
Nach dem ersten Start: Netzwerk und Gasttools
Beim ersten Anmelden arbeitet die Netzwerkkarte arbeitet im VirtIO-Modus, aber Windows kennt dafür noch keinen Treiber. Im Geräte-Manager taucht ein „Ethernet-Controller“ unter „Andere Geräte“ auf, und der Server ist ohne Netz. Da das VirtIO-ISO zu diesem Zeitpunkt noch immer an der VM hängen sollte, öffnen Sie einfach das Laufwerk im Explorer und starten „virtio-win-guest-tools.exe“.
Das Paket installiert die übrigen Treiber, darunter den Netzwerktreiber NetKVM und den Treiber für die Speicherverwaltung (Balloon), und richtet zusätzlich den QEMU Guest Agent ein. Der Agent erlaubt dem Hypervisor, die VM sauber herunterzufahren und Informationen aus dem Gast abzufragen. Nach der Installation meldet sich die Netzwerkkarte und Sie können IP-Adresse und Domänenmitgliedschaft einrichten und den Remotedesktop aktivieren.
Ist alles erledigt, fahren Sie die VM herunter und entfernen die beiden CD-ROM-Geräte oder ändern zumindest ihre Priorität in der Startreihenfolge. Andernfalls bootet die VM beim nächsten Start wieder in das Installationsprogramm statt in das frisch installierte System.
Veeam installieren
Jetzt kommt die Veeam-ISO dran. Es gibt zwei saubere Wege. Der erste: VM stoppen, ein neues CD-ROM-Gerät mit der Veeam-ISO hinzufügen, VM starten. Der zweite ist bequemer: Die ISO liegt wie bei mir ohnehin auf einer Freigabe des NAS. Sie öffnen diese Freigabe im Windows Explorer der VM und klicken im Kontextmenü mit rechts auf „Bereitstellen“. Windows hängt die ISO dann selbst als virtuelles Laufwerk ein, ohne Eingriff in die VM-Konfiguration. Daraus startet Sie dann das Setup.exe und folgen dem Installationsassistenten. Die NFR-Lizenzdatei wird später in der Konsole eingespielt.
Fazit
Der Weg von der leeren Festplattenliste zum laufenden Backup-Server besteht aus wenigen, aber unnachgiebigen Regeln. Die Treiber müssen im Gast ankommen, bevor man sie braucht. Dazu gehört, dass zur Installation nur die beiden Medien in der VM stecken, die man wirklich benötigt. Alles andere folgt danach. Dann läuft Windows Server 2025 auf VirtIO-Hardware, mit schnellerem Plattenzugriff und einer Netzwerkkarte, die den Hypervisor nicht länger ausbremst.
Am Ende des Tages ist der Weg zur stabilen Windows-Server-Umgebung unter TrueNAS SCALE zwar mit kleinen technischen Fallstricken versehen, doch wer die Macken von QEMU-Sockets, ZFS-Blockgrößen und den Eigenheiten des Hypervisors erst einmal umschifft hat, wird mit einer Plattform belohnt, die an Stabilität und Kontrolle kaum zu übertreffen ist.