!SOLVED! Hilfe: Datastores verschwunden Pfade aber noch vorh

[bla!zilla]

Hab ihr die ESXer geklont oder per Hostprofile bearbeitet? Hast du dir mal die Config vom SW-Initiator angesehen, ob die IQNs der Server auch wirklich unterschiedlich sind?

[Login]

Hab ihr die ESXer geklont oder per Hostprofile bearbeitet?

weder noch!

Hast du dir mal die Config vom SW-Initiator angesehen, ob die IQNs der Server auch wirklich unterschiedlich sind?

jepp:
host1: iqn.1998-01.com.vmware:tk-esx-01-4bc490d6
host2: iqn.1998-01.com.vmware:tk-esx-01-17305ea3

Ich an deiner Stelle würde mal einen LUN/Bus Reset ausprobieren, und zwar von dem Host, der aktuell die VM's hostet.

kannst du mir dabei behilflich sein? Ich bekomme den Befehl nicht durch die vShereCLI durch:

vmkfstools.pl --server=xxx.xxx.xxx.xxx -L unreset /vmfs/devices/disks/naa.600d0230ffffffff06cf8179af752001


auch

vmkfstools.pl --server=xxx.xxx.xxx.xxx /L unreset /vmfs/devices/disks/naa.600d0230ffffffff06cf8179af752001

auch

vmkfstools.pl --server=xxx.xxx.xxx.xxx -lock unreset /vmfs/devices/disks/naa.600d0230ffffffff06cf8179af752001

auch

vmkfstools.pl --server=xxx.xxx.xxx.xxx --lock unreset /vmfs/devices/disks/naa.600d0230ffffffff06cf8179af752001

habe auch das Gefühl, mit dem Befahl was reißen zu können!!

Gruß,
Conne

[Login]

UPDATE:

ich bin grad nochmal zur Klinik zum Monitor und zur CLI gefahren:

# esxcfg-info | egrep -B5 "s Reserved|Pending"

ausgeführt und keine LUN Reserved oder Pending = 1 entdeckt.

Somit wären die Lun Reservierungen ebenfalls ausgeschlossen.

Gruß,
Conne

PS: Gibt es eigentlich nichts besseres als die vSphere CLI wenn man nicht direkt vorm Monitor und der unsupported CLI steht???

[kastlr]

Hallo Conne,

wenn es sich um eine hängen gebliebene SCSI Reservierung handeln würde, hättest du diese mit dem Reboot des Arrays gelöscht, da VMware nur SCSI 2 Reservierungen verwendet.
Und es kann sein, das du diesen Befehl nur direkt auf dem Server ausführen kannst und nicht unter Verwendung von vCLI.

Kannst du denn überhaupt noch auf den Storage zugreifen, vielleicht mal von einem anderem System?

Alternativ kannst du mal mit folgenden Befehlen versuchen, Daten von den Platten zu lesen.
Ich würde das auch wieder direkt auf dem System ausführen.

partedUtil get /vmfs/devices/disks/naa.600d02310006cf81000000005753a7ac
dd if=/vmfs/devices/disk/naa.600d02310006cf81000000005753a7ac of=/tmp/Output_LUN0 bs=512 count=34 conv=notrunc

partedUtil get /vmfs/devices/disks/naa.600d02310006cf810000000079af7520
dd if=/vmfs/devices/disk/naa.600d02310006cf810000000079af7520 of=/tmp/Output_LUN1 bs=512 count=34 conv=notrunc

partedUtil get /vmfs/devices/disks/naa.600d02310006cf810000000179af7520
dd if=/vmfs/devices/disk/naa.600d02310006cf810000000179af7520 of=/tmp/Output_LUN2 bs=512 count=34 conv=notrunc

Gruß,
Ralf

[kastlr]

Hallo Conne,

lies dir mal den folgenden Artikel durch, kann es sein, das jemand mit einem Windows Server auf die LUNs zugegriffen hat?
kein Zugriff mehr auf Storage nach Update

Gruß
Ralf

[Login]

Hallo Ralf,

danke für den Denkanstroß! Der Thread liest sich tatsächlich sehr ähnlich zu meinem Fall.

In dem Netz wird mit SymantecBackupEXEC und einem vAgent auf das vCenter zugegriffen, um die VMs weg zu sichern. Ich bin mir sehr sicher, dass die VMDKs der VMs während der Sicherung an die Backup-VM drangehangen werden. Aber ob da eine Komponente dirtekt auf die LUNs zugreift, kann ich schwer sagen...

Zudem ist der iSCSI-Weg pysikalisch vom LAN getrennt und nutzt andere IP-Netze. Es sei denn, der ESXi stellt während des BAckups einen direkten Weg zur Lun bereit, aber das weiß ich nicht.

Mittlerweile tippe ich doch auch ganz stark auf korupptes Filesystem, zwar komisch, dass es ALLE 3 Luns getroffen hat, aber ok.

Kannst du denn überhaupt noch auf den Storage zugreifen, vielleicht mal von einem anderem System?

Wie gesagt, die Pfade und Luns sind in jedem Fall vorhanden, aber das vmfs kann nicht gelesen/gemounted werden!
Der Gegentest bestand darin, einen der ESXi komplett neu aufzusetzen (neuinstallation mit neuen IP-Adressen, Bezeichnungen, etc.), hier wurde auch erst eine einpfadige Standardkonfig mit MTU1500 ausprobiert. In JEDEM Fall waren die Pfade + Luns für den Host sichtbar, aber kein Datastore darauf

Kann das evtl. wirklich Symantec verbockt haben ? Wenn ja, wie?

Chap ist nicht konfiguriert.

viele Grüße,
Conne

[Login]

!!!!SOLVED!!!!

Nachdem für das System ordentliche Lizenzen incl. Support gekauft wurde und ein Call bei VMware eröffnet wurde, haben wir folgendes herausgefunden:

Das Storage hat aus bisher noch ungeklärten Gründen die naa Nummer der drei LUNs geändert, somit hat der Header der Datastores falsche Einträge hinterlegt gehabt -> Der Datastore war "nicht mehr vorhanden".

Es wurde ein Resignaturing der drei Volumes durchgeführt, danach war wieder alles wie immer!

Warum das Storage das getan hat, ist jetzt für mich das nächste

Die Logs gehen morgen auf jeden Fall direkt zum Storagehersteller.

Hier noch das ssh-Protokoll des Supports:

login as: root
root@10.197.91.240's password:
You have activated Tech Support Mode.
The time and date of this activation have been sent to the system logs.

Tech Support Mode is not supported unless used in consultation
with VMware Tech Support.

VMware offers supported, powerful system administration tools. Please
see www.vmware.com/go/sysadmintools for details.

Tech Support Mode may be disabled by an administrative user.
Disabling requires a reboot of the system. Please consult the ESXi
Configuration Guide for additional important information.

~ # fdisk -lu

Disk /dev/disks/naa.600d0230ffffffff06cf815753a7ac00: 1198.9 GB, 1198925021184 bytes
255 heads, 63 sectors/track, 145760 cylinders, total 2341650432 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/disks/naa.600d0230ffffffff06cf815753a7ac00p1 128 2341634399 1170817136 fb VMFS

Disk /dev/disks/naa.600d0230ffffffff06cf8179af752000: 1499.8 GB, 1499897790464 bytes
255 heads, 63 sectors/track, 182352 cylinders, total 2929487872 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/disks/naa.600d0230ffffffff06cf8179af752000p1 128 2929484879 1464742376 fb VMFS

Disk /dev/disks/naa.600d0230ffffffff06cf8179af752001: 1499.8 GB, 1499896741888 bytes
255 heads, 63 sectors/track, 182352 cylinders, total 2929485824 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/disks/naa.600d0230ffffffff06cf8179af752001p1 128 2929484879 1464742376 fb VMFS

Disk /dev/disks/naa.6001517555bf40000f850ff81aa99b73: 437.9 GB, 437998583808 bytes
64 heads, 32 sectors/track, 417708 cylinders, total 855465984 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/disks/naa.6001517555bf40000f850ff81aa99b73p1 8192 1843199 917504 5 Extended
/dev/disks/naa.6001517555bf40000f850ff81aa99b73p2 1843200 10229759 4193280 6 FAT16
/dev/disks/naa.6001517555bf40000f850ff81aa99b73p3 10229760 855465983 422618112 fb VMFS
/dev/disks/naa.6001517555bf40000f850ff81aa99b73p4 * 32 8191 4080 4 FAT16 <32M
/dev/disks/naa.6001517555bf40000f850ff81aa99b73p5 8224 520191 255984 6 FAT16
/dev/disks/naa.6001517555bf40000f850ff81aa99b73p6 520224 1032191 255984 6 FAT16
/dev/disks/naa.6001517555bf40000f850ff81aa99b73p7 1032224 1257471 112624 fc VMKcore
/dev/disks/naa.6001517555bf40000f850ff81aa99b73p8 1257504 1843199 292848 6 FAT16

Partition table entries are not in disk order
~ # esxcfg-mpath -b
naa.600d0230ffffffff06cf8179af752000 : IFT iSCSI Disk (naa.600d0230ffffffff06cf8179af752000)
vmhba38:C1:T1:L1 LUN:1 state:active iscsi Adapter: iqn.1998-01.com.vmware:tk-esx-01-4bc490d6 Target: IQN=iqn.2002-10.com.infortrend:raid.sn7817089.101 Alias= Session=00023d000001 PortalTag=1
vmhba38:C0:T0:L1 LUN:1 state:active iscsi Adapter: iqn.1998-01.com.vmware:tk-esx-01-4bc490d6 Target: IQN=iqn.2002-10.com.infortrend:raid.sn7817089.001 Alias= Session=00023d000001 PortalTag=1

naa.600d0230ffffffff06cf8179af752001 : IFT iSCSI Disk (naa.600d0230ffffffff06cf8179af752001)
vmhba38:C1:T1:L2 LUN:2 state:active iscsi Adapter: iqn.1998-01.com.vmware:tk-esx-01-4bc490d6 Target: IQN=iqn.2002-10.com.infortrend:raid.sn7817089.101 Alias= Session=00023d000001 PortalTag=1
vmhba38:C0:T0:L2 LUN:2 state:active iscsi Adapter: iqn.1998-01.com.vmware:tk-esx-01-4bc490d6 Target: IQN=iqn.2002-10.com.infortrend:raid.sn7817089.001 Alias= Session=00023d000001 PortalTag=1

t10.TANDBERGTS400___________400080501351 : Local TANDBERG Tape (t10.TANDBERGTS400___________400080501351)
vmhba2:C0:T2:L0 LUN:0 state:active Local HBA vmhba2 channel 0 target 2

naa.600d0230ffffffff06cf815753a7ac00 : IFT iSCSI Disk (naa.600d0230ffffffff06cf815753a7ac00)
vmhba38:C1:T1:L0 LUN:0 state:active iscsi Adapter: iqn.1998-01.com.vmware:tk-esx-01-4bc490d6 Target: IQN=iqn.2002-10.com.infortrend:raid.sn7817089.101 Alias= Session=00023d000001 PortalTag=1
vmhba38:C0:T0:L0 LUN:0 state:active iscsi Adapter: iqn.1998-01.com.vmware:tk-esx-01-4bc490d6 Target: IQN=iqn.2002-10.com.infortrend:raid.sn7817089.001 Alias= Session=00023d000001 PortalTag=1

mpx.vmhba0:C0:T0:L0 : Local TEAC CD-ROM (mpx.vmhba0:C0:T0:L0)
vmhba0:C0:T0:L0 LUN:0 state:active Local HBA vmhba0 channel 0 target 0

naa.6001517555bf40000f850ff81aa99b73 : Local INTEL Disk (naa.6001517555bf40000f850ff81aa99b73)
vmhba3:C0:T0:L0 LUN:0 state:active Local HBA vmhba3 channel 0 target 0

~ # esxcfg-volume -l
VMFS3 UUID/label: 4bc08e5c-33ca5d00-3753-00151764442c/iSCSI_SAS
Can mount: Yes
Can resignature: Yes
Extent name: naa.600d0230ffffffff06cf815753a7ac00:1 range: 0 - 1143295 (MB)

VMFS3 UUID/label: 4be2c037-d74b3f58-37c2-001517643738/iSCSI_Sata_01
Can mount: Yes
Can resignature: Yes
Extent name: naa.600d0230ffffffff06cf8179af752000:1 range: 0 - 1430271 (MB)

VMFS3 UUID/label: 4bf52654-046a3600-a165-00151764442c/iSCSI_Sata_02
Can mount: Yes
Can resignature: Yes
Extent name: naa.600d0230ffffffff06cf8179af752001:1 range: 0 - 1430271 (MB)

~ # esxcfg-volume
esxcfg-volume <options>
-l|--list List all volumes which have been
detected as snapshots/replicas.
-m|--mount <VMFS UUID|label> Mount a snapshot/replica volume, if
its original copy is not online.
-u|--umount <VMFS UUID|label> Umount a snapshot/replica volume.
-r|--resignature <VMFS UUID|label> Resignature a snapshot/replica volume.
-M|--persistent-mount <VMFS UUID|label> Mount a snapshot/replica volume
persistently, if its original copy is
not online.
-h|--help Show this message.
~ # esxcfg-volume -r iSCSI_Sata_02
Resignaturing volume iSCSI_Sata_02
~ # esxcfg-volume -r iSCSI_Sata_01
Resignaturing volume iSCSI_Sata_01
~ # esxcfg-volume -r iSCSI_SAS
Resignaturing volume iSCSI_SAS

Wie man die SSH-Console auf einem ESXi freischaltet weiß ich jetzt auch

Allen, die sich hier am Thread und dessen Lösung beteiligt haben -> Vielen Dank!

Gruß,
Conne

[bla!zilla]

Daumem hoch, dass du deine Lösung hier postest! Aber das is ja schon ein wenig strange... Das Storage ändert die NAA ID? Spricht jetzt nicht gerade für Infortrend. Kannst du bitte die Ergebnisse des Calls bei Infortrend hier posten? Das ist sicherlich für alle interessant.

[Login]

Aussage vom Storagehersteller: Die UUIDs haben sich nach dem Firmwareupdate des Storages am Freitagabend geändert. Der VMwareSupport hat diese Situation durch ein resignaturing beheben können. Di haben also das Folgeproblem gelöst

Was aber vorher passiert ist, konnte IFT nicht bestimmen.

Obwohl es mich natürlich brennend interessiert, sehe ich von einem weitern VMware Call und einer Log-Auswertung ab.

Der Kunde hat heute das 2. Storage bestellt, somit ist die Sache für mich erstmal erledigt.

Viele Grüße,
Conne

[bla!zilla]

Woah... beim Firmwareupdate UUIDs ändern? Ist das Verhalten dokumentiert und reproduzierbar? Wenn ja, dann hat sich Infortrend gerade in meinen Augen disqualifiziert.