VMware-Forum

Hallo,

ich habe hier eine VM (Win7) die noch läuft, die ich aber nicht verschieben kann.
Offenbar gibt es eine beschädigte Snapshot-Datei die beim kopieren auf ESX-Hostebene blockiert.
Da es sich um ein Testsystem handelt nutze ich die Gelegenheit mal diverse Rettungsszenarien zu testen ohne direkt in irgendwelchen Systemfiles zu editieren etc.
Ziel ist es für Gelegenheitsuser wie meine Azubis einen gangbaren Weg aufzuzeigen der ihnen nicht sofort Schweiss auf die Stirn zaubert.

1)
kopieren mit Trilead sowohl lokal als auch auf einen PC schlägt fehl.
2)
vmware Converter bricht ab
3)
cp aus ESX Host direkt bricht ab
4)
booten von Acronis CD mit Disc-Copy auf eine zusätzliche virtuelle Platte schlägt fehl wobei mir der Effekt nicht ganz klar ist. Der Windows-Gast selber funktioniert ja noch und bootet sauber durch.

Ich werde weiter berichten:
Gruss

Wäre es nicht hilfreicher, zu wissen, ob es tatsächlich an einem Snapshot liegt? Ist die VM mal irgendwann migriert worden? Möglicherweise läuft da noch ein Prozeß, der eine Datei festhält.

weigeltchen hat geschrieben:Wäre es nicht hilfreicher, zu wissen, ob es tatsächlich an einem Snapshot liegt? Ist die VM mal irgendwann migriert worden? Möglicherweise läuft da noch ein Prozeß, der eine Datei festhält.

Der Host wurde komplett neu gestartet.
Mit geht es im Moment eher darum Tools/ Verfahren zu finden die von wenig geschulten Anwendern in Notfall auch noch genutzt werden können.

Gruss

Den Snapshot wirst du nicht mehr retten können. Ich würde einen Fullclone der VMDK machen und nach erfolgreichem Reboot mit der neuen VMDK die alte VMDK wegwerfen. Man muß sich dann nur noch entscheiden ob Thick... ...oder Thin...
Anschließend muß man dann entweder die VMX-Datei auf den neuen VMDK-Namen ändern oder die neue VMDK wieder umbenennen:


Die andere Möglichkeit wäre, in der VM ein Backup oder Image zu ziehen und den Inhalt dann in eine neue VMDK restaurieren.

Dayworker hat geschrieben:Den Snapshot wirst du nicht mehr retten können. Ich würde einen Fullclone der VMDK machen und nach erfolgreichem Reboot mit der neuen VMDK die alte VMDK wegwerfen. Man muß sich dann nur noch entscheiden ob Thick...

Code: Alles auswählen

vmkfstools -i /pfad/zur/vmdk/alte.vmdk /pfad/zur/vmdk/neue.vmdk

...oder Thin...

Code: Alles auswählen

vmkfstools -i /pfad/zur/vmdk/alte.vmdk -d thin /pfad/zur/vmdk/neue.vmdk

Anschließend muß man dann entweder die VMX-Datei auf den neuen VMDK-Namen ändern oder die neue VMDK wieder umbenennen:

Code: Alles auswählen

vmkfstools -E NeuerName.vmdk AlterName.vmdk

Die andere Möglichkeit wäre, in der VM ein Backup oder Image zu ziehen und den Inhalt dann in eine neue VMDK restaurieren.

Hallo,

letzteres spiele ich gerade durch wobei Acronis schon gescheitert ist.
Ersteres werde ich danach testen und für den Notfall in meinem "Werkzeugkasten" ablegen.
Ausserdem würde mich noch interesssieren was die ESX Rettungs-CD hier aus dem Forum dazu sagt. Aber dazu brauche ich ein Zeitfenster das ich im Moment nicht habe.

Gruss

Welche Meldung liefert dir Acronis?
Teste mal Drivesnapshot. Falls das auch defekte Sektoren findet, wird dir eine BadSectors-Datei angelegt und du kannst dann testen, ob und welche Dateien ggf beschädigt sind. Die Syntax dafür lautet:

Dayworker hat geschrieben:Welche Meldung liefert dir Acronis?

Zugriffsfehler bei einem Sektor, unter normalen Umständen würde ich einen Hardwaredefekt vermuten.
http://www.minitool-drivecopy.com/download.html ist durchgelaufen.
Mal morgen weiter schauen. 11 Stunden am Tag sind genug.

Gruss

Wie, ohne Fehlermeldung und das bei einem nachweislichen Fehler?
Dann würde ich diesem Tool nicht trauen. Wer weiß, was dieses noch alles verschweigt.

Wie gesagt, probier mal Drivesnapshot aus. Damit kannst du wenigstens überprüfen, ob der betreffende Sektor überhaupt Daten enthält.

Dayworker hat geschrieben:Wie, ohne Fehlermeldung und das bei einem nachweislichen Fehler?
Dann würde ich diesem Tool nicht trauen. Wer weiß, was dieses noch alles verschweigt.

Wie gesagt, probier mal Drivesnapshot aus. Damit kannst du wenigstens überprüfen, ob der betreffende Sektor überhaupt Daten enthält.

Drive snapshot meldet 21 bad sectors.
Ich lege diese Sicherung jetzt mal in die Ecke und schau mal ob ich die virtuelle Platte repariert bekomme.
Wie gesagt: Testsystem und alles ganz entspannt

Gruss

rprengel hat geschrieben:

Dayworker hat geschrieben:Wie, ohne Fehlermeldung und das bei einem nachweislichen Fehler?
Dann würde ich diesem Tool nicht trauen. Wer weiß, was dieses noch alles verschweigt.

Wie gesagt, probier mal Drivesnapshot aus. Damit kannst du wenigstens überprüfen, ob der betreffende Sektor überhaupt Daten enthält.

Drive snapshot meldet 21 bad sectors.
Ich lege diese Sicherung jetzt mal in die Ecke und schau mal ob ich die virtuelle Platte repariert bekomme.
Wie gesagt: Testsystem und alles ganz entspannt

Gruss

drivesnapshot hat das System sauber in eine frische neue Win7 Installation zurück kopiert.
Die Fehler konnte das Tool offenbar kompensieren.

Gruss

Bei der Ausgangslage:
vmkfstools -i bricht mit I/O error ab
Host wurde schon neugestartet

mache ich als nächstes folgendes:
mit Linux booten - VMFS-volume mit vmfs-fuse mounten - flat.vmdk mit gddrescue kopieren

geht das auch nicht - dann sind massivere Mittel gefragt.

continuum hat geschrieben:Bei der Ausgangslage:
vmkfstools -i bricht mit I/O error ab
Host wurde schon neugestartet

mache ich als nächstes folgendes:
mit Linux booten - VMFS-volume mit vmfs-fuse mounten - flat.vmdk mit gddrescue kopieren

geht das auch nicht - dann sind massivere Mittel gefragt.

Hallo,

wie gerade geschrieben hat drivesnapshot das problem erledigt.
Das wäre auch noch ein Vorgehen das meine Azubis hin bekommen wenn wir eine boot-Cd fertig haben.
Das Teil gefällt mir richtigt gut: Einfach und effektiv, da wissen Leute was sie tun.

Gruss

Wenn du die VM fehlerfrei restaurieren konntest, dürften die defekten Sektoren unbelegt gewesen sein. Wie bereits früher schon geschrieben, kannst du Drivesnapshot mit folgendem Parameter laufen lassen und das Tool zeigt dir ggf defekte Dateien bzw Verzeichnisse direkt an:


Ich würde trotzdem mal nach Continuums Weg vorgehen und es damit durchspielen.