Comment déterminer si le gel d’une sauvegarde de VM vient des E/S de l’invité ou du stockage de l’hôte

Correléz le moment du gel de l'agent invité avec la latence du datastore de l'hôte ; un gel avant l'apparition de la pression sur l'hôte oriente vers l'invité, tandis qu'une latence observée sur plusieurs invités oriente vers le stockage.

Cette décision est importante lorsqu'une VM se met en pause ou ne répond plus pendant une sauvegarde en mode snapshot. Les deux hypothèses concurrentes sont un délai de mise en cohérence de l'invité, de vidage du système de fichiers ou de l'application, et une latence du datastore de l'hôte, du snapshot, du réseau ou de la cible de sauvegarde. Commencez avec une configuration enregistrée et des données jetables, n'observez qu'une branche à la fois et arrêtez-vous si le test accroît le risque de perte de données, de problèmes d'autorisation ou d'indisponibilité.

Distinguer le délai de mise en cohérence de l'invité, du système de fichiers ou du vidage de l'application de la latence du datastore de l'hôte, du snapshot, du réseau ou de la cible de sauvegarde

Consignez l'environnement avant toute modification : versions des logiciels et des micrologiciels, identités des périphériques, chemin de montage ou chemin réseau, espace libre, autorisations et symptôme observable. La référence doit conserver suffisamment de détails pour reproduire le fait qu'une VM se mette en pause ou ne réponde plus pendant une sauvegarde en mode snapshot.

La première hypothèse est un délai de mise en cohérence de l'invité, du système de fichiers ou du vidage de l'application. La seconde est une latence du datastore de l'hôte, du snapshot, du réseau ou de la cible de sauvegarde. Le comportement actuel de Proxmox vzdump définit le mécanisme ou la limite de commande utilisés dans le test ; il ne remplace pas l'observation effectuée sur ce serveur domestique précis.

Écrivez la condition d'acceptation et la condition d'arrêt avant d'exécuter le test discriminant. Une réussite doit modifier les éléments attendus par une branche tout en laissant les services sans rapport inchangés ; un échec doit ramener le système à l'état enregistré plutôt que déclencher une série de corrections spéculatives.

Exécuter un seul test discriminant contrôlé

Utilisez ce test discriminant : horodatez les événements de gel et de dégel, la latence du disque invité, la latence du stockage de l'hôte et les autres comportements de la VM pendant une sauvegarde contrôlée. Conservez la charge de travail, le client, le chemin, l'ensemble de fichiers et le calendrier afin que le résultat soit attribuable à la variable modifiée.

Utilisez l'état de l'agent invité QEMU pour sélectionner le champ capable de distinguer les branches, puis capturez son horodatage, son statut de sortie, le texte de l'erreur, l'identité du périphérique ou du snapshot, la latence, le nombre d'octets transférés, les autorisations et l'état de récupération. Une sortie de commande sans erreur ne suffit pas lorsque l'identité, la durabilité ou l'état de l'application constitue l'élément testé.

Répétez le test une fois après un redémarrage, une reconnexion, un remontage ou un cache froid lorsque cet événement fait partie de la condition initiale. Si la première exécution est destructive ou si l'environnement ne peut pas être restauré, arrêtez-vous et reproduisez le test sur une copie jetable.

journalctl -u qemu-guest-agent
pvesh get /nodes/NODE/status
# corréler les horodatages avec la latence du datastore

Interpréter la branche étayée par les éléments observés

RÉUSSITE : un invité se fige tandis que l'hôte reste sain, ou plusieurs invités ralentissent alors que la file d'attente et la latence de l'hôte augmentent. Notez la version exacte, l'identité et la charge de travail ayant produit la réussite afin que la conclusion reste conditionnelle et ne devienne pas une affirmation universelle.

ÉCHEC : la bande passante de sauvegarde et les métadonnées du snapshot peuvent produire les deux signaux ; répétez donc le test avec la mise en cohérence désactivée, uniquement sur un état jetable. Un échec ne prouve pas automatiquement la branche opposée lorsque le réseau, la mémoire, les autorisations ou la cohérence de la source peuvent influencer les deux ; isolez ces dépendances communes avant d'aller plus loin.

RÉSULTAT EXCEPTIONNEL OU AMBIGU : restaurez le mode de sauvegarde précédent et dégelez l'invité avant de modifier les paramètres du stockage ou de l'agent. Conservez les journaux et n'exécutez aucune commande de réparation, de purge, de destruction, de repartitionnement ou de modification récursive des propriétaires avant de disposer d'une copie récupérable.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Appliquer l'action correspondante et reproduire l'échec initial

Appliquez l'action correspondant à la branche observée, puis reproduisez la condition initiale plutôt qu'un substitut simplifié. La décision n'est valable que lorsqu'un invité se fige tandis que l'hôte reste sain, ou lorsque plusieurs invités ralentissent avec une file d'attente et une latence de l'hôte en hausse pendant deux cycles ou lors du redémarrage, de la sortie de veille, de l'interruption ou de la transition de charge concerné.

Utilisez les modes de sauvegarde Proxmox pour vérifier le flux de travail dépendant le plus proche, mais conservez le déclencheur initial inchangé. Les jeux de données, partages, conteneurs, utilisateurs et points de récupération sans rapport doivent conserver leur accès et leur comportement temporel précédents.

La limite d'arrêt est explicite : si la bande passante de sauvegarde et les métadonnées du snapshot peuvent produire les deux signaux, répétez donc le test avec la mise en cohérence désactivée, uniquement sur un état jetable, revenez à la dernière configuration vérifiée, conservez les éléments observés et ne passez à un test plus approfondi de la plateforme ou du matériel que lorsque la branche est reproductible.

Une fois le résultat cible obtenu, comparez-le aux dépendances d'arrêt afin que la correction ne déplace pas le risque vers un service voisin. Un test cible réussi qui entraîne une nouvelle défaillance de sauvegarde, d'identité, de délai d'attente ou de disponibilité reste une modification échouée.

FAQ

Pour diagnostiquer le gel d'une VM pendant une sauvegarde, les recherches restantes portent généralement sur les questions suivantes : la désactivation du gel de l'invité prouve-t-elle que l'agent est en cause, pourquoi toutes les VM se mettent-elles en pause pendant une sauvegarde et quand faut-il utiliser le mode d'arrêt. Les réponses ci-dessous séparent ces cas particuliers de la décision principale.

La limite d'acceptation ne change pas : un invité se fige tandis que l'hôte reste sain, ou plusieurs invités ralentissent avec une file d'attente et une latence de l'hôte en hausse. Si une condition ultérieure modifie le système de fichiers, l'identité, le chemin réseau ou la version de l'application, répétez uniquement le test discriminant concerné par cette modification.

Arrêtez d'élargir l'expérience lorsque la bande passante de sauvegarde et les métadonnées du snapshot peuvent produire les deux signaux ; répétez donc le test avec la mise en cohérence désactivée, uniquement sur un état jetable. À ce stade, restaurez le mode de sauvegarde précédent et dégelez l'invité avant de modifier les paramètres du stockage ou de l'agent ; conservez les éléments observés avant de faire remonter le problème au responsable de la plateforme, du stockage ou du matériel.

La désactivation du gel de l'invité prouve-t-elle que l'agent est en cause ?

Elle isole le chemin de mise en cohérence, mais peut réduire la cohérence de l'application ; utilisez-la uniquement comme test contrôlé.

Pourquoi toutes les VM se mettent-elles en pause pendant une sauvegarde ?

La file d'attente du stockage de l'hôte, les métadonnées du snapshot ou la bande passante de sauvegarde peuvent affecter le datastore partagé.

Quand faut-il utiliser le mode d'arrêt ?

Lorsqu'un arrêt propre est requis et que sa durée d'indisponibilité correspond à l'objectif de récupération.

Le diagnostic est terminé lorsque la même charge de travail fait suivre les éléments observés au délai de mise en cohérence de l'invité, du système de fichiers ou du vidage de l'application, ou à la latence du datastore de l'hôte, du snapshot, du réseau ou de la cible de sauvegarde, et que l'action correspondante supprime le symptôme initial sans en créer un second. Si aucune branche ne reste reproductible, conservez les journaux et l'état enregistré intacts ; l'incertitude justifie une escalade, pas l'empilement de nouvelles corrections.