So erkennen Sie, ob ein VM-Backup-Stillstand durch Gast-I/O oder Host-Speicher verursacht wird

Bringen Sie den Zeitpunkt des Einfrierens des Guest-Agents mit der Latenz des Host-Datastores in Zusammenhang: Tritt das Einfrieren vor Anzeichen einer Host-Überlastung auf, deutet dies auf den Gast hin, während eine Latenz über mehrere Gäste hinweg auf den Speicher hindeutet.

Die Entscheidung ist relevant, wenn eine VM während einer Sicherung im Snapshot-Modus pausiert oder nicht mehr reagiert. Die beiden konkurrierenden Zustände sind das Quiescen des Gasts, das Verzögern des Flush-Vorgangs von Dateisystem oder Anwendung sowie die Latenz des Host-Datastores, von Snapshots, des Netzwerks oder des Sicherungsziels. Beginnen Sie mit einer gespeicherten Konfiguration und nicht kritischen Daten, beobachten Sie jeweils nur einen Zweig und brechen Sie ab, wenn der Test das Risiko von Datenverlust, Berechtigungsproblemen oder Nichtverfügbarkeit erhöht.

Verzögerung beim Quiescen des Gasts, beim Flush von Dateisystem oder Anwendung von der Latenz des Host-Datastores, von Snapshots, des Netzwerks oder des Sicherungsziels trennen

Dokumentieren Sie die Umgebung, bevor Sie etwas ändern: Software- und Firmwareversionen, Geräteidentitäten, Einhänge- oder Netzwerkpfad, freien Speicherplatz, Berechtigungen und das beobachtbare Symptom. Die Ausgangsbasis muss genügend Details enthalten, um reproduzieren zu können, dass eine VM während einer Sicherung im Snapshot-Modus pausiert oder nicht mehr reagiert.

Der erste mögliche Verursacher ist eine Verzögerung beim Quiescen des Gasts, beim Flush des Dateisystems oder der Anwendung. Der zweite ist eine Latenz des Host-Datastores, von Snapshots, des Netzwerks oder des Sicherungsziels. Das aktuelle Proxmox-Verhalten von vzdump definiert den im Test verwendeten Mechanismus oder die Befehlsgrenze; es ersetzt nicht die Beobachtung dieses konkreten Heimservers.

Legen Sie die Akzeptanz- und Abbruchbedingungen fest, bevor Sie den Unterscheidungstest ausführen. Ein erfolgreicher Test muss die von einem Zweig vorhergesagten Anzeichen verändern, während unabhängige Dienste unverändert bleiben; bei einem Fehlschlag muss das System in den gespeicherten Zustand zurückversetzt werden, anstatt eine Kette spekulativer Reparaturen auszulösen.

Einen kontrollierten Unterscheidungstest durchführen

Verwenden Sie diesen Unterscheidungstest: Erfassen Sie Zeitstempel der Freeze-/Thaw-Ereignisse, die Latenz der Gastfestplatte, die Latenz des Host-Speichers und das sonstige Verhalten der VM während einer kontrollierten Sicherung. Halten Sie Workload, Client, Pfad, Dateisatz und Zeitplan konstant, damit das Ergebnis der geänderten Variable zugeordnet werden kann.

Verwenden Sie den Zustand des QEMU-Gast-Agents, um das Feld auszuwählen, das die beiden Zweige tatsächlich voneinander trennen kann. Erfassen Sie anschließend Zeitstempel, Exit-Status, Fehlertext, Geräte- oder Snapshot-Identität, Latenz, übertragene Bytes, Berechtigungen und Wiederherstellungsstatus. Ein sauberer Befehlsabschluss reicht nicht aus, wenn Identität, Dauerhaftigkeit oder Anwendungsstatus Gegenstand der Prüfung sind.

Wiederholen Sie den Test nach einem Neustart, einer erneuten Verbindung, einem erneuten Einhängen oder einem Kaltcache, wenn ein solches Ereignis Teil der ursprünglichen Bedingung ist. Ist der erste Durchlauf destruktiv oder kann die Umgebung nicht wiederhergestellt werden, brechen Sie ab und reproduzieren Sie den Vorgang stattdessen mit einer nicht kritischen Kopie.

journalctl -u qemu-guest-agent
pvesh get /nodes/NODE/status
# Zeitstempel mit der Datastore-Latenz abgleichen

Auswerten, welchen Zweig die Belege stützen

BESTANDEN: Ein Gast friert ein, während der Host gesund bleibt, oder mehrere Gäste werden bei steigender Host-Warteschlange und Latenz langsamer. Notieren Sie die genaue Version, Identität und den Workload, mit denen der Test bestanden wurde, damit die Schlussfolgerung bedingt bleibt und nicht zu einer allgemeingültigen Aussage wird.

FEHLGESCHLAGEN: Sicherungsbandbreite und Snapshot-Metadaten können beide Signale erzeugen. Wiederholen Sie den Test daher mit deaktiviertem Quiescen, aber nur mit nicht kritischen Daten. Ein Fehlschlag beweist nicht automatisch den jeweils anderen Zweig, wenn Netzwerk, Arbeitsspeicher, Berechtigungen oder Quellkonsistenz beide beeinflussen können. Isolieren Sie diese gemeinsamen Abhängigkeiten, bevor Sie die Untersuchung ausweiten.

