Datastore wird immer kleiner?!

[ChrisU]

Hallo Zusammen,

Ich habe folgendes Problem:

Wir nutzen bei uns ESX 3.5. Bei einem der Server laufen drei virtuelle Server (Exchange, Datenbank, DC/DNS).
Momentan habe ich zwei Probleme/Fragen.

Zum einen wird unser Datastore immer kleiner - woran kann das liegen? Die virtuellen Maschinen sind ja fest konfiguriert.

Die andere Sache: Bei unserem Exchange-Server haben wir mehrere Dateien (VM-Server-Name-000001.vmdk bis VM-Server-Name-000005.vmdk) mit einer Größe zwischen 17GB und 150GB. Manche .vmdk werden immer größer und verkleinern unseren Datastore
Im Snapshot-Manager sind keine Snapshots gespeichert. Kann ich diese Dateien einfach löschen?

Vielen Dank schon mal.


Gruß
Christian Umrein

[irix]

Also die Namen der VMDKs welche du gepostet hast sind Snapshots!. Das erklaert auch warum der freie Platz in deinem Datastore immer kleiner wird. Ein weiter Grund welcher Platz wegnehmen kann waeren Coredumps. Die sollten aber keine merkbare Groesse haben und sind unerwuenscht.

Guck mal in die kleinen VMDK Beschreibungsdateien rein und finde ueber die ParentID heraus zu welcher original VMDK die gehoeren.

Direkte Frage:
Warum wendet man sich nicht an den Support mit sowas? Haettest du die wirklich einfach geloescht wenn hier keiner was zum Thema gesagt haette?

Gruss
Joerg

[ChrisU]

Hallo,

danke für die schnelle Antwort. Ich hätte die Dateien nicht einfach gelöscht, deshalb hab ich ja in diversen Foren mal nachgefragt.

Die kleine VMDK hat folgenden Inhalt und bezieht sich, wenn ich das richtig verstehe auf RHS002 - Exchange 2k7-flat.vmdk:

# Disk DescriptorFile
version=1
CID=e407ffd8
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 524288000 VMFS "RHS002 - Exchange 2k7-flat.vmdk"

# The Disk Data Base
#DDB

ddb.toolsVersion = "7302"
ddb.adapterType = "lsilogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "255"
ddb.geometry.cylinders = "32635"
ddb.virtualHWVersion = "4"

Ich habe außerdem folgende VMDK:

RHS002 - Exchange 2k7-000001.vmdk
RHS002 - Exchange 2k7-000001-delta.vmdk
RHS002 - Exchange 2k7-000002.vmdk
RHS002 - Exchange 2k7-000002-delta.vmdk
RHS002 - Exchange 2k7-000003.vmdk
RHS002 - Exchange 2k7-000003-delta.vmdk
RHS002 - Exchange 2k7-000004.vmdk
RHS002 - Exchange 2k7-000004-delta.vmdk
RHS002 - Exchange 2k7-000005.vmdk
RHS002 - Exchange 2k7-000005-delta.vmdk

Die 000001-000004 verändern ihre Größe nicht, nur die 0000005.

[irix]

Es waechst ja auch nur der "aktuelle" Snapshot somit ist das erstmal normal. Wenn du immer noch nicht den Support bemuehen moechstest wuerde ich folgendes machen

1. Direkt mit dem VI Client auf den ESX connecten und nicht vCenter
2. Sicherungskopie der kleinen VMDKs in ein anderes Verz.
3. Backup (evtl. sogar mit VCB)
4. einen manuellen Snapshot machen und hinterher "Delete ALL Snapshots" um zu gucken ob er die anderen wieder mit einarbeiten wuerde.

Bei der ganzen Geschichte mit einem tail -f die logs messages hostd.log und das in der VM angucken.

Bei einer normalen VM koennte man die auch durch den Konverter jagen bzw. clonen. Aber bei einem Exchange/DC/ usw. will man sowas normal nicht.

Gruss
Joerg

[ChrisU]

Hallo Jörg,

was mich aber verwundert, in dem Snapshot-Manager sind keine Snapshots drin?!

Also könnte man da die 00000x-vmdk löschen oder eher nicht?
Ich brauche von dem Server keine Snapshots, da ich den jeden Tag mit BackupExec sichere.

Wegen des Supportes habe ich eben festgestellt, dass unser Vertrag im November 08 abgelaufen ist.

Deine Variante mit dem neuen Snapshot erstellen und danach auf "Alle löschen" habe ich schon getestet, leider ohne Erfolg.

[irix]

Hallo Jörg,

was mich aber verwundert, in dem Snapshot-Manager sind keine Snapshots drin?!

Also könnte man da die 00000x-vmdk löschen oder eher nicht?
Ich brauche von dem Server keine Snapshots, da ich den jeden Tag mit BackupExec sichere.

Die 0000005 waechst aber laut deiner Aussage und somit kannst du die auch nicht loeschen und solltest das auch nicht tun.

Wegen des Supportes habe ich eben festgestellt, dass unser Vertrag im November 08 abgelaufen ist.

Zeitpunkt um ueber eine Verlaengerung nachzudenken oder?

Deine Variante mit dem neuen Snapshot erstellen und danach auf "Alle löschen" habe ich schon getestet, leider ohne Erfolg.

Fahre die VM herunter, erstelle einen Clone ohne Customizing und wenn der Laueft loesche das alte Verzeichnis.

Gruss
Joerg

[bla!zilla]

Fakt ist aber: Deine VM läuft auf einem Snapshot. Und da du im Snapshotmanager keinen siehst, ist das primär schon mal sehr, sehr komisch.

1. Support verlängern
2. VMware Support in Anspruch nehmen

Alternativ:

1. Selber basteln
2. Das Risiko des Datenverlustes selber tragen

Schau bitte mal in die Eigenschaften der VM, speziell bei den Virtual Disks: Sind da auch die 0000x.vmdk eingetragen?

[ChrisU]

Ich habe folgende Vermutung:

Die wachsende vmdk-Datei xxx-0000005.vdmk scheint ein neuer Snapshot zu sein, der jetzt aus den alten (1-4) einen neuen, funktionierenden erstellt.

Habe auch mit meinem Chef gesprochen, dass er den Support-Vertrag verlängert.

Trotzdem Danke für eure Anregungen.

[bla!zilla]

Glaub ich weniger, aber gut.

Fakt ist: Dir wird dein VMFS platzen... irgendwann ist der Snapshot entweder so groß, dass das VMFS voll ist, oder er ist so groß, dass du keinen Platz mehr hast ihn zu mergen. Beides wäre sehr, sehr, sehr doof.

[irix]

Glaub ich weniger, aber gut.

Fakt ist: Dir wird dein VMFS platzen... irgendwann ist der Snapshot entweder so groß, dass das VMFS voll ist, oder er ist so groß, dass du keinen Platz mehr hast ihn zu mergen. Beides wäre sehr, sehr, sehr doof.

Da ein Snapshot nicht grosser wird als die Ausgangsplatte kann er das ja ausrechnen ob der Platz reicht oder nicht.

Gruss
Joerg

[continuum]

Im Snapshot-Manager sind keine Snapshots gespeichert.

Hast du keine *.vmsn Datei im Verzeichnis der VM ?

[ChrisU]

Ich habe eine vmsn Datei - Server-Snapshot34.vmsn.
Im Snapshot-Manager ist jetzt ein Snapshot, den keiner unserer Mitarbeiter erstellt hat: Consolidate Helper- 0

[irix]

Ich habe eine vmsn Datei - Server-Snapshot34.vmsn.
Im Snapshot-Manager ist jetzt ein Snapshot, den keiner unserer Mitarbeiter erstellt hat: Consolidate Helper- 0

Wird von VCB gemacht und bleibt sichtbar wenn VCB einen Fehler bringt und nicht durchlaueft.

Gruss
Joerg

[bla!zilla]

Dann könnte doch VCB/ Symantec Backup Exec der Verursacher sein.