VMware-Forum

Hallo Forum,

ich habe ein Problem mit einer VM.
Es ist Veeam Backup im Einsatz und es scheint so zu sein das die erstellten Snapshots nicht konsolidiert werden können. Im Snapshotmanager sind keine Snapshots zu sehen. Wenn ich aber per Dateibrowser nach sehe, finde ich über 100 Snapshots und ***-ctk.vmdk Dateien.
Bis gestern habe ich beim versuch der Konsolidierung " unspecified filename was not found“ bekommen.
Seit heute ist es "Die snapshot hirachie ist zu tief".
Vmware lehnt den support ab -> es sei ein Veeam Problem. Veeam kommt aber nicht richtig in die Hufe.

Eckdaten
single ESXi Host - Vmware 5.1.0
Veeam Version 9 SP 2

Hat hier jemand einen Ansatz ?

Vielen dank im Voraus

Nils

screens:
http://imageshack.com/a/img921/9428/WtvL9Y.png
http://imageshack.com/a/img924/2443/2PO0MW.png
http://imageshack.com/a/img921/198/ML5S5e.png
edit:
was ich schon probiert habe:
host rebooten
konsolidieren wenn asugeschaltet
Snapshot erstellen und löschen (fehlermeldung kein weiterer snapshot möglich).

Was ich noch plane (aber auf infos hoffe da die Prozesse sehr lange dauern)
mit dem VMware converter die maschine in eine neue Konvertieren

Veeam Quick Migrate ....

oder per SSH und shell konsolidieren (da trau ich mich nicht recht da ich nciht so der Linux Profi bin)

Dateibrowser/Datastore Browser ist schon mal sehr schlecht...

Die weiteren Arbeiten sollten auf der ESXi-Kommandozeile und bei ausgeschalteter VM ausgefuehrt werden.

Dort kann man dann, nach Pruefung der Konsistenz der Snapshot-Kette per vmkfstools, die Snapshots "von innen heraus" konsolidieren.

Dazu aendert man die .vmx dahingehend, dass sie nicht mehr auf das Ende der Kette verweist, sondern z.B. auf den zwanzigsten Snapshot.
Dann wird mit "vim-cmd vmsvc/snapshot.removeall #" (genauen Aufruf bitte mit der in der Kommandozeile integrierten Hilfe ermitteln; ich habe gerade kein passendes System zur Hand) die "innerste" Kette von Snapshots entfernt, und somit die Gesamtanzahl reduziert.

Das muss ggfs. wiederholt werden, bis die Konsolidierung wieder geht, oder man macht's gleich selbst und entfernt nacheinander ALLE Snapshots.

Bei Unsicherheit wird ein lokaler faehiger Partner sicher gerne die Durchfuehrung uebernehmen. Selbstverstaendlich (und mit vollem Recht) gegen den Einwurf groesserer Mengen kleiner Muenzen...

ich würde ja eine Anzalh kleiner Münzen zur Verfügung stellen.
Habe nur miemanden zur Hand der das kann.

Was meinst du zu der Idee mit dem Converter ?ist das vieleicht auch was ? laut freund Google ist das wohl eine Alternative.

Grüße

Nils

wenn ich versuche mit vmkfstools -i die Platte zu clonen auf welche vmdk muss ich referenzieren ?
in den Eigenschaften ist bei Festplatte 1 XXX-XXX000256.vmdk <- ist die dann meine Quellel ?

Einen Versuch ist der Converter sicher wert. Mir macht allerdings die beobachtete Meldung ueber die fehlgeschlagene Snapshot-Operation Sorgen. Das kann gut sein, dass darueber auch der Converter stolpert.

Wenn genuegend Platz vorhanden ist, kannst Du es auch erst einmal mit versuchen.

Was mich wundert ist, dass VMware nicht einmal auf "Per-Incident"-Support daran basteln moechte. Sicher ist die URSACHE die Snapshot-Operation durch Veeam, aber Bereinigung der vielen Snaps hat dann wieder mit Veeam nix zu tun, sondern ist einzig Host-OS Operation...

Vielleicht meldet sich ja jemand der Pos(t)er hier im Forum mit einem Angebot per Personal Mail. Ansonsten g**gle doch mal mit "Postleitzahl vmware partner"... Nach den ersten Werbe-Links zu VMware selber sollten dann jede Menge Partner auftauchen.

Edit:
Ich muss doch mal lernen, schneller zu tippen

Was mich wundert ist, dass VMware nicht einmal auf "Per-Incident"-Support daran basteln moechte.

