Rescan LUN´s

[mullfreak]

Hi,
wir erweitern unser SAN (HP MSA2012i). Bei der Anschaffung und Erstkonfiguration haben wir die VMware LUN´s für alle Hosts freigegeben. Da wir jetzt auch unsere CIFS-Daten auf den Filer bringen ist es eher unvorteilhaft, dass in einem Windows-Server auch die VMFS-Partitionen angezeigt werden.
Deshalb wird jetzt das LUN-Mapping umgestaltet, dass auch jede Maschine das sieht, was sie soll (darf)!

Folgende Vorgehensweise ist angedacht:
1. Herunterfahren der VM´s
2. Unmapping der Zuweisung an "All Hosts"
3. Neues Mapping an die richtigen VMware-ESX-Hosts
4. Rescan der LUN´s
5. Einschalten der VM´s

Gibt es irgendwas spezielles zu beachten, besonders bei Punkt 4??? Werden die VMFS-Partitionen einwandfrei wiedererkannt???

Gruß und danke für Eure Hilfe.

Mull

[Saturnous]

Solange die LUN Nummer gleich bleibt und die Daten sich nicht ändern null problemo, man beachte aber das wenn ein Windows die LUN signiert hat dann rennt der ESX trotzdem bis zum nächsten Rescan munter weiter. Soll heissen JETZT schon mal mit fdisk -lu einen Blick auf die LUNs werfen ggf reparieren (in der VMWare community nach Saxnot suchen).

Man kann die Snapshot awarnes ausschalten (disallowsnapshotlun = 0) und sogar den Check nach der LUN Nummer unterdrücken (hab das @work irgendwo noch liegen wie der parameter sich nennt) - aber eigentlich kann man in der MSA2ki doch die LUN Nummer einstellen.

[mullfreak]

Hi,

danke für den äußerst hilfreichen Beitrag.

Kann das jetzt heißen, dass die LUN´s durchs konnektieren von Windows her, defekt sind??? Das wäre ja gruslig!!!

Die LUN-Numbers lassen sich in der MSA einstellen, das stimmt.

Mull

[Saturnous]

Ja (unzählig gesehen und korrigiert) .. ausser du bist bedacht vorgegangen und hast vor dem ersten zeigen auf windows diskpart <enter> automount disable <enter> ausgeführt oder es waren schon immer Enterprise Varianten von Windows. Aber auch da kann jeder Popuplegasteniker aus einer Zeigefingerspastik heraus den Vorschlag "Darf ich die Datenträger signieren" bestätigen.

esxcfg-vmhbadevs zeigt die LUNs an, schreib die die /dev/sdX namen der VMFS LUNs raus, und prüf mit fdisk -lu ob auf diesen Laufwerken noch eine partition mit typ "fb" liegt.

Wenn nicht musst du das neubauen - keine panik hat bis jetzt immer gefunzt. Check mal FW Version der MSA ab J210P19 (mist oder wars R19) sollte mindestens drauf sein.

Was clevere Strategie ist um das letzte aus iSCSI rauszuquetschen siehe mein post :

http://vmware-forum.de/viewtopic.php?t=17830

[mullfreak]

Es ist folgendermaßen:
Die beiden LUN´s mit den VM´s wurden in Windows nie berührt. Lediglich in der Datenträgerverwaltung werden die beiden angezeigt. Signiert wurde nichts!

Wie führe ich am Windows Server fdisk -lu aus. Es gibt doch nur noch diskpart???

Wie kann ich was neubauen? Die letzte FW ist an der MSA2012i eingespielt. Ist die J210P19-02.

Gruß
Mull

[Saturnous]

fdisk -lu (wie auch esxcfg-vmhbadevs) sollst du auf den ESX hosts ausführen, hättest du nach dem glorreichen Gott der Sachsen und ESX gegoogelt hättest du das hier gefunden :

http://spininfo.homelinux.com/news/ESX_ ... ysis_tips_

und es wär dir klar

Wodoch ich sauer bin das dieser Crawler zwar den gut bewerteten Communitybeitrag spiegelt aber den Erstellernamen (Saturnous) weglässt .

automount signiert spontan auch ohne nachzufragen, mögliche Trigger sind dann einstecken eines USB Sticks - rescan in der Datenträgerverwaltung etc. Prüf lieber mal nach bevor du es erst beim Rescan merkst.

Übrigens die MSA legt noch etwas zu wenn du unter Advanced -> Net -> TcpHeapSize und TcpHeapMax die Maximalwerte eintragen.

[mullfreak]

So, danke für die Hinweise. Auch für die Performance-Steigerung bei der MSA. Werds gleich mal probieren wenn nächstes WE sowieso die Maschinen off sind!!!

[kastlr]

Hallo,

eine LUN wird unter Windows nicht automatisch initialisiert, das erfordert immer eine User Aktivität.
Solange also niemand den Diskadministrator (oder diskpart) zum Initiialisieren verwendet, besteht keine Gefahr.
Das mit dem Automount disablen kannst du dir sparen, da Windows ohnehin nur ihm bekannte Filesysteme mounten kann, und das sind eben nur NTFS und FAT.

Allerdings ist eine Einstellung wie "All Hosts" im Mixbetrieb schon grob fahrlässig, schließlich sieht dann jeder Host alle Platten.
Und dann wird eine vermeintlich freie LUN mal auf die Schnelle geschreddert.

Mit HP MSA2012i habe ich leider keinerlei Erfahrung, aber sofern es NAA unterstützt, sind die LUN Nummern eventuell unerheblich.
Allerdings nur in dem Fall, das dieses Feature schon beim Anlegen der Datastores verfügbar war (und nicht erst durch ein späteres FW Upgrade).

Bei NAA fähigen Arrays verwendet ESX nämlich die Device WWN zur Identifikation eines Datastores, und die ist unabhängig von der LUN ID.
Jedoch wurde die NAA Unterstützung nach meinem Kenntnisstand erst ab ESX3.5U2 implementiert, wurden deine Datastores schon vorher angelegt, kann es Probleme geben.

fdisk -lu sollst du auf dem ESX Server ausführen, es liefert dir die Partitionsinfos zu deinen LUNs.
Mit diesen Infos könntest du die Partitionstabelle wieder herstellen, wenn jemand eine LUN z. B. mit diskpart clean "behandelt" hat.

Gruß
Ralf

[mullfreak]

Hi,

so, Befehle ausgeführt, hier das Ergebnis:

[root@DEGESX01 root]# esxcfg-vmhbadevs
vmhba0:0:0 /dev/cciss/c0d0
vmhba32:0:0 /dev/sda
vmhba32:2:0 /dev/sdb

[root@DEGESX01 root]# fdisk -lu

Disk /dev/sda: 440.3 GB, 440396611584 bytes
255 heads, 63 sectors/track, 53541 cylinders, total 860149632 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/sda1 128 860136164 430068018+ fb Unknown

Disk /dev/sdb: 440.3 GB, 440395628544 bytes
255 heads, 63 sectors/track, 53541 cylinders, total 860147712 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 128 860136164 430068018+ fb Unknown

Disk /dev/cciss/c0d0: 73.3 GB, 73372631040 bytes
255 heads, 63 sectors/track, 8920 cylinders, total 143305920 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/cciss/c0d0p1 * 63 305234 152586 83 Linux
/dev/cciss/c0d0p2 305235 10795679 5245222+ 83 Linux
/dev/cciss/c0d0p3 10795680 12900194 1052257+ 82 Linux swap
/dev/cciss/c0d0p4 12900195 143299799 65199802+ f Win95 Ext'd (LBA)
/dev/cciss/c0d0p5 12900258 33865019 10482381 83 Linux
/dev/cciss/c0d0p6 33865083 38057984 2096451 83 Linux
/dev/cciss/c0d0p7 38058048 42250949 2096451 83 Linux
/dev/cciss/c0d0p8 42251013 46443914 2096451 83 Linux
/dev/cciss/c0d0p9 46443978 143090954 48323488+ fb Unknown
/dev/cciss/c0d0p10 143091018 143299799 104391 fc Unknown

ID --> fb

Sieht gut aus, denke ich. Das heißt am WE alles umschrauben so dass es passen wird.

Danke auch an kastlr für den Beitrag.

Gruß
Mull