VM fährt nicht mehr hoch...

[thor_pfosten]

Hi,

habe da ein dringendes Problem... hoffe ihr seid gewillt mir da nochmal zu helfen.

Eine VM auf meinem ESXi Host fährt nicht mehr hoch. Ich komme nur noch ins rescue grub (siehe Attachment).
[

Da kann ich mir mit ls die Partitionen ansehen. Die Root partition fd0 scheint beschädigt.
Gibt es da eine Möglichkeit das Ding wieder flott zu kriegen ?
...Brauche da dringend Hilfe!

Vielen Dank!

VG

Thor

[JustMe]

Sorry, aber bei diesem Bild ist der Virtualisierungsunterbau ziemlich raus.
Die VM an sich startet, es wird sogar was von irgendwo her gestartet (naemlich grub).

fd0 als root-Partition halte ich fuer eine ziemlich gewagte These, denn fd steht bei Linux fuer Floppy Disk. Und die duerfte in der VM-Konfiguration leer sein, was den Fehler beim Lesen erklaert.

Das Einzige, was auf ESXi-Seite in diesem Stand noch geprueft werden koennte, ist dann halt die Konfiguration der VM:
- sind alle erwarteten VMDKs noch da, und an den richtigen Stellen (Typ SCSI/IDE/nVME/...) angebunden
- sind alle VM-Dateien sauber im Zugriff (je nach Platz mal versuchen, die woanders hin zu kopieren [bei ausgeschalteter VM])
- was wurde vielleicht gerade vorher (oder seit dem letzten Boot der VM) alles geaendert
- ...

Alles Weitere muss dann auf Linux-Seite wie bei einem physischen System weiter analysiert (und korrigiert) werden.

Aber vielleicht findet sich ja auch hier jemand mit entsprechendem Linux-KnoffHoff. Was nicht ganz auszuschliessen ist...

[rprengel]

Hi,

habe da ein dringendes Problem... hoffe ihr seid gewillt mir da nochmal zu helfen.

Eine VM auf meinem ESXi Host fährt nicht mehr hoch. Ich komme nur noch ins rescue grub (siehe Attachment).
[IMG_20201016_095452_resized_20201016_095644654.jpg
Da kann ich mir mit ls die Partitionen ansehen. Die Root partition fd0 scheint beschädigt.
Gibt es da eine Möglichkeit das Ding wieder flott zu kriegen ?
...Brauche da dringend Hilfe!

Vielen Dank!

VG

Thor

Das ist kein Vmware Thema aber lade dir eine Live Cd des Linux das da laufen soll, starte die Cd und prüfe ob du die Platte noch mounten kannst.
Kommst du dann noch deine Daten wird nir der Bootloader defekt sein; siehts du keine Daten wird es vermutlich Zeit für ein Backup.
Ggf. hilft auf supergrub2 disk weiter.
Gruß
Ralf

[thor_pfosten]

Hallo,

und vielen Dank für die Hilfe ...
... we vielleicht schon deutlich handelt es sich im ESXi 5.5.

Da liegt noch eine weitere VM auf dem Host könnte man evtl. eine Disk von einer VM zur nächsten übertragen. Geht das im GUI ? Oder könnte auf der Shell schlicht ein VDMK - File umkopieren ?

Vielen Dank!
Thor

[JustMe]

Die ESXi-Version ist irrelevant, da es ja kein Virtualisierungsproblem ist

Ja, man kann einfach eine VMDK an eine andere VM haengen, auch im GUI ("vorhandene Festplatte hinzufügen").
ACHTUNG!
Dabei ist UNBEDINGT auf eventuelle Snapshots zu achten! (die im GUI [Datastore Browser] nicht immer sauber angezeigt werden...)
ACHTUNG!

Beim Kopieren muss man eben darauf achten, dass die richtigen (vmdk-)Dateien kopiert werden.

[thor_pfosten]

ok danke ....
...snapshots gibt es da derzeit keine.
Kann einer grad sagen, wie man die Platte von einer VM zur nächsten überträgt ?
...sehe da grad keine Optionen.

[rprengel]

ok danke ....
...snapshots gibt es da derzeit keine.
Kann einer grad sagen, wie man die Platte von einer VM zur nächsten überträgt ?
...sehe da grad keine Optionen.

Plattendatei kopieren und in der Ziel-VM als neue Platte basierend auf vorhandenef Datei einbinden.
auf der Konsole einfach mit cp arbeiten.
Der Dialog dazu ist eindeutig.
Grus

[thor_pfosten]

ok ... das Einbinden habe ich gefunden...
aber muß man es vorher nicht auf der ursprünglichen VM freigeben ?

[JustMe]

Nein, muss man nicht.
Sobald die "abgebende" VM heruntergefahren ist, kann auf die vmdk zugegriffen werden.

[thor_pfosten]

Wenn ich die Platte über "Entfernen" von der VM entfernen will erhalten ich folgende Fehlermeldung:

vm_issue.PNG (4.1 KiB) 6665 mal betrachtet

...Könnt ihr grad helfen ?

[thor_pfosten]

ok ... versuche es grad nochmal nach rprengel

[JustMe]

Tu, was Du nicht lassen kannst.

Aber irgendwie steht der Text der Fehlermeldung in krassem Gegensatz zu Deinen vorherigen Aussagen
Fehlermeldung:
weil sie oder eine der übergeordneten Festplatten Teil von einem Snapshot der virtuellen Maschine ist
Quote thor_pfosten:
snapshots gibt es da derzeit keine

Also schreib' hinterher nicht, wir haetten Dich nicht gewarnt

[Dayworker]

"fd0" ist mit Hintergrund auf Grub-Rescue kein Floppy. Welches Linux läuft in der VM?
Ich würde die VMDK zuerst Clonen und dann wie bereits vorgeschlagen von einer Live-CD derselben Distribution booten. Per "chroot" kannst du dann das System wieder in einen bootfähigen Zustand bringen.

[thor_pfosten]

Hallo "Justme" ... das war ein Fehler meinerseits. Ich weß grad nicht wo mir der Kopf steht.
Du hast vollkommen recht.

Ich würde jetzt gerne vmdk - Files verschieben auf der Shell und zwar von einem VM - Folder zum anderen.
Im GUI kann ich die Filenames sehen:

Festplatte 1
[Data2-Raid10-1.2Tx4-sas] Production Server/Production Server-000002.vmdk


Festplatte 2
[Data2-Raid10-1.2Tx4-sas] Production Server/Production Server_1-000002.vmdk

Im Folder von Production server steht das folgende:





Reicht es, wenn ich nur die Files ( eben Production Server-000002.vmdk und Production Server_1-000002.vmdk)
laut GUI rüberkopiere (in dem Folder der anderen VM) ? Oder ist das evtl. gefährlich ?

Danke für eure Hilfe !

[JustMe]

NEIEN, AUF GAR KEINEN FALL! (sorry fuer das Schreien)

Die -00002*-Dateien enthalten nur die Aenderungen gegenueber den -00001*-Dateien, welche wiederum nur die Aenderungen gegenueber den -flat.vmdk enthalten.

Ausreichend freien Platz vorausgesetzt, solltest Du stattdessen auf der Kommandozeile im Verzeichnis von "Production Server" versuchen:

Code: Alles auswählen

grep -i vmdk *.vmx


Damit pruefst Du zuerst, ob die -00002.vmdk tatsaechlich das Ende der Snapshotkette darstellen. Erst wenn das bestaetigt werden kann, folgt mit

Code: Alles auswählen

vmkfstools -i Production\ Server-00002.vmdk /vmfs/volumes/irgendwoandersmitgenugPlatz/PS.vmdk
vmkfstools -i Production\ Server_1-00002.vmdk /vmfs/volumes/irgendwoandersmitgenugPlatz/PS_1.vmdk


ein Klonen der Platten von "Production Server" (ich hasse es, wenn Leute Leerzeichen in solchen Namen verwenden, weswegen es sein kann, dass Du noch Anfuehrungszeichen setzen musst; sicherheitshalber kannst Du die Tab-Vervollstaendigung verwenden) an den Zielort. Dabei werden gleich die Snapshot-Fragmente in die beiden Zielplatten PS.vmdk und PS_1.vmdk eingearbeitet. Diese PS.vmdk und PS_1.vmdk kannst Du dann an das Ziel anhaengen.

PS:
Irgendwie scheinen die Bilder in Deinem letzten Post durcheinandergeraten zu sein...

[thor_pfosten]

Hallo Justme,

Danke für deine Hinweise. Es ist noch nix passiert

Code: Alles auswählen

grep -i vmdk *.vmx


liefert

Code: Alles auswählen

er-000002.vmdk"
er_1-000002.vmdk"
er_4.vmdk"


demnach ist -000002 nicht das Ende der Snapshotkette.

[JustMe]

Jetzt fehlt der linke Teil der Zeilen...

Eigentlich ist -00002.vmdk schon das Ende.
Die *_4.vmdk kann ein Rest von einer frueher mal angehaengten vmdk-Platte sein.
Sicherheitshalber solltest Du mal die komplette "Production Server.vmx" hier posten. (Als Anhang, nicht als Text).

[thor_pfosten]

Hi Justme,

hier die vmx im Anhang:

[JustMe]

Hi thor_pfosten,

wie vermutet:

Code: Alles auswählen

scsi0:2.fileName = "Production Server_4.vmdk"
scsi0:2.present = "[color=#FF0000]FALSE[/color]"

(Ich muss gleich mal schauen, ob das FALSE tatsaechlich in der code-Umgebung auch rot dargestellt wird)
(OK, tut es nicht . Also weisen die verbleibenden color-Tags nur auf die Bedeutung des Wortes hin...)

Somit ist -000002 tatsaechlich der aktuelle Endpunkt der Datentraeger dieser VM, und die beiden vmkfstools-Befehle sollten, ausreichend Platz vorausgesetzt, ausgefuehrt werden koennen. Die tun tatsaechlich das, was auch Dayworker mit dem Vorschlag "clonen" zum Ausdruck brachte.

Ansonsten musst Du darauf achten, dass die -000002.vmdk-Dateien nur kleine Descriptor-Files sind. Die tatsaechlichen Inhaltsdaten liegen in den -delta.vmdk (und -flat.vmdk). Somit wuerde es Dir rein goarnuescht bringen, nur diese kleinen Dateien zu kopieren/verschieben.

[thor_pfosten]

OK ...
Erstmal recht herzlichen Dank für Deine Mühe.
Platz ist grad nicht genug da. Ich werde deshalb die VM mittels scp auf den VM Ordner auf einen anderen ESXi Host übertragen. Das hat schon mal geklappt.
Was mich aber stutzig macht , ist das Filesystem. Wenn Du dir die Grafik im allerersten Post von mir anguckst, dann steht da ext2. Das war aber immer ext4. Könntest Du Dir grad Hintergründe vorstellen ?
Vielen Dank nochmal!

VG

Thor

[JustMe]

Sicherung ist IMMER gut

Die ext2/ext4-Geschichte ist eigentlich auch wieder was fuer Linuxer. Das duerfte damit zusammenhaengen, dass beide Dateisysteme dieselbe ID verwenden, und ext4 mehr oder minder eine Weiterentwicklung von ext2 darstellt, und in gewissen Bereichen sogar kompatibel ist. Und der Rescue-GrUB hat eine andere (aber auch nicht unbedingt falsche) Interpretation der gefunden Daten als das installierte Debian.

Mich persoenlich macht viel stutziger, dass die delta-Datei zur zweiten Festplatten-vmdk groesser als die -flat-Datei ausgewiesen wird. Das sollte eigentlich nicht moeglich sein, koennte aber auch mit der Darstellung Deines Screenshots zusammenhaengen.

[rprengel]

OK ...
Erstmal recht herzlichen Dank für Deine Mühe.
Platz ist grad nicht genug da. Ich werde deshalb die VM mittels scp auf den VM Ordner auf einen anderen ESXi Host übertragen. Das hat schon mal geklappt.
Was mich aber stutzig macht , ist das Filesystem. Wenn Du dir die Grafik im allerersten Post von mir anguckst, dann steht da ext2. Das war aber immer ext4. Könntest Du Dir grad Hintergründe vorstellen ?
Vielen Dank nochmal!

VG

Thor

Noch mal.
boote von einer Live-CD (Knoppix) und schaue ob du die Platten. noch mounten kannst .
Wenn du dann keine Daten siehts ist die Platte hin.
Gruss

[Dayworker]

Kann es sein, daß dir der Platz ausgegangen ist und die VM dadurch beschädigt wurde?
Ich frage, weil deine VM mit 48GB vRAM ausgestattet ist und bei VM-Start eigentlich immer auch eine Datei gleicher Grösse angelegt wird. Arbeitet man dann noch mit Thin-VMDKs ohne vernünftige Überwachung des Speicherplatzes, kann das schief gehen.

[thor_pfosten]

Hi Dayworker,

guter Punkt....
Es war unterschiedlich viel Platz vorhanden. Ich hatte aber vor kurzem eine VM gelöscht, so dass ich mir eigentlich sicher bin, dass hinreichend Platz dagewesen sein muß. Kann man das evtl. recovern ? Hättest Du Vorschläge ?

In jedem Fall herzlichen Dank für den Hinweis!

VG

Thor

[Dayworker]

Wenn die gelöschte VM bzw deren VMDK(s) in keiner laufenden VM locked wurde(n) und du aus Platzgründen nicht manuell auf verschiedenen Datastores operiert hast, wird die auch wirklich gelöscht worden sein.
Interpretiere ich die Verzeichnisauflistung richtig, dann war zumindest Snapshots-Nr2 gut gefüllt und jeder Snapshot kann immer bis zur Größe der Basis-VMDK anwachsen. An VMDKs lese ich erstmal für Laufwerk_0 die ~55GB mit ~26GB im Snapshot2 und für Laufwerk_1 waren es ~41GB mit ~81GB im Snapshot2. Wenn ich keinen Rechenfehler gemacht habe, sind das mit den 48GB an vRAM zusammen ~251GB an Platzbedarf und selbst das ist dann noch ohne PCI-Adreßbereich sowie VGA-RAM dieser VM.

Kannst du bitte mal alle noch vorhandenen vmware.log-Dateien zippen und anhängen sowie ein richtiges Verzeichnislisting per "ls -ahls" plus den freien Platz per "vdf -h" posten.