200-002918 Vom61 TS PDF

Veritas Operations Manager 6.
1:
Troubleshooting
200-002918
Copyright © 2015 Symantec Corporation. All rights reserved. Symantec, the Symantec Logo,
and VERITAS are trademarks or registered trademarks of Symantec Corporation or its affiliates
in the U.S. and other countries. Other names may be trademarks of their respective owners.
THIS PUBLICATION IS PROVIDED “AS IS” AND ALL EXPRESS OR IMPLIED CONDITIONS,
REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE
DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY
INVALID. SYMANTEC CORPORATION SHALL NOT BE LIABLE FOR INCIDENTAL OR
CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE
OF THIS PUBLICATION. THE INFORMATION CONTAINED HEREIN IS SUBJECT TO CHANGE
WITHOUT NOTICE.
No part of the contents of this book may be reproduced or transmitted in any form or by any
means without the written permission of the publisher.
Symantec Corporation
World Headquarters
350 Ellis Street
Mountain View, CA 94043
United States
http://www.symantec.com
Lead Subject Matter Technical Contributors and

Course Developer
Experts Reviewers
Aditya Deshpande
Deepak Karwande Alexander Krause
Hafiz Rehman Bilge Gerrits
Kim Nielsen Carlos Ortega Gonzalez
Seema Mangaonkar Maurizio Lancia Ganesh Iyer
Manish Arya Ivette Reyes
Michael Auria Manoj Singal
Matthias Rauschenberg
Mandar Joshi
Table of Contents
Course Introduction
VOM troubleshooting course overview .............................................................................. Intro‐2
Lesson 1: VOM Architecture and Operation Framework
Importance of VOM .................................................................................................................... 1‐4
VOM Architecture ....................................................................................................................... 1‐8
Operation Framework .............................................................................................................. 1‐14
Hardware and Software Compatibility List ............................................................................... 1‐21
Lesson 2: Monitoring VOM
Checking Management Server .................................................................................................... 2‐4
Checking Managed Hosts ......................................................................................................... 2‐10
Viewing VOM‐related Files ....................................................................................................... 2‐15
Lesson 3: Troubleshooting VOM Part 1
Installation issues ....................................................................................................................... 3‐4
Management Server configuration issues ................................................................................ 3‐10
Add host issues ......................................................................................................................... 3‐13
Log‐in/security/LDAP issues ..................................................................................................... 3‐17
User interface issues ................................................................................................................. 3‐21
Deployment/add‐on issues....................................................................................................... 3‐29
Viewing error‐codes using SORT .............................................................................................. 3‐31
Lesson 4: Troubleshooting VOM Part 2
Configuring deep discovery for Storage Insight add‐on ............................................................. 4‐4
Discovering SAN fabric switches using Fabric Insight add‐on .................................................. 4‐10
Analyzing VOM reports for troubleshooting VCS ..................................................................... 4‐18
Appendix A: Labs
Lab 1: Lab environment overview ............................................................................................. A‐3
Intro Lab A: Using the VMWare workstation environment……………………………………………….A‐9
Exercise 1: Starting virtual computers ............................................................................ A‐12
Exercise 2: Logging on to virtual computers ................................................................... A‐16
Exercise 3: Adjusting the VMware view……………………………………………………………………….A‐19
Exercise 4: Testing passwordless ssh for the root user .................................................. A‐20
Exercise 5: Running basic commands ............................................................................. A‐22
Intro Lab B: Using the Granite lab environment………………………………………………………………A‐26
Exercise 1: Connecting to the lab environment ............................................................. A‐29
Exercise 2: Connecting to virtual machines .................................................................... A‐30
Exercise 3: Testing passwordless ssh for the root user .................................................. A‐32
TOC - i
Exercise 4: Running basic commands ............................................................................. A‐34

Lab 2: Checking VOM 6.1 environment ................................................................................... A‐39
Exercise 1: Determining the role of systems in the environment ................................. A‐40
Exercise 2: Verifying processes and services running on VOM MS ................................. A‐44
Exercise 3: Verifying processes and services running on VOM MH ................................ A‐46
Exercise 4: Checking log files on VOM MS and MH ......................................................... A‐48

Lab 3: Troubleshooting VOM ................................................................................................... A‐51
Exercise 1: Testing how xprtld works ............................................................................ A‐53
Exercise 2: Troubleshooting host configuration issues ................................................... A‐55
Exercise 3: Testing how patching works .......................................................................... A‐58
Exercise 4: Troubleshooting add host issues ................................................................... A‐60
Exercise 5: Testing behavior of the MS and estimating file space usage ........................ A‐64
Exercise 6: Using vomgather.pl to gather VOM data ...................................................... A‐67

Lab 4: Analyzing logs for troubleshooting issues ..................................................................... A‐69
Exercise 1: Analyzing configuration log file ................................................................... A‐71
Exercise 2: Analyzing add host log file ............................................................................. A‐74

Appendix B: Job‐aids
Ask before troubleshooting ............................................................................................. B‐1
A case example: Reporting escalation cases to Engineering from Support ...................... B‐2
Steps to upload a PostgreSQL database for troubleshooting ........................................... B‐5
Knowledge Management articles linked by cases ............................................................. B‐7

TOC - ii
Welcome to the one-day instructor-led training on “Veritas Operations Manager
6.1: Troubleshooting”.
The IA curriculum is a series of courses designed to provide a full range of
expertise with Symantec high availability solutions.
The Storage Foundation course covers basic concepts, installation and
configuration, focusing on running application and database services.
The Cluster Server course covers installation and configuration of common VCS
configurations, running highly available application for local clustering.
The VOM Administration course focuses on managing HA environments in
multisite data centers using VOM.
The What’s New range of courses for each solution covers new features and
enhancements in the current releases of respective products.
This training provides comprehensive instruction on the basic troubleshooting
techniques for supporting Veritas Operations Manager in customer environment.
The course covers architecture and framework that enables you to test the
discovery cycle. You learn how to verify processes, services running, commands
to start and stop services, and respond to faults/errors/notifications.
In the troubleshooting section, the course provides comprehensive instruction on

how to analyze logs, basic components, and troubleshoot problems within VOM
environment.
This course also provides information to help you search for the error codes,
possible faults, including brief job-aids.
This course assumes that you have an administrator-level understanding of Veritas
Operations Manager 6.x. You must understand how to configure hosts, storage devices
using VOM console and manage networking in multiserver environments. Proficiency
managing Veritas Storage Foundation family products, including Veritas Cluster Server,
Volume Manager, and File System, is highly desirable. You must also have basic
knowledge of UNIX and Windows platform.
The content for troubleshooting training is covered through lessons guides and lab
guides. The lesson guide covers slides presented by your instructor along with the
notes. The lab guide covers lab exercises to enable you to practice your new skills and
supported log files or screenshots for further reference. The supplements include job-
aid, flashcard, and supplementary material that can be used as on-the-job reference
material.
• Job-aid for ‘Using Symantec Web resources’

