SPECTRUM Virtual Host Manager

Solution Guide (5192)

r9.1

SPECTRUM® Virtual Host Manager

This documentation and any related computer software help programs (hereinafter referred to as the

―Documentation‖) is for the end user’s informational purposes only and is subject to change or withdrawal by CA at

any time.

This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in

part, without the prior written consent of CA. This Documentation is confidential and proprietary information of CA

and protected by the copyright laws of the United States and international treaties.

Notwithstanding the foregoing, licensed users may print a reasonable number of copies of the Documentation for

their own internal use, and may make one copy of the related software as reasonably required for back-up and

disaster recovery purposes, provided that all CA copyright notices and legends are affixed to each reproduced copy.

Only authorized employees, consultants, or agents of the user who are bound by the provisions of the license for

the Product are permitted to have access to such copies.

The right to print copies of the Documentation and to make a copy of the related software is limited to the period

during which the applicable license for the Product remains in full force and effect. Should the license terminate for

any reason, it shall be the user’s responsibility to certify in writing to CA that all copies and partial copies of the

Documentation have been returned to CA or destroyed.

EXCEPT AS OTHERWISE STATED IN THE APPLICABLE LICENSE AGREEMENT, TO THE EXTENT PERMITTED BY

APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION ―AS IS‖ WITHOUT WARRANTY OF ANY KIND, INCLUDING

WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE

OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO THE END USER OR ANY THIRD PARTY FOR ANY LOSS

OR DAMAGE, DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT

LIMITATION, LOST PROFITS, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY

ADVISED OF SUCH LOSS OR DAMAGE.

The use of any product referenced in the Documentation is governed by the end user’s applicable license

agreement.

The manufacturer of this Documentation is CA.

Provided with ―Restricted Rights.‖ Use, duplication or disclosure by the United States Government is subject to the

restrictions set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section

252.227-7014(b)(3), as applicable, or their successors.

All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.

Copyright © 2009 CA. All rights reserved.

CA Product References

This document references the following CA products:

■ CA SPECTRUM® (SPECTRUM)

■ CA SPECTRUM® Virtual Host Manager (Virtual Host Manager)

■ CA Virtual Performance Management AIM for VMware vCenter (CA VPM

AIM)

Contact CA

Contact Technical Support

For your convenience, CA provides one site where you can access the

information you need for your Home Office, Small Business, and Enterprise CA

products. At http://ca.com/support, you can access the following:

■ Online and telephone contact information for technical assistance and

customer services

■ Information about user communities and forums

■ Product and documentation downloads

■ CA Support policies and guidelines

■ Other helpful resources appropriate for your product

Provide Feedback

If you have comments or questions about CA product documentation, you can

send a message to [email protected].

If you would like to provide feedback about CA product documentation,

complete our short customer survey, which is also available on the CA Support

website, found at http://ca.com/docs.

http://www.ca.com/support

mailto:[email protected]

http://www.ca.com/docs



Contents 5

Contents

Chapter 1: Virtual Host Manager 7

About Virtual Host Manager .................................................................... 7

Who Should Use Virtual Host Manager........................................................... 7

Virtual Technologies Supported by Virtual Host Manager .......................................... 8

System Requirements .......................................................................... 8

How Virtual Host Manager Works ............................................................... 8

Chapter 2: Getting Started 11

How to Install Virtual Host Manager ............................................................ 11

How to Discover and Model Your Virtual Environment ........................................... 12

Run SPECTRUM Discovery ................................................................. 12

Upgrade the SystemEDGE Model ........................................................... 14

How vCenter Discovery Works ............................................................. 15

Add SNMP Capabilities to VHM Models ...................................................... 16

Move an ESX Host to a New vCenter ....................................................... 17

How to Configure Virtual Host Manager ......................................................... 18

Configure the CA VPM AIM ................................................................. 19

Configure and Monitor Resource Status ..................................................... 22

Manage Device Models for Devices Deleted from vCenter .................................... 23

Configure Maintenance Mode for New Virtual Machines ...................................... 24

Chapter 3: Viewing Your Virtual Environment 27

Virtual Host Manager in SPECTRUM OneClick ................................................... 27

Workstation Icons in Virtual Host Manager ...................................................... 31

Viewing Your VMware Virtual Network in SPECTRUM ............................................ 31

How the Virtual Host Manager Data is Updated ................................................. 35

Deleted Models ........................................................................... 36

Custom Views for Virtual Entity Types .......................................................... 37

Searching .................................................................................... 38

Locater Tab for Virtual Host Manager ....................................................... 39

Status Monitoring Options ..................................................................... 40

Chapter 4: Alarms and Fault Isolation in Virtual Host Manager 43

Virtual Host Manager Alarms .................................................................. 43

How SPECTRUM Forwards Traps from SystemEDGE ......................................... 44

Traps Supported in Virtual Host Manager ................................................... 45

6 Solution Guide (5192)

Fault Management for Virtual Networks ........................................................ 49

How Fault Isolation Works when Device Contact is Lost ...................................... 50

How Fault Isolation Works when Proxy Management is Lost .................................. 53

Determining Virtual Machines Affected by ESX Outages .......................................... 55

Appendix A: Troubleshooting 57

Duplicate Models Created After SNMP and vCenter Discovery .................................... 57

Glossary 59

Index 61


Chapter 1: Virtual Host Manager

This section contains the following topics:

About Virtual Host Manager (see page 7)

Who Should Use Virtual Host Manager (see page 7)

Virtual Technologies Supported by Virtual Host Manager (see page 8)

System Requirements (see page 8)

How Virtual Host Manager Works (see page 8)

About Virtual Host Manager

Virtual Host Manager is an application provided with SPECTRUM that models

and monitors the health of your virtual network environment. Access to Virtual

Host Manager is provided in the SPECTRUM OneClick interface. With this

application, you can view your complete network topology within SPECTRUM,

including the relationships between your physical and virtual components.

This broad view helps you better monitor the health of your network

infrastructure, preventing service interruptions to your virtual machines.

Monitoring your virtual environment, such as monitoring resource utilization on

hosts and virtual machines, can help you identify potential performance issues.

Virtual Host Manager also helps you pinpoint and effectively troubleshoot

problems within your entire network by applying SPECTRUM fault isolation

techniques to virtual environments.

A key challenge when monitoring your virtual environment is keeping the data

updated. Virtual environments are designed to optimize resource allocation as

needed, so the relationship between the virtual and physical networks can

change rapidly. Virtual Host Manager keeps up with these changes and

continuously monitors the current state of your virtual network to detect any

changes.

Who Should Use Virtual Host Manager

Multiple vendors provide virtual technology applications. Virtual Host Manager

is intended for SPECTRUM users who create and manage virtual machines and

want to monitor the performance of both their physical and virtual network

entities.

Virtual Technologies Supported by Virtual Host Manager


Virtual Technologies Supported by Virtual Host Manager

Virtual Host Manager can model and manage virtual networks created with

VMware vCenter.

System Requirements

Virtual Host Manager is an application that works within SPECTRUM, if all

required components are available and configured properly. Virtual Host

Manager requires the following components:

■ SPECTRUM r9.1

■ VMware vCenter Server release 2.x

■ CA SystemEDGE agent r4.3 PB0

■ CA VPM AIM rPL0

More information:

How to Install Virtual Host Manager (see page 11)

How Virtual Host Manager Works

The purpose of Virtual Host Manager is to seamlessly monitor your virtual

network entities alongside your physical network entities within SPECTRUM,

giving you a full view of your network and letting you troubleshoot networking

issues for both. Although your virtual network entities behave like physical

components, the process for monitoring those entities differs from the general

SPECTRUM monitoring process. Understanding how this process works can

help you locate and resolve networking issues related to your virtual network.



Traditionally, SPECTRUM contacts an SNMP agent on your network machines to

gather information. Some ESX hosts and virtual machines (VMs) do not have

an SNMP agent installed, making it difficult to gather information needed for

monitoring status and pinpointing issues using fault isolation. Therefore,

Virtual Host Manager uses the CA VPM AIM module of the SystemEDGE agent

to gather the needed information. This module is loaded on the VMware

vCenter (VC) server, as shown in the following diagram:



The process to gather information about your virtual network machines is as

follows:

1. The VMware vCenter application manages the ESX hosts in your virtual

network, storing detailed data about each ESX host and their virtual

machines.

2. The SystemEDGE agent resides on the vCenter server, and this agent has

the CA VPM AIM loaded. With that module loaded, SystemEDGE

communicates with vCenter to gather the details about your virtual

network.

3. Periodically, SPECTRUM retrieves this information from SystemEDGE and

uses it to model and monitor your virtual machines in OneClick.

Because Virtual Host Manager communicates with vCenter, SPECTRUM is

aware of spontaneous network configuration changes, such as those caused by

VMware vMotion, HA technology, or a DRS scenario. Changes caused by these

events are quickly reflected in OneClick and factored into the root cause

analysis.

More information:

How the Virtual Host Manager Data is Updated (see page 35)


Chapter 2: Getting Started

This section describes the installation, configuration, and modeling process for

Virtual Host Manager. These tasks are typically performed only once per

installation by the administrator.


How to Install Virtual Host Manager (see page 11)

How to Discover and Model Your Virtual Environment (see page 12)

How to Configure Virtual Host Manager (see page 18)

How to Install Virtual Host Manager

Virtual Host Manager is included in your SPECTRUM extraction key. When you

install SPECTRUM, the Virtual Host Manager components are automatically

installed and available for use. However, Virtual Host Manager is not operable

until you also install and configure the SystemEDGE CA VPM AIM on your

VMware vCenter servers. To manage your virtual devices properly, SPECTRUM

must be able to contact the SystemEDGE agent (which has the CA VPM AIM

installed), and the AIM must be able to communicate with vCenter.

To install Virtual Host Manager properly, the administrator must complete

these tasks:

1. Install the SystemEDGE agent on each vCenter host and load the CA VPM

AIM.

Note: For installation instructions and more information about the CA VPM

AIM, see the CA Virtual Performance Management AIM for VMware

VirtualCenter Product Guide.

2. Install SPECTRUM with Virtual Host Manager included.

Note: For specific installation instructions, see the Installation Guide

(5136).

You can now model your virtual network in SPECTRUM.

More information:

System Requirements (see page 8)


How to Discover and Model Your Virtual Environment



To monitor your virtual environment, you must discover and model your virtual

entities—datacenters, resource pools, clusters, ESX hosts, and virtual

machines. Modeling these entities in SPECTRUM lets you view your complete

network topology in one tool, showing the relationships between your physical

and virtual components.

The main steps for modeling your virtual environment are as follows:

1. Run a standard SPECTRUM Discovery (see page 12).

The purpose of this Discovery is to make sure the upstream routers and

switches, SNMP-capable ESX hosts and virtual machines, and vCenter

servers are modeled before vCenter Discovery runs. When modeling these

entities, be sure that your modeling options are set correctly to support

Virtual Host Manager.

2. Upgrade the SystemEDGE model (see page 14).

This step is required only if your SystemEDGE agent on the vCenter server

was modeled in a release before SPECTRUM r9.1.

3. Let vCenter Discovery run (see page 15).

When you model the SystemEDGE agent with CA VPM AIM on the vCenter

server, vCenter Discovery begins automatically. Each of these vCenter

Server models has its own vCenter Discovery process. The purpose of

vCenter Discovery is to find the virtual entities managed by vCenter,

model them if they do not exist, and place them in the Virtual Host

Manager view of the Navigation panel.

More information:


Add SNMP Capabilities to VHM Models (see page 16)

Move an ESX Host to a New vCenter (see page 17)

Run SPECTRUM Discovery

To prepare for vCenter Discovery, you must run the standard SPECTRUM

Discovery first. The purpose of this Discovery is to make sure the upstream

routers and switches, SNMP-capable ESX hosts and virtual machines, and

vCenter servers are modeled.

Note: Modeling the SNMP-capable ESX hosts and virtual machines is

recommended, but optional. Modeling them before you model the SystemEDGE

agent with CA VPM AIM provides a more feature-rich device model.



These models must exist in SPECTRUM before running vCenter Discovery,

because SPECTRUM discovers and models the connections from your virtual

entity models to these physical entity models. Modeling these connections

helps to ensure that your virtual entities appear in the Universe topology

correctly.

Note: This procedure is performed by an administrator only.

To run Discovery before modeling your virtual network

1. Open the Discovery console.

Note: Before modeling, be sure that you know the correct community

strings, IP addresses, and port numbers for any SNMP agents that run on a

nonstandard port.

2. Click the "Creates a new configuration" button in the Navigation panel.

3. Configure your options to support virtual network modeling, as follows:

a. Click the Modeling Options button in the Modeling Options group.

The Modeling Configuration dialog opens.

b. Click the Protocol Options button.

The Protocol Options dialog opens.

c. Select the ARP Tables for Pingables option, and click OK.

The Modeling Configuration dialog opens.

d. Select the Create "802.3" (Fanout) option and click OK.

e. Click the Advanced Options button in the Advanced Options group.

The Advanced Options dialog opens.

f. (Optional) Add your nonstandard SNMP ports (such as, the

SystemEDGE agent port), and click OK.

4. Enter individual IP addresses or the beginning and ending IP addresses in

the IP Boundary List fields and click Add.

Important! Be sure the range of IP addresses includes vCenter servers

with SystemEDGE and CA VPM AIM installed, interconnecting switches and

routers, and the SNMP-capable ESX hosts and virtual machines for which

you want to create SNMP models. SPECTRUM cannot build the relationships

between your physical and virtual entities in the Universe topology if these

models do not exist before running vCenter Discovery.



5. Enter any additional values needed in the Discovery console to model your

network and click the Discover button.

The following models are created and added to your network topology in

SPECTRUM:

■ vCenter servers and the switches and routers that connect them to

your network—information about your virtual environment comes from

the vCenter server, so these vCenter Server models must exist before

vCenter Discovery can begin.

■ ESX hosts and virtual machines—(Optional) If you decide not to model

these entities with SPECTRUM Discovery, vCenter Discovery creates

them as VHM models (see definition on page 60).

Note: Instead of using Discovery, you can manually model your virtual

network by IP address. Always model in the correct order: connecting

routers and switches, SNMP-capable ESX hosts and virtual machines, then

your vCenter servers with the SystemEDGE agent and CA VPM AIM

installed. Modeling in the correct order helps ensure that the relationships

between these entities are built correctly in the topology. For more

information about how to perform a Discovery or manually discover by IP

address, see the Modeling Your IT Infrastructure Administrator Guide

(5167).

More information:




Upgrade the SystemEDGE Model

The SystemEDGE agent could have been modeled in SPECTRUM before

installing Virtual Host Manager or before the CA VPM AIM was loaded on the

agent. In this case, the existing SystemEDGE model is not compatible with

Virtual Host Manager. You must upgrade the model so Virtual Host Manager

can access the CA VPM AIM capabilities in SystemEDGE. This procedure is not

required if the SystemEDGE agent with CA VPM AIM loaded is installed on the

vCenter server, and this server is modeled after installing SPECTRUM r9.1.

To upgrade the SystemEDGE model, send a reconfigure model action to

SystemEDGE.

The SystemEDGE model is upgraded to support the CA VPM AIM.

Note: For instructions to send a reconfigure model action to SystemEDGE, see

the Modeling Your IT Infrastructure Administrator Guide (5167).



More information:




How vCenter Discovery Works

vCenter Discovery is a specialized discovery process that gathers detailed

information about your virtual network entities. The purpose of vCenter

Discovery is to obtain the virtual entities managed by vCenter, model them if

they do not exist in SPECTRUM, and place them in the Virtual Host Manager

view of the Navigation panel. A key benefit of vCenter Discovery is that it runs

automatically in the background, continually keeping your virtual network data

updated in SPECTRUM. Understanding how vCenter Discovery works reinforces

the importance of installing and modeling the various components of Virtual

Host Manager properly.

The vCenter Discovery process works as follows:

1. Immediately after the SystemEDGE agent and CA VPM AIM are installed

correctly, the CA VPM AIM communicates with vCenter to gather

information about the virtual entities it manages. This information is stored

by the CA VPM AIM.

Important! The SystemEDGE agent must be installed on the vCenter

server with the CA VPM AIM loaded. If this installation is not configured

correctly, vCenter Discovery cannot run, because SystemEDGE, vCenter,

and SPECTRUM must be able to communicate.

2. During SPECTRUM Discovery, SPECTRUM creates a vCenter Server model

for each server referenced in step 1 and enables SPECTRUM intelligence to

handle communication between SPECTRUM and the SystemEDGE agent.

3. SPECTRUM intelligence polls the CA VPM AIM to gather the vCenter

information stored in step 1.

4. SPECTRUM uses this information to update modeling in the SPECTRUM

Topology tab and the Virtual Host Manager hierarchy in the Navigation

panel, as follows:

a. VHM models (see definition on page 60) are created for the

datacenters, clusters, and resource pools.

b. Previously existing ESX host and virtual machine models are promoted

to VHM models.



c. VHM models are created for the ESX hosts and virtual machines that

do not previously exist in SPECTRUM.

d. All models for your virtual network are added to the Virtual Host

Manager portion of the Navigation panel.

5. vCenter Discovery automatically repeats this process at each regularly

scheduled vCenter polling interval.

More information:




Add SNMP Capabilities to VHM Models

Although SNMP provides enriched device monitoring, such as process or file

monitoring, SNMP agents can be costly and time-consuming to deploy

throughout an enterprise. Fortunately, Virtual Host Manager creates ESX hosts

and virtual machines as VHM models regardless of whether they have an SNMP

agent. However, you can upgrade these VHM models with SNMP capabilities at

any time.

To add SNMP capabilities to a VHM model

1. Deploy or enable an SNMP agent on the device, if needed.

2. Model the device again using one of the following methods:

■ SPECTRUM Discovery

■ Model individual devices by IP

When the new SNMP-capable model is created, SPECTRUM removes the

previous model from Virtual Host Manager and deletes it. Upon the next

vCenter polling cycle, SPECTRUM adds the SNMP-capable model to Virtual

Host Manager in the Navigation panel.

Important! When your previous models are destroyed, all notes or other

customization applied to those models are lost.

More information:

How to Discover and Model Your Virtual Environment (see page 12)

Deleted Models (see page 36)



Move an ESX Host to a New vCenter

Moving an ESX host from one SPECTRUM managed vCenter to another can

cause problems with modeling. Some possible symptoms of these modeling

problems are as follows:

■ SPECTRUM deletes the models associated with the ESX host and does not

recreate them after the move

■ False proxy lost alarms are created and remain, even though the new

vCenter can contact the ESX host and all hosted virtual machines

If you move your ESX host in exactly the correct order, you can avoid these

problems.

To move an ESX host to a new vCenter server

1. (Optional) Change the Allow Device Model Deletes During vCenter

Discovery option to No (see page 23).

Note: Perform this step only if both the originating and destination

vCenters are modeled in the same SpectroSERVER. Setting this option to

"No" keeps the existing ESX and virtual machine models from being

deleted when they become unmanaged by the first vCenter server.

Therefore, customizations or historical details for the models are preserved

and available after the move.

2. Open VMware and remove the ESX host from management of the first

vCenter server.

3. Wait for Virtual Host Manager in the OneClick Navigation panel to reflect

the changes.

4. Open VMware and add the ESX host into the destination vCenter server.

Note: Virtual Host Manager is not DSS (see definition on page 59) aware.

Therefore, when moving the ESX host to a vCenter server modeled on a

different SpectroSERVER, a new set of models are created to represent the

ESX host and its hosted virtual machines.

5. (Optional) Change the Allow Device Model Deletes During vCenter

Discovery option back to Yes on the originating vCenter server model.

The ESX host is successfully moved from one vCenter server to a second

vCenter server.

How to Configure Virtual Host Manager



After Virtual Host Manager is installed and your virtual network is modeled,

you can configure Virtual Host Manager for use. Configuring your preferences

helps ensure that Virtual Host Manager handles your virtual device models

correctly and monitors only the information that is important to you.

To configure your installation of Virtual Host Manager, perform the following

procedures after you discover and model your virtual network:

■ Configure the CA VPM AIM options (see page 19)—These options let you

select settings for the SystemEDGE CA VPM AIM, such as the CA VPM AIM

polling interval and various traps.

■ Configure threshold values and other status monitoring options (see

page 22)—These options determine which information SPECTRUM monitors

for you and how it manages the various events that occur in your virtual

network.

■ Set the Allow Device Model Deletes During vCenter Discovery option (see

page 23)—This option controls how SPECTRUM handles the virtual device

models when virtual machines or ESX hosts are removed from vCenter.

■ Set the Enable Maintenance Mode on New Virtual Machines option (see

page 24)—This option lets you decide which newly discovered virtual

machines to place into maintenance mode until you are ready for

SPECTRUM to manage them.

More information:




Configure the CA VPM AIM

The CA VPM AIM communicates with vCenter to manage and collect

information about your virtual network. In Virtual Host Manager, you can

configure the AIM to determine how it handles polling, traps, and events. The

CA VPM AIM configuration settings let you decide the right balance of

information to gather against the amount of resources it takes to do so.

To configure the CA VPM AIM in Virtual Host Manager

1. Open Virtual Host Manager in the OneClick Navigation panel (see page 27).

The main details page opens in the Contents panel for the selected Virtual

Host Manager.

2. Locate and click your vCenter server on the Explorer tab in the Navigation

panel.

The tabs in the Contents panel are populated with details about your

vCenter server.

3. Click the Information tab.

4. Expand the VMware vCenter Server, VPM AIM, Configuration view.

5. Click Set to change the settings for the following fields, as needed:

Poll Interval (Seconds)

Specifies the time interval (in seconds) when the CA VPM AIM polls and

caches status and modeling information from the vCenter server. This

polling retrieves status and modeling updates, such as the virtual

machine powered down status, ESX host disconnected, new datacenter

available, new ESX host, new virtual machine, and more.

Default: 120

Limits: Numbers greater than or equal to 30

Note: For best results, we recommend that you set this interval no

larger than the SPECTRUM poll cycle interval.

VC Event Poll (Seconds)

Specifies the time interval (in seconds) when the CA VPM AIM polls and

caches event information from the vCenter server. This polling interval

affects the polling of the vCenter event queue.

Default: 120

Limits: Numbers greater than or equal to 120



VC Event Enable

Determines how Virtual Host Manager handles events collected from

the vCenter server and from the CA VPM AIM. The options are as

follows:

Disable

Specifies that no events are collected.

Collect

Specifies that events are gathered, but no traps are sent for those

events that have traps.

Collect and trap

Specifies that the events are gathered and traps are sent.

Default: disable

VC Event Monitor Info

Determines whether vCenter information events are collected. The

options are Enable and Disable.

Default: disable

VC Event Monitor User

Determines whether vCenter user events are collected. The options are

Enable and Disable.

Default: disable

VC Event Monitor Error

Determines whether vCenter error events are collected. The options

are Enable and Disable.

Default: disable

VC Event Monitor Warning

Determines whether vCenter warning events are collected. The options

are Enable and Disable.

Default: disable

Trap Enable Mask

Determines which class of traps are sent by the CA VPM AIM. The

value entered in this field determines the class. The values are as

follows:

0

Sends no traps.

1

Sends detected vCenter change traps.



2

Sends detected AIM state change traps.

3

Sends detected vCenter change traps and detected AIM state

change traps.

4

Sends AIM configuration change traps only.

5

Sends AIM configuration change and detected vCenter change

traps.

6

Sends AIM configuration change traps and detected AIM state

change traps.

7

(Default) Sends all traps.

Default: 7

Limits: 0-7

Log Level

Specifies the level of information written to the CA VPM AIM log file.

The levels are cumulative (for example, log level 4 writes all messages

at levels 0 through 4). The log levels are as follows:

■ 0: Fatal

■ 1: Critical

■ 2: Warning

■ 3: Info

■ 4: Debug

■ 5: Debug Low

■ 6: Debug Lower

■ 7: Debug Lowest

Default: 2

Note: Specifying a debug level greater than 4 is discouraged.

Your CA VPM AIM is configured with your selections.



More information:


Configure and Monitor Resource Status

When analyzing the performance of your virtual environment, you can monitor

the status of your virtual resources. For example, you can view the total

physical memory, used physical memory, percent of free space on a datastore,

and more. Also, you can set monitoring options, such as enabling alerts and

setting threshold values for traps. Configuring and viewing this information can

help you optimize your virtual network performance and troubleshoot alarms

that occur within your virtual environment.

Note: Traps are set on and managed by the CA VPM AIM, but you can

configure these threshold values from the OneClick views. A read/write

community string is required to change any threshold values or settings.

To view or configure resource status options and information for

virtual devices



Host Manager.

2. Locate and click the virtual device on the Explorer tab in the Navigation

panel.

The device details display in the Contents panel.


Multiple information groups are available for viewing. Generally, the

information group at the bottom of the tab includes the resource allocation

and utilization information for the selected model. For example, a

datacenter model displays an information group named "Datacenter

Information" that includes details for the specific datacenter model you

selected in the Navigation panel.



4. Expand the appropriate information group.

All available resource status details and monitoring options for the selected

device model are displayed.

Note: The vCenter model provides combined information for all virtual

devices managed by the vCenter server. That is, selecting the vCenter

model in the Navigation panel displays information about the selected

vCenter server and combined information about all ESX hosts, virtual

machines, virtual switches, NICs, datastores, and more. This information is

the same data displayed on the Information tab for each individual entity

model. The combined view in the vCenter model can provide a good

overview about all the virtual entities it manages.

More information:

Custom Views for Virtual Entity Types (see page 37)

Virtual Host Manager Alarms (see page 43)

Status Monitoring Options (see page 40)

Manage Device Models for Devices Deleted from vCenter

By the nature of virtual networks, the devices and relationships between them

can change frequently. Maintaining accurate and timely data about your virtual

network in SPECTRUM is challenging. For example, when an ESX host is

removed or a virtual machine is deleted in vCenter, SPECTRUM knows to

remove the corresponding device model from Virtual Host Manager in the

Navigation panel. However, should SPECTRUM keep or delete the model in

topology? The Allow Device Model Deletes During vCenter Discovery option lets

you select your preference. When enabled, this option keeps SPECTRUM

models of ESX hosts and virtual machines synchronized with the ones

managed by vCenter. It also helps to keep your SPECTRUM topology from

getting cluttered with obsolete device models until you manually remove them.

Important! If models are automatically deleted, all notes or other

customizations on those models are lost. You can choose to disable this option

if your models are likely to be recreated in vCenter later.

To manage device models for devices deleted from vCenter



Host Manager.


panel.


vCenter server.




4. Expand the VMware vCenter Server, vCenter Discovery view.

5. Click Set in the Allow Device Model Deletes During vCenter Discovery field

and select Yes or No from the drop-down list.

Note: The default setting is Yes.

Your setting is saved, and device models are handled accordingly after the

device is deleted from vCenter.

More information:


Deleted Models (see page 36)


Traps Supported in Virtual Host Manager (see page 45)

Configure Maintenance Mode for New Virtual Machines

Virtual Host Manager automatically models all virtual machines managed by

vCenter. SPECTRUM attempts to manage all models discovered, but some new

virtual machines are not ready for SPECTRUM management when they are

initially modeled. For example, powered down virtual machines cause

Spectrum to generate a Contact Lost alarm. To prevent undesired alarms on

new virtual machine models, you can decide which new virtual machine models

are immediately placed into maintenance mode. Later, you can manually

disable maintenance mode when you are ready for SPECTRUM to manage

these devices.

To configure the maintenance mode option for new virtual machines



Host Manager.


panel.


vCenter server.




4. Expand the VMware vCenter Server, vCenter Discovery view.

5. Click Set in the Maintenance Mode for New Virtual Machines field and

select one of the following options:

Place only Powered down VMs in Maintenance Mode

(Default) Applies maintenance mode to only powered down or

suspended virtual machine models upon initial vCenter Discovery.

Place all VMs in Maintenance Mode

Applies maintenance mode to all new virtual machine models upon

initial vCenter Discovery.

Your setting is saved and new virtual machines modeled in Virtual Host

Manager are placed into maintenance mode per your selection.

More information:




Chapter 3: Viewing Your Virtual

Environment

This section describes the basic concepts for viewing your virtual environment

and the alarms associated with your virtual infrastructure. Although the basic

steps are no different from the standard SPECTRUM procedures, this section

describes conceptual differences and specific details for virtual technologies

only.


Virtual Host Manager in SPECTRUM OneClick (see page 27)

Workstation Icons in Virtual Host Manager (see page 31)

Viewing Your VMware Virtual Network in SPECTRUM (see page 31)



Searching (see page 38)


Virtual Host Manager in SPECTRUM OneClick

Virtual Host Manager is integrated into the Navigation panel in SPECTRUM

OneClick. Virtual Host Manager provides a hierarchical tree structure that helps

you to visualize the relationships between your virtual environment resources.

This hierarchy also helps you to manage and monitor the performance of your

resources by providing a quick way to view their details and troubleshoot their

alarms.

Virtual Host Manager displays the logical relationships between your virtual

environment resources, as configured in the VMware vCenter application.

Using this information, you can see how resources are shared among your

virtual hosts, which can help you identify opportunities to reorganize and

optimize your virtual environment.



Because Virtual Host Manager is not aware of a DSS environment, it is located

within a landscape hierarchy. The following example shows where Virtual Host

Manager fits into the OneClick Navigation view and illustrates the virtual

environment hierarchy:

[-] SpectroSERVER host

[+] Universe

[-] Virtual Host Manager

[-] VMware

[+] vCenter server 1

[-] vCenter server 2

[-] Datacenter 1

[+] Cluster 1

[-] Cluster 2

[-] Resource Pool 1

[-] Resource Pool A

VM

[-] Resource Pool 2

VM A

VM B

VM C

ESX host A

ESX host B

VM 1

VM 2

ESX host 1

[-] ESX host 2

[+] Resource Pool 3

VM 3

[+] Datacenter 2

[+] Datacenter 3

Virtual Host Manager is the root node for the entire virtual environment

managed by this SpectroSERVER. Selecting this node in the Navigation panel

displays Virtual Host Manager details in the Contents panel on four tabs:

Alarms, List, Events, and Information. From these tabs, you can view details

such as events and alarms related to your virtual environment as a whole.

Directly under Virtual Host Manager, virtual environments are organized within

folders that represents the technology with which they are created. In the

example hierarchy above, the VMware folder contains the portion of the virtual

environment that was created using VMware technology. In this folder, Virtual

Host Manager lists all vCenter servers managed by this SpectroSERVER.



Each vCenter server represents a host that contains the SystemEDGE agent

with CA VPM AIM loaded. The hierarchy under each vCenter server contains

only the portion of the entire virtual environment that it manages. Selecting a

vCenter server in the Navigation panel displays details in the Contents panel

on four tabs: Alarms, List, Events, and Information. From these tabs, you can

view details such as the datacenters or ESX hosts managed by the selected

vCenter application.

Under each vCenter server, the hierarchy represents the logical relationships

between the following virtual entities:

■ Datacenters

A datacenter in VMware represents the primary container of virtual

environment components, such as ESX hosts and clusters. Companies can

create multiple datacenters, each representing distinct organizational units

in their enterprise, such as geographical regions or separate business

functions. Components can interact within datacenters, but interaction

across datacenters is limited. A datacenter can contain clusters or hosts.

Selecting a datacenter in the Navigation panel displays details in the

Contents panel on four tabs: Alarms, List, Events, and Information. From

these tabs, you can view details such as events and alarms related to the

datacenter, a list of clusters contained in the datacenter, and more.

■ Clusters

A cluster is a group of ESX hosts and their associated virtual machines.

When a host is added to a cluster, the host’s resources become part of the

cluster’s resources. The cluster manages the resources of all hosts within

it. Within a cluster, you can have hosts, resource pools, or virtual

machines (VMs).

Selecting a cluster in the Navigation panel displays details in the Contents

panel on four tabs: Alarms, List, Events, and Information. From these tabs,

you can view details such as events and alarms related to the cluster, a list

of ESX hosts and virtual machines contained in the cluster, the DRS and

HA settings, and more.

■ Resource pools

A resource pool can be used to hierarchically partition available CPU and

memory resources of a cluster or standalone host. Resource pools provide

a mechanism to control the aggregate allocation of resources to a set of

virtual machines. A resource pool can contain virtual machines or

additional resource pools.

Selecting a resource pool in the Navigation panel displays details in the


these tabs, you can view details such as overall CPU usage, events and

alarms related to the resource pool, a list of other virtual network objects

contained in the resource pool, and more.



■ ESX hosts

An ESX host is a physical computer that uses ESX Server virtualization

software to run virtual machines. Hosts provide the CPU and memory

resources that virtual machines use and give virtual machines access to

storage and network connectivity. An ESX host can contain resource pools

or virtual machines.

Note: When a host appears within a cluster folder, the virtual machines

associated with the host are not grouped under the host. Instead, they

appear under the cluster folder alongside the host.

Selecting an ESX in the Navigation panel displays details in the Contents

panel on four tabs: Alarms, List, Events, and Information. From these tabs,

you can view details such as total virtual machine memory, CPU state, a

list of virtual machines managed by the ESX, and more.

■ Virtual machines

A virtual machine (VM) is a software computer that, like a physical

computer, runs an operating system and applications. Because every

virtual machine is an isolated computing environment, they are often used

as desktop or workstation environments, as testing environments, or to

consolidate server applications. A virtual machine is always a leaf node on

the Virtual Host Manager hierarchy tree.

Selecting a virtual machine in the Navigation panel displays details in the


these tabs, you can view details such as the power status, memory usage,

related events and alarms, and more.

Note: The vCenter server, ESX host, and virtual machine models created for

your virtual environment are also integrated into the Universe topology view.

The topology shows how these virtual entities are connected to your physical

network entities. For more information about using the OneClick interface, see

the OneClick Console User Guide (5130).

More information:

Searching (see page 38)


Workstation Icons in Virtual Host Manager


Workstation Icons in Virtual Host Manager

To distinguish physical and virtual entities, the virtual device icons have a

halo-like appearance around the outer edge. For example, a virtual machine

model icon displays a halo around the perimeter, as follows:

Viewing Your VMware Virtual Network in SPECTRUM

After configuring Virtual Host Manager and modeling your virtual network,

SPECTRUM manages both your physical and virtual network entities, displaying

the relationship between them in the OneClick interface. Virtual entities are

distinguished from physical models because they have a halo-like appearance

around the icon. To view the virtual network you create in VMware vCenter,

you have the following options in SPECTRUM:

■ Virtual Host Manager in the Navigation panel—This view displays the

logical relationships between your virtual network entities, as configured in

the VMware vCenter application.

■ Universe topology view—This view provides an L2 view of the network,

showing how ESX hosts and virtual machines are connected to the

network. You can use this view to resolve alarms involving these virtual

network models.



Understanding how the vCenter information appears in SPECTRUM is the key

to deciding which view is best for viewing your virtual entities. Virtual Host

Manager in the Navigation panel mimics the information presented in vCenter.

Virtual entities are grouped under the datacenters, resource pools, and hosts

to which they belong. Custom folders are the only organization items from

vCenter that are not represented in SPECTRUM. The following graphic shows

how information in vCenter looks in SPECTRUM OneClick:

When Virtual Host Manager discovered the virtual network in this example, it

found the "cas" vCenter server and added it to the Virtual Host Manager view

in the OneClick Navigation panel. Then, Virtual Host Manager added the

remaining virtual entities that the server manages:

■ Datacenter: Operations

■ Cluster: Online Transactions

■ ESX host: esx-test



■ Resource pools: Root Pool, Management & Performance, and Production

■ Virtual machines: fillmore, grant, adams, and madison

The topology view of the same information shows the L2 connectivity between

these virtual entities and the physical entities to which they are connected. For

example, the following view of networking information in vCenter shows that

the "esx-test" ESX host has two NICs (vmnic0 and vmnic1). The virtual entities

on this server are connected to the NICs through two virtual switches—the ESX

service console uses vSwitch0 and the virtual machines use vSwitch1.

Note: The following example is taken from the VMware vCenter application

and is not available from within the SPECTRUM interface.



This networking information from vCenter appears in the Universe topology as

follows:

To understand the topology view, you need to know the following:

■ SPECTRUM does not create models for virtual switches.

Virtual switches are represented in the Universe topology as fanouts. In

this example, the "Rpt_Segment" fanout represents the vSwitch1

connection between the virtual machines and a physical switch

("sysName") in your network. The "esx-test" ESX host is also connected to

the same physical switch—this connection represents the vSwitch0

connection. However, no fanout is required to represent this connection. A

fanout is necessary only when the upstream switch detects multiple MAC

addresses from the virtual switch, such as the MAC addresses for the

multiple virtual machines. Although two MAC addresses are sent through

vSwitch0, only one of these MAC addresses (that is, the ESX address) is

modeled in SPECTRUM. So, this connection appears in the topology view as

a direct connection between the ESX and upstream switch.

How the Virtual Host Manager Data is Updated


■ Virtual machines are not directly connected to the ESX.

When Virtual Host Manager models the ESX host, it is actually modeling

the ―Service Console‖ of the host, as seen in the example vCenter

networking information. The Service Console connects to a virtual switch

like the managed virtual machines—these virtual machines are not directly

connected to the Service Console. Instead, they are connected to the