Das wundert mich nicht - schliesslich sagt die Dokumentation ja dass dieser Fall unmöglich sein sollte - also hat der Support auch nicht gelernt wie man das sicher abwickelt.
Ich mach das bei Bedarf auch im laufenden Betrieb indem ich die Snapshotkette in einzelne handliche Abschnitte zerlege und diese dann von Hand konsolidiere.
Das benötigt zwar etwas zusätzlichen Platz hat aber den Vorteil, dass die VM die meiste Zeit weiterlaufen kann und ein eventueller Fehlschlag einer Teilkonsolidierung toleriert werden kann.
Meiner Erfahrung nach wird der Converter für die Aktion ewig brauchen und ein vmkfstools -i Clone der gesamten Kette sollte mit einer Fehlermeldung direkt nach dem Start abbrechen.
Ablauf:
1. Treffen:
Absprechen der Option - Suchen von Ausweichplatz
Start erste vmkfstools -i Aktion
insgesamt ca 1 Stunde

2. Treffen:
5 Minuten Downtime der VM
Start zweite vmkfstools -i Aktion
ca 20 Minuten

3. Treffen:
5 Minuten Downtime der VM
Start dritte vmkfstools -i Aktion
ca 20 Minuten

4. Treffen
5 Minuten Downtime der VM
letzte Umkonfigurierung
letzte Standpauke für den Admin vor Ort wegen Leichtsinn und mangelnder Überwachung der Datastores

Falls die Sache im laufenden Betrieb gemacht werden soll - bieten sich Termine nach Büroschluss an.
Meine Telefonnummer und Skype-kontakt stehen ein paar Zeilen tiefer ....
Anrufe früh morgens unerwünscht.

Hi,
ich habe noch mal beim VMWARE support angerufen und es hat sich einer "erbarmt" zur Zeit läuft das clonen der Platten mit vmkfstools -i. Das hatte ich mich nicht getraut anzustoßen da die in dem KB beschriebenen Schritte vor dem Befehl schon fehl schlugen.
Es dauert aber eeeeewwwiiiigggg.

Ich werde auf jeden Fall berichten falls es geklappt haben sollte, wenn nicht weine ich hier weiter

Danke euch beiden schon mal für die guten Tips.

Als V* Partner kann ich nur sagen das da beide den schwarzen Peter haben.
- Dafuer das VMware nicht supportet mehr als XX(32?) Snapshots zuhaben dies aber nicht unterbindet
- Veeam welche rumtoenen das sich da nen Snapshothunter haette der aber scheinbar bei die die Klappe haelt
- Die Snapshot DB welche eine simple TxT Datei ist und Prozesse scheinbar gegenseitig reinschreiben koennen
- Es "passiert" aber auch mit allen anderen Backupprodukten. Bei denen welche HotAdd wenden ist die Problemrate etwas hoeher.

Ich koennte mich schon wieder aufregen......

Aber auch euch muss man an den Ohren ziehen weil weil es scheinbar da kein Monitoring an der Ecke gibt. Eine aktive VMs mit 100 Snaps ist auch arsch langsam.

Um deine Eingangsfrage zu beantworten. Bei dem "clonen" mit vmkfstools wird immer mit dem Descriptor "vmname-0000123.vmdk" gearbeitet und man gibt die "aktuelle" Datei weil die automatik dann rekursiv nach unten durch geht.
Die "aktuelle" zu bestimmen erfordert aber etwas sorgfalt das es nicht automaisch die mit der hoehsten Nummer ist.

Wie lange der Vorgang dauert haengt von der Datenmenge und der Geschwindigkeit des Storages ab. Ein "esxtop" in einer 2. Shell Session laesst einen ja zugucken und ueber die MB/s ungewaehr ausrechnen wielange es dauert.

Gruss
Joerg

Hallo Forum,

es hat sich geklärt.
Nach dem Clonen der Platte lief die VM wieder einwandfrei. Beim erstellen von snapshots kam es aber wieder zu starken Leistungseinbrüchen. Auch das verschieben der "alten" VMDK´s brach mit einer Fehlermeldung ab.
Einige VMDK´s waren "in use".
nach langem suchen haben wir herausgefunden dass, Veeam Backup Snapshot´s in den Backup Server eingehängt hat (und offensichtlich nicht mehr ausgehängt --Quick Migration?? )). Dadurch waren die Files gelocked.
Die Platten ausgehängt und alles funktioniert wieder.
Jetzt muss ich morgen nach einem Backup lauf nur schauen ob wieder irgendwas gelocked ist.

Danke für die Anregungen.

Nils

Wenn mittels HotAdd gesichert wird dann ist dies eine haeufige Fehlerquelle das die vDISK am Veeam Proxy haengen bleibt. Geht aber anderen Produkten genau so..... als langjaehriger vRanger Anwender weis ich wovon ich Spreche

Bei Problemen mit Snaps und besonders wenn die VMware Meldung "VM muss Konsolidiert" werden kommt dann muss geschaut werden was die Ursache ist bevor eine Bereinigungsaktion blindlings gestartet wird.

Gruss
Joerg