Before you start it is recommended that you have a complete backup so that
should there be any problems you can return to the status quo ante.
The steps are the following:
(1)Delete unnecessary data from the database.
(2)Unload the data from the database into a flat file.
(3)Edit the solid.ini file in order to limit the size to which the database
will grow.
(4)Delete the database.
(5)Recreate the database.
(6)Reload the data into it.
1) To delete unnecessary data from the database use the command
#ovdwevent -trim.
You can test to see what data you are about to delete using
#ovdwevent -trimnodelete
before you do it for real. For a full explanation of the options see the
ovdwevent (1) man page. However deleting data will not reduce the size of the
database file, it will simply free up space inside it. (Once you have got your
database under control you might consider setting up a cron job to delete
superfluous data on a regular basis, and thus prevent any problems caused by
the database filling up.)
2) Now unload the data from the database into a flat file with ovdwunloader.
Check the man page for a full explanation of the options. You will need to
export both the trend and event data, so you will need to run the command twice:
#ovdwunloader -file trend_output_file -trend -v
#ovdwunloader -file event_output_file -event -v
Stop OpenView
#ovstop -v
3) The default size of the database is a single two gigabytes file. You can
control the size by editing $OV_DB/analysis/default/solid.ini and setting the
FileSpec parameter in the Index File section. The FileSpec parameter describes
the location and the maximum size of the database file and accepts the
following three arguments:
database file name
max filesize
device number (optional)
You can also use the FileSpec parameter to divide the index file into multiple
files and onto multiple disks. To do this, specify another FileSpec parameter
identified by the number 2. The index file will be written to the second file
if it grows over the maximum value of the first FileSpec parameter. For example
the default value for this parameter is solid.db, 2147483647 (which equals 2 GB
expressed in bytes).
FileSpec_1=SOLID.DB 2147483647
In the following example, the parameters divide the index file on the disks C:,
D: and E: to be split after growing larger than 1 GB (=1073741824 bytes).
FileSpec_1=c:\soldb\solid.1 1073741824 1
FileSpec_2=D:\soldb\solid.2 1073741824 2
FileSpec_3=G:\soldb\solid.3 1073741824 3
NOTE. The index file locations entered must be valid path names in the server’s
operating system. For example, if the server runs on a UNIX operating system,
path separators must be slashes instead of backslashes. Although the database
files reside in different directories, the file names must be unique. In the
above example, it is assumed that C:, D: and E: partitions reside on separate
physical disks. Splitting the index file on multiple disks will increase the
performance of the server because multiple disk heads will access the data in
your index file. There is no limit to the number of index files you may use.
4) Now delete the database:
#cd $OV_DB/analysis/default
#rm solid.db
#rm solmsg.*
#rm ./log/sol*.log
5) Now recreate an empty database
#cd $OV_DB/analysis/default
#ovdbrun -x exit -u ovdb -p ovdb
#cd $OV_CONF/analysis/sqlScripts
#ovdbcheck -start
#ovdwquery -file tables_common.solid
#ovdwquery -file tables_event.solid
#ovdwquery -file tables_trend.solid
#ovdwquery -file tables_topo.solid
#ovdbcheck -stop
#ovstart -v
6) Now that OpenView is running again we need to reload the data from the flat
files into the database.
#ovdwloader -file trend_output_file -v
#ovdwloader -file event_output_file -v
September 26, 2011
July 19, 2011
Check free memory on unix server
Commands to check free memory on unix servers -
(1) vmstat 1 2 | tail -1 | awk '{printf "%d%s\n", ($5*4)/1024, "MB" }'
(2) top -h -d 1
(1) vmstat 1 2 | tail -1 | awk '{printf "%d%s\n", ($5*4)/1024, "MB" }'
(2) top -h -d 1
June 19, 2011
Script to monitor files (with a file name prefix) are updating in a directory
#!/bin/sh
OPCMON="/opt/OV/bin/opcmon"
MON_NAME=$1
line1=`eval date +'%Y%m%d/MSC'`
##### Count_M10C1.txt file keeps the count of total number of files in the input directory #########
FILE_M10C1="/tmp/count_M10C1.txt"
if [ ! -f $FILE_M10C1 ]; then
echo "File Does Not Exist"
`ls $line1 | grep M10C1 | wc -l >> /tmp/count_M10C1.txt`
exit 1
fi
var=`cat $FILE_M10C1`
for i in $var;
do
line=$i
done
##### Filecount is the variable which stores the current number of files in input directory ##########
Filecount=`ls "$line1" | grep M10C1* | wc -l`
##### Comparison is being done whether the current number of files in input directory is equal to the previous count #######
if [ $Filecount = $line ];
then
echo "Count Equal"
/opt/OV/bin/opcmon "${MON_NAME}=1"
else
echo "Count Unequal"
/opt/OV/bin/opcmon "${MON_NAME}=0"
fi
###### Store the current number of files in input directory to temporary file count_M10C1.txt ########
`ls $line1 | grep M10C1* | wc -l > /tmp/count_M10C1.txt`
OPCMON="/opt/OV/bin/opcmon"
MON_NAME=$1
line1=`eval date +'%Y%m%d/MSC'`
##### Count_M10C1.txt file keeps the count of total number of files in the input directory #########
FILE_M10C1="/tmp/count_M10C1.txt"
if [ ! -f $FILE_M10C1 ]; then
echo "File Does Not Exist"
`ls $line1 | grep M10C1 | wc -l >> /tmp/count_M10C1.txt`
exit 1
fi
var=`cat $FILE_M10C1`
for i in $var;
do
line=$i
done
##### Filecount is the variable which stores the current number of files in input directory ##########
Filecount=`ls "$line1" | grep M10C1* | wc -l`
##### Comparison is being done whether the current number of files in input directory is equal to the previous count #######
if [ $Filecount = $line ];
then
echo "Count Equal"
/opt/OV/bin/opcmon "${MON_NAME}=1"
else
echo "Count Unequal"
/opt/OV/bin/opcmon "${MON_NAME}=0"
fi
###### Store the current number of files in input directory to temporary file count_M10C1.txt ########
`ls $line1 | grep M10C1* | wc -l > /tmp/count_M10C1.txt`
October 21, 2010
Process Monitoring in OMU
Use the following script to do process monitoring of managed node from OMU -
To use the script, create a measurement threshold policy and write program name as : "script_name" "monitor_name" "process_name"
and put threshold 1 for not running condition and threshold 0 for running condition.
###ENV##
MON_NAME=$1
OPCMON="/opt/OV/bin/OpC/opcmon";
OPTION="-option proc"
CMD="/usr/bin/ps"
PROCESS=$2
PROGNAME=`basename $0`
###ENV#
OBJECT=""
#############################################Find whether file exists####
CMD_OUTPUT=`$CMD -ef | grep $PROCESS | grep -v grep | wc -l`
if [ ${CMD_OUTPUT} -eq 0 ]
then
STATUS=1;
else
STATUS=0;
fi
$OPCMON $MON_NAME=$STATUS
exit
To use the script, create a measurement threshold policy and write program name as : "script_name" "monitor_name" "process_name"
and put threshold 1 for not running condition and threshold 0 for running condition.
###ENV##
MON_NAME=$1
OPCMON="/opt/OV/bin/OpC/opcmon";
OPTION="-option proc"
CMD="/usr/bin/ps"
PROCESS=$2
PROGNAME=`basename $0`
###ENV#
OBJECT=""
#############################################Find whether file exists####
CMD_OUTPUT=`$CMD -ef | grep $PROCESS | grep -v grep | wc -l`
if [ ${CMD_OUTPUT} -eq 0 ]
then
STATUS=1;
else
STATUS=0;
fi
$OPCMON $MON_NAME=$STATUS
exit
October 8, 2010
How to remove and recreate all certificates in OMU
This procedure is very long and involves manual steps on all agents and redeployment of
policies to all agents. It should only be used in last resort when no other option is
available. For instance, this procedure may be considered if the private key of the
certificate authority has been lost or compromised.
This procedure consists of several subprocedures:
Remove all certificates on the management server
Recreate the trusted certificate on the management server
Recreate the server and node certificate on the management server
Backup the certificates and private keys on the management server
Prepare the management server for certificate and policy deployment
Redeploy policies to the management server
Redeploy policies to the agent on the management server
Recreate the certificates and redeploy policies on all the agents
These subprocedures are designed to be run in sequence. It is not safe to jump directly to
a subprocedure until you have completed all previous subprocedures. Once you have
started with the first subprocedure, you must complete all subprocedures to recover a
fully operational OVO setup.
Remove all certificates on the management server
All steps in this subprocess should be taken on the management server.
If the OVO management server runs on a cluster as a package or resource group, first put
the package or resource group into maintenance mode to avoid it from switching to
another node.
Stop all OVO management server, agent and L-core processes:
mgmtsv# ovstop opc ovoacomm
mgmtsv# ovc –kill
mgmtsv# ps –ef | grep ov
mgmtsv# ps –ef | grep opc
mgmtsv# ps –ef | grep coda
Ensure that all OVO and L-core processes have stopped. It is quite common that some
processes will not stop or that “ovc” will report an error. This is due to the fact that some
processes communicate locally through HTTPS and you are currently resolving a
problem with certificates that may adversely affect HTTPS communication. You will
have to kill these processes manually. Use “kill -9” if necessary.
Now remove all certificates on the management server:
OV Certificates Cookbook Version 1.0
Chapter 4 How to remove and recreate all certificates
NOTE: after taking the following steps the OVO setup will not be fully operational
until you proceed with all steps up to and including Recreate the certificates and
redeploy policies on all the agents, which implies manual steps on all agents and
redeployment of policies to all agents.
mgmtsv# ovcert -list
+---------------------------------------------------------+
| Keystore Content |
+---------------------------------------------------------+
| Certificates: |
| dcd0c94c-cb7d-7506-079a-9cc1b0282993 (*) |
+---------------------------------------------------------+
| Trusted Certificates: |
| CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993 |
+---------------------------------------------------------+
+---------------------------------------------------------+
| Keystore Content (OVRG: server) |
+---------------------------------------------------------+
| Certificates: |
| dcd0c94c-cb7d-7506-079a-9cc1b0282993 (*) |
+---------------------------------------------------------+
| Trusted Certificates: |
| CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993 (*) |
+---------------------------------------------------------+
mgmtsv#: ovcert -remove dcd0c94c-cb7d-7506-079a-9cc1b0282993
* Do you really want to remove the certificate with alias
'dcd0c94c-cb7d-7506-079a-9cc1b0282993' (yes(y)/no(n))? y
INFO: Certificate has been successfully removed.
mgmtsv# ovcert -remove CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993
* Do you really want to remove the certificate with alias
'CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993' (yes(y)/no(n))? y
INFO: Certificate has been successfully removed.
mgmtsv# ovcert -remove dcd0c94c-cb7d-7506-079a-9cc1b0282993 -ovrg server
* Do you really want to remove the certificate with alias
'dcd0c94c-cb7d-7506-079a-9cc1b0282993' (yes(y)/no(n))? y
INFO: Certificate has been successfully removed.
mgmtsv# ovcert -remove CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993 -ovrg server
* Do you really want to remove the certificate with alias
'CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993' (yes(y)/no(n))? y
INFO: Certificate has been successfully removed.
You should now see the following:
mgmtsv# ovcert -list
+---------------------------------------------------------+
| Keystore Content |
+---------------------------------------------------------+
| Certificates: |
+---------------------------------------------------------+
| Trusted Certificates: |
+---------------------------------------------------------+
+---------------------------------------------------------+
| Keystore Content (OVRG: server) |
+---------------------------------------------------------+
| Certificates: |
+---------------------------------------------------------+
| Trusted Certificates: |
OV Certificates Cookbook Version 1.0
Chapter 4 How to remove and recreate all certificates Page 26
+---------------------------------------------------------+
You must now proceed with step Recreate the trusted certificate on the management
server.
4.2 Recreate the trusted certificate on the management server
All steps in this subprocess should be taken on the management server.
Since all generated certificates must be signed by the certificate authority, as a first step
we must recreate the trusted certificate, also referred to as the root certificate or the CA
certificate.
To recreate the trusted certificate on the server:
mgmstv# ovcm -newcacert
INFO: Generating a new CA key pair...
INFO: Installing...
INFO: Installation was successful.
You should now see the following:
mgmtsv# ovcert -list
+---------------------------------------------------------+
| Keystore Content |
+---------------------------------------------------------+
| Certificates: |
+---------------------------------------------------------+
| Trusted Certificates: |
+---------------------------------------------------------+
+---------------------------------------------------------+
| Keystore Content (OVRG: server) |
+---------------------------------------------------------+
| Certificates: |
+---------------------------------------------------------+
| Trusted Certificates: |
| CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993 (*) |
+---------------------------------------------------------+
Now you can export the trusted certificate from the server side and import it on the node
side:
mgmtsv# ovcert -exporttrusted -file /tmp/trustedcertif -ovrg server
INFO: Trusted certificates have been successfully exported to file '/tmp/
trustedcertif'.
mgmtsv# ovcert -importtrusted -file /tmp/trustedcertif
INFO: Import operation was successful.
You should now see the following:
mgmtsv# ovcert -list
+---------------------------------------------------------+
| Keystore Content |
+---------------------------------------------------------+
| Certificates: |
OV Certificates Cookbook Version 1.0
Chapter 4 How to remove and recreate all certificates Page 27
+---------------------------------------------------------+
| Trusted Certificates: |
| CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993 |
+---------------------------------------------------------+
+---------------------------------------------------------+
| Keystore Content (OVRG: server) |
+---------------------------------------------------------+
| Certificates: |
+---------------------------------------------------------+
| Trusted Certificates: |
| CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993 (*) |
+---------------------------------------------------------+
You must now proceed with step Recreate the server and node certificate on the
management server.
Recreate the server and node certificate on the management
server
All steps in this subprocess should be taken on the management server, but they depend
on whether the OVO management server runs standalone or as a package or resource
group on a cluster.
IF The OVO management server runs on a cluster as a package or
resource group
Issue and import a new server certificate:
mgmtsv# ovcm -issue -file /tmp/certif -name $(hostname package/virtual node) -pass mypwd -coreid
$(ovcoreid –ovrg server)
INFO: Issued certificate was written to file '/tmp/certif'.
mgmtsv# ovcert -importcert -file /tmp/certif -pass mypwd -ovrg server
INFO: Import operation was successful.
mgmtsv# rm /tmp/certif
Issue and import a new node certificate:
mgmtsv# ovcm -issue -file /tmp/certif -name $(hostname active cluster node) -pass mypwd -coreid
$(ovcoreid)
INFO: Issued certificate was written to file '/tmp/certif'.
mgmtsv# ovcert -importcert -file /tmp/certif -pass mypwd
INFO: Import operation was successful.
mgmtsv# rm /tmp/certif.
policies to all agents. It should only be used in last resort when no other option is
available. For instance, this procedure may be considered if the private key of the
certificate authority has been lost or compromised.
This procedure consists of several subprocedures:
Remove all certificates on the management server
Recreate the trusted certificate on the management server
Recreate the server and node certificate on the management server
Backup the certificates and private keys on the management server
Prepare the management server for certificate and policy deployment
Redeploy policies to the management server
Redeploy policies to the agent on the management server
Recreate the certificates and redeploy policies on all the agents
These subprocedures are designed to be run in sequence. It is not safe to jump directly to
a subprocedure until you have completed all previous subprocedures. Once you have
started with the first subprocedure, you must complete all subprocedures to recover a
fully operational OVO setup.
Remove all certificates on the management server
All steps in this subprocess should be taken on the management server.
If the OVO management server runs on a cluster as a package or resource group, first put
the package or resource group into maintenance mode to avoid it from switching to
another node.
Stop all OVO management server, agent and L-core processes:
mgmtsv# ovstop opc ovoacomm
mgmtsv# ovc –kill
mgmtsv# ps –ef | grep ov
mgmtsv# ps –ef | grep opc
mgmtsv# ps –ef | grep coda
Ensure that all OVO and L-core processes have stopped. It is quite common that some
processes will not stop or that “ovc” will report an error. This is due to the fact that some
processes communicate locally through HTTPS and you are currently resolving a
problem with certificates that may adversely affect HTTPS communication. You will
have to kill these processes manually. Use “kill -9” if necessary.
Now remove all certificates on the management server:
OV Certificates Cookbook Version 1.0
Chapter 4 How to remove and recreate all certificates
NOTE: after taking the following steps the OVO setup will not be fully operational
until you proceed with all steps up to and including Recreate the certificates and
redeploy policies on all the agents, which implies manual steps on all agents and
redeployment of policies to all agents.
mgmtsv# ovcert -list
+---------------------------------------------------------+
| Keystore Content |
+---------------------------------------------------------+
| Certificates: |
| dcd0c94c-cb7d-7506-079a-9cc1b0282993 (*) |
+---------------------------------------------------------+
| Trusted Certificates: |
| CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993 |
+---------------------------------------------------------+
+---------------------------------------------------------+
| Keystore Content (OVRG: server) |
+---------------------------------------------------------+
| Certificates: |
| dcd0c94c-cb7d-7506-079a-9cc1b0282993 (*) |
+---------------------------------------------------------+
| Trusted Certificates: |
| CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993 (*) |
+---------------------------------------------------------+
mgmtsv#: ovcert -remove dcd0c94c-cb7d-7506-079a-9cc1b0282993
* Do you really want to remove the certificate with alias
'dcd0c94c-cb7d-7506-079a-9cc1b0282993' (yes(y)/no(n))? y
INFO: Certificate has been successfully removed.
mgmtsv# ovcert -remove CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993
* Do you really want to remove the certificate with alias
'CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993' (yes(y)/no(n))? y
INFO: Certificate has been successfully removed.
mgmtsv# ovcert -remove dcd0c94c-cb7d-7506-079a-9cc1b0282993 -ovrg server
* Do you really want to remove the certificate with alias
'dcd0c94c-cb7d-7506-079a-9cc1b0282993' (yes(y)/no(n))? y
INFO: Certificate has been successfully removed.
mgmtsv# ovcert -remove CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993 -ovrg server
* Do you really want to remove the certificate with alias
'CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993' (yes(y)/no(n))? y
INFO: Certificate has been successfully removed.
You should now see the following:
mgmtsv# ovcert -list
+---------------------------------------------------------+
| Keystore Content |
+---------------------------------------------------------+
| Certificates: |
+---------------------------------------------------------+
| Trusted Certificates: |
+---------------------------------------------------------+
+---------------------------------------------------------+
| Keystore Content (OVRG: server) |
+---------------------------------------------------------+
| Certificates: |
+---------------------------------------------------------+
| Trusted Certificates: |
OV Certificates Cookbook Version 1.0
Chapter 4 How to remove and recreate all certificates Page 26
+---------------------------------------------------------+
You must now proceed with step Recreate the trusted certificate on the management
server.
4.2 Recreate the trusted certificate on the management server
All steps in this subprocess should be taken on the management server.
Since all generated certificates must be signed by the certificate authority, as a first step
we must recreate the trusted certificate, also referred to as the root certificate or the CA
certificate.
To recreate the trusted certificate on the server:
mgmstv# ovcm -newcacert
INFO: Generating a new CA key pair...
INFO: Installing...
INFO: Installation was successful.
You should now see the following:
mgmtsv# ovcert -list
+---------------------------------------------------------+
| Keystore Content |
+---------------------------------------------------------+
| Certificates: |
+---------------------------------------------------------+
| Trusted Certificates: |
+---------------------------------------------------------+
+---------------------------------------------------------+
| Keystore Content (OVRG: server) |
+---------------------------------------------------------+
| Certificates: |
+---------------------------------------------------------+
| Trusted Certificates: |
| CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993 (*) |
+---------------------------------------------------------+
Now you can export the trusted certificate from the server side and import it on the node
side:
mgmtsv# ovcert -exporttrusted -file /tmp/trustedcertif -ovrg server
INFO: Trusted certificates have been successfully exported to file '/tmp/
trustedcertif'.
mgmtsv# ovcert -importtrusted -file /tmp/trustedcertif
INFO: Import operation was successful.
You should now see the following:
mgmtsv# ovcert -list
+---------------------------------------------------------+
| Keystore Content |
+---------------------------------------------------------+
| Certificates: |
OV Certificates Cookbook Version 1.0
Chapter 4 How to remove and recreate all certificates Page 27
+---------------------------------------------------------+
| Trusted Certificates: |
| CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993 |
+---------------------------------------------------------+
+---------------------------------------------------------+
| Keystore Content (OVRG: server) |
+---------------------------------------------------------+
| Certificates: |
+---------------------------------------------------------+
| Trusted Certificates: |
| CA_dcd0c94c-cb7d-7506-079a-9cc1b0282993 (*) |
+---------------------------------------------------------+
You must now proceed with step Recreate the server and node certificate on the
management server.
Recreate the server and node certificate on the management
server
All steps in this subprocess should be taken on the management server, but they depend
on whether the OVO management server runs standalone or as a package or resource
group on a cluster.
IF The OVO management server runs on a cluster as a package or
resource group
Issue and import a new server certificate:
mgmtsv# ovcm -issue -file /tmp/certif -name $(hostname package/virtual node) -pass mypwd -coreid
$(ovcoreid –ovrg server)
INFO: Issued certificate was written to file '/tmp/certif'.
mgmtsv# ovcert -importcert -file /tmp/certif -pass mypwd -ovrg server
INFO: Import operation was successful.
mgmtsv# rm /tmp/certif
Issue and import a new node certificate:
mgmtsv# ovcm -issue -file /tmp/certif -name $(hostname active cluster node) -pass mypwd -coreid
$(ovcoreid)
INFO: Issued certificate was written to file '/tmp/certif'.
mgmtsv# ovcert -importcert -file /tmp/certif -pass mypwd
INFO: Import operation was successful.
mgmtsv# rm /tmp/certif.
October 2, 2010
OMU 9 Configuration Backup
Default OMU 9 configuration backup is available at following location and configuration backup is taken through the GUI using option Tasks -> Download all –
/opt/OV/OMU/adminUI/data/clipboard/
/opt/OV/OMU/adminUI/data/clipboard/
January 15, 2010
OMW to OMU Message forwarding
Problem -
I am having two management server architecture in my environment, wherein OMU acts as Manager of Managers and OMW monitors all the servers and applications.
I want to forward all the alerts from OMW to OMU.
Solution -
Whenver you add any node in OMW, add the same node simultaneously in OMU.
To add node in OMU, follow the below steps -
(1) Add node in OMU through Actions -> Node -> Add, specify the node name, Fully Qualified Node Name, server type etc.
Uncheck the Automatic Software De-installation, Check communication options that core id is 00000000000000000
(2) Once the node addition is successful, get the ovcoreid from the OMW server for the same node.
(3) execute following command in OMU -
/opt/OV/bin/OpC/utils/opcnode -chg_id
for example : /opt/OV/bin/OpC/utils/opcnode -chg_id abc.vtg BBC_SOL_SPARC solaris COMM_BBC NETWORK_IP unix 034fere34fd343fer
Once the command is executed successfully, move the node to appropriate node group
(4) Restart OMU services : /opt/OV/bin/opcsv -stop
/opt/OV/bin/opcsv -start
I am having two management server architecture in my environment, wherein OMU acts as Manager of Managers and OMW monitors all the servers and applications.
I want to forward all the alerts from OMW to OMU.
Solution -
Whenver you add any node in OMW, add the same node simultaneously in OMU.
To add node in OMU, follow the below steps -
(1) Add node in OMU through Actions -> Node -> Add, specify the node name, Fully Qualified Node Name, server type etc.
Uncheck the Automatic Software De-installation, Check communication options that core id is 00000000000000000
(2) Once the node addition is successful, get the ovcoreid from the OMW server for the same node.
(3) execute following command in OMU -
/opt/OV/bin/OpC/utils/opcnode -chg_id
for example : /opt/OV/bin/OpC/utils/opcnode -chg_id abc.vtg BBC_SOL_SPARC solaris COMM_BBC NETWORK_IP unix 034fere34fd343fer
Once the command is executed successfully, move the node to appropriate node group
(4) Restart OMU services : /opt/OV/bin/opcsv -stop
/opt/OV/bin/opcsv -start
Switch management server from OMW to OMU in case OMW failure
Problem -
I am having two management server architecture and out of which Operation Manager for Unix acts as Manager of Managers which receives alerts from OMW, NNM, BAC etc. and other management server is OMW which monitors servers and applications.
I want to forward all alerts to OMU from OMW in case OMW services goes down or OMW server is not available.
Solution -
To achieve above target, perform following actions -
(1) Create a failover policy in OMW.
Failover policy would of type Flexible Management Policy with following content -
#
# Configuration file
# defines two action-allow managers
# messages are always send to the primary manager
#
TIMETEMPLATES
#none
RESPMGRCONFIGS
RESPMGRCONFIG
DESCRIPTION "responsible mgrs for Nodes in VAA"
#Secondary managers have to be specified,
#but this section is not used by OpenView Operations for Windows
SECONDARYMANAGERS
SECONDARYMANAGER
NODE IP 0.0.0.0 ""
DESCRIPTION "HP OpenView Operation for Unix Management Server"
SECONDARYMANAGER
NODE IP 0.0.0.0 """
DESCRIPTION "HP OpenView Opearion for Windows Management Server"
ACTIONALLOWMANAGERS
ACTIONALLOWMANAGER
NODE IP 0.0.0.0 """
DESCRIPTION "HP OpenView Operation for Unix Management Server"
ACTIONALLOWMANAGER
NODE IP 0.0.0.0 """
DESCRIPTION "HP OpenView Opearion for Windows Management Server"
# Recommended: include the primary manager into the list of action-allow managers
# even if all possible managers are already listed
ACTIONALLOWMANAGER
NODE IP 0.0.0.0 "$OPC_PRIMARY_MGR"
DESCRIPTION "current primary manager"
MSGTARGETRULES
MSGTARGETRULE
DESCRIPTION "always send all messages to current primary manager"
MSGTARGETRULECONDS
MSGTARGETMANAGERS
MSGTARGETMANAGER
TIMETEMPLATE "$OPC_ALWAYS"
OPCMGR IP 0.0.0.0 "$OPC_PRIMARY_MGR"
(2) Deploy the policy on all of the managed nodes
(3) When you want to switch management server from OMW to OMU, run following command on OMU server :
opcragt -primmgr
Wait till the command execution completes and check whether command is executed succesfully. If it goes successful then management server switching is done.
(4) If you want to revert the management server back to OMW then issue the same command on OMW server :
opcragt -primmgr
I am having two management server architecture and out of which Operation Manager for Unix acts as Manager of Managers which receives alerts from OMW, NNM, BAC etc. and other management server is OMW which monitors servers and applications.
I want to forward all alerts to OMU from OMW in case OMW services goes down or OMW server is not available.
Solution -
To achieve above target, perform following actions -
(1) Create a failover policy in OMW.
Failover policy would of type Flexible Management Policy with following content -
#
# Configuration file
# defines two action-allow managers
# messages are always send to the primary manager
#
TIMETEMPLATES
#none
RESPMGRCONFIGS
RESPMGRCONFIG
DESCRIPTION "responsible mgrs for Nodes in VAA"
#Secondary managers have to be specified,
#but this section is not used by OpenView Operations for Windows
SECONDARYMANAGERS
SECONDARYMANAGER
NODE IP 0.0.0.0 "
DESCRIPTION "HP OpenView Operation for Unix Management Server"
SECONDARYMANAGER
NODE IP 0.0.0.0 ""
DESCRIPTION "HP OpenView Opearion for Windows Management Server"
ACTIONALLOWMANAGERS
ACTIONALLOWMANAGER
NODE IP 0.0.0.0 ""
DESCRIPTION "HP OpenView Operation for Unix Management Server"
ACTIONALLOWMANAGER
NODE IP 0.0.0.0 ""
DESCRIPTION "HP OpenView Opearion for Windows Management Server"
# Recommended: include the primary manager into the list of action-allow managers
# even if all possible managers are already listed
ACTIONALLOWMANAGER
NODE IP 0.0.0.0 "$OPC_PRIMARY_MGR"
DESCRIPTION "current primary manager"
MSGTARGETRULES
MSGTARGETRULE
DESCRIPTION "always send all messages to current primary manager"
MSGTARGETRULECONDS
MSGTARGETMANAGERS
MSGTARGETMANAGER
TIMETEMPLATE "$OPC_ALWAYS"
OPCMGR IP 0.0.0.0 "$OPC_PRIMARY_MGR"
(2) Deploy the policy on all of the managed nodes
(3) When you want to switch management server from OMW to OMU, run following command on OMU server :
opcragt -primmgr
Wait till the command execution completes and check whether command is executed succesfully. If it goes successful then management server switching is done.
(4) If you want to revert the management server back to OMW then issue the same command on OMW server :
opcragt -primmgr
Unable to get proper severity symbol against node icon
Problem -
Unable to get proper severity symbol against the icon of the nodes in OMW.
For example, if a server A has got an alert of severity critical then the corresponding node icon should represent red symbol.
Solution -
Restart OMW services using command vpstat -3 -r and once command is successful, verify that all the services running fine using following command :
vpstat -3
Unable to get proper severity symbol against the icon of the nodes in OMW.
For example, if a server A has got an alert of severity critical then the corresponding node icon should represent red symbol.
Solution -
Restart OMW services using command vpstat -3 -r and once command is successful, verify that all the services running fine using following command :
vpstat -3
January 12, 2010
Unable to do service discovery of nodes in OMW
Problem -
I am unable to get service map of the nodes which are added in OMW, the agent services are running absolutely fine and discovery policies are also been deployed but still i am not able to get service map of the nodes.
Solution -
Please perform following options and check whether you are able to get service map of the nodes -
a. Remove all the policies from this Agent
b. Confirm you have no policies on the Agent with the
command ("ovpolicy –list")
c. Kill the Agent the Agent (“ovc –kill”)
d. Rename the file system.txt to system.txt.old
e. Delete all the file in the folder “C:\Documents and
Settings\All Users\Application Data\HP\HP BTO Software\tmp\agtrep”
f. Re-start the Agent
g. Re-deploy the service discovery policies
I am unable to get service map of the nodes which are added in OMW, the agent services are running absolutely fine and discovery policies are also been deployed but still i am not able to get service map of the nodes.
Solution -
Please perform following options and check whether you are able to get service map of the nodes -
a. Remove all the policies from this Agent
b. Confirm you have no policies on the Agent with the
command ("ovpolicy –list")
c. Kill the Agent the Agent (“ovc –kill”)
d. Rename the file system.txt to system.txt.old
e. Delete all the file in the folder “C:\Documents and
Settings\All Users\Application Data\HP\HP BTO Software\tmp\agtrep”
f. Re-start the Agent
g. Re-deploy the service discovery policies
January 7, 2010
OvEpMsgActSrv Service in OMW is aborted
Problem -
In OMW 8.10 OvEpMsgActSrv Service is aborted abnormally and even restarting the servicesand rebooting the system it didn't started
Solution - Stopped OMW services using vpstat -3 -r stop and removed following folder
$OvShareDir\server\datafiles\bbc\snf\OvEpMessageActionServer
and then restarted services using vpstat -3 -r start
which finally resolvd the issue.
In OMW 8.10 OvEpMsgActSrv Service is aborted abnormally and even restarting the servicesand rebooting the system it didn't started
Solution - Stopped OMW services using vpstat -3 -r stop and removed following folder
$OvShareDir\server\datafiles\bbc\snf\OvEpMessageActionServer
and then restarted services using vpstat -3 -r start
which finally resolvd the issue.
Subscribe to:
Posts (Atom)