• Flashcard for ‘Ask before troubleshooting’
• Videos on Connect: http://www.symantec.com/connect/vom-videos
• About VOM: https://sort.symantec.com/vom
Welcome to the “VOM Architecture and Operation Framework” lesson.
1-1
This is the first lesson in this course.
1-2
In this lesson, you learn how VOM is important for Symantec customers and why Technical
Support Engineers must be good at supporting VOM. You also learn about the architecture and
the operation framework, and how the components work together in VOM. In addition, you
learn about the hardware and software compatibility list for supporting VOM 6.1 in the data
center.
1-3
This is the “Importance of VOM” topic.
1-4
Veritas Operations Manager is a centralized, operationally-focused tool that enhances the
management of Storage Foundation, Dynamic Multi-Pathing, Cluster Server, and ApplicationHA
across various applications, servers, virtualization, and storage platforms. In addition to
providing a complete centralized management interface for those environments, VOM
discovers a wealth of detail about the adjacent configuration. This includes visibility into the
storage array configuration, the SAN connectivity and fabrics, multi-vendor virtualization and
server platforms, and applications, such as MS SQL Server and Oracle Databases.
By having a wide perspective on the configuration, VOM enables customers to:
• Minimize risk by enabling them to better understand the dependencies in their
configurations from various perspectives
• Accelerate operations by standardizing on proven Storage and Availability solutions from
Symantec
• Optimize storage and server assets through better reporting and simplified remediation
1-5
As a tool, Veritas Operations Manager has high visibility throughout Symantec. It is designed as
a value-add for Storage Foundation customers. If they buy SF, they get VOM for free.
VOM makes SF a more valuable solution to keep. VOM ships with SF, SFHA, DMP, and AppHA. It
is designed to eventually replace various SF family GUIs, such as VEA and VCS Java console.
Additionally, VOM is the basis for IT Resiliency Platform (ITRP) and Symantec’s platform for DR
solutions.
1-6
With the help of Operations Manager, you can perform various operations to gain visibility and
control across all SF and VCS features. The tool enables standardized operations for cluster
server, volume replicator, volume manager, file system, and dynamic multi-pathing. The uptime
reports and fault/risk analysis reports help to ensure availability. VOM provides utilization
reports to better understand storage requirements and optimizes storage by migrating from
thick to thin and performing thin storage reclamation. Finally, the licensing reports and patching
functionality through VOM enables you to maintain compliance in the data center.
1-7
This is the “VOM Architecture” topic.
1-8
The slide displays a distributed client-server architecture of Veritas Operations Manager. It
consists of a Management Server, a database server, a Web server, and one or more managed
hosts, each hosting an agent. The Storage Foundation Managed Host (SFMH) agent is a process
that collects status information from all resources on the host and relays that information to
VOM. Typically, a managed host is a production server on which components of Storage
Foundation products are installed and running. A typical data center can have thousands of
hosts using some or all of the Storage Foundation range of products. VOM is aimed at
managing Storage Foundation hosts, and the agent is installed as a package with a Storage
Foundation installation.
Another element of the architecture is the control host that aids in agentless host discovery.
Hosts that do not have the SFMH agent installed are called Agentless hosts.
Discovery hosts can have the Fabric Insight Add-on installed and they discover the SAN
switches.
An additional element is the Storage Insight Add-on, which enables deep visibility into your
storage utilization, and for which you need array vendor softwares, such as HiCommand or
NaviCLI. The vendor software must be installed on the respective discovery host that is
configured to discover the given array. The Storage Insight Add-on provides enhanced
functionality to VOM.
1-9
In addition to discovering agentless hosts, the control host is used to discover information
about virtual environments. The control host connects to vCenter or an ESX server and acquires
all the mapping of your resources, from VMs, to ESX, to the array.
1-10
In addition to VMware ESX, VOM supports a number of other virtualization technologies. These
are Solaris Zones, Oracle VM Server for SPARC, which was previously called Sun Logical
Domains (Ldoms), Logical partition (LPAR) , Microsoft Hyper-V , and Kernel-based Virtual
Machine (KVM) with Red Hat Enterprise Linux as the KVM Server.
1-11
You must install the Control Host Add-on on one or more MHs and/or MS. The Control Host
helps you manage discovery data from agentless hosts and can discover HBAs, OSHandles on
the host, multipathing, Linux LVM, and file systems (including native options like ZFS). Agentless
discovery does not support the discovery of databases and applications.
A UNIX Control Host cannot be used to agentlessly discover Windows hosts. If you plan to
agentlessly discover Windows hosts, you will need to plan your Control Host deployment
accordingly.
You must install Storage Insight Add-on and configure arrays for deep discovery. Storage Insight
Add-on must be deployed to enable correlation of OSHandles on the agentless hosts to array
LUNs. If you make any configuration changes, for example creating new LUNs and making them
visible to the host, on storage arrays, then the agentless discovery that occurs after a
subsequent SI deep array discovery will reflect the changes on the agentless hosts. After
making changes to the array, one SI deep discovery needs to occur and only then a subsequent
agentless discovery will pick up the changes on the host.
For agentless discovery of a UNIX or Linux hosts, VOM requires a non-root user account for the
remote host. Privileged access is required to discover some information.
To perform agentless discovery of a remote Windows host, VOM runs a script that executes
data-gathering commands. The script uses Windows Management Instrumentation (WMI), a
Windows management technology that is used to work with remote hosts. The WMI calls use
Microsoft’s Distributed Component Object Model (DCOM) to obtain the data from the host.
VOM creates a private local user account (vomuser) on the Management Server or a Control
Host to facilitate its use of DCOM. To communicate between VOM Control Host and the remote
12
host, WMI uses port 135. VOM uses WMI in two ways: First, WMI contacts a service that
runs on the remote host and invokes the service to perform the actions that collect data
about the host. As it collects data, WMI sends the data back to the Control Host. Second,
WMI invokes command line tools such as nslookup and fcinfo. The output from the
command line tools saves to a data file on the remote host in the %systemroot%\temp
directory. Veritas Operations Manager copies the file from the host’s mapped admin$
filestore, sends it to Veritas Operations Manager Control Host, and deletes the file from the
remote host. To perform this discovery process, VOM requires a local administrator account
for the remote host.
1-12
The Management Server has administrative rights in the Storage Foundation environment it is
managing. Therefore, it is important for the Management Server to have a secure
infrastructure. Security aspects of the Management Server are maintained by the embedded
authentication brokers, which enable secure communication with public key infrastructure (PKI)
and the secure sockets layer (SSL) protocol. The authentication service also enables the
Management Server to work as an authentication domain system to integrate with public
domain user name spaces. VOM supports the authentication mechanisms configured in the
operating system, including Pluggable Authentication Modules (PAMs), Network Information
Service (N-I-S), and NIS+, with the exception of multi-factor authentication mechanisms. In
addition to the native operating system authentication, VOM supports Lightweight Directory
Access Protocol (LDAP) and Active Directory (AD). The embedded authentication broker cannot
be disabled on the central Management Server.
The Management Server does not store any user information. It only assigns specific privileges
to users, depending on the configuration. VOM 6.1 also has the capability to be placed in a VCS
cluster for high availability of the Management Server.
1-13
This is the “VOM Operations Framework” topic.
1-14
When VOM is installed in the data center, the Management Server package (VRTSsfmcs) and
Managed host (VRTSsfmh) packages are installed on the host that is designated as
Management Server:
• The VRTSsfmcs package installs components, such as Authentication service, Database
server, and Web User Interface Component on the Management Server host.
• The VRTSsfmh package installs the following components on the managed hosts and on the
Management server host:
• Agentlet framework (Discovery module)
• XPRTL (server and client)
• Xdist
• Action agent
• Event framework
The Symantec Product Authentication Service is a common Symantec component that validates
identities based on existing network operating system domains (such as unixpwd and NT) or
private domains. The Authentication Service protects communication channels between
Symantec application clients and services through message integrity and confidentiality
services.
The Web User Interface component provides a Graphical User Interface and comprises sub-
components, such as Add-on Web plug-ins, VRTSweb, client infrastructure, and database
access utilities.
1-15
The XPRTL component facilitates communication in VOM. The XPRTL component consists of a
server (XPRTLD) and a client (XPRTLC). The VRTSsfmh package installs XPRTLD and XPRTLC on
the managed hosts and on the Management Server host.
XPRTLD is a lightweight and full-featured Web server that uses HTTP based protocols to
forward information to other components of VOM. XPRTLD uses CGI scripts to update the VOM
database with the information that it receives from the managed hosts. In VOM, XPRTLD also
acts as the scheduler.
XPRTLC is the HTTP client that enables other modules of VOM to communicate with XPRTLD.
XRPTC provides any of the following that enable other modules to communicate with XPRTLD:
• A set of APIs that enables other modules to link to and communicate with XPRTLD
• A Command Line Interface (CLI) that enables any module to use CGI scripts that are located
along with XPRTLD.
Xdist forwards the http requests that it receives to many managed hosts simultaneously. Xdist
enables you to perform the same action on all, or a subset of, the managed hosts that are
added to Management Server. Also, Xdist queues the requests for a managed host that is not in
service and delivers the request when the host returns to service.
1-16
After the BIN file installs the VRTSsfmcs and the VRTSsfmh packages on the host that is
designated as the Management Server, XRPTLD that is part of the VRTSsfmh package is used
for configuring the Management Server components. After the successful installation of the
packages, open a Web browser and type https://hostname:5634, where hostname is the
Management Server host name, fully-qualified host name, or IP address, and 5364 is the port
number of XPRTLD. The Web browser directly communicates with XPRTLD. You can use the
dialogs that display to configure the components of Management Server. After the successful
configuration of the Management Server components, the Web browser communicates with
VOM through the Web server.
In each managed host, XPRTLC receives the information from the components and sends it to
XPRTLD in the Management Server. On receiving the information, XPRTLD uses CGI scripts to
communicate with the Management Server components.
The scheduler that is part of XPRTLD schedules the Agentlet Framework to scan the managed
hosts in regular intervals. The Agentlet framework passes the information that it collects to
XPRTLC in the managed host. XPRTLC communicates this information to XPRTLD on the
Management Server. XPRTLD in each managed host uses the CGI scripts to communicate with
the VOM components in the managed hosts.
1-17
The Agentlet framework in VOM discovers the managed hosts and the Storage Foundation
products that are installed on the managed hosts. The Agentlet framework performs the
following operations:
• Controls agentlets (scripts) that discover attributes of Storage Foundation products on
managed hosts
• Compares and contrasts the current system state and the last reported system state that is
discovered by an agentlet
• Coalesces the differences between the current and last reported system states
To synchronize data into the database, the CGI interface is invoked via the managed host on the
management server.
The managed host reports canonical data by JSONReporter. The MS picks data reported by
JSONReporter that it can consume and returns a response to the caller (managed host
discovery).
Data is then converted into SQL from JSON. Using xdbadm, the management server pumps
data into the database.
1-18
The table describes the frequency of the managed host information updates in the
Management Server database. The discovery on each managed host is divided into discovery
families to focus on a particular functional area.
1-19
The discovery for the Storage Foundation and Symantec Cluster Server families is event-driven
and scheduled. This indicates that the discovery is triggered when configuration changes occur
on the managed hosts. As a result, this information is updated in the Veritas Operations
Manager database in the following update.
If configuration changes are not detected on the managed hosts, communication between the
managed host and the Management Server is restricted to the heartbeat communication that
occurs every five minutes.
You can connect a managed host to multiple Management Servers. The performance of a
managed host is not affected in this scenario because the discovery only occurs once.
Status reporting is performed based on the number of Management Servers to which the
managed host reports.
1-20
This is the “Hardware and Software Compatibility List” topic.
1-21
VOM 6.1 provides support for additional array models, new array firmware and command-line
versions, and applications. For more information, refer to the Veritas Operations Manager
Hardware and Software Compatibility List (HSCL).
1-22
The slide shows a snippet from the HSCL guide that documents the list of supported operating
systems for the Management Server.
1-23
The slide shows a snippet from the HSCL guide that documents the list of supported operating
systems for the managed hosts.
For the latest platform support documentation for Storage Foundation (UNIX) and Storage
Foundation HA for Windows, visit the Symantec Technical Support Web site at
www.symantec.com/techsupp/ or the Symantec Operations Readiness Tools (SORT) Web site at
https://sort.symantec.com/productmatrix.
1-24
For more information about the topics discussed in this lesson, refer to the resources listed on
the slide and remember to check the SORT Web site frequently.
1-25
Welcome to the “Monitoring VOM” lesson.
2-1
This is the second lesson in this course.
2-2
In this lesson, you learn how to verify processes running on the Management Server and on
managed hosts using the command line and console. You also learn about the log files,
configuration files, and their respective locations in Windows and Linux environments. In
addition, you learn how to use vomgather.pl and the SORT data collector to gather information
for troubleshooting.
2-3
This is the “Checking VOM Management Server” topic.
2-4
Veritas Operations Manager uses default ports, as displayed on the slide, to transfer
information. If port 5634 is blocked, a managed host cannot be added to the Management
Server domain, whereas, if port 14161 is blocked, you cannot access the VOM Web console. In
addition, port 5636 is used to connect to the database and port 162 is used for Management
Server to receive Virtual Machine state change SNMP traps from VMWare vCenter. If port 162 is
blocked, changes to VMware infrastructure cannot be discovered near real time (NRT). Finally,
ensure SORT connectivity ports are accessible so that Management Server can download
patches from SORT. If you are managing hosts within multiple domains, update the network
settings to resolve the host addresses from all domains.
2-5
For the Management Server on Windows platform, confirm that the VOM-related services are
running from the Services panel.
• Veritas Operations Manager Authentication Service
• Veritas OperaƟons Manager Service
• Veritas Storage Foundation Messaging Service
• Veritas Operations Manager Database Service
• Veritas Operations Manager SNMP Trap Service
For the Management Server on the Linux platform, the VOM-related services are linked to the
/opt directory, as mentioned on the slide.
2-6
Use the service option of the vomadm command to start/stop the individual services; this is
the recommended method, especially when the Management Server is configured for HA.
2-7
The table lists the log files and their default locations on the Management Server for Windows
and Linux respectively.
2-8
The table lists the configuration files and their default locations on the Management Server in a
UNIX environment.
2-9
This is the “Checking Managed Hosts” topic.
2-10
The sfmh-discovery and dcli processes do not run on a Windows managed host.
2-11
On Linux, you can validate the processes running by using ps –ef command.
2-12
The agentless driver log files are stored at the Control Host, where hostname is the name of the
agentless host.
2-13
The slide shows the various log files saved in the /var/opt/VRTSsfmh/logs folder on a Linux-
managed host.
2-14
This is the “Viewing VOM-related files” topic.
2-15
Vomgather is a utility that can be executed from the command-line interface that is included
with VOM Management Server and Managed Host versions 4.0 and later. Vomgather gathers
configuration files and log files that are specific to VOM and can be used to gather data from
both the MS and an MH.
This is highly recommended because a vomgather troubleshooting archive is typically required
when resolving VOM-related issues. Because displaying information in the VOM GUI is the
result of mechanisms at the MH and CS, Symantec recommends that you run this utility on
both MH and CS.
Use the vomgather.pl script to gather logs for troubleshooting issues on Veritas Operations
Manager Management Server and managed hosts:
• On UNIX/Linux: /opt/VRTSsfmh/adm/vomgather.pl --dir mydir
• On Windows:
"C:\Program Files\Veritas\VRTSsfmh\bin\perl.exe"
"C:\Program Files\Veritas\VRTSsfmh\adm\vomgather.pl" --dir
mydir
where mydir is the directory used to store gathered data.
Use the --full option of the vomgather.pl script to gather the following data for
troubleshooting issues:
• Management Server: Database, Spool, and store data
• Managed hosts: Spool data
2-16
As a best practice to collect data for troubleshooting VOM is to collect a SORT vxexplorer.
There are several benefits of using SORT vxexplorer.
A SORT vxexplorer includes VOM specific data, that is vomgather which is embedded in the
vxexplorer for access to other items for that system (packages, hostname, memory size, LUN(s),
system logs, SFHA configuration, etc.)
The most important reason for gathering a SORT vxexplorer is that the customer needs to run
one data gathering tool (sortdc) instead of collecting a vomgather separately.
Vxexplorer also has the ability to correlate timestamps to non-VOM events in the system, such
as syslog, VCS logs etc. The newer versions of the Data Collector (sortdc) automatically uses
VOM communications (xprtld) for remote data collection. This enables customer to run sortdc
at the CS (or any MH) and collect data for all affected machines in the VOM domain.
2-17
The Data Collector has reporting capabilities in conjunction with SORT (the Web portal
administration tool); it also has the ability to generate a vxexplorer troubleshooting
archive. The slide lists the benefits of using the SORT data collector.
Download the Data Collector from the SORT Web site. Sortdc uses xprtld, ssh, rsh, or hacli for
remote data collection (automatic cross-platform capable).
Set the archive script execute permissions and run it. Follow the prompts and upload the .tar.gz
file to ftp.veritas.com/incoming
Notes:
*1 This is not available when run using the vxexplorer command-line option (for example,
sortdc -vxexplorer).
*2 This functionality is automatically disabled if the server does not have a connection to the
Internet; can also be manually disabled via a configuration file (sortdc.conf).
2-18
The Technical solution article is available on the Support site which provides:
• Walk-through video
• Where to get the data collector
• How to run the data collector
• How to send the logs to Support
And for any additional information regarding evidence collection, bookmark the TECH203525 in
to your local browser.
In the event that additional data is required, use the vomgather.pl script to gather the following
data for troubleshooting issues:
■ Management Server: Database, Spool, and store data
■ Managed hosts: Spool data
It may be necessary to collect an additional vomgather executing it at the command line with
the “--full” parameter.
2-19
Once the SORT vxexplorer is on the evidence server and extracted, the embedded vomgather
must be extracted for VOM troubleshooting.
The slide shows an example of how to organize evidence for troubleshooting.
When you unzip the content of vomgather data, you can see the list of files as follows:
/var/opt/VRTSsfmcs
/var/opt/VRTSsfmh/.
/var/opt/VRTSsfmh/./logs.
…
…
/etc/vx/VRTSsfmcs/.
/etc/vx/VRTSsfmcs/./.odbc11.ini
/etc/vx/VRTSsfmcs/./.odbc.ini
/var/opt/VRTSsfmh/spool/addons/store/sadm.ini
# ls
/etc and /var contains vomgather content for standalone MS; MH and clustered VOM (VOMHA)
will contain additional sub-directories
2-20
Since the systems in VOM have different roles, it is helpful to put a prefix on the vxexplorer
directory for each system. Now, let’s see how to determine the role of systems from the data
gathered in VxExplorere directories.
First, verify the packages installed on each system. If both cs and mh packages are present on a
single system, then it is the Management Server. Once the presence of both packages has been
verified, check the output of config.state file . If it shows cs-configured, then the system is
configured as a Management Server.
If only the mh package exists, it can be a managed host. The output of sfm_resolv.conf file
validates if the MH is configured to report to one or more management servers.
2-21
The vxexplorer directories can be renamed to use the appropriate prefix, such as CS, MH, CH, or
DH. Then, in order to resolve the issue, collect the screen captures, archives, and older data.
Screen Captures
Being that VOM is a GUI, the issue encountered will be clear to all who reference the case by
collecting one or more screen captures. Make a directory called screen_captures to hold these
items. These can be sent by the customer or collected during a Webex. Best Practice is to
collect a full screen capture as a lot of customers tend to send snippets of the portion in error.
It is important to have context. Example: customer sent snippet which at face value was indeed
incorrect. After a full screen capture was received, it was noticed that user was browsing to an
older version MS (customer had attached to wrong CS).
Archives
If it is desired to keep the compressed .tar.gz archive, make a directory called archives to hold
these items. This keeps the upper level directory (nnnnnnnn/) clean and manageable.
Older data
Oftentimes, a fresh vxexplorer or some other data may be received. If it is desired to retain the
older version of a piece of data (old to new comparisons), make a directory called old to hold
these items. This will keep the upper level directory (nnnnnnnn/) clean and manageable.
2-22
And as you start analyzing the issue and troubleshooting to resolve the case, there will be
incidents where you need Engineering assistance to look into the problem. You need to open
an engineering etrack case and cross-attach Sales Force case number with etrack. Mention the
issue in detail, steps you performed to resolve the case, system, platform, and product version
details along with the location of evidences collected. Refer to the attached pdf to see an
example of a case escalated to Engineering from Support. The template helps to keep the
gathered information clear and manageable and thus enables Engineering team to provide you
with prompt solutions.
2-23
2-24
This is the “Troubleshooting VOM: Part 1” lesson.
3-1
This is the third lesson in this course.
3-2
In this lesson, you learn how to troubleshoot issues related to installing and upgrading the VOM
management server. You also learn how to troubleshoot issues encountered while adding
hosts, configuring the management server, and deploying add-ons. In addition, you learn how
to identify issues related to log-in, security, LDAP, and user interface configuration. Finally, you
learn how to view error-codes using SORT.
3-3
This is the “Installation issues” topic.
3-4
The slide lists possible error messages you may encounter during the installation or upgrading of VOM
MS. If you do not have sufficient disk space in your current database directory to create the temporary
files, you are prompted to provide the path for a temporary working area having enough disk space.
Provide the complete path of a temporary working area.
You can calculate the disk space requirements for the temporary files as follows:
(2 * DB size) + (10% of DB size) + 150 MB
where DB size is the size of your database. The size of the database is actually the size of the
/var/opt/VRTSsfmcs/db/ database directory. The VRTSsfmcs directory contains the relational database
(sybase or postgres). The VRTSsfmh directory contains several subdirectories and lots of files that make
up a database (but not in the sense of a relational database like in VRTSsfmcs).
# cd /var/opt
# ls –la
total 28
drwxr-xr-x 5 root root 4096 Jun 11 2014 .
drwxr-xr-x 29 root root 4096 Jan 20 2014 ..
drwxr-xr-x 2 root root 4096 Aug 16 2012 dbed_lic
lrwxrwxrwx 1 root root 19 Jan 20 2014 VRTSsfmcs ->
/var/opt/.VRTSsfmcs
drwxr-xr-x 11 habdbsync root 4096 Dec 16 08:25 .VRTSsfmcs
drwxr-xr-x 30 root root 4096 Dec 19 11:30 VRTSsfmh
# du –sh VRTSsfmh
3-5
104M VRTSsfmh/
# du –sh VRTSsfmcs
87M VRTSsfmcs/
3-5
In the 6.1 release, the VOM database is ported from Sybase ASA 11 to PostgreSQL 9.3.4. The
6.1 upgrade is seamless (similar to the MS 6.0 upgrade) and database migration does not
expose any new complexity to the user.
PostgreSQL is an open-source and free object-relational database management system
(ORDBMS) software. It is ACID-compliant, fully transactional, has extensible data types,
operators, index methods, functions, aggregates, and procedural languages. Along with
inheritance of table structures, it has freely-available ODBC drivers and Level 4 JDBC drivers.
PostgreSQL supports multiple operating systems, such as Linux, Windows, UNIX, and Mac. It
also supports numerous languages used to create user-defined database functions, such as
native SQL, PgSQL, Java, C, C++, TCL, Python, and Perl.
3-6
The slide shows broad-level steps for uploading MS 6.1 database from customer site to
postgresql database of the in-house lab setup. Remember to take the full backup of the source
db directory from the source management server at the customer’s site. Then, copy the backup
directory to the target MS in your lab setup. Refer the attached .pdf to learn how to upload MS
6.1 database from customer site into PostgreSQL database of the in-house lab setup. The .pdf
lists detail steps for both the MS on Linux and Windows platform.
When configuring VOM MS, in the Database Setting panel, you can accept the default location
or specify your own location. To modify the default location, clear Use Default and specify
another location. On Windows, if you modify the default, you must have full control permission
on the drive that you specify.
The default database directory is /var/opt/VRTSsfmcs/db on Linux and
%ALLUSERSPROFILE%\Symantec\VRTSsfmcs\db on Windows.
3-7
If you encounter an error while migrating the database on the management server, first verify
that the database process is running on MS. You can also use the command line to start and
stop the VOM database process on the management server. If you need to trace the database
configurations, the relevant log file locations on Linux and Windows are listed on the slide.
3-8
Note: The xdbadm command to query the database using the –x and –f options remains
unchanged.
3-9
This is the “Management Server configuration issues” topic.
3-10
There are some common errors identified during the Management Server configuration. As a
quick check, you can start with checking firewall settings and verifying that ports 5634 and
14161 are open on MS. You can also check whether the xprtld and webgui processes are
running correctly.
The slide lists the commonly identified Management Server configuration issues and diagnostic
steps to fix those issues.
3-11
1) Set the umask to 0022.
2) Ensure that a new directory can be created in /home or in the desired location (can be local
or NFS mounted).
(if it is desired to create the user's home directory in other than /home, that is OK and will be
left up to the customer to execute the appropriate command(s) ).
3) Uninstall VOM.
# rpm -qa|grep sfm
VRTSsfmcs-6.1.0.0-0
VRTSsfmh-6.1.0.0-0
# rpm -e VRTSsfmcs-6.1.0.0-0 VRTSsfmh-6.1.0.0-0
4) Run the VOM installer at the command line (phase 1), but do not continue with the
browser-based configuration (phase 2).
5) Verify that the habdbsync user and it's home directory have been created properly.
(if the site has configured the default to be other than /home, please check for the existence of
the habdbsync home directory in that location)
(example below is a local login vs. an Active Directory or LDAP login)
# grep habdbsync /etc/passwd
habdbsync:x:99999:100::/home/habdbsync:/bin/bash
3-12
# grep habdbsync /etc/group
habdbsync:x:99999:
# ls -l /home
total 4
drwxr-xr-x 5 habdbsync habdbsync 4096 Oct 8 09:25 habdbsync
6) If not, please use the commands below to properly create the user before proceeding to
the brows-based configuration (phase 2)
# userdel habdbysnc
# useradd -g habdbsync -u 99999 -o habdbsync -s /bin/bash -m
(if user accounts at the site are NFS mounted, the user account/home directory may need to
be created per site policy using the UID above this is an expected value in this release)
7) Ensure the habdbsync account is available.
# su - habdbsync
$ id
uid=99999(habdbsync) gid=99999(habdbsync) groups=99999(habdbsync)
$ pwd
/home/habdbsync
8) Continue with the browser-based configuration phase of the VOM installation.
This issue will be corrected in a future release.
3-12
This is the “Add host issues” topic.
3-13
The slide lists commonly identified add host issues and diagnostic steps to fix those issues.
3-14
The slide lists additional add host issues and diagnostic steps to fix those issues.
3-15
As a best practice, start with checking if the VRTSsfmh package is installed and what version it is
on the sym3 and sym4 hosts.
• From the MS, run the following commands,
# ping sym3
# ping sym4
• From sym3 and sym4 run the following commands,
# ping mgt
• Verify if Port 5634 is opened bi-directionally to make sure that the two-way communication
is set up between the Managed Host and Management Server.
3-16
This is the “Login/security/LDAP issues” topic.
3-17
Operations Manager uses the existing user groups that are present in Lightweight Directory
Access Protocol (LDAP), or Active Directory (AD), or the authentication mechanism in the native
operating system of Windows and UNIX/Linux. Permissions, such as Admin or Guest can be
assigned to the user groups on an Organization within a perspective. The Operator role can be
assigned only in the Availability perspective.
The user groups having the Operator role can perform operations, such as taking a service
group online or offline, freezing or unfreezing a service group, or running the high availability
and disaster recovery fire drill.
The User group name is case-sensitive.
To perform this task, your user group must be assigned the Admin role on the perspective.
To assign permissions to user groups on an Organization within a perspective:
1. In the Home page on the Management Server console, go to the perspective, and select
Manage in the left pane.
2. Right-click the Organization and select Properties.
3. In the Permissions tab, under Add Permission, click Select user group.
4. In the Select user group panel, select the domain, and enter the name of the user group.
5. Click Validate user group and click OK.
6. Under Add Permission, select a role from the drop-down list. Click Add.
7. In the Success panel click OK.
3-18
The slide lists commonly identified login, security, and LDAP issues, and diagnostic steps to fix
those issues.
3-19
The slide lists additional login, security, and LDAP issues, and diagnostic steps to fix those
issues.
3-20
This is the “User Interface Configuration Issues” topic.
3-21
The esmweb.cfg file is the user interface configuration file that contains the configuration
details of the Web application. This file provides information about the VRTSsfmcs installation
location, the location of the log files, and the SSL port.
To change the VOM Web application port, confirm that the default port is 14161. Update
SSLPORT in the esmweb.cfg file to change the port, and then restart the Web server.
3-22
The db-config.properties file is the database configuration file. The VOM user interface file
uses it to connect to the database. The file provides information about the DB port and the
connection pool settings.
3-23
The vom_ui_log_config.properties file is a log configuration file. It is used by the VOM UI to log
information related to log message format and filenames, the number of backups for log file
rotation, and the file size.
There are three types of log levels: Debug, Info, and Warning. To change the log level from the
VOM UI, navigate to Settings and select the Management Server tab. From the Web Server
Settings field, set the log level for all web server log files.
3-24
On Windows MS, you can also use the Veritas Operations Manager Service to start and stop the
Webserver.
3-25
From the VOM Management Server Deployment screen, if you are not able to see the
available patches for a host, there may be a connectivity issue from the MS host to SORT.
Examine the WebDebugLog.txt file to determine the internet connection status from the
Management Server.
You can also verify the mh.log file to check whether the LDR family is reporting to existing
products installed on the host.
3-26
To fix UI-related issues, verify three types of log files.
• The WebDebugLog.txt files is used for debugging information and gracefully-handled
exceptions.
• The tomcat.log file is used for sysouts and unhandled exceptions.
• The webserverdump.log file is generated when an OutOfmemory incident is logged.
When you receive an error, such as “Webserver crash due to OutOfMemory,” check tomcat.log
for an OutOfMemory exception. Open the esmweb.cfg file and find the location of the
webserverdump.log file under the JAVA_OPTS section. Collect the logs for analysis.
3-27
Occasionally, in the VOM UI, you find issues, such as the Web page is blank, the browser
becomes unresponsive, or the browser displays pop-up error messages. In these cases, first
verify that the browser requirements are met. Check the UI logs for exceptions and refresh the
UI page. You can also try accessing the page from a different browser, such as Chrome, FireFox,
or Explorers.
If exceptions are not found in the log files, these may indicate JavaScript errors. Either take a
screenshot or specify the browser and version used and submit them for further investigation
of this case.
3-28
This is the “Deployment/Add-on issues” topic.
3-29
In a scenario where the add-on failed to deploy to selected managed hosts, start by checking
the management server. Verify the vxdeploy.log file from the management server. Checking the
output of xinfo from the management server may also be useful.
3-30
3-31
From the SORT website, search for the error-code V-383-1-2039 and read the solutions for
listed errors.
3-32
From the SORT website, search for the error-code V-338-1-2039 and read the solutions for
listed errors.
3-33
Navigate to the sitemap from the SORT Website, and scroll down to the bottom of the page.
Click Error-code list. This page displays the extensive list of error-codes and relevant
documentation to support Symantec solutions. Navigate to page 31 and you see all v-383 prefix
for core VOM error codes. Click the error-code link to study relevant documentation.
Remember that some of them are without solutions. The possible reason is people resources
and knowledge to document all the solutions. So the kind of ‘error without solutions’ only gets
done when support sends an email or creates an incident saying that a customer looked up a
particular UMI or error.
In frequent cases, customers generally type the VOM error message into Google. This usually
hits a Symantec Technote or some other kind of useful information.
3-34
3-35
This is the “Troubleshooting VOM: Part 2” lesson.
4‐1
This is the fourth lesson in this course.
4‐2
In this lesson, you learn how to troubleshoot problems that may arise when configuring deep
discovery for Storage Insight Add‐on. You also learn about troubleshooting problems that may
occur when discovering SAN fabric switches using Fabric Insight Add‐on. In addition, you learn
how to analyze VOM reports for troubleshooting VCS.
4‐3
This is the “Configuring deep discovery for Storage Insight Add‐on” topic.
4‐4
With VOM 6.0, the Storage Insight Add‐on provides Deep Array Discovery and Mapping of the
detailed information on the storage enclosures in the data center. This add‐on is installed in the
VOM Management Server. It enables the Management Server to use array‐specific commands
and utilities through discovery hosts to collect detailed enclosure information at the array level.
The discovery hosts need to be added to the Management Server as managed hosts. The slide
shows the various arrays supported by the Storage Insight Add‐on and lists the array‐specific
utilities used in each case.
After the Storage Insight Add‐on performs the deep discovery of enclosures, you can view the
types of additional information on the details page of each enclosure, such as logical devices,
physical devices, thin pools, host associations, and replications.
In addition to providing deeper insight on your enclosures, the Storage Insight Add‐on enables
you to define the tiers for the LUNs in the data center. The tiering of LUNs supports Hierarchical
Storage Management (HSM), which manages the data by putting it into different types of
storage media according to the various parameters. In addition, the Storage Insight Add‐on
enables you to perform maintenance of the DMP paths at the level of array ports and adapters.
4‐5
The table on the slide describes supported enclosures and the mechanism used to discover the
related information. Veritas Operations Manager Storage Insight Add‐on, with deep discovery
Capabilities, enables you to discover the enclosures, such as HP EVA, EMC Celerra, IBM system
storage, 3PAR, IBM SVC, EMC VNX, and EMC VPLEX.
For more information about vendor or enclosure support related to the Storage Insight Add‐on,
refer to the VOM 6.0 Hardware and Software Compatibility List Guide and VOM Management
Server 6.0 Add‐ons User Guide.
4‐6
The SSH private key file is used for user authentication. Specify the full path of the
corresponding SSH private key file on the device configuration panel of Storage Insight Add‐on.
A valid SSH private key file is required up to version 6.2 of IBM SAN Volume Controller and IBM
Storwize V7000. For version 6.3 and later, either provide a password, or use the SSH private key
file for user authentication.
When the SSH Key Pair is updated on the Array, discovery of the already‐configured array fails in
VOM and a “FATAL ERROR” message is displayed in the VOM array discovery log file. This
happens when you have configured an array in VOM and later, an administrator has configured
a new SSH key pair for the same user.
4‐7
To discover the HITACHI enclosure, ensure that storage network physical connections, the
HiCommand server, and the Storage Insight Add‐on are properly configured. The Storage Insight
Add‐on discovery host communicates with the HiCommand server to access the HITACHI
enclosure.
The physical connection requirements for HITACHI enclosure are:
• Network connectivity between the HiCommand server and the Storage Insight Add‐on
discovery host
• Connection from the discovery host to the HiCommand server using the following URL:
http://HiCommand_server_address:2001
where HiCommand_server_address is the IP address of the HiCommand server, and 2001 is
access port.
4‐8
To discover the NetApp enclosure using the Storage Insight Add‐on, ensure that storage
network physical connections, the NetApp server, and the Storage Insight Add‐on are properly
configured.
The physical connection requirements for NetApp enclosure discovery are:
• Network connectivity between the discovery host of the Storage Insight Add‐on and
NetApp enclosure
• Connection from the discovery host to the NetApp server using HTTP and HTTPS
connections as follows:
• https://netapp_address/na_admin
where Port 443 is used for the HTTPS connection
• http://netapp_address/na_admin
where Port 80 is used for the HTTP connection
• netapp_address is the IP address or NetApp array name, registered with the Domain
Name System (DNS).
Setting up the device includes NetApp server configuration and enabling support for MultiStore
Virtual Systems on the NetApp enclosure.
Configure the array with an IP address or name and an administrator‐level account with a valid
user name and password. The Storage Insight Add‐on uses these credentials to access the
enclosure. If a MultiStore license is installed on the filer, VOM discovers the MultiStore virtual
system.
4‐9
This is the “Discovering SAN fabric switches using Fabric Insight Add‐on” topic.
4‐10
You can use the Fabric Insight Add‐on to discover storage area network (SAN) fabric switches
that are configured in the data center. For discovering the Cisco and Brocade switches, the
prerequisites listed on the slide must be met.
Cisco discovery
For Cisco discovery, the supported switch operating systems versions are: Cisco SAN OS 3.1
(model DS‐C9509 and DS‐C9124‐K9) and Cisco NX‐OS 5.1 (model N5K‐C5548UP). All switches in
the fabric must have the same user credentials. Cisco switches in NPV mode cannot be
configured as seed switches. Seed switch is the first switch in the fabric you want to discover.
Discovery of mixed‐vendor fabrics is not supported. Ensure that UDP port 161 is open between
the discovery host and the Cisco switch.The supported SNMP protocol versions are SNMP v1,
v2c, and v3. However, when you select SNMP v1/v2c when configuring the switch discovery,
SNMP v2c is used for the discovery.
Brocade discovery
For Brocade discovery, for the principal switch, Fabric OS version 6.3.x or later is required. For
the subordinate switch, Fabric OS version 5.3.2, or later is required. For the Seed Switch, Fabric
OS version 5.3.2, or later is required. The minimum guest‐level access is required for the
discovery. All switches in the fabric must have the same user credentials for a successful switch
discovery. The BNA credentials are the BNA database credentials; not the BNA application login
credentials. For discovery using HTTP communications, ensure that HTTP port 80 is open. For
discovery using the Brocade Network Advisor (BNA), postgress port 5432 should be open. For
BNA‐based discovery, the BNA version should be 11.x, or later. For HTTP‐based discovery, the
switch firmware version should be 5.3.x, or later.
4‐11
This slide lists reasons why the fabric discovery may fail.
4‐12
For HTTP‐based discovery of Brocade switches, verify the network connectivity and firewall
settings. Ensure all switches in the fabric have the same credentials configured and the
Principal switch in the fabric is reachable using the supplied credentials.
For logical switch discovery, the configured user has access to all the logical fabric FIDs and has
the Chassis Access role (at a minimum, Guest access is required).
For more information about the FOS version criteria, refer to the VOM 6.1 Hardware and
Software Compatibility List Guide and the VOM Management Server 6.1 Add‐ons User Guide.
4‐13
With some versions of BNA (for example version 12.x and later), additional steps are required
on the BNA server to enable the Veritas Operations Manager discovery host to discover the
switches. Change the BNA database client authentication file (pg_hba.conf) to allow the
discovery host to connect to the BNA database. The file is located at C:\Program Files\Network
Advisor 12.0.0\data\databases\pg_hba.conf.
4‐14
In order to troubleshoot discovery issues with Cisco switches, some parameters and settings
needs to be verified.
• Check network connectivity between the VOM discovery host and the switches in the
fabric.
• Check that SNMP is allowed in the firewall; VOM uses default UDP port 161.
• Check whether the authentication parameters are supplied and verify that all switches in
the fabric have the same credentials configured.
• All switches in the fabric must be reachable.
• Check that the configured user has at least Network Operator role.
• Finally, check that the seed switch configured in VOM is not in NPV mode.
4‐15
In there are errors in switch discovery, verify the VOM logs on the discovery host as specified
on the slide.
4‐16
Getciscodata.pl is shipped with VOM. For troubleshooting, run the getciscodata utility to
obtain the customer’s switch‐related data in‐house. This utility can also be used to test SNMP
access to switches.
4‐17
This is the “Analyzing VOM reports for troubleshooting VCS” topic.
4‐18
In VOM, clusters, service groups, and replication features provide high availability and disaster
recovery of applications. In the Management Server console, the Availability perspective
provides you with a snapshot of the high availability and disaster recovery status of the data
center. It includes service group states, associated faults, risks, details about clusters, and
replications.
The slide shows an example of a 3‐node cluster configured with SFHA 6.2 on the UNIX platform.
This consolidated view allows you to perform the following operations:
• View the status of the objects that are available in the Availability perspective. These
objects include service groups, clusters, systems, and Virtual Business Services. You can
view the status under Object Status in Overview at the data center level.
• View top faults and risks under Faults and Risks in Overview at the data center and
Organization level. From this view, you can drill down to the source of fault.
• Monitor the status of selected service groups. You can add service groups that you want to
monitor under Favorite Service Group in Overview at the data center level.
4‐19
You can generate various reports related to trends, activity, and analysis for all HA objects –
clusters, service groups, and resources. You cannot run the report for a single service group.
You can either run the report on a selected Organization or the entire data center. If you select
an Organization, all the service groups that are associated with the Organization are scanned.
The slide highlights the types of reports that are generated using VOM 6.1.
• Activity reports capture the change in Symantec Cluster Server attributes for high
availability objects. These include Cluster Activity, Service Group Activity, and Resource
Activity.
• The Uptime Analysis report provides information about a service group’s state over the
specified time.
• The Resource Fault Trending report provides information about resource types that are
unstable. You can view the most unstable resource types that generated the maximum
number of faults. From the Symantec Cluster Server perspective, this information is useful
because the Symantec Cluster Server uses its agents to monitor the resource types.
• The Failover Summary report displays information on planned and unplanned failovers that
are associated with a cluster, as follows:
• A planned failover that you have planned and executed with the Online, Offline, or the
Switch operations
• An unplanned automatic failover that occurred because of faults in the data center,
which would have affected the high availability adversely
Cluster Server has performed the failover operation without your interference.
• An unplanned manual failover that occurred because of faults in the data center
VCS required your interference to clear the faults, or perform the corrective action to
complete the failover.
4‐20
The slide shows an example of the Uptime Analysis report generated for sfha62 cluster. It
provides information about data_sg and Cluster_service service group’s state over the specified
time. In the customer environment, where more than 10 clusters are configured, the report
comes handy for troubleshooting clustered application’s related issues.
4‐21
The slide shows an example of the Average Failover Duration Report generated for a
replicated cluster with RHEL62, called RepClusRhel62. It provides information about time taken
by VCS to failover the generic_app_sg_nfs service group in specified scope range. In the
customer environment, where more than 10 clusters are configured, the report comes handy
for knowing failover duration, and troubleshooting clustered application’s related issues.
4‐22
The slide shows an example of a Resource Fault Trending report generated on vcslx5 cluster.
The faults section provides information about two resource types that are faulted on a host.
From the Availability perspective, you can view the fault/error notification and try to fix the
selected resource type. This information is useful because the Symantec Cluster Server uses its
agents to monitor the resource types.
4‐23
4‐24
Appendix A: Labs
Lab 1: Lab environment overview
The lab exercises for this course are performed in a virtual environment that
comprises of eight virtual computers. These virtual computers are mgt,util1,
util2, sym1, sym2, sym3, sym4, and vom-ms.
The subsequent topics provide detailed information about the virtual lab
environment.
Lab 1: Lab environment overview A–3

Copyright © 2015 Symantec Corporation. All rights reserved.
Virtual machine configuration
This topic provides detailed information about all virtual computers present in the
lab environment. The virtual computers that are used when you perform a lab are
mentioned at the beginning of each lab. In addition, pointers are provided
throughout the lab guide specifying the virtual computer on which a sequence of
lab steps have to be performed.
A–4 Veritas Operations Manager 6.1: Troubleshooting

mgt: root/train
Name mgt
OS RedHat Enterprise Linux 6.5
Role DNS Server
Veritas Operations Manager Management Server
NFS Server
IP address 10.10.2.3
Installed Software Adobe Flash Player
Veritas Operations Manager 5.0
util1: root/train
Name util1
Role 3PAR Array simulator
Installed Software
util2: root/train
Name util2
Role Array simulator
Installed Software

sym1: root/train
Name sym1
OS RedHat Enterprise Linux 6.5 (RHEL65)
Role Cluster Node
Installed Software Active Perl
SFHA 6.2
sym2: root/train
Name sym2
Role Cluster Node
SFHA 6.2

sym3: administrator/train
Name sym3
OS Windows Server 2012 R2 Standard
Role Cluster Node
SFWHA 6.1
Name sym4
OS Windows Server 2012 R2 Standard
Role Cluster Node
SFWHA 6.1
vom-ms: root/train
Name vom-ms
Role Cluster Node
Installed Software Pre-populated data (demo only)
Note: In the lab exercises, the virtual computers are identified by the system names
in the preceding tables.

Accessing virtual machines
There are two introductory labs that follow. You may complete only one of them
depending on how and where you attend this course. Your instructor will direct
you to the appropriate introductory lab.
• If you are attending this course in a physical classroom, continue to Intro Lab
A: Using VMware Workstation in a physical classroom.
• If you are attending this course in a virtual environment where you are
connected via the internet, skip to Intro Lab B: Using Granite.

Intro Lab A: Using VMware Workstation in a classroom
In this lab, you become familiar with the VMware Workstation lab environment
used in a physical classroom environment. You will become familiar with the
virtual machines used with the Veritas Operations Manager 6.1: Troubleshooting
course, as well as the method for accessing these virtual machines.
The hands-on portion of this lab enables you to perform basic operations on virtual
machines. The best practice guidelines provided in this lab enables you to perform
the remaining labs more effectively.
In this lab, you perform the following exercises:
• Starting the virtual machines.
• Logging on to virtual machines.
• Adjusting VMware view.
• Running basic commands.
• Testing passwordless SSH for the root user
Note: These exercises are performed only in a physical classroom using the
VMware Workstation environments. Exercises for the Granite environment
are in Intro Lab B.
Lab 1: Intro Lab A: Using VMware Workstation in a classroom A–9

VMware Workstation lab environment
In this lab environment, each of the virtual computers is connected to a single
virtual network residing on the host. All the virtual machines are accessed using
VMware Workstation.

VMware Workstation interface
The slide displays the VMware Workstation interface used to access the virtual
computers. Virtual computers are referred to as guest systems, which are running
their own guest operating systems. The physical system running the VMware
Workstation application is referred to as the host system running the host operating
system. Virtual computers are accessed by clicking the tab named after the system
you want to access.

Exercise 1: Starting virtual computers
In this exercise, you start the virtual computers and display the existing snapshots
for each virtual computer.
After the lab environment is deployed, the VMware workstation interface appears
as shown in the following screenshot.
1 Review the current settings for each virtual computer.
a To select a virtual computer, click a tab.
b Use the Summary view to locate the Devices pane and review the the
virtual computer configuration information that is displayed.
c Click each of the remaining tabs and review the Devices pane information
for each virtual computer.
mgt: root/train
2 Start the mgt virtual computer.
a In VMware, click the mgt tab.

b From the toolbar, click the green Power On button.
c Wait until the logon window is displayed.
util1: root/train
3 Start the util1 virtual computer.
a In VMware, click the util1 tab.
c Wait until the logon window is displayed. .
util2: root/train
4 Start the util2 virtual computer.
a In VMware, click the util2 tab.
Note: mgt, utill, and util2 can be started at the same time. sym1, sym2,
sym3, and sym4, must be powered on only after the mgt, util1, and util2
virtual machines are up and running.
sym1: root/train
5 Start the sym1 virtual computer.
a In VMware, click the sym1 tab.
c Wait until the logon window is displayed

sym2: root/train

vom-ms: root/train
9 Start the vom-ms virtual computer.
a In VMware, click the vom-ms tab.

Exercise 2: Logging on to virtual computers
Log on to each virtual computer to become familiar with the logon procedures and
credentials for each virtual computer.
mgt: root/train
1 Log on to mgt as root with password train.
a Click the mgt tab.
b Logon to mgt using the following credentials:
› User name: root

› Password: train
c Press Enter or click the arrow.
Note: There is no need to log on to util1 and util2. So it is not included here.
sym1: root/train
2 Log on to sym1 as root with password train.
a Click the sym1 tab.
b Logon to sym1 using the folowing credentials:
› User name: root

› Password: train
sym2: root/train
3 Logon to sym2 as root with password train.

b Logon to sym2 using the following credentials:
› User name: root

› Password: train
› User name: root

› Password: train
› User name: root

› Password: train

vom-ms: root/train
6 Logon to vom-ms as root with password train.
a Click the vom-ms tab.
b Logon to vom-ms using the following credentials:
› User name: root

› Password: train

Exercise 3: Adjusting the VMware view
Adjust the VMware view controls to become familiar with navigating a virtual
computer.
1 Select Settings > Full Screen Mode to enable the Full Screen view.
How is the Full Screen view different from the default view?
Answer: The workspace is enlarged to fit the screen, including the other virtual
computer tabs.
2 Select Settings > Exit Full Screen Mode to change back to the default view.

Exercise 4: Testing passwordless SSH for the root user
The setup of passwordless SSH is a local security consideration, especially when

configured for the root user. For convenience, the lab systems have persistent
passwordless SSH configured for the root user.
In this exercise, you verify that passwordless SSH is configured on the two cluster
systems.
mgt: root/train
1 Use ssh to connect to the sym1, sym2 and localhost host names and verify
that you are not prompted for a password or passphrase. After each successful
ssh, type exit to return back to the mgt system.
a ssh sym1
exit
b ssh sym2
exit
c ssh localhost
exit
Note: If you are prompted because the authenticity of the host name cannot be
established, type yes to continue, and then exit the connection and retry a
prompt-free connection to the same host name.
sym1: root/train
2 Use ssh to connect to the sym2 and localhost host names and verify that you
are not prompted for a password or passphrase. After each successful ssh,
type exit to return back to the sym1 system.
a ssh sym2
exit

b ssh sym1
exit
c ssh localhost
exit
sym2: root/train
a ssh sym1
exit
b ssh sym2
exit
c ssh localhost
exit
Note: When you run the command ssh localhost, you may see a warning
message “The authenticity of host can’t be established. Are you sure you
want to continue connecting? (yes/no)” Select Yes to proceed. This will
permanently add localhost to the list of known hosts.

Exercise 5: Running basic commands
In this exercise, you determine whether the virtual machines can communicate by
way of TCP/IP on the virtual network.
mgt: root/train
1 Use the ip addr show command to confirm the IP address assigned to mgt.
# ip addr show eth1 | grep inet

inet 10.10.2.3/24 brd 10.10.2.255 scope global eth1
inet6 fe80::250:56ff:fe8d:b43/64 scope link
2 Use the ping -c command to confirm the addresses assigned to ping sym1
and sym2.
ping -c 3 sym1
PING sym1.example.com (10.10.2.11) 56(84) bytes of data.
64 bytes from sym1.example.com (10.10.2.11): icmp_seq=1 ttl=64
time=0.226 ms
...
ping -c 3 sym2
time=0.201 ms
...
3 Use the nslookup command to confirm that the fully qualified host name is
mgt.example.com
# nslookup mgt
Server: 10.10.2.3
Address: 10.10.2.3#53
Name: mgt.example.com
Address: 10.10.2.3

sym1: root/train
1 Use the ip addr show command to confirm the IP address assigned to

sym1.

inet6 fe80::250:56ff:fe8d:2a2b/64 scope link
sym1.example.com.
# nslookup sym1
Server: 10.10.2.3
Address: 10.10.2.3#53
Name: sym1.example.com
Address: 10.10.2.11
3 Use the fdisk -l command to ensure that disks are available.
fdisk -l /dev/sd? | grep Disk

Disk /dev/sda: 26.8 GB, 26843545600 bytes
Disk /dev/sdb: 26.8 GB, 26843545600 bytes
Disk /dev/sdc (Sun disk label): 128 heads, 32 sectors, 1022 cylinders
Disk /dev/sdd (Sun disk label): 128 heads, 32 sectors, 1022 cylinders
Disk /dev/sde (Sun disk label): 128 heads, 32 sectors, 1022 cylinders
...
...
...
Disk /dev/sdz (Sun disk label): 128 heads, 32 sectors, 1022 cylinders

sym2: root/train

sym2.

inet6 fe80::250:56ff:fe8d:38c3/64 scope link
sym2.example.com
# nslookup sym2
Server: 10.10.2.3
Address: 10.10.2.3#53
Address: 10.10.2.12

Disk /dev/sdc (Sun disk label): 128 heads, 32 sectors, 1022 cylinders
...
...
...
1 Use the control panel to confirm the IP address assigned to sym3.
a Go to Control Panel > Network and Sharing Center
b Select classroom2_13

c Select Properties.
d Select the option for Internet Protocol Version (TCP/IPv4), and click
Properties.
DNS Server: mgt.example.com

Address: 10.10.2.3
Address: 10.10.2.13
1 Perform the same steps as sym3 and verify the IP address assigned to sym4.
Address: 10.10.2.3
Address: 10.10.2.14

Intro Lab B: Using the Granite lab environment
In this lab, you become familiar with the Granite lab environment accessed
through the Internet. You will become familiar with the virtual machines used with
the Veritas Operations Manager 6.1: Troubleshooting course, as well as the
method for accessing these virtual machines.
The hands-on portion of this lab enables you to perform basic operations on virtual
machines. The best practice guidelines provided in this lab enables you to perform
the remaining labs more effectively.
In this lab, you perform the following exercises:
• Connecting to the lab environment.
• Connecting to additional virtual machines.
• Testing passwordless SSH for the root user.
• Running basic commands.
Note: These exercises are performed only if the class is using the hosted Granite
platform to access the lab environment. Exercises for the VMware
Workstation environment are in Intro Lab A.

Granite interface
The Granite interface is used to access the virtual machines. Instead of using tabs
like VMware Workstation, the Granite virtual machines are accessed from the
Granite console. Other key interface elements include:
• Title Bar: Indicates the currently connected lab and whether you have control
of the machine or are in view-only mode.
• My Labs: Used to add/delete virtual labs from the Granite repository.
• Right panel: Used to switch between active virtual machines.
• Blueprint details: Used to view the lab configuration details like OS, memory,
softwares, stoarge, IPs, networking pre-configured in the lab images.
Lab 1: Intro Lab B: Using the Granite lab environment A–27

Exercise 1: Connecting to the lab environment
In this exercise, you log on to Granite and connect to the first system. For each lab
environment in Granite, a particular virtual machine is marked as a primary
machine. All other machines are marked as secondary machines. When you
connect to the Granite interface, you are initially connected to the primary virtual
machine.
1 Locate the Granite portal URL

https://granite.gsl.symantec.com/labs/
2 From the left pane, under My Labs, click Add.
3 A new window opens which shows list of labs available through Granite. In the
Search field type vom61-k1.
4 The window will display the description, deploy time, Org, and publisher
details for the vom61-k1 lab. Click Deploy. Depending on the bandwidth, it
will take 5-7 minutes to deploy tha lab images on your acount.
Note: Once the deployment is complete, you will receive an email stating
Granite Notification - Deployment Completed.
5 In the Granite console, you will see the VMs listed are powered on.
6 Click the Blueprint Details link to view the login credentials to access the
VMs and basic configurations done for the images.

Exercise 2: Connecting to virtual machines
In this exercise, you connect to virtual machines and become familiar with
switching between systems.
sym1: root/train
1 Log into the sym1 server using the following credentials.

– Account: root
– Password: train
a From the sym1 computer desktop, click the mouse to establish keyboard
control.
b In the Username field, type: root
c Press the Enter key.
d In the Password field, type: train
e Press the Enter key.
2 Use the Window > mgt menu item to switch to the mgt system.
3 Use the Window > sym1 menu item to switch back to the sym1 system.
4 Use the Window menu item to verify that the console window for the sym1
system is closed.
Note: Notice that the sym1 entry is no longer available from the Window
menu item.
Note: In further labs, use the steps you practiced in this exercise to navigate
between different virtual lab systems in the Granite environment. The lab
solutions will no longer display the steps needed to navigate from one
virtual machine to another.

Exercise 3: Testing passwordless SSH for the root user
The setup of passwordless SSH is a local security consideration, especially when

configured for the root user. For convenience, the lab systems have persistent
passwordless SSH configured for the root user.
In this exercise, you verify that passwordless SSH is configured on the two cluster
systems.
sym1: root/train
a ssh sym2
exit
b ssh sym1
exit
c ssh localhost
exit
sym2: root/train
a ssh sym1
exit

b ssh sym2
exit
c ssh localhost
exit
established, type yes to continue, enter the password as train, and exit the
connection. Then retry a prompt-free connection to the same host name.

Exercise 4: Running basic commands
In this exercise, you use basic commands to determine whether the virtual
machines can communicate by way of TCP/IP on the virtual network.
Note: Use the steps in Exercise 2 to connect and navigate to the additional
machines as needed.
Note: For simplicity, the instructions found in the solutions to enter a command
in a terminal window only show the command to be typed. These
commands are displayed in a bold font that is different than the normal
text.
As an example, the instructions for step 1a is displayed as:

ip addr show eth1 rather than:
In the terminal window, type ip addr show eth1
After typing each command, press Enter.
Sample output that is to be expected from each command is displayed

directly after the command in a smaller font.
mgt: root/train

mgt.

inet6 fe80::250:56ff:fe86:1564/64 scope link
2 Use the ping -c command to confirm the addresses assigned to ping sym1
and sym2.
ping -c 3 sym1
time=0.312 ms
...

ping -c 3 sym2
time=0.271 ms
...
mgt.example.com
# nslookup mgt
Server: 10.10.2.3
Address: 10.10.2.3#53
Name: mgt.example.com
Address: 10.10.2.3
sym1: root/train

sym1.

...
inet6 fe80::250:56ff:fe86:63df/64 scope link
sym1.example.com
# nslookup sym1
Server: 10.10.2.3
Address: 10.10.2.3#53
Address: 10.10.2.11

Disk identifier: 0x00001f2f
Disk identifier: 0x3ab9291a
Disk /dev/sdc: 53.7 GB, 53687091200 bytes

Disk identifier: 0x00000000
Disk /dev/sdd (Sun disk label): 128 heads, 32 sectors, 1022
cylinders
Disk /dev/sde (Sun disk label): 128 heads, 32 sectors, 1022
cylinders
Disk /dev/sdf (Sun disk label): 128 heads, 32 sectors, 1022
cylinders
Disk /dev/sdg (Sun disk label): 128 heads, 32 sectors, 1022
cylinders
...
sym2: root/train

sym2.

...
inet6 fe80::250:56ff:fe86:6071/64 scope link
sym2.example.com
# nslookup sym2
Server: 10.10.2.3
Address: 10.10.2.3#53
Address: 10.10.2.12

Disk identifier: 0x00001f2f
Disk identifier: 0x13b8533f
Disk /dev/sdc: 53.7 GB, 53687091200 bytes
Disk identifier: 0x00000000
Disk /dev/sdf (Sun disk label): 128 heads, 32 sectors, 1022 cylinders
Disk /dev/sdg (Sun disk label): 128 heads, 32 sectors, 1022 cylinders
...

1 Use the control panel to confirm the IP address assigned to sym3.
a Go to Control Panel > Network and Sharing Center
b Select classroom2_13
c Select Properties.
d Select the option for Internet Protocol Version (TCP/IPv4), and click
Properties.

Address: 10.10.2.3
Address: 10.10.2.13

Perform the same steps as sym3 and verify the IP address assigned to sym4.
Address: 10.10.2.3
Address: 10.10.2.14
End of Lab

Lab 2: Checking VOM 6.1 environment
In this lab, you execute a verification check for VOM environment. This lab
contains the following exercise:
• Determine the role of systems in the environment
• Verify the processes and services running on the Management Server
• Verify the processes and services running on the Managed Hosts
• Check the log files on the Management Server and Managed Hosts, both for
Windows and RHEL systems.
Lab 2: Checking VOM 6.1 environment A–39

Exercise 1: Determining the role of systems in the environment
In this exercise, you perform a verification check for VOM environment and
determine the role of each VM using CLI.
mgt: root/train
1 Perform a verification check of Veritas Operations Manager Management

Server configuration.
a Run the rpm -qa command to verify the packages installed on mgt.
rpm -qa | grep sfm

VRTSsfmh-6.1.0.0-0.x86_64
VRTSsfmcs-6.1.0.0-0.x86_64
b Verify the /var/opt/VRTSsfmh/config.state to see if the MS is

been configured.
more /var/opt/VRTSsfmh/config.state
cs-configured
Note: These 2 tests determine that a host is installed and configured as a

management server. So for lab purpose, mgt is configured as a VOM 6.1
Management Server.
Note: There are 3 possible states for the command:

/var/opt/VRTSsfmh/config.state
Installed and not configured
Installed and configured as standalone CS (shown
in this step)
Installed and configured as clustered CS (HA)
2 Perform a verification check of VOM Managed Host configuration on each

VM.
sym1: root/train
a Run the rpm -qa command to verify the packages installed on Linux
VM.

rpm -qa | grep sfm
VRTSsfmh-6.1.0.100-0.x86_64
rpm -qa | grep -w VRTSvcs

VRTSvcs-6.2.0.000-RHEL6.i686

sym2: root/train
b Run the rpm -qa command to verify the packages installed on Linux VM
rpm -qa | grep sfm

VRTSsfmh-6.1.0.100-0.x86_64
rpm -qa | grep -w VRTSvcs

VRTSvcs-6.2.0.000-RHEL6.i686
Note: This verifies that VCS 6.2 is installed on both the hosts and they are
configured as managed hosts. So for lab purpose, sym1 and sym2 are
configured as a VOM 6.1 Managed Hosts with latest patch.
c Navigate to Program and Features panel to verify the packages installed

on Windows VM.
Go to Start > Control Panel > Programs and Features

d Navigate to Program and Features panel to verify the packages installed
on Windows VM.
Go to Start > Control Panel > Programs and Features
Note: This verifies that SFWHA 6.1 is installed on both the hosts and they are
configured as Windows Managed Hosts. So for lab purpose, sym3 and
sym4 are configured as VOM 6.0 Managed Hosts.
vom-ms: root/train
a Run the rpm -qa command to verify the packages installed on this VM.
rpm -qa | grep VRTS

...
VRTSvxvm-6.1.0.000-GA_RHEL5
VRTSfsadv-6.1.0.000-GA_RHEL5
...
VRTSsfmcs-6.1.0.0-0
VRTSsfmh-6.1.0.0-0
...
b Verify the /var/opt/VRTSsfmh/config.state to see if the MS is

been configured.
cs-configured

Note: For lab purpose, vom-ms is configured as a VOM 6.1 Management Server
on RHEL5.5 and has some pre-populated database for visualization
purpose only.

Exercise 2: Verifying processes and services running on VOM MS
In this exercise, you verify processes and services running on the VOM
management server on Linux platform.
mgt: root/train
1 Run the vomadm command to view status of the individual services.

/opt/VRTSsfmh/bin/vomadm service --status
Veritas Operations Manager Services:
Web Server....................[RUNNING]
Authentication Service........[RUNNING]
Messaging Service.............[RUNNING]
Database Service..............[RUNNING]
Distributed Command Line Daemon[RUNNING]
Watchdog......................[RUNNING]
SNMP Trap Service.............[RUNNING]
Note: Service option of vomadm command is used to start/stop the individual

services and is the recommended method especially when the Management
Server is configured for High Availability.
2 Run the ps -ef command to view status of the xprtld process.

ps -ef | grep xprtld
root 2129 1 0 Mar03 ? 00:01:01 /opt/
VRTSsfmh/bin/xprtld -X 1 /e
tc/opt/VRTSsfmh/xprtld.conf
root 8659 8597 0 06:55 pts/3 00:00:00 grep
xprtld

Exercise 3: Verifying processes and services running on VOM MH
In this exercise, you verify processes and services running on the VOM
managed host on the Windows and Linux platform.
sym1: root/train
1 Use ps command to verify the VOM processes running on the MS.

ps -aef|grep sfm
root 20197 1 0 Jan27 ? 00:00:35 /opt/
VRTSsfmh/bin/xprtld -X 1 /etc/opt/VRTSsfmh/xprtld.conf
root 20217 1 0 Jan27 ? 00:00:00 /opt/
VRTSsfmh/bin/perl /opt/VRTSsfmh/bin/sfmh-discovery.pl
…
root 24651 1 0 Jan27 ? 00:00:01 /opt/
VRTSsfmh/bin/vxdclid
…
2 Run the following commands to start/stop the individual processes.
a Run the /adm/xprtldctrl command to start/stop xprtld process.
/opt/VRTSsfmh/adm/xprtldctrl start
/opt/VRTSsfmh/adm/xprtldctrl status
running
/opt/VRTSsfmh/adm/xprtldctrl stop
stopped
b Run the command to verify status of the sfmh-discovery process.
/opt/VRTSsfmh/adm/vxvmdiscovery-ctrl.sh status
running

1 Navigate to the Windows Services panel and verify VOM related service is
running.
Veritas Storage Foundation Messaging Service is running
on Local System.
Note: sfmh-discovery and dcli processes do not run on Windows

Managed Hosts.

Exercise 4: Checking log files on VOM MS and MH
In this exercise, you check the configuration log files on the VOM managed host
on the Windows and Linux platform.
mgt: root/train
1 Navigate to the log directories to view management server log files on Linux
MS.
a For viewing general log files, navigate to /var/opt/VRTSsfmcs/

logs
cd /var/opt/VRTSsfmcs/logs
ls
action_agent_xdbadm.log monitorApp.log
vbs_configurator.log.1
ApiAccessLog.txt ReportRun.log
dbisql.log SupportLog.txt
dbsync.log tasklog.log
dbsync.log.lck tomcat.log
vbs_configurator.log.lck
discover_patch_meta.log unregister.log VMAdminLog.txt
discover_patch_meta.log.lck unregister.log.lck WebDebugLog.txt
guidstate.txt vbs_configurator.log
b For viewing database integration and upgrade logs, navigate to /var/

VRTSsfmcs/config_db
cd /var/VRTSsfmcs/config_db
ls
auth.sql.9938 config_db.log config_db.log.lck
c For viewing installer log file, navigate to /var/opt/VRTSsfmh/

logs/install_sfm.log
more /var/opt/VRTSsfmh/logs/install_sfm.log
...
Mon Aug 18 07:40:09 EDT 2014: Veritas Operations
Manager 6.1 installation

Mon Aug 18 07:40:27 EDT 2014:
AVLBL_SPACE_FOR_BIN_EXTRACTION = 66321 KB
Mon Aug 18 07:40:27 EDT 2014: MOUNT_POINT_DOT = /
Mon Aug 18 07:40:27 EDT 2014:
SPACE_RQD_FOR_BIN_EXTRACTION = 382 MB
Mon Aug 18 07:40:27 EDT 2014: MIN_SPACE_RQD_OPT = 1024
MB
Mon Aug 18 07:40:27 EDT 2014: MOUNT_POINT_OPT = /
...
d For viewing DB engine log, navigate to /var/opt/VRTSsfmcs/db/

data/SFMdb3.dblog
more /var/opt/VRTSsfmcs/db/data/SFMdb3.dblog
...
2015-01-05 08:44:34 EST 176105 habdbsync: LOG: call
SP_UPDATE_RULE_BASE_OE_MEMB ERS(2015-01-05
08:37:14.487215,2015-01-05 08:44:34.461719)
2015-01-05 08:44:34 EST 176105 habdbsync: STATEMENT:
select SP_update_oim_cron( )
2015-01-05 08:44:34 EST 176105 habdbsync: LOG:
SFMS:sp_update_oim:select sp_oir_grps ( 0,1,'be' ) :
...
sym1: root/train
1 Navigate to the log directory to view managed host log files.

cd /var/opt/VRTSsfmh/logs
ls
access.log
fetch_arrayinfo.log.lck
mhrun.log
vomadm.log
debug.log
hostguid.log
mhrun.log.lck
xprtldctrl.log
error.log
hostguid.log.lck
sfmh-discovery.log
fetch_arrayinfo.log
mh_ctl.log
sfmh-discovery.log.lck

Note: You may like to view contents of each log file by running more command.
1 From the command prompt window, navigate to logs directory.

cd C:\ProgramData\Symantec\VRTSsfmh\logs
dir
End of lab

Lab 3: Troubleshooting VOM
In this lab, you verify the discovered data using VOM console.
This lab contains the following exercises:
• Testing how xprtld works
• Troubleshooting host configuration issues
• Testing how patching works
• Troubleshooting add host issue
• Testing behaviour of the MS host and estimating file space usage
• Using vomgather.pl to collect VOM data
Lab 3: Troubleshooting VOM A–51

Lab prerequisites
All VMs should be running. Two terminal windows logged in as the root user
should be open on sym1 and sym2 systems.
The following table provides information needed for verifying discovered data
using VOM 6.1 console.
Attribute/properties Lab value

Linux Cluster host names sym1, sym2
SG configuration cvm, parallel SG
Cluster name west
Windows host names sym3, sym4
VOM console configured https://<mgt IP>:14161/vom
Software location /student/software/vom/vom61/MS

Exercise 1: Testing how xprtld works
In this exercise, you check the xprtld communication on MS and MH.
https://mgtIP:14161/vom: root/train
1 Navigate to the VOM console and verify error notification from the Server
perspective.
2 Go to Server > Uncategorised Hosts
3 Select mgt and click the Overview tab.
4 Under the Faults and Risks section, you can see the notification as ‘Host is
missing critical update’ for every host such as, mgt, sym1, and sym2.
5 When you click sym3, it shows one more notification as ‘VOM agent (xprtld)
is not communicating with the MS.’
6 In order to troubleshoot, let’s see how the Add Host page looks like.
a Go to Home > click Settings > click Host.
b In the Manage > Data Center section, you can see the discovery is
successful but the Status column is blank.
c Let’s go to mgt, and using CLI verify the processes running.
mgt: root/train
1 Run the ps -ef command to verify the processes running.

root 31399 30880 0 03:32 pts/0 00:00:00 grep xprtld
2 Let’s verify the status using /adm command and start the process.
stopped

RUNNING
root 2131 1 0 Jan27 ? 00:04:33 /opt/
VRTSsfmh/bin/xprtld -X 1 /etc/opt/VRTSsfmh/xprtld.conf
root 31015 30880 0 03:11 pts/0 00:00:00 grep
xprtld
3 Now, let’s verify the VOM console, Host page again.
4 Great, the status column now shows all the hosts are connected.
5 Let’s navigate to Server perspective and check the notification messages.
6 Go to Home > Server > Uncategorised Hosts > select Overview tab for each
server.
7 Confirm the status of mgt, sym1, sym2 notifications are cleared.
Note: If the status is still not shown as ‘Connected’, you can try removing all
three hosts and adding them back again to the VOM Management Server.
8 Sym3 still shows the error as xprtld communication is missing.
9 Let’s check if there are any host configuration issues on sym3.

Exercise 2: Troubleshooting host configuration issues
In this exercise, in order to clear the fault notification, you upgrade the VRTSsfmh
version to 6.1 on the managed host.
Issue: From the VOM console, Server perspective, sym3 host is shown as Faulted
and the risk notification indicates the following message:
Host is missing critical update

VOM agent (xprtld) is not running or unable to
communicate with the VOM Management Server.
sym3: Administrator/train
1 Go to the Control Panel > Program and Features, verify the version
installed for VRTSsfmh package.
2 Possible issue could be the VRTSsfmh package is not upgraded to 6.1
3 Navigate to /Students folder and run the

VRTSsfmh_6.1.0.0_Windows_arch_x64 file to upgrade the Managed Host
version to 6.1.
a Go to (student)Z:\software\vom\vom61\MS
b Double click VRTSsfmh_6.1.0.0_Windows_arch_x64.msi
4 The setup wizard displays the prompts to upgrade the managed host.

5 Click Install to begin the installation.
6 Wait while the setup wizard completes the installation of VOM host
components.
7 Click Finish to exit the setup wizard.
8 Navigate to Control Panel > Program and Features.
9 Verify the version of VOM host component is changed to 6.1.
10 Navigate to the VOM console and verify the hosts overview page from the
Server perspective.
a Go to https://<mgt IP>:14161/vom
b From the Home page, select Server perspective
c Go to Manage > Uncategorized Hosts > sym3

d Select Overview tab, verify the notification status is changed and status
shown as Healthy.
Note: When xprtld is stopped on the Veritas Operations Manager (VOM)

Management Server (mgt), a fault is not raised as it was shown for a
Managed Host (sym3). This is the known limitation of VOM MS.

Exercise 3: Testing how patching works
In this exercise, you identify the missing patches on the managed host and install
solution from the VOM console.
https://<mgt IP>:14161/vom: root/train
1 Go to Home > Settings > Deployment > Repository and expand the Hot
Fixes option.
2 From the Hot Fixes tab, verify vom 6.1.0.200 status as installed on 2 Linux
hosts and one windows host.
3 Right-click vom 6.1.0.200, select Install.
Note: Remember to apply the patch on mgt first and then proceed with sym3.
4 A new window is displayed, which shows sym3 is listed under applicable host
for the hotfix installation.
5 Select sym3 and click Finish.

6 A new Result window is displayed showing message as Install request is sent
successfully. Click OK.
7 In the Recent task field, you see the Install update status is in progress
Note: During the Hotfix installation, the VOM Web-server will be stopped. It will
be started when Hotfix install completes. This may take several minutes.
Once the Web-server is started, you will have to log-in again to the VOM
UI.
8 When the status changes to Completed, you can verify the sections under Hot
Fixes tab shows 4/4 installed.

Exercise 4: Troubleshooting add host issue
In this exercise, you troubleshoot an issue while adding a Windows host to the
management server. You identify the cause on the managed host, fix it and add
sym4 as a managed host from the VOM console.
1 From the mgt server, open the Mozilla browser and navigate to already
configured VOM console. Let’s try adding sym4 as the agent host from the
management server called mgt.
a From the Home page, click Settings > Add Host and select Agent from
the drop-down list.
b From the Add agent host window, enter host name and credentials for the
Windows host.
c Enter Host name: sym4
d Enter credentials as: Administrator/train
e Click Finish.
2 Notice the pre-configuration checks that console performs.
3 And then the Result window of the console shows an error.

Error V-383-50513-5745 Management Server is not
reachable from managed host. Add host operation cannot
proceed.

4 What could be the possible issue?
5 Check SORT for the v-code documentation (V-383-50513-5745)
6 Check add host log file.

[02/17/2015 09:27:32] Return code: 768
[02/17/2015 09:27:32] Checking to see if CS is reachable from MH
[02/17/2015 09:27:35] Output: HTTP/1.1 404 Not Found. Could not
connect to proxy target
404 Not Found. Could not connect to proxy target

[02/17/2015 09:27:35] Return code: 1024
[02/17/2015 09:27:35] fancy_die
[02/17/2015 09:27:35] ADD_HOST_CS_NOT_REACHABLE
[02/17/2015 09:27:35] fancy_dead
7 Try and verify bi-directional pinging from mgt and sym4.
8 From the log file it seems Windows host is not able to communicate with the
management server. So the next step is to verify basic settings on sym4.

sym4: Administrator/train
1 Verify the version of VOM Host component.
a Go to Control Panel > Programs and Features
b Verify the version of VOM Managed Host component is 6.1
2 Check if the services are running.
a Click Administrative Tools > Services
b verify that the Veritas Storage Foundation Messaging Service is

running.
3 From the command prompt window, ping mgt and check the output.
ping mgt
ping request could not find host mgt. Please check the
name and try again.
Note: The ping command output provides a hint that host name could not be
resolved from the Windows host. So need to verify the entry in the /etc/
hosts file.
4 Check /etc/hosts file.
a Navigate to C:/Windows/System32/Drivers/etc/hosts
b Double-click hosts file and open it using notepad or wordpad.
c Check for the mgt entry. Looks like it is missing.
d At the end of the file, type following entries, save the file and close it.
10.10.2.3 mgt
10.10.2.3 mgt.example.com
5 Let’s try adding sym4 from the VOM console again.

6 This time the add-host operation is successful, and sym4 is successfully
discovered from the management server.

Exercise 5: Testing behavior of the MS host and estimating file
space usage
In this exercise, we will be checking the behavior of another management server

called vom-ms. There is some pre-configured data stored on this MS and is used
for visualization purpose only. The prerequisite checks have been completed and
an acceptable precheck run has been made in a previous lab.
1 From the mgt server, open the Mozilla browser and navigate to already
configured VOM console. Let’s try managing vom-ms as the agent host from
the management server called mgt.
a From the Home page, click Settings > Add hosts > select Agent
b In the panel, add the host name vom-ms and credentials, and click Next.
2 Display the error.
3 What could be the possible issue?
4 Let’s navigate to the host and verify settings.
vom-ms: root/train
5 Verify packages installed on the host vom-ms.
rpm -qa | grep sfm

VRTSsfmh-6.1.0.0-0
VRTSsfmcs-6.1.0.0-0
6 Verify if MS is configured.
cs-configured
Note: The host is already configured as the Management Server. You cannot add
one management server to another management server’s domain.

7 Navigate to DB directory to verify the data discovered through the host.
cd /var/opt
ls -la
total 28
drwxr-xr-x 5 root root 4096 Jun 11 2014 .
drwxr-xr-x 29 root root 4096 Jan 20 2014 ..
drwxr-xr-x 2 root root 4096 Aug 16 2012 dbed_lic
lrwxrwxrwx 1 root root 19 Jan 20 2014 VRTSsfmcs -
> /var/opt/.VRTSsfmcs
drwxr-xr-x 11 habdbsync root 4096 Dec 16 08:25
.VRTSsfmcs
drwxr-xr-x 30 root root 4096 Dec 19 11:30 VRTSsfmh
cd VRTSsfmcs
ls
blist.sql logs sec vom

conf mh_cred.xml sfm_temp_cred.xml
vom_bkup.version
data pcreg_insert.err store
xdbadm_error.log
db reports VBS
ls db/data
base pg_ident.conf pg_snapshots pg_tblspc
postgresql.conf
global pg_multixact pg_stat pg_twophase
postmaster.opts
pg_clog pg_notify pg_stat_tmp PG_VERSION
postmaster.pid
pg_hba.conf pg_serial pg_subtrans pg_xlog
SFMdb3.dblog
Note: There are two databases on this management server. The VRTSsfmcs
directory contains the relational database (sybase or postgres). The
VRTSsfmh directory contains several subdirectories and lots of files that
make up a database (but not in the sense of a relational database like in
VRTSsfmcs)
cd ../VRTSsfmh
ls
actionagent.lock NR stats

annotations.json PC STORE
annotations.lock PCV_NOTIFY tasks
audit.msg PERF
tasks.json
audit.msg.lock ping_sfm.lock
tasks.lock
catalogs pkgsinfo
threshold.conf
CGITemp refresh_host.lock
threshold.conf.lock
config.state refresh_repository.lock tmp
DB remove_host.lock
trusted
etc rescan.lock
upgrade_cms.lock
event.lock rules
upgrade_mh.lock
fault_conditions.json scheduler.conf VCS
faults.lock scheduler.lock
vdid_def.conf
fetch-update-meta.lock sec vea
HOST setup_metering.lock VVRBW
host.sql SF
vxhostdeploy.lock
KVM sfmh-discovery.lock
whitelist.json
LDR sfm_VxArray12
xprtld.pid
logs shared xtrapd.pid
mh_config.ver sort
NATIVE spool
8 Run du command to estimate the file space usage.

du -sh ../VRTSsfmcs
104M /VRTSsfmcs
du -sh ../VRTSsfmh
914M /VRTSsfmh
Note: This indicates how du command can be helpful to customers to estimate

the file space usage when there are issues like upgrade failed due to space
requirement.

Exercise 6: Using vomgather.pl to gather VOM data
In this exercise, you execute vomgather.pl script for collecting data and logs from
the management server.
mgt: root/train
1 Run the vomgather.pl script to collect information from the management server
and store gathered data into the directory called vomgather.d.
/opt/VRTSsfmh/adm/vomgather.pl --dir /var/tmp/
vomgather.d
Executing /opt/VRTSsfmh/bin/perl /opt/VRTSsfmh/bin/
xinfo
got cmd output in /var/opt/VRTSsfmh/tmp/vomgather13823/
xinfo.out
Executing /opt/VRTSsfmh/bin/perl /opt/VRTSsfmh/bin/
mh_driver.pl --version
got cmd output in /var/opt/VRTSsfmh/tmp/vomgather13823/
mh_ver.out
Executing /opt/VRTSsfmh/bin/vxadm service status
.....
.....
.....
Backing up data /opt/VRTSsfmh/bin/perl /opt/VRTSsfmcs/
config/adm/vom_bkup.pl --backup /vomgather.d --exclude
Gathered data from VOM CMS
2 Navigate to the directory to see the contents.

cd /var/tmp/vomgather.d
vom_bkup.backup_log vomgather.log
vom_linux_mgt_14563.tar.gz
vom_bkup.backup_log.lck vomgather.log.lck
3 Unzip and extract files from the archive.

mkdir vomgather_data
cd vomgather_data
mv ./vom_linux_mgt_14563.tar.gz
gunzip vom_linux_mgt_14563.tar.gz
tar xvf vom_linux_mgt_14563.tar
...
var/opt/.VRTSsfmcs/xdbadm_error.log

var/opt/.VRTSsfmcs/.hostguid
var/opt/.VRTSsfmcs/conf/
var/opt/.VRTSsfmcs/conf/esmweb.cfg
var/opt/.VRTSsfmcs/conf/habguest.conf
...
var/opt/.VRTSsfmcs/conf/habdbsync.conf
var/opt/.VRTSsfmcs/conf/habgui.conf
var/opt/.VRTSsfmcs/conf/db-config.properties
var/opt/.VRTSsfmcs/conf/sahara.conf
var/opt/.VRTSsfmcs/conf/db-config.properties.postgres
var/opt/.VRTSsfmcs/conf/dba.conf
var/opt/.VRTSsfmcs/conf/web.locale
...
etc/vx/VRTSsfmcs/./
etc/vx/VRTSsfmcs/./.odbc.ini
etc/vx/VRTSsfmcs/./.odbcpg.ini
var/opt/VRTSsfmh/spool/addons/store/sadm.ini
cd /vomgather_data
etc
var
vom_linux_mgt_14563.tar
Note: Once the files are extracted, you can take a look at the configuration files
and log files. /etc and /var contains vomgather content for
standalone MS; MH and clustered VOM (VOMHA) contains additional sub-
directories.
We will analyse some of the sample logs and collected evidences in lab4.
End of lab

Lab 4: Analysing logs for troubleshooting issues
In this lab, you analyse the outputs from different log files, evidence collected, and
try to troubleshoot the issue.
This lab contains the following exercises:
• Analysing configuration log file
• Analysing add host log file
Lab 4: Analysing logs for troubleshooting issues A–69

Lab prerequisites
The following exercises are not to be performed in the assigned lab enviornment.
This lab particularly focus on example log files and evidences collected from
different VOM environment. The exercises will help in understanding the format
of different log files, how to view the entries, read errors/notifications, and identify
diagnostic steps to perform the basic troubleshooting tasks.
In the exercise, you analyse the output of log files.

Study the log details carefully. Discuss the key entries to look for so to identify the
root cause. Discuss the key entry, possible reason, and diagnostic steps.
1 What are the key entries you find in the log that will help to analyze the
problem?
2 What could be the possible reason?
3 What are the recommended steps?

Exercise 1: Analysing configuration log file
1 The output of configuration log
[02/03/2015 11:57:03] Return code: 0

[02/03/2015 11:57:03] creating task for Add host
[02/03/2015 11:57:04] ADD_HOST_PRECONFIG_CHK
[02/03/2015 11:57:04]
{"JOB":{"RETURNCODE":0,"ERROR":"Success","NAME":"add_host","OUT
PUT":"ADD_HOST_PRECONFIG_CHK","STATE":"SUCCESS","PROGRESS":1}}
[02/03/2015 11:57:04] retriving Agent password
[02/03/2015 11:57:04] ADD_HOST_INPUT_PARAM_CHK
[02/03/2015 11:57:04]
PUT":"ADD_HOST_INPUT_PARAM_CHK","STATE":"SUCCESS","PROGRESS":6}
}
[02/03/2015 11:57:04] user name is "root"
[02/03/2015 11:57:04] ADD_HOST_CONTACTING_MH
[02/03/2015 11:57:04]
PUT":"ADD_HOST_CONTACTING_MH","STATE":"SUCCESS","PROGRESS":20}}
[02/03/2015 11:57:18] Output: HTTP/1.1 302 OK
Status: 307 Moved
Location: /admin/htdocs/cs_config.htm
[02/03/2015 11:57:18] Return code: 768

[02/03/2015 11:57:18] Checking to see if CS is reachable from MH
[02/03/2015 11:57:18] Output: {
"XPRTLD_VERSION" : "6.1.0.200",
"LOCAL_NAME" : "mgt.example.com",
"LOCAL_ADDR" : "10.10.2.3",
"PEER_NAME" : "vom-ms.example.com",
"PEER_ADDR" : "10.10.2.30",
"LOCAL_TIME" : "1422982638",
"LOCALE" : "en_US.UTF-8",
"DOMAIN_MODE" : "TRUE",
"QUIESCE_MODE" : "RUNNING",
"OSNAME" : "Linux",
"OSRELEASE" : "2.6.32-431.el6.x86_64",
"CPUTYPE" : "x86_64",
"OSUUID" : "{00010050-5686-378c-0000-000000000000}",
"DOMAINS" : {
"sfm://mgt:5634/" : {
"admin_url" : "vxss://mgt:14545/sfm_admin/sfm_domain/
vx",
"primary_broker" : "vxss://mgt:14545/sfm_agent/
sfm_domain/vx"
}

}
}
[02/03/2015 11:57:18] Return code: 0

[02/03/2015 11:57:18] CS host (mgt) is resolvable
[02/03/2015 11:57:18] Trying to figure out if host is already
part of the domain
[02/03/2015 11:57:18] Executing: /opt/VRTSsfmh/bin/xprtlc -u
nobody -l https://localhost:5634/agent/domain/enum
[02/03/2015 11:57:19] ADD_HOST_SEND_CRED_MH
[02/03/2015 11:57:19]
PUT":"ADD_HOST_SEND_CRED_MH","STATE":"SUCCESS","PROGRESS":30}}
[02/03/2015 11:57:19] Output: SUCCESS
[02/03/2015 11:57:19] Return code: 0

[02/03/2015 11:57:21] push_exec command succeeded [/opt/
VRTSsfmh/bin/getvmid_script]
[02/03/2015 11:57:22] ADD_HOST_INIT_DISCOVERY
[02/03/2015 11:57:22]
PUT":"ADD_HOST_INIT_DISCOVERY","STATE":"SUCCESS","PROGRESS":75}
}
[02/03/2015 11:57:22] Executing /opt/VRTSsfmh/bin/xprtlc -u
"root" -j /var/opt/VRTSsfmh/xprtlc-payload-YrOhDJlU -l https://
vom-ms:5634/admin/cgi-bin/sfme.pl operation=configure_mh&cs-
hostname=mgt&cs-ip=10.10.2.3&mh-hostname=vom-ms&agent-
password=******
[02/03/2015 11:57:28] Waiting for output from configure_mh----
[02/03/2015 11:57:28]
}
[02/03/2015 11:57:28]
}
[02/03/2015 11:57:28]
}
[02/03/2015 11:57:32]
[02/03/2015 11:57:32]
}

[02/03/2015 11:57:32]
}
[02/03/2015 11:57:32] fancy_die
[02/03/2015 11:57:32] CONFIGURE_MH_HOST_IS_CS
[02/03/2015 11:57:32] fancy_dead
Note: The return codes are perl language return codes. TSEs must give less
weightage for such return codes. And look for the Veritas error-code (error
V-383-xx-xxx) if any. The logging is improved in latest release of VOM so
that Support Engineers can easily find out root cause of add host failure.

Exercise 2: Analysing add host log file
1 The output of add host log

[01/06/2015 14:21:17] Return code: 0
[01/06/2015 14:21:17] creating task for Add host
[01/06/2015 14:21:17] ADD_HOST_PRECONFIG_CHK
[01/06/2015 14:21:17]
PUT":"ADD_HOST_PRECONFIG_CHK","STATE":"SUCCESS","PROGRESS":1}}
[01/06/2015 14:21:17] retriving Agent password
[01/06/2015 14:21:17] ADD_HOST_INPUT_PARAM_CHK
[01/06/2015 14:21:17]
PUT":"ADD_HOST_INPUT_PARAM_CHK","STATE":"SUCCESS","PROGRESS":6}
}
[01/06/2015 14:21:17] user name is "root"
[01/06/2015 14:21:17] ADD_HOST_CONTACTING_MH
[01/06/2015 14:21:17]
PUT":"ADD_HOST_CONTACTING_MH","STATE":"SUCCESS","PROGRESS":20}}
[01/06/2015 14:21:17] Output: HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="vom-rhev1-vm2"
[01/06/2015 14:21:17] Return code: 1024
[01/06/2015 14:21:17] fancy_die
[01/06/2015 14:21:17] ADD_HOST_INVALID_USERNAME_PSWD
[01/06/2015 14:21:17] fancy_dead

Answer key:
Log 1:
The key message to study here is:
[02/03/2015 11:57:32] CONFIGURE_MH_HOST_IS_CS
The host you are trying to add is configured as a management server. VOM doesn’t support
adding one management server to another management server’s domain. Either uninstall the
management server packages from the selected host and try adding again OR rectify the issue.
Log 2:
The key message to study here is:
[01/06/2015 14:21:17] ADD_HOST_INVALID_USERNAME_PSWD
Authorization Required. The server could not verify that you are authorized to access the host
requested. Either you supplied the wrong credentials (e.g, bad password), or your browser
doesn't understand how to supply the credentials required.
End of lab

Appendix B: Job-aids
This flashcard is developed as a troubleshooting job‐aid. Use the set of questions to reflect on the problem and ask yourself when you start
analyzing the problem/error/issue to be fixed. The questions will help as guidelines to troubleshoot in right direction.
VOM 6.1 Troubleshooting | Flashcard Page 57

A case example: Reporting escalation cases to Engineering from Support
‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
From: xxxx xxxxx
Sent: 10 September 2014 11:03
To: DL-ENG-SFMS-ONCALL; xxxxxx
Cc: Enterprise_Technical_Support; Moinudeen Ahmed Mustafa
Subject: [Pri2][SF 07145699] [Etrack 3615791 ] [VOM 6.1]Landstinget I Östergötland: after 6.1 upgrade
MHs appear as not installed [ ref:_00D30jPy._50050V9n8I:ref ]
Hi Team,
I have created Etrack 3615791 to follow the investigation in to this issue.
Following a 6.1 VOM upgrade, the existing MHs were not seen in the host table and after host upgrade
to 6.1 they appeared as “uninstalled”
#===========================================================================
# VERITAS SUPPORT TO ENGINEERING ESCALATION TEMPLATE Ver1.8/20020911
#===========================================================================
Reason for advancement
possible corrup DB after VOM 6.0 ‐ 6.1 upgrade
Date reported to Support: 20th Aug 2014
Date reported to Backline: 9th Sept 2014
Date escalated to Engineering: 10th Sept 2014
Case ID#: 07145699
Company Name: Landstinget BC
ENGINEERING Escalation Priority: 2
Current State of Customer System: degraded and regressed back to Vom 6.0
Technical Support Engineer: Moinudeen Ahmed Mustafa
Backline Engineer: Rick Stephens
Brief Problem Description:
Brief Description of problem: after upgrading to VOM 6.1 MS, the hosts are not
seen listed in the hosts tab.but can be seen from settings. there are some
management hosts where he upgraded VOM to 6.1 mh, which are showing its status
as "Not Installed" in MS . actually it should be showing as Installed. only
after reboot of MH, the change gets effect on MS showing "installed" state.Due
to this issue, customer revert back the change and now customer is using VOM
6.0. customer asking if he needs to add MH only by one to the MS as he is
unable to see it.
VOM 6.1 Troubleshooting: Lesson 2 Page 58
A case example: Reporting escalation cases to Engineering from Support
Action(s) Requested: Assist with investigation
Exact VERITAS Product(s) and Version(s): VOM 6.0 ‐ 6.1 upgrade
Operating System and Version: Linux RH 6.x
Vomgather
Location Of Evidence:
http://mtv‐evidence.spr.spt.symantec.com/evidence/mtv/99/07145699/
Additional Analysis or Comments:
Error seen the vxdeploy.log suggest DB corrupt or problems retreiving data from
it:
/evidence/mtv/99/07145699/vom_s‐
santest1_7896/ProgramData/Symantec/VRTSsfmh/logs]$ more vxdeploy.log
2014‐05‐20 09:10:16 [debug] 7628 vxdeploy:
#################Starting vxdeploy
2014‐05‐20 09:10:23 [error] 7628 vxdeploy: query_table: Query select * from
HABDBSYNC.SF_VIEW_ADD_ON_R; failed: 768:
2014‐05‐20 09:10:23 [error] 7628 vxdeploy: list_store: Failed to query DB
2014‐09‐01 12:27:04 [debug] 7712 vxdeploy:
#################Starting vxdeploy
2014‐09‐01 12:27:06 [error] 7712 vxdeploy: query_table: Query select * from
HABDBSYNC.SF_VIEW_ADD_ON_R; failed: 768:
2014‐09‐01 12:27:06 [error] 7712 vxdeploy: list_store: Failed to query DB
Kind regards
Rick
Richard Stephens
Principal Tech Support Engineer
Technical Services
Symantec (UK) Ltd.
www.symantec.com
‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐
Steps to upload a PostgreSQL database for troubleshooting
Refer the detail steps below to learn how to upload 6.1 customer databases into PostgreSQL database in
Support lab machines. The instructions are provided for the MS on Linux and Windows platform.
Linux MS
Source Machine: (Customer Setup)
1. # /opt/VRTSsfmh/bin/perl /opt/VRTSsfmh/adm/vomgather.pl --dir
/tmp/my61backup --full
2. Copy vom_backup_linux_6.1.0.0.tar.gz to target machine.
Target Machine: (In‐house Lab Setup)
1. Stop Database Service
a. # /opt/VRTSsfmh/bin/vomadm service --stop db
2. Create stage directory to store ‘source/customer’ gathered archive
a. # mkdir /tmp/stage
b. # mv /tmp/vom_backup_linux_6.1.0.0.tar.gz /tmp/stage
c. # cd /tmp/stage
3. Unzip and extract database files from archive
a. # gunzip vom_backup_linux_6.1.0.0.tar.gz
b. # tar xvf vom_backup_linux_6.1.0.0.tar
4. Rename existing ‘target/in‐house’ 6.1 MS database files
a. # cd /var/opt/VRTSsfmcs/db/
b. # mv data data_org
5. Copy ‘source/customer’ database directory from stage location to production location, note ‐rp
flags as the permissions also needs to be preserved while copying database files:
a. (If 6.1 MS installation is with Default database location)
b. # cp -rp /tmp/stage/var/opt/VRTSsfmcs/db/data
/var/opt/VRTSsfmcs/db/
c. (If 6.1 MS installation is with Non‐Default database location)
d. # cp -rp /tmp/stage/<non-default-dir-
name>/.VRTSsfmcs/db/data /var/opt/VRTSsfmcs/db/
6. Start Database Service
a. /opt/VRTSsfmh/bin/vomadm service --start db
7. Login to in‐house lab MS
8. This completes customer DB upload steps; however please refer below step if Web service
needs to be restarted later.
9. Update Broker Info in database to resolve GUI/web service startup issues:
a. Create one sql file and add following query
b. # vi /tmp/mysql.sql
c. update habdbsync.p_broker_info set domain_name= '<in-house
lab MS FQHN>', broker_name='<in-house lab MS FQHN>';
d. # /opt/VRTSsfmh/bin/xdbadm -f /tmp/mysql.sql -o
/etc/vx/VRTSsfmcs/.odbc.ini -c /var/opt/VRTSsfmcs/conf -d
SFMdb3 –v
Steps to upload a PostgreSQL database for troubleshooting
Windows MS
Source Machine: (Customer Setup)
1. C:\>"c:\Program Files\Veritas\VRTSsfmh\bin\perl.exe"
"c:\Program Files\Veritas\VRTSsfmh\adm\vomgather.pl" --
dir c:\my61backup –full
2. Copy vom_backup_win_6.1.0.0.zip to target machine.
Target Machine: (In‐house Lab Setup)
1. Stop Database Service
2. C:\>"C:\Program Files\Veritas\VRTSsfmh\bin\perl.exe" "C:\Program
Files\Veritas\VRTSsfmh\bin\vomadm.pl" service --stop db
3. Create ‘C:\Stage’ directory to store ‘source/customer’ gathered archive (refer step 2) and
Extract archive.
4. Backup existing ‘target/in‐house’ 6.1 MS database files at
“C:\ProgramData\Symantec\VRTSsfmcs\db\data” to
“C:\ProgramData\Symantec\VRTSsfmcs\db\data_org”
5. Copy and replace ‘source/customer’ database files from stage location to production location
data directory:
6. For eg:
7. Stage Location:
C:\Stage\vom_backup_win_6.1.0.0\ProgramData\Symantec\VRTSsfmcs\db
\data\*
8. Production location:
9. C:\ProgramData\Symantec\VRTSsfmcs\db\data\*
10. Start Database Service
C:\>"C:\Program Files\Veritas\VRTSsfmh\bin\perl.exe" "C:\Program
Files\Veritas\VRTSsfmh\bin\vomadm.pl" service --start db
11. For windows, need to update P_SECURITY_GROUP and P_BROKER_INFO with existing in‐house
lab MS information in database.
12. Create one sql ‘c:\mysql.sql’ file and add following query
i. update habdbsync.p_security_group set name= <in-house
lab MS HOSTNAME>\Administrators';
ii. update habdbsync.p_broker_info set domain_name= '<in-
house lab MS FQHN>', broker_name='<in-house lab MS
FQHN>';
13. "C:\Program Files\Veritas\VRTSsfmh\bin\xdbadm" -f c:\mysql.sql -o
C:\ProgramData\Symantec\VRTSsfmcs\.odbc.ini -c
C:\ProgramData\Symantec\VRTSsfmcs\conf -d SFMdb3 -v
Cases created from 10/01/2013 through 11/01/2014 for Veritas Operations Manager
KM Articles Linked by Date run: 11/5/2014 9:19:52 AM
Article ID Number of Cases Title

TECH199426 8 HOWTO: How to use the vomgather utility to gather logs for Veritas Operations Manager
(VOM).
HOWTO51891 6 How to use the vomgather utility to gather logs for Veritas Operations Manager.
HOWTO32575 4 3 steps to use the SORT Data Collector to gather and submit an enhanced vxexplorer
troubleshooting archive (Unix)
TECH183027 4 Nessus security scanner identifies Veritas Operations Manager (VOM) components
TECH206121 4 When adding a Managed Host to the Veritas Operations Manager (VOM) domain, the error
is encountered: Management Server is not reachable from managed host.
TECH212372 4 Upgrade to Veritas Operations Manager 6 (VOM 6.0) fails at database update
TECH216500 4 Is Veritas Operations Manager (VOM) affected by the Heartbleed vulnerability?
TECH223438 4 "Database configuration failed" during configuration on the Central Management Sever
while installing VOM 6.1
DOC7482 3 Veritas™ Operations Manager 6.1 Release Notes
HOWTO94645 3 Adding managed hosts to Management Server using the Auto Configure (gendeploy.pl)
script in Veritas Operations Manager 6.0
TECH174842 3 VMware Configuration discovery fails with error, Error in discovery: no data available
TECH183915 3 Error is encountered while configuring Veritas Operations Manager (VOM) on the Central
Server; error: Database configuration failed
TECH209223 3 Veritas Operations Manager (VOM) 5.0 cumulative hotfix 1 (HF1)
TECH211214 3 xprtld fails to start after changing the VOM CS server hostname and/or IP address
TECH217242 3 Veritas Operations Manager (VOM) unable to connect to web console after install of
HotFix2 (vom‐6.0.0.0200a)
DOC6797 2 Veritas™ Operations Manager Management Server 6.0 User Guide
HOWTO100858 2 About upgrading Management Server to Veritas Operations Manager 6.1
HOWTO94769 2 Gathering information for troubleshooting
HOWTO94861 2 Upgrading managed hosts using the Veritas Operations Manager 6.0 console
HOWTO94955 2 Using Veritas Operations Manager 6.0
HOWTO94958 2 How to upgrade to Veritas Operations Manager 6.0
TECH155909 2 Configuring Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) as
domain within an authentication broker under Veritas Operations Manager (VOM)
TECH172819 2 "VxVM vxplex ERROR V‐5‐1‐10870 fsgen/vxplex: Warning: vxsync exited with exitcode 42:
Volume data may not be flushed to all plexes" appears when attempting to dissociate a plex
TECH185450 2 Veritas Operations Manager (VOM) and custom SSL certificate.
TECH190704 2 Status of objects not being displayed correctly in Veritas Operation Manager (VOM)
Page 1 of 7
TECH195638 2 Qualsys Security Scan identified a vulnerability on the port 5634 used by xprtld process
TECH203525 2 Using the SORT Data Collector to gather logs for Storage Foundation Technical Support
TECH210708 2 Veritas Operations Manager 6.0 Late Breaking News (LBN)
TECH211826 2 Managed hosts with duplicate virtual machine identifiers are automatically removed by
Veritas Operations Manager (VOM)
TECH214622 2 Error encountered when upgrading Veritas Operations Manager (VOM) regarding
declarations.store
TECH214698 2 VOM 6 Product Inventory generates a SQL error
TECH215194 2 Error uploading VOM 6.0 HF‐1
TECH216056 2 New Control Host addon for VOM 6.0 with updated Java is now available
TECH216501 2 Add Windows host into Linux VOM6.0 domain fail if Windows OS has Chinese language pack
installed
TECH216838 2 Considerations when using Storage Insight addon in Veritas Operations Manager (VOM) for
Netapp array discovery in relation to Heartbleed bug
TECH222934 2 Upgrading VOM managed host 3.1.x to 6.1
TECH67777 2 VxVM:xxxx: ERROR: IPC Failure: Configuration daemon is not accessible
DOC5782 1 Veritas Operations Manager 5.0 Frequently Asked Questions
DOC5789 1 Veritas™ Operations Manager Management Server 5.0 Installation Guide
DOC5884 1 Veritas Storage Foundation™ and High Availability 6.0.1 Installation Guide ‐ Linux
DOC6778 1 Veritas™ Operations Manager Management Server 6.0 Add‐ons User Guide
DOC6832 1 Veritas™ Operations Manager 6.0 Release Notes
DOC7472 1 Veritas™ Operations Manager Management Server 6.1 Installation and Configuration Guide
HOWTO100890 1 Upgrading managed host using the Veritas Operations Manager 6.1 console
HOWTO19001 1 Configuring a CA‐signed SSL certificate
HOWTO36625 1 Migrating volumes from one storage array to another using a mirror (plex)
HOWTO38237 1 How to Submit a Suggestion or Idea for Symantec Products.
script
HOWTO60283 1 About setting up file system alerts for file system usage
HOWTO64511 1 Log file locations for displaying log files and their default locations
Page 2 of 7
HOWTO65598 1 Virtual Business Service start operation does not validate the service group's resource
criticality (2169223)
HOWTO77835 1 About log file locations in Veritas Operations Manager 5.0
HOWTO77856 1 Uninstalling Veritas Operations Manager 5.0 Management Server on UNIX
HOWTO77927 1 Creating alert rules using Veritas Operations Manager 5.0
HOWTO78126 1 Authentication broker crashes while performing LDAP authentication (2017319)
HOWTO78324 1 XPRTLD daemon fails when Veritas Operations Manager starts because of the corrupt AT
pem files in the VRTSsfmh package (2145925)
HOWTO78395 1 About Veritas Operations Manager Package Anomaly Add‐on 5.0
HOWTO78656 1 Virtual Business Service start operation does not validate the service group's resource
criticality (2169223)
HOWTO78953 1 Service management using the vomadm utility in Veritas Operations Manager 5.0
HOWTO79025 1 Upgrading host management to Veritas Operations Manager 5.0 on UNIX using operating
system commands
HOWTO79303 1 Modifying the default IP address and host name of the existing UNIX‐based Management
Server for high availability configuration in Veritas Operations Manager 5.0
HOWTO79321 1 Configuring service group dependencies for a Virtual Business Service using VBS Availability
Add‐on 5.0
HOWTO80561 1 V‐223‐7‐3980
HOWTO82328 1 How to unconfigure DMP support for LVM boot volume group when bootdisk is on VSCSI
devices?
HOWTO83301 1 Installing HSCL Pack 1 Add‐on for Management Server in Veritas Operations Manager 5.0
HOWTO94638 1 Viewing the overview of SFHA licenses in the data center in Veritas Operations Manager 6.0
HOWTO94687 1 About backing up and restoring Veritas Operations Manager 6.0 data
HOWTO94808 1 Restoring backed up Veritas Operations Manager 6.0 data on Linux
HOWTO94882 1 Edit Rule ‐ Select the type of fault condition to trigger this rule panel options
HOWTO94926 1 About upgrading managed hosts to Veritas Operations Manager 6.0
HOWTO94930 1 Restricting users or user groups from accessing the Veritas Operations Manager 6.0 console
HOWTO94953 1 Commands to start and stop the Veritas Operations Manager processes on Management
Server on Linux
HOWTO94961 1 Adding and managing hosts in Veritas Operations Manager 6.0
HOWTO94981 1 Storage area network fabric discovery using Fabric Insight Add‐on 6.0
HOWTO98549 1 System resource requirements for Veritas Operations Manager 6.0
Page 3 of 7
TECH102607 1 How to update content for Symantec Endpoint Protection Manager using a .jdb file
TECH105179 1 Tuning the Performance of the Symantec Endpoint Protection Manager console
TECH122466 1 Virus removal and troubleshooting on a network
TECH128126 1 How to prevent ERROR V‐5‐1‐10128 No more space in disk group configuration Description:
There is no more space in the disk group�s configuration database for VxVM object
TECH129836 1 SFMH mh_driver.pl ‐‐family NR consumes very high ~49% CPU time.
TECH137016 1 VOM displays a fault that vxdclid is not running on the Managed Host when it is
TECH145505 1 Symantec Data Insight 2.x Troubleshooting Guide
TECH145674 1 GENERAL ERROR: NBU status: 800, EMM status: Disk volume is down
TECH150618 1 VXVCS service failed to start on Storage Foundation for Oracle 5.0MP3 (Solaris)
TECH157425 1 Networking requirements for Veritas Operations Manager 3.0
TECH157449 1 Basic troubleshooting and Setup information for Veritas Operations Manager.
TECH157561 1 Symantec Product Authentication API Error Codes
TECH158489 1 xprtld daemon failed when CMS IP was changed,but also failed connection to second CMS
TECH158498 1 PRO:Unknown in the Kernel log of the LAN Enforcer
TECH161453 1 VCS WARNING V‐16‐1‐10638 IpmHandle::recv _read_errno is 5. Client (hareg) Pid <PID>
TECH162305 1 Veritas Operation Manager (VOM) Managed Hosts (MH) no longer report to VOM
Management Server (MS).
TECH164663 1 After upgrade from VOM 3.x to VOM 4.0, vom_bkup.pl fails showing "Out of memory!".
TECH164885 1 Late Breaking News (LBN) ‐ Updates to the Release Notes for Veritas Storage Foundation
and High Availability Solutions 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, and 6.0.5
TECH166401 1 Veritas Operation Manager process MH_DRIVER.PL is constantly respawned and consumes
CPU resources
TECH167020 1 Service Group failed over after ERROR "VCS ERROR V‐16‐2‐13067 (node1) Agent is calling
clean for resource(resource1) because the resource became OFFLINE unexpectedly, on its
TECH167494 1 Login to VOM Console fails showing "HTTP Status 500". ERROR
java.lang.NullPointerException; Webserver: [SEVERE] SAXParseException
TECH168232 1 Default location of the VOM (Veritas Operations Manager) MIB file.
TECH168806 1 Clustered hosts are appearing in VOM with the name of the virtual host or gateway
appliance
TECH169247 1 Basic troubleshooting and Setup information for Veritas Operations Manager (VOM).
TECH170785 1 Central server is not generating Email alerts.
TECH174455 1 Addons not added to repository in GUI after successful uploads
Page 4 of 7
TECH17676 1 How to use the VRTSexplorer utility to gather information useful for Symantec Corporation
Technical Support
TECH1794 1 Intentional Panic of a node in a Veritas Cluster Server cluster by GAB
TECH179557 1 GAB: Port b halting system due to network failure
TECH180819 1 Invalid CA certificate error V‐223‐7‐3980
TECH182722 1 Veritas Operations Manager (VOM) authentication not working when using non‐root users
authenticating with OS‐based PAM enabled authentication
TECH183706 1 Configuration issue when installing Virtual Business Service (VBS)
TECH184404 1 Enquiry about ALERTS in VOM
TECH184796 1 QualysGuard Enterprise Suite security scanner identifies Veritas Operations Manager (VOM)
components
TECH184835 1 After /var filesystem filled up and space issue resolved, an error was encountered when
logging into Veritas Operations Manager (VOM)
TECH185254 1 Filesystems not displayed in Veritas Operations Manager (VOM)
TECH185285 1 Unable to remove Host from VOM as it's CH
TECH189942 1 Where can I download the Veritas Cluster Server (VCS) Java Console, the Veritas Enterprise
Administrator (VEA) and the Veritas Cluster Server Simulator?
TECH194707 1 VxVM vxdisksetup ERROR V‐5‐2‐43 c3t50060E8006D2D521d35: Invalid disk device for
vxdisksetup
TECH194963 1 Why is the administrator or root user unable to login after an upgrade or fresh install of
Veritas Operations Manager 5.0 on Solaris 10 Sparc Management Server.
TECH195100 1 New disk adding to the existing diskgroup under vcs, seting up volume and mount resource.
TECH195635 1 Qualsys Security Scan identified a vulnerability on the port used by xprtld process (typically
5634).
TECH195711 1 Getting a clean Qualys Security scan of the Secure Sockets Layer protocol vulnerability for
port 5634 requires Veritas Operations Manager 5.0 and a configuration change.
TECH195755 1 "Operation install failed for hotfix HF050001960‐01" error appears when installing
HF050001960‐01 for VOM (Operations Manager) 5.0
TECH198254 1 Why does the Veritas Enterprise Administrator functionality on Storage Foundation 6.0.1 /
6.0PR1 for Solaris 11 fail from the Veritas Operations Manager Console?
TECH199403 1 Veritas Operations Manager (VOM) is displaying an xprtld fault,
/etc/default/sfm_resolv.conf is discovered missing at the Managed Host (MH)
TECH200338 1 Error while adding Managed Host (ADD_HOST_VERIFY_FAILED)
TECH200616 1 Managing Licenses in Veritas Storage Foundation and Veritas Cluster Server
TECH200824 1 VRTSexplorer on SFHA 6.0.1 fails to gather system configuration details on SUSE Linux
Enterprise Server (SLES) 11 SP2 with Kernel updates beyond 3.0.13‐0.27.1
TECH201558 1 Unable to login to VOM management server console GUI installed on Solaris 10 SPARC after
upgrade to VOM 5.0
TECH204048 1 Veritas Operations Manager (VOM) Windows Managed Hosts (MH) with Storage
Foundation for Windows (SFW) installed reports incorrect disk Serial number.
TECH204950 1 Stripe set performance considerations for Veritas Storage Foundation
Page 5 of 7
TECH205635 1 vxfen driver is unloaded by /sbin/rc3 in Solaris SMF multi‐user‐server milestone
TECH206665 1 Veritas Operations Manager (VOM) process xprtld is consuming 100% of CPU
TECH207103 1 HOWTO: In Veritas Operations Manager (VOM), using vomadm to remove a Managed Host
(MH) from the domain at the command line
TECH208478 1 "xprtld process is down"
TECH20928 1 How to rename a disk if the disk media name contained non‐alphanumeric characters
TECH212977 1 Unable to log into VOM 6 UI where it can work in VOM 5
TECH213594 1 Can you configured SMTP authentication for Veritas Operation Manager (VOM) Mangement
Server ?
TECH214534 1 Veritas Operations Manager (VOM) 6.0 Agentless discovery for Linux Host with device‐
mapper cannot correlate physical disks with LVM volume‐groups and volumes.
TECH215520 1 Veritas Operations Manager (VOM) web services API can't access dbfile object type for
Oracle database
TECH215572 1 Ports and protocols used by a VOM Management Server while accessing and utilizing SORT
TECH215791 1 How to add a NetBackup Appliance 5220 into VOM?
TECH215990 1 Unable to manage file systems from VOM 6.0
TECH216288 1 Unable to configure LDAP authentication in VOM using IBM Tivoli Directory Server
TECH216422 1 SPVU reports NA on some LPARs (clicking NA link gives error "Virtualization server not
found")
TECH216709 1 Important information about the "Heartbleed" OpenSSL vulnerability and how it affects
Information Availability products
TECH217102 1 When add Linux Managed Host(MH) to Veritas Operations Manager(VOM) 6.0 domain fails
with "Error ‐1" code
TECH217580 1 System logged too many scsi errors for EMC MirrorView Disks
TECH217639 1 Replicated Volume Groups not discovered when host aliasing is used on a Windows
Managed Host
TECH21770 1 Preventing service group failover options in VERITAS Cluster Server (VCS)
TECH218376 1 Late Breaking News (LBN) for Veritas Operations Manager (VOM) 6.1.
TECH218499 1 Container object change in Veritas Operations Manager 6.x
TECH222274 1 VOM discovery of switches becomes unresponsive at "Switch discovery in progress."
TECH223233 1 MH would not start after upgrade to VOM 6.0
TECH223828 1 How to disable and uninstall control‐host add‐on on managed host?
TECH224093 1 Error while configuring VOM 6.1 in High Availability environment
TECH224319 1 Private Fix: Increase the VOM API Certificate validation period beyond 9 hours
Page 6 of 7
TECH224500 1 How to upgrade.
TECH224532 1 VOM seems to cause tape drives to rewind when Linux host is added to VOM domain
(configured as Managed Host)
TECH33489 1 How to increase the private region of a Volume Manager disk
TECH53492 1 Exceeding available space in private region for disk group configuration results in the error
"V‐5‐1‐10128 no more space in disk group configuration"
TECH55625 1 Get the message "WARNING: VxVM VVR vxio V‐5‐0‐293 SRL header for RVG <rvg> is of older
version (version 20)" after upgrading to VVR MP2
TECH62887 1 If disk is not seen properly by Operating System (OS), Volume Manager won't see it properly
TECH69409 1 System panics while installing 5.0MP3, during patchadd of # 122058‐11.
TECH69476 1 Solaris 8 system panics while installing 5.0MP3, during patchadd of # 122058‐11.
TECH70319 1 Can the plex name be changed on a mounted active volume.
TECH72540 1 What is the Event Source Daemon (vxesd) ?
TECH76355 1 "Data Corruption Protection Activated"
TECH78028 1 Veritas File Systems with Disk Layout Version 4 or Version 5 Cannot be Mounted or
Upgraded with Veritas File System Release 5.1
TECH83441 1 Ports that are used by Veritas Storage Foundation for Windows and Storage Foundation HA
for Windows
TECH87101 1 Performance checklist with VXFS and VXVM.
TECH90439 1 How to change the hostname on Solaris and HP‐UX
Page 7 of 7
4‐25

200-002918 Vom61 TS PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

200-002918 Vom61 TS PDF

Uploaded by

Copyright:

Available Formats

Veritas Operations Manager 6.

Lead Subject Matter Technical Contributors and

In the troubleshooting section, the course provides comprehensive instruction on

• Job-aid for ‘Using Symantec Web resources’

Lab 1: Lab environment overview A–3

A–4 Veritas Operations Manager 6.1: Troubleshooting

Lab 1: Lab environment overview A–5

A–6 Veritas Operations Manager 6.1: Troubleshooting

Lab 1: Lab environment overview A–7

A–8 Veritas Operations Manager 6.1: Troubleshooting

Lab 1: Intro Lab A: Using VMware Workstation in a classroom A–9

A–10 Veritas Operations Manager 6.1: Troubleshooting

Lab 1: Intro Lab A: Using VMware Workstation in a classroom A–11

1 Review the current settings for each virtual computer.

a To select a virtual computer, click a tab.

2 Start the mgt virtual computer.

a In VMware, click the mgt tab.

A–12 Veritas Operations Manager 6.1: Troubleshooting

c Wait until the logon window is displayed.

3 Start the util1 virtual computer.

a In VMware, click the util1 tab.

b From the toolbar, click the green Power On button.

c Wait until the logon window is displayed. .

4 Start the util2 virtual computer.

a In VMware, click the util2 tab.

b From the toolbar, click the green Power On button.

c Wait until the logon window is displayed.

5 Start the sym1 virtual computer.

a In VMware, click the sym1 tab.

b From the toolbar, click the green Power On button.

c Wait until the logon window is displayed

Lab 1: Intro Lab A: Using VMware Workstation in a classroom A–13

6 Start the sym2 virtual computer.

a In VMware, click the sym1 tab.

b From the toolbar, click the green Power On button.

c Wait until the logon window is displayed.

7 Start the sym3 virtual computer.

a In VMware, click the sym1 tab.

b From the toolbar, click the green Power On button.

c Wait until the logon window is displayed.

8 Start the sym4 virtual computer.

a In VMware, click the sym2 tab.

b From the toolbar, click the green Power On button.

c Wait until the logon window is displayed.

A–14 Veritas Operations Manager 6.1: Troubleshooting

9 Start the vom-ms virtual computer.

a In VMware, click the vom-ms tab.

b From the toolbar, click the green Power On button.

c Wait until the logon window is displayed.

Lab 1: Intro Lab A: Using VMware Workstation in a classroom A–15

1 Log on to mgt as root with password train.

a Click the mgt tab.

b Logon to mgt using the following credentials:

› User name: root

c Press Enter or click the arrow.

2 Log on to sym1 as root with password train.

a Click the sym1 tab.

b Logon to sym1 using the folowing credentials:

› User name: root

c Press Enter or click the arrow.

3 Logon to sym2 as root with password train.

A–16 Veritas Operations Manager 6.1: Troubleshooting

b Logon to sym2 using the following credentials: