VMware-Forum

Hi,
hab hier ein komisches Phänomen bei einem Kunden.

2x ESX Hosts (3.5 Update4)
1x Virtual Center

Plötzlich ohne Fremdeinwirkung (angeblich) fehlt auf einem ESX Host eine LUN und alle VMs wurden auf den anderen Host geschoben. Es läuft auch alles soweit nur muss der Zweite HOST auch wieder ordentlich laufen und alle LUNs sehen.
Es handelt sich um vier LUNs.
Wenn ich direkt auf die console schaue und ein FDISK -L mache dann sieht man diese LUN auch eigentlich



Es handelt sich um /dev/sdd1 . Diese wird im Virtual Center unter Storage nicht mehr angezeigt.

Allerdings wenn ich mir den Storage Adapter anschaue sieht man dort alle LUNs . Also müsste man einfach nur irgendwie die LUN remounten. Dafür gibt es aber keine Funktion, diese gibt es erst seit dem ESX4. RESCAN und REFRESH hab cih schon probiert.

Wenn ich ein esxcfg-vmhbadevs --vmfs mache sehe ich auf dem ESX1


und auf dem wo es fehlt:


Ich muss die SDD1 irgendwie wieder mounten.
Hie rnoch ein esxcfg-swiscsi -s:



Dort werden alle angezeigt. Die fehlende wäre "0:3"

Jemand eine Idee? Wenn ihr noch irgendwelche daten benötigt dann sagt becheid kann ich euch dann geben.

Anbei noch ein Bild.

Gruss
woisch

das bild wollte im ersten beitrag nicht so.... :-/
kann das bild irgendwie nicht hinzufügen....

was sagt denn das vmkernel-log während eines rescans?

irgendwas mit "lun xxxxx may be a snapshot, disabling access?"
(sind auch super suchbegriffe )

wenn die LUN anscheinend vom ESX erkannt wird (beim rescan, zum sicherstellen mach mal cat /proc/scsi/scsi ), aber die VMFS-Partition drauf nicht gemounted wird, ist das meist ein anzeichen dafür, dass die LUN nicht mit der gleichen ID wie vorher/ wie dem anderen Server vom Storage präsentiert wird.

Dazu gibts dann die Einstellungen lvm.enableReginature und lvm.disallowsnapshots, die das richten, aber da sollte man nicht rumspielen ohne zu wissen was man tut.

Nähere Infos:
http://www.yellow-bricks.com/2008/12/11 ... apshotlun/
http://blog.laspina.ca/ubiquitous/under ... fs-volumes

Viele Grüße,
Jörg

Auf der LUN ist ein FAT16 - bieg mal auf Typ fb um.

Device Boot Start End Blocks Id System
/dev/sdd1 1 156650 1258291093+ 6 FAT16

und check ob der Anfang der Partition sauber eingerückt ist mit fdisk -lu.

Was passiert denn, wenn Du im VI Add Datastore machst, wird die LUN dann als VMFS oder als leer erkannt?

Ich kann keine Dateien anhängen, er sagt immer das die maximale Grösse aller attachments erreicht wurde obwohl die sachen nur ein paar kb sind......

Also hier dann das vmkernel log:


Am ende vom LOG steht was mit LUN-DATA1, das ist nicht die LUN um die es sich handelt. Hängt es aber vielleicht damit zusammen?) Das komische ist aber das der ESX Server drauf zugreifen kann.

Ein fdisk -lu gibt folgendes aus:



Das mit dem Typ FAT16 und FB hab ich ja auch schon gedacht. Nur wenn ich auf den ESX Host schaue der funktioniert, sieht es da gleich aus. Das iritierrt mich ein wenig.

Wenn ich direkt über den VCServer über add Storage was anhängen möchte, sehe ich gar nichts. Gehe ich direkt über den ESX Host wo die LUN fehlt sehe ich:



Was denkt ihr? Alles verloren? Aber das kann ich mir nicht vorstellen. Hat jemand Erfahrung mir "EnableResignature" . Kann ich das auf dem einen HOST einfach so machen, so dass der andere nicht beeinflusst wird? Ich vermute auch das da irgendwas mit der ID nicht mehr stimmt.

Sorry für den langen post aber ich kann leider keine Anhänge anfügen. :-/

Ok, das Thema ist erstmal abgeschlossen. Hab ein Ticket aufgemacht und eben hat ein Mitarbeiter von VMWare das Problem lösen können.

Letztendlich hat er es mit Abweichungen über diese Variante gelöst.

http://communities.vmware.com/message/258751#258751

Muss schon sagen das war ein fähiger Mensch.
Danke euch für eure Hilfe.

Gruss
woisch

nochmal zur Info.

Das Problem ist höchtwahrscheinlich vom VCServer ausgegangen. Dieser ist direkt mit dem SAN verbunden.

In letzter Zeit wurden häufiger externe Festplatten verbunden. Dadurch wurde die Partitionstabelle verändert und daher auch das plötzliche FAT16 System.....

Hätte man auf dem 1ten ESX einen rescan gemacht wäre die LUN höchstwahrscheinlich auch nicht mehr sichtbar.

Man sollte daher mit diskpart arbeiten unter dem Windows system.

Hier mal ein Link -> http://www.vmware.com/pdf/vi3_35/esx_3/ ... backup.pdf

Seite 34 wäre dann passend.

Gruss
woisch

Also war die VMFS-LUN für den Windows-Host sichtbar?

aaah, der Klassiker!

Dann hast Du wohl gerade nochmal Glück gehabt... ich kenn da einige Umgebungen, bei denen sowas schon zu ausführlichen Tests, ob das Backup funktioniert hat, führte

Viele Grüße,
Jörg

Ja, besonders weil der Standard-Windows-Admin immer ja klickt - auch auf die Frage, ob Windows mal eben die 1TB-LUN initialisieren soll. -.- Also: Unbedingt LUN-Masking/SSP/whatever machen!

Wenn die Windows-Maschine ein Backup-Proxy ist, ist LUN-Masking eher kontraproduktiv - jedenfalls dann, wenn man übers SAN sichern möchte...

Georg.

Naja, aber dann sollte der Windowsmensch ja wenigstens wissen, was er da tut...

Ich versuch bzgl. des VCB-Proxy immer, die Unternehmensrichtlinien etwas aufzuweichen/zu umgehen:
Der VCB-Proxy ist ein Teil der virtuellen Infrastruktur, kein "Windows server" im herkömmlichen Sinne. (kein komänenmitglied, nur die ESX-Admins haben zugriff drauf usw.)

Im Idealfall weiß die Mausschubser-Abteilung gar nicht, dass er existiert....

Lässt sich allerdings nicht überall machen, Stichwort Updates,Lizensierung usw.

Viele Grüße,
Jörg

fdisk /dev/sdd <enter>
d <enter>
w <enter>

und dann meinen Post von hier durchmachen

http://communities.vmware.com/message/909887