AUSNAHME ODER MEHRDEUTIGES ERGEBNIS: Stellen Sie den vorherigen Sicherungsmodus wieder her und heben Sie das Einfrieren des Gasts auf, bevor Sie Speicher- oder Agent-Einstellungen ändern. Bewahren Sie die Protokolle auf und führen Sie keine Reparatur-, Bereinigungs-, Lösch-, Partitionierungs- oder rekursiven Besitzänderungsbefehle aus, bevor eine wiederherstellbare Kopie vorhanden ist.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Die passende Maßnahme anwenden und den ursprünglichen Fehler reproduzieren

Wenden Sie die zum beobachteten Zweig passende Maßnahme an und wiederholen Sie anschließend die ursprüngliche Bedingung statt eines reduzierten Ersatztests. Die Entscheidung gilt nur, wenn ein Gast einfriert, während der Host gesund bleibt, oder mehrere Gäste über zwei Zyklen beziehungsweise beim relevanten Neustart, Ruhezustand, der Unterbrechung oder dem Lastübergang bei steigender Host-Warteschlange und Latenz langsamer werden.

Verwenden Sie die Proxmox-Sicherungsmodi, um den nächstgelegenen abhängigen Ablauf zu prüfen, aber lassen Sie den ursprünglichen Auslöser unverändert. Unabhängige Datensätze, Freigaben, Container, Benutzer und Wiederherstellungspunkte müssen weiterhin denselben Zugriff und dasselbe Zeitverhalten wie zuvor aufweisen.

Die Abbruchgrenze ist eindeutig: Wenn Sicherungsbandbreite und Snapshot-Metadaten beide Signale erzeugen können, wiederholen Sie den Test mit deaktiviertem Quiescen, aber nur mit nicht kritischen Daten. Kehren Sie zum zuletzt verifizierten Zustand zurück, bewahren Sie die Belege auf und führen Sie einen tiefergehenden Plattform- oder Hardwaretest nur dann durch, wenn der Zweig reproduzierbar ist.

Nachdem das Zielergebnis erreicht wurde, vergleichen Sie es mit den Abhängigkeiten beim Herunterfahren, damit die Behebung das Risiko nicht auf einen benachbarten Dienst verlagert. Ein erfolgreicher Zieltest mit einem neuen Fehler bei Sicherung, Identität, Timeout oder Verfügbarkeit ist weiterhin eine fehlgeschlagene Änderung.

FAQ

Bei der Diagnose des Einfrierens von VMs während einer Sicherung betreffen die verbleibenden Fragen meist, ob das Deaktivieren des Einfrierens des Gasts den Agent als Ursache bestätigt, warum alle VMs während einer Sicherung pausieren und wann der Stoppmodus verwendet werden sollte. Die folgenden Antworten halten diese Sonderfälle von der eigentlichen Entscheidung getrennt.

Die Akzeptanzgrenze bleibt unverändert: Ein Gast friert ein, während der Host gesund bleibt, oder mehrere Gäste werden bei steigender Host-Warteschlange und Latenz langsamer. Wenn eine nachfolgende Bedingung das Dateisystem, die Identität, den Netzwerkpfad oder die Anwendungsversion verändert, wiederholen Sie nur den von dieser Änderung betroffenen Unterscheidungstest.

Weiten Sie das Experiment nicht weiter aus, wenn Sicherungsbandbreite und Snapshot-Metadaten beide Signale erzeugen können. Wiederholen Sie den Test dann mit deaktiviertem Quiescen, aber nur mit nicht kritischen Daten. Stellen Sie anschließend den vorherigen Sicherungsmodus wieder her und heben Sie das Einfrieren des Gasts auf, bevor Sie Speicher- oder Agent-Einstellungen ändern. Bewahren Sie die Belege auf, bevor Sie die Angelegenheit an den Plattform-, Speicher- oder Hardwareverantwortlichen eskalieren.

Beweist das Deaktivieren des Einfrierens des Gasts, dass der Agent die Ursache ist?

Es isoliert den Quiescen-Pfad, kann aber die Anwendungskonsistenz verringern. Verwenden Sie es nur als kontrollierten Test.

Warum pausieren alle VMs während einer Sicherung?

Die Warteschlange des Host-Speichers, Snapshot-Metadaten oder die Sicherungsbandbreite können den gemeinsam genutzten Datastore beeinflussen.

Wann sollte der Stoppmodus verwendet werden?

Wenn ein sauberes Herunterfahren erforderlich ist und die dafür nötige Ausfallzeit zum Wiederherstellungsziel passt.

Die Diagnose ist abgeschlossen, wenn derselbe Workload zeigt, dass die Belege der Verzögerung beim Quiescen des Gasts, beim Flush von Dateisystem oder Anwendung oder der Latenz des Host-Datastores, von Snapshots, des Netzwerks oder des Sicherungsziels folgen und die passende Maßnahme das ursprüngliche Symptom beseitigt, ohne ein weiteres zu verursachen. Wenn keiner der beiden Zweige reproduzierbar bleibt, bewahren Sie Protokolle und gespeicherten Zustand unverändert auf. Unsicherheit ist ein Grund zur Eskalation, nicht dazu, weitere Reparaturen zu stapeln.