Disk-File hinüber?

[asi]

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

[stgepopp]

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

[asi]

die datei gibt es, die liegt da. jemand meinte mal, man solle mit dem command

Code: Alles auswählen

vmkfstools -g /vmfs/san1/vma.vmdk

schauen ob das file OK ist. dort meint das tool aber nur: DiskLib_Open() failed. The file specified is not a virtual disk. (13)

[stgepopp]

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

[Tovaco]

mal anderst gefragt, wie hast du das File angelegt ?

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

grüße thorsten

[asi]

danke erst mal für eure antworten.

@stgepopp

Code: Alles auswählen

[root@server san1]# head vma.vmdk | file -
standard input:              x86 boot sector


Code: Alles auswählen

[root@server san1]# vmware-mount.pl -p vma.vmdk

--------------------------------------------
VMware for Linux - Virtual Hard Disk Mounter
Version: 1.0 build-11548\nCopyright 1998 VMware, Inc.  All rights reserved. -- VMware Confidential
--------------------------------------------
Warning: Unable to open the virtual hard disk vma.vmdk


Code: Alles auswählen

[root@server san1]# vmkfstools -L reserve vma.vmdk
vma.vmdk: Permission denied


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

[Tovaco]

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

[asi]

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

[Tovaco]

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

[clabo]

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

[asi]

@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:

Code: Alles auswählen

-rw-------    1 root     root         4.0G Sep 22 11:34 vma.vmdk


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.

[Tovaco]

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

[asi]

hier die vmx-datei:

Code: Alles auswählen

#!/usr/bin/vmware
config.version = "6"
virtualHW.version = "3"
scsi0.present = "TRUE"
scsi0.virtualDev = "vmxlsilogic"
memsize = "384"
ide0:0.present = "TRUE"
ide0:0.fileName = "/dev/cdrom"
ide0:0.deviceType = "atapi-cdrom"
floppy0.startConnected = "FALSE"
floppy0.fileName = "/dev/fd0"
Ethernet0.present = "TRUE"
Ethernet0.connectionType = "monitor_dev"
Ethernet0.devName = "vmnic0"
Ethernet0.networkName = "VLAN4"
usb.present = "FALSE"
RemoteDisplay.depth = "16"
displayName = "vma"
guestOS = "winNetStandard"
checkpoint.cptConfigName = "vma-c3fde6c1"
priority.grabbed = "normal"
priority.ungrabbed = "normal"

Ethernet0.addressType = "generated"
uuid.location = "56 4d ba c0 85 b3 72 1f-05 57 a4 ba ec cd 9d 79"
uuid.bios = "56 4d ba c0 85 b3 72 1f-05 57 a4 ba ec cd 9d 79"
ethernet0.generatedAddress = "00:0c:29:cd:9d:79"
ethernet0.generatedAddressOffset = "0"

draw = "gdi"
isolation.tools.dnd.disable = "TRUE"
scsi0:0.name = "san1:vma.vmdk"
scsi0:1.name = "san1:vma-Disk1.vmdk"
scsi0:0.present = "TRUE"
scsi0:1.present = "TRUE"
tools.syncTime = "FALSE"


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/

Code: Alles auswählen

total 112k
-rw-------    1 root     root         8.5k Sep 22 12:34 nvram
-rwxr-xr--    1 root     root         1.0k Sep 16 11:32 ******05.vmx
-rwxr-xr--    1 root     root          975 Jun 15 19:10 ******08.vmx
-rwxr-xr--    1 root     root         1.1k Aug 20 02:29 ******15.vmx
-rwxr-xr--    1 root     root         1.0k Aug 20 02:44 ******16.vmx
-rwxr-xr--    1 root     root          983 Sep 22 12:34 ******50.vmx
-rwxr-xr--    1 root     root         1.0k Sep 20 11:32 ******70.vmx
-rwxr-xr--    1 root     root         1.1k Aug 20 02:30 ******90.vmx
-rwxr-xr--    1 root     root         1.1k Aug 20 02:45 vma.vmx
-rw-r--r--    1 root     root          14k Sep 22 13:04 vmware-0.log
-rw-r--r--    1 root     root          14k Sep 22 12:37 vmware-1.log
-rw-r--r--    1 root     root          19k Sep 22 12:34 vmware-2.log
-rw-r--r--    1 root     root          14k Sep 26 09:24 vmware.log


/vmfs/san1/

Code: Alles auswählen

