Das Forum wurde aktualisiert. Wurde höchste Zeit. Wenn etwas nicht funktioniert, bitte gerne hier jederzeit melden.

VC update von 2.0.1 auf 2.0.2 schlägt fehl

Virtualisierungsmanagement, Servermanagement.

Moderatoren: Dayworker, continuum, Tschoergez, irix, stefan.becker

Profi
Beiträge: 535
Registriert: 04.01.2006, 12:06
Wohnort: Hamm

VC update von 2.0.1 auf 2.0.2 schlägt fehl

Beitragvon ostekl1 » 05.11.2007, 13:56

Hallo zusammen,

ich stehe hier vor einem seltsamen Phänomen.
Wir haben langem ein VirtualCenter in Verbindung mit einer Oracle 10g (10.2.0.2) Datenbank laufen. Um meine Probleme mit den VCB Snapshots in den Griff zu bekommen, habe ich jetzt alle ESX Server auf 3.0.2 gebracht, wollte dann VC 2.0.2 installieren um VCB 2.03 nutzen zu können.

So war zumindest der Plan :?

Das Aktualisieren der ESX Server hat auch unfallfrei geklappt. Allerdings klemmt es jetzt beim Update auf VC 2.0.2. Ziemlich am Ende der Installation kommt eine DB Fehler und die Installationsroutiene beginnt das Rollback.
Auf dem Datenbankserver findet sich dann diese Fehlermeldung beim Compilieren eines PL/SQL Moduls:

Code: Alles auswählen

PROCEDURE VCENTER2.VPX_STATS_ROLLUP
On line:  197
PLS-00201: identifier 'DBMS_LOCK' must be declared

Auf dem VC Server sieht das dann so aus:

Code: Alles auswählen

...
"ODBC error: (HY000) - [Oracle][ODBC][Ora]Trigger, procedure or function created with PL/SQL compilation error(s)." is returned when executing SQL statement "/* *************************************************************************
* Copyright 2004 VMware, Inc. All rights reserved. -- VMware Confidential
* *************************************************************************/

