Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

Virtuelle Platte defekt ?

Hilfe bei Problemen mit der Installation oder Benutzung des VMware GSX Server und VMware Server 1.

Moderatoren: irix, Dayworker

Member
Beiträge: 10
Registriert: 08.01.2009, 17:32

Virtuelle Platte defekt ?

Beitragvon enzo_ferrari » 16.07.2012, 15:25

Hi,

ich bekomme auf einer VM für die Rootpartition folgende Fehlermeldung:
"EXT3-fs error (device hda3) in start_transaction: Journal has aborted". Lt.
"http://rackerhacker.com/2007/11/20/ext3-fs-error-device-hda3-in-start_transaction-journal-has-aborted/" passiert das, wenn sich Journal und Filesystem nicht einig sind. Das Fixen scheint nach dieser Webseite kein großes Problem. Aber wie kann eine virtuelle Platte kaputt gehen ? SMART unterstützt sie nat. nicht. Die VM liegt auf einem logical volume, das wiederum auf einem RAID5 auf einem HP ML350G5 liegt, RAID-Controller ist ein HP-Controller E200i. Lt. Webinterface ist der sowie auch die Platten in Ordnung.
Mit smartctl kommt der RAID-Controller nicht klar:

pc53200:~ # smartctl -H /dev/cciss/c0d0
smartctl version 5.38 [x86_64-suse-linux-gnu] Copyright (C) 2002-7 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Standard Inquiry (36 bytes) failed [No such device or address]
Retrying with a 64 byte Standard Inquiry
Standard Inquiry (64 bytes) failed [No such device or address]
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.
pc53200:~ # smartctl -a /dev/cciss/c0d0
smartctl version 5.38 [x86_64-suse-linux-gnu] Copyright (C) 2002-7 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Standard Inquiry (36 bytes) failed [No such device or address]
Retrying with a 64 byte Standard Inquiry
Standard Inquiry (64 bytes) failed [No such device or address]
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

Host OS ist SLES 10 SP4, Gast OS ist SuSE 9.2


Bernd



Bernd

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 16.07.2012, 17:23

Was sagt ein Dateisystemcheck innerhalb der VM dazu?

Member
Beiträge: 10
Registriert: 08.01.2009, 17:32

Beitragvon enzo_ferrari » 16.07.2012, 17:34

Dayworker hat geschrieben:Was sagt ein Dateisystemcheck innerhalb der VM dazu?


Hallo,

ich bin nach der o.g. Anleitung vorgegangen, fsck hat repariert. Nach dem Booten der VM läuft diese z.Zt. einwandfrei. Die Frage ist auch eher "Wie kann eine virtuelle Festplatte kaputt gehen ?". Schließlich liegt die ja physikalisch nicht vor.

Bernd

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 16.07.2012, 17:57

Fuer solche Effekte kommen Virenscanner oder hartes Abschalten (VM-Stop/Reset, USV-Einsatz) in Frage.

Was haben das "vmware.log" und dein Host/Gast-Kernel.log dazu vermerkt?

Member
Beiträge: 10
Registriert: 08.01.2009, 17:32

Beitragvon enzo_ferrari » 16.07.2012, 19:02

Dayworker hat geschrieben:Was haben das "vmware.log" und dein Host/Gast-Kernel.log dazu vermerkt?


Ich hab beim letzten booten der VM einen event bekommen, in dem directory der VM seien nur 150MB frei. Df -h auf der betr. Partition sagt aber, es wären 32 GB frei.
Das log im Gast setzt zu einem best. Zeitpunkt einfach aus, da aus Sicherheitsgründen, wenn sich Journal und Filesystem nicht einig sind, die Platte nur ro gemountet wird.

Ich guck mir die logs noch näher an, dann gibt's ein weiteres posting.

Bernd

Benutzeravatar
UNSTERBLICH(R.I.P.)
Beiträge: 14759
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 17.07.2012, 03:07

:Die Frage ist auch eher "Wie kann eine virtuelle Festplatte kaputt gehen ?". Schließlich liegt die ja physikalisch nicht vor.


Speziell bei wachsenden vmdks können virtuelle Platten auch kaputt gehen.
Das äussert sich dann entweder so wie es dir jetzt passiert ist - oder aber VMware meldet.

"The virtual disk needs repair"" beim starten.

Member
Beiträge: 10
Registriert: 08.01.2009, 17:32

Beitragvon enzo_ferrari » 17.07.2012, 11:11

continuum hat geschrieben:
:Die Frage ist auch eher "Wie kann eine virtuelle Festplatte kaputt gehen ?". Schließlich liegt die ja physikalisch nicht vor.