total 196G
-rw-------    1 root     root         5.9G Sep 27 15:05 copy_of_******77.vmdk
-rw-------    1 root     root         6.0G Sep 20 12:51 copy_of_*****1k3.vmdk
-rw-------    1 root     root         8.0G Sep 28 10:13 ******01.vmdk
-rw-------    1 root     root         8.0G Sep 28 10:13 ******02.vmdk
-rw-------    1 root     root         8.0G Sep 28 10:09 ******03.vmdk
-rw-------    1 root     root         8.0G Sep 28 10:05 ******04.vmdk
-rw-------    1 root     root         6.0G Sep 28 12:26 ******05.vmdk
-rw-------    1 root     root         6.0G Jun 17 13:39 ******08.vmdk
-rw-------    1 root     root         3.9G Sep 28 10:13 ******09.vmdk
-rw-------    1 root     root         9.0G Sep 28 10:13 ******10-Disk1.vmdk
-rw-------    1 root     root         6.0G Sep 28 10:13 ******10.vmdk
-rw-------    1 root     root         6.0G Sep 28 10:13 ******11.vmdk
-rw-------    1 root     root         5.9G Sep 28 10:13 ******12.vmdk
-rw-------    1 root     root         4.0G Aug 31 13:58 ******12.vmdk.new
-rw-------    1 root     root         3.9G Sep 28 10:13 ******13.vmdk
-rw-------    1 root     root         5.9G Sep 28 10:13 ******14.vmdk
-rw-------    1 root     root         4.0G Sep 28 12:27 ******15.vmdk
-rw-------    1 root     root         4.0G Aug 20 01:17 ******16.vmdk
-rw-------    1 root     root         6.0G Sep 20 12:16 ******50.vmdk
-rw-------    1 root     root         6.0G Sep 28 12:27 ******70.vmdk
-rw-------    1 root     root          29G Sep 28 10:13 ******76-Disk1.vmdk
-rw-------    1 root     root         6.0G Sep 28 10:13 ******76.vmdk
-rw-------    1 root     root         5.9G Sep 28 10:13 ******77.vmdk
-rw-------    1 root     root         4.0G Sep 28 12:27 ******90.vmdk
-rw-------    1 root     root          12G Aug 20 02:39 vma-Disk1.vmdk
-rw-------    1 root     root         4.0G Sep 22 11:34 vma.vmdk
-rw-------    1 root     root         4.0G Sep 22 11:18 ******00.vmdk.200509220917
-rw-------    1 root     root         3.9G Sep  5 15:49 ******20.vmdk
-rw-------    1 root     root         6.0G Sep 16 11:31 *****2k3.vmdk


thx für den einsatz

[Tovaco]

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

Code: Alles auswählen

/root/vmware/winNetStandard/
-rwxr-xr--    1 root     root         1.1k Aug 20 02:45 vma.vmx

/vmfs/san1/
-rw-------    1 root     root          12G Aug 20 02:39 vma-Disk1.vmdk
-rw-------    1 root     root         4.0G Sep 22 11:34 vma.vmdk


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 ?

[asi]

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

Code: Alles auswählen

vmkernel.1:Aug 20 01:03:59 ******81 vmkernel: 52:23:54:15.458 cpu0)SCSI: 8959: Finished rescan of adapter vmhba2


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

Code: Alles auswählen

vmkernel.1:Aug 20 01:07:32 ******81 vmkernel: 52:23:57:48.402 cpu1)WARNING: SCSI: 5331: vmhba1:1:1:5 status = 24/0 0x0 0x0 0x0
vmkernel.1:Aug 20 01:07:32 ******81 vmkernel: 52:23:57:48.402 cpu1)SCSI: 8752: vmhba1:1:1:5 status = 24/0 0x0 0x0 0x0

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

Code: Alles auswählen

vmkernel:Aug 20 02:44:47 ******81 vmkernel: 53:01:35:03.369 cpu0)WARNING: FS2: 2996: Accessing non-disk-image VMFS file as a virtual disk

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

Code: Alles auswählen

grep "Aug 20" * | less

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:

[Tovaco]

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

[asi]

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:

Code: Alles auswählen

./vmkernel.1:Aug 20 01:33:42 ******81 vmkernel: 53:00:23:56.904 cpu0)VMNIX: VMKFS: 2624: dentryreval returned failure (00000000=<NULL>,cdc03900=vma-Disk1.vmdk)
./vmkernel.1:Aug 20 01:39:24 ******81 vmkernel: 53:00:29:38.209 cpu0)VMNIX: VMKFS: 2624: dentryreval returned failure (00000000=<NULL>,c8f50200=vma.vmdk)


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...