kein Zugriff mehr auf Storage nach Update

[bedee]

Hallo

Habe heute einen meinen ESXi 4 Host upgedate auf 4.1.0 381591
Dieser läuft zusammen mit einem anderen ESXi Host (4.1.0 320137) in einem Cluster. Via hba (qLogic isp2432) steht den beiden Hosts ein LUN auf dem IBM SAN zur Verfügung.
Nach dem Upgrade und Reboot sehe ich nun das Datastore nicht mehr. Ein Rescan der hba bringt auch keine Erfolg.
Beim Storage Adapter sehe ich die Disk, LunID, Grösse etc, somit ist der SAN Pfad korrekt. Es gab ja auch keine Änderungen im SAN Netzwerk.
Wenn ich Add Storage ausführe, wird mir das bestehende vmfs Volume nicht angezeigt.
Der zweite Host hat nach wie vor Zugriff auf das LUN. Die VM laufen ohne Probleme.

im message log bekomme ich folgende Fehler, wenn ein esxcfg-rescan vmhba2 ausgeführt wird.

May 4 14:12:44 shell[9058]: esxcfg-rescan vmhba2
May 4 14:12:44 vmkernel: 0:00:05:51.937 cpu1:9295)ScsiScan: 1059: Path 'vmhba2:C0:T0:L18': Vendor: 'IBM ' Model: '1815 FAStT ' Rev: '0914'
May 4 14:12:44 vmkernel: 0:00:05:51.937 cpu1:9295)ScsiScan: 1062: Path 'vmhba2:C0:T0:L18': Type: 0x0, ANSI rev: 5, TPGS: 0 (none)
May 4 14:12:44 vmkernel: 0:00:05:51.937 cpu1:9295)ScsiScan: 1059: Path 'vmhba2:C0:T1:L18': Vendor: 'IBM ' Model: '1815 FAStT ' Rev: '0914'
May 4 14:12:44 vmkernel: 0:00:05:51.937 cpu1:9295)ScsiScan: 1062: Path 'vmhba2:C0:T1:L18': Type: 0x0, ANSI rev: 5, TPGS: 0 (none)
May 4 14:12:44 vmkernel: 0:00:05:51.970 cpu2:9295)Vol3: 1604: Could not open device 'naa.6842b2b05b06480014517d1e0a2a4b1d:8' for probing: Permission denied
May 4 14:12:44 vmkernel: 0:00:05:51.971 cpu2:9295)Vol3: 644: Could not open device 'naa.6842b2b05b06480014517d1e0a2a4b1d:8' for volume open: Permission denied
May 4 14:12:44 vmkernel: 0:00:05:51.974 cpu2:9295)Vol3: 1604: Could not open device 'naa.6842b2b05b06480014517d1e0a2a4b1d:6' for probing: Permission denied
May 4 14:12:44 vmkernel: 0:00:05:51.975 cpu2:9295)Vol3: 644: Could not open device 'naa.6842b2b05b06480014517d1e0a2a4b1d:6' for volume open: Permission denied
May 4 14:12:44 vmkernel: 0:00:05:51.978 cpu4:9295)Vol3: 1604: Could not open device 'naa.6842b2b05b06480014517d1e0a2a4b1d:5' for probing: Permission denied
May 4 14:12:44 vmkernel: 0:00:05:51.979 cpu4:9295)Vol3: 644: Could not open device 'naa.6842b2b05b06480014517d1e0a2a4b1d:5' for volume open: Permission denied

Kennt jemand dieses Problem?

[bedee]

Problem ist glöst. Hier noch kurz ein paar Infos:

Es bestand ein Fehler im zusammenhang mit dem VMFS Volume. Diese war höchstwahrscheinlich korrupt, warum später....

Solange ein Host noch Daten (VMs) im entsprechenden LUN, resp Volume laufen hatte, wurde das Datastore angezeigt. Sobald sämtliche VMs gestopt wurden auf dem zweiten Host, also keine aktiven Daten mehr im Volume liefen, war das Datastore weg... inklusive allen Daten VMs etc.... Zum Glück gibts Backups und es war nur eine Testumgebung

Ab diesem Zeitpunkt konnten dann über beide Host wie gewöhnlich ein neues Datastore erstellt werden. Die ESXi Hosts erkannten das LUN als blank Disk, vmfs neu formatieren etc...

Wie konnte ein solcher Zustand passieren? Die Vermutung liegt nahe, dass das vmfs Volume durch einen gewollten Test korrupt wurde. Als Backup wird Veeam eingesetzt, welches direkt aus dem SAN die Daten zieht, somit sicht auf die LUNs hat. Zu Versuchszwecken wollte ich auf dem Veeam Backupserver über den Windows Diskmanager, die Disk des entsprehcenden LUNs intialisieren/formatieren. Dies ging nicht und wurde einem Operation failure beendet, was eigentlich auch richtig ist. Ich gehe nun davon aus, dass doch irgendwas geändert wurde und so der Fehler entstand.

Die Permission denied Fehler im Log, haben schlussendlich nichts mit den beschriebenen Problem zu tun. Bei dem Volume handelt es sich um lokale Disks auf dem ESXi host, habe ich erst später bemerkt.

Grüsse

[Tschoergez]

Ok, danke für den ausführlichen Bericht.
Das mounten von VMFS-Partitionen an Windows-server sorgt sehr häufig für korrupte VMFS-Partitionen, deswegen steht auch ganz dick im Backup-guide: vorher automount disable und automount scrub vom diskpart ausführen
Gut, dass keine wichtigen Daten verloren gegangen sind.

Viele Grüße,
Jörg

[bedee]

youp sehe ich auch so. automount und automout scrub war disabled. Macht es so viel mir ist ab Veeam V5 sogar automatisch. Aber lieber ein mal zu viel prüfen.

Aber solche Tests mit dem Diskmanager (gewollt initialisieren und formatieren...), hoffe ich mal, dass das keiner auf einem produktiven System ausprobiert und sonst kann hier das Resulat nachgelsen werden

[ch-hunn]

Etwas Ähnliches hat mal einer bei uns im Lab gemacht: Mit seinem Notebook mal schnell was testen wollen und dem iSCSI Initiator auf den Openfiler - Bumms! Ganze Testumgebung weg!
Natürlich weil Testumgebung wenig Security und kein Backup von nichts.
Seitdem sind die LUNs für den ESXi mit IP Filter und einem Ellenlangen CHAP ala hhF34/dfDf<hTjü{34,4kÄl34" geschützt....

Chregu