VMware-Forum

Hallo Forum,

ich habe derzeit genau die Probleme wie in diesem Beitrag zu sehen: viewtopic.php?f=36&t=31853&hilit=clone

Ich bin nun bei dem Punkt, dass ich versuche die derzeit verwendete VMDK zu Klonen, das ganze geht auch bleibt aber bei 84% stehen.

Cloning disk '/vmfs/volumes/Intern/SRVNAME/SRVVM-000258.vmdk'...
Clone: 84% done.

Danach macht der nicht mehr weiter, ihr habe testweise Mal die geklonte VMDK eingebunden und gestartet, diese funktioniert soweit auch.
Das Ganze war aber nur bei einem Testserver, bevor ich mich an den DC, TS, FS ran wage wollte ich nochmal nachfragen was ihr dazu sagt?
Eventuell hat jemand von euch eine Idee weshalb der bei 84% nicht mehr weitermacht.


Viele Grüße und schönes Wochenende
Leroy

258 Snapshots? Wie viele aktive VMDKs hat denn dieser Server?

Ich habe dort derzeit 4 VMs laufen

Ich meinte: Wie viele aktive VMDKs hat denn diese VM?

Derzeit habe ich im Datastore von 001 - 258.
Der Server hatte die VMDK SRVVM-000258.vmdk eingebunden.

Hoffe das meintest du?

Also nochmal ganz deutlich: Diese Server-VM hat in ihrem Verzeichnis eine ununterbrochene Kette von 258 Snapshots (001 bis 258) und der letzte ist in der VMX-Datei als Festplatte eingetragen?

EDIT: Und die 258 sind dann im Snapshot-Manager auch zu sehen?

Die liste ist vollständig, ja.
Aber eingetragen ist die vorletzte also 257.

VMware supportet 32 Snaps.

Du must die in Etappen zusammenkopieren. Dabei kann dir der VMware Support helfen... oder hier auf den Ulli warten oder einen der dir sagt was zutun ist.

Es kann aber besser sein ein Backup und Restore zumachen.

Gruss
Joerg

Vielen Dank für die ersten Antworten.
Ich werde mich parallel mit Vmware in Verbindung setzten!

schönes Wochenende

Leroy

Wichtig vorab, weil ~thc's Frage nach der Anzahl der der VM zugewiesenen Virtuellen Platten noch nicht schluessig beantwortet erscheint: Das Folgende gilt fuer eine VM mit nur EINER angehaengten Festplatte (unabhaengig von der Anzahl der gefundenen Snaopshots). Sonst bitte die Aussagen anpassen.

Du kannst es ja statt mit dem gesamten Snapshot-Tree erst einmal versuchen mit


Wenn Du danach die bearbeiteten Snapshot-Dateien weg verschiebst, die erstellte VMDK umbenennst zu <VM-Name>-000100.vmdk (vmkfstools -E) und in das Verzeichnis mit den anderen Snapshots kopierst, sollte die Kette auch wieder konsistent sein (pruefe mit vmkfstools -e; sonst kann man's in der Descriptor-Datei anpassen).

Ich setze dabei voraus, dass der Zieldatastore auch genuegend Platz fuer die neue Datei bietet, und nicht einfach bei den 84% vollgelaufen ist...

Ein Backup ist definitiv eine gute Idee. Vielleicht auch aus dem Gast-OS der VM heraus, falls ein ESXi-Backup per (weiterem) Snapshot an derselben Stelle fehlschlagen sollte.

Hallo,

zu den angehängten Festplatten:

RDP -> 1 Festplatte
SQL -> 1 Festplatte
RDP2 -> 1 Festplatte
DC -> 5 Festplatten


@JustMe: Ich werde deinen Lösungsweg nun mit dem RDP2 versuchen.

JustMe hat geschrieben:Du kannst es ja statt mit dem gesamten Snapshot-Tree erst einmal versuchen mit

Code: Alles auswählen

vmkfstools -i /vmfs/volumes/<Quell Datastore>/<VM-Name>/<VM-Name>-000100.vmdk /vmfs/volumes/<Ziel Datastore>/<ggfs. Verzeichnisname>/ziel.vmdk

Das habe ich nun versucht:

Clone: 96% done.

Dann springt der weiter in die nächste Zeile.
Ich habe im Storage noch 300GB frei, die VM hat insgesamt 60GB.

Na, also, dann geht's ja doch voran

Und wenn's mit 100 noch nicht ganz geht, dann probier's vielleicht erst einmal mit nur 50. Es bedeutet dann nur mehr "Muehe", resp. iterative Schritte.

Wie schon erwaehnt, unterstuetzt VMware selber offiziell ja nur 32.

Genau das habe ich nun vor.
Ich gebe gleich eine Rückmeldung!

EDIT



Fast haben wir es geschafft

Du machst das nun in Teilschritten a 50 Snaps?

- Denk dran das du nun in einem der Descriptors den Pfad/Name anpassen must
- Hinweis: Die Snapshotnummerierung muss nicht fortlaufend sein. Gibts mal luecken weil was geloescht wurde so fuellt VMware diese wieder auf. Drum pruefen das man auch immer den letzten eine Kette erwischt

Welche Software ist eigentlich fuer das Disaster verantwortlich? Ich kann jedem nur empfehlen einen Check einzurichten gegen Snaps.

Gruss
Joerg

Ich habe es versucht, da es ebenfalls nicht funktioniert hat, habe ich nun 25 Schritte versucht.



Das ging nun bis 99%, ich habe es gerade nochmal überprüft von 01-25 sind diese fortlaufend.
Ich werde es nun mal in 10er Schritten versuchen...


Das Problem hat mit Veeam angefangen, seit dies für die Sicherung verwendet wird sind auch die ganzen Probleme aufgetreten.
Ich habe bereits den Host aus dem Backup Proxy entfernt -> ohne Erfolg.
Ich habe nun soweit alles gelöscht, Veeam hat nur noch das NAS als Backup Repository stehen, sonst nichts. Auch keine weiteren Backup Tasks.

Der Veeam Support hat mir mittlerweile gesagt, dass es ein VMWare Problem sei und die mir nicht mehr weiterhelfen können.

Also erstmal bist du mit dem Problem nicht ganz alleine und ja man kann Veeam nicht die ganze Schuld geben. Ich sage immer das bei dem Problem 2 Schuld sind und jeder traegt 51% davon . Andere Backupprodukte sind da auch betroffen. Veeam sticht hervor weil es ja sehr verbreitet ist was zumind. mein Kundenclientel angeht.

- Du hast in 5,5.1 gepostet. Beides ist nun extrem alt und die Frage obs mit einer aktuellen Version nicht auch besser geht
- Ich sehe das Problem haeufig bei Umgebungen die eh etwas Schwach auf der Brust sind bzw. ueberfordert sind
- Bei VMs mehreren/grossen vDisks

Ich kann nur anraten sich einen Report/Check bzw. vCenter Alarm zu basteln was das Thema angeht. Leider ist der vCenter Alarm was Snaps angeht nur bedingt geeignet da er auf die SnapshotDB zugreift welche oftmals kaputt geht.

Gruss
Joerg

Das vmfkstool Kommando hat auch einen Schalter zum pruefen der Kette.... sprich er geht von der angegebenen Datei dann Rueckwaerts und guckt das die Kette vollstaendig ist. Der Schalter sollte in der Hilfe zu finden sein.

Gruss
Joerg

...oder auch in meinem Post vom 27.10.2017, 14:52

JustMe hat geschrieben:...oder auch in meinem Post vom 27.10.2017, 14:52

Ah.... du must halt groesser schreiben... so kleingedruckten sehen meine alten trueben Augen nicht mehr

Gruss
Joerg

Also ich habe das ganze nun in 10er und 5er Schritten versucht.
Der bleibt immer bei 99% stehen und springt dann in eine neue Zeile.

Ich denke das scheint ein größeres Problem zu sein

Neue Zeile...
... MIT prompt, oder ohne?

Falls ohne: Beendest Du dann mit Ctrl-C?
Falls mit: Dann waer's ja ok...

Besteht die Option, den Host mal zu rebooten? Vielleicht hat sich nur was verhakt. (Was dann vielleicht auch die letztliche Ursache der vielen Snapshots sein koennte...)
Falls es ein Cluster mit Shared Storage ist: Wurde die Operation schon auf einem anderen Host probiert?

JustMe hat geschrieben:Neue Zeile...
... MIT prompt, oder ohne?

Den Host habe ich erst am letzte Woche Freitag neugestartet.
Leider haben wir kein Cluster.

Dann sollte er eigentlich fertig sein...

Ist er denn vorher nach 84 bzw. 96/98% auch einfach wieder auf den Prompt gesprungen?

Wohlgemerkt:
Bei Verwendung von vmkfstools wird ja eine Kopie erzeugt; die bearbeiteten Snapshot-Dateien werden nicht automatisch geloescht. Das Einarbeiten der Snapshot-Dateien in das Kopie-Ziel ist hier nur "schmueckendes Beiwerk".

JustMe hat geschrieben:Dann sollte er eigentlich fertig sein...

Ist er denn vorher nach 84 bzw. 96/98% auch einfach wieder auf den Prompt gesprungen?

Ja beim ersten versuch habe ich direkt die letzte VMDK genommen (255) dort ist er bis 84% und dann auch direkt in den Prompt.
Ich habe probeweise die VM mit der geklonten Disk gestartet, das lief soweit auch ohne Probleme.
Ich habe nur ein wenig Angst, dass bei dem SQL, DC und richtigen RDP Server zutun.

Da 84% nunmal nicht 100% sind