Wenn der Installer würfelt: Nutanix Foundation scheitert sporadisch in clean_disks

Bei einem 3-Node-Deployment von Dell XC760-14 mit Nutanix AHV ist uns die CVM-Installation reproduzierbar, aber scheinbar zufällig um die Ohren geflogen: erst nur auf Node 3, nach einem Neustart plötzlich auch auf Node 2. Die Ursache war weder Hardware noch Firmware, sondern ein Timing-Problem zwischen dem Phoenix-Installer und udev. Ein einzeiliger Workaround hat das Deployment gerettet.

In diesem Beitrag zeigen wir, wie sich der Fehler äußert, wie wir ihn eingegrenzt haben und wie Sie ihn umgehen.

Die Umgebung

Drei identische Nodes, alle mit demselben Firmware-Stand. Das wird später noch wichtig.

Das Fehlerbild

In der Foundation-GUI bleibt der betroffene Node bei „fatal: Running CVM Installer, Starting host installer“ stehen. Das Node-Log zeigt nur eine nichtssagende Meldung:

Imaging thread 'svm' failed with reason [None]
CRITICAL AOS installation failed. Reason: None

Die eigentliche Ursache steht weiter oben, in der Ausgabe von svm_rescue bzw. clean_disks:

INFO  clean_disks:130 Formatting partition /dev/sda1 with ext4
...   (sda1 wird erfolgreich formatiert, ca. 13 s)
INFO  clean_disks:130 Formatting partition /dev/sdb1 with ext4
ERROR luks_util.py:143 Failed to check if the partition /dev/sdb1 is LUKS encrypted. ret: 2
ERROR disk.py:465 Failed to get size for partition /dev/sdb1 ... blockdev: cannot open /dev/sdb1: No such file or directory
CRITICAL clean_disks:345 Failed to clean partitions: [...]

Der Installer hat die Partition wenige Sekunden vorher selbst angelegt, findet sie beim Formatieren aber nicht. Im lsblk am Ende des Logs ist sie wieder da. Welche HDD es trifft, wechselt: mal sdb1, mal sda1.

Die übrigen Fehler im Log sind Rauschen und für das Problem irrelevant: fehlendes ipmitool auf dem Foundation-Rechner, ipmicfg -tp (TwinPro, ein Supermicro-Tool) sowie factory_config.json und release_version im Chroot.

Was es nicht war

Der naheliegende Verdacht ist eine defekte Disk. Diese Spuren haben wir nacheinander ausgeschlossen:

Der entscheidende Hinweis kam aus dem Wiederholen: Nach einem Kaltstart traf es eine andere Disk. Später scheiterten auch zwei Nodes, die vorher sauber durchgelaufen waren. Ein Hardware-Defekt wandert nicht, ein Timing-Problem schon.

Die Ursache: ein Wettlauf mit udev

Der Kernel-Log (dmesg) im laufenden Phoenix zeigt den Mechanismus:

[354.03]  sdf:          ← Installer löscht die alten Partitionstabellen
[355.65]  sdc:
[357.16]  sdd:
[358.53]  sde:
[360.11]  sda:
[361.70]  sdb:
[363.49]  sda: sda1     ← plötzlicher Komplett-Rescan von sda
          → unmittelbar danach: blockdev: cannot open /dev/sda1

So kommt es zum Fehler:

1. repartition_disks legt die neue Partition per parted an. Der Kernel trägt sie still ein, im dmesg erscheint dazu nichts.
2. clean_disks prüft direkt vor dem Formatieren, ob die Disk ein Self-Encrypting Drive ist. Dafür öffnet es das Gerät und schließt es wieder.
3. udev überwacht Block-Devices per inotify. Wird eine Disk nach einem Schreib-Open geschlossen, stößt udev einen Rescan der Partitionstabelle an.
4. Beim Rescan entfernt der Kernel alle Partitionen der Disk kurz und legt sie neu an. Das ist die Zeile sda: sda1.
5. Fällt der nächste Zugriff von clean_disks (cryptsetup, blockdev --getsize64) genau in diese Lücke, existiert /dev/sdX1 nicht, und die Installation bricht ab.

