vCenter DB - Was genau ist drin?

[djbreezer]

Hiho,
ich möchte gern unser vCenter neuinstallieren, da nach dem Update auf 4.1 irgendwie nichts mehr richtig rund läuft.

Muss ich hierzu die vCenter DB sichern, oder kann ich eine neue anlegen? Weiß jemand, was genau in der DB alles eingetragen ist?

Habe unteranderem Netzwerkconfigs vorgenommen. die ich nur ungern nochmal machen möchte. Trunking + Teaming etc. Sind diese Einstellungen in der DB? Habe nirgendwo verlässliche Infos finden können, was genau alles da drin steht.

Danke für eure Antworten

Grüße

Alex


EDIT: http://communities.vmware.com/thread/81313

Sorry für die Fragen

[Tschoergez]

Zusammenfassend: Die Netzwerkkonfigs liegen auf den ESX und gehen NICHT verloren bei ner kompletten vCenter neu installation.

Was verloren geht:
Permissions, Alarme, Perfomance-Daten, Template-registierungen, Guest Customization Specs, Resource-Pools im DRS-Cluster und Cluster-configuration allgemein und die Ordnerstruktur im Inventory.

Normalerweise nix, was sich nicht relativ schnell wiederherstellen lässt.

viele Grüße,
Jörg

[irix]

Zusammenfassend: Die Netzwerkkonfigs liegen auf den ESX und gehen NICHT verloren bei ner kompletten vCenter neu installation.

Wie sieht das bei einem vDS aus? Ich weis das die Konfig sowohl im vCenter als auch auf dem Hosts gespeichert ist. Ich gehe aber davon aus das vCenter das fuehrende System ist.

Wenn du die VIM_VCDB behalten willst gebe ich der Neuinstallation aber keine Chancen das anschliessend dein Problem behoben ist. Wann immer es Probleme mit dem vCenter hier gab in den letzten 3 Jahren musste immer auch die DB dranglauben nachdem der VMware Support aufgegeben hat.

Gruss
Joerg

[djbreezer]

sehr gut! seh nämlich grade, dass die DB vom vCenter wohl auch n schlag hat.... irgendwas stimmt da ganz gewaltig nicht. Die DB wurde vor fast genau 1 Jahr erstellt und hat nun bereits 4650 MB... was eigentlich unmöglich ist, da es eine Express-DB is.

Hab nun grad mal dieses abspeck Script von VMWare durchlaufen lassen, hat aber nich viel gebracht.

In der Umgebung sind nur 3 Hosts und 30 VMs. Hat jem. ne Idee wieso die DB so anwachsen kann???

[Tschoergez]

[quote="irix"

Wie sieht das bei einem vDS aus? Ich weis das die Konfig sowohl im vCenter als auch auf dem Hosts gespeichert ist. Ich gehe aber davon aus das vCenter das fuehrende System ist.
[/quote]

SH*T! Die vergesse ich immer
Natürlich ist die vDS-konfiguration im vCenter, wenn das verloren geht, müssen sie neu konfiguriert werden.
Die vDS-Konfig wird zwar auf den ESX auch gespeichert, aber nur, damit der ESX auch switchen kann, falls das vCenter mal down ist. Es gibt keine Möglichkeit, die Konfig vom ESX "zurückzuholen".
Guter Punkt: Wenn vDS => vCenter-Datenbank sehr wichtig!

Viele Grüße,
Jörg

[Virtuozzi]

Events und Tasks, sowie Perf-Daten welche langfristig gespeichert werden.

Seitdem ich auch dieses Problem bei einer älteren 4.0 Installation hatte, setze ich bei neuen von Anfang an die retention policy, vcenter-seitig (Home->vcenter server settings->database retention policy).

Kennt jemand eine Methode wie man das gleiche für die perf-Daten setzen kann?

[Tschoergez]

Jo, für die Performance Daten: In vCenter Server Settings => Statistics kannst Du festlegen, wieviele Counter-Werte wie lange aggregiert und aufgehoben werden sollen.
Grüße,
jörg

[irix]

...
In der Umgebung sind nur 3 Hosts und 30 VMs. Hat jem. ne Idee wieso die DB so anwachsen kann???

Das koennte daran liegen das die Verarbeitung der Perf-Daten nicht mehr funktioniert. Dann explodiert da eine der VIM_HIST_STAT* Tabellen. Wir hatten 60mio Eintraege drin und der Support konnte das Problem nicht beheben bei der Verwendung der ExpressDB.

Ja natuerlich kann man die Eintraege loeschen.... aber das behebt das eigentliche Problem nicht. Falls man aber loescht sollte man vorher das Wiederherstellungsmodell der DB von Vollstaendig auf Einfach setzen weil ansonsten hat man eine Sternennova was das Transaktionslog angeht. Zumind. wenn man vom Normalfall ausgeht.

Damit die phys. Datenbankdateien in ihrer Groesse reduziert werden nach groessen Loeschaktionen must du diese "Verkleinern".

Gruss
Joerg

[Tschoergez]

Kam gerade via Feedreader "rein", passt nicht ganz zu den Performance-daten, aber zum restlichen Thema:
http://www.vfrank.org/2011/04/28/trunca ... -database/

viele grüße,
jörg

[djbreezer]

also bei mir sind die Tabellen vpx_event und vpx_event_arg am größten. Das Script von VMWare spuckt mir in bezug auf die Tabellen HIST_STAT_1 bis HIST_STAT_4 , das es da nix zu löschen gibt. Hab als Parameter mal -180 Tage eingestellt, wie ich in der Retencion Policy auch eingerichtet hab.

Zu meinen riesen Tabellen konnte ich bei VMWare nur folgendes finden:

Code: Alles auswählen

Whats in the VirtualCenter database?VPX_EVENT[/b] – Used to store all events as a result of tasks or alarms in VC (event type, date/time, VM name, username, category, hostname), this table is typically large and has 15 columns and usually a large amount of rows but is generally small in megabytes, 50,000 rows will equal approximately 9MB.

Whats in the VirtualCenter database?VPX_EVENT_ARG[/b] – This corresponds to the VPX_EVENT table and contains event ids, argument types & data and miscellaneous IDs. This table is usually pretty large and contains the text of the events from the VPX_EVENT table. This table has 14 columns and usually has more records then the VPX_EVENT table, 150,000 records will generally use about 20MB of space.


Nun haben diese 2 Tabellen bei mir aber ca. 1,6 GB !!

[irix]

Na das passt doch dann zu dem was Jörg gepostet hat.

Gruss
Joerg

[djbreezer]

Kam gerade via Feedreader "rein", passt nicht ganz zu den Performance-daten, aber zum restlichen Thema:
http://www.vfrank.org/2011/04/28/trunca ... -database/

viele grüße,
jörg

sauber + volltreffer

Wer probierts ?

[irix]

Kam gerade via Feedreader "rein", passt nicht ganz zu den Performance-daten, aber zum restlichen Thema:
http://www.vfrank.org/2011/04/28/trunca ... -database/

viele grüße,
jörg

sauber + volltreffer

Wer probierts ?

Na immer der welcher heute seinen letzten Tag vor dem 3 woechigem Urlaub hat:)

Gruss
Joerg

[djbreezer]

sind 2 Fehler sind im script... addconstraint muss mit Space also: "add constraint"...

[djbreezer]

so habs mal durchgezogen...

Meine DB hat noch 1,3 GB

[irix]

Hast du herausbekommen was die Flut der Eintraege verursacht hat?

Gruss
Joerg

[Tschoergez]

ich kenns von externen skripten, z.B. das disk-monitoring vcplus skript von
http://www.run-virtual.com/?page_id=38

das erzeugt etliche einträge, oder halt andere PowerCLI, Orchestrator und sonstige Tools, die auf irgendwas regelmäßig machen, was einen Events-Eintrag erzeugt.

[djbreezer]

ne sorry keine ahnung warum genau diese 2 Tabellen so groß geworden sind. Ich schätze es kommt von den HP Insight Managern... die sind auf allen Servern aktiv. Ist natürlich nur ne Vermutung...

[Tschoergez]

gut möglich.
findest Du denn viele gleichartige Einträge (falls Du sie noch nicht gelöscht hast) ?

[djbreezer]

so habs mal durchgezogen...

Meine DB hat noch 1,3 GB

too late