Sichere Warenwirtschaft per KVM/QEMU-VM

Ausgangslage

Die Lexware Warenwirtschaft Pro läuft aktuell auf einem dedizierten Windows-11-Rechner im Unternehmen. Diese Architektur bringt drei konkrete Probleme mit sich:

Lange Backup-Zeiten: Die regelmäßigen Datensicherungen dauern zwischen 45 und 60 Minuten. In dieser Zeit ist das System belastet und der Betrieb eingeschränkt.

Windows-Update-Risiko: Nach einem fehlerhaften Windows-Update ist der Zugriff der Clients auf die Warenwirtschaft sofort unterbrochen. Eine Wiederherstellung dauert je nach Fehler Stunden – Ausfallzeiten, die im Unternehmensalltag nicht tolerierbar sind.

Cyberangriffe: Die Bedrohungslage durch Ransomware und gezielte Angriffe auf Unternehmensinfrastruktur hat sich in den letzten Jahren dramatisch verschlechtert. Ein Windows-System direkt im Netzwerk ist ein exponiertes Ziel.

Ziel

Windows 11 soll nicht verschwinden – Lexware läuft ausschließlich auf Windows und das bleibt so. Das Ziel ist es, Windows 11 nicht mehr als Hauptbetriebssystem zu betreiben, sondern als vollständig isolierte virtuelle Maschine unter Linux Mint.

Bare-Metal heute          Zielarchitektur
─────────────────         ─────────────────────────────
Windows 11                Linux Mint (Host)
  └─ Lexware WW Pro         └─ KVM/QEMU
                               └─ Windows 11 (VM)
                                    └─ Lexware WW Pro

Vorteile der VM-Lösung

Snapshots statt langer Backups

Mit KVM/QEMU lassen sich automatisierte Snapshots der gesamten Windows-VM erstellen – inklusive Betriebssystem, installierten Programmen und allen Daten. Ein Snapshot dauert Sekunden, nicht Minuten. Vor jedem Windows-Update wird automatisch ein Snapshot angelegt. Schlägt das Update fehl, ist der letzte funktionierende Zustand in unter einer Minute wiederhergestellt.

Schutz vor Cyberangriffen

Die Windows-VM läuft in einer vollständig isolierten Umgebung. Der Linux-Host ist für Angreifer deutlich schwerer zu kompromittieren als ein Windows-System. Ransomware, die in die Windows-VM eindringt, kann den Host und damit alle Snapshots nicht erreichen – vorausgesetzt die Snapshot-Ablage liegt außerhalb der VM.

Schnelle Wiederherstellung bei Hardware-Defekt

Die gesamte VM ist eine Handvoll Dateien auf dem Host-System. Bei einem Hardware-Defekt wird diese Datei auf einen Ersatzrechner kopiert und die VM dort gestartet – in Minuten, nicht Stunden. Kein Windows-Neuaufbau, keine Neuinstallation von Lexware, kein Einspielen von Backups.

Unabhängigkeit vom Windows-Update-Zyklus

Der Linux-Host läuft stabil unabhängig von Windows. Selbst wenn die Windows-VM durch ein Update nicht mehr startet, ist der Host-Betrieb nicht betroffen. Die VM wird einfach auf den letzten Snapshot zurückgesetzt.

Geplante Umsetzung

Host-System

Betriebssystem: Linux Mint (LTS)
Virtualisierung: KVM/QEMU mit virt-manager als grafische Oberfläche
Netzwerk: VM erhält eine eigene IP im Firmennetz über eine Bridge-Verbindung – für Clients transparent, kein Unterschied zum bisherigen Betrieb

Windows-11-VM

Volle Hardwarebeschleunigung via KVM – die VM läuft nahezu mit nativer Geschwindigkeit
Lexware Warenwirtschaft Pro läuft wie bisher, Clients verbinden sich über das Netzwerk
Druckerzugang und andere Peripherie werden per USB-Passthrough oder Netzwerkdrucker eingebunden

Snapshot-Strategie

Snapshot-Typ	Intervall	Aufbewahrung
Automatisch vor jedem Update	Bei jedem Windows-Update	3 Versionen
Täglich (Nacht)	02:00 Uhr	7 Tage
Wöchentlich	Sonntag	4 Wochen
Monatlich	1. des Monats	6 Monate

Disaster Recovery

Die VM-Dateien werden zusätzlich auf ein externes NAS oder einen separaten Datenträger repliziert. Im Fall eines vollständigen Hardware-Defekts:

Ersatzrechner mit Linux Mint booten
VM-Dateien vom Backup einspielen
VM starten → Lexware läuft

Ziel: Wiederherstellungszeit unter 30 Minuten.

Bisherige Fortschritte

Bevor die Migration im Produktivbetrieb stattfindet, habe ich das gesamte Setup auf einem separaten Testserver als Machbarkeitsnachweis aufgebaut. Statt Linux Mint kam dabei Debian 13 Trixie mit XFCE als Host zum Einsatz – schlank, stabil, SSH-fähig und trotzdem mit Desktop für den Notfall. Der Aufbau verlief erfolgreich und bestätigt die geplante Architektur in allen wesentlichen Punkten.

Virtualisierung und KVM/QEMU-Stack

Zunächst die Hardware-Unterstützung geprüft:

egrep -c '(vmx|svm)' /proc/cpuinfo

Ein Ergebnis größer als 0 bedeutet, dass Virtualisierung unterstützt wird – im Testsystem mit 32 Threads. Anschließend den kompletten Stack installiert:

sudo apt install -y qemu-system-x86 libvirt-daemon-system libvirt-clients bridge-utils virt-manager ovmf

ovmf – UEFI-Firmware, für Windows 11 zwingend erforderlich
virt-manager – grafische Verwaltung der VMs

Benutzer zur libvirt-Gruppe hinzufügen und neu starten:

sudo usermod -aG libvirt,kvm BENUTZERNAME
sudo reboot

Ein leeres virsh list --all ohne Fehler bestätigt, dass alles korrekt eingerichtet ist.

Windows-11-VM mit VirtIO

Für maximale Performance setze ich auf VirtIO-Treiber statt emulierter Hardware – das bringt deutlich schnellere Disk- und Netzwerk-Performance. Das passende Treiber-ISO:

wget https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso -P /home/BENUTZERNAME/

Die VM wurde in virt-manager mit folgenden Eckdaten erstellt:

Einstellung	Wert
Chipsatz	Q35
Firmware	UEFI
TPM	v2.0 / TIS
Festplattenbus	VirtIO
Netzwerk Gerätemodell	virtio
RAM	12288 MiB (12 GB)
CPUs	14 vCPUs
Festplattengröße	350 GiB

Wichtig: Eine zweite CDROM mit der virtio-win.iso einbinden – sie wird während der Windows-Installation für die Treiber gebraucht.

Treiber während der Installation laden

Beim Schritt „Speicherort auswählen” zeigt Windows zunächst keine Festplatte an – das ist normal, da Windows VirtIO noch nicht kennt. Über Treiber laden → virtio-win CDROM → viostor\w11\amd64 erscheint die virtuelle Festplatte und die Installation läuft durch. Den Netzwerktreiber anschließend über NetKVM\w11\amd64 nachladen.

Nach der Installation in Windows die restlichen VirtIO-Komponenten ergänzt:

virtio-win-gt-x64.exe – alle VirtIO-Treiber auf einmal
guest-agent\qemu-ga-x86_64.msi – QEMU Guest Agent für saubere Host-Kommunikation

Autostart von Netzwerk und VM

Damit die VM beim Hochfahren des Servers automatisch zur Verfügung steht:

# Virtuelles Netzwerk dauerhaft aktivieren
sudo virsh net-autostart default
sudo virsh net-start default

# VM Autostart beim Hochfahren
sudo virsh autostart KAT-Windows11-VM

# Prüfen
sudo virsh dominfo KAT-Windows11-VM | grep Autostart

Ergänzend habe ich auf dem Host XFCE-Autologin eingerichtet, damit nach einem Neustart kein manueller Eingriff nötig ist (/etc/lightdm/lightdm.conf mit autologin-user).

Snapshots erfolgreich getestet

Der für das Projekt zentrale Punkt – schnelle Snapshots statt langer Backups – funktioniert in der Praxis wie erhofft. Interne Snapshots liegen direkt in der QCOW2-Datei und lassen sich mit einem einzigen Befehl erstellen:

# Snapshot erstellen (VM sollte ausgeschaltet sein)
sudo virsh snapshot-create-as --domain KAT-Windows11-VM --name "$(date +%Y-%m-%d_%H-%M)" --description "Manueller Snapshot"

# Snapshots anzeigen
sudo virsh snapshot-list KAT-Windows11-VM

# Zu einem Snapshot zurückkehren
sudo virsh snapshot-revert KAT-Windows11-VM SNAPSHOT-NAME

# Snapshot löschen
sudo virsh snapshot-delete KAT-Windows11-VM SNAPSHOT-NAME

Portabilität und Backup verifiziert

Die komplette VM besteht aus nur zwei Dateien – das bestätigt die geplante Disaster-Recovery-Strategie:

# Festplatte und Snapshots
/var/lib/libvirt/images/KAT-Windows11-VM.qcow2

# VM-Konfiguration (CPU, RAM, Geräte)
/etc/libvirt/qemu/KAT-Windows11-VM.xml

Für das Backup (VM ausgeschaltet) beide Dateien auf eine externe Platte kopieren. Die Wiederherstellung auf einem anderen Rechner gelingt mit sudo cp ...qcow2 /var/lib/libvirt/images/ und anschließendem sudo virsh define ...xml – genau das Vorgehen, das im Ernstfall die Wiederherstellungszeit unter 30 Minuten halten soll.

Erkenntnisse für die Produktivmigration

Das Setup läuft stabil, Windows 11 startet automatisch beim Hochfahren des Servers.
VirtIO sorgt für nahezu native Performance – ein spürbarer Engpass war im Test nicht erkennbar.
Snapshots und Portabilität funktionieren exakt wie im Konzept vorgesehen.
Der OEM-Windows-Key lässt sich bei Bedarf direkt aus dem UEFI auslesen: sudo strings /sys/firmware/acpi/tables/MSDM.

Damit ist der technische Kern des Projekts validiert. Für die Produktivumgebung bleibt der Wechsel auf Linux Mint (LTS) als Host sowie die Anbindung an das Firmennetz per Bridge-Verbindung und der Druckerzugang offen.

Status

Der Machbarkeitsnachweis auf einem Debian-Testserver ist abgeschlossen und erfolgreich – die geplante Architektur funktioniert in der Praxis. Die Übertragung auf das Produktivsystem (Linux Mint als Host, Anbindung ans Firmennetz, Lexware-Migration) ist für die nächsten Monate vorgesehen.