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!
beschädigte VM renovieren div. Methoden testen (Testsystem)
beschädigte VM renovieren div. Methoden testen (Testsystem)
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
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
-
weigeltchen
- Member
- Beiträge: 359
- Registriert: 28.11.2011, 09:46
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
-
Dayworker
- King of the Hill
- Beiträge: 13658
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
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.
Code: Alles auswählen
vmkfstools -i /pfad/zur/vmdk/alte.vmdk /pfad/zur/vmdk/neue.vmdkCode: Alles auswählen
vmkfstools -i /pfad/zur/vmdk/alte.vmdk -d thin /pfad/zur/vmdk/neue.vmdkAnschließ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.vmdkDie 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......oder Thin...Code: Alles auswählen
vmkfstools -i /pfad/zur/vmdk/alte.vmdk /pfad/zur/vmdk/neue.vmdkCode: 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
-
Dayworker
- King of the Hill
- Beiträge: 13658
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
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:
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:
Code: Alles auswählen
Snapshot --locatesector @"Z:\Pfad\zu\BadSectors.txt"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
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
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
-
Dayworker
- King of the Hill
- Beiträge: 13658
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
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.
Code: Alles auswählen
Snapshot --locatesector @"Z:\Pfad\zu\BadSectorsC.txt"Ich würde trotzdem mal nach Continuums Weg vorgehen und es damit durchspielen.
Zurück zu „vSphere 5 / ESXi 5 und 5.1“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 6 Gäste
