Ich muss hier einen Fall von Layer-8 Ignoranz schildern – mit etwas Vorgeschichte.

Alles Cloud …

Vor vier Monaten erzählte mir ein Freund, dass er eine Praxis übernehmen würde – mit einer Softwarelösung, die zu 100% in der Cloud läuft. „Wir brauchen nur ein paar Tablets und Internet, da kannst du mir vielleicht helfen?“ Wo fängt man da an …

1. Es gab PCs, Baujahr 2018 oder 2019 – so genau wusste das niemand. Man hielt sie für „relativ neu“. OK – relativ. Und mit <Panikmodus>Festplatten</Panikmodus>
2. Ein neues, dreidimensionales Röntgengerät musste her. Die Daten sollten direkt in die Cloud gespeichert werden – allerdings braucht es dazwischen ein „Laufwerk“ als Cloud-Cache
3. Dazu kamen diverse Konnektoren – wofür auch immer

Die Informationen sickerten nach und nach durch. Ein vollständiges Bild hatten wir erst 14 Tage vor der Wiedereröffnung der Praxis.

Where the rubber meets the road …

Für Punkt 1 konnte ich mit etwas Überzeugungsarbeit ein Synology-NAS (RS822+) ins Spiel bringen. Dank Synology Directory Server gab es eine kleine Domäne, über die sich die PCs (nun mit SSDs ausgestattet) verwalten ließen.

Mit maximalem RAM ausgestattet, liefen darauf zwei bis drei kleine VMs. Der AMD Ryzen 1500B ist zwar kein Kraftpaket, aber für kleine Aufgaben reicht’s. Die Bereitstellung der VMs übernahm der Synology Virtual Machine Manager (VMM), also QEMU/KVM so mehr oder weniger.

Zwei Windows-VMs wurden eingerichtet:

• Eine mit 4 vCPUs, 16 GB RAM und 2 TB Speicher für den Cloud-Cache (Punkt 2).
• Eine weitere mit 10 GB RAM für einen Healthconnector.

Nach einigen Optimierungen liefen die VMs stabil und flott – auch dank SSD-Cache im NAS.

Punkt 3: Die Konnektoren

Der erste Konnektor ließ sich problemlos installieren. Kein Thema. Dann kam der RISE-Konnektor – und wie so oft: ein Dienstleister, der sich als besonders „resistent“ erwies.

Natürlich, der Dienstleister ist immer der andere …

Die „Anforderung“, in der virtuellen Windows-VM (QEMU/KVM-basiert) das „Hyper-V Networking“ zu installieren, war für mich nicht nachvollziehbar. Angeblich sei das für WireGuard-VPN nötig?! Das Eventlog zeigte jedenfalls mehr als nur „Hyper-V Networking“ – vielleicht hatte er sich jemand verklickt.

Mir ist kein explizites „Hyper-V Networking“ bekannt. Windows bietet auf dem Client die folgenden Features an:

• Hyper-V Platform / Hyper-V Hypervisor
• Hyper-V Platform / Hyper-V Services

Vor dem Reboot sah der Taskmanager noch wie folgt aus …

Die Konsequenzen waren aber dem Reboot zu sehen und verheerend.

Der Screenshot zeigt nicht das gesamte Ausmaß des Desasters, die virtuellen CPUs liefen über weite Strecken auf 100% und ein Arbeiten war nicht mehr möglich. Weder RDP-Sitzungen noch TeamViewer funktionierten. Auch mehr vCPUs halfen nicht wesentlich.

Ich konnte die Last auf etwa 40 % drücken – aber die VM blieb träge. Sehr träge.

Sobald die Hyper-V-Rolle innerhalb des Windows 11-Gastsystems installiert ist, beginnt sich die virtuelle Maschine selbst wie ein Hyper-V-Host zu verhalten (oder versucht es zumindest). Dies verändert die Art und Weise, wie Windows mit der zugrunde liegenden Hardware und der Virtualisierungsschicht interagiert und führt häufig zu:

• Konflikten bei verschachtelter Virtualisierung: Hyper-V innerhalb einer VM (Nested Virtualization) kann mit den eigenen Virtualisierungsmechanismen von QEMU/KVM interferieren.
• Problemen bei der Interrupt-Verarbeitung: Das System kann auf andere Taktquellen oder Interrupt-Modelle umschalten (z. B. hyperv_clocksource_tsc_page vs. tsc), was zu übermäßigen System-Interrupts und einer verschlechterten Leistung führen kann
• Verändertes Timer- und Polling-Verhalten: Hyper-V kann beeinflussen, wie das Gastbetriebssystem Leerlaufzustände und Interrupts behandelt – insbesondere, wenn Funktionen wie halt_poll nicht abgestimmt sind

Ein zeitaufwändig erstellter Dump des Systemprozesses (PID 4) zeigte massenhaft IRPs – ein weiteres Indiz für Probleme durch Hypervisor-Verschachtelung.

Hyper-V musste also wieder runter

Final blieb nur die Möglichkeit Hyper-V zu entfernen, was dem Dienstleister nicht wirklich gefallen hat. Die Lösung war die Installation des RISE-Konnektors auf einen der PCs in der Praxis, wobei hier auf das Hinzufügen der Hyper-V Rolle verzichtet wurde?!Wir fragen nicht und nehmen die Alternative mal einfach so hin

Die beiden folgenden PowerShell Aufrufe zeigten halfen das System dann anschließend zu korrigieren und in einen nutzbaren Zustand zu versetzen:

# Anzeigen aller aktivierten (enabled) Features in Windows 11
Get-WindowsOptionalFeature -Online | Where-Object {$_.State -eq "Enabled"}
# Deaktivieren der Hyper-V Rolle + manuellem Reboot hinterher
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

Nach dem Neustart lief der RISE-Konnektor mit ~10 % Systemlast. Der Dienstleister war da schon am nächsten PC – und ich hatte ehrlich gesagt keine Lust mehr. Hauptsache, die VM lief wieder.

So, genügend – einfach aufpassen und schauen, was “Fachkräfte” auf den Systemen so installieren und sich die Systemanforderungen im Vorfeld schriftlich per Mail besorgen.

Enjoy it, b!