Ob es knallt, entscheiden Millisekunden. Deshalb trifft es mal diesen, mal jenen Node und mal diese, mal jene Disk. Mit 8-TB-HDDs, deren Formatierung (mke2fs mit bigalloc) rund 13 Sekunden dauert, scheint das Zeitfenster ungünstig zu liegen.

Der Workaround: udev-Watch im Phoenix abschalten

Wir schalten für die Dauer der Installation die udev-Überwachung der Datendisks ab. Die Regel lebt nur im RAM des laufenden Phoenix und ist nach dem nächsten Reboot automatisch weg.

1. Deployment in Foundation starten.
2. Warten, bis im Node-Log Rebooted into Phoenix successfully steht. Bis zum Start des CVM-Installers bleiben dann etwa 2 bis 5 Minuten, je nachdem, wie schnell das AOS-Paket übertragen wird.
3. Per SSH auf die CVM-IP des Nodes verbinden. Phoenix-Standardlogin: root / nutanix/4u. Da Phoenix bei jedem Boot einen neuen Host-Key erzeugt, lohnt sich hier die Option ohne Key-Prüfung:

   ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@<CVM-IP>

4. Regel setzen und anwenden:

   echo 'SUBSYSTEM=="block", KERNEL=="sd*", OPTIONS+="nowatch"' > /etc/udev/rules.d/99-nowatch.rules
   udevadm control --reload
   udevadm trigger --action=change --subsystem-match=block
   udevadm settle

5. Optional prüfen, ob die Regel wirkt. Der Befehl öffnet und schließt sda nur und schreibt nichts. Taucht danach keine neue sda:-Zeile im dmesg auf, ist die Überwachung aus:

   dmesg | tail -1; exec 3<>/dev/sda; exec 3>&-; sleep 2; dmesg | tail -1

Bei mehreren Nodes geht das vom Admin-Rechner aus in einer Schleife:

for ip in <CVM-IP-1> <CVM-IP-2> <CVM-IP-3>; do
  ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@$ip 
  'echo "SUBSYSTEM=="block", KERNEL=="sd*", OPTIONS+="nowatch"" > /etc/udev/rules.d/99-nowatch.rules && udevadm control --reload && udevadm trigger --action=change --subsystem-match=block && udevadm settle && echo "$(hostname -I) OK"'
done

Mit der Regel lief die CVM-Installation auf dem zuvor dreimal gescheiterten Node beim ersten Versuch durch.

Fazit

„AOS installation failed. Reason: None“ heißt nur, dass Foundation den Grund nicht kennt. Die Antwort steht fast immer weiter oben im Node-Log, in der Ausgabe von svm_rescue. Unsere Empfehlungen:

• Bei sporadischen clean_disks-Fehlern mit „cannot open /dev/sdX1″ zuerst an das Timing denken, nicht an die Disk.
• dmesg im laufenden Phoenix ist der schnellste Weg zur Ursache: Ein Rescan wie sdX: sdX1 direkt vor dem Fehler ist das Erkennungszeichen.
• Der Workaround ist ein Eingriff in die Installationsumgebung und kein offizieller Fix. Melden Sie den Fall parallel beim Hersteller-Support. Bei Dell XC läuft auch der Nutanix-Support über Dell.
• Vor dem Deployment prüfen, ob eine neuere Foundation-Version verfügbar ist.

Wir haben den Fall an den Support gemeldet und ergänzen diesen Beitrag, sobald es eine offizielle Lösung gibt.

Sie planen ein Nutanix-Deployment oder hängen gerade selbst in Foundation fest? Sprechen Sie uns an, wir helfen gern.