RIESEN PROBLEM BITTE F1 !

[newbie2007]

Hi,
ich habe ein riesiges Problem mit meinem ESXi 4 Server, ich habe drei virtuelle Festplatten angelegt und es hat auch alles perfekt funktioniert, auf einmal kam folgende Fehlermeldung:

Code: Alles auswählen

Meldung von localhost.localdomain: There is no
more space for virtual disk
MSHOGHE01-02-000001.vmdk.  You may be able
to continue this session by freeing disk space on
the relevant partition, and clicking Retry.
Otherwise, click Abort to terminate this session.
Info
14.09.2010 18:20:09
User


Jetzt möchte ich wissen was hier das Problem ist, wenn ich die VM starte kommt immer die gleiche Meldung und die VM läßt sich nicht starten.

Nun möchte ich damit ich die Daten wenigstens noch von der VM bekomme, die virtuellen Harddisks noch auf eine bestehende funktionierende VM einbinden, wie mache ich das am besten?

Ich danke allen für die Mitarbeit.

Newbie2007

[echt_weg]

Scheint so als wäre der Datastore einfach voll?

Erst einmal nichts machen solange nicht klar ist was genau los ist. Nicht anfangen Dateien zu löschen oder ähnliches

Sind die "neuen" virtuellen Platten alle leer?

Snapshots auf dieser oder anderen VMs (auf gleichem Datastore) vorhanden?

[irix]

Also fuer jeden welcher hier der mit dem Problem eines vollgelaufenen Datastore und Snapsshotproblemen aufschlaegt einen Euro und das Thema Rente koennte man entspannter ansehen.

Letzen Samstag gabs http://vmware-forum.de/viewtopic.php?p=106317#106317 und die Problemloesung ist auch aufgezeigt.

Um zu wissen ob man die Snaps ueberhaupt noch Comitten(Loeschen) kann muss man wissen wie Gross die sind und wieviel Platz noch auf dem Datastore ist. Aber da schon die Meldung kommt das er fuer ein 16MB extend keinen Platz mehr hat kann man das loeschen gleich knicken.

Die Loesung ist die VMDK in einen neuen Datastore zukopieren und dabei die Snaps zu Committen. Es kommt dann hinten der aktuelle Stand raus. Das macht man mit jeder VMDK welche die VM hat.

Vorraussetzung ist aber das die Snapshotkette noch intakt ist.

Gruss
Joerg

[newbie2007]

Hi,
ja die Rente ist anscheinend gesichert . Jetzt habe ich alles was noch auf diesem Store gelegen hat weggesichert. Anschließend habe ich mir gedacht ich entferne mal alle Platten aus der VM und binde diese wieder neu ein. Das hab ich leider auch gemacht und jetzt bootet das System nicht mehr, er versucht ständig vom Netz zu booten, das sieht so aus als würde der keine bootbare Festplatte finden.

Was kann ich jetzt machen? Bitte nicht gleich steinigen ich weiß, dass das mit dem entfernen und neu einbinden nicht gerade die beste Idee war.

Ich danke euch Newbie2007

[irix]

Gebraucht wird ein ls -alh vom Inhalt des Verzeichnisses, die VMX und die kleinen VMDKs und sofern vorhanden die VMSD. Das ganze direkt aus dem VMFS und nicht ueber den Datastorebrowser.

Sollte aber aus dem anderen Thread ersichtlich gewesen sein.

Gruss
Joerg

[newbie2007]

Ich habe nur Bahnhof verstanden Es wäre voll nett wenn du mir das ganze schritt für schritt erklären könntest. Ich habe bei den Einstellungen der VM die Festplatten entfernt und dann wieder alle hinzugefügt. Ich habe nicht diese VM auf einen anderen Datastore gelegt sondern alle anderen und jetzt sind die symthome wie in meinem letzten Beitrag. Sprich VM versucht ständig einen PXE Boot.

Ich danke für die Geduld. Newbie2007

[irix]

Wir moechten den Inhalt des VM Verzeichnisses aus dem Datastore deines ESXi Servers sehen. Also ein simples Listing wo man erkennen kann was noch vorhanden ist und wie Gross die Dateien sind. Unter Windows waere es ein "dir" und unter Unix/Linux ein "ls -alh" Befehl.

Das andere ist der Inhalt von den Konfigurationsdateien. Hinter der *.vmx verbirgt sich die Konfig der VM und die kleinen *.vmdk sind die Descriptoren der Festplatten und last but not least is da die *.vmsd ist Stand der Snapshots welche dem VIC praesentiert werden.

Wenn du nicht weis wir man an die Infos kommt dann erfrage das gezielt oder besser mache dich selber Schlau. Dein ESXi hat einen "Techmode" welche geoeffnet werden kann und so das du auf der Busybox in das Verzeichnis /vmfs/volumes/..../vmname/ wechseln kannst. Da wir aber die Infos braucht macht es Sinn kurzzeitig den SSH auf deinem ESXi zu aktivierren so das du mit Putty/WinSCP von deinem Windowsrechner aus die Infos ermitteln und uebertragen kannst.

Gruss
Joerg

[continuum]

Joerg - ich glaube wir sollten mal einen sticky-post mit dem Titel:

Wie geht man mit Notfaellen um

zusammenstellen

[irix]

Joerg - ich glaube wir sollten mal einen sticky-post mit dem Titel:

Wie geht man mit Notfaellen um

zusammenstellen

Das geht doch fix... du must nur deine Telefonnummer dort hinterlegen

Mal im Ernst... ich vermisse hier was Wiki/FAQ Artiges was man im Laufe der Zeit aendern und ergaenzen kann. Ein Forum so wie dieses in nur bedingt dazu geeignet. Ich war viele Jahre in d.c.l.p sowie (PHP)Mailinglisten aktiv und mit den Anworten aus der FAQ[1],welche immer als Link gegen wurde, konnte man eine Vielzahl von Anfragen schnell und vor allen Dingen detailiert beantworten.

Gruss
Joerg

[1] http://www.php-faq.de

[e-e-e]

Hallo,

wahrscheinlich wird wohl hier ein Wiki wegen des desertierten Admins nicht möglich sein, aber ein Link zu einem externem Wiki wird doch einrichtbar sein. Ansonsten gibt's doch FAQs, die man eventuell um fachliche bzw. themenbezogene Fragen erweitern kann.

[Dayworker]

Da wir uns hier immer weiter vom Thread-Thema entfernen, hab ich unter Sollten wir ein Wiki oder FAQ für häufige Fragen aufstellen? mal einen neuen Thread im Bereich "Feedback & Smalltalk" aufgemacht.

[newbie2007]

Hallo ich habe jetzt wieder einen Teil hinbekommen, das System startet wieder. Das Problem war, dass ich die Festplatten in falsvher Reihenfolge eingebunden habe.
Jetzt habe ich das Problem, dass ich einen Stand in der VM vom letzten Snapshot habe.

Ich habe auch ganz komische files im Ordner. Hier mal ein ls -lah von der VM.

Code: Alles auswählen

drwxr-xr-x    1 root     root         5.2k Sep 18 18:54 .
drwxr-xr-t    1 root     root         1.1k Sep 18 05:46 ..
-rw-------    1 root     root         4.5G Sep 14 16:29 MSHOGHE01-02-000001-delta.vmdk
-rw-------    1 root     root          312 Sep 14 16:28 MSHOGHE01-02-000001.vmdk
-rw-------    1 root     root       960.1M Apr 20 03:34 MSHOGHE01-02-000002-delta.vmdk
-rw-------    1 root     root          312 Apr 19 18:21 MSHOGHE01-02-000002.vmdk
-rw-------    1 root     root       208.1M Apr 19 16:40 MSHOGHE01-02-000003-delta.vmdk
-rw-------    1 root     root          305 Apr 19 18:21 MSHOGHE01-02-000003.vmdk
-rw-------    1 root     root         4.0G Apr 16 12:26 MSHOGHE01-02-Snapshot2.vmsn
-rw-------    1 root     root         4.0G Apr 19 16:45 MSHOGHE01-02-Snapshot3.vmsn
-rw-------    1 root     root         4.0G Apr 20 03:41 MSHOGHE01-02-Snapshot4.vmsn
-rw-------    1 root     root        40.0G Sep 18 18:54 MSHOGHE01-02-flat.vmdk
-rw-------    1 root     root         8.5k Sep 18 18:54 MSHOGHE01-02.nvram
-rw-------    1 root     root          451 Sep 18 18:05 MSHOGHE01-02.vmdk
-rw-------    1 root     root         1.7k Apr 20 03:34 MSHOGHE01-02.vmsd
-rwxr-xr-x    1 root     root         2.7k Sep 18 18:58 MSHOGHE01-02.vmx
-rw-------    1 root     root          267 Sep 18 18:58 MSHOGHE01-02.vmxf
-rw-------    1 root     root        32.0k Apr 20 03:34 MSHOGHE01-02_1-000001-delta.vmdk
-rw-------    1 root     root          316 Apr 20 03:34 MSHOGHE01-02_1-000001.vmdk
-rw-------    1 root     root        32.0k Apr 19 16:40 MSHOGHE01-02_1-000002-delta.vmdk
-rw-------    1 root     root          316 Apr 19 16:40 MSHOGHE01-02_1-000002.vmdk
-rw-------    1 root     root        16.0M Apr 19 16:40 MSHOGHE01-02_1-000003-delta.vmdk
-rw-------    1 root     root          309 Apr 19 18:21 MSHOGHE01-02_1-000003.vmdk
-rw-------    1 root     root        15.0G Sep 14 16:23 MSHOGHE01-02_1-flat.vmdk
-rw-------    1 root     root          453 Sep 14 16:23 MSHOGHE01-02_1.vmdk
-rw-------    1 root     root       144.1M Apr 19 18:01 MSHOGHE01-02_2-000001-delta.vmdk
-rw-------    1 root     root          309 Apr 19 16:48 MSHOGHE01-02_2-000001.vmdk
-rw-------    1 root     root         9.3G Sep 14 16:38 MSHOGHE01-02_2-000002-delta.vmdk
-rw-------    1 root     root          316 Sep 14 16:17 MSHOGHE01-02_2-000002.vmdk
-rw-------    1 root     root        30.0G Sep 18 18:54 MSHOGHE01-02_2-flat.vmdk
-rw-------    1 root     root          453 Sep 18 18:06 MSHOGHE01-02_2.vmdk
-rw-r--r--    1 root     root        17.1k Sep 15 17:56 vmware-29.log
-rw-r--r--    1 root     root        38.7k Sep 18 05:47 vmware-30.log
-rw-r--r--    1 root     root        38.3k Sep 18 06:01 vmware-31.log
-rw-r--r--    1 root     root            0 Sep 18 06:15 vmware-32.log
-rw-r--r--    1 root     root        38.2k Sep 18 07:35 vmware-33.log
-rw-r--r--    1 root     root       117.8k Sep 18 09:48 vmware-34.log
-rw-r--r--    1 root     root       211.0k Sep 18 18:54 vmware.log


Könnt Ihr mir sagen was da noch falsch ist?

danke newbie2007[/code]

[Dayworker]

Dir ist aber schon klar, daß hier keine Anhänge mehr gehen. Den Grund dafür und einen Ausweg findest du doch ganz einfach in meiner Signatur.

[irix]

Newbie,
es fehlen noch Infos. Was man aber sehen kann das deine VM 3 Festplatten hat und alle haben Snapsshots. Allerdings ist die 3. Platte spaeter hinzugekommen. Um zusehen ob die Snapshotkette Intakt ist fehlen aber noch die anderen Infos.

Gruss
Joerg

[continuum]

Ich habe auch ganz komische files im Ordner.

Nein - hast du nicht - das ist alles ganz normal.
Newbie - die VM in diesem Moment zu starten ist contra-produktiv.

Bitte sofort runterfahren - kein checkdisk oder defrag ausfuehren.
Im Zweifelsfall hart abschalten.

Wir brauchen noch folgende files:

MSHOGHE01-02-000001.vmdk
MSHOGHE01-02-000002.vmdk
MSHOGHE01-02-000003.vmdk
MSHOGHE01-02.vmdk
MSHOGHE01-02.vmsd
MSHOGHE01-02.vmx
MSHOGHE01-02_1-000001.vmdk
MSHOGHE01-02_1-000002.vmdk
MSHOGHE01-02_1-000003.vmdk
MSHOGHE01-02_1.vmdk
MSHOGHE01-02_2-000001.vmdk
MSHOGHE01-02_2-000002.vmdk
MSHOGHE01-02_2.vmdk

