Wie kann ich eine Partition als Datenspeicher einbinden?

[HaPeKa]

Guten Abend allerseits,

heute ist mir ein unverzeihlicher Anfängerfehler passiert.

Ich betreibe einen ESXi Server auf einem HP ProLiant DL380p und habe dort 5 virtuelle Maschinen am laufen. Letzte Woche ist mir eine Disk ausgestiegen, die heute ersetzt wurde.

Nach dem Einsetzten der Disks habe ich diese vor dem Booten von ESXi auf dem Server konfiguriert und dann den Server gestartet. Zu meiner Überraschung hat der Server versucht, von der CD zu booten, keine der Disks wurde erkannt.

Dann ist mir die fatale Idee gekommen, ich könnte ja nochmal von der CD ESXi installieren, das würde den Bootsektor wohl wiederherstellen.
Jetzt weiss ich, es hätte gereicht, in der Konfig die erste der Disks als Bootdisk zu konfigurieren, diese Einstellung ist aus unersichtlichen Gründen verloren gegangen. Am Controller war 'none' als Bootdisk definiert.

Die Experten werden jetzt schmunzeln und wissen, was passiert ist. ESXi hat die bestehende Installation erkannt, aber die Partition, auf der die 5 virtuellen Maschinen drauf sind, nicht als DataStore gemountet. Wenn ich diese über's GUI ins System einbinden will, kann ich das nicht, weil sie nicht leer ist.

Gibt es eine Möglichkeit, z.B. mit den vmkfstools eine nicht leere Partition als Datenspeicher einzubinden?
Ich möchte die Partition 3 (siehe ScreenShot 'New DataStore') als 'Bay1 SSD DataStore' wieder im System sehen.

Gibt es sonst Möglichkeiten, die Partition auszulesen? Die Partition 3 ist da und sichtbar (siehe ScreenShot 'Partitions').

Und ja, ich habe einen ESXi Backup, der ca. 10 Tage alt ist, aber falls es eine einfachere Möglichkeit gibt, die Daten wiederherzustellen, werde ich diese bevorzugen

Danke für die hilfreichen Tipps ...

[~thc]

Wenn ich das richtig verstanden habe, hast du mehrere einfache lokale Platten im Einsatz. Eine davon war defekt und wurde ersetzt.

- Wie viele Platten und auf welcher war ESXi selbst installiert? Was befindet sich auf den anderen?

- Was meinst du mit "habe ich diese vor dem Booten von ESXi auf dem Server konfiguriert"?

Dann ist mir die fatale Idee gekommen, ich könnte ja nochmal von der CD ESXi installieren, das würde den Bootsektor wohl wiederherstellen. Jetzt weiss ich, es hätte gereicht, in der Konfig die erste der Disks als Bootdisk zu konfigurieren

- Auf welche der Disks wurde denn ESXi neu installiert?

[HaPeKa]

Ich habe 4 Platten drin:

Bay1: 1TB SSD: ESXi und die virtuellen Maschinen
Bay6: 5TB HDD: ESXi DataStore
Bay7: 5TB HDD: per RDM dediziert an eine VM
Bay8: 5TB HDD: per RDM dediziert an eine VM

Die Disk in Bay6 ist letzte Woche ausgefallen und auf Garantie ersetzt worden.
Das Problem nach dem Ersetzen der Disk war, dass der Diskcontroller die primary Bootdisk von 'Logical Volume 1' auf 'none' gesetzt hatte.
Das habe ich leider nicht realisiert. Es hätte genügt, dort wieder 'Logical Volume 1' zu aktivieren, und alles wäre okay gewesen.
So konnte der Server nicht von der Disk booten und hat versucht, von der CD zu starten.

Anyway, habe gestern kurz vor Mitternacht den Restore gestartet, sollte in ca. 3h alles wieder i.O. sein.

[~thc]

Okay, dann nur der Vollständigkeit halber:

Du hast dann ESXi über die Bay1 Platte drüber installiert? Dann muss der Installer dich doch fragen, was er mit dem Datastore (den er findet) machen soll...

[Dayworker]

Bay1: 1TB SSD: ESXi und die virtuellen Maschinen
Bay6: 5TB HDD: ESXi DataStore

