Beim Versuch, VMware Virtual SAN auf einen kleinen 3-Node-Cluster zu aktiveren, tauchten einige der in den ESXi-Hosts verbauten SATA-Platten einfach nicht im VSAN-Assistenten für das Disk-Claiming auf. Sie waren also für VSAN nicht berechtigt (ineligible). Warum ?

Ist eine HDD für VSAN nicht „berechtigt“ kann sie nicht als Datenplatte zum Kapazitäts-Tier beitragen. In diesem Fall lag das offenkundig daran, dass trotz zuvor per GUI entfernter Datastores offenbar noch VMFS-Partitionen vorhanden waren, die die Verwendung für VSAN verhinderten. Dies wiederrum kann dann der Fall sein, wenn einer VMFS-Partition (beim ESXi-Setup automatisch so konfiguriert) zur Aufnahme von Coredumps im Dateisystem dient oder als Scratch-Location. Die betreffenden Partitionen müssen also manuell entfernt werden.

Trotzdem soll an dieser Stelle noch auf die vSAN-Fehlersuchbefehle der RVC (Ruby vSphere Console) hingewiesen werden Diese startet man auf der Windows-vCenter-Version mit …

~%PROGRAMFILES%\VMware\Infrastructure\VirtualCenter Server\support\rvc\rvc.bat

… und an der  vCenter Server Appliance

rvc root@localhost

So findet man z.B. mit

vsan.disks_info <Host>

schnell heraus, welche Disks für vSAN „ineligible“ sind. Auch hier ist ersichtlich: der Grund dass die betreffenden Disks nicht für VSAN „claim-bar“ sind besteht darin, dass VMFS-Volumes auf den Disks existieren.

Korrespondieren diese nicht mittelbar mit einem Datastore, den man meist über die GUi erfolgreich entfernen kann, kann man diese mit dem Tool „partedUtil“ per SSH oder ESX-Shell löschen, wobei man sich aber anhand der Geräte und Partitionsnamen ganz sicher sein muss, auch die richtigen Partitionen zu löschen, wie z. B.

partedUtil delete „/dev/disks/t10.ATA_____WD5003ABYX2D88_______________________LEN______WD2DWMAYP6589359“ 1

Sollte das nicht funktionieren, hilft zum Löschen der Partition nur noch die „harte Tour“ mittels

dd if=/dev/zero of=“/dev/disks/<DISK>“ bs=512 count=34 conv=notrunc

Wurden alle “störrischen” Partitionen entfernt, muss man 1 Mal den Adapter neu scannen mit

esxcli storage core adapter rescan –all

.. und die Disks sollten anschließend für VSAN nutzbar.

Ergänzend sei noch erwähnt, dass seit der vSphere/vCenter-Version 6.0 U2 auch im Web-Client eine Option zum Löschen von Partitionen zur Verfügung steht. Hierzu navigiert man bei markiertem Host zu „Configure / Storage Adapters“, markiert den gewünschten Adapter, wechselt dann unten bei „Adapter Details“ zum gewünschten Device und klickt auf das letzte Icon vor den Menü „All Actions“. In folgender Abbildung findet sich eine VMware Diagnostic Partition (CoreDump).

Nach dem Löschen der CoreDump-Partition auf der lokalen SATA-Disk, kann man den Host auf der Kommandozeile jederzeit mit

esxcli system coredump partition set –enable true –smart

veranlassen, selbst eine passende Diagnostic-Partition auf dem USB-Device anzulegen. Der korrespondierende erweitere Konfigurations-Parameter lautet: „VMkernel.Boot.autoPartitionCreateUSBCoreDumpPartition„. Mit dem erweiterten Parameter „VMkernel.Boot.autoCreateDumpFile“ kann man zudem erzwingen, dass der ESXi-Host bei nicht vorhandener Diagnostic-Partition Coredumps in eine Datei schreibt, die irgendwo auf einem zugänglichen VMFS-Datastore liegt.