ldornak
Contributor
Contributor

VC2.0.2 Disconnect from Oracle

Jump to solution

We're running VC 2.0.2 with Oracle 10g for the DB. Whenever we restart the VC server, VirtualCenter service fails to start. Here's the vpxd.log:

Log for VMware VirtualCenter, pid=3856, version=2.0.2, build=build-61426, option=Release, section=2
Current working directory: C:\WINDOWS\system32
Initializing SSL context
Vmacore::InitSSL: doVersionCheck = true, handshakeTimeoutUs = 120000000
NFC connection accept timeout: 180000 milliseconds
NFC request timeout: 180000 milliseconds
NFC read timeout: 60000 milliseconds
NFC write timeout: 600000 milliseconds
Starting VMware VirtualCenter 2.0.2 build-61426
Log directory: C:\WINDOWS\TEMP\vpx.
Account name: SYSTEM
Enabled low-frag process heap.
Enabled low-frag crt heap.
34 max LROs
6 reserved internal LROs
6 reserved blocker LROs
6 reserved short LROs
4 reserved long LROs
600-second task lifetime
Unable to get exclusive access to VC repository. Please check if another VirtualCenter instance is running against the same schema.
Failed to intialize VMware VirtualCenter. Shutting down...

If we look at the DB, it shows vpxadmin still connected although we only have one VC server and the service is currently stopped. We have been working around the problem by instructing the DBAs to restart the database. After that, the service starts fine. Anyone else seen this issue?

0 Kudos
1 Solution

Accepted Solutions
esiebert7625
Immortal
Immortal

You don't want to set it to low to negatively impact the server. VC is always writing to it's database to log the performance history of the VM's so it's probably writing every minute or so. Once you reboot the server it is probably about 3-4 minutes before VC tries to open it's database so I would say at least 2-3 minutes. Also if you have support with VMware I would also ask them, unless your Oracle environment is configured unusually you usually shouldn't have to worry about this.

-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

Thanks, Eric

Visit my website:

-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

View solution in original post

0 Kudos
6 Replies
esiebert7625
Immortal
Immortal

Did you grant the extra dbms_lock privilege to the vc database account in oracle?

Oracle Database Server Preinstallation Tasks

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 upgrade on an existing system, you (or your Oracle Database administrator (DBA)) must log in to the Oracle Database server as the sysdba and grant the privilege, as follows:

sqlplus system/@ as sysdba

grant execute on dbms_lock to vpxadmin;

Note that the 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/[@] 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";

-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

Thanks, Eric

Visit my website:

-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

ldornak
Contributor
Contributor

I asked our DBA if vpxadmin had execute permissions on dbms_lock.

Here's his reply:

It does. As a matter of fact, vpxadmin has the DBA role, and on top of that, has ‘grant execute' on dbms_lock specified.
Check it out:
CREATE USER VPXADMIN
IDENTIFIED BY VALUES 'D3645DAA57EA91AB'
DEFAULT TABLESPACE VIRTUALCENTER
TEMPORARY TABLESPACE TEMP
PROFILE DEFAULT
ACCOUNT UNLOCK;
-- 3 Roles for VPXADMIN
GRANT RESOURCE TO VPXADMIN;
GRANT CONNECT TO VPXADMIN;
GRANT DBA TO VPXADMIN;
ALTER USER VPXADMIN DEFAULT ROLE ALL;
-- 2 System Privileges for VPXADMIN
GRANT CREATE VIEW TO VPXADMIN WITH ADMIN OPTION;
GRANT UNLIMITED TABLESPACE TO VPXADMIN;
-- 1 Object Privilege for VPXADMIN
GRANT EXECUTE ON SYS.DBMS_LOCK TO VPXADMIN;

0 Kudos
esiebert7625
Immortal
Immortal

So if the server is just being re-booted the VC application may not be closing the database connections. Have you tried shutting down the VC service before rebooting? Alternately you can check with your dba's to see if there is a connection timeout on their side that will automatically close a database connection after a period of inactivity. We use Oracle with VC also and have only seen this problem once in perhaps a dozen or more reboots, that was on an older version of VC also (think it was 2.0.1)

-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

Thanks, Eric

Visit my website:

-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

ldornak
Contributor
Contributor

I think that's exactly what's happening. VC is not gracefully closing the db connections. I have tried stopping and starting the service with the same results. I've also tried stopping the service before a reboot with the same results. I will check with the DBAs to see if a connection time-out can be set. What's a good time-out value to use?

0 Kudos
esiebert7625
Immortal
Immortal

You don't want to set it to low to negatively impact the server. VC is always writing to it's database to log the performance history of the VM's so it's probably writing every minute or so. Once you reboot the server it is probably about 3-4 minutes before VC tries to open it's database so I would say at least 2-3 minutes. Also if you have support with VMware I would also ask them, unless your Oracle environment is configured unusually you usually shouldn't have to worry about this.

-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

Thanks, Eric

Visit my website:

-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=-=-=-=-

View solution in original post

0 Kudos
ldornak
Contributor
Contributor

Thanks. I'll call support.

0 Kudos