Aller au contenu

Recette post-migration : perf, sauvegarde, HA

Day 1 · DéployerNiveau 2 · OpérerChecklistRédigé · à valider en lab

Objectif. Déclarer une VM migrée (ici VMID 101) « bonne pour la production » seulement après avoir vérifié sa configuration, ses performances, sa sauvegarde, sa restauration et sa reprise sur un autre nœud. Tant que cette checklist n'est pas complète, la VM source reste éteinte mais conservée.

Mode d'emploi

Une copie de cette checklist par VM, ou par groupe de VMs d'une même application. Collez les sorties de commandes dans votre dossier de migration : elles serviront de référence en cas d'incident.

1. Configuration Proxmox

  • Contrôleur et disques paravirtualisés : qm config 101 montre scsihw: virtio-scsi-single et scsi0: …,discard=on,iothread=1.
  • Carte réseau VirtIO sur le bon bridge et VLAN : net0: virtio=…,bridge=vmbr0,tag=….
  • Agent activé et joignable : agent: enabled=1 (ou agent: 1) et qm guest cmd 101 ping sans erreur.
  • Type de CPU compatible avec tous les nœuds (pas host sur un cluster hétérogène) : ligne cpu:.
  • Type d'OS correct (ostype: win11, win2k22, l26…) : il conditionne certaines optimisations.
  • Ordre de démarrage propre, aucun disque unusedN ni lecteur CD virtio-win oublié.
  • VM UEFI : bios: ovmf et efidisk0 présents ; VM avec vTPM : tpmstate0 présent.
  • Démarrage automatique au boot du nœud si nécessaire : Options → Start at boot (onboot: 1).
  • Tags ou pool renseignés pour retrouver la VM : tags: ou Datacenter → Permissions → Pools.

2. Système invité

  • Windows : aucun périphérique inconnu dans le Gestionnaire de périphériques ; service « QEMU Guest Agent » démarré.
  • VMware Tools ou Integration Services absents de la liste des programmes.
  • IP, masque, passerelle, DNS identiques à la source : ipconfig /all ou ip a. Adresses visibles dans VM → Summary.
  • Aucune carte réseau fantôme portant l'ancienne IP.
  • Heure synchronisée (domaine ou NTP) : w32tm /query /status ou timedatectl.
  • Windows activé ; licences applicatives liées au matériel revalidées.
  • Journaux système sans nouvelle erreur de pilote ou de disque depuis le premier démarrage.

3. Performances

  • Charge CPU et RAM comparables à la référence VMware sur une période d'usage normal : VM → Summary, graphiques en moyenne horaire.
  • Pas de ballooning subi par une application qui le supporte mal (bases de données) : mémoire fixe si besoin (balloon: 0).
  • Latence disque acceptable dans l'invité (Moniteur de ressources ou iostat -x 5) ; sur Ceph, ceph osd perf sans OSD à latence anormale.
  • Test applicatif métier réalisé par le propriétaire (temps de réponse d'une transaction type) et validé par écrit.
  • Espace récupéré après suppression de fichiers (discard actif) : fstrim -av sous Linux, Optimiser les lecteurs sous Windows ; occupation réelle visible dans pvesm list ceph-vm --vmid 101 ou rbd du -p ceph-vm vm-101-disk-0.

4. Sauvegarde et restauration

  • VM incluse dans un job de sauvegarde vers pbs-local : Datacenter → Backup → job → Job Detail liste le VMID 101.
  • Première sauvegarde manuelle réussie : vzdump 101 --storage pbs-local --mode snapshot, tâche terminée par TASK OK.
  • Gel du système de fichiers par l'agent effectif : le journal de la tâche mentionne issuing guest-agent 'fs-freeze' command puis fs-thaw.
  • Test de restauration sous un autre VMID, réseau déconnecté, démarrage vérifié (RB-12).
  • Restauration d'un fichier testée (RB-13).
  • Sauvegarde présente sur le PBS du MSP après le sync suivant (RB-15).

5. Haute disponibilité et mobilité

  • Migration à chaud vers chaque autre nœud réussie : qm migrate 101 pve02 --online, application toujours joignable pendant l'opération.
  • VM déclarée en ressource HA si elle est critique : ha-manager add vm:101 --state started, puis ha-manager status affiche service vm:101 (pve01, started).
  • Règles d'affinité posées si deux VMs doivent être séparées (deux contrôleurs de domaine sur deux nœuds) : Datacenter → HA → Rules. Voir HA.
  • Architecture ZFS 2 nœuds : réplication configurée et à jour, pvesr status montre le job 101-0 en OK (RB-11).
  • Test de bascule HA réalisé en fenêtre de maintenance sur une VM représentative, si le contrat le prévoit, avec le MSP.

6. Exploitation

  • VM visible dans la supervision (sonde Zabbix, Prometheus ou métriques Proxmox) avec seuils définis.
  • Documentation d'exploitation mise à jour : nouveau VMID, nœud, stockage, procédure d'arrêt.
  • Propriétaire métier informé de la fin de migration.

7. Décommissionnement de la source

  • Période d'observation terminée (durée fixée dans le plan de migration).
  • VM source supprimée de l'inventaire VMware ou Hyper-V seulement après validation écrite.
  • Stockage esxi d'import retiré du cluster une fois toutes les vagues terminées : pvesm remove esxi01.
  • Fichiers de transit supprimés : ls /var/lib/vz/import/ vide.

Pièges vus en support

  • VM jamais ajoutée au job de sauvegarde : découverte le jour où il faut restaurer.
  • Sauvegarde déclarée OK sans test de restauration : la VM restaurée ne démarre pas (pilote, EFI).
  • VM migrée en type CPU host : la migration à chaud vers un nœud d'une autre génération échoue pendant une maintenance.
  • Source supprimée dès le premier jour, puis découverte d'une donnée manquante.

Quand ouvrir un ticket iTop

Performances nettement inférieures à la source sans cause trouvée : P3, avec les mesures avant / après. Sauvegarde ou sync en échec sur une VM migrée : suivre RB-14, puis P2 si l'échec se répète deux nuits. Demande de test de bascule HA accompagné : P4.

Ouvrir un ticket iTop