Wenn der ESXi in Bay1 installiert war, stört das den ESXi in keinster Weise. Lediglich alle vorher in Bay6 gespeicherten VM sind dann halt weg bzw werden als "Karteileichen" im Inventory geführt.
Hattest du die Bay6 auch als Speicherort für die Scratchpartition gesetzt, sorgt das natürlich für Probleme und der ESXi bemängelt sowas dann auch im vmkernel.log.

Mir ist absolut unklar, weshalb du die ausgetauschte Disk vor dem ESXi-Start konfiguriert hast. Ich kenne von meinem Dell-Server nur eine "Pre-Boot-Option" (genauer Name entfallen), damit der Server einfacher mit einem neuen OS installiert werden kann und das ist bei dir ja überhaupt nicht notwendig. Der ESXi erkennt eine leere Disk und bietet dann an, darauf einen neuen Datastore einzurichten. Wenn der ESXi bei dir im UEFI-Modus installiert wurde, hat deine unnötige Konfiguration vor ESXi-Start wahrscheinlich die neue Platte als Boot-Laufwerk eingerichtet. Mit etwas Glück ist deine alte Config wieder startbar, wenn du Bay6 herausziehst und wieder jungfräulich machst. Den ersten MB mit Nullen zu überschreiben, dürfte reichen.

[HaPeKa]

Du hast recht, Dayworker, ich hätte wohl erst einmal starten und schauen sollen, ob alles wieder hochkommt.
Der Server hat den Drive in Bay 6 als 'failed' gemeldet und ich habe mir angewöhnt, neue Disks über die ACU erst mal zu konfigurieren.
Was ich nicht gemerkt habe: Aus einem mir unerklärlichen Grund wurden am P420i Smart Array Controller sowohl das Primary wie auch das Secundary Boot Volume auf 'none' gesetzt. Wie bereits erwähnt, hätte es genügt, dort 'Logical Drive 1' zu wählen und alles wäre i.O. gewesen.

Wieder was gelernt - auf die harte oder zumindest aufwändige Tour

[Dayworker]

Verzeih mir, aber ich verstehe immer noch nicht, was man nach einem Plattentausch konfigurieren muß. Ich nehme hier einfach den monierten Datenträger raus, pack den neuen rein und fahre dann wieder hoch. Mehr als die Platten im UEFI/Bios anmelden und unkonfiguriert lassen, sollte doch das ACU hinbekommen.

Da du drei 5TB-Platten hast, schon mal über ein Raid5 nachgedacht?

[HaPeKa]

Das ist auf jedenfall eine Überlegung wert, insbesondere wegen der Ausfallsicherheit.
Mit den dreien hätte ich einen 10TB grossen Datastore.
Müsste mal schauen, wie sich das auf die Performance auswirkt.
Habe bisher nur den Geschwindigkeitsunterschied zwischen 5TB als Datastore und 5TB per RDM eingebunden verglichen, da ist die RDM wesentlich schneller. Raid 5 hat aber wegen dem parallelen Schreiben und Lesen einen Geschwindigkeitsvorteil, ob der die Differenz ausgleichen kann, wäre zu testen ...
Auf den beiden per RDM eingebundenen Disks werden nur Backups mit mehreren Generationen gemacht.

[HaPeKa]

Da du drei 5TB-Platten hast, schon mal über ein Raid5 nachgedacht?

Nochmals vielen Dank für den Tipp.

Habe mich etwas in die Thematik eingelesen und mich entschieden, ein Raid5 mit 5 Platten zu nutzen.
Von der Schreibperformance her sind ja Raid5 mit 3, 5 oder 9 Platten sinnvoll.

Habe jetzt noch 2 5TB Platten bestellt und werde ein Raid 5 mit 20TB nutzbarem Speicher einrichten.
So bin ich safe und habe noch genügend Reserven für die nächsten paar Jahre

Der Defekt der Platte hat mich gelehrt, der Datensicherheit höhere Priorität zuzuweisen als der Performance.
Habe durch den Defekt zum Glück keine Daten verloren, aber einiges an Zeit aufwenden müssen, um den vorherigen Zustand wieder herzustellen ...

[Dayworker]

Bei 20TB würde ich eher über ein Raid6 nachdenken, um im Fehlerfall mehr Zeit zu haben...
Denn wenn du jetzt 20TB einrichtest, wirst du damit bestimmt fast zeitgleich bereits ~10TB in Belegung haben und die müssen auch irgendwohin gesichert werden. Das geht auch nur noch auf ein anderes Datenträgersystem und bei den Volume-Grössen würde ich im Fehlerfall auch kein Raid-Rebuild mehr anschieben. Den damit verursachten Dauerstreß von, je nach Controller und Raidbelegung, mehreren Tagen würde ich den Platten nicht mehr antun. Stirbt beim Rebuild eine weitere Platte, ist das ganze Raid verloren. Das Raid müßte bei mir daher nur solange halten, um die bestehenden Daten runter zu kopieren. Nach dem Laufwerkstausch würde ich dann das Raid direkt neu aufsetzen und die Daten wieder draufschieben. Das dürfte im Endeffekt sicherer (aktuellstes Backup ist dann ja vorhanden) und vermutlich auch schneller sein, als wenn der Controller für die vorhandenen Daten reihum alle Raidmembers abklappert, fehlende Teile aus den Paritätsdaten ermittelt und schließlich wegschreibt.

[HaPeKa]

Danke für den Hinweis. Bin gerade daran, meine Datenspeicherung und die Backupstrategie neu zu überdenken.

Bei mir fallen sehr viele Fotodaten an, die ich sichern und archivieren will. Für eine TimeLapse Aufnahme können gut und gerne mal 40-60GB Originalaufnahmen anfallen, die ich nach dem Erstellen des Videos archivieren möchte.

Bisher habe ich die Daten zu Hause auf einer Synology 218+ mit 2 Platten gesichert (1x4TB und 1x10TB). Diese habe ich jede Nacht auf einen Fileserver auf dem hp Server, der im Geschäft stand, gesichert. Über die Weihnachtstage kommt der Server nun nach Hause in ein kleines Rack im Keller. Das heisst, er ist dann nicht mehr remote, sondern ebenfalls lokal, wenn auch räumlich getrennt. Er wird dann, wie die Synology über eine 1GB Ethernet Schnittstelle verbunden sein, die wohl der Engpass sein wird.

Bei diesem Setup kann ich also mit RAID5 gut leben, die Daten sind ja auch auf der Synology gespeichert. Bei einem Ausfall einer Platte im RAID5 Verbund muss ich nicht zwingend einen Rebuild fahren, sondern kann, wie von dir erwähnt, das RAID5 neu aufbauen und die Daten von der Synology wieder zurückspielen ...

By the way, im Server hätte ich auch eine PCI-Karte mit 2x10GB Ethernet (RJ45), aber mir graust vor der Umstellung des ganzen Heimnetzes auf 10GB. Ich bräuchte mindestens 3 10GB fähige Switches, zwei PCI Karten für die beiden PCs eine neue Synology und möglicherweise auch eine neue Verkabelung ... Also es gibt noch Verbesserungspotenzial, aber das wird im ersten Schritt noch nicht ausgeschöpft ...

[Dayworker]

Wieso 3 Switches? Zuhause würde ich mir diese Redundanz sparen.
Mit GE sind netto 117MByte/s drin, folglich kannst du 50GByte in ~7:20min kopieren und GE wirst du vorher wahrscheinlich auch nicht als Upstream gehabt haben. Ich würde da erstmal Messungen an deinem realen Datenbestand vornehmen. Mit vielen kleinen Dateien bringt dir 10GE auch nix und wenn du mit grossen Dateien die angedachten 10GE ausnutzen willst, muß du die Daten auch erstmal in der benötigten Geschwindigkeit sowohl lesen als auch wegschreiben können und bei letzterem könnte das Raid5/6 zum begrenzenden Faktor werden. In dem Fall wäre dann ein Raid10 bei grösseren Plattenverschnitt schneller. Wechselst du die HDDs gegen SSDs, kommst du auch nicht günstiger weg. Consumer-SSDs eignen sich aufgrund ihrer stark schwankenden Latenzen für kein Raid. Ist die SSD mit internen Optimierungen (GC etc) beschäftigt und antwortet nicht rechtzeitig, wirft der Raid-Controller diesen Member häufig raus und meldet das Raid als degraded...

[HaPeKa]

Du hast recht, erst mal nach der Umstellung alles testen und schauen, wie das Ganze läuft.
Und den Haupttraffic generieren die Backups in der Nacht, wenn es nicht so auf den Speed ankommt.
Bin mir ziemlich sicher, dass das Netzwerk nicht der grosse Engpass sein wird.

