VMware-Forum

Hallo, wir haben hier ein Problem mit einer virtuellen Maschine.

Das Acronis Backup ist fehlgeschlagen. (Backup for Vmware)

Folgende Fehlermeldung:

Nachricht: Erwarteter Task 'EstimateStoragesForConsolidation' fehlgeschlagen. Ursache: A general system error occurred: Failed to query the space requirement: A required file was not found.

Außerdem ist uns aufgefallen, dass im Verzeichnis der VM weitere VMDKs erzeugt wurden. Eine davon wächst, bzw. ist laut VMX die aktuelle Festplatte.

Hier noch ein Screenshot vom Vsphere Client:


Kann uns jemand bei der Lösung helfen?

jo es gibt 2 snapshots, versuchen platz zumachen und die snaps löschen, danach die Konsolidierung anwerfen, wenns möglich ist am besten wenn die vm aus ist

Stefan.r hat geschrieben:jo es gibt 2 snapshots, versuchen platz zumachen und die snaps löschen, danach die Konsolidierung anwerfen, wenns möglich ist am besten wenn die vm aus ist

Platz machen ist schon etwas schwierig, der Kunde hat noch ca. 12 GB auf dem Datastore frei...

Ich könnte die VM auf ein ISCSI Target verschieben auf dem noch genug Platz ist. Einer der Snapshots ist als Main HDD eingebunden und wird vom OS genutzt. Wenn ich den Snapshot lösche, sind die Daten dann noch alle vorhanden?

Snapshots beinhalten änderung zum vorhergehenden Snapshot, der letzte Snapshot ist in der Regel auch die aktuelle Festplattendatei, löschen solltest du die garnicht, was du machen könntest, wäre die Platte mit dem vmdk tools clonen(meinetwegen auf das Iscci drive), dann solltest du(in der Theorie) wieder eine vmdk haben

"Snapshot löschen" ist aber nun schon einmal die Terminologie, die im (Web) Client verwendet wird, und insofern nicht komplett falsch...

Nur die Dateien direkt auf dem Datentraeger sollte man in der Tat nicht einfach entfernen.

12GB freier Bereich koennten durchaus zum Konsolidieren ausreichen. Wird das im heruntergefahrenen Zustand der VM (nach fast 1 Jahr Laufzeit schadet das vmtl. auch nicht) durchgefuehrt, stehen sogar noch ca. 10GB mehr zur Verfuegung, weil die Swap-Dateien dann entfernt sind.

Das mit dem Klonen per vmkfstools braucht's erst dann, wenn "Konsolidieren" und "Alle löschen" nicht schon helfen sollte.

Wäre der Vmware Converter auch geeignet um die Maschine zu "reparieren"?

Tja, wenn man zuviel Zeit und Plattenplatz hat, dann moeglicherweise schon...

Waer' mir persoenlich aber einfach zu unabwaegbar vom Ergebnis her.

Der Converter ist bekanntermaßen nicht der Schnellste und daher würde ich diesen nur als Letztes nutzen. Mir stellt sich auch die Frage, weshalb ihr einen Snapshot nun schon seit Februar 2015 mit rumschleppt. Snapshots waren, sind und werden niemals ein Backup sein. Sie sind im Grunde nur Mittel zum Zwecke eines Backups oder kommen bei besonderen Configs wie Linked-Clones zum Zuge.

Werden dir den im C#- oder Web-Client noch beide Snapshots angezeigt?
Ja, dann such dir einen sehr ruhigen Zeitpunkt mit möglichst wenig Betrieb auf dem Storage und nutze die Schaltfläche "Alle Löschen" bei abgeschalteter VM. Beim Einpflegen des oder der Snapshots wird das Storage maximal gefordert, da bleiben ohne Begrenzung durch das Storage nicht mehr viele IOs für andere auf dem Storage laufende VMs übrig. Je grösser ein Snapshot ist, desto länger dauert auch das "Einpflegen" in die Basis-vDISK.

Werden dir den im C#- oder Web-Client noch beide Snapshots angezeigt?

Das ist die entscheidende Frage.
Wenn ja würde ich folgendes empfehlen: per GUI zuerst Snapshot 000002.vmdk löschen.
Dann einen neuen Snapshot erstellen und anschliessend wieder per GUI Snapshot 000001.vmdk löschen. Das wird eine Weile dauern.
Wenn das ganze durch ist, kann auch der neu erstellte Snapshot gelöscht werden.

Ohne dem Meister hier zu sehr widersprechen zu wollen, aber:

Wie soll man aus dem GUI (Snapshot-Manager) herauslesen, welcher der (moeglicherweise) beiden angezeigten Snapshots der -000001 und welcher der -000002 ist?

Schau' ich gleich morgen mal genauer nach. Aber ich meine mich zu erinnern, dass das nicht explizit angezeigt wird.

Da die Zeitstempel des -000002 wesentlich aelter als die vom -000001 sind, koennte ich mir vorstellen dass hier auch der Grund fuer die Verwirrung vom Acronis herkommt. Moeglicherweise sind die irgendwann mal "uebrig" geblieben...

Das ENDE der Snapshotkette ist ja jeweils die Datei, die momentan im GUI bei den VM-Einstellungen angezeigt wird. Und da wuerde ich eher auf die -000001er tippen.

Um also GANZ sicher gehen zu koennen, braeuchte man vmtl.
- das aktuelle vmware.log und wohl auch vmware-9.log
- alle KLEINEN vmdk-Dateien (aus der Kommandozeile oder WinSCP, und keinesfalls [!] aus dem Datastore Browser)
- Dateilisting von der Kommandozeile

Und das alles bitte ohne Verfaelschungen.
Meine persoenliche Ansicht ist: Wer meint, geheime Daten zu verarbeiten, der (oder die) sollte fuer den Support auch bei Leuten bezahlen, zu denen er (oder sie) Vertrauen hat.

Acronis hat doch eine Meldung hinterlassen und den meiner Ansicht nach entscheidenden Part habe ich markiert:

Nachricht: Erwarteter Task 'EstimateStoragesForConsolidation' fehlgeschlagen. Ursache: A general system error occurred: Failed to query the space requirement: A required file was not found.

Das am Ende eine Datei nicht gefunden wurde, ist ein Folgefehler, weil der freie Speicherplatz nicht ausreichte.

Wie soll man aus dem GUI (Snapshot-Manager) herauslesen, welcher der (moeglicherweise) beiden angezeigten Snapshots der -000001 und welcher der -000002 ist?

Du hast Recht - das GUI zeigz das leider nicht an.
In diesem Fall aber kein Problem da der ältere Snapshot die 000002.vmdk verwendet und der neuere die 000001.vmdk. (Ergibt sich aus den Datum der vmdks)
Ansonsten muss man diese Infos aus der vmsd manuell auslesen.

Da die Zeitstempel des -000002 wesentlich aelter als die vom -000001 sind, koennte ich mir vorstellen dass hier auch der Grund fuer die Verwirrung vom Acronis herkommt. Moeglicherweise sind die irgendwann mal "uebrig" geblieben...

Das sollte aber ein Backuptool nicht durcheinander bringen.
Ich tippe eher darauf dass die vmsd ungültig oder leer ist. Dann würde das Backuptool die nächste freie Nummer nehmen. Nach *-000001.vmdk also *-000002.vmdk. Die ist aber schon vorhanden und das ergibt dann den Fehler.
Bei gültiger vmsd-Datei würde diese ausgelesen und anhand dieser Daten wäre der nächste Snapshot mit 000003.vmdk gebildet worden.