vSwitch1 virtual switch, which is modeled in SPECTRUM as the

"Rpt_Segment" fanout. The topology view represents the networking

relationships established in vCenter, which explains why SPECTRUM does

not show the virtual machine models connected to the ESX host model.


During your initial vCenter Discovery, SPECTRUM populates Virtual Host

Manager hierarchy in the Navigation panel with your virtual device models.

After SPECTRUM builds this initial hierarchy, your virtual network configuration

can change frequently, and Virtual Host Manager must continually work to

keep this information accurate in SPECTRUM. For example, the following

events can change your virtual network configuration:

■ Creating or deleting datacenters, clusters, resource pools, ESX hosts, or

virtual machines in the vCenter application

■ HA or DRS settings in VMware, which can cause virtual machines to move

spontaneously to a new ESX host

■ Manually migrating a virtual machine from one ESX host to another



To keep your information accurate, Virtual Host Manager detects these

changes by polling the CA VPM AIM. Therefore, your virtual network

configuration is updated in SPECTRUM at each polling cycle. SPECTRUM also

receives traps from the AIM and generates the corresponding events. By

reviewing the event log, you can find out when configuration changes occur,

such as when a virtual device is migrated because of HA or DRS. When it

detects a change in your virtual network configuration, SPECTRUM performs

the following tasks:

■ Updates the placement of your virtual device models in the Virtual Host

Manager hierarchy of the Navigation panel

■ Automatically rediscovers connections to the affected virtual models and

places them in the same LAN container as the upstream switch

Important! To reestablish connections to your virtual models correctly, all

interconnecting routers and switches in your physical network must be

modeled. If these models do not exist before connections to your virtual

devices are rediscovered, SPECTRUM cannot resolve those connections and

display the information correctly in the Universe topology view—these

virtual devices appear as orphaned models. The ESX hosts and virtual

machines are placed in the same LAN container as the SystemEDGE

model.

More information:

How Virtual Host Manager Works (see page 8)

Manage Device Models for Devices Deleted from vCenter (see page 23)

Configure and Monitor Resource Status (see page 22)


Deleted Models

Models can be deleted from OneClick at any time for various reasons, and

deleting these models can have various implications. In Virtual Host Manager,

models can be automatically deleted for the following reasons:

■ Virtual entity no longer exists in VMware vCenter—As datacenters,

resource pools, clusters, ESX hosts, and virtual machines are deleted in

VMware, those models are also deleted from Virtual Host Manager.

Note: Although the default setting is to delete the models, you can

configure Virtual Host Manager to leave the ESX and virtual machine

models in the OneClick topology, even if they are removed from Virtual

Host Manager.

■ Upgraded models exist—In some cases, an ESX host or virtual machine

is first modeled for Virtual Host Manager without SNMP capabilities. If

SNMP capabilities are later added to a VHM model (see definition on page

60), the previous model is deleted and replaced with the new

SNMP-capable model.

Custom Views for Virtual Entity Types


More information:

Manage Device Models for Devices Deleted from vCenter (see page 23)


Custom Views for Virtual Entity Types

Your Virtual Host Manager models collectively provide information about your

virtual environment. Individually, each model provides unique information or

configuration settings, depending on the virtual entity type it represents. This

custom view appears on the Information tab in the Contents panel. These

views can contain real-time data, such as disk space available or memory

utilization, and provide access to threshold settings. For example, the custom

view for a cluster is the "Cluster Information" view, as shown:

Searching


Note: The vCenter model provides combined information for all virtual devices

managed by the vCenter server. That is, selecting the vCenter model in the

Navigation panel displays information about the selected vCenter server and

combined information about all ESX hosts, virtual machines, virtual switches,

NICs, datastores, and more. This information is the same data displayed on

the Information tab for each individual entity model. The combined view in the

vCenter model can provide a good overview about all the virtual entities it

manages.

More information:



Searching

Virtual Host Manager does not provide a virtual-only topology view, so

SPECTRUM provides a collection of searches designed specifically for your

virtual network. Using these searches can help you locate details you can use

to monitor the performance of your virtual environment. Searches can locate

specific virtual components, such as locating all ESX host servers within a

single datacenter. These types of searches can help you investigate

information related to a specific branch office. For example, you can use

details associated with that office in your searches, such as a specific cluster or

resource pool.

The search options are grouped under the Virtual Host Management folder on

the Locater tab, as shown:

Searching


For example, if you know the name of a specific ESX host, you can search for

all virtual machines that it manages. Creating this list of virtual machines can

be useful when checking the status of a group of virtual machines. Or, you can

use the list to determine which machines require management changes in

VMware, such as moving the virtual machines to a different ESX or placing

them in maintenance mode.

More information:


Locater Tab for Virtual Host Manager

In addition to viewing details about your virtual environment on the Explorer

tab, you can also use the Locater tab to run preconfigured Virtual Host

Manager searches. These detailed searches can help you investigate

information related to virtual entities only, such as a specific resource pool or

ESX.

Note: Although Virtual Host Manager is not DSS (see definition on page 59)

aware, these preconfigured searches let you select multiple landscapes to

search in the search parameters.

The Locater tab in the Navigation panel includes the following searches for

Virtual Host Manager information:

All Clusters

Locates all clusters that have been modeled in the SPECTRUM database for

the virtual network.

All Datacenters

Locates all datacenters that have been modeled in the SPECTRUM

database for your virtual network.

All Hosts

Locates all ESX host servers that have been modeled in the SPECTRUM


All Resource Pools

Locates all resource pools that have been modeled in the SPECTRUM


All Virtual Center Hosts

Locates all VMware vCenter host servers that have been modeled in the

SPECTRUM database for your virtual network.

Status Monitoring Options


All Virtual Machines

Locates all virtual machines that have been modeled in the SPECTRUM


Hosts

Locates ESX host servers in the SPECTRUM database, limited to only the

ESX hosts managed by the containers specified in one of the following

searches:

■ By Cluster Name

■ By Datacenter Name

Virtual Machines

Locates virtual machines in the SPECTRUM database, limited to only the

virtual machines managed by the containers specified in one of the

following searches:

■ By Cluster Name

■ By Datacenter Name

■ By Host Name

■ By Resource Pool Name


SPECTRUM provides a wide range of options for monitoring the state of your

virtual network resources. The status information available for a resource

varies, depending on the type of virtual entity you are monitoring. Also, your

ability to configure a status option depends on its type. For example, some

status options are read-only, but others let you configure threshold values,

enable behaviors, or select an alarm severity. Providing this range of options

and levels of customization, SPECTRUM lets you decide how to best monitor

the performance of your virtual network.

Status fields are located in the OneClick views. All status information for a

given virtual environment is available on the vCenter server model in a tabular

format. Also, each virtual entity type that has a unique model in SPECTRUM

provides a subset of the same status information for easy viewing.

Status-related settings, including the alert type, monitor, and thresholds, can

be set from either view location.



The following tables outline the type of status information available for each

virtual entity type. The View Location column describes where the

corresponding status fields are located in OneClick. For example, SPECTRUM

lets you monitor "memory" information for your resource pool models, and the

corresponding status fields are available from the Resource Pool and vCenter

views on the Information tab in OneClick. To explore the exact status options

available for each status information type, locate the view in OneClick.

Datacenter

Status Information Type View Location

Overall Datacenter and vCenter

Resource Pool


Overall

Resource Pool and vCenter

CPU

Resource Pool and vCenter

Memory Resource Pool and vCenter

Virtual Machine


Percent ready

Virtual Machine and vCenter

CPU Virtual Machine and vCenter

Memory Virtual Machine and vCenter

Heartbeat Virtual Machine and vCenter

Power Virtual Machine and vCenter

OS state Virtual Machine and vCenter

Connected Virtual Machine and vCenter

VMware tools

Virtual Machine and vCenter

Virtual NICs vCenter only

ESX Host


CPU

ESX Host and vCenter

Memory ESX Host and vCenter




Sensor

■ CPU

■ Memory

■ Fan

■ Temperature

■ Voltage

■ Power

vCenter only

Physical NICs vCenter only

Datastores


Free space

vCenter only

Accessibility vCenter only

vCenter


Overall

vCenter

CPU

vCenter

Memory vCenter

More information:





Chapter 4: Alarms and Fault Isolation in

Virtual Host Manager

This section describes the traps used by Virtual Host Manager and the resulting

alarms. This section also explains how Virtual Host Manager fault isolation

differs from basic SPECTRUM fault isolation.



Fault Management for Virtual Networks (see page 49)

Determining Virtual Machines Affected by ESX Outages (see page 55)

Virtual Host Manager Alarms

To alert you to problems within your virtual network, SPECTRUM generates

alarms. Alarms are created in two ways:

■ Traps sent from the SystemEDGE agent

■ Polling

The only alarms generated from polling are the powered down/suspended and

proxy lost/unavailable alarms. However, several traps can generate alarms on

your virtual devices. SPECTRUM supports all traps sent by the CA VPM AIM

from the SystemEDGE agent. To get the greatest value from these traps when

monitoring your devices, you can configure the threshold values for each

virtual device individually.

If a trap breaches your threshold value and generates an alarm, SPECTRUM

uses the value of the ―state‖ var-bind passed along with the trap to determine

the alarm severity. All state var-binds have the following possible values,

which SPECTRUM alarms on the same way:

■ 0: Unknown

■ 1: OK

■ 2: Warning

■ 3: Critical



SPECTRUM maps these vCenter states to a SPECTRUM alarm severity, as

shown:

vCenter State SPECTRUM Alarm Severity

0: Unknown

Clear

1: OK Clear

2: Warning

Minor (Yellow)

3: Critical Major (Orange)

More information:



How SPECTRUM Forwards Traps from SystemEDGE

SPECTRUM supports all traps sent by the CA VPM AIM MIB. These traps are

initially sent to the vCenter SystemEDGE model. If the destination for a trap is

not the vCenter model, SPECTRUM forwards the trap to the correct virtual

model.

Note: For specific event codes related to the traps, use the Event

Configuration application and filter on ―0x056e.‖ Alternately, you can launch

MIB tools to view the traps in the Trap Support table for the

―EMPIRE-CAVMVCA-MIB‖ MIB. For more information about using the Event

Configuration application, see the Event Configuration User Guide (5188). For

more information about using MIB tools, see the Modeling Your IT

Infrastructure Administrator Guide (5167).



SPECTRUM follows this process to determine which model to forward the trap

to:

1. When SPECTRUM receives a trap, it maps the UID of the entity type to a

well-known var-bind location.

Note: For the Host Sensor traps, SPECTRUM uses the virtual entity name,

not the UID. If you have more than one host with the same vCenter name,

SPECTRUM maps to the first entry.

2. SPECTRUM intelligence uses this UID to look up and locate the SPECTRUM

model tied to a given UID. The entity type associated with all traps is

predetermined. Depending on the results of the look-up, SPECTRUM

forwards the trap as follows:

■ If it finds a SPECTRUM model of a specific type with a given UID,

SPECTRUM forwards the event and corresponding alarm to the

destination model.

■ If it cannot find a SPECTRUM model for a given UID, SPECTRUM

generates a new generic event (0x56e109f) on the vCenter model.

This new event includes the following details:

– Trap details

– Entity type searched for

– Information used when SPECTRUM attempted to find the

information relating to a given model

Note: The most likely case when SPECTRUM cannot find a related

model is when a trap is sent immediately after changing your virtual

network entities in vCenter, and vCenter Discovery has not yet

identified and created the corresponding model in SPECTRUM.

More information:


Traps Supported in Virtual Host Manager

All traps generated by the CA VPM AIM are supported in SPECTRUM. The traps

are initially sent to the vCenter model. Then, the traps are forwarded to a

corresponding virtual entity type (that is, the "destination" entity), depending

on the type of trap. Using these traps, you can monitor the performance of

your virtual network, resolve any resulting alarms, or trigger events.

Note: For more information about traps generated by the CA VPM AIM, see

the CA Virtual Performance Management AIM for VMware VirtualCenter Product

Guide.



The following tables list the traps for a specific destination entity type and

specify whether the trap generates an alarm.

Cluster Traps

Trap Name Trap OID Alarm?

vmvcAimClusterHADRSChangeTrap

1.3.6.1.4.1.546.1.1.0.165253

No

vmvcAimClusterRenamedTrap

1.3.6.1.4.1.546.1.1.0.165254

No

vmvcAimClusterDRSConfigChangeTrap 1.3.6.1.4.1.546.1.1.0.165255 No

Datacenter Traps


vmvcAimDCRenamedTrap

1.3.6.1.4.1.546.1.1.0.165248

No

vmvcAimDCConfigChangeTrap 1.3.6.1.4.1.546.1.1.0.165249 No

ESX Host Traps


vmvcAimHostCpuStateChangeTrap

1.3.6.1.4.1.546.1.1.0.165208

Yes

vmvcAimHostTotalCpuStateChangeTrap 1.3.6.1.4.1.546.1.1.0.165209 Yes

vmvcAimHostTotalMemStateChangeTrap 1.3.6.1.4.1.546.1.1.0.165210 Yes

vmvcAimHostMemStateChangeTrap 1.3.6.1.4.1.546.1.1.0.165211 Yes

vmvcAimHostConfigChangeTrap 1.3.6.1.4.1.546.1.1.0.165212 No

vmvcAimHostTotalVMCpuStateChangeTrap 1.3.6.1.4.1.546.1.1.0.165213 Yes

vmvcAimHostMemOtherStateChangeTrap 1.3.6.1.4.1.546.1.1.0.165214 Yes

vmvcAimHostThresholdChangeTrap 1.3.6.1.4.1.546.1.1.0.165215 No

vmvcAimHostVMotionTrap 1.3.6.1.4.1.546.1.1.0.165218 No

vmvcAimHostConnectionStateTrap 1.3.6.1.4.1.546.1.1.0.165219 No**

vmvcAimHostTotalVMMemStateChangeTrap 1.3.6.1.4.1.546.1.1.0.165220 Yes

vmvcAimPNICStateChangeTrap 1.3.6.1.4.1.546.1.1.0.165241 Yes

vmvcAimPNICAddedTrap 1.3.6.1.4.1.546.1.1.0.165242 No

vmvcAimPNICRemovedTrap 1.3.6.1.4.1.546.1.1.0.165243 No

vmvcAimPNICConfigChangeTrap 1.3.6.1.4.1.546.1.1.0.165244 No

vmvcAimHostDiskAddedTrap 1.3.6.1.4.1.546.1.1.0.165291 No

vmvcAimHostDiskRemovedTrap 1.3.6.1.4.1.546.1.1.0.165292 No

vmvcAimCPUSensorStateChangeTrap* 1.3.6.1.4.1.546.1.1.0.165281 Yes

vmvcAimMemSensorStateChangeTrap* 1.3.6.1.4.1.546.1.1.0.165282 Yes




vmvcAimFanSensorStateChangeTrap* 1.3.6.1.4.1.546.1.1.0.165283 Yes

vmvcAimVoltageSensorStateChangeTrap* 1.3.6.1.4.1.546.1.1.0.165284 Yes

vmvcAimTempSensorStateChangeTrap*

1.3.6.1.4.1.546.1.1.0.165285

Yes

vmvcAimPowerSensorStateChangeTrap* 1.3.6.1.4.1.546.1.1.0.165286 Yes

*The vCenter ESX host name is used to locate the ESX model in SPECTRUM. If two ESX models exists

with the same name, SPECTRUM alarms on the first model matching the name.

**These traps are not alarmed on, because SPECTRUM vCenter polling intelligence detects and

generates these alarms on the next vCenter poll cycle.

Resource Pool Traps


vmvcAimResourcePoolCpuStateChangeTrap

1.3.6.1.4.1.546.1.1.0.165258

Yes

vmvcAimResourcePoolConfigChangeTrap 1.3.6.1.4.1.546.1.1.0.165259 No

vmvcAimResourcePoolRenamedTrap 1.3.6.1.4.1.546.1.1.0.165260 No

vmvcAimResourcePoolMemStateChangeTrap

1.3.6.1.4.1.546.1.1.0.165264

Yes

vmvcAimResourcePoolHealthStateChangeTrap 1.3.6.1.4.1.546.1.1.0.165265 Yes

vCenter Server Traps


vmvcAimServerStateChangeTrap

1.3.6.1.4.1.546.1.1.0.165201

Yes

vmvcAimVCConfigChangeTrap 1.3.6.1.4.1.546.1.1.0.165202 No

vmvcAimVCCPUStateChangeTrap 1.3.6.1.4.1.546.1.1.0.165203 Yes

vmvcAimVCThresholdChangeTrap 1.3.6.1.4.1.546.1.1.0.165204 No

vmvcAimVCEventReceivedTrap 1.3.6.1.4.1.546.1.1.0.165205 No

vmvcAimVCMemStateChangeTrap 1.3.6.1.4.1.546.1.1.0.165206 Yes

vmvcAimHostAddedTrap*** 1.3.6.1.4.1.546.1.1.0.165216 No

vmvcAimHostRemovedTrap*** 1.3.6.1.4.1.546.1.1.0.165217 No

vmvcAimVMAddedTrap*** 1.3.6.1.4.1.546.1.1.0.165222 No

vmvcAimVMRemovedTrap*** 1.3.6.1.4.1.546.1.1.0.165223 No

vmvcAimVMMigratedTrap*** 1.3.6.1.4.1.546.1.1.0.165230 No

vmvcAimDCAddedTrap*** 1.3.6.1.4.1.546.1.1.0.165246 No




vmvcAimDCRemovedTrap*** 1.3.6.1.4.1.546.1.1.0.165247 No

vmvcAimClusterAddedTrap*** 1.3.6.1.4.1.546.1.1.0.165251 No

vmvcAimClusterRemovedTrap*** 1.3.6.1.4.1.546.1.1.0.165252 No

vmvcAimResourcePoolAddedTrap*** 1.3.6.1.4.1.546.1.1.0.165256 No

vmvcAimResourcePoolRemovedTrap*** 1.3.6.1.4.1.546.1.1.0.165257 No

vmvcAimTemplateAddedTrap 1.3.6.1.4.1.546.1.1.0.165261 No

vmvcAimTemplateRemovedTrap 1.3.6.1.4.1.546.1.1.0.165262 No

vmvcAimTemplateRenamedTrap 1.3.6.1.4.1.546.1.1.0.165263 No

vmvcAimCustomizationSpecAddedTrap 1.3.6.1.4.1.546.1.1.0.165266 No

vmvcAimCustomizationSpecRemovedTrap 1.3.6.1.4.1.546.1.1.0.165267 No

vmvcAimDatastoreAddedTrap 1.3.6.1.4.1.546.1.1.0.165271 No

vmvcAimDatastoreRemovedTrap 1.3.6.1.4.1.546.1.1.0.165272 No

vmvcAimDatastoreAccessibleStateChangeTrap 1.3.6.1.4.1.546.1.1.0.165273 Yes

vmvcAimDatastoreConfigChangeTrap 1.3.6.1.4.1.546.1.1.0.165274 No

vmvcAimDatastoreRenamedTrap

1.3.6.1.4.1.546.1.1.0.165275

No

vmvcAimDatastoreFreeSpaceStateChangeTrap 1.3.6.1.4.1.546.1.1.0.165276 Yes

***These events are generated on the vCenter server, because vCenter Discovery generates similar

events on each entity when that entity is discovered or removed from SPECTRUM management.

Virtual Machine Traps


vmvcAimVMCpuStateChangeTrap

1.3.6.1.4.1.546.1.1.0.165221

Yes

vmvcAimVMConfigChangeTrap 1.3.6.1.4.1.546.1.1.0.165224 No

vmvcAimVMThresholdChangeTrap 1.3.6.1.4.1.546.1.1.0.165225 No

vmvcAimVMPercentReadyTrap 1.3.6.1.4.1.546.1.1.0.165226 Yes

vmvcAimVMRenamedTrap 1.3.6.1.4.1.546.1.1.0.165227 No

vmvcAimVMBehaviourChangeTrap 1.3.6.1.4.1.546.1.1.0.165228 No

vmvcAimVMConnectionStateChangeTrap 1.3.6.1.4.1.546.1.1.0.165229 No**

vmvcAimVMNICStateChangeTrap 1.3.6.1.4.1.546.1.1.0.165231 Yes

vmvcAimVMNICAddedTrap 1.3.6.1.4.1.546.1.1.0.165232 No

Fault Management for Virtual Networks



vmvcAimVMNICRemovedTrap 1.3.6.1.4.1.546.1.1.0.165233 No

vmvcAimVMNICConfigChangeTrap 1.3.6.1.4.1.546.1.1.0.165234 No

vmvcAimVMVDiskStateChangeTrap 1.3.6.1.4.1.546.1.1.0.165236 Yes

vmvcAimVMVDiskAddedTrap 1.3.6.1.4.1.546.1.1.0.165237 No

vmvcAimVMVDiskRemovedTrap 1.3.6.1.4.1.546.1.1.0.165238 No

vmvcAimVMVDiskConfigChangeTrap 1.3.6.1.4.1.546.1.1.0.165239 No

vmvcAimVMMemStateChangeTrap 1.3.6.1.4.1.546.1.1.0.165268 Yes

vmvcAimVMPowerStateChangeTrap

1.3.6.1.4.1.546.1.1.0.165269

No**

vmvcAimVMHBStateChangeTrap

1.3.6.1.4.1.546.1.1.0.165270

No

**These traps are not alarmed on, because SPECTRUM vCenter polling intelligence detects and

generates these alarms on the next vCenter poll cycle.

More information:



How SPECTRUM Forwards Traps from SystemEDGE (see page 44)




The goal of fault isolation is to narrow down the root cause of a networking

problem, helping you to troubleshoot and quickly correct the problem or to

correct the problem programmatically with automated scripts. Deciding which

devices are the root cause of an alarm can be difficult, because problems with

a single device can cause several devices in your network to generate events.

For example, losing contact with an ESX host often means that you have also

lost contact with the virtual machines managed by that ESX. Therefore, the

ESX device model and all affected virtual machines generate alarms. Using

fault isolation techniques, Virtual Host Manager correlates these alarms in an

attempt to identify a single root cause.



Virtual networks provide a unique management opportunity, because they

provide SPECTRUM an alternate management perspective. That is, SPECTRUM

can gather information through direct contact with your virtual devices or

through the virtual network management application, VMware vCenter. This

alternate management perspective enhances standard SPECTRUM fault

management in two ways:

■ Enhanced contact lost alarms—Two sources of information about a

device means Virtual Host Manager can pinpoint the cause and more easily

correlate events to a single root cause.

■ Proxy failure alarms—Proxy management is the act of managing

network devices using an alternate management source in place of or in

addition to the primary manager. For example, SPECTRUM can manage

virtual network devices by contacting them directly or through VMware

vCenter contact with the devices. When vCenter loses contact with a

virtual network device, Virtual Host Manager generates a proxy

management lost alarm for each device. These alarms are unique, because

they are alerting you to the fact that management of the device through

the proxy is affected, not the state of the device or direct (SNMP)

management.

How Fault Isolation Works when Device Contact is Lost

To help you troubleshoot networking problems with your devices, SPECTRUM

uses fault isolation to narrow down the root cause of an alarm. For virtual

networks, Virtual Host Manager uses information from direct contact with the

device plus information provided by vCenter through the CA VPM AIM. In many

cases, standard SPECTRUM fault management can pinpoint the root cause. But

in special circumstances, the method for isolating problems in a virtual

network go beyond the standard methods.

The type of fault isolation Virtual Host Manager uses to discover the root cause

depends on which devices are alarming and the type of events the devices

generate. The following scenarios describe two unique fault management

situations and how SPECTRUM isolates the networking error in your virtual

network.

Scenario 1: Virtual machine is powered down or suspended

In a virtual environment, the virtual management application can provide more

details than SPECTRUM can discover through standard device monitoring. For

example, the management application is aware when a virtual machine is

placed into one of the following modes:

■ Powered down

■ Suspended



If a virtual machine is in one of these modes and SPECTRUM loses contact with

it, but proxy management (see definition on page 59) of the ESX host is

uninterrupted, SPECTRUM determines the root cause as follows:

1. When SPECTRUM loses contact with the virtual machine, it generates a

contact lost alarm.

2. During its next polling cycle, the vCenter server model polls the CA VPM

AIM to gather information about the virtual machines. Because vCenter

manages the virtual machines, it can provide a unique view into the

possible cause of alarms generated by a virtual machine.

3. If vCenter finds that a virtual machine is powered down or suspended, it

generates the appropriate alarm.

Note: The powered down and suspend alarms are cleared upon the first

vCenter polling cycle after the virtual machine is powered on.

4. Virtual Host Manager correlates these powered down and suspend alarms

to the corresponding contact lost alarm created by SPECTRUM. Virtual Host

Manager makes the contact lost alarm appear as a symptom of the

powered down or suspend alarms.

Scenario 2: ESX host is down

If SPECTRUM loses contact with an ESX host and all virtual machines running

on that host, SPECTRUM checks the status of the upstream routers and

switches. Depending on their status, SPECTRUM determines the root cause as

follows:

■ One or more directly connected routers or switches are

unavailable—Standard SPECTRUM fault isolation techniques determine the

root cause.

■ All directly connected routers and switches are available—SPECTRUM infers

that the ESX is the root cause and responds as follows:

a. The ESX and all virtual machines, ports, and fanouts that are directly

connected to the ESX model or virtual machine models generate the

standard fault isolation alarms.

b. Virtual Host Manager creates a physical host down alarm for the ESX

model.

c. All fault isolation-related alarms that are created for the impacted

devices (such as virtual machines, ports, and fanouts) are correlated to

the physical host down alarm, making them symptoms of the physical

host down alarm. These symptom alarms appear in the Symptoms

table on the Impact tab for the main ESX alarm.



Note: For each ESX model, Virtual Host Manager creates a "virtual

fault domain." This domain includes the ESX and virtual machines, plus

all ports and fanouts directly connected to the ESX model or virtual

machines. When the ESX and the models in its virtual fault domain

generate alarms, all standard fault isolation alarms within the domain

are correlated to the ESX alarm. Correlating these alarms as symptoms

indicates that the ESX alarm is the root cause.

d. All impacted devices are listed in the Management Lost Impact table on

the Impact tab for the main ESX alarm.

Note: Devices that are suppressed do not have a corresponding alarm

in the Symptoms table, which is why the following example shows only

two alarms but six impacted devices:

e. If a directly connected switch or router becomes unavailable,

SPECTRUM clears the physical host down alarm, because it can no

longer reliably state that the fault lies with the ESX host.



More information:

How Fault Isolation Works when Proxy Management is Lost (see page 53)

Determining Virtual Machines Affected by ESX Outages (see page 55)

How Fault Isolation Works when Proxy Management is Lost

The VMware vCenter application used to create your virtual network provides

SPECTRUM a unique management opportunity. SPECTRUM can use the

standard methods to contact your virtual devices directly, plus SPECTRUM can

simultaneously gather virtual device information from vCenter. In this sense,

vCenter is a "proxy" from which SPECTRUM gathers virtual device information.

If SPECTRUM loses direct contact with a device, it generates alarms. Likewise,

if vCenter loses contact with a virtual device or if Virtual Host Manager loses

contact with the vCenter application, Virtual Host Manager generates

alarms—proxy management lost alarms (see definition on page 59).

In response, SPECTRUM attempts to isolate the cause of the proxy

management failure. Proxy fault isolation is similar to the standard SPECTRUM

fault isolation, except that these alarms alert you to the fact that proxy

management of a virtual device is affected. Proxy management fault isolation

cannot tell you whether a virtual device is up or down. However, it is important

to know when contact through the proxy is lost, because you could be missing

important virtual information about a device.

The type of proxy fault isolation Virtual Host Manager uses to discover the root

cause depends on which devices are alarming and the type of events the

devices generate. The following scenarios describe two unique proxy fault

management situations and how Virtual Host Manager isolates the networking

error in your virtual network.

Scenario 1: Contact between vCenter and ESX is lost

If vCenter loses contact with one of the ESX hosts it is managing, the vCenter

data about that ESX and all hosted virtual devices is lost. To isolate the

problem, Virtual Host Manager determines the root cause as follows:

1. A proxy lost alarm is generated on the ESX and all hosted virtual

machines.

2. The virtual machine alarms are correlated to the ESX proxy lost alarm,

making them symptoms of the ESX alarm. Correlating these alarms as

symptoms indicates that the ESX alarm is the root cause.

3. If the ESX host also generates a physical host down alarm, the proxy lost

alarm generated for the ESX is correlated to the physical host down alarm.

In this case, the proxy lost alarm becomes a symptom of the physical host

down alarm. Correlating this alarm as a symptom indicates that the ESX

physical host alarm is the root cause.



Scenario 2: Contact between SPECTRUM and vCenter is lost

If SPECTRUM loses contact with the vCenter model, SPECTRUM loses the

vCenter data about all virtual models managed by that vCenter server. To

isolate the problem, Virtual Host Manager determines the root cause as

follows:

1. SPECTRUM generates proxy lost alarms for all virtual models managed by

that vCenter server, including virtual machines, ESX hosts, datacenters,

resource pools, and clusters. SPECTRUM also generates a separate proxy

unavailable alarm on the vCenter server model.

2. The virtual machine alarms are correlated to their corresponding ESX

model alarm.

3. The ESX, datacenter, resource pool, and cluster alarms are correlated to

the vCenter model proxy unavailable alarm.

4. The vCenter alarm is correlated to another alarm generated by standard

SPECTRUM fault management, such as the alarms created for the following

situations:

■ Lost management of vCenter (that is, a problem occurred with the

SystemEDGE agent on the vCenter server)

■ Machine contact is lost

■ vCenter is in maintenance mode

More information:

How Fault Isolation Works when Device Contact is Lost (see page 50)

Determining Virtual Machines Affected by ESX Outages


Determining Virtual Machines Affected by ESX Outages

When contact with an ESX host is interrupted or the ESX host goes down, all

virtual machines hosted by the ESX are affected. Because vCenter cannot

communicate with the ESX host to get usage information, you might not

receive alarms for a critical virtual machine hosted on that ESX. To find out if a

critical virtual machine is impacted, you can view a list of affected virtual

machines on the Impact tab of the alarm, as follows:

■ Symptoms view—displays all symptom alarms generated by the affected

virtual machines

■ Management Lost Impact view—lists the virtual machines impacted by the

alarm

More information:

How Fault Isolation Works when Device Contact is Lost (see page 50)

Appendix A: Troubleshooting 57

Appendix A: Troubleshooting

This section describes common symptoms or issues that can occur when using

Virtual Host Manager and our recommended solution.

Duplicate Models Created After SNMP and vCenter

Discovery

Symptom:

After I run the standard SPECTRUM Discovery on my virtual network and then

let Virtual Host Manager run a vCenter Discovery, I get a "Duplicate Models"

alarm for some of my virtual machines. Which model should I delete, and how

do I prevent it from happening again?

Solution:

When modeling a virtual environment, a duplicate model can be created when

a virtual machine has neither VMware tools nor an SNMP agent installed. The

duplicate model is created as follows:

1. SPECTRUM Discovery models the virtual machine using a Pingable model

type, because the virtual machine does not have an SNMP agent installed.

This model contains an IP address, but it does not contain a MAC address.

The upstream router that usually looks up the MAC address for a device is

not yet modeled, so the MAC address for the virtual machine cannot be

resolved.

2. Virtual Host Manager runs a vCenter Discovery and finds the same virtual

machine. Because the virtual machine does not have VMware tools

installed, Discovery can identify a MAC address but cannot determine the

IP address. Therefore, vCenter Discovery does not recognize it as the

existing model created in step 1, so it creates a second model for the

virtual machine. This model contains a MAC address but no IP address.

3. When SPECTRUM finds a model with no IP address, it performs an OS call

using the model name to get the IP address. If the virtual machine name

in vCenter matches the name returned from the OS, the OS passes the IP

address of the virtual machine device to SPECTRUM. SPECTRUM sets the IP

address in the model created by the vCenter Discovery—this model now

contains both the MAC address and IP address.

4. The Duplicate Model alarm is triggered for each model, because they both

have the same IP address.

Duplicate Models Created After SNMP and vCenter Discovery


To correct the problem, delete the virtual machine device model created by the

SPECTRUM Discovery (that is, the model that contains the IP address

only)—keep the model that has both an IP and MAC address. Otherwise, the

same problem repeats the next vCenter poll cycle. If the delete affects the

Virtual Host Manager hierarchy, wait one polling cycle of the vCenter server

host, and the modeling is restored.

To avoid this problem when modeling your virtual environment using

SPECTRUM Discovery, verify that the upstream routers for all virtual machines

without VMware tools meet one of the following criteria:

■ Routers have already been modeled with an SNMP-capable model type

■ Routers are included in your Discovery range along with the proper SNMP

credentials

By including the upstream routers, SPECTRUM attempts to resolve the physical

address belonging to each host that does not have an SNMP agent.

If you model your virtual environment by modeling your VMware vCenter

server by IP address and Discovery creates models without IP addresses, you

must manually specify the IP for those devices before running SPECTRUM

Discovery.

Glossary 59

Glossary

cluster

A cluster is a group of ESX hosts and their associated virtual machines. When

a host is added to a cluster, the host’s resources become part of the cluster’s

resources. The cluster manages the resources of all hosts within it.

datacenter

A datacenter in VMware represents the primary container of virtual

environment components, such as ESX hosts and clusters. Companies can

create multiple datacenters, each representing distinct organizational units in

their enterprise, such as geographical regions or separate business functions.

distributed SpectroSERVER (DSS)

Distributed SpectroSERVER (DSS) is a powerful modeling feature that enables

the distribution of management for portions of a large-scale network, either

geographically, or across multiple servers in a single physical location.

ESX host

An ESX host is a physical computer that uses ESX Server virtualization

software to run virtual machines. Hosts provide the CPU and memory

resources that virtual machines use and give virtual machines access to

storage and network connectivity.

pingable model

A pingable model is a generic type of network model created in SPECTRUM

based on a non-SNMP model type. SPECTRUM can poll these devices to provide

basic model management, but SNMP-capable monitoring is not available.

proxy management

Proxy management is the act of managing network devices using an alternate

management source in place of or in addition to the primary manager. For

example, SPECTRUM can manage virtual network devices by contacting them

directly or through VMware vCenter contact with the devices.

resource pool

A resource pool can be used to hierarchically partition available CPU and

memory resources of a cluster or standalone host. Resource pools provide a

mechanism to control the aggregate allocation of resources to a set of virtual

machines.

vCenter

vCenter is a VMware application that provides centralized management,

operational automation, and resource optimization for ESX environments.


VHM model

A VHM model in SPECTRUM represents a virtual entity managed by the vCenter

server. Instead of retrieving status and management information from SNMP

like some traditional SPECTRUM models, a VHM model communicates directly

to the CA VPM AIM for its fault and virtual management capabilities. A VHM

model can additionally communicate via SNMP if an SNMP agent is installed

and configured on the modeled device.

virtual machine (VM)

A virtual machine (VM) is a software computer that, like a physical computer,

runs an operating system and applications. Because every virtual machine is

an isolated computing environment, they are often used as desktop or

workstation environments, as testing environments, or to consolidate server

applications.

Index 61

Index

A

About Virtual Host Manager • 7

Add SNMP Capabilities to VHM Models • 16

Alarms and Fault Isolation in Virtual Host

Manager • 43

C

CA Product References • iii

cluster • 59

Configure and Monitor Resource Status • 22

Configure Maintenance Mode for New Virtual

Machines • 24

Configure the CA VPM AIM • 19

Contact CA • iii

Custom Views for Virtual Entity Types • 37

D

datacenter • 59

Deleted Models • 36

Determining Virtual Machines Affected by ESX

Outages • 55

distributed SpectroSERVER (DSS) • 59

Duplicate Models Created After SNMP and

vCenter Discovery • 57

E

ESX host • 59

F

Fault Management for Virtual Networks • 49

G

Getting Started • 11

H

How Fault Isolation Works when Device

Contact is Lost • 50

How Fault Isolation Works when Proxy

Management is Lost • 53

How SPECTRUM Forwards Traps from

SystemEDGE • 44


• 35

How to Configure Virtual Host Manager • 18

How to Discover and Model Your Virtual

Environment • 12

How to Install Virtual Host Manager • 11

How vCenter Discovery Works • 15

How Virtual Host Manager Works • 8

L

Locater Tab for Virtual Host Manager • 39

M

Manage Device Models for Devices Deleted

from vCenter • 23

Move an ESX Host to a New vCenter • 17

P

pingable model • 59

proxy management • 59

R

resource pool • 59

Run SPECTRUM Discovery • 12

S

Searching • 38

Status Monitoring Options • 40

System Requirements • 8

T

Traps Supported in Virtual Host Manager • 45

Troubleshooting • 57

U

Upgrade the SystemEDGE Model • 14

V

vCenter • 59

VHM model • 60

Viewing Your Virtual Environment • 27

Viewing Your VMware Virtual Network in

SPECTRUM • 31

Virtual Host Manager • 7

Virtual Host Manager Alarms • 43

Virtual Host Manager in SPECTRUM OneClick •

27


virtual machine (VM) • 60

Virtual Technologies Supported by Virtual Host

Manager • 8

W

Who Should Use Virtual Host Manager • 7

Workstation Icons in Virtual Host Manager • 31

Documents

SPECTRUM Virtual Host Manager