am besten gezippt alle zusammen

[newbie2007]

GuMo,
ich habe jetzt die von euch geforderten Infos auf einen Server gestellt. Leider muß man beim Download 60 sec. warten ich hoffe das stört euch nicht.

http://uploading.com/files/fa4ca6fa/upload.zip/upload.zip

Ich danke euch allen für eure Geduld.

Newbie2007

[Dayworker]

Das ist aber reichlich Wartezeit...

[newbie2007]

Hi
was meinst du mit lange Wartezeit?

[Dayworker]

Für ganze 6KByte an Daten muß man volle 60sec warten und dazu wird man auch noch mit Pop-Up's bombadiert...

[newbie2007]

Hi,
ja das stimmt aber der Hoster, den du in deiner Signatur eingetragen hast, bei dem müßen die Files mindestens 9 Kb groß sein, sonst sagt er immer filesize to small.

Zu meiner ursprünglichen Sache, ich habe die VM wieder hergestellt, doch leider ist das System und auch die Daten nicht wie vor dem Absturz. Kann mir jemand helfen, da das System morgen früh wieder funktionieren sollte hab ich es schon ein bischen eilig.

Ich danke euch nochmals, Newbie2007

[Dayworker]

Also ich hab das jetzt nach 5min aufgegeben. Wenn man auf kostenlos klickt, wird man auf http://pc.de weitergeleitet und wenn man stumpf die Zeit auf der Downloadseite verweilt, passiert garnix.
Wenn du zu kleine Dateien hast, zippe die bitte einfach ohne Kompression und damit solltest du immer über das Minimum von 9 KByte kommen.

[irix]

Die VMX verweist direkt auf die Basis VMDKs und somit ist es klar das nun Daten fehlen da dies der Stand ist an dem der ersten Snapshot gemacht wurde. Die MSHOGHE01-02-000003.vmdk verweist komischer Weise auf die MSHOGHE01-02.vmdk aber die ParentCID stimmt nicht. Ausserdem fehlen dann die 2 anderen Snaps in der Kette.

@Ulli
Wenn er die Baisis VMDK jetzt wieder in Benutzung hat kann dann ein Commit der Snaps, sofern man sie wieder in die richtige Reihenfolge bekommt ueberhaupt noch funktionieren?

Gruss
Joerg

[Dayworker]

Wenn er die Baisis VMDK jetzt wieder in Benutzung hat kann dann ein Commit der Snaps, sofern man sie wieder in die richtige Reihenfolge bekommt ueberhaupt noch funktionieren?

Für mein Verständnis enthalten die Delta's nur die geänderten Schreibzugriffe, der Rest wird nach abklappern aller vorherigen Snapshots und dann aus der ursprünglichen v.Disk gelesen. Wenn er also die Basis-Disk durch Neustart ändert, stimmen die Änderungen im Delta damit nicht mehr überein. In meinen Augen hätte er damit ohne ein Backup auch jede Chance auf vollständige Wiederherstellung verspielt.

[newbie2007]

Hi irix,
hab ich jetzt noch eine chance, dass ich das wieder so hinbekomme, wie es am Absturztag war? Wie ist das zustande gekommen?
Mir ist nämlich auch jetzt nach dem Zwischfall aufgefallen, das genau bei diesem Server die Sicherung nicht funktioniert hat!!!!!!!!!!!!

Ich danke dir sehr herzlich für Geduld.
Newbie2007

[continuum]

Wenn er die Baisis VMDK jetzt wieder in Benutzung hat kann dann ein Commit der Snaps, sofern man sie wieder in die richtige Reihenfolge bekommt ueberhaupt noch funktionieren?

Ja - wenn man die VM zuegig wierder runterfaehrt nach dem man den fehler erkannt hat.

Wenn man allerdings Dummheiten wie checkdisk oder defrag macht - verscherzt man sich das im Handumdrehen.

Deswegen steht ja auch bei mir auf der vm-sickbay Seite:

1. keine Panik
.und kurz danach schon: VM nicht anderweitig mounten

Wie sieht es denn im Moment aus - arbeitet irgendwer an der sache ?