/*==================================================================
* rollup_oracle.sql
* vpx_stats_rollup procedure is called by vpxd to roll up stat
* samples from one interval to another. This script processes the
* stats da"


Der Fehler taucht auf wenn ich versuche das Update auf VC 2.0.2 zu installieren, egal ob ich die build 50618 oder die aktuelle Version 61426 verwende. Anschließend kann ich aber die alte 2.0.1 build 40644 problemlos reinstallieren (reparieren).
Kennt jemand dieses Problem?

Benutzeravatar
Experte
Beiträge: 1323
Registriert: 08.07.2005, 16:41
Wohnort: bei Trier

Beitragvon angoletti1 » 05.11.2007, 14:12

Hi,

wird der jetzt nicht viel weiterhelfen, aber man soll zuerst das VC updaten und dann die Hosts.
Hast du schon den Support bemüht? Vielleicht kann der helfen.

Grüße Chris

Profi
Beiträge: 535
Registriert: 04.01.2006, 12:06
Wohnort: Hamm

Beitragvon ostekl1 » 05.11.2007, 14:19

Hi,
danke für die Anteilnahme :grin:
Ja, bei VMware habe ich ein Ticket aufgemacht, aber so schnell sind die nicht ...

Warum muß denn eigentlich das VC vor den ESX Servern aktualisiert werden?

Benutzeravatar
Experte
Beiträge: 1323
Registriert: 08.07.2005, 16:41
Wohnort: bei Trier

Beitragvon angoletti1 » 05.11.2007, 14:51

Habe ich so (frag nicht in welcher Doku) gelesen. Ich denke mal, wenn die ESX zuerst upgedatet werden, reporten die Agents irgendwie anders ans VC oder mit Infos, die VC nicht verarbeiten kann (weil keine entsprechenden Tabellen in der DB existieren) oder Ähnliches. Wenn du dann VC zuerst updatest, legt die Installation neue Tabellen oder was auch immer an, welche dann gefüllt werden, wenn die ESX auf die entsprechende Version gehoben werden.

Ich hoffe das war halbwegs verständlich, ist halt meine Vermutung.

Grüße
Chris

Profi
Beiträge: 535
Registriert: 04.01.2006, 12:06
Wohnort: Hamm

Beitragvon ostekl1 » 05.11.2007, 16:16

Danke für den Hinweis!
Mittlerweile habe ich doch tatsächlich auch eine Antwort von VMware erhalten.
Der Übeltäter (wenn man es überhaupt so nennen kann) ist die Rechtestruktur am Oracle Server. Um die Installation durchzuführen werden Prozeduren auf dem Datenbankserver gestartet. Das darf wohl nicht einmal der DBA sondern nur der SYS user. Der muss dann auch die entsprechenden Oracle Rechte setzen.

Hier die originale Mitteilung von Anna (VMWare):

Dear Klaus,

Thank you for your Support Request.
My name is Anna and I will be assisting you with this Support Request.

PLS-00201: identifier 'DBMS_LOCK' must be declared
Looks like this would be the cause:

The schema used to manage the VirtualCenter objects must be able to use
Oracle's DBMS_LOCK built-in package, which means it requires execute
privileges on the package. Prior to installing the VirtualCenter upgrade on
an existing system, you (or your Oracle Database administrator (DBA)) must
log on to the Oracle Database server as the sysdba and grant the privilege,
as follows:

sqlplus system/<password>@<systemname> as sysdba
grant execute on dbms_lock to vpxadmin;

Note that the [@<systemname>] is relevant for a remote database host
connection only. For example, assuming a database instance installed on the
same host as the VirtualCenter Server system, the session might look as
follows:

C:\oracle\product\10.2.0\10gR2_Home\BIN>sqlplus system/techpubs as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on Fri Jan 5 10:01:51 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options

SQL> grant execute on dbms_lock to vpxadmin;

Grant succeeded.

SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 -
Production
With the Partitioning, OLAP and Data Mining options

C:\oracle\product\10.2.0\10gR2_Home\BIN>

For a fresh install of VirtualCenter on an existing Oracle Database Server,
you must create the schema and grant it the appropriate privileges prior to
VirtualCenter installation. Here's an example of a SQL*Plus schema-creation
session for an Oracle Database Server 10gR2 instance, from a Windows console:
sqlplus system/<password>[@<systemname>] as sysdba
CREATE SMALLFILE TABLESPACE "VIRTUALCENTER"
DATAFILE 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\TECHPUBS\virtualcenter'
SIZE 500M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

ALTER DATABASE DEFAULT TABLESPACE "VIRTUALCENTER";

CREATE USER "VPXADMIN" PROFILE "DEFAULT"
IDENTIFIED BY "*******"
DEFAULT TABLESPACE "VIRTUALCENTER"
TEMPORARY TABLESPACE "TEMP"
ACCOUNT UNLOCK;
GRANT "CONNECT" TO "VPXADMIN";
GRANT "RESOURCE" TO "VPXADMIN";
GRANT "CREATE VIEW" TO "VPXADMIN";
GRANT "EXECUTE ON DBMS_LOCK" TO "VPXADMIN";


After these (the update or clean part) has been run on the db, try the update
VC again.
If that would fail again, please include the full log. And if the install
succeeds after this, let me know.

Looking forward to hearing from you.
Kind regards,

Anna


Mit diesem Problem war ich sicherlich nicht alleine, und der eine oder andere könnte von Annas Mail ja auch profitieren .... ;-)

Ach ja, ein witziger Effekt noch:
Nach erfolgreicher Installation (es wurde überigens nicht gefragt ob die die Datenbank weiternutzen oder plattmachen will) habe ich mich am VC angemeldet und erstmal einen Schreck bekommen. Alle ESX Server ausgegraut!
Allerdings wurden in der Taskliste Agentenupdates für alle Server angezeigt die gerade erst bei 80% waren. Nach kurzer Zeit waren die Agenten dann aktualisiert und die Server wieder administrierbar (schwarz).


Zurück zu „vCenter / VMware VirtualCenter“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste