Réinstallation d’un nœud Nutanix Community Edition sur du matériel qui portait déjà un AHV. L’installeur Phoenix démarre, détecte le matériel, puis s’arrête sur une traceback Python :

FATAL An exception was raised: Traceback (most recent call last):
  File "/root/phoenix/./phoenix", line 155, in <module>
    main()
  ...
  File "/root/phoenix/sysUtil.py", line 2086, in mount_ahv_lvm_volumes
    shell_cmd(['mount', '-t ext4', dev, target + mntpnt])
Exception: Failed command: [mount -t ext4 /dev/mapper/ahv-varlog /mnt/stage/var/log]
with error: [mount: /mnt/stage/var/log: special device /dev/mapper/ahv-varlog does not exist.]

Le message semble parfaitement exact, et c’est ce qui le rend trompeur : le périphérique n’existe pas. La vraie question est de savoir pourquoi Phoenix le cherche.

Comprendre pourquoi l’installeur Nutanix plante

La pile d’appels raconte toute l’histoire, à condition de la lire de bas en haut :

• get_params → determine_actions → get_hyp_state
• get_hyp_state → customize_kvm.get_state → __mount_kvm_partition → mount_ahv_lvm_volumes

Phoenix ne plante pas pendant l’installation. Il plante avant, pendant la phase de détection, quand il essaie de déterminer quelles actions proposer. Il a trouvé un hyperviseur existant sur le disque, il a donc basculé sur son chemin customize (celui qui met à jour un AHV en place plutôt que d’en installer un neuf) et ce chemin exige de monter les volumes de l’installation existante.

Les lignes de log qui précèdent confirment le raisonnement :

INFO Calling dmsetup remove /dev/mapper/ahvstorage-varlogaudit
INFO Calling dmsetup remove /dev/mapper/ahvstorage-varlog
INFO LVM volume group ahv detected
INFO Found block device entry /dev/mapper/ahv-root, calling vgchange -an ahv

Deux groupes de volumes distincts apparaissent : ahv et ahvstorage. Un lvs depuis le shell de secours confirme la répartition :

Voilà le décalage. Sur le disque, varlog vit dans le VG ahvstorage. L’ISO Phoenix, lui, cherche /dev/mapper/ahv-varlog, c’est-à-dire varlog dans le VG ahv. Il applique un schéma LVM qui n’est pas celui présent sur la machine.

L’explication la plus probable est un écart de génération : le layout AHV a évolué vers un VG de stockage séparé, et le média utilisé pour la réinstallation attend la disposition antérieure. Résultat, Phoenix reconnaît assez bien l’installation existante pour vouloir la réutiliser, mais pas assez pour savoir la monter.

La Solution : Faire table rase du disque système

Puisque le blocage tient entièrement à la détection d’une installation préexistante, la solution est de faire en sorte qu’il n’y ait plus rien à détecter.

Phoenix laisse un shell root accessible après l’échec. On commence par cartographier avant de détruire :

lsblk
pvs
vgs
lvs

Dans mon cas, deux PV sur un seul disque : /dev/sda3 pour ahv, /dev/sda5 pour ahvstorage.

Puis on démonte les VG et on les supprime :

vgchange -an ahvstorage
vgremove -f ahvstorage

ahvstorage disparaît sans résistance. ahv, lui, s’obstine :

Logical volume ahv/root contains a filesystem in use.
Can't deactivate volume group "ahv" with 2 open logical volume(s)

Le second problème : les volumes restés montés

Ce message est le vrai point de bascule de la procédure, et la sortie de lvs en donne la clé :

root  ahv  -wi-ao----
var   ahv  -wi-ao----

L’attribut o signifie open. Ces deux volumes logiques sont montés. Ce sont les « 2 open logical volume(s) » du message d’erreur, et c’est ce qui fait ensuite échouer toute la chaîne :

pvremove -ff -y /dev/sda3
  Can't open /dev/sda3 exclusively. Mounted filesystem?
  Cannot use /dev/sda3: device has a signature

wipefs -a /dev/sda
  wipefs: error: /dev/sda: probing initialization failed: Device or resource busy

La cause est simple : Phoenix avait monté root et var sous /mnt/stage avant de planter sur varlog, et il n’a rien démonté en sortant. L’échec a laissé le disque dans un état intermédiaire.

Il faut donc démonter avant tout le reste :

findmnt -R /mnt/stage
umount -R /mnt/stage

Si un processus tient encore la partition :

fuser -vm /mnt/stage
fuser -km /mnt/stage

On vérifie que les LV sont bien fermés, l’attribut doit être -wi-a-----, sans le o :

lvs

Et seulement ensuite, l’effacement complet :

vgchange -an ahv
vgremove -f ahv
pvremove -ff -y /dev/sda3
wipefs -a /dev/sda
sgdisk --zap-all /dev/sda
dd if=/dev/zero of=/dev/sda bs=1M count=100 conv=fsync

Le sgdisk --zap-all n’est pas décoratif. Une table GPT possède une copie de secours en fin de disque, que le dd sur les 100 premiers mégaoctets laisse parfaitement intacte. C’est la raison pour laquelle des groupes de volumes « reviennent » après un effacement qu’on croyait complet.

Si les disques de données CVM portent eux aussi des résidus, on leur applique le même traitement : wipefs -a puis sgdisk --zap-all sur chacun.

Reboot, relance de l’installeur, et Phoenix ne détecte plus rien : il propose une installation neuve.

Ce que je retiens de cette réinstallation

Un message d’erreur exact peut désigner le mauvais problème :

« ahv-varlog n’existe pas » est littéralement vrai et complètement hors sujet. Le problème n’est pas l’absence du volume, c’est que l’installeur applique un schéma qui n’est pas celui du disque. Sans lire la pile d’appels, on part chercher un volume manquant au lieu de comprendre qu’on est dans la mauvaise branche du programme.

Un échec d’installeur laisse un état :

Phoenix a planté après avoir monté deux volumes, et ces montages ont survécu à son arrêt. Tous les échecs de la séquence suivante (pvremove, wipefs) en découlaient directement. Avant de lutter contre un « Device or resource busy », il faut chercher ce qui tient le périphérique.

Un cluster explicitement destructible change la nature du problème :

Cette procédure est brutale : elle efface tout. Elle n’est acceptable que parce que ce nœud appartient à un environnement désigné comme sacrifiable, dont aucune donnée irremplaçable ne dépend. Décider à l’avance quel cluster est jetable ne change rien à la panne, mais change entièrement le temps qu’on passe à la résoudre.