ViPR SRM 3.6 – SolutionPack for Physical Hosts Summary Sheet

Table of Contents

Overview

Learn how to install and configure theSolutionPack for Physical Hosts. The SolutionPack for Physical Hosts enables you to monitor and generate real-time and historical reports on the performance of physical hosts.

The SolutionPack gives better insight into parameters such as capacity and utilization associated with an inventory of File Systems, Volume Groups, and Disks (local and remote).

SolutionPack for Physical Hosts

SolutionPack for Physical Hosts

Back to Top

Technical Specifications

Main reports

Host Information and details

File Systems, Volume Management summary report

Internal and SAN Disk Capacity Reports

Service level for LUNs mapped to host file systems

Performance metrics for host devices namely CPU, Memory, Disks

Native Multipathing and Powerpath reports

Supported collection interfaces

For information about supported collection interfaces, refer to the ViPR SRM Support Matrix.

Back to Top

Where to find the latest SolutionPack software

Install the latest core software update for your product suite. SolutionPacks distributed with core software have a 30-day free evaluation period. If you plan to use the software longer than 30 days, you must install a SolutionPack license before the trial period ends.

This 30-day free evaluation only applies to new installations and is not available for upgraded installations. If you upgrade the core software and want to try a new SolutionPack, you must request a license for that SolutionPack by completing a Support Request (SR) form, which is available on the EMC Online Support website at http://support.emc.com.

Back to Top

Preparing your hosts for discovery and data collection

You need to configure your hosts to support resource discovery and data collection.

ViPR SRM uses the md5sum utility to verify the checksum of files on the target hosts and compare them to the files on the collector before pushing scripts and binaries to the host. The md5sum binary must be installed on the hosts, and the PATH environment variable must contain the location to the md5sum binary.

Refer to the following sections for additional details about configuring your hosts:

Back to Top

Guidelines for hostnames and IP addresses

You have to follow these guidelines to ensure a successful host discovery and data collection.

  • The host names are in Domain Name Server (DNS) format with fully qualified domain name (FQDN).
  • IP addresses are registered with the appropriate domain name servers and resolve for a reverse DNS lookup.

Back to Top

Guidelines for SNIA libraries and HBA drivers

In order to discover SNIA-qualified HBA-related information for all the host platforms you should ensure the right versions of SNIA library, drivers and firmware are in place.

  • Ensure you have EMC-supported host bus adapter (HBA) drivers and firmware. EMC ViPR SRM Support Matrix provides information for the supported SNIA compliant version of the HBA driver.
  • HBA Model and the compatible driver versions qualified by EMC can also be verified on https://support.emc.com > Product and Support Tools > Elab Interoperability Navigator. The vendor websites also list the EMC compatible drivers
  • The vendor-specific SNIA libraries must be installed on the target host.
  • The HBA model number and part number should be verified before updating the hosts with SNIA libraries for HBA.
  • You can install the SNIA library as part of HBA driver installation package or install the latest version of HBAnywhere (for Emulex installations) or SAN Surfer (for Qlogic installation).

    To discover an HP-UX host with a multi-port Fibre Channel card, the package CommonIO bundle 0812(Dec 2008) or later should be present on the host to obtain the updated FC-SNIA file set. INQ is dependent on binaries from CommonIO bundle.

Back to Top

Windows host configuration for discovery and data collection

Software to preinstall on hosts

  • Install Powershell 2.0 or later on Windows hosts. Powershell can be downloaded from http://support.microsoft.com/kb/968929/en-us. User should have permissions to execute powershell scripts. To provide permissions to execute scripts, type on powershell terminal: Set-ExecutionPolicy RemoteSigned

Preinstall the following software on hosts using Windows 2003:

  • Fcinfo is required to fetch HBA information. fcinfo.exe can be downloaded from http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=17530. Use the latest version of fcinfo and the default install location recommended by Windows.
  • INQ 7.6.2 needs to be made available on the host. Platform specific INQ can be downloaded from: ftp://ftp.emc.com/pub/symm3000/inquiry/v7.6.2/ The downloaded platform specific binary should be renamed to inq and placed in any one of the below specified locations:
    • C:\inq.exe
    • C:\temp\inq.exe
    • C:\windows\Temp\nl_dwd\inq.exe

    INQ binary should have executable permissions on the host.

User permissions required to be configured in ViPR SRM

The user credentials required for successful host discovery would be as follows:

  • Local administrator
  • Domain user who is part of administrator's group
  • Non-admin user
A non-admin user is identified by ViPR SRM as a service account user or domain user who is neither a part of the Administrator group or domain Administrators group.

Types of discovery allowed by different privilege levels

Configurations to be performed on the host

Hosts should be pre-configured with certain WSMAN settings. These settings are required to prepare Windows hosts for ViPR SRM discovery of objects using WinRM services.

Configure one of the following listeners:

  • WinRM HTTP listener with the following configuration:
    • Negotiate authentication mode set to true.
    • AllowUnencrypted be set to true
    • Firewall exception added for port 5985
  • WinRM HTTPS listener with following configuration:
    • Negotiate authentication mode set to true
    • A certificate needs to be generated and placed in personal store.

      Generating a .pfx certificate

    • Firewall exception added for port 5986.

These changes can be accomplished via two methods:

Back to Top

Types of discovery allowed by different privilege levels

In this topic, the term "non-admin user" is a service account user or domain user who is not part of the Administrators group on a Windows host.

The following table applies to Windows 2003, 2008, and 2012:

Chargeback reports for non-admin users is supported on VMAX, VNX, VNXe and XtremIO array devices. Refer to the release notes for any limitations on third-party array LUNs masked to Windows hosts.

Back to Top

Customizing a WinRM URL prefix

Before you begin

EMC supports use of a custom WinRM URL prefix. You can change the URL prefix from the default "wsman" to any other, by using following command on the target host.

Procedure

  1. Type the following command:
    For Use
    Non-SSL communication winrm set winrm/config/listener?Address=*+Transport=HTTP @ {URLPrefix="EMC"}
    SSL-based communication winrm set winrm/config/listener?Address=*+Transport=HTTPS @{URLPrefix="EMC"}
  2. In the default installation path /opt/APG/Collecting/Collector-Manager/Generic-RSC/conf), add and commit the following line in module.properties: apg.remote.shell.winrm.path=<URL prefix>
    "/EMC" is an example of a user-defined WinRm URL prefix.
Back to Top

Prerequisites for discovering a Windows host using non-admin user credentials

To prepare Windows hosts for discovery, you can configure privileges in these ways:

  • Provide the option -user nonadmin as an input to the Host Configuration utility
  • Manually

The following checklist summarizes the configuration changes required on Windows hosts:

  1. WinRM configuration settings:
    1. Adding a non-admin user to a group
    2. Retrieving the SID of a non-admin user
    3. Adding a non-admin SID to root SDDL
  2. Enabling WMI permissions for the non-admin user
  3. Restarting WinRM and WMI services

If you decide to use Host Configuration utility, the script performs these operations on the host.

  • For Windows 2003 hosts the Host configuration utility sets the WinRM changes. You must manually configure the WMI permissions.

    Enabling WMI permissions for the non-admin user

  • For Windows 2008 and Windows 2012, the Host Configuration utility sets both WinRM and WMI configurations.

These procedures are only available in ViPR SRM 3.5.1.

Back to Top

Adding a non-admin user to a group

Before you begin
  • On a Windows 2003 host, the non-admin user should be part of the following groups:
    • TelnetClients
    • Performance Monitor Users
    • Performance Log Users
    • Distributed COM Users

On a Windows 2008/2012 host a non-admin user should be part of the following groups:

  • Performance Monitor Users
  • Performance Log Users
  • Add non-admin users to the group WinRMRemoteWMIUsers__ . If that group does not exist, add the user to Distributed COM Users group.

Procedure
  1. Go to Start.
  2. Right-click Computer name and click Manage.
  3. On the Computer management window, click Local Users and Groups.
  4. Right-click the non-admin user and select Properties.
  5. Select the MemberOf tab.
  6. Click the Add button and key in the group name.
  7. Click Ok, then click Apply.
  8. Repeat these steps to add Performance Monitor Users, Performance Log Users and TelnetClients.
  9. click Ok
Back to Top

Retrieving the SID of a non-admin user

Procedure
  1. Run the command wmic useraccount get name,sid at a command prompt.
  2. From the output of the command, capture the SID of the non-admin user.
Back to Top

Adding a non-admin SID to root SDDL

Procedure
  1. Open a command prompt.
  2. Type the following command to add the SID.
    winrm set winrm/config/service @{RootSDDL="O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;<non-admin-sid>)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)"}
    Replace <non-admin-sid> in this command with the SID you obtained.
Back to Top

Enabling WMI permissions for the non-admin user

Procedure
  1. Go to Start.
  2. Right click Computer name and click Manage.
  3. On the Computer management window, expand Services and Applications.
  4. Select WMI Control.
  5. Right click WMI Control and select properties.
  6. Click Security.
  7. Select Root and click the Security button.
  8. Add the non-admin user (hostname\non-admin-username) and click ok.
  9. Select the check boxes for Enable Account, Read Security, and Remote Enable.
  10. Click Advanced > edit on non-admin user > Apply onto > This namespace and subnamespaces.
  11. Click Ok, click Apply, and click Ok.
Back to Top

Restarting WinRM and WMI services

Procedure
  1. Go to Start > Run.
  2. Type the command services.msc.
  3. Right click Windows Remote Management and click start.
    In case the services are already running, click restart.
Back to Top

Using the HostConfiguration Utility

The host configuration utility is packaged along with SolutionPack for Physical Hosts. It is available <APG Home Directory/Collecting/Remote Shell Collector/Generic-RSC/scripts/windows>

The script verifies and performs the following actions:

  • Ensures that the WINRM service is running
  • Creates a listener port for accepting WS-MAN requests
  • Adds firewall exceptions to open port 5985 as non-SSL and 5986 as SSL
  • Sets Basic or Negotiate authentication mode, based on input argument to script (-authType <Authentication_type>), to true.
  • Sets AllowUnencrypted to true.
  • Sets MaxTimeout value to 300000 ms.
  • Checks whether fcinfo package is present on the host, if Windows 2003
  • Verifies the presence of INQ on the host and checks its version, if Windows 2003

Usage

./hostconfig-srm.ps1 <-verify | -set | -set -force> [-authType <authentication_type>] [-ssl [-thumbprint <thumbprint_value>] [-CN <certificate_hostname>]] [-user <username>][-help]

Examples

The following screens show how to perform actions with the Host Configuration Utility.

  • Verify whether host is ready for discovery with HTTP using Negotiate authtype on Windows 2003:
    Host Configuration Utility screen

    Verify that the host is ready for discovery with HTTP

  • Set Negotiate authtype for a successful discovery with HTTP on Windows 2008:
    Host Configuration Utility screen

    Set Negotiate authtype

  • Verify whether the host is ready for a successful discovery with HTTPS on Windows 2008:
    Host Configuration Utility screen

    Verify that the host is ready for discovery with HTTPS

  • Set Basic authtype for a successful discovery with HTTPS on Windows 2008, without prompting the user:
    Host Configuration Utility screen

    Set Negotiate authtype

  • Set non-admin user on Windows 2008:
    Host Configuration Utility screen

    Set non-admin user

Back to Top

Configuring group policy

Use a group policy if you do not want to set the configuration on each and every host (either manually or using a script). The group policy lets you apply a set of configurations across a set of hosts. You have to configure the group policy so that it can be applied across hosts as required.

Procedure

  1. Right-click Computer and select Manage.
  2. Go to Features > Group Policy Management > Forest Domain name > Domains > Domain Name > Default Domain Policy.
  3. Right-click Default Domain Policy and select Edit.
    The group policy editor appears.
  4. Select Default Domain Policy > Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management.
  5. Modify the following parameters as required:
    • Enable Allow automatic configuration of listeners.
    • Enable Allow Negotiate Authentication (for domain user).
    • Enable AllowUnencrypted.
    • Add Windows Firewall exception for Port 5985 - HTTP
    • Add Windows Firewall exception for Port 5986 - HTTPS
    Note Image
    HTTPS listener configuration is not possible from Group Policy.

Back to Top

Configuring firewall port exception using group policy

Using group policy, you have to configure firewall port exception if you are not using default ports.

Procedure

  1. Click Computer.
  2. Go to Computer Configurations > Policies > Windows Settings > Windows Firewall with Advanced Security > Inbound Rules
  3. Create a new inbound rule
    This enables the WinRM communication.
Back to Top

Updating group policy

If you update the group policy on a domain controller, the changes are reflected on the computers that are part of the domain in approximately 90-120 minutes. Use this procedure to force update the group policy on the member computers.

Procedure

  1. You can use any of the options for force update of group policy:
    Option Comment

    Run the command gpupdate/force on all the member computers.

    This command results in a fetch operation for the group policy

    This command has to be run on all the hosts and hence maybe cumbersome.

    Change the Group Policy Refresh Interval in the Group Policy Management editor under Computer Configuration > Administrative Templates > System > Group Policy

    Minimum possible time is 7 minutes.

    Reducing refresh interval is not recommended as it increases the load on the network.

Back to Top

Generating a certificate

WinRM HTTPS requires a local computer server authentication certificate or self-signed certificate with a CN name installed on the host. The certificates should not have expired or been revoked.

Perform the following to create certificates:

Procedure

  1. Generate a .pfx certificate
  2. Exporting the .pfx certificate
  3. Importing the .pfx certificate
  4. Generate a .cer file
  5. Import the .cer file
Back to Top

Generating a .pfx certificate

You can generate the required certificate using any certificate generator. This procedure demonstrates generating a certificate using makecert.

Procedure
  1. From the command prompt, run C:\>makecert.exe -ss MY -sr LocalMachine -n "CN=<certificatename>" -sky exchange -pe -a sha1 -eku 1.3.6.1.5.5.7.3.1
    This creates a certificate under the personal store. Use the following steps to verify the certificate created using makecert.
  2. On a Windows host, click Start > Run.
  3. Type mmc and click OK.
    The Console window appears.
  4. Click File > Add/Remove Snap-in.
  5. Select Certificates under Available snap-ins and click Add.
  6. Select Computer account.
  7. Click Finish.
  8. Click OK in the Add or Remove snap ins window.
  9. On the left pane, double click Certificates (Local Computer) > Personal > Certificates.
  10. On the right pane double click the certificate listed.
  11. Navigate to Details tab. Select Subject to get the CN Name and Thumbprint to get the Thumbprint of the certificate.

    Note the CN Name and Thumbprint value, which will be used later while creating a WSMAN listener for HTTPS.

Back to Top

Exporting the .pfx certificate

To use the same certificate on multiple hosts, the generated certificate has to be imported on other hosts.

Procedure
  1. On a Windows host, click Start > Run.
  2. Type mmc and click OK.
  3. In the Console window, click Certificates (local Computer) > Personal > Certificates.
  4. Double-click Certificates.
  5. Under Details, click Copy to File.
  6. In the Certificate Export Wizard select Yes, export the private key. and click Next.
  7. Select Include all certificates in the certification path if possible and click Next.
  8. Type a password for the private key.
    This password is used when you import this certificate on other hosts.
  9. Type a filename and save the .pfx file.
Back to Top

Importing the .pfx certificate

You have to import the .pfx on other hosts if you want to use the same certificate on multiple hosts.

Before you begin

The .pfx certificate must be copied on the host where it is to be imported.

Procedure
  1. On a Windows host, click Start > Run.
  2. Type mmc and click OK.
  3. In the Console window, click Certificates (Local Computer) > Personal > Certificates
  4. Right-click and select All Tasks > Import.
  5. In the browse window, select the .pfx certificate and click OK.
Back to Top

Generating a .cer file

The .cer file is created from a .pfx certificate with only a public key, which is used along with the private key for a successful handshake between the client and server.

Procedure
  1. Go to Start > Run > mmc > Certificates (Local Computer) > Personal > Certificates
  2. Double-click Certificates.
  3. Under Details, click Copy to File.
  4. Select No, do not export the private keys.
  5. Selecting the Encoding type as DER or Base-64, and click Next.
  6. Type a file name and click Save.
Back to Top

Importing a .cer file

You have to import the .cer file on the collector host to enable a successful handshake between the server and the client.

Procedure
  1. Copy the .cer file on the collector host.
  2. Log in to the collector.
  3. Run the command /opt/APG/Java/Sun-JRE/6.0u45/bin/keytool -import -file <Public_Certificate_File>-keystore/opt/APG/Java/Sun-JRE/6.0u45/lib/security/cacerts-alias <Name>

    The command prompts for keystore’s password. The default password is changeit.

    A sample output returned by the command:
    Owner: CN=<CN Name>
    Issuer: CN=Root Agency
    Serial number: 522200243f029a894c741bcb83d58a5d
    Valid from: Tue Dec 10 11:59:03 EST 2013 until: Sat Dec 31
    18:59:59 EST 2039
    Certificate fingerprints:
    MD5: 99:2A:6E:DC:CD:D7:7E:7D:07:C3:E2:8A:8F:E1:BB:DD
    SHA1:
    17:29:F4:45:99:AE:DC:C5:08:C6:73:D4:CF:A6:BE:7E:79:48:50:76
    Signature algorithm name: SHA1withRSA
    Version: 3
    Extensions:
    #1: ObjectId: 2.5.29.1 Criticality=false
    #2: ObjectId: 2.5.29.37 Criticality=false
    ExtendedKeyUsages [
    serverAuth
    ]
    Trust this certificate? [no]: yes
Back to Top

Unix host configuration for discovery and data collection

ViPR SRM supports discovery of several Unix variants. Each Unix environment requires some configuration for ViPR SRM to collect data consistently.

Software to preinstall on Unix hosts for discovery

The following software must be installed on Unix hosts for successful ViPR SRM discovery:

  • INQ binary (an EMC command line executable). You can acquire INQ in the following ways:
    • The SolutionPack for Physical Hosts is packaged with the INQ binary for each OS variant. Users can allow ViPR SRM to push INQ to the user's HOME directory during discovery from ViPR SRM. No action is needed from the user.
    • Pre-install INQ at a user-specified location on the host at a location provided to ViPR SRM during SolutionPack installation.

      INQ 7.6.2 needs to be made available on the host. Platform specific INQ can be downloaded from: ftp://ftp.emc.com/pub/symm3000/inquiry/v7.6.2/

      The downloaded platform-specific binary should be renamed to inq and placed in any user-defined location. The location where the INQ binary is placed must be provided to ViPR SRM during installation of the SolutionPack for Physical Hosts.

      Note: The INQ binary should have executable permissions on the host.

  • System Activity Report (SAR)

    This tool is used by ViPR SRM to collect performance metrics from hosts. Identify the compatible version of SAR (corresponding to the OS) and install the software on hosts required for discovery. The SolutionPack for Physical Hosts does not package the SAR utility.

Prepare Unix hosts for discovery

Unix hosts can be discovered in the following ways:

Back to Top

Configuring sudo for host discovery

Due to security constraints, ViPR SRM must be able to discover Linux and UNIX hosts in a data center even with non-root credentials. SUDO is a tool on UNIX hosts that can temporarily elevate a user’s credentials. Administrators can add specific commands in the sudoers file to enable ViPR SRM to execute those commands and collect host information.

Before you begin

Supported sudo versions
Linux Fedora distribution: sudo-1.8.6 and above
Other operating systems: any version of sudo

Procedure

  1. Include the path of sudo command in the environment variable $PATH for the sudo user.
    The variable $PATH can be set either in /etc/environment or /etc/default/login or any other OS specific file.
  2. Include the paths of OS commands in the environment variable $PATH for sudo user.
    By default, most of the command files have the following location: /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
  3. Verify that the $PATH is correct.
    1. Log in as sudo user
    2. Type which sudo.
  4. Ensure that the sudoers file is available.
    By default, the sudoers file is available in /etc or /opt/sfw/etc/ or /usr/local/etc/sudoers
  5. Add the following line to the defaults section of the sudoers file:

    Defaults !requiretty #for all users

    or

    Defaults : SRMADMIN !requiretty #for a specific user

  6. For AIX hosts, if inq gives partial information, add the following line:
    Defaults env_keep += "ODMDIR"
  7. Ensure that the sudo user has root privilege to run the following commands on a given host.

    Ensure the absolute path to the packages are provided in sudoers file.

    It is recommended to use visudo to edit sudoers file.

    Some packages are not installed by default.

    AIX
    sar, inq, powermt, vxdisk, swap, kdb (kdb is only for VIO Clients)
    Linux
    sar, inq, powermt, vxdisk, dmidecode, lvdisplay, pvs, vgs, multipath
    HPUX
    sar, inq, powermt, vxdisk, /opt/sfm/bin/CIMUtil (CIMUtil is allowed only in ViPR SRM 3.5.1 or higher)
    Solaris
    sar, inq, powermt, vxdisk, mpstat

    Sample sudoers file for Linux OS

Back to Top

Configuring PowerBroker for host discovery

PowerBroker for UNIX & Linux allows system administrators to delegate UNIX and Linux privileges and authorization without disclosing passwords for root or other accounts. Administrators can add specific commands in the configuration/policy files to enable ViPR SRM to execute those commands and collect host information.

Procedure

  1. Include the path of the pbrun command in the environment variable $PATH for the powerbroker submit/run host.
  2. Include the paths of the OS commands in the environment variable $PATH for the pbrun user. By default, most of the command files have the following location:
    /usr/local/:sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
  3. Verify that the $PATH is correct.
    1. Log in to the submit/run host.
  4. Type "which pbrun".
  5. The configuration/policy files exist on the master host and they must include the pbrun user name and the associated commands for host discovery. The following screenshot displays the policy files for a configuration in which the master/submit/run host is on the same host:
    In this screenshot, the RootUsers variable includes "cmguser", which is the submit user (the ViPR SRM user used for discovering the host details) and the RootProgs variable includes the various commands required by ViPR SRM to discover the host. Note that the commands mentioned in the section about configuring sudo apply here as well.
Back to Top

Generating a public and private key pair for SSH key based authentication

For the SSH key method of discovering UNIX hosts, you must generate a valid public and private key pair. You can choose any key generation tool to generate a valid public and private key pair.

Before you begin

Before you begin host discovery, you must have a public key present on all the UNIX hosts that are to be discovered using the private key. You can create SSH keys in any Unix environment and import them onto the ViPR SRM collector. EMC recommends that you create public-private SSH keys on ViPR SRM collectors (Linux VMs) where host discovery will be initiated.

These steps describe the procedure to generate a public and private key pair for UNIX hosts using the ssh-keygen tool.

Note Image
The public key is to be added to the authorized_keys file on the target hosts intended for discovery and the private key is to be imported to the collector VMs where discovery is triggered.

Procedure

  1. A Public-Private key can be generated using the following command:
    ssh-keygen -t rsa -f <location_of_the_private_key/name_of_ private_key_file> -N ""

    For example: ssh-keygen -t rsa -f /root/.ssh/id_rsa -N ””

  2. Ensure that the public and private key pair that is generated has the following permissions:
    • chmod 600 /root/.ssh/id_rsa
    • chmod 644 /root/.ssh/id_rsa.pub
    The private key file is id_rsa.
    The public key file is id_rsa.pub.
  3. To make the key pair functional, append the public key to <user's home directory>/.ssh/authorized_keys in the target UNIX host using the command cat <location_of_the_public_key/name_of_public_key_file>>> /<user's home directory>/.ssh/authorized_keys
    For example: cat /root/.ssh/id_rsa.pub >> /<user's home directory>/.ssh/authorized_keys
    Next, import the private key to the Collector used for discovery.
Back to Top

Importing a private key into the Collector

Procedure

  1. Place the generated private key in the RSC conf folder /opt/APG/Collecting/Remote-Shell-Collector/<instance_of_collector>/conf
  2. Type chown apg:apg <private_key_file>
    This command changes the owner.
    The host is now ready for successful data collection.
Back to Top

Configuring SSH authentication

Modify the /etc/ssh/sshd_config file on SLES 11 SP3 to allow successful ssh authentication.

Procedure

  1. Change the following value to yes:
    #PasswordAuthentication no <--- original
    #PasswordAuthentication yes <--- modified
    Tunneled clear text passwords are disabled.
Back to Top

Configuring ESX hosts to collect PowerPath metrics

Provides information about configuring ESX host to collect PowerPath metrics.

Before you begin

  • Ensure that PowerPath/VE remote CLI (rpowermt) is installed on the host and enable performance collection by running the rpowermt set perfmon={on [interval=<#seconds>] | off} host=HOST_FQDN command.

    The EMC ViPR SRM Support Matrix provides more information on supported PowerPath versions.

  • Register ESX and enable performance for reporting.

    Refer to the Powerpath /Ve or Rtools documentation about how to register an ESX server and enable performance.

  • Configure the host where RTOOLS resides in generic-RSC based on the operating system type (ESX-LINUX or ESX-Windows).

To collect PowerPath metrics, do the following:

Procedure

  1. Create a lockbox.
  2. Update host username and password in the lockbox.

    The PowerPath/VE for VMware vSphere Installation and Administration Guide provides detailed description of performing the above steps.

    PowerPath reports can also be accessed from Explore View > Host > Storage Connectivity.

    PowerPath reports are available for the SolutionPack for IBM LPAR.
Back to Top

Configuring hosts to collect PowerPath metrics

Provides information about configuring host to collect PowerPath metrics.

To collect PowerPath metrics, do the following:

Procedure

  1. Install PowerPath CLI (powermt) on the host.
  2. Enable performance collection by running the powermt set perfmon={on [interval=<#seconds>] | off} command.
    Note Image
    The EMC ViPR SRM Support Matrix provides more information on supported PowerPath versions.

Back to Top

Installing the SolutionPack

Before you begin

The steps below assume a typical four server deployment: Primary Backend, Additional Backend, Collector, and Front End.

Procedure

  1. Click Administration.
  2. Click Centralized Management.
  3. Click SolutionPacks.
  4. Click SolutionPack Center.
  5. Select the SolutionPack in the Browse and Install SolutionPacks window.
  6. Click Install.
  7. Type the instance name.
  8. Assign a server for each component.
    In a typical four server deployment, the recommended servers are selected automatically.
  9. Click Next.
    The window displays a note about Alert Consolidation.
  10. If desired, select Enable the Host PowerPath Alerts.
  11. Click Next.
    The window displays reports settings.
  12. In Administration Web-Service Instance, select an existing instance or create a custom instance.
  13. Click Next.
    The window displays script settings.
  14. Select the performance metrics that you want to collect. Click Use advanced settings to configure the absolute paths of the binaries.
  15. Click Install.
  16. Click Ok when the installation is complete.
  17. Click Discovery Center > Devices Management.
  18. Click Host configuration.
    These steps describe how to add hosts individually. For information about using discovery groups to use the same credentials to discover multiple hosts, refer to the "Adding new devices" topic in the online help.
  19. Click Add new device.
  20. Select the server and collector instance where you want to store the configuration details for this device.
  21. Enter the hostname and OS type.
  22. From the Authentication Type drop-down menu, select:
    • Password based if you are using password based authentication.
    • Public key based if you are using key-based authentication.
  23. Provide the username (root or sudo user).
  24. If you are using password based authentication, provide the password for the host.
  25. If you are using key-based authentication, provide the absolute location of the private key:
    /opt/APG/Collecting/Remote-Shell-Collector/<instance_of_collector>/conf/<Name of private key>
  26. Type the network port.
  27. Click Test to validate the credentials.
  28. Click OK.
  29. Click Save.
  30. Add a new device for each host that will be discovered.
Back to Top

Adding hosts as part of groups in Discovery Center

Learn how to add hosts as part of groups in Discovery Center.

Procedure

  1. From Centralized Management, click Discovery Center > Discovery Center Backends.
  2. Select the Backend server.
  3. Click Register.
  4. Select the server you want to use for discovering the hosts.
  5. Click OK.
  6. Click Discovery Center > Devices Management.
  7. Click Host Configuration.
  8. Click the Discovery Groups tab.
  9. Click Add new Discovery group.
  10. Provide a name for the group and click OK.
  11. Click the newly created group.
  12. Under Credentials, click Add new entry.
  13. Type the username.
  14. Select the authentication type.
  15. If you are using password authentication, provide the password and click OK.
  16. If you are using key-based authentication, provide the absolute location of the private key and click OK.
  17. Repeat the previous five steps to add as many username/password (or key) combinations as you would like.
  18. Under Hostname or IP address, click Add new entry.
  19. Provide the Hostname/IP Address of the host and Network Port and click OK.
  20. Repeat the previous two steps to add as many hosts as you would like.
  21. Click Save.
  22. Click the Collected Devices tab.
  23. Click Discover.
  24. Select the Discovery group and Discovery Mode and click OK.
    The progress bar is displayed above the Collected Devices tab.
  25. When the progress bar is gone, click Discovery Results.
  26. Click the group name that you added.
  27. Under the group name, you can see the status of all the hosts that you added.
  28. Click Import to Collected Devices.
  29. Merge the devices if you want to retain older hosts that were added previously.
  30. Click OK.
  31. Select the action and click Continue.
  32. Click Save.

    All the hosts have been added to discovery

    Review your hosts and credentials to avoid lockout of hosts due to multiple attempts of incorrect credentials. EMC recommends that you create groups in such a way that hosts have a minimal set of credentials to be tried against. EMC recommends using common public-private key pairs for multiple hosts.

Back to Top

SolutionPack reconfiguration

If you want to change the answers that were provided during the SolutionPack installation, you can change them by reconfiguring the SolutionPack.

Procedure

  1. Click Administration.
  2. Under Centralized Management, click SolutionPacks > Independent SolutionPackBlocks and select the required instance.
    The SolutionPack Reconfiguration dialog box appears.
  3. Change the configuration as desired.
  4. Click Reconfigure.
Back to Top

Limitations

Learn about the limitations that apply to the SolutionPack for Physical Hosts.

Back to Top

Confirming report creation

After you install a SolutionPack, you can view its reports.

To view the reports:

Procedure

  1. Go to User Interface > Report Library.
  2. Click the SolutionPack to view its reports.

Results

It may take up to an hour to display all relevant information in these reports.

Back to Top

Troubleshooting

Report display problems

Back to Top

What to do if data does not appear in any reports

Procedure

  1. After the completion of at least three collection cycles, verify if data is populating into the reports. If there is still no data in the reports, continue to the next step.
  2. Run the scheduled task to import data into reports. If there is still no data in the reports, continue to the next step.
  3. To view the log files for errors, go to Centralized Management and click Collecting > Collector-Manager::<instance name> > Log Files.
Back to Top

Running a scheduled task to import data into reports

After you push a new configuration into a collector, a scheduled task runs and populates the reports with new data. You can manually run the scheduled task to import the data more quickly.

Before you begin

Allow at least three polling cycles to pass before manually running the scheduled task.

Procedure

  1. Click Administration.
  2. Click Centralized Management.
  3. Expand Scheduled Tasks.
  4. Click Database.
  5. Select the import-properties-Default task.
  6. Click Run Now.
  7. Confirm success in running the task in the Last Result and Last Result Time columns.
Back to Top

What to do if data does not appear in some reports

Procedure

  1. Run the scheduled task to import data into reports. If there is still no data in the reports, continue to step 2.
  2. Search for the metric in the database.
  3. To view the log files for errors, go to Centralized Management and click Collecting > Collector-Manager::<instance name> > Log Files.
Back to Top

Searching for metrics in the database

You can verify that a metric is being collected and used for reporting when you search and find the metric in the database.

Procedure

  1. Go to the Administration page.
  2. Under Modules, click Management of Database Metrics.
  3. On the Metric Selection page, create the filter, type the number of results, and select the properties to display for the metric.
    For example, to list up to 100 results of the Capacity metric with the properties of device and IP, type name=='Capacity' in the Filter field, 100 in the Maximum results field, and select device and IP for the Properties to show.
  4. Click Query.
    A list of the metric results appears. If nothing displays, the metric is not being collected.
Back to Top

Viewing collector errors in the Collector-Manager log files

Review the Collector-Manager log files to troubleshoot problems with data collection.

Procedure

  1. Click Administration.
  2. Click Centralized Management.
  3. Expand Collecting.
  4. Click the Collector-Manager for your collector instance.
    Collector-Manager::<Collector-Manager instance> - <host_ID>
  5. Expand Log Files and click the View File icon to review the configuration error messages.
Back to Top