Speziell bei wachsenden vmdks können virtuelle Platten auch kaputt gehen.
Das äussert sich dann entweder so wie es dir jetzt passiert ist - oder aber VMware meldet.

"The virtual disk needs repair"" beim starten.


Hi,

ich habe den Platz der Platte direkt komplett allokiert.
Hast Du eine Idee wieso die VM beim Booten zickt, es wäre kaum Platz da, wenn in /var noch 32GB frei sind ?

Bernd

Member
Beiträge: 10
Registriert: 08.01.2009, 17:32

Beitragvon enzo_ferrari » 17.07.2012, 13:37

Dayworker hat geschrieben:Fuer solche Effekte kommen Virenscanner oder hartes Abschalten (VM-Stop/Reset, USV-Einsatz) in Frage.

Was haben das "vmware.log" und dein Host/Gast-Kernel.log dazu vermerkt?


Hier weiteres zu den logs:
Ich habe in sämtlichen logs nichts Auffälliges gefunden. Btw: kann man die Zeitstempel in den event-logs in "echte" Zeit umrechnen ?
Ichwüßte mal gerne, was 1337265424 und 1337342122 für eine Zeit ist.

Bernd

Benutzeravatar
UNSTERBLICH(R.I.P.)
Beiträge: 14759
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 17.07.2012, 13:53

GMT: Thu, 17 May 2012 14:37:04 GMT
und
GMT: Fri, 18 May 2012 11:55:22 GMT

anhand http://www.epochconverter.com/

Alle Angaben ohne Gewähr

Member
Beiträge: 10
Registriert: 08.01.2009, 17:32

Beitragvon enzo_ferrari » 17.07.2012, 13:58

continuum hat geschrieben:GMT: Thu, 17 May 2012 14:37:04 GMT
und
GMT: Fri, 18 May 2012 11:55:22 GMT

anhand http://www.epochconverter.com/

Alle Angaben ohne Gewähr


Danke. Dann sind die Meldungen beim Booten bzgl. geringen Speicherplatz nicht aktuell und haben mit dem aktuellen Problem nichts zu tun.

Bernd

King of the Hill
Beiträge: 12942
Registriert: 02.08.2008, 15:06
Wohnort: Hannover/Wuerzburg
Kontaktdaten:

Beitragvon irix » 17.07.2012, 14:54

enzo_ferrari hat geschrieben:
Dayworker hat geschrieben:Fuer solche Effekte kommen Virenscanner oder hartes Abschalten (VM-Stop/Reset, USV-Einsatz) in Frage.

Was haben das "vmware.log" und dein Host/Gast-Kernel.log dazu vermerkt?


Hier weiteres zu den logs:
Ich habe in sämtlichen logs nichts Auffälliges gefunden. Btw: kann man die Zeitstempel in den event-logs in "echte" Zeit umrechnen ?
Ichwüßte mal gerne, was 1337265424 und 1337342122 für eine Zeit ist.

Bernd


Das ist ein Unix Timestamp und der Gibt die Anzahl der Sekunden seit dem 1.Jan. 1970 an.

Code: Alles auswählen

C:\temp>php -r "echo date('d.m.Y H:i:s', 1337265424 );"
17.05.2012 16:37:04


Gruss
Joerg

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 17.07.2012, 15:36

enzo_ferrari hat geschrieben:Hier weiteres zu den logs:
Ich habe in sämtlichen logs nichts Auffälliges gefunden.

Zippe doch einfach alle noch vorhandenen "vmware.log" und verlinke diese auf einen Freehoster.
Du hast ja bekanntermaßen nicht beliebig viele Start/Stop-Versuche um ein Problem auf den Grund zu gehen. Nach vier VM-Start/Stops sind alle Logs durchrotiert. ;)

Member
Beiträge: 10
Registriert: 08.01.2009, 17:32

Beitragvon enzo_ferrari » 18.07.2012, 20:46

Dayworker hat geschrieben:
enzo_ferrari hat geschrieben:Hier weiteres zu den logs:
Ich habe in sämtlichen logs nichts Auffälliges gefunden.

Zippe doch einfach alle noch vorhandenen "vmware.log" und verlinke diese auf einen Freehoster.
Du hast ja bekanntermaßen nicht beliebig viele Start/Stop-Versuche um ein Problem auf den Grund zu gehen. Nach vier VM-Start/Stops sind alle Logs durchrotiert. ;)


Hier die 4 Logs:

http://filecloud.io/6i1dhswt
http://filecloud.io/pco0bvw8
http://filecloud.io/dvp3gzwn
http://filecloud.io/a6no1cyq

Bernd

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 19.07.2012, 16:34

Dein ältestes Log (vmware-2.log) stammt vom 24.Juni 18:29:03 bis 16.Juli 14:08:37 und zu diesem Zeitpunkt hattest du noch freien Plattenplatz:
Jun 24 18:29:04: vmx| DISK: OPEN '/var/lib/vmware/Virtual Machines/seneca/seneca.vmdk' Geo (7832/255/63) BIOS Geo (7832/255/63) freeSpace=68034Mb


Beim Stand von vmware-1.log am 16.Juli zwischen 14:12:55 bis 15:49:32 hattest du nur noch freien Platz übrig:
Jul 16 14:12:56: vmx| DISK: OPEN '/var/lib/vmware/Virtual Machines/seneca/seneca.vmdk' Geo (7832/255/63) BIOS Geo (7832/255/63) freeSpace=32459Mb


Das vmware-0.log vom 16.Juli 15:50:01 bis 18.Juli 19:53:34 vermeldete noch:
Jul 16 15:50:01: vmx| DISK: OPEN '/var/lib/vmware/Virtual Machines/seneca/seneca.vmdk' Geo (7832/255/63) BIOS Geo (7832/255/63) freeSpace=32458Mb


Das neueste vmware.log vom 18.Juli 20:04:35 bis zum letzten Eintrag um 20:05:34 des gleichen Tages listete noch:
Jul 18 20:04:35: vmx| DISK: OPEN '/var/lib/vmware/Virtual Machines/seneca/seneca.vmdk' Geo (7832/255/63) BIOS Geo (7832/255/63) freeSpace=36582Mb



Als vDisk ist eine "vmx| DISKLIB-LINK : Opened '/var/lib/vmware/Virtual Machines/seneca/seneca.vmdk' (0xa): twoGbMaxExtentFlat, 125829120 sectors / 61440 Mb." im Einsatz. Von daher sollte der freie Platz eigentlich egal sein, die vDisk wurde ja bereits in voller Größe angelegt.

Fragezeichen verursachen bei mir im vmware-1.log nur Einträge der Art:
Jul 16 14:40:46: vcpu-0| SCSI DEVICE (scsi0:0): No transfer information for READ DEFECT DATA (0x37)
Jul 16 14:40:46: vcpu-0| SCSI-DEV0:0: Unsupported command READ DEFECT DATA issued. --ok
Auch wenn dort hintenan immer "--ok" steht, dürfte zu diesem Zeitpunkt auf dem Host irgendetwas passiert sein.
Noch übler in dieser Hinsicht sind aber die folgenden Einträge am 13.Juli:
Jul 12 23:09:22: vmx| SCSI0:0: Command WRITE(10) took 1.407 seconds (ok)
Jul 12 23:09:22: vmx| SCSI0:0: Command WRITE(10) took 1.434 seconds (ok)
Jul 12 23:09:22: vmx| SCSI0:0: Command WRITE(10) took 1.433 seconds (ok)
Jul 12 23:09:22: vmx| SCSI0:0: Command WRITE(10) took 1.431 seconds (ok)
Jul 12 23:09:22: vmx| SCSI0:0: Command WRITE(10) took 1.449 seconds (ok)
Jul 12 23:09:22: vmx| SCSI0:0: Command WRITE(10) took 1.083 seconds (ok)
Jul 12 23:09:22: vmx| SCSI0:0: Command WRITE(10) took 1.094 seconds (ok)
Jul 12 23:09:22: vmx| SCSI0:0: Command WRITE(10) took 1.125 seconds (ok)
Jul 12 23:09:22: vmx| SCSI0:0: Command WRITE(10) took 1.139 seconds (ok)
Jul 12 23:09:23: vmx| SCSI0:0: Command WRITE(10) took 1.169 seconds (ok)
Jul 12 23:09:24: vmx| SCSI0:0: Command WRITE(10) took 1.131 seconds (ok)
Jul 12 23:09:24: vmx| SCSI0:0: Command WRITE(10) took 1.138 seconds (ok)
Jul 12 23:09:24: vmx| SCSI0:0: Command WRITE(10) took 1.143 seconds (ok)
Jul 12 23:09:24: vmx| SCSI0:0: Command WRITE(10) took 1.144 seconds (ok)
Jul 12 23:09:24: vmx| SCSI0:0: Command WRITE(10) took 1.152 seconds (ok)
Jul 12 23:09:24: vmx| SCSI0:0: Command WRITE(10) took 1.027 seconds (ok)
Jul 13 12:39:22: vmx| DISKLIB-LIB :numIOs = 1950000 numMergedIOs = 0 numSplitIOs = 0

Jul 13 17:49:31: vcpu-0| SCSI0:0: Command WRITE(10) took 30.008 seconds (ok)
Jul 13 17:50:02: vcpu-0| SCSI0:0: Command WRITE(10) took 30.017 seconds (ok)
Jul 13 17:50:31: vcpu-0| SCSI0:0: Command WRITE(10) took 29.987 seconds (ok)
Jul 13 17:51:02: vcpu-0| SCSI0:0: Command WRITE(10) took 30.018 seconds (ok)
Jul 13 17:51:32: vcpu-0| SCSI0:0: Command WRITE(10) took 29.996 seconds (ok)
Jul 13 17:52:01: vcpu-0| SCSI0:0: Command WRITE(10) took 29.987 seconds (ok)
Jul 13 17:52:31: vcpu-0| SCSI0:0: Command WRITE(10) took 29.964 seconds (ok)
Jul 13 17:53:01: vcpu-0| SCSI0:0: Command WRITE(10) took 29.994 seconds (ok)
Jul 13 17:53:31: vcpu-0| SCSI0:0: Command WRITE(10) took 29.993 seconds (ok)
Jul 13 17:54:01: vcpu-0| SCSI0:0: Command WRITE(10) took 30.044 seconds (ok)
Jul 13 17:54:31: vcpu-0| SCSI0:0: Command WRITE(10) took 29.977 seconds (ok)
Jul 13 17:55:01: vcpu-0| SCSI0:0: Command WRITE(10) took 30.013 seconds (ok)
Jul 13 17:55:31: vcpu-0| SCSI0:0: Command WRITE(10) took 29.991 seconds (ok)

Jul 13 17:55:37: vmx| SCSI0:0: Command WRITE(10) took 5.750 seconds (ok)
Jul 13 17:55:37: vmx| SCSI0:0: Command WRITE(10) took 5.750 seconds (ok)
Jul 13 17:55:37: vmx| SCSI0:0: Command WRITE(10) took 5.750 seconds (ok)
Jul 13 17:55:37: vmx| SCSI0:0: Command WRITE(10) took 5.750 seconds (ok)
Jul 13 17:55:37: vmx| SCSI0:0: Command WRITE(10) took 5.750 seconds (ok)
Wenn man mal ein Raid im Einsatz hatte, kennt man diese ominösen 30sec sehr genau. Das ist nämlich genau die Zeit, die eine Platte vom Controller bzw OS bekommt, um einen Schreibbefehl abzuschließen, bevor das OS von einem Schreibfehler ausgeht (dürfte sich als Kernel-oOPs oder BSOD bemerkbar machen) oder der Controller ein "Degraded Raid" an das OS meldet. Auch zu diesem Zeitpunkt muß etwas auf dem Host passiert sein.
Die in orange geschriebenen Zeilen sehe ich dagegen schon wieder als unproblematisch an. Sowas kann auf einem Host, der zu mehr als nur dem Hosten des VMserver dient oder über keine getrennten Datenträger für System und vDISKs verfügt, immer mal auftreten und solange diese kurzzeitigen Ausrutscher immer unterhalb 10sec bleiben, hatte ich noch nie Probleme gehabt. In deinem Fall deutet es aber auf rege Schreibaktivität nach einen Plattenproblem bzw eventuell auch ein Raid-Rebuild in niedriger Priorität hin.


Abschließend läßt sich sagen, daß du keine Logs vom fraglichen Zeitraum um den "17.05.2012 16:37:04" mehr hast. Das waren also 2 komplette VM-Start/Stop-Zyklen zuviel.


PS: Hast du was mit Spinhenge@Home zu tun :?:

Member
Beiträge: 5
Registriert: 02.10.2012, 14:07

Beitragvon KingPeter » 10.10.2012, 12:24

continuum hat geschrieben:GMT: Thu, 17 May 2012 14:37:04 GMT
und
GMT: Fri, 18 May 2012 11:55:22 GMT

anhand http://www.epochconverter.com/

Alle Angaben ohne Gewähr

Lange gesucht und endlich gefunden! :) Vielen Dank. Gibt es dafür auch ein Tool? Würde es gerne automatisiert umrechnen lassen.

LG



[edit um 21h16]
Link zur Mobile-Ortung entfernt...
[/edit]

Benutzeravatar
UNSTERBLICH(R.I.P.)
Beiträge: 14759
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 10.10.2012, 15:23

@ King Peter

ABMAHNUNG

Du hast einen sinnvollen Link geandert und auf etwas verlinkt das hier nichts zu suchen hat.

Nochmal so eine Aktion und dein Account ist Vergangenheit


Zurück zu „VMserver 1 und GSX“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 7 Gäste