3 Switches nicht aus Redundanzgründen, sondern wegen der Topologie.
Einen bräuchte ich im Keller beim VMware Server, einen im Büro bei der NAS und einen, um Keller und Büro zu verbinden. Eine direkte Leitung ist aufgrund der Leerrohre nicht möglich. Immerhin würden Switches mit 2 x 10GBE genügen, da gibt es ja schon erschwingliche ...

[HaPeKa]

Ich hab mein Problem wieder. Hatte den Server eine Nacht vom Strom und die Konfig war weg, keine Logical Drives mehr, musste im ACU die Drives wieder definieren. Wahrscheinlich ist der Akku hin und kann die Config ohne Strom nicht mehr halten.

Anyway, nach der Neukonfiguration habe ich wieder meine Logical Drives und ESXi bootet, aber im ESXi gibt es keine Datenspeicher mehr.
Sieht dann unschön aus:

Wenn ich dann versuche, den auf der Disk bestehenden Datenspeicher wieder einzubinden, geht das zumindest in der GUI nicht mehr, ich bekomme immer die folgende Meldung:

Mach ich was falsch oder verstehe ich was nicht? Wie kann ich den Datenspeicher wieder einbinden? Scheint ja alles noch da zu sein ...

Wenn's über das GUI nicht geht, gibt es eine Möglichkeit, den Datenspeicher per SSH mit entsprechenden Befehlen einzubinden?

Wäre über Tipps sehr dankbar ...

[Dayworker]

Das kann ja kein Dauerzustand sein, irgendetwas an deiner HW ist oberfaul. Du schreibst leider nichts zur genauen HW, ob diese überhaupt vom 6.7er noch unterstützt wird. Der DL380 umfaßt mehr als eine Generation.

Häng doch bitte trotzdem mal das "vmkernel.log" an, vielleicht erhellt das etwas.

[HaPeKa]

Ich denke, das Hauptproblem sitzt vor dem Bildschirm und ist zu experimentierfreudig

Also, ich hatte bisher einen hp Microserver Gen9 hier im Einsatz, aus einem Projekt jedoch einige DL360p Gen8 übernehmen können.
Zudem habe ich eine vSphere Lizenz für 6 Prozessoren.

Mein Ziel wäre, den etwas lahmen Microserverdurch die DL360p zu ersetzen, die haben 32GB Memory, Dual Xeon Prozessoren und zusätzlich noch einen hp 10GB Eth NIC.

Mir ist bewusst, dass Gen8 offiziell nicht mehr supportet wird, aber für ein privates Projekt zu Hause ist das für mich vertretbar.
Läuft ja auch alles ganz gut, solange ich nicht auf komische Ideen komme, wie z.B. heute.

Momentan habe ich hier 2 DL360p auf dem Tisch, beide in Bay 1 eine 1TB SSD, und einer mit 5 x 5TB als Raid5 Volume.
Nun habe ich mal alles bestens eingerichtet, lief auch alles tip top und bevor ich 'in Produktion' gehe, wollte ich noch ein paar Szenarien durchgehen.
Das Spiegeln der beiden 1TB Disks hat Angfang Woche geklappt, beide liefen absolut problemlos.

Heute wollte ich mal den Ernstfall durchspielen: Bay 1 auf der produktiven Maschine geht down. Also alle 5 Platten raus und in den Standby Server rein.
Überraschung: Der kannte keine Volumen mehr, selbst Volume1, von dem er Anfang Woche gestartet hat, war weg und ich musste im ACU die Volumes erstellen. Meine Vermutung: Da er jetzt einige Zeit nicht am Strom war, könnte der Akku leer sein, so dass die Konfig nicht dauerhaft gespeichert wird.
Deine Vermutung, Dayworker, dass da eine Inkompatibilität reinspielt, ist sicher auch berechtigt, es kann durchaus sein, dass meine Konfig solche 'Tests' einfach nicht verträgt.

Ich kann natürlich wieder alles aufsetzen, aber ich wüsste eben schon gerne, ob es einen Weg gibt, den ja noch vorhandenen und nicht überschriebenen Datastore wieder einzubinden. Dieses Wissen gehört ja auch ein ein Notfallkästchen

Also wie geschrieben, ich bin mir bewusst, dass ich da was verbockt habe, weiss aber nicht, wie schlimm es ist.
Jetzt, in der Testphase, ist das zu verkraften, aber wenn ich mal alle VMs drauf und produktiv am Laufen habe, werde ich solche Experimente natürlich lassen und allfällige HW Ausfälle durch aktuelle Backups auffangen. Habe ja auch noch eine Serverlizenz für Acronis, aber die habe ich noch nicht installiert. Das ist dann der nächste Schritt ...

P.S. Logs liefere ich nach, muss mich erst einlesen, wo die zu finden sind

[Dayworker]

Ich komme nicht mehr mit. Im Eröffnungsposting ist die Rede von DL380p und jetzt kommst du mit 360ern ums Eck. Exerziere doch erstmal ein Szenario mit einem Gerät durch.
Mir ist auch nicht klar, was du mit einer Dual-Xeon-Maschine willst, wenn die nur 32GB RAM hat. Ausgehend von der HPE-Werbung für die DL360G9 unterstützen die bis zu 3TB RAM und vertragen CPUs zwischen 4 und 22 Kernen. Auch wenn Desktop-Rechner im Leerlauf größtenteils unter 20W liegen, gilt das keinesfalls für richtige Server. Allein deren KVM-Lösung für den Remote-Zugriff schluckt bereits diese 20W und dafür muß der Server noch nicht mal laufen. Unter 50W im Leerlauf wirst du die sicherlich nicht betreiben können. Bist du dir dieses Umstandes bewußt?
Ich hätte hier auch noch einen DL380G2 (2U) bei Abholung kostenlos abzugeben, den ich vorrangig aus Lautstärke- und Energiegründen nicht mehr einsetze....

Unter Linux mit einem SW-Raid könnte dein 5-Platten-Tausch klappen, weil der Superblock meines Wissen reihum gespeichert wird. Hängt man sie in genau der gleichen Reihenfolge wieder ein, sollte das Raid entweder wieder hochkommen oder sich von Hand wieder einbinden lassen. Ich weiß aber nicht, was ein HW-Controller zum Raid speichert noch wo überall dazu etwas gespeichert wird. Meine Vermutung wäre, daß das Raid-Level sowohl auf Platten als auch Controller gespeichert wird. Bei den besseren Herstellern dürfte diesem auch ein vollständiger Controllerdefekt geläufig sein, so daß man in meiner Naivität davon ausgehen könnte, daß dieser Wege zur Raidübernahme anbietet. Das handhabt aber jeder Hersteller sicherlich wieder anders, notfalls muß man das Backup einspielen oder halt Controller samt Platten umhängen.
Das was dir jetzt in den Sinn kommt, läuft SW-mäßig bei VMware unter HA und ist in jedem Fall kostenpflichtig. Deutlich kostengünstiger dürfte dich dann https://napp-it.org/cluster.html kommen.


Wenn ich das noch richtig in Erinnerung habe, war Bay1 doch dein ESXi plus Datastore. Was hältst du denn davon, in Bay2 noch eine 1TB SSD zu stecken und dann zumindest ein Raid1 für ESXi plus ersten DS zu haben. Mit etwas Glück läuft das Raid auch mit Consumer-SSDs ausreichend stabil und das leidige Thema Plattentauschen zwischen verschiedenen Geräten hört damit auf.

[HaPeKa]

Ups, sorry, das im Eingangspost war ein Fehler, es sind DL360p Gen8 ...

Wahrscheinlich hast du recht, statt einen als Standby zu halten, wär's wohl vernünftiger, Bay1 und Bay2 als Raid1 zu betreiben und dann die Bays 4-8 als Raid5 ... so habe ich bei beiden DataStores die Ausfallsicherheit. Werd mir das mal in Ruhe überlegen. Das mit dem Hin- und Herswappen von Disks scheint recht gefährlich zu sein ... Bei der einzelnen Disk in Bay1 klappte es mit der Spiegelung problemlos, aber mit einem Raid scheint das nicht mehr zu gehen.

Habe mal das vmkernel.log rauskopiert. Komisch, dass alle Daten auf 2015-09-11 sind, also doch keinen Akku, der die Zeit und Config hält?

Well, ich habe mit einer Fehlmanipulation die Konfig verschossen.

Bleibt die Ausgangsfrage: Kann ich die Partition einer physischen Platte irgendwie als Datastore einbinden?

[Dayworker]

Die HP-Server geben meines Wissens eine Warnmeldung aus, wenn die CMOS-Battery fertig hat. Dazu müßte dann aber zumindest eine HP-Custom-ISO installiert worden sein.

Was ist auf der Platte drauf? Der ESXi kennt nur VMFS. Du könntest die Platte per RDM einbinden. SAS geht per HTML5-GUI, SATA nur per SSH bzw CLI am ESXi selber.


[add]
Hast du im BIOS/UEFI selber mal die Uhrzeit gestellt?
Nicht das lediglich das falsch eingestellt ist... Weil ab Zeile 3876 steht:

Code: Alles auswählen

2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13064: ============= Dumping HPSA SCSI DEV List  ===============
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13087:   0: C0:T0:L1(T0)  LUN Addr=0000004000000000, Device ID=600508b1001c795071a6b227220a6b80, WWID=0000000000000000, SCSIDev=0x4308fef11ce8 internal
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13101:      Raid Level=0x0(RAID 0), Lun State=0x0, Type=0x0(Direct-Access    ), Phy Dev Type=0x0(N/A), Queue Depth=0x0, IOAccelHandle=0x0
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13087:   1: C0:T0:L2(T0)  LUN Addr=0100004000000000, Device ID=600508b1001c539fd0e499eb19fd1cb9, WWID=0000000000000000, SCSIDev=0x4308fef11d78 internal
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13101:      Raid Level=0x3(RAID 5 or 50), Lun State=0x0, Type=0x0(Direct-Access    ), Phy Dev Type=0x0(N/A), Queue Depth=0x0, IOAccelHandle=0x0
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13064: ============= Dumping Offline Volume list  ===============
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13064: ============= Dumping Masked Device List  ===============
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13087:   0: C0:T0:L0(T0)  LUN Addr=000000c000000001, Device ID=5002538e409e711f0000000000000000, WWID=3001438022dcd700, SCSIDev=0x4308fef70510
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13101:      Raid Level=0x8(Physical Drive), Lun State=0x0, Type=0x0(Direct-Access    ), Phy Dev Type=0x1(SATA device), Queue Depth=0xe, IOAccelHandle=0x110000
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13087:   1: C0:T0:L0(T0)  LUN Addr=000000c000000301, Device ID=5000c500bd9034d40000000000000000, WWID=3001438022dcd703, SCSIDev=0x4308fef705a0
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13101:      Raid Level=0x8(Physical Drive), Lun State=0x0, Type=0x0(Direct-Access    ), Phy Dev Type=0x1(SATA device), Queue Depth=0xe, IOAccelHandle=0x1120001
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13087:   2: C0:T0:L0(T0)  LUN Addr=000000c000000401, Device ID=5000c500a9b901300000000000000000, WWID=3001438022dcd704, SCSIDev=0x4308fef70630
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13101:      Raid Level=0x8(Physical Drive), Lun State=0x0, Type=0x0(Direct-Access    ), Phy Dev Type=0x1(SATA device), Queue Depth=0xe, IOAccelHandle=0x2130002
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13087:   3: C0:T0:L0(T0)  LUN Addr=000000c000000501, Device ID=5000c500ba91af710000000000000000, WWID=3001438022dcd705, SCSIDev=0x4308fef706c0
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13101:      Raid Level=0x8(Physical Drive), Lun State=0x0, Type=0x0(Direct-Access    ), Phy Dev Type=0x1(SATA device), Queue Depth=0xe, IOAccelHandle=0x3140003
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13087:   4: C0:T0:L0(T0)  LUN Addr=000000c000000601, Device ID=5000c500bdaad96b0000000000000000, WWID=3001438022dcd706, SCSIDev=0x4308fef70750
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13101:      Raid Level=0x8(Physical Drive), Lun State=0x0, Type=0x0(Direct-Access    ), Phy Dev Type=0x1(SATA device), Queue Depth=0xe, IOAccelHandle=0x5160005
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13087:   5: C0:T0:L0(T0)  LUN Addr=000000c000000701, Device ID=5000c500a90f09d90000000000000000, WWID=3001438022dcd707, SCSIDev=0x4308fef707e0
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDevList:13101:      Raid Level=0x8(Physical Drive), Lun State=0x0, Type=0x0(Direct-Access    ), Phy Dev Type=0x1(SATA device), Queue Depth=0xe, IOAccelHandle=0x4150004
2015-09-12T10:46:50.110Z cpu22:2097684)nhpsa: hpsa_DumpSCSIDev:13155: =================== Dump completed =======================

...und das könnte bei dir ja fast zutreffen.