VMware-Forum

Hallo erst mal,

Ich bin neu hier, gewissermassen auch Neuling was die Verwaltung von ESX Servern angeht. Dieses Los gezogen habe ich wegen der Linux Kenntnisse, welche bei ESX aber wohl den allerkleinsten Teil ausmachen...

Bei der VM A wird mir beim Start folgender Fehler angezeigt:
Unable to open scsi target san1:vma.vmdk: Invalid Argument (2)
Failes to configure scsi0

für diese VM sind zwei Virtuelle Disks erstellt worden, scsi1 funktioniert noch immer. Ich kann das DiskFile vma.vmdk auch nicht auswählen (es wird garnicht angezeigt in der Liste).

Wenn ich in der Management Konsole (also via Browser) den Verzeichnisbaum durchsuche und zu den DiskFiles gelange, werden mir alle DiskFiles mit einem "Disk-Icon" angezeigt, das der vma jedoch nicht, das Icon ist leer.

Ich wäre wirklich dankbar um eine Antwort... wenn's denn eine gibt Kann man ein defektes File "reparieren"? Und wie kommt es das ein File überhaupt korrupt wird?

Danke schon im Voraus. Gruss, Tobi

Hallo asi,

öffne mal als root eine Putty-Session zu deiner Service-Console und mach mal:

# ls -l /vmfs/san1/vma.vmdk

Kommt 'ne Fehlermeldung, dann liegt das File wo anders oder es existiert nicht mehr. Wird was angezeigt, dann hast du als VM-User nicht die passenden Rechte, dann sollte die VM aber als root startbar sein.

Die Fehlermeldung bedeutet konkret, dass in der Konfigurationsdatei (*.vmx) ein Verweis zu einer VM-Diskdate (san1:vma.vmdk) drin steht und die kann nicht geöffnet werden.

Erich

die datei gibt es, die liegt da. jemand meinte mal, man solle mit dem command schauen ob das file OK ist. dort meint das tool aber nur: DiskLib_Open() failed. The file specified is not a virtual disk. (13)

Hallo Asi,

also Datei ist da. Check mal, ob die Datei wirklich gelockt ist z.B:

# head vma.vmd | file -
# vmware-mount.pl -p vma.vmdk

Wenn nach den beiden Beispiel-Kommandos ein Fehler angezeigt wird, ist die Disk gesperrt.

Check mal, ob es noch einen Prozess gibt für diese VM:

# ps -ef | grep vmware

Falls du einen Prozess findest, der diese Disk sperrt:

# kill -9 PID

Sonst hilft nur noch:

# vmkfstools -L ...
# vmkfstools -R ...

(vorher in der man-Page nochmals lesen)

oder Reboot.

Erich

mal anderst gefragt, wie hast du das File angelegt ?

über einen feinen vmkfstools -c 999G /vmfs/<LUN-Name>/<blabla.vmdk> ?

grüße thorsten

danke erst mal für eure antworten.

@stgepopp







der andere befehl, vmkfstools -R vma.vmdk zeigt mir einfach die "help" site, also welche befehle man wie verwendet, tut aber nix in dem sinn

wenn ich den ps befehl ausführe bekomme ich eine riesen liste. ist in der liste irgendwo ersichtlich welche VM auf welche disk zugreifft? rebooten kommt nicht in frage (also zumindest nicht während den geschäftszeiten)...

danke so weit.


Tovaco
wie das diskfile angelegt wurde weiss ich nicht. wie gesagt, ich hatte bis jetzt eigentlich nichts damit zu tun, darf aber jetzt debugen. die zuständigen herren sind sich nicht ganz sicher. soviel ich weiss (nach anfrage), wurde das diskfile einfach im webforntend des ESX erstellt wo die ganze VM kreiert wurde...

danke auch dir.


LG, tobi

Hallo Tobi,

bist zu zwischenzeitlich mit deinem Problem weitergekommen ?

Wenn nicht würde ich dir mal folgendes vorschlagen:

Kopier das dsk-File, welches ok ist, (weit) weg. Dann editier das vmx-file und werf das 2.dsk-file weg.

Dann starte den Gast. Wenn das funktioniert, dann kannst du zumindest sicher sein, daß das andere dsk-file noch nie richtig an einem esx-Gast drangehangen hat.

Dann überprüf mal, ob die Daten die du siehst denen entsprechen die du erwartest, oder erwarten solltest.

Wenn das alles nichts hilft dann schlage ich die rücksicherung einer hoffentlich erstellten Sicherung vor.

Da du hier mit "lebenden/wichtigen" Daten rumhantierst schlage ich dir vor, die virtuellen-scsi-devices in den Status "undoable" zu setzen. Muß halt auf der betreffenden LUN noch etwas Platz sein. Vorteil: du machst deine Veränderungen und beim Stop des VM kannst du entscheiden ob du die Änderungen auf das org.dsk-file schreiben läßt oder nach wie vor auf ein "redo-log" schreibst. An solchen Übungen bin ich aktuell dran und ich finde immer mehr Gefallen an solchen"Redo-Logs". Davon abgesehen, daß du im laufenden Betrieb ein dsk-File wegkopieren kannst, da das dsk-File nur READ-ONLY ist und nicht dauernd "busy".

grüße
thorsten

morgen Tovaco,

Danke für die Antwort. Also, das File das ich hier habe, welches nicht geht, ist eine Weile ganz normal gelaufen. Es wurde verwendet, es hing an der VM. Irgend etwas ist nicht ganz okay. dieses Phänomen hatten wir bereits einmal, dass bei einer Windows-WM einfach das Disk-File unbrauchbar ist. Das mit der Sicherung ist kein Thema, nur wäre es wichtig zu wissen aus welchen Gründen sowas passiert, schliesslich kann das ja nicht immer so weiter gehn

vielen dank noch für den tip mit dem scsi-status. kann man sehr gut brauchen. ich muss mich in dieses thema sowieso noch einarbeiten, aber wie du das erzählst, bekomm ich da richtig lust drauf

Danke und Gruss, Tobi

Das mit dem head und file habe ich auf ein windows und ein linux-vmdk-file ausprobiert:

windows: standard input: ASCII text, with no line terminators
linux: standard input: x86 boot sector

liegt wohl daran, daß das linux mit dem header vom windows nix anfangen kann.

Aber dein vmdk ist immer noch kaputt ?

vielleicht hast du´s dir mal zerstört als du per dd if=/dev/zero of=/vmfs/SAN.../...vmdk-file gemacht hast ?

grüße thorsten

wie sind die Zugriffsrechte auf das vmdk-File?
unter welchem Konto arbeitest Du in der SC? root?

@Tovaco
die vmdk funktioniert nach wie vor nicht kann sein das linux nix mit dem file beginnen kann, ich weiss auch nicht wieviel linux damit zu tun hat. fakt ist aber das VMware, also der ESX server sehr wohl etwas mit diesem file anfagen können sollte...

ich habe nie diskfiles auf diese art "platt" gemacht (dd). wie gesagt, ich selber habe nie etwas mit dem server zu tun gehabt, ich bin nur göttlicherweise für das debugging zuständig. die verantwortlichen herren haben aber dummer weise vieles vergessen, sprich: sie wissen nicht mehr genau wie sie vorgegangen sind, sie wissen nicht genau seit wann die files korrupt sind... ich bin also in einer etwas blöden situation weil ich weder ahnung habe was die angestellt haben, mir noch von ihnen helfen lassen kann...

@clabo
die berechtigung sieht wie folgt aus:

und ich arbeite mit root, jep. die berechtigungen sollten ja richtig sein, alle anderen files haben dieselben berechtigungen und owner.

danke nochmals und sorry das ich hier keine genaueren angaben machen kann, bin selber etwas frustiert von den inputs die ich erhalte.

poste mal dein vmx-file

dann noch bitte einen ls -lh auf der console, auch hier posten.

Ich würd dir ja gerne helfen...aber so Ferndiagnosetechnisch ist das alles
ein wenig Mist.

grüße thorsten

hier die vmx-datei:


und welchen ls -lh, von welchem directory? von dem wo die config-files sind oder von dem wo die disk-files sind? (ich werd mal beides *g*)

/root/vmware/winNetStandard/


/vmfs/san1/


thx für den einsatz

Hm...das ist doch merkwürdig. Sind die die Uhrzeiten der Files aufgefallen ?



Ich möcht da ja nicht unken, aber das sieht danach aus, als ob´s letzte Mal am 20August um 2.39 gelebt hat. Und danach wars das dann.

Grüße Thorsten

ps: ich dachte, daß irgendwo ein Schreibfehler oder eine Berechtigung nicht paßt. Aber bei mir sehen die Kisten auch so aus.

vielleicht mal unregistrieren und anschließend wieder registrieren ?

ich hab mich mal durch die logs gewühlt und mir vor allem den 20 August etwas genauer angesehen. etwas fällt mir auf, sagt mir aber nichts. nach dem befehl

erscheinen diese beiden meldungen immer abwechselnd (nehme an die gehören so zusammen), mehrmals pro sekunde


dann, etwas später (um 2:44 desselben tages) kommt die nachricht

diese nachricht erscheint erst ab diesem datum und von da an in unregelmässigen abständen.

ich habe jetzt einfach im verzeichnis /var/log/ mit
gesucht, genauso bei den meldungen etc. gibt es noch andere verzeichnise, spezielle logfiles die ich beachten muss? ich habe auch das problem das teils logs vor dem 30 august garnicht existieren oder schon gelöscht wurden *grml*

danke übrigens für den tip mit dem datum, ist mir ganz entgangen...

edit: mir ist so eben aufgefallend as eine andere vmdk ebenfalls während dem 20 august, früh morgens (gegen 1 uhr) das letzte mal benutzt wurde. dieses file ist ebenfalls korrupt. ich vermute das bei der SAN-anbindung etwas schief lief, werde mich mal in dieser richtung umhören :wink:

mal nachdenken:
also per grep -ir "text" /var/log/* sucht das liebe linux auch in Unterverzeichnissen (-r) und ohne Groß-/Kleinschreibung (-i).

naja, die normalen Verdächtigen:
/var/log/messages
/var/log/vmkernel
/var/log/vmware/vmware-ccagent bzw. vmware-guestd

die vmware.log Files deines Gastes...

Also was noch zu klären ist, ob das tatsächlich mitten in der Nacht war, oder ob nur die aktuelle Uhrzeit daneben ist/war.

Beim Rescan sollte nichts daneben gehen. Weil der Gast muß ja gestartet sein und erst danach wurde er zerstört...

Entweder hat einer das File dann auf der Console zerlegt (der Gast kann das ja nicht) oder SAN.

Wenn beispielsweise das SAN von A nach B gespiegelt wird...und jetzt hat einer den Spiegel von B nach A umgebogen, dann ist natürlich die komplette LUN im Eimer...bzw. Die Files die halt vom Spiegelprozess im SAN gerade erwischt wurden.

Vielleicht kommste in der Ecke etwas weiter.

Grüße Thorsten

guten morgen,

ich habe mir alle logfiles (mir grep -ir) nochmals angesehen und durchstöbert. habe dabie nach dem 20. August, dem VM name etc. gesucht. dabei bin ich auf folgendes gestossen:

diese zeilen, also "dentryreval returned failure" hab ich aber bei so ziemlich jeder VM irgendwo mal feststellen können. ich dachte aber, so von der zeit und datum her könnte das ein anhaltspunkt sein.

dazu kommt das bei einer anderem VM ebenfalls ein korruptes diskfile vorhanden ist, auf demselben server. auch dieses file wurde zuletzt an diesem 20. August editiert, etwa eine stunde vor dem der vma.

was die serverzeit angeht. diese geht, wie ich festellen muss, zwei stunden vor. ist eigentlich nicht sooo tragisch, nur weiss ich nicht wie's zu dem zeitpunkt war

ich hab mir dann mal die log-files der SAN switches sowie der EVA zeigen lassen. dort war herzlich wenig zu erkennen. von dem datum, 20.8, gabs eigentlich nur ganz normale systemmeldungen, keine probleme oder derartiges... ich bin langsam echt überfragt...