Der Betreiber berichtet von einer Serverauslastung im dreistelligen Bereich. Der Wert beschreibt keine überlastete CPU, sondern wartende Prozesse: Sie stehen in der Warteschlange, weil das Storage nicht antwortet.

Die im Proxmox-Webinterface angezeigte E/A-Verzögerung (IO delay) steigt über 50 Prozent. Ab diesem Bereich verbringt der Host mehr Zeit mit Warten auf Datenträger als mit Rechnen – alles auf dem Pool wird träge.

Laufende virtuelle Maschinen reagieren zeitweise nicht mehr und stehen für 20 bis 30 Sekunden. Für Anwendungen mit kurzen Zeitüberschreitungen ist das lange genug, um Verbindungen und Transaktionen abzubrechen.

In Windows-VMs erscheinen Fehler der virtio-Treiber. Der virtuelle Datenträger bestätigt Schreibvorgänge nicht innerhalb der erwarteten Zeit, der Treiber wertet das als Fehler des Geräts.

Auf einem Windows-Domänencontroller wurde nach einem Restore-Vorgang eine Beschädigung des Dateisystems festgestellt. Bei einem Verzeichnisdienst wirkt sich das unmittelbar auf Anmeldungen im gesamten Netz aus.

Datenbanken quittieren die abgebrochenen Schreibvorgänge mit beschädigten Tabellen. Solche Schäden bleiben häufig unbemerkt, bis eine Anwendung die betroffenen Daten liest.

In Linux-VMs kommt es zu Kernel-Hangs. Prozesse bleiben im nicht unterbrechbaren Wartezustand stehen; ein sauberes Beenden ist dann meist nicht mehr möglich, es bleibt der Neustart der VM.

Ein gesetztes Bandbreitenlimit – im gemeldeten Fall 200 MiB/s – wurde beim Restore nicht wirksam angewendet. Die naheliegende Gegenmaßnahme, den Vorgang einfach zu drosseln, greift damit nicht zuverlässig.