Hi,
Im produktiven Einsatz, ist eine 3TB „schwere“ Samba VM, welche diverse Shares anbietet.
Guest ist ein Ubuntu18 LTS auf aktuellem Stand.
Ein All Flash Storage ist über 10GB iSCSI angebunden.
Die VM liegt allein in einer 4 TB LUN.
Es liegen aktuell 3351097 Files auf den Shares, von 1MB bis 970MB größe.
Die Shares dienen zu Ablage Build Results und unterschiedlichste Installer, welche ununterbrochen gebaut werden.
Der Wartungsworkflow sieht vor, dem einspielen der Updates ein Snapshot um ausgeschalteten Zustand gezogen wird.
Problem ist nun, das sobald dieser Snap gezogen wurde, direkt danach die Meldung aufpoppt, dass die Platten konsolidiert werden müssen.
Wird die Konsolidierung bzw. delete Snapshot getriggert, läuft der Job zu 100% durch und wird abgeschlossen.
Weiterhin wird der consolidate Trigger angezeigt und die 00001…vmdks liegen weiterhin da, aber das vCenter ist der Meinung, dass keine Snapshots vorhanden sind.
Das die VM clonen eine Möglichkeit ist, ist klar, aber kann ich die VM nicht anders wieder reparieren?
danke für die Hilfe
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!
große Samba VM - Disk consolidate ändert nichts
-
- King of the Hill
- Beiträge: 12902
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Re: große Samba VM - Disk consolidate ändert nichts
Trigger sind
1. Nicht alle vDisks haben die gleiche Anzahl an Snaps
2. Die SnapDB(kleiene Textdatei) stimmt nicht mit den Dateipfaden ueberein welche immer aufzeigen ob die VM einen Snap hat
Kann es sein das das Snapshot loeschen niemals fertig wird weil die Aenderungsrate zu hoch ist? Sieht man das nicht im vmware.log oder vmkernel?
Gruss
Joerg
1. Nicht alle vDisks haben die gleiche Anzahl an Snaps
2. Die SnapDB(kleiene Textdatei) stimmt nicht mit den Dateipfaden ueberein welche immer aufzeigen ob die VM einen Snap hat
Kann es sein das das Snapshot loeschen niemals fertig wird weil die Aenderungsrate zu hoch ist? Sieht man das nicht im vmware.log oder vmkernel?
Gruss
Joerg
Re: große Samba VM - Disk consolidate ändert nichts
hmm hier scheint so einiges im argen zu sein
wie genau heißt das SnapDB file?
im Datastore find ich nichts.
Code: Alles auswählen
-rw------- 1 root root 527.8G Jun 10 04:18 tt-ddvs15_5-000003-sesparse.vmdk
-rw------- 1 root root 236.7G Jun 10 10:52 tt-ddvs15_5-000004-sesparse.vmdk
-rw------- 1 root root 49.0G Jun 9 00:20 tt-ddvs15_5-000002-sesparse.vmdk
-rw------- 1 root root 42.7G Jun 8 20:12 tt-ddvs15_5-000001-sesparse.vmdk
-rw------- 1 root root 1.4G Jun 10 08:38 tt-ddvs15_7-000001-sesparse.vmdk
-rw------- 1 root root 1.4G Jun 10 10:52 tt-ddvs15_4-000001-sesparse.vmdk
-rw------- 1 root root 5.5M Jun 10 04:18 tt-ddvs15_7-000001-ctk.vmdk
-rw------- 1 root root 5.3M Jun 8 20:12 tt-ddvs15_5-000001-ctk.vmdk
-rw------- 1 root root 5.3M Jun 9 00:20 tt-ddvs15_5-000002-ctk.vmdk
-rw------- 1 root root 5.3M Jun 10 04:18 tt-ddvs15_5-000003-ctk.vmdk
-rw------- 1 root root 5.3M Jun 10 04:18 tt-ddvs15_5-000004-ctk.vmdk
-rw------- 1 root root 1.9M Jun 10 04:18 tt-ddvs15_4-000001-ctk.vmdk
-rw------- 1 root root 467 Jun 9 00:20 tt-ddvs15_5-000001.vmdk
-rw------- 1 root root 420 Jun 9 07:57 tt-ddvs15_5-000002.vmdk
-rw------- 1 root root 397 Jun 9 21:01 tt-ddvs15_5-000003.vmdk
-rw------- 1 root root 397 Jun 10 04:18 tt-ddvs15_5-000004.vmdk
-rw------- 1 root root 389 Jun 10 04:18 tt-ddvs15_7-000001.vmdk
-rw------- 1 root root 388 Jun 10 04:18 tt-ddvs15_4-000001.vmdk
wie genau heißt das SnapDB file?
im Datastore find ich nichts.
-
- King of the Hill
- Beiträge: 12902
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Re: große Samba VM - Disk consolidate ändert nichts
Ist eine kleine ASCII Datei ... zeig doch mal den ganzen Inhalt des Ordners weil dann muss ich nicht bei mir nachgucken.
Gruss
Joerg
Gruss
Joerg
Re: große Samba VM - Disk consolidate ändert nichts
Der Dateiname lautet <VM-Name>.vmsd (fuer Snapshot Descriptor vmtl.). Wahrscheinlich ist die sogar nur noch 0 Bytes gross, oder enthaelt keine Snapshot-Infos mehr. Evtl. sind beim (mehrfachen) Aufloesen der Snapshots nur einzelne der VMDKs bearbeitet worden, aber nicht alle.
So auf den ersten Blick wuerde ich meinen, dass an der VM mindestens drei bis 8 VMDKs dran haengen, und die haben jeweils unterschiedlich viele Snapshot-Dateien. Und dies bei einer gewaltigen Aenderungsrate.
Das duerfte ein Fall fuer sukzessives Klonen der einzelnen VMDKs per vmkfstools sein, waehrend die VM aber heruntergefahren sein muss.
Die Frage von irix nach dem kompletten Ordnerinhalt wuerde ich um dem Inhalt der <VM-Name>.vmx oder alternativ der aktuellen vmware.log erweitern. Danach braucht's wohl auch noch die kleinen vmdk-Dateien (<1kB), um die Snapshot-Reihenfolge zu verfizieren.
So auf den ersten Blick wuerde ich meinen, dass an der VM mindestens drei bis 8 VMDKs dran haengen, und die haben jeweils unterschiedlich viele Snapshot-Dateien. Und dies bei einer gewaltigen Aenderungsrate.
Das duerfte ein Fall fuer sukzessives Klonen der einzelnen VMDKs per vmkfstools sein, waehrend die VM aber heruntergefahren sein muss.
Die Frage von irix nach dem kompletten Ordnerinhalt wuerde ich um dem Inhalt der <VM-Name>.vmx oder alternativ der aktuellen vmware.log erweitern. Danach braucht's wohl auch noch die kleinen vmdk-Dateien (<1kB), um die Snapshot-Reihenfolge zu verfizieren.
Re: große Samba VM - Disk consolidate ändert nichts
ReedyTT hat geschrieben:Hi,
Im produktiven Einsatz, ist eine 3TB „schwere“ Samba VM, welche diverse Shares anbietet.
Guest ist ein Ubuntu18 LTS auf aktuellem Stand.
Ein All Flash Storage ist über 10GB iSCSI angebunden.
Die VM liegt allein in einer 4 TB LUN.
Es liegen aktuell 3351097 Files auf den Shares, von 1MB bis 970MB größe.
Die Shares dienen zu Ablage Build Results und unterschiedlichste Installer, welche ununterbrochen gebaut werden.
Der Wartungsworkflow sieht vor, dem einspielen der Updates ein Snapshot um ausgeschalteten Zustand gezogen wird.
Problem ist nun, das sobald dieser Snap gezogen wurde, direkt danach die Meldung aufpoppt, dass die Platten konsolidiert werden müssen.
Wird die Konsolidierung bzw. delete Snapshot getriggert, läuft der Job zu 100% durch und wird abgeschlossen.
Weiterhin wird der consolidate Trigger angezeigt und die 00001…vmdks liegen weiterhin da, aber das vCenter ist der Meinung, dass keine Snapshots vorhanden sind.
Das die VM clonen eine Möglichkeit ist, ist klar, aber kann ich die VM nicht anders wieder reparieren?
danke für die Hilfe
Ggf. mal überlegen ob man die Daten nicht auf eine Synology oder ein anderes NAS umzieht?
Gruß
-
- King of the Hill
- Beiträge: 13525
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Re: große Samba VM - Disk consolidate ändert nichts
Wenn ich die Angaben All-Flash-Storage mit 10GBit-Anbindung lese, dürfte der Umzug auf ein NAS nur wenig bis garnix am Problem ändern, weil wir weder die Änderungsrate noch die dabei auftretende Datenmenge kennen und man noch mit einem zusätzlichen Gerät rumhantieren müßte. KISS geht irgendwie anders.
Ohne genauere Angaben zur vorhandenen, eingesetzten HW halte ich jede Empfehlung für weitere HW für wenig zielführend.
Ohne genauere Angaben zur vorhandenen, eingesetzten HW halte ich jede Empfehlung für weitere HW für wenig zielführend.
Re: große Samba VM - Disk consolidate ändert nichts
Guten Morgen,
am Wochenende ist die LUN dann vollgelaufen.
Nach der Vergrößerung um weitere 2TB und "abklemmen" des internen NICs (wegen der zu hohen Änderungsrate, guter Tipp!) hat das konsolidieren tatsächlich funktioniert.
aktueller DataStore Inhalt:
Im Screenshot, sieht man gut den Moment, als ich das konsolidieren angeschmissen hab.
Das besondere an der VM ist, die hohe Dauerschreiblast.
Dazu kommt das Backup, welches auch jede Stunde vorbei kommt und einen Snapshot zieht.
Als erst Folge, werde ich in der Wartung den samba Dienst aus machen.
Logs hänge ich gleich noch an.
Inhalt von der *.vmsd sieht so aus:
ps.:
das aktuelle Logfile musste ich zippen, weil 7MB zu groß sind, nicht wundern
am Wochenende ist die LUN dann vollgelaufen.
Nach der Vergrößerung um weitere 2TB und "abklemmen" des internen NICs (wegen der zu hohen Änderungsrate, guter Tipp!) hat das konsolidieren tatsächlich funktioniert.
aktueller DataStore Inhalt:
Code: Alles auswählen
total 3153681728
-rw------- 1 root root 2911987826688 Jun 13 06:46 tt-ddvs15_5-flat.vmdk
-rw------- 1 root root 375809638400 Jun 13 05:13 tt-ddvs15_7-flat.vmdk
-rw------- 1 root root 32212254720 Jun 13 06:46 tt-ddvs15_4-flat.vmdk
-rw------- 1 root root 87031808 Jun 11 12:39 vmx-tt-ddvs15-ed1d09d2f15cfd908ebf81b14894a3a2ad42ed78-1.vswp
-rw-r--r-- 1 root root 42612607 Jun 8 19:48 vmware-6.log
-rw-r--r-- 1 root root 26344959 May 25 19:26 vmware-3.log
-rw-r--r-- 1 root root 7198036 Jun 13 05:14 vmware.log
-rw------- 1 root root 5734912 Jun 13 05:14 tt-ddvs15_7-ctk.vmdk
-rw------- 1 root root 5554688 Jun 13 05:14 tt-ddvs15_5-ctk.vmdk
-rw------- 1 root root 1966592 Jun 13 05:12 tt-ddvs15_4-ctk.vmdk
-rw-r--r-- 1 root root 1139385 Jun 11 12:29 vmware-7.log
-rw-r--r-- 1 root root 525987 Apr 28 07:07 vmware-2.log
-rw-r--r-- 1 root root 516704 May 25 22:04 vmware-4.log
-rw-r--r-- 1 root root 287334 May 25 22:07 vmware-5.log
drwxr-xr-x 1 root root 86016 Jun 13 05:13 .
drwxr-xr-t 1 root root 73728 Apr 27 18:56 ..
-rw------- 1 root root 8684 Jun 11 12:41 tt-ddvs15.nvram
-rwxr-xr-x 1 root root 4670 Jun 13 05:13 tt-ddvs15.vmx~
-rwxr-xr-x 1 root root 4652 Jun 13 05:13 tt-ddvs15.vmx
-rw------- 1 root root 636 Jun 13 05:13 tt-ddvs15_5.vmdk
-rw------- 1 root root 634 Jun 13 05:13 tt-ddvs15_7.vmdk
-rw------- 1 root root 616 Jun 13 05:11 tt-ddvs15_4.vmdk
-rw-r--r-- 1 root root 576 Apr 27 22:10 tt-ddvs15-017cbdf5.hlog
-rw------- 1 root root 150 Jun 11 12:29 tt-ddvs15.vmxf
-rw-r--r-- 1 root root 45 Jun 13 05:13 tt-ddvs15.vmsd
-rw-r--r-- 1 root root 14 Jun 13 05:13 tt-ddvs15-aux.xml
-rw------- 1 root root 0 Jun 11 12:39 tt-ddvs15-15b739ad.vswp
-rw------- 1 root root 0 Jun 11 12:39 tt-ddvs15.vmx.lck
Im Screenshot, sieht man gut den Moment, als ich das konsolidieren angeschmissen hab.
Das besondere an der VM ist, die hohe Dauerschreiblast.
Dazu kommt das Backup, welches auch jede Stunde vorbei kommt und einen Snapshot zieht.
Als erst Folge, werde ich in der Wartung den samba Dienst aus machen.
Logs hänge ich gleich noch an.
Inhalt von der *.vmsd sieht so aus:
Code: Alles auswählen
.encoding = "UTF-8"
snapshot.lastUID = "139"
ps.:
das aktuelle Logfile musste ich zippen, weil 7MB zu groß sind, nicht wundern
- Dateianhänge
-
- vmware.7z
- (204.18 KiB) 42-mal heruntergeladen
-
- King of the Hill
- Beiträge: 12902
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Re: große Samba VM - Disk consolidate ändert nichts
Dann ist ja das urspruengliche Problem geloest. Die Frage was aber nun das eigentliche Problem ist? Wenn das Problem das naechste mal Auftritt dann bitte im vmware log/vmkernel gucken weil da sollte vermerkt sein das die Aenderungsrate zu hoch ist.
Gruss
Joerg
Gruss
Joerg
Re: große Samba VM - Disk consolidate ändert nichts
jep das grundliegende Problem ist gelöst, beim nächste Mal was höchstwahrscheinlich nächste Woche Mittwoch sein wird, melde ich mich.
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast