VMware-Forum

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

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

Tschoergez hat geschrieben: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

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???

[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

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?

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

djbreezer hat geschrieben:...
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

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

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:



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

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

Gruss
Joerg

Tschoergez hat geschrieben: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 ?

djbreezer hat geschrieben:

Tschoergez hat geschrieben: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

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

so habs mal durchgezogen...

Meine DB hat noch 1,3 GB

Hast du herausbekommen was die Flut der Eintraege verursacht hat?

Gruss
Joerg

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.

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...

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

djbreezer hat geschrieben:so habs mal durchgezogen...

Meine DB hat noch 1,3 GB

too late