BMC Performance Assurance Virtual Servers

www.bmc.com

BMC Performance AssuranceImplementation Guidefor Virtual Systems

Supporting

BMC Performance Assurance, version 7.5.10BMC Capacity Management, versions 8.1.00 and 8.2.00

April 2011

Contacting BMC Software

You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information about the company, its products, corporate offices, special events, and career opportunities.

United States and Canada

Address BMC SOFTWARE INC2101 CITYWEST BLVDHOUSTON TX 77042-2827 USA

Telephone 713 918 8800 or800 841 2031

Fax 713 918 8000

Outside United States and Canada

Telephone (01) 713 918 8800 Fax (01) 713 918 8000

© Copyright 2011 BMC Software, Inc.

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners.

IBM, AIX, WPAR, LPAR, DLPAR, SPLPAR, PowerVM, Power5, Power6 and others are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both.

IT Infrastructure Library® is a registered trademark of the Office of Government Commerce and is used here by BMC Software, Inc., under license from and with the permission of OGC.

ITIL® is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office, and is used here by BMC Software, Inc., under license from and with the permission of OGC.

Linux is the registered trademark of Linus Torvalds.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

UNIX is the registered trademark of The Open Group in the US and other countries.

The information included in this documentation is the proprietary and confidential information of BMC Software, Inc., its affiliates, or licensors. Your use of this information is subject to the terms and conditions of the applicable End User License agreement for the product and to the proprietary and restricted rights notices included in the product documentation.

Restricted rights legendU.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC SOFTWARE INC, 2101 CITYWEST BLVD, HOUSTON TX 77042-2827, USA. Any contract notices should be sent to this address.

Customer support

You can obtain technical support by using the BMC Software Customer Support website or by contacting Customer Support by telephone or e-mail. To expedite your inquiry, see “Before contacting BMC.”

http://www.bmc.com

3

Support website

You can obtain technical support from BMC 24 hours a day, 7 days a week at http://www.bmc.com/support. From this website, you can

■ read overviews about support services and programs that BMC offers■ find the most current information about BMC products■ search a database for issues similar to yours and possible solutions■ order or download product documentation■ download products and maintenance■ report an issue or ask a question■ subscribe to receive proactive e-mail alerts when new product notices are released■ find worldwide BMC support center locations and contact information, including e-mail addresses, fax numbers, and

telephone numbers

Support by telephone or e-mail

In the United States and Canada, if you need technical support and do not have access to the web, call 800 537 1813 or send an e-mail message to [email protected]. (In the subject line, enter SupID:<yourSupportContractID>, such as SupID:12345). Outside the United States and Canada, contact your local support center for assistance.

Before contacting BMC

Have the following information available so that Customer Support can begin working on your issue immediately:

■ product information

— product name— product version (release number)— license number and password (trial or permanent)

■ operating system and environment information

— machine type— operating system type, version, and service pack or other maintenance level such as PUT or PTF— system hardware configuration— serial numbers— related software (database, application, and communication) including type, version, and service pack or

maintenance level

■ sequence of events leading to the issue

■ commands and options that you used

■ messages received (and the time and date that you received them)

— product error messages— messages from the operating system, such as file system full— messages from related software

http://www.bmc.com/support

mailto:[email protected]

4 BMC Performance Assurance Implementation Guide for Virtual Systems

License key and password information

If you have questions about your license key or password, use one of the following methods to get assistance:

■ Send an e-mail message to [email protected].

■ Use the Customer Support website at http://www.bmc.com/support.

mailto:[email protected]

http://www.bmc.com/support

Contents 5

ContentsChapter 1 Introduction to Virtual Systems 9

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Overview of VMware virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Overview of Microsoft virtualization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Overview of AIX hardware partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Overview of HP virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Overview of Oracle Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Introduction to BMC Performance Assurance for Virtual Servers . . . . . . . . . . . . . . . . 16

Chapter 2 Implementing Performance Assurance in a VMware Environment 19

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Benefits of using BMC Performance Assurance in this environment . . . . . . . . . . 20

Installation and configuration considerations for a VMware environment . . . . . . . . 21Installation notes for a VMware environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Overview of implementation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Setting up VMware ESX and vCenter Server proxy data collection . . . . . . . . . . . . . . 22Methods of collecting data from ESX servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Requirements for VMware ESX and vCenter Server proxy hosts . . . . . . . . . . . . . 24Configure a VMware ESX proxy host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Configure a vCenter Server proxy host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Collecting data from a Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Viewing results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Displaying VMware in Analyze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Displaying VMware CPU Usage in Visualizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Displaying VMware CPU Use in Perceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48FAQs for CPU reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Modeling a VMware Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Working with VMware systems in Predict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61View the Predict report for VMware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Performing “What if...?” investigations of VMware systems . . . . . . . . . . . . . . . . . 66FAQs for Predict Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Evaluating the virtual environment in Perceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Step 1: View overall guest activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Step 2: Identify guests of interest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Step 3: Review resource utilization for a guest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Step 4: Explore guest activity on a single Virtual Host . . . . . . . . . . . . . . . . . . . . . . 92

6 BMC Performance Assurance Virtual Systems Implementation Guide

Chapter 3 Implementing Performance Assurance in a Microsoft Virtual Environment 97

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Support for Microsoft Virtual Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Support for Hyper-V (Microsoft 2008 Virtualization Server) . . . . . . . . . . . . . . . . . 98

Installation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Installation considerations for a Microsoft Hyper-V environment . . . . . . . . . . . . 99Installation considerations for a Microsoft Virtual environment . . . . . . . . . . . . . 100

Managing performance of a Microsoft Virtual Server . . . . . . . . . . . . . . . . . . . . . . . . . 101Collecting and processing data from a Microsoft Virtual Server . . . . . . . . . . . . . 101

Viewing the results for Virtual Server data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Viewing Virtual Server CPU Usage in Visualizer . . . . . . . . . . . . . . . . . . . . . . . . . . 108Viewing Virtual Server data in Perceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Managing performance in a Microsoft Hyper-V environment . . . . . . . . . . . . . . . . . . 110Setting up data collection for Hyper-V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Viewing results for a Hyper-V environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Viewing Hyper-V CPU usage in Visualizer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Viewing Microsoft Hyper-V results in Perceiver . . . . . . . . . . . . . . . . . . . . . . . . . . 113Virtualization Planning support for MS Hyper-V . . . . . . . . . . . . . . . . . . . . . . . . . 126

Chapter 4 Implementing Performance Assurance on an AIX System with Hardware Partitions 127

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Support for AIX hardware partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Support for AIX workload partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Installation Considerations for AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Installation considerations for AIX hardware partitions . . . . . . . . . . . . . . . . . . . . 129Installation considerations for AIX workload partitions . . . . . . . . . . . . . . . . . . . . 130

Configuration Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Enable Remote Command Execution on the HMC. . . . . . . . . . . . . . . . . . . . . . . . . 131Configuring the AIX Environment using the Perform Configuration File . . . . . 132Manually configuring the AIX Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Verify that the HMC was added to the list of known hosts . . . . . . . . . . . . . . . . . 135

Managing the performance of AIX hardware partitions . . . . . . . . . . . . . . . . . . . . . . . 136Collecting data from AIX hardware partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Displaying data from AIX Partitioned Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Viewing AIX partition metrics in Investigate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Key Analyze reports to review for AIX partitions . . . . . . . . . . . . . . . . . . . . . . . . . 140Displaying AIX hardware partition CPU usage in Visualizer . . . . . . . . . . . . . . . 144Displaying AIX hardware partition CPU use in Perceiver . . . . . . . . . . . . . . . . . . 146

FAQs for CPU reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147How does SMT affect the number of CPUs? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Where do I start? What view is "correct"? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148How do I interpret the name of the physical system? . . . . . . . . . . . . . . . . . . . . . . 160When I look at "per processor" usage, it's very uneven. Why? . . . . . . . . . . . . . . . 160When I look at "per logical processor" usage, it's very uneven. Why? . . . . . . . . 162

Modeling AIX partitioned systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Evaluate the model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Contents 7

Review the Physical System Summary report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Perform “What if...?” investigations of AIX partitioned systems . . . . . . . . . . . . 167Scenario for modeling data from an AIX partition. . . . . . . . . . . . . . . . . . . . . . . . . 168Additional scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170FAQs for Predict Modeling of AIX partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Managing the performance of workload partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Collecting and processing data from a workload partition . . . . . . . . . . . . . . . . . 181Viewing metrics in Investigate from a workload partition . . . . . . . . . . . . . . . . . . 188Displaying WPAR CPU Use in Perceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Displaying AIX partitions with Live Partition Mobility . . . . . . . . . . . . . . . . . . . . 191

General FAQs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193What are best practices for performance reporting and analysis for the AIX

environment?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Chapter 5 Implementing Performance Assurance on HP Systems with Hardware Partitions 197

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Support for hardware partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Support for HP Integrity VM systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Installation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Installation considerations for HP-UX partitions . . . . . . . . . . . . . . . . . . . . . . . . . . 200Installation considerations for HP Integrity VM systems . . . . . . . . . . . . . . . . . . . 200

Managing the performance of HP-UX partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201Data collection considerations for HP hardware partitions . . . . . . . . . . . . . . . . . 201Displaying data from HP hardware partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Modeling HP-UX virtual systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Overview of HP Integrity VM systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

HP IVM Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212Data collection considerations for HP IVM systems . . . . . . . . . . . . . . . . . . . . . . . 213

Displaying data from HP IVM partitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213Viewing HP IVM metrics in Investigate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214Viewing HP IVM data in Visualizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Viewing HP IVM data in Perceiver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217Viewing HP IVM data in Analyze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Virtualization Planning support for HP IVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Reporting capacity usage for HP IVM systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227Reporting CPU for a HP IVM system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228Reporting CPU allocation for a HP IVM system . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Modeling HP IVM systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Implementation of best practices for HP IVM modeling and reporting . . . . . . . 229Evaluate the Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231Review the Physical System Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232Perform “What if...?” investigations of HP IVM partitioned systems. . . . . . . . . 234Modeling process summary of HP IVM systems . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Chapter 6 Implementing Performance Assurance on a Oracle PartitionedSystem 237

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238


Support for Solaris Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Support for Solaris Dynamic System Domains (DSDs) . . . . . . . . . . . . . . . . . . . . . 239Support for Solaris Logical Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Installation considerations for Solaris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240For installing in Solaris 10 environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240For installing in Solaris DSD environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240For installing in Solaris LDom environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Managing performance of Solaris Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Collecting and processing data from Solaris Container systems . . . . . . . . . . . . . 241Displaying data in Visualizer for Solaris Container systems . . . . . . . . . . . . . . . . 249Displaying data in Perceiver for Solaris Container systems . . . . . . . . . . . . . . . . . 251Finding out more using Investigate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Managing performance of Oracle partitioned (DSD) systems. . . . . . . . . . . . . . . . . . . 257Displaying Data in Analyze from Oracle Partitioned Systems . . . . . . . . . . . . . . . 257Modeling Data from a Oracle Partitioned Environment . . . . . . . . . . . . . . . . . . . . 257

Managing performance of Oracle Logical Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Displaying data in Investigate from Oracle LDoms . . . . . . . . . . . . . . . . . . . . . . . . 259Displaying Oracle LDom CPU usage in Visualizer . . . . . . . . . . . . . . . . . . . . . . . . 259Displaying Solaris LDom CPU Use in Perceiver. . . . . . . . . . . . . . . . . . . . . . . . . . . 260Modeling data from a Oracle LDom environment . . . . . . . . . . . . . . . . . . . . . . . . . 262Managing performance with Chip Multi-Threading . . . . . . . . . . . . . . . . . . . . . . . 265Modeling an UltraSPARC processor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

Chapter 7 Implementing Performance Assurance on Xen Systems 269

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269Support for Xen nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270Benefits of using BMC Performance Assurance in this environment . . . . . . . . . 270

Installation and configuration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271Collecting and processing data from Xen systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

How do I collect and process the data? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271Viewing results in Analyze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279Viewing results in Perceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

Xen Partition Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281Xen Host Summary by Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285Xen Partition Summary by Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

Modeling Xen servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289Working with Xen systems in Predict. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289View the Predict report for Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292Virtualization Planning support for Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

Index 295

Chapter 1 Introduction to Virtual Systems 9

C h a p t e r 11 Introduction to Virtual Systems

This chapter presents the following topics:

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Overview of VMware virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Overview of Microsoft virtualization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Overview of AIX hardware partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Overview of HP virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Overview of Oracle Partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Introduction to BMC Performance Assurance for Virtual Servers . . . . . . . . . . . . . . . . 16

Overview Many companies are using virtualization and partitioning technologies to create application servers that can share physical resources to reduce hardware costs, enhance scalability, and simplify systems management. In effect, these are virtual systems that appear to be isolated from other servers that share the underlying hardware. You can create a virtual system by using virtualization software, such as VMware on Intel-based hardware platform, or by using hardware partitions in UNIX environments.

In a VMware or Microsoft Virtual Server environment, a physical system hosts a group of logical systems, or virtual machines. Operating systems and applications are configured to run inside a virtual machine that is managed by the Host Server. This approach allows system resources to be dynamically allocated to any of the virtual machines based on need, providing mainframe-class capacity usage and control of server resources.

In a typical UNIX hardware partitioned system, each operating system image has hardware associated with it. This hardware includes the CPU, memory, I/O ports, and network interface card. The operating system runs on the partitioned system, and the applications run inside each image of the operating system. The hardware partition essentially provides the separation of the operating system images.

Overview of VMware virtualization


You can then change the resources allocated to each operating system image by moving the resources between the partitions or reassigning them within the physical machine. Some vendors also provide the capability for dynamic partitions and partitions that share resources.

The chapters in this book explain how to implement BMC Performance Assurance in each of the following virtual system environments:

■ VMware■ Microsoft Virtual Server and Microsoft 2008 Virtualization Server (Hyper-V)■ IBM AIX ■ HP-UX■ Oracle Solaris

The following sections provide some background information for each of these environments.

Overview of VMware virtualization

VMware ESX Server runs directly on the hardware, offering the greatest performance and finest resource controls. The ESX Server is a scalable architecture that is well suited for enterprise deployments.

The VMware ESX Server product enables physical systems to host a group of logical systems, or VMware ESX Virtual Machines (VMs). Operating systems and applications are configured to run inside a VM that is managed by the Host Server, which is a complete physical system (i.e. CPUs, disks, memory, NICs, and so on). To the operating system, the VM acts like a standalone computer. This approach allows system resources to be dynamically allocated to any of the VMs based on need, providing mainframe-class capacity usage and control of server resources.

Each VM (also referred to as a VM session) can run Microsoft Windows or Linux operating systems as guest operating systems.

The VMware Virtual Infrastructure manages system hardware and the VMs running on the server. It runs directly on the system hardware to provide a secure, uniform platform for deploying, managing, and remotely controlling multiple VMs. This layer presents a uniform hardware environment to each of the guest operating systems.

TIP Keep in mind when moving any virtual system from one physical system to another in Predict, that you can move systems only within the same physical system type. For example, a a VMware virtual machine can be moved only to another VMware host, not to an AIX server.

Overview of Microsoft virtualization


The VMware vCenter Server (formerly VMware VirtualCenter) provides a scalable platform that enables IT administrators control the virtual environment. It provides virtualization management by centrally managing VMware servers and VMs.

Overview of Microsoft virtualization

BMC Performance Assurance supports the following types of Microsoft virtualization:

■ Microsoft Virtual Server 2005 ■ Microsoft 2008 Virtualization Server (Hyper-V)

Microsoft Virtual Server 2005

Microsoft Virtual Server 2005 runs on Microsoft Windows Server 2003, which is the host operating system. You can create virtual machines that can run other operating systems (including Microsoft Windows and Linux), called the guest operating system. Microsoft Virtual Server 2005 enables the virtualization of multiple server instances on a single hardware platform running Microsoft Windows Server 2003.

In this environment, BMC Performance Assurance identifies the physical system configuration, including all the guests, the operating systems running inside the guests, and the resource usage (such as processors and network). The Analyze component reconciles the collected data and produces Visualizer files to output the results to Visualizer, which can be viewed by Visualizer or BMC Performance Perceiver.

Microsoft 2008 Virtualization Server (Hyper-V)

Microsoft Windows Server 2008 supports server virtualization with an operating system feature called Windows Server 2008 Hyper-V.

With Hyper-V uses hypervisor-based server virtualization technology, which consolidates multiple server roles as separate virtual machines running on a single physical machine. You can run multiple operating systems (Windows and Linux) in parallel, on a single server.

Overview of AIX hardware partitions

AIX hardware partitions (previously called Advanced Power Virtualization or APV) enable IBM hardware to support AIX, Linux and IBM partitions, where BMC Performance Assurance supports AIX and Linux.



With the introduction of AIX version 5.3, there are three types of logical partitions that can be implemented on servers built on POWER5 (p5) and POWER6 (p6) architecture:

■ dedicated processors assigned to AIX Logical Partitions (LPARs)■ Dynamic Logical Partitions (DLPARs)■ AIX systems running in shared processor logical partitioned mode (SPLPARs) on

IBM p5 and p6 servers with Micro-Partitioning.

With the introduction of AIX 6.1, the software-based Workload Partitions (WPARs) can be created on any p5 and p6 hardware that supports the operating system.

Type of hardware partitions

The following table offers basic explanations of each of these partition types:

Table 1 Types of AIX hardware partitions (part 1 of 2)

Partition type Description

LPAR Logical partition

Introduced with AIX 5.1 and POWER4 servers. In an LPAR configuration, hardware resources are divided into partitions where the resources assigned to that partition are dedicated to that partition. Each LPAR must have at least one CPU, 1GB memory, and one I/O adapter. This partition type is static: you cannot change the allocation of resources for the partition without bringing down the operating system.

DLPAR Dynamic logical partition

Introduced with AIX 5.2, a DLPAR configuration enables the addition or removal of resources (for example CPUs, adapters, or memory) without rebooting the operating system or partition. This configuration improves system availability as well as resource utilization.

As with an LPAR, the hardware resources in a DLPAR are divided into partitions where the resources associated with the partition are used only by that partition. Each DLPAR must have at least one CPU, 1GB memory, and one I/O adapter. This partition type is dynamic: the allocation of resources to the individual partitions can be changed on demand, while the AIX system image is running.



Workload Partitions (WPARs)

Introduced with AIX 6.1. A WPAR is a software-created virtualized OS environment within a single AIX V6 image. Each workload partition is a secure and isolated environment for the application it hosts. WPARs can be considered as a boundary around a set of AIX processes. The application in a WPAR thinks that it is being executed in its own dedicated AIX instance.

WPAR is a purely software partitioning solution that is provided by the operating system. It has no dependencies on hardware features. You can create WPARs within an AIX6 LPAR. This type of configuration has the advantage of flexibility to create new isolated application environments without creating and managing new AIX logical partitions.

The Role of the Hardware Management Console

The Hardware Management Console (HMC) is a standalone Intel system that runs a modified version of the Linux operating system. The main task of the HMC is to run a graphical user interface that provides management tools for controlling one or more partition-capable servers and the partitions associated with those servers. The HMC provides tools for managing complex system configurations, including a mix of static and dynamic logical partitions, as well as clusters of virtual servers. IBM does not recommend that you install any applications on the HMC.

SPLPAR Shared processor logical partition

Introduced with AIX 5.3 and the POWER5 micro-partitioning technology, you can create virtual servers for the AIX system in an SPLPAR configuration. The allocation of these resources can be changed dynamically while the AIX system image is running, enabling you to adjust physical resources to meet changing workload requirements.

The processor resources are allocated as sub-units of processing power, known as a Processing Unit (PU) that can span multiple physical CPUs. This enables the physical CPUs to act as a shared pool of CPUs. This shared pool of CPUs acts as a 'virtual' CPU, which provides multiple operating system threads for the partitions.

To create this type of partitioned environment, you first create the shared pool of dedicated processors. You then create the SPLPAR inside the shared pool of processors, assigning a number of virtual processors (in 0.1 PU increments) to each SPLPAR. This value is the entitlement for each partition. The entitlement defines the amount of CPU capacity each partition can use.

Table 1 Types of AIX hardware partitions (part 2 of 2)

Partition type Description

Overview of HP virtualization


The use of partition mobility

With Live Partition Mobility, you can move running partitions (and their hosted applications) from one physical server to another, without disrupting infrastructure services. Partition mobility enables you to be more proactive in managing the AIX virtual environment; you can rebalance the load across systems by moving running partitions and applications from systems that are under a heavy workload to other, less-constrained systems. BMC Performance Assurance version 7.5 supports AIX Live Partition Mobility. When moving partitions between physical computers, BMC Performance Assurance follows the movement and monitors the partition in its new location.

Overview of HP virtualization

On HP systems, there are various types of partitions: physical partitions (nPars), virtual partitions (vPars), and Integrity Virtual Machines (Integrity VMs).

nPars and vPars

On an nPar, the software running on the nPar exclusively uses all the processors, memory, and I/O associated with the physical machine. Each nPar has its own system boot interface and each nPartition can be started and stopped independently.

A vPar is another configuration option supported on HP systems that you can use to subdivide server resources into multiple, smaller virtual partitions through the use of software partitioning. Each vPar runs its own instance of the HP-UX operating system and has its own dedicated hardware resources. A vPar can be reconfigured and can dynamically reallocate certain processors among other vPars on the local nPartition.

A HP partition-capable server can be configured in three ways:

■ Multiple nPars running on a server, with each nPar running one instance of the HP-UX operating system.

■ Multiple vPars running directly on a server, with each vPar running one instance of the operating system.

■ Multiple nPars running on a server, some of which have vPars configured. Each non-virtual-partitioned nPar runs one instance of the HP-UX and each vPar in the nPar runs one instance of the operating system.

Overview of Oracle Partitions


In both the nPar only and vPar examples, all of the partitions are actual systems that can be started and stopped. In the vPar on an nPar scenario, the nPar is no longer a discreet system, as the resources it contains are allocated to the virtual partitions; it cannot run an instance of the operating system.

The following table lists the BMC Performance Assurance support for each hardware partition platform.

Integrity VMs

HP Integrity VM is a virtualization technology that provides operating systems isolation and supports shared processors. A single HP Integrity server running Integrity VM can support multiple guest instances on the server, each with its own separate guest operating system.

Integrity VM runs only on HP Integrity servers, and supports several operating systems as guests (for example, HP-UX, Microsoft Windows Server, and RedHat Linux).

Overview of Oracle Partitions

Oracle offers several partitioning environments:

■ Hardware partitions known as Dynamic System Domains (DSDs), which are implemented on the SunFire architecture of servers.

■ Partitions known as Containers, or zones, available on Solaris 10 systems.

■ Solaris LDom

Dynamic System Domains (DSDs)

Each physical SunFire system can support multiple partitions, or DSDs, enabling companies to consolidate workloads onto a single server, for example, thereby lowering costs and simplifying system management.

Hardware Platform Supported for vPar Supported for nPar Supported for IVM

PA-RISC ■ HP-UX 11.11■ HP-UX 11.31

■ HP-UX 11.11■ HP-UX 11.31

Not supported

Itanium Not supported ■ HP-UX 11.23■ HP-UX 11.31

■ HP-UX 11.31

Introduction to BMC Performance Assurance for Virtual Servers


Resources can be re-allocated across individual DSDs without rebooting the partitions, enabling mission-critical applications to continue running while the computing environment is being upgraded.

BMC Performance Assurance supports Solaris Dynamic System Domains as implemented on the SunFire architecture (SunFire 12K, 15K, 20K, and 25K) with a System Controller running System Management Services software version 1.3, 1.4.1 or later, under a limited support agreement. Since the SunFire architecture provides a variety of site-specific configurations, BMC Software will provide this support on a case-by-case basis with the specified customer.

Solaris 10 Containers (Zones)

Oracle's Solaris operating system version 10 provides a method of virtualization by creating zones inside the operating system image. These zones act as independent nodes within the operating system image, which is referred to as the global zone. Applications running within discreet zones are isolated from each other.

A global zone may contain many zones referred to as non-global zones. Global and non-global zones share one copy of the Solaris 10 operating system, running in the global zone.

Solaris LDoms

Logical domains (LDoms) enable you to create virtual machines that take advantage of the large thread scale offered by the CoolThreads server platforms. With LDoms, the logical processors are associated with threads and threads are associated with specific cores. With LDoms you can create up to 128 virtual servers on one server.

Logical domains speed deployment, reduce disk capacity requirements, and create higher availability domains (using redundant virtual networks and disks). You can also reallocate resources such as CPU, virtual disks, and virtual networks on the fly to meet the demands of the workloads and services running in the LDom.


BMC Performance Assurance is an integrated set of products that monitor, measure, evaluate, predict, and report the performance of distributed systems. BMC Performance Assurance supports the collection, analysis, and modeling of kernel-level system data.



BMC Performance Assurance is the premiere product for comprehensive performance management of virtualized server environments.

BMC Performance Assurance offers the following capabilities in environments that are moving towards virtualization:

■ Help identify candidates for virtualization (before deployment)■ Help identify candidates for consolidation■ Manage host-system and virtual machine performance (after deployment)

This guide describes how to implement BMC Performance Assurance in the various Virtual Server environment.

NOTE Analyzing and modeling data collected from the virtual system environments described in this book use the version 7.5.00 BMC Performance Assurance Console on Microsoft Windows. Similar support is available on UNIX consoles.


C h a p t e r 22 Implementing Performance Assurance in a VMware Environment


Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Benefits of using BMC Performance Assurance in this environment . . . . . . . . . . 20

Installation and configuration considerations for a VMware environment . . . . . . . . 21Installation notes for a VMware environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Overview of implementation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Setting up VMware ESX and vCenter Server proxy data collection . . . . . . . . . . . . . . 22Methods of collecting data from ESX servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Requirements for VMware ESX and vCenter Server proxy hosts . . . . . . . . . . . . . 24Configure a VMware ESX proxy host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Configure a vCenter Server proxy host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Collecting data from a Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Viewing results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Displaying VMware in Analyze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Displaying VMware CPU Usage in Visualizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Displaying VMware CPU Use in Perceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48FAQs for CPU reporting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Modeling a VMware Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Working with VMware systems in Predict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61View the Predict report for VMware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Performing “What if...?” investigations of VMware systems . . . . . . . . . . . . . . . . . 66FAQs for Predict Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Evaluating the virtual environment in Perceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Step 1: View overall guest activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Step 2: Identify guests of interest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Step 3: Review resource utilization for a guest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Step 4: Explore guest activity on a single Virtual Host . . . . . . . . . . . . . . . . . . . . . . 92

Overview


OverviewWith BMC Performance Assurance, you can manage the performance of VMware ESX servers. You can analyze performance information for the virtualized systems (Windows and Linux) and obtain a system-level view of the VMware ESX server for server sizing, management, and daily reporting. BMC Performance Assurance provides the ability to collect VMware ESX server configuration and system-wide statistics, analyze this data with the Analyze component, and report on the data using the Investigate and Visualizer components.

For an overview, refer to Overview of VMware virtualization” on page 10.

Benefits of using BMC Performance Assurance in this environment

BMC Performance Assurance can help manage the performance of each VM and report the appropriate performance data for the VMware server.

Performance data collected from within the VM's operating system may be used to display the “relative” resource usage of individual processes. All VMs share system resources, so obtaining accurate measurements of total actual resource usage is necessary to provide a complete picture of system usage.

With BMC Performance Assurance, you configure a Perform Agent running on a Microsoft Windows computer or in a VM as a VMware proxy data collector. After it is configured, this proxy data collector collects both total and per VM resource usage for one or more VMware host servers. This information is used to create system-level views to support analysis of individual VM usage and to assist performance analysts and planners in determining when and how to deploy individual VMs.

NOTE Analyzing and modeling data collected from the virtual system environments described in this book use the version 7.5.10 BMC Performance Assurance console on Microsoft Windows. Similar support is available on UNIX consoles.

Installation and configuration considerations for a VMware environment


Installation and configuration considerations for a VMware environment

Installation notes for a VMware environment

You install the Perform Agent shipped with the BMC Performance Assurance product on a Microsoft Windows server (running .NET Framework 2.0 service pack 1 or later), and configure the computer to act as a VMware proxy host. The proxy host collects data remotely from other VMware ESX servers (version 3.0 and later). This method provides a robust list of metrics for both the host servers and the VMs running on those servers.

For more information, see Install and configure the proxy host” on page 25 and the Implementing Proxy Data Collection appendix in the BMC Performance Assurance Getting Started guide.

Overview of implementation process

To implement BMC Performance Assurance in a VMware environment, you must:

■ Select a Microsoft Windows server to act as a VMware proxy host computer.

■ Run the installation program according to the instructions in BMC Performance Assurance Getting Started guide, installing the Perform Agent on the selected Microsoft Windows server.

■ Configure the VMware proxy host according to the instructions in the Configure the VMware ESX proxy host in Perform Agent” on page 28 section and in the Implementing Proxy Data Collection appendix in the BMC Performance Assurance Getting Started guide.

WARNING Do not install the Perform Agent on the VMware service console operating system (Red Hat Linux).

Setting up VMware ESX and vCenter Server proxy data collection


Setting up VMware ESX and vCenter Server proxy data collection

Setting up a proxy host to collect data from ESX servers is similar to setting up a Windows proxy host. However, in the case of ESX server data collection, you have two options to choose from. You can configure the proxy host to collect data from vCenter Server, or directly from the ESX servers. These two options differ in the methods they use to collect data, and in the information needed to set up the proxy hosts. Investigate history is disabled by default for both methods of collection.

Methods of collecting data from ESX servers

There are two methods for collecting data from VMware ESX servers:

1. VMware ESX server: The proxy host collects data from individual ESX servers, and can also collect cluster and pool data from vCenter Server. This method:■ requires you to configure a user account with read privileges on every ESX

server from which you want to collect data■ requires you to configure a Windows user account (domain or local) with read

privileges for vCenter Server, if you want to collect cluster and pool data■ requires Level 3 in vCenter Server in order to collect certain cluster and pool

data (for specifics see, “Set the VirtualCenter statistics level”)■ provides default 1-minute sampling frequency that enables you to view real-

time data through Investigate

2. vCenter Server: The proxy host collects data only from vCenter Server. In this method, a single master collector collects all the configuration metrics that have changed since the last sampling and the 20 second real-time performance data for all the hosts, VMs, clusters and resource pools from a single vCenter. The master collector then summarizes the multiple real-time data points into one data point over the sampling interval based on the data type and places the results into the shared memory. If the default 15 minute sampling interval is used, the master collector will summarize 45 real-time data points into one. Each vCenter proxy collector responsible for an ESX host goes into the shared memory and pick up the data related to the host. This method:■ requires you to configure a Windows user account (domain or local) with read

privileges only on vCenter Server■ enables you to collect cluster and pool data without reconfiguring the level■ provides default 15-minute sampling frequency that can be reduced to 5-

minutes, which is too low to view real-time data through Investigate

Methods of collecting data from ESX servers


Table 2 on page 23 shows the differences in the two methods and demonstrates the advantages of using the vCenter Server to collect data. BMC Best Practices recommends using only vCenter Server to collect data from ESX servers.

Table 2 Methods for collecting data from VMware ESX servers

Feature ESX Host Data Collection vCenter Data Collection

Configuring collection ■ Requires you to configure a user account with read privileges on every ESX server from which you want to collect data.

■ In addition, requires you to configure a user account with read privileges on vcenter to collect cluster and resource pool details.

Requires you to configure a user account with read privileges on vcenter server only.

Availability Host and guest metrics will be available as long as the host is up and running. Collection is not impacted by the connectivity to vCenter except for cluster and resource pool information.

Depends solely on the connectivity to vCenter. No data will be collected if vCenter is down; there is a single point of failure.

Collection granularity The default is 1 minute for host/VM and 15 minutes for cluster/pool.

The default is 15 minutes.

vCenter 'Level' for data collection

Performance metrics for Cluster and resource pool are available only if the vCenter is at level 3 or above.

Collection from vCenter is not affected by the level set in vCenter. All metrics are available.

Supported metrics Same set of configuration and statistical metrics as vCenter data collection.

Same set of configuration and statistical metrics as ESX host data collection.

Supportability metrics No specific supportability metrics available.

■ Collector will record vCenter connection failure status in the 'collector information' metric group.

■ Collector records ESX host status to the 'VMware Host Configuration' metric group.

■ Data availability metric in udr provides the number of seconds for which data is available for the spill interval

■ In the database , field "collector_type" in the Agent table identifies the kind of collection (ESX or vCenter).

Requirements for VMware ESX and vCenter Server proxy hosts


Requirements for VMware ESX and vCenter Server proxy hosts

Prior to collecting VMware data using a proxy host, you must meet the requirements described in the following sections:

■ Verify the version of VMware■ Verify the version of Microsoft .NET Framework■ Install and configure the proxy host

Verify the version of VMware

To collect VMware data using a proxy host, the agentless ESX servers must be running VMware ESX 3.0 or later.

Performance & Scalability ■ Very limited additional system resources needed

■ BMC recommends limiting to collecting to a maximum of 100 VMware hosts per proxy host.

■ Very limited additional system resources needed

■ BMC recommends limiting to collecting to a maximum of 150 VMware hosts per proxy host.

Use Cases ■ Investigate - Sampling interval of 1 minute will make the data refresh much slower than OS collectors that have 10 sec sampling

■ PrintUDR - works as before■ Analyze & Predict - works like

other platforms , no change to the workflow

■ Investigate - not recommended for real-time monitoring■ The default of 15 minute

sampling is not very useful for the real-time investigate use case

■ PrintUDR - works as before ■ Analyze & Predict - works like

other platforms, no change to the workflow. Must have 7.5.10 console to process vCenter data.

WARNING The only supported data collection method for VMware ESX 3.5/4.0 and 3.5i/4.0i is a VMware ESX or vCenter Server proxy host. Local installation on a VMware ESX 3.5/4.0 Service Console is not supported due to a known defect in the VMware Perl Scripting API, which prevents data collection using a locally installed Perform Agent on VMware ESX 3.5/4.0. There is also a known memory leak in the VMware Perl Scripting API.

Table 2 Methods for collecting data from VMware ESX servers

Feature ESX Host Data Collection vCenter Data Collection

Configure a VMware ESX proxy host


Verify the version of Microsoft .NET Framework

The computer that you are configuring as the VMware ESX or vCenter Server proxy host must be running Microsoft .NET Framework version 2.0 or later. The proxy host uses the VMware Web Service API in the Microsoft .NET Framework to collect data from the ESX servers.

Install and configure the proxy host

You must install Perform Agent on a Microsoft Windows computer and configure it to be the VMware ESX or vCenter Server proxy host.

■ For a VMware ESX proxy host see, Configure a VMware ESX proxy host” on page 25.

■ For a vCenter Server proxy host see, Configure a vCenter Server proxy host” on page 30


The following sections describe the procedure for setting up a VMware ESX proxy host.

Obtain a user account to connect to the ESX servers

Before you can configure the proxy host in Perform Agent, you must first obtain a user account to connect to the ESX servers.

Remote access to ESX servers requires a user account with privileges to connect and query the VMware Virtual Infrastructure (VMware VI) web service. If the account you are using is not a root or vpxuser account, you must grant the account read privileges. Granting a non-admin account the privilege to connect and query the web service is described in the following procedure.

To grant account privileges on VMware

1 Start the VMware Infrastructure Client and log on to the ESX server.

2 Select the ESX host.

3 Select the Permissions tab in the right panel.

4 Right-click the context menu and select Add Permissions.



5 In the Assign Permissions dialog box, click Add.

6 Select the account you want to use in the list and click Add.

7 Click OK.

8 Ensure that the account is using at least the Read-Only role to provide adequate permissions.

9 Click OK to finish.

Obtaining VMware ESX server accounts using esxUser

You can also use a command line tool (esxUser.exe) to manage the VMware VI user account remotely on a Windows computer. This tool requires .NET 2.0 or later and VMware related DLLs (VimService2005.dll and VimService2005.XmlSerializers.dll) to run (any system qualified as VMware or vCenter proxy host meets this requirement).

To run EsxUser.exe to obtain user accounts

1 When running this tool without any argument, the following is displayed:

Figure 1 esxUser.exe command line window

2 Use command line switches to perform operations on the VMware ESX server:

Table 3 esxUser.exe command line switches

Switch Description

/list List all VMware VI accounts for an ESX server

/add Create a read-only VMware VI account

/grantRead Grant a local account with the read privilege to the VMware VI objects

/deprive Remove the privilege from a VMware VI account



Obtain a user account to connect to vCenter Server

If you want to configure the proxy host to collect cluster and pool data from vCenter Server, you must obtain a Windows domain or local account that has (at least) read privileges for vCenter Server.

Set the VirtualCenter statistics level

If you want to collect all of the cluster and pool data available from the ESX servers, you must set the VirtualCenter statistics level to 3. The following two lists of metrics will not be collected unless VirtualCenter statistics is at level 3.

Cluster Level

Resource Pool Level

/rm Delete a VMware VI account from the ESX server

<logon user> User account name used to access web service

<password> User account password used to access web service

NOTE VMware does not recommend changing the vCenter statistics level to 3. According to VMware, "Level 1 has very low overhead on both the VirtualCenter server as well as the ESX Server hosts. Levels 2 - 4 have slightly greater overhead on ESX, but can adversely impact VirtualCenter performance if there are more than 10 ESX Server hosts." For more information see http://www.vmware.com/pdf/vi3_monitoring_statistics_note.pdf.

■ CPU Usage ■ Mem Usage■ CPU MHz Usage■ Mem Swap Used■ Mem Granted■ Mem Shared

■ Mem Active■ Mem Zero■ Mem Vmmemctl■ Mem Consumed■ Mem Overhead

■ CPU MHz Usage■ Mem Granted■ Mem Shared■ Mem Active■ Mem Zero

■ Mem Vmmemctl■ Mem Consumed■ Mem Overhead■ Mem Swapped

Table 3 esxUser.exe command line switches

Switch Description

http://www.vmware.com/pdf/vi3_monitoring_statistics_note.pdf



Configure the VMware ESX proxy host in Perform Agent

PATROL - Perform Agent must be installed on each computer you want to use as a proxy host. This procedure assumes you have already completed the tasks described in “Preparing for proxy data collection” section in the Implementing Proxy Data Collection chapter of the BMC Performance Assurance Getting Started guide.

1 Click the VMware Proxy tab in PATROL - Perform Agent.

2 Click Add New to configure a new domain for proxy collection. The Logical Domain Setup dialog box appears.

3 In the Logical Domain field, enter the name of the domain from which the proxy host will collect data. The domain can have any unique name. It is used to group all of the agentless ESX servers together.

4 Select Enable this domain to include the domain in the proxy collection.

5 Specify the following information in the ESX Server Account Information area:

■ User Name: Name of the user account that will be used to manage the ESX servers. The account must have (at least) Read permissions in order for the VMware VI objects to collect data from the ESX servers. (By default, only root and vpxuser have this privilege on the ESX servers.)

■ Password and Confirm Password: The password associated with the user name.

6 In Agentless ESX Server Configuration, select one of two discovery methods for locating ESX servers.

■ Use ESX Server List - Uses the list of ESX servers configured in the agentlessComputers.cfg file. For information on populating this file see, the “Preparing for proxy data collection” section in the Implementing Proxy Data Collection chapter of the BMC Performance Assurance Getting Started guide.

■ Discover from the VC - Uses the list of ESX servers discovered via a vCenter server if it is defined for the logical domain. If you select this option and do not specify a vCenter, no ESX server will be returned for discovery.

NOTE The VC Account button that was available in 7.5.00 is not available in 7.5.10.



7 Click Apply to save your changes. A message appears notifying you that the user information has been created in the registry. Click OK. The Edit List button becomes available.

8 Depending on the option you chose in step 6, click Edit List if you want to:

■ Edit the agentlessComputers.cfg file. For instructions about editing the file, see the “Preparing for proxy data collection” section in the Implementing Proxy Data Collection chapter of the BMC Performance Assurance Getting Started guide.

■ Specify the vCenter Server machine that will supply the list of ESX servers and the data related to clusters and resource pools. For further instructions, see the following procedure, “To specify a vCenter Server machine.”

9 Click Exit to close the Logical Domain Setup dialog box and return to the VMware Proxy tab. The new domain appears in the Logical Domain Setup list.

10 You can add additional domains or click OK to exit PATROL - Perform Agent. A message appears asking you to wait while the agent is being restarted. A second message appears stating that the restart was successful. Click OK again. PATROL-Perform Agent Setup closes.

If for any reason it is not successful, you must restart the application manually (from Start => Settings => Control Panel => PATROL - Perform Agent).

To specify a vCenter Server machine

1 From within the Logical Domain Setup dialog box, click Edit List.

2 In Virtual Center List Setup dialog box you can specify one vCenter Server machine for each logical domain. Enter the following account details:

■ Virtual Center: Name of the vCenter Server machine from which you want the list of ESX servers and data related to clusters and resource pools.

■ User Name: Name of the user account used to access vCenter Server.

NOTE Regardless of the option you use, you have to define a vCenter in order to collect cluster and resource pool data.

NOTE In7.5.10 no more than one vCenter can be defined for any logical domain, while in 7.5.00 multiple vCenters can be defined for a logical domain.

Configure a vCenter Server proxy host



3 Click Add to save your settings. A message appears asking you to wait while the account information is being verified. A second message appears informing you that the account information has been created. Click OK.

4 Click Exit to return to the Logical Domain Setup dialog box.

Configure a vCenter Server proxy host

The following sections describe how to set up a vCenter Server proxy host.

Obtain a user account to connect to vCenter Server

Before you can configure the proxy host in Perform Agent, you must first obtain a Windows domain or local account that has (at least) read privileges for vCenter Server.

Configure the vCenter Server proxy host in Perform Agent

PATROL - Perform Agent must be installed on each computer you want to use as a proxy host. This procedure assumes you have already completed the tasks described in “Preparing for proxy data collection” section in the Implementing Proxy Data Collection chapter of the BMC Performance Assurance Getting Started guide.

1 Click the vCenter Proxy tab in PATROL - Perform Agent.

2 Click Add New to configure a new domain for proxy collection.

3 In the vCenter Setup dialog box, select Enable this vCenter for data collection to include vCenter Server in the proxy collection.

4 Specify the following domain information in the vCenter Account Information area:

■ vCenter Name: Name of the vCenter Server machine from which the proxy host will collect data.

■ User Name: Name of the Windows domain or local account that will be used to access vCenter Server.


Collecting data from a Virtual Machine


5 (optional) Select Use the Configuration File instead of the vCenter to Discover and Collect Data from the ESX Servers, to collect data only from those ESX servers listed in the agentlessComputers.cfg file. (See the “Preparing for proxy data collection” section in the Implementing Proxy Data Collection chapter of the BMC Performance Assurance Getting Started guide).

6 (optional) Click Edit Configuration File to open the agentlessComputers.cfg file for editing.

7 Click Apply to save your changes. A message appears asking you to wait while the account information is being verified. A second message appears informing you that the account information has been created. Click OK.

8 Click Exit to return to the vCenter Proxy tab. The new vCenter Server proxy appears in the vCenter Setup list.

9 You can add additional vCenter Servers or click OK to exit PATROL - Perform Agent. A message appears asking you to wait while the agent is being restarted. A second message appears stating that the restart was successful. Click OK again. PATROL-Perform Agent Setup closes.

If for any reason the restart is not successful, you must restart the application manually (from Start => Settings => Control Panel => PATROL - Perform Agent).

Collecting data from a Virtual MachineTo collect VMware data using the proxy host, create a Manager run that specifies the proxy host domain and the proxy host computer that will initiate data collection.

These data collection methods are fully described in the BMC Performance Assurance for Microsoft Windows Implementation Guide for Microsoft Windows, or by referring to the online Help.

NOTE BMC Best Practices recommends using vCenter Server to discover and collect data from the ESX servers.

NOTE The vCenter Server name listed here is treated the same as the domain for a Windows or VMware ESX proxy.



The following tasks describe the recommended process for collecting and processing data from VMware systems.

Task 1: Set up a policy that includes the target VMware systems

To collect data automatically using a Manager script you must have an Investigate policy. The following steps describe the basic process for creating a policy. See the Investigate online Help for assistance with wizard screens or dialog boxes.

1 In the Investigate snap-in, right-click Policies and select New Policy. This starts the New Policy Wizard.

2 On the Welcome page, enter a name for the policy and accept the default location for the console data repository. The default location is C:\Program Files\BMC Software\Patrol3\BEST1\NTC\Repository. Click Next. This starts the New Computer wizard.

3 Make sure discovered from network is selected in the drop-down list, and then click the Discover/Add button.

4 On the Discover Computers window, specify an IP address range and click Start Discovery.

The discovery process could take a while depending on the number of computers in your network. After it is complete, you will have a list of all computers within the specified IP address range. You can sort by column headings. For example, if you only want to collect data from computers with the 7.5.10 Agent installed, click the Agent Version column head. This sorts the discovered computers by Agent version. You can then easily select computers with the 7.5.10 Agent for collection. Alternatively, you can select non-7.5.10 computers and delete them from the list.

Task Refer to

Create a policy that includes the VMware Host Server. page 32

Set up an Automator script. page 33

Set up and schedule the Manager script. page 34

Verify the data collection and processing. page 36

NOTE The tasks described in the following sections are for the Windows version of the BMC Performance Assurance console. Similar support is available for the UNIX console. For instructions on how to complete these tasks using the UNIX console, see BMC Performance Assurance Implementation Guide for UNIX.



5 Click the Agent Version column to sort by Agent type.

6 Highlight the computer you are interested in and click the Add button. To select more than one computer, hold down the Shift key when making your selections.

7 Click OK.

8 On the Computers to Add to Policy window, click the check-boxes to select the individual computers from which to collect data.

9 Click OK to save the policy.

Remember the file name and the location, as you will need this information as you build the Manager script.

Task 2: Set up the Automator script

To automatically populate the data you collect into a Visualizer database, you must first set up an Automator script. Review the default scripts available in Automator and tailor them for your use, depending on how often you want to populate the data into the Visualizer database.

For more information, refer to the Visualizer online Help or the Visualizer Implementation Guide.

1 From the Automator File menu, choose one of the default scriptname.b1a files to open the Select a Database from the Catalog dialog box.

— New Daily Script (daily.b1a)— New Weekly Script (weekly.b1a)— New Monthly Script (monthly.b1a)

2 Select one of the databases from the Database selection list. When you click OK, Visualizer creates a script and names it with capital letters.

TIP If you have installed the Perform Agent and system collector on one or more VMs, group the Host Server and other instrumented VMs in the same policy.

TIP Run your script against a small or duplicate database first, previewing and testing it before running it against the production database.



For example, if you select demo.b1a, after you click OK, the newly created script is named DEMO.B1A.

3 Review the events in the script and modify as necessary. To change an event, highlight the event line in the script. Then do one of the following:

— Choose Edit => Modify.— From the keyboard, press Alt+Enter.

4 Choose Run => Preview Mode.

5 Choose Run => Script Now. Click Yes when you see the following prompt.

6 Review the log and correct any errors in the script.

7 From Automator, choose File => Save As.

The script is now available to be included in the Manager script.

Task 3: Set up and schedule the Manager script

To collect data using the Manager snap-in on the BMC Performance Assurance console, you must create a script or use an existing one. The steps in this section show how to create a script. You must also create a policy or use an existing one. These steps assume the use of the default policy provided with BMC Performance Assurance console. See Task 1: Set up a policy that includes the target VMware systems” on page 32.

1 Right-click the Manager snap-in, right-click Scripts, and choose New Script from the menu. This starts the New Script Wizard. Read the Welcome page and click Next to proceed to the Manager Script File Name page.

2 Enter a name for your script. Use the default folders provided, unless you have set up alternative locations for script files and reports. Click Next.

3 On the Operation window, select Collect New Data. Leave the default selection of System and applications data.

4 Click Add to browse to the policy that has the computers you identified in Task 1: Set up a policy that includes the target VMware systems” on page 32. On the Select Policy File window, select the policy file and click Open.

Preview mode is enabled ¨C the database will not be alteredin any way. Are you sure you want to preview the script:scriptname now?



5 On the Operation window, click Next. The Analyze and Predict window is displayed. The Analyze and Predict window lets you decide how you will use the data that you collect. You can generate reports for Analyze, Predict, and Applications (if you selected that option on the previous window). You can also generate Visualizer files and create workload characterization files.

6 Set the Analyze and Predict window options:

— Leave the Generate reports for... options blank. — Accept the default values for the Generate Visualizer files section.— Accept the Default workload characterization file option. — Click Next.

7 On the Collect or Analyze Interval window, use the up and down arrows in the From and To fields to establish the collection interval.

BMC Software strongly recommends that you enable a gap of five to ten minutes between the current Collect request end time and the next collect request start time to allow the existing VMware collectors to exit completely before the new collectors start in the Manager run. An example you could specify a Manager run from 12:00 a.m. to 11:55 p.m. This prevents intense resource contention that can cause the collector to fail.

8 Select the time zone, and then click Next. Changing the time zone setting might be necessary if data is being collected from computers that are in time zones that differ from the time zone of the console computer.

9 On the Automator Script Option window, click Browse. Use the Automator Script Option page to specify the Automator script to be executed during the Manager run. Automator is a Visualizer tool that runs user-built scripts to populate a Visualizer database. The Automator script you specify will use Visualizer files you generated with Predict and Analyze to populate the Visualizer database. (See the Visualizer Implementation Guide for information about using Automator scripts.)



10 On the Select Automator File dialog, browse to the Automator script you created in Task 2: Set up the Automator script” on page 33, and then click Open.

11 On the Automator Script Options window, click Next.

12 On the Schedule a run of the script window, select the Schedule the script to run checkbox. Click the up and down arrows to set the time to run the script. Set the recurrence options for the script in the Run script section.

13 Click Finish to save the script and set the schedule.

Task 4: Verify the data collection

Using the Manager component has the added advantage of allowing you to view collection status with the Status Report feature.

To access the Status Report:

1 In the BMC Performance Assurance console scope pane, open the Manager snap-in.

2 Click Status Report.

The Perform - Data Collection Status opens in the results pane. The available Manager scripts are in the left portion of the report.

To view the status of data collection, click on a script. You can also click Schedule in the scope pane to display the scripts in the results pane. Then right-click on the script for which you want to view reports and select View Status Report.

Viewing results


See the online help, available from the help button on the top right portion of the Status Report, or refer to the appendix on Troubleshooting Tools in the BMC Performance Assurance Getting Started for more information about using these reports.

Viewing resultsYou can access performance data about the VM sessions by using any of the following components, using the Perform Microsoft Windows console:

■ Investigate■ Analyze■ Visualizer■ Perceiver

For Investigate, refer to the online Help to create drill-downs on the VMware sessions or the Host Server. For more information, refer to the chapter on VMware metrics in BMC Performance Assurance System Metrics for Microsoft Windows and UNIX, Volume Two.

The following sections describe how to display and interpret the data using Analyze, Visualizer, and Perceiver.

Displaying VMware in Analyze

Analyze has five reports that present information specific to VMware, including configuration and resource consumption:

■ VMware Summary■ VMware Memory■ VMware Disk■ VMware Network■ VMware Per Processor

In these reports, each VM is identified by its display name used by VMware, and the guest operating systems are also displayed. Each operating system instance, including the VMware service console operating system, is shown as an independent computer. For more information about these reports, refer to the Analyze online Help.



First, you must create a workload characterization file that includes the VMware service console, and optionally the virtual machines, as computers. An Analyze workload characterization contains parameters for

■ Creating a performance model for use by Predict ■ Viewing charts of performance data ■ Creating performance reports■ Creating input files for Visualizer

When you run Analyze, it uses the workload characterization to evaluate collected performance data, and create a performance model, reports, and, optionally, Visualizer input files.

To generate the VMware reports, perform the following steps:

1 Right-click Analyze in the Tree view, and choose Open Workload Characterization.

2 Choose the appropriate workload characterization (.an) file for the VMware system.

3 Review the displayed interval or set another interval.

4 Run Analyze by clicking on the green arrow in the menu bar, or right-click on the Workload Characterization in the Tree view and choose Start Analyze.

5 Expand the Reports item and then expand the VMware selection.

The following sections discuss the various VMware reports.

VMware Summary Report

Use this report to view summary information for the VMware service console and the VMs (identified by display name) for the system, as shown in Figure 2.



Figure 2 Analyze VMware Summary Report

The following table describes each of the columns in the report. You may need to scroll to the right to see some of the report columns.

Column Description

VMware Console Name

The name of the VMware service console that provides all of the management functions for the VMs. For reporting purposes, this name is used to refer to the physical host machine.

Display Name This value is used to refer to the VM. Each VM is identified by its display name specified in the VMware configuration file. The display name is not guaranteed to be unique on the VMware server. BMC Performance Assurance does not support duplicate VM display names within a VMware server. VMs with the same display name are treated as one.

Guest OS The operating system type installed as a guest OS on the VM. Each VM can run Microsoft Windows or Linux as guest OSs.

Physical Procs The number of physical processors on the ESX server system. This value is shown only for the top-level server information.

Logical Procs The number of logical processors on the ESX server system. This value is shown only for the top-level server information.

Virtual Procs The number of CPUs allocated to the VM. This value is shown for each VM.

System Service The total reported overhead usage for all VMs, due to virtualization. The CPU utilization attributed to the VMware host on behalf of the VMs.



VMware Memory Report

Use this report to view memory statistics for the VMs (identified by display name) as shown in Figure 11.

CPU Util The percentage of CPU time used by a VM. The CPU usage shown in this column is a physical value; it represents the total CPU usage of the amount of CPU that has been allocated for the VM.

CPU Shares The number of CPU shares assigned to a VM.

CPU Min The guaranteed minimum CPU percentage reserved for this VM.

CPU Max The maximum CPU percentage for a VM. The valid range of values is from zero (“0”) to the number representing the total physical CPU resources. The maximum may be greater than 100 for SMP virtual machines that may use more than one full physical CPU.

CPU Ready The percentage of time during the measurement session that the VM was ready to process transactions, but could not get scheduled to run on a physical CPU.

CPU Effective The percentage (out of 100%) of the maximum physical CPU resource allocated to the VM that it is currently using.

Total Memory The amount of RAM (in MB) for the physical machine. This value is shown only for the top-level VMware service console row.

Shared Memory The memory required for single copy of memory shared between VMs.

Swapped Memory The sum of all currently swapped memory for running VMs. This value is equivalent to swapout-swapin.

Guest Memory Config

Amount of memory allocated for the VM (in MB).

Column Description



Figure 3 Analyze VMware Memory Report

The following table describes each of the columns in the report:

Column Description

VMware Console Name


Display Name This value is used to refer to the VM. Each VM is identified by its display name specified in the VMware configuration file. This display name is not guaranteed to be unique on the VMware server. BMC Performance Assurance does not support duplicate VM display names within a VMware server. Virtual machines with the same display name are treated as one.

Memory Shares The total number of memory shares assigned to a VM.

Shared Memory The amount of memory in MB that is shared through transparent page sharing either within a VM or with other VMs running on the same server.

Memory Used The amount of memory in MB actively used by a VM.

Overhead Memory

The overhead memory in MB for the VM.

Memory Swap In The amount of memory swapped in to the VMFS partition swap file for a VM.

Memory Swap Out

The amount of memory swapped out to the VMFS partition swap file for a VM.

Swapped Memory The amount of memory swapped into and out of the VMFS partition swap file for a VM.



VMware Disk Report

Use this report to view disk statistics for the VMs (identified by display name) as shown in Figure 4.

Figure 4 Analyze VMware Disk Report


Column Description

VMware Console Name


Display Name This value is used to refer to the VM. Each VM is identified by its display name specified in the VMware configuration file. This display name is not guaranteed to be unique on the VMware server. BMC Performance Assurance does not support duplicate VM display names within a VMware server. Virtual machines with the same display name are treated as one.

Disk Name The host target logical unit number (LUN) for the disk.

Disk Shares The number of disk shares assigned to a VM on the target device specified by the host target LUN.

Disk Reads The number of disk reads (per second) for a VM on the target device specified by the host target LUN.

Disk Read in KB The amount of data read (per second) for a VM on the target device specified by the host target LUN.



Figure 5 VMware Storage Architecture

VMware Per Processor Report

Use this report to view CPU utilization information (per processor) for the system, as shown in Figure 6.

Disk Writes The number of disk writes (per second) for a VM on the target device specified by the host target LUN.

Disk Writes in KB The amount of data written in KB (per second) for a VM on the target device specified by the host target LUN.

Column Description

Displaying VMware CPU Usage in Visualizer


Figure 6 Analyze VMware Per Processor Report



To view VMware data from Visualizer, complete the following steps:

1 Click Database=>Select and select the database into which you populated the VMware data.

2 Click Database=>Detail and choose the data for the graph. Ensure that you select ESX from the Virtual Type drop-down list.

Column Description

VMware Console Name

The name of the VMware service console that provides all of the management functionality for the virtual machines. The service console OS in the VMware ESX Server is based on Red Hat version 7.2. The service console runs as another guest OS but has access to the VMware kernel to perform management functions.

CPU Number Each virtual machine on the system is identified by a number.

CPU Util The percentage of CPU time used by the physical machine, broken down by processor.

CPU Idle Time The percentage of time the CPU is idle.



3 From the Graphics menu, choose VMware => VMware Host/VM.

Figure 7 VMware Host/VM Graph

4 Double-click the row representing the service console to see the bar chart that shows the physical CPU usage, by VM, on the server.



Another graph to look at is the VMware CPU by Host/VM graph. An important metric to view in this report is %Host.

1 From the Graphics menu, choose VMware => VMware CPU by Host/VM graph.

Figure 8 VMware CPU Use Hierarchy

2 Right-click the graph and select the %Host view to see the view of CPU consumption across all virtual machines, relative to the capacity of the entire system.

3 From the Graphics menu, select VMware => VMware Cluster/Host. This graph shows the resource consumption of all the hosts running under a cluster for the selected set of clusters.



Figure 9 VMware Cluster/Host

4 From the Graphics menu, select VMware => VMware Cluster/Host/VM. This graph shows the resource consumption of all the hosts running under a cluster and all the VMs running under that host for the selected set of clusters.

Figure 10 VMware Cluster/Host/VM

Displaying VMware CPU Use in Perceiver


5 From the Graphics menu, select VMware => VMware Cluster/Resource Pool/VM. This graph shows the resource consumption of all the Resource pools configured under a cluster and all the VMs running in that resource pool for the selected set of clusters.

Figure 11 VMware Cluster/Pool/VM


You can also use BMC Performance Perceiver to view performance data for VMware servers and VMs.

The CPU Profile view (Figure 12) under VMware Host Summary by Resource shows a VMware host along with the VMware Virtualization layer.



Figure 12 CPU Profile from the VMware Host Summary by Resource

If you select a host, you get the following table and charts:

For more information on Perceiver views and metrics, see the “Evaluating the virtual environment in Perceiver,” section in this guide, refer to the online Help, or the BMC Performance Perceiver Getting Started Guide.

Metric Description

CPU Utilization by VM Displays the physical CPU capacity used by each VM as a percentage of the physical processors in the server and normalized to a maximum of 100%.

CPU User by VM Displays percentage of CPU used by each VM when the processor is executing in user mode, calculated based on the number of physical processors in the host.

CPU System by VM Displays the percentage of CPU used by each VM when the processor is executing in system mode, calculated based on the number of physical processors in the host.

Virtual CPU Capacity Used

Displays the percentage of (virtual) CPU used by each VM in this host calculated based on the number of Virtual CPUs configured for the VM.

Virtual Processors Configured by VM

Displays the number of virtual processors that are configured for all the virtual machines for the selected host.

CPU Rating Used Displays the host capacity with respect to spec rating for the selected VMware host.

FAQs for CPU reporting



As an analyst you are likely to start with CPU reporting.

Where do I start with CPU reporting?

There are two possible perspectives on a VMware system:

■ overall host/physical system and ■ individual virtual machines.

The first perspective is the only view which allows you to see the entire environment and assess overall capacity consumption. Any of the VMware Visualizer graphics can be used to display this view. Analyze and Predict VMware Summary reports contain similar information, as do the VMware views in Perceiver. For CPU reporting reports and views already described in this chapter see:

■ Analyze■ Analyze VMware Summary Report” on page 39

■ Predict■ Predict VMware Summary report” on page 65

■ Visualizer■ VMware Host/VM Graph” on page 45■ VMware CPU Use Hierarchy” on page 46■ VMware Cluster/Host” on page 47■ VMware Cluster/Host/VM” on page 47■ VMware Cluster/Pool/VM” on page 48

■ Perceiver■ CPU Profile from the VMware Host Summary by Resource” on page 49

The number of processors being used as the host capacity is the number of physical processors. The number of logical CPUs are also reported (e.g. Hyper-threaded_Processors), but are not used as a basis for available CPU capacity. The number of physical processors can be viewed in a couple of VMware graphics, but again, here's how this information is displayed in the customized VMware CPU Use Hierarchy graphic shown in Figure 8 on page 46.

The 400 %Physical_Max indicates that 4 Physical_Processors (7.5 equivalent is Host Processors) are configured throughout this day. And this maximum applies to the entire host, and thus is the overall perspective applied to each virtual machine.



Figure 13 VMware CPU Use Hierarchy

However, the VMware CPU Use Hierarchy does not show how the individual VMs are performing. The overall physical system view shows relative consumption of the CPU by each, but it doesn't relate it to their allocations of CPU capacity. Thus, another view is needed for this, describing how much is each VM is using with respect to its allocated capacity. Again, the customized VMware CPU Use Hierarchy graphic can be used to see how much of each VM's total virtual processing (%Virtual_Used or in the non-customized graphic, %VProc) capacity is in use. See Figure 14 on page 52.



Figure 14 Selected VMware CPU Use Data

An integrated view of the VMware host using Visualizer is also available, simultaneously showing both allocations—Physical processors (total for the system) and Virtual processors (for that virtual machine)—and what portion of the allocated capacity is in use. Metrics of interest in this graph (Figure 15 on page 53) are % Virtual and % Host. See also, Figure 37 on page 90. which shows similar information in a Perceiver view.



Figure 15 VMware CPU Host % Capacity Used

Another useful view is across all virtual machines within a host system. This graphic, VMware CPU VM % Capacity” on page 54, shows total physical processor capacity utilized, and average virtual utilization. metrics are % Virtual and % Host.

Also, using this graphic over time, either for individual virtual machines or for the host system as a whole, provides a complete overview of what's happening and what the long-term trends are. Of course you can drill down as appropriate to find out what the underlying cause is for a significant change in utilization. Similar charts are available in Perceiver, including Virtual CPU Capacity Used chart” on page 94.



Figure 16 VMware CPU VM % Capacity

Details of how CPU performance is affected by the particular combination of resources, VM resource demands, and VM configuration parameters are reported by the customized VMware CPU Use Hierarchy graphic (see VMware CPU Use Hierarchy” on page 51) as well as the default Visualizer graphic, VS, VMware CPU Use Hierarchy.



Figure 17 Selected VS, VMware CPU Use Data

In this graph:

■ %Ready is the percentage of time during the measurement session that the VM was ready to process transactions, but could not get scheduled to run on a physical CPU

■ Degrd_VM is the percentage of CPU response time due to competition from other VMs

■ Degrd_All is the percentage of CPU response time due to competition within the VM and between this VM and other VMs

In this example, the degradation percentage is very small, so there is very little wait introduced due to competition for CPU resources.

This information is also presented for 7.5 Visualizer databases (via the VMware CPU Host/VM graphic), with some differences:

■ % Ready has been normalized to 100%, so that VMs with different virtual processor configurations can be directly compared with each other ■ the underlying CPU measurements are highlighted in VMware CPU States

Cluster/Host/VM graphic■ values for individual VMs can be displayed for one (or more) hosts using

VMware CPU by VM % Ready

■ values for individual VMs can be displayed for one (or more) clusters using ■ Degradation reporting requires a console patch and updated vgd file



What other views of ESX CPU can I use?

Metrics are also available at the cluster and pool level.

In Visualizer, see:

■ VMware CPU Use Hierarchy” on page 46■ VMware Cluster/Host” on page 47■ VMware Cluster/Host/VM” on page 47■ VMware Cluster/Pool/VM” on page 48

In Perceiver see:

■ VMware Cluster Summary - Cluster Overview■ VMware Cluster Summary - Resource Usage by Host■ VMware Cluster Summary - Resource Usage by Virtual Machine■ VMware Resource Pool Summary - Resource Pool Overview■ VMware Resource Pool Summary - Resource Usage by Virtual Machine.

Why is there a difference between Cluster CPU and Memory Utilization reported by 7.5.10 and the 7.5.00 views?

Beginning with Release 7.5.10, metrics are available directly for the cluster and are presented in:

■ VMware Capacity Cluster: reports cluster CPU and Memory configured and used, as well as remaining capacity projections in %, number of additional VMs, amount of additional work that could be supported; also reports the average VM resource consumption

■ VMware Balance Cluster/Host: reports how well-balanced the CPU and Memory load is across hosts within the cluster; also reports the average VM resource consumption

NOTE The degradation percentages are calculated by Predict, so will not appear in these graphics if Predict response times have not been requested as part of Manager processing. These percentages are also output during interactive modeling,



Cluster utilization is obtained directly from the VMware API, which documents that cluster utilization includes all of the VM activity, but no "overhead" activity . This would be the same as the results obtained from summing all of the VMs, such as shown in:

■ VMware CPU Cluster/Host/VM : reports VM use and configuration, aggregating to both the host and cluster levels (examples shown above); reporting as %, GHz, processors, queue length

However, resource utilization metrics can also be reported for the cluster by summing the activity for the hosts in that cluster, as shown in the following views11:

■ VMware CPU Cluster/Host: reports host and cluster CPU configured and used■ VMware CPU Capacity Cluster/Host: reports host and cluster CPU usage as %,

GHz, SPEC, as well as remaining capacity projections

This method depends on having all hosts within the cluster properly instrumented with collectors, but has the advantage that both VM and overhead activity is accounted for.

So any report based on the directly available values for the cluster (or the sum of the VMs) will understate current total utilization and thus overstate available capacity. The exact amount can be determined by using any of the 7.5.00 views, and comparing them with the 7.5.10 views. For example, the summed view reports almost 50% cluster CPU utilization where the directly available cluster metric only reports about 30% CPU utilization.

Figure 18 Summed view vs. directly available cluster metric



In addition, you can report on exactly what the breakdown is between overhead and the VMs using other alternatives such as VMware CPU Cluster/Host: Overhead Processors or VMware Virtualization Overhead Cluster/Host: % CPU. Host utilization obtained by summing the VMs would be similarly affected.

What about the view from inside a Virtual Machine?

The second possible perspective is that from within an individual virtual machine. Unlike an OS like AIX which was specifically instrumented for virtualization, the versions of Linux and Windows which are currently available to run under VMware are not. Specifically this means that performance metrics which are time-based can be misleading; for example, CPU utilization. This is one of the important factors to consider when making a decision about which virtual machine(s) should have traditional system collectors deployed (in addition to the VMware host collector). Metrics such as I/O rate are unaffected by virtualization.

Another potentially important consideration is the performance cost to run the collector, usually estimated to be in the 3 - 5% range per collector. If there are more than 20 virtual machines, this level of overhead could be unacceptable, i.e. 20 * 3-5%.

Also, if a collector is deployed on an otherwise idle virtual machine, the periodic demands of the collector can generate possible performance degradation for active virtual machines.

In summary, collectors should be deployed selectively on virtual machines. They are needed when having process-level data is important. In other words, if there aren't multiple applications running in the virtual machine, a system collector is probably not necessary.

After the system collector has been deployed on one or more virtual machines, probably the most sensible processing would be to group the System Services and other instrumented virtual machines in the same domain/policy.

All of the traditional reports and Visualizer graphics are available for performance analysis activities.

When interpreting performance metrics from within a virtual machine, here are a few pointers:

NOTE Remember that the host-level (for example, outside) view is only available from reports and graphics labeled with "VMware", and that all other reports and graphics show the view from inside the virtual machine(s) which have been instrumented with a system collector .

In general, the metrics from inside a virtual machine and at the host level (e.g. outside) will not agree due to the virtualization considerations described above.



(a) if there is very little competition for resources among virtual machines, the data will represent reality - if there is a lot of competition, data accuracy will be affected

The classic example of this is that if a virtual machine requires 25% of a CPU, but there are other virtual machines competing with it, the virtual machine will report 100% CPU utilization (instead of 25%), because it is using the CPU during all of the time allotted to it.

(b) when viewing process data directly or indirectly (via transactions/workloads), process metrics may be differentially affected by virtualization. This means that as competition among virtual machines increases, some processes will have their CPU more overstated than other processes . And this means that precise breakdown of CPU utilization across workloads cannot be determined. You can still identify which applications are running in the VM, just not exactly how much resource each is consuming.

Figure 19 on page 59 shows an example of comparing the outside and inside view for selected guest on an ESX server. The top graphic shows the outside view, i.e. how much of the total host CPU is utilized, which is about 40% across all guests. The bottom graphic shows the inside view, which is what does the guest OS think its utilization is, which is 100% for two guests, and around 5% for the other two guests. The two guests showing 100% for the inside view are using around 10% in reality.

Figure 19 Comparison 1 - outside and inside view for selected guest



Figure 20 on page 60 shows more outside views of what's really happening. The heaviest usage VMs are not coming close to their virtual processor allocation, using only about 20 and 30% of virtual capacity (top graphic). But competition for CPU is clearly evident in the bottom graphic, which shows %Ready as around 75% for both VMs.

Figure 20 Comparison 2 - outside and inside view for selected guest

When I look at "per processor" usage, it's very uneven. Why?

Per processor usage for the host level is reported by

■ Analyze: VMware Per Processor report ■ Visualizer: VMware CPU Host per Processor and VMware CPU Host % per

Processor graphics■ Perceiver: VMware Views, VMware ESX per CPU Statistics

The most likely explanation is that Processor 0 is used exclusively for System Services, and if that work consumes a lot of CPU, the relative CPU utilization of Processor 0 will reflect that.

Modeling a VMware Server


How does Hyper-Threading affect the number of CPUs? Will I see double the number of processors I really have?

Hyper-threading does double the number of processors reported on under VMware. BPA presents the total number of processors as logical processors. Note also that VMware is instrumented with virtual-aware CPU accounting for Hyper-threading, so the sum of all processor time does not exceed the number of physical processors.

However, CPU utilization for all other performance objects (VM, ESX host, ESX cluster) should always be viewed with respect to physical processors, which is presented consistently in the graphics shown in Where do I start with CPU reporting?” on page 50. CPU queue length is also expressed relative to the number of physical processors.

The Predict model always presents the physical processor view.

Modeling a VMware ServerUsing Predict to model a VMware system can help you decide which virtual machines on the VMware server affect overall performance. You can use this information to experiment with different configurations of VMware servers and virtual machines to see how to achieve the best mix. You can also use the Scenario Planner capability to perform long-term capacity planning.

See the online help for detailed, step-by-step procedures for using the windows, menus, and dialog boxes of the Predict user interface.

Working with VMware systems in Predict

The following sections describe how to prepare the model for “What if...?” analysis.

Identify the VMware hosts and VMs

The VMware Host Server is displayed at the same level as a standalone computer. The virtual machines associated with the VMware Host Server are displayed at a secondary level to the Host Server, as shown in Figure 21.



Figure 21 VMware icon in Predict

The host view is prefixed with VH to identify it as the Virtual Host. Any VMs which are instrumented (have the Perform Agent and collector installed on the OS) are displayed as standalone computers.

Evaluate the Model

After you open the model, you must evaluate it to obtain the performance metrics calculated by Predict. When you evaluate the model, Predict displays information and any errors while the model is being evaluated.

When you click the Evaluate model icon, Predict evaluates the model, produces reports concerning the performance of the system represented by the model, and displays more information about the model components.

Your next step is to examine the components in the model to

■ verify or correct the information in the model■ identify any resources that might be exceeding your service level objectives. The

guideline and threshold apply only to the VMware ESX Host Server.

For more information on calibrating the model and creating a valid baseline, refer to the Predict online Help.

Display the properties of the VMware system

Right click on the VMware Host Server, or the virtual machine icon. Select Properties and then click the Configuration tab to display the system attributes. The following table identifies the attributes available for each type of system.

TIP A model containing a VMware ESX Host Server and its associated VMs is much like a model containing physical machines. You can change the VMware host or VM configuration settings (such as CPU, memory, CPU shares, and so on), prior to baselining.



Figure 22 shows the Properties for a VMware Host Server.

Figure 22 Properties page for a VMware system

For either the VMware host or the VM itself, you can click the Virtual System Allocation button on the Configuration tab to see how the system resources are being allocated across the VMs, as shown in Figure 23. You can reassign the physical system resources among the virtual machines using this dialog box.

Type of system you are viewing

Key attributes shown on the Configuration tab for that system type

VMware Host Server Host name (using the VMware console OS name), CPU model, the number of physical processors, and memory size.

Virtual machines Display name, number of processor configured, memory size configured, CPU share and measured CPU utilization (in X*100% where X is number of processors configured). The VMware Host Server name is also displayed.

View the Predict report for VMware


Figure 23 Resource allocation for VMs


Predict offers a variety of charts and reports that you can use to examine the results of your “What if…?” studies. These charts and reports contain a summary of network, computer, workload, transaction, and disk activity for each period.

After you have evaluated the model, there are two perspectives for the VMware system that you can view on the Predict VMware Summary report: the overall physical (host) system and the individual VMs.

You can view the Predict VMware summary report to examine the CPU performance in terms of “degradation”. Degradation is the ratio of system response time to service time. The two types of degradation shown on the report are: degradation due to the overall activity associated with the VMware host (shown on the report as Overall Response Time Wait), and degradation due to other activity attributed to other VMs (shown as Other VM Response Time Wait).

Finally, you can review other information such as I/O rates to virtual disks and configuration information for the individual VMs.

See the online Help for descriptions of the Predict reports and for information on working with them.



To view the report:

■ Expand the Reports tree in the scope pane.■ Expand the Computer tree. ■ Select the VMware Summary report. Predict displays the report in the results

pane, as shown in Figure 24.

Figure 24 Predict VMware Summary report

The following table describes the columns in this report. You may need to scroll to the right of the report to see some of these columns.

Column Description

VMware Host The name of the VMware service console that provides all of the management functions for the VMs, prefixed by ‘VH’. For reporting purposes, this name is used to refer to the physical VMware Host Server.

VM System This value is used to refer to the VM. Each VM is identified by its display name specified in the VMware configuration file. This display name is not guaranteed to be unique on the VMware server.

CPU model The model number of the hardware.

Vendor The hardware vendor.

Processor For the VMware Host, this is the total number of physical processors. For Virtual Machines, this is the number of virtual processors.

Performing “What if...?” investigations of VMware systems


Predict also creates a Visualizer file that contains the VMware performance results. See the Visualizer online Help for descriptions of the VMware reports and for information on working with them.

A few key items to review in the report:

■ The VMware Host total line shows the total physical processors expressed as a percentage (for example, 400% translates to four physical processors). Therefore the CPU Utilization reflects the total across all VM, relative to a maximum of 400% in the example of four processors. The Processor value for each VM shows the number of virtual processors, which translates to 100% for one processor.

■ The Overall and Other VM Response Time Wait percentages show the effect on CPU response time due to competition among VMs. The higher the percentage for these values, the more degraded the performance is as compared to a system running a native OS with dedicated resources.

■ The System SVC field shows the amount of CPU consumed by the System Services console, which services the entire Virtual Host system.


After you have established a valid baseline model, you can change the VMware host CPU model and investigate how the changes will affect system performance.

System SVC The CPU utilization attributed to the VMware Host Server (specifically the System Services console which runs on the host).

Util For the VMware Host, this is the percent of CPU utilization out of online processors * 100. For the Virtual Machine, this is the percent of CPU utilization out of physical online processors * 100, with a maximum value of the number of virtual processors * 100.

% utilization out of For the VMware Host this equals the online processors * 100.

Total Disk I/O The total disk I/O for the VMware Host is the sum of the I/Os for all the Virtual Machines running on that host.

Total Memory For the VMware Host this is the total physical memory. For the Virtual machines, this is the total virtual memory. The memory for the VMware Host is not the sum of the virtual memory of the Virtual Machines.

Overall Response Time Wait The percentage of CPU wait time due to all virtual machines (including itself) on the VMware ESX Host Server.

Other VM Response Time Wait

The percentage of CPU wait time due to activity from other virtual machines.

Column Description



For more information on modeling and “What if...?” analysis, refer to the Predict online Help or the BMC Performance Assurance for Microsoft Windows Implementation Guide for Microsoft Windows.

The following section explores a sample “What if...?” scenario involving VMware systems.

Example scenario: How do I take existing work and move it to a new Virtual Host?

In this example, a company is looking to reduce the number of dedicated redundant servers by managing the failover of their 24 physical servers to a single ESX Server. They have decided they want the ability to have up to four servers simultaneously failover to one ESX Server, but do not know how big the VMware ESX Server and individual virtual machines need to be.

The following example demonstrates how BMC Performance Assurance can be used to accurately size an ESX Server to accommodate the workloads from four physical machines.

For general information on workloads, baselines, and models, see the online Help or the BMC Performance Assurance for Microsoft Windows Implementation Guide for Microsoft Windows.

Collecting, Analyzing, and Modeling the Data to Size the VMware ESX Server

1 Collect performance data from the machines of interest. In this example performance data was collected from all of the 24 physical servers. To understand the performance of the systems and capacity, you need to continually collect performance data. In this example data was collected over a period of time which included the periods of peak demand. This peak demand period relates to the four most highly utilized servers in the server farm.

NOTE VMware virtual machines can be moved or assigned only to another VMware Host Server. Converting a standalone computer to a VM is not supported, but workloads from a standalone computer can be moved to a VM.

TIP For details on collecting data using the Perform Agent and Perform collector, refer to Chapter 2 of the BMC Performance Assurance for Microsoft Windows Implementation Guide for Microsoft Windows.



2 Using Analyze, define workloads that represent each of the four machines.

— Create separate Analyze workload characterization files for each machine. Workload characterization enables you to aggregate disparate processes from one or more computers into a logical group. These groups (workloads) can define a business application, group of users, or in this example, all the work on a physical computer. You can then use Predict to calculate the throughput and response time for each transaction in the workload.

— Create an ALL transaction and workload class containing all processes using the “.*” regular expression. (The ALL workload encapsulates all of the work being done on the physical machine.)

3 After you've collected performance data over a meaningful period and created workloads for each machine in the study, you can use the Analyze component of BMC Performance Analyzer to identify the period of peak demand. In each workload characterization file (.an), identify the peaks for each physical server, and create a model that represent the worst case behavior, in terms of performance. To do so:

A Select the peak interval (normally a 1-2 hour time period) for each machine in your Analyze workload characterization file, as shown in the following figure.

B Run Analyze, by right-clicking the workload characterization file and selecting Start Analyze. Repeat this step for every workload characterization in your study. Analyze outputs include a model file (.md) used by Predict to answer the “What-if...” questions, and a Visualizer (.vis) file. Visualizer is the component that provides scheduled and ad-hoc graphical reports on application and system performance, based upon data collected by the Perform Agent and collector.

TIP Individual machines encounter peak utilization at different times (intervals). That is why you the need to create multiple workload characterization files.



4 Use Visualizer to estimate the size of the target VMware ESX server. With Visualizer, you can draw performance graphs which enable you to understand the performance of the physical system(s). Since the analysis interval chosen was during peak utilization, any graph drawn in Visualizer reflects peak values. Understanding the required capacity during this peak demand period helps you accurately size and configure the VMware ESX Server. Draw a stacked CPU utilization graph from the four physical machines you want to migrate to the VMware ESX Server as virtual machines. The following figure shows the Stacked CPU chart used to determine peak capacity requirements. Refer to the Visualizer online Help for specific instructions.

TIP It is important to view the Y axis in SPECINT rating, as opposed to utilization percentage. The SPECINT rating is a way to normalize the different processing power of different CPUs. This example uses SPEC INT RATE 2000. At peak demand a SPECINTRATE2000 of 4.5 serves as the peak value, meaning the CPUs we choose for our new VMware ESX Server must collectively have a minimum SPEC INT RATE 2000 value of 4.5 to adequately support these workloads.



5 Export the workloads to the workload library.

— Using Predict, open each of the models created by Analyze.

— Export the ALL workloads for each model to a workloads file. To export the workloads, right-click the workload and choose Export workload. Click Save in the Export workload dialog box to save the workloads on a library. These saved workloads will be imported into a newly created model.

— After it is exported, the ALL workloads from each of the four machines can be imported into a new Predict model. It is in this new model where we will create a new ESX Server and four virtual machines.

6 Create a new model with a VMware ESX Server and a staging computer to serve as a container for the saved workloads from the four physical machines.



A Create a new model by right-clicking Predict and selecting New model. The New model wizard walks you through the steps of creating a new model. In this example, the new model is named Sizing.

B Create the computer to serve as a container for the saved workloads from the four physical machines. To do so, right-click the Computer object in the tree and selecting New Computer. The New Computer wizard walks you through the steps of creating the computer. This computer will be used as a container for the saved workloads from your physical machines. In this example, the new computer is named Staging.

C Create a new VM host system by right-clicking the Computer object in the tree and selecting New VMware Host System, as shown below.

The New VMware Host System wizard walks you through the steps of creating the new system.

■ In this example, on the VMware Host System Name page, the system is named VMwareHost_1 and the Performance rating selected is SPEC CINT 2000 RATE.

■ On the Model Selection page of the wizard, choose the CPU model. It is important to select CPUs that have a SPEC INT RATE 2000 performance rating that is greater than or equal to what was identified in the Visualizer Node CPU Utilization graph. In this example, the CPU model you choose for your ESX server must have a SPEC CINT RATE (performance rating) of at least 4.5 to match the rating shown in the Visualizer graph in step 4 on page 69.

NOTE BMC Performance Assurance supports multiple performance ratings. Ensure the performance rating used in Analyze and Visualizer matches the performance rating in Predict.



■ On the VMware Host System Configuration page, the system has a total memory configuration of 2048 Mbytes, and two online processors.

■ After you have created the new VMware host system, you can verify the configuration of the system by right-clicking the VMwareHost_1 computer and selecting Properties.

1 Create virtual machines (VMs) on the VMwareHost_1 server for each physical system.

A Right-click the VMwareHost_1 computer, and select New Virtual System. The New Virtual System Wizard is displayed.

B Click Next on the welcome page. The General Information page is displayed.

C Specify a name, a brief description, select the operating system, and click Next.

D Complete the system configuration information for the new VM, as shown below, and click Finish.

TIP Do not be concerned about configuring each VM with the correct amount of virtual processors, memory, or CPU shares at this point in the process. That information is unknown at this time. Only after modeling the ESX Server and virtual machines, running the four workloads, will you identify the optimum configuration, given your performance objectives.



E Repeat the process to add the other three VMs.

In this example, four VMs have been created; one for each of the ALL workloads on the physical machines.

2 Import the saved workloads to the Staging computer. Right click the Workloads object in the Sizing model, and select Import Workloads. On the Import Workload dialog, select the target computer (in this example the Staging system), the four workloads in the Objects in Library window, and click OK, as shown in the following figure.



The four workloads are imported into the newly created Sizing model, and are contained in the Staging system. They will eventually be moved to the individual VMs that were just created on VMwareHost_1.

3 Move the workloads to the individual VMs. For example, to move the workload PhyNode_1 to the virtual machine VM VirtualNode_1 running on ESX Server VMwareHost1:

A Right-click the Workloads in the model, and select Move workload.

B On the Move Workload Computer Options dialog, select Virtual System.

C On the Move Workloads to Virtual System dialog, choose the target VMware host, the target VM, and the utilization adjustment and click OK.

D Repeat the process for each of the workloads you want to move.

4 Evaluate the model to ensure that performance is acceptable. In this example, right-click the Sizing model and choose Evaluate Model.

Review the Predict – VMware Summary Report

After evaluating the model review the Predict – VMware Summary report (an example is shown in Figure 24 on page 65) to understand the performance of the VMware Host system and all virtual machines.

■ When reviewing the VMware Summary Report in Predict pay special attention to the values in Overall Response Time Wait column and the Other VM Response Time Wait column. Overall Response Time Wait is the percentage of CPU wait time due to all virtual machines (including itself) on the ESX server. Other VM Response Time Wait indicates the percentage of CPU wait time due to activity from other virtual machines.

■ Comparing overall wait time and wait time due to other VMs helps you identify if you have balanced the VMs on a the ESX Server properly. The CPU shares and utilization both impact the wait time.



What to do next

After you have reviewed the report, consider the following course of action:

■ If the wait time for the VM is significantly higher than the other VMs on the server, use the virtual machine properties page to reallocate the number of virtual processors and CPU shares until performance is acceptable. To access this dialog, right-click the VM under the Computers object, and select Properties.

For example, the Overall Response Time Wait column and the Other VM Response Time Wait column in the Predict VMware Summary report may have indicated that the VM spends a significant amount of time waiting for resources. The CPU shares and CPU utilization settings on the virtual machine properties page both impact these wait time statistics.

— The number of CPU shares assigned to a VM defines whether or not the VM has a higher or lower priority to CPU resources than the other VMs. The more shares a VM has the more CPU cycle opportunities the VM has at its disposal.

— The fields in the CPU Utilization group box control the minimum and maximum amount of CPU resources that can be allocated to the VM. By increasing these percentages, in conjunction with increasing the number of CPU shares, you can decrease the amount of time the VM will spend waiting for resources.

TIP Focus more on the relationship between the two values and not the values themselves. Look for indications that a VM is monopolizing the server:

■ If you see a VM with high overall wait time but low wait time due to others, it is the dominant VM on the server. On an under utilized system, this may not be an issue.

■ If you see a VM with high overall wait time and high wait time due to others, then there is another VM dominating the system. In this case, you may want to move that dominant VM to another server, so that other VMs can receive better service.

Ultimately, the competition between virtual machines and the work inside the virtual machines affect your overall transaction response time.



■ If the overall wait time and wait time due to other VMs in the Predict VMware Summary report indicated that the VMs are not properly balanced on the ESX Server properly, use the Virtual System Allocation dialog to reallocate resources for all of the virtual machines. You may have found that one of the VMs is over allocated in terms of CPU shares, and this is affecting the performance of the new VM you are modeling. To access this dialog, click the Virtual System Allocation button on the Configuration tab of the VMware Host Server.

■ If the performance is still unacceptable, you may need to consider changing the configuration of the ESX Server (for example, to upgrade or downgrade CPU) or moving the application to a different server. To access the VMware Host System properties page, right-click the VM Host Server under the Computers object, and select Properties.



Additional Sample Scenarios

You can also explore other “What if...?” scenarios, such as:

■ What would happen to performance if I move a virtual machine from one VMware server to another, to see the effect on CPU utilization and response time wait.

■ What would happen to performance if I move a virtual machine from one VMware server to another, to see the effect on CPU utilization.

■ What if I move an existing workload from an existing stand-alone system to an existing virtual machine?

■ What if I create a new VMware server by specifying server name, CPU model and system service utilization, and move an existing virtual machine there? What would happen to overall performance?

■ What if I upgrade a CPU on the VMware host machine? What effect would it have on response time?

FAQs for Predict Modeling



How does a VMware model differ from a "traditional" model?

The Predict view of the model simultaneously displays both the Virtual Host (i.e. outside) and virtual machine (i.e. inside) views.

Figure 25 Predict view of a model

The outside view is prefixed with VH to identify it as the Virtual Host. Any virtual machines which are instrumented are displayed as "regular" computers (for example, "tstcvm1a" is the System Services console).

Even though both views are displayed simultaneously, they are not linked; that is, if a change is made to tstcvm1a, it will not be reflected in performance results for VHtstcvm1a (and vice versa). So as a practical matter, typical Predict usage would focus on either the Virtual Host or one or more virtual machines, but not both within the same modeling session.



How do I confirm that the CPU model is properly identified?

Confirm that the CPU model is properly identified for the Virtual Host system and/or the individual virtual machines, depending on the focus of the modeling study. In either case, check the Analyze Hardware Summary report.

Figure 26 Hardware Summary report

In order to check that the Virtual Host has been properly identified, check that the VMware host computer has an appropriate Identified Model. You will also see the fully identified VH in Predict, by observing the VH configuration (Properties => Configuration for Windows console; Nodes => Edit => Configuration for UNIX console).

Figure 27 Virtual Host Configuration



A CPU identification issue which is unique to VMware is that the System Services console runs Linux, classified as UNIX for hardware table purposes, and the Virtual Host is running VMware, which is classified as NT (i.e. Windows) for hardware table purposes. The reality is that both are running on the same physical hardware, but the Analyze/Predict hardware table lookup process would look for the same CPU hardware benchmarked on both UNIX and NT. But almost no systems are benchmarked on both operating systems, so the following message will be issued when Analyze/Predict establishes that the same performance rating will be used for both:

RNING-ALTPERFRAT No performance rating available for cpu model XEON_MP@3660 vendor INTEL operating system UNIX. Alternate performance rating of operating system WINDOWS for this cpu-model will be used.

If you wish to avoid seeing this message, a new hardware table entry can be made for the User Hardware table by modifying the existing one.

First, the original hardware table entry:

CREATE CPU-MODEL XEON_MP@3660 VENDOR INTELDESCRIPTION Copied from ProLiant ML570G3 XeonMP 3.66GHz 1MBL2 667MHzbus 1core/chipCATEGORY systemMIN-PROCESSORS 1MAX-PROCESSORS 4PROCESSORS 1

PERFORMANCE-RATING SPECINT2000 1386 NT PERFORMANCE-RATING SPECINTRATE2000 16.1 NT

PROCESSORS 2PERFORMANCE-RATING SPECINTRATE2000 30.6 NT

PROCESSORS 4PERFORMANCE-RATING SPECINTRATE2000 57.1 NT

#Source : Equivalence of XEON_MP@3660 with HP ML570G3@3660 made by Support #Date : February 2006

Then the new entry which needs to be added to the best1user.hrw file:

MODIFY CPU-MODEL XEON_MP@3660 VENDOR INTELPROCESSORS 1

PERFORMANCE-RATING SPECINT2000 1386 UNIX PERFORMANCE-RATING SPECINTRATE2000 16.1 UNIX

PROCESSORS 2PERFORMANCE-RATING SPECINTRATE2000 30.6 UNIX

PROCESSORS 4PERFORMANCE-RATING SPECINTRATE2000 57.1 UNIX

#Source : Equivalence of XEON_MP@3660 with UNIX and NT ratings made by Support



In the previous example reports, there is no published rating on spec for a XEON_MP@3660, so both a User Hardware Table entry and User Translation Table entry are required (in addition to the optional entry which avoids the message). Please contact Customer Support for assistance with CPUs which are not published by spec.org, and thus are not in the default Hardware Table.

Which reports should I look at to understand what's happening at the CPU?

This discussion parallels the discussion in the CPU reporting section above, so all you need for navigating Predict is to understand where to find the corresponding views.

As explained previously, there are two necessary perspectives on a VMware system: (1) the overall physical (host) system and (2) the individual VMs. You can use Visualizer graphics to see these views (see Where do I start with CPU reporting?” on page 50) and/or the Predict report, VMware Summary Report.

Figure 28 Predict VMware Summary Report



The VMware Host total line shows the total physical processors expressed as a % (% Utilization out of), e.g. 400% translates to 4 physical processors, and the CPU Utilization there is the total across all virtual machines, relative to a maximum of 400%. The Processor value for each VM shows the number of virtual processors, which should be translated to %, e.g. 100% for 1 processor.

Also shown are Overall and Other VM Response Time Wait % , which show the effect on CPU response time due to competition among VMs. The larger the %, the more degraded performance is as compared with running a native OS with dedicated resources.

System SVC shows the amount of CPU consumed by the System Services console, which services the entire Virtual Host. This is displayed as a separate virtual machine in Visualizer rather than as an embedded part of the Host in Predict.

How does Predict "alert" for Virtual Hosts and Virtual Machines?

The traditional computer provides resources for workloads which generate a particular amount of CPU utilization, and the CPU Utilization objectives for that computer specify when alerts should be generated in Predict, e.g. yellow alert at 70% utilization and red alert at 80% utilization per processor. A Virtual Host works identically to the traditional computer. Virtual Machines do not have individual performance objectives, but are messaged when they no longer have adequate resources to complete their work:

WARNING-CUTMAXVS CPU on Virtual System 564d53ef49e2010a863db86dfa5da0d5 is exceeding its MAX-CPU-UTILIZATION and the model is evaluated with a cutback on its CPU Utilization.

The report shows the tstcmdsvr1 virtual machine at 100% utilization, its maximum due to its configuration with 1 virtual processor.

NOTE Remember that all of the traditional interactive Predict reports (for workloads, relative response time, response time breakdown, etc.) show performance results for virtual machines which have been instrumented with system collectors only (see What about the view from inside a Virtual Machine?” on page 58).



Figure 29 Predict VMware Summary

The overall Virtual Host is not constrained yet (i.e. 178% out of 400%), so it would be possible to satisfy the VMs requirements by increasing its virtual processor allocation from 1 to 2.

Figure 30 VMware Host Properties



How do I use Scenario Planner to change the amount of work in a Virtual Machine?

Scenario Planner works similarly for Virtual Hosts as it does for a traditional computer. Overall growth can be specified, and that will affect all virtual machines. In this example, zero overall growth is specified.

Figure 31 Growth Rates

Alternatively, individual virtual machine growth may be specified (similar to workload growth for traditional computers). In this example, a single VM's requirements will grow by 500, then 1000%.



Figure 32 New Growth Override by Virtual System Wizard

The results are displayed in the Period-Predict VMware Summary report within Scenario Planner. Other Scenario Planner reports display results for individual VMs which have been instrumented with system collectors (see What about the view from inside a Virtual Machine?” on page 58).

How do I add work onto an existing Virtual Host?

The method for doing this is to import a workload from another model (after it has been exported from its baseline model), then move it to a Virtual System within a Virtual Host. The specific steps for doing this:

1. When defining workloads for this type of modeling, the simplest workload structure is the easiest to work with, i.e. a single workload, "zzz" should be used if feasible. If all the work isn't being moved to a virtual system, two workloads are enough, e.g. "work_to_be_moved" and "zzz".

■ A complex workload structure just makes for a lot of work, so it should be avoided.

■ Build baseline model(s) containing each computer which has work on it that is being moved to VMware .

2. Select the workloads to be moved to a Virtual System

A. Workloads, right-click a workload, Workload Export (Windows console)

B. Workloads, select a workload, File -> Save to Library (UNIX console)



This step should be repeated for each baseline model built in Step 1.

3. Work with a baseline model of an existing Virtual Host.

4. Add any new Virtual System(s) to a Virtual Host as desired . If work is to be moved to existing Virtual System(s), this step can be skipped.

A. Computers, right-click a VMware Host -> New Virtual System (Windows console)

B. Nodes, Edit -> Create -> VMware Virtual System (UNIX console)

5. Windows console only , right click Workloads -> Move workloads.

A. Select Virtual Systems.

B. To select workloads to move either

1. Use ADD Workloads from Library to import workloads that have been exported from other models

2. Otherwise check the box next to each workload you want to move

C. Select the VMware guest you want to move work to (under VMware System Available)

D. Click Add>>

6. Optional addition for "Move workload" step (above) is to add any desired overhead, (use the Utilization adjustment field in the Move Workload dialog). The % is added in proportion to the work being moved to the virtual system, e.g. 100% utilization adjustment will double the utilization of the incoming workload.

7. Evaluate the model

Remember that after a workload has been moved, its work is combined with all of the other work for that Virtual System, and cannot be specifically tracked as a separate workload. The workload remains in the model, but no longer generates any resource requirements, so appears as follows.



Figure 33 After workload move, original computer(s) show zero resource utilization

Figure 34 After workload move, Virtual System(s) show resource utilization

Evaluating the virtual environment in Perceiver


Evaluating the virtual environment in Perceiver

You can view predefined views that describe resource consumption for virtual environments using BMC Performance Perceiver.

In addition to overall VMware host resource usage, the resource usage for each of the guests is reported. As with stand-alone systems, the views provide system identification, configuration and hardware performance rating information for the VMware systems. These details are critical in supporting the sizing and consolidation requirements.

The following sections walk you through an example of how you might use these predefined views to assess the overall performance of the virtual environment in your data center.

Step 1: View overall guest activity

Use the VMware Virtual Machine Overview (Figure 35) to get an overall idea of guest activity in the VMware virtual environment. For example, is the overall guest utilization balanced, or is it skewed one way or another?

1 In the task pane, click the VMware Virtual Machine Overview category.

2 Select one of the available views. This example uses Virtual Machine Overview.

3 In the selector pane, select a group from the Group menu.

In this example, the Viewer Administrator has created a group called DataCenter2, that includes all the VMware hosts and guests systems in the data center.

4 In the selector pane, select a time interval from the Time menu.

This view displays the average distributed values for the computers in your data center by metric. It also includes a ranking table that shows where the computers being measured fall in increments of 10 percentage points, based on a blended value of the essential metrics (Physical CPU Capacity Used, Virtual CPU Capacity Used, IO Rate, Memory Utilization, Network Rate).

NOTE BMC Performance Perceiver includes predefined views for many virtualization platforms. The following example illustrates some aspects of the support for the VMware virtual environment.

Step 2: Identify guests of interest


Figure 35 Virtual Machine Overview

The distribution charts in this example show that while guest CPU utilization seems to be low overall, there are a few guests with very high CPU utilization. The charts also indicate that there may be a growing problem with memory utilization.


The ranking table (Figure 36) shows which guest systems are approaching the resource usage limits on their VMware hosts.

Figure 36 Virtual Machine ranking table



In this example, the top four guests shown in the table are displaying high memory utilization, with the next two being above guidelines, and the top two guests are displaying both high virtual CPU and high memory utilizations. After these guest systems are identified in the ranking table, use the Virtual Machine Metrics view to see a more complete picture of the overall resource utilization.

The Virtual Machine Metrics view (Figure 37) displays multi-server charts for the essential metrics (Physical CPU Capacity Used, Virtual CPU Capacity Used, IO Rate, Physical Memory Used, Network Rate) in your data center, by group of VMs.

Figure 37 Virtual Machine Metrics view

From these charts, we see that there appears to be sufficient physical CPU capacity in this group. However, it is apparent that the guest resource utilization for both virtual CPU and memory is not balanced among the virtual hosts available in the data center. The next step is to isolate the virtual hosts with high guest resource utilization.

In Figure 37, an obvious candidate to examine is guest system engrhes50vms5.

NOTE The Network rate chart is not shown in the Figure 37 example.

Step 3: Review resource utilization for a guest


Step 3: Review resource utilization for a guest

Use the Virtual Machine Summary by Resource views to look at utilization of those guests on the virtual hosts you have identified and included in your group.

In this example, we are focusing on the resource utilization of the guest system QAIA-CLT-vm1.

1 In the task pane, click the Virtual Machine Summary by Resource view category.

2 Select one of the available views. This example uses CPU Profile.

3 In the selector pane, select a group from the Group menu. This example uses a group called VM Systems.

4 Select engrhes50vms5 in that group from the Computer menu.


The CPU Profile view displays key CPU-related metrics and system identification and configuration information for the individual guests in your data center.

Figure 38 Virtual Machine Summary by Resource - CPU Profile view

This profile shows that the guest is using all of the virtual CPU allocated to it for long periods of time, but is using less than 10% of the physical CPU capacity of the Host Server.

Step 4: Explore guest activity on a single Virtual Host


Another key piece of information from this view is the name of the VMware Host Server on which it runs (shown in the VM System Identification section) and the information shown in the VMware Host System CPU Configuration section.

6 Click Memory Profile to see the memory utilization statistics for the guest.

Figure 39 Virtual Machine Summary by Resource - Memory Profile view

Consumed memory for the guest is high, over 90% at times, while shared memory is around 4.5%, and balloon memory (amount of reclaimed memory available) is near zero. The memory swapping rate is also near zero.

The next step is to look at the overall resource utilization for the VMware Host Server on which this guest is running. From the VM Host System CPU Configuration section shown in the CPU Profile (Figure 38), we see that the Host Server is lex-rd-esx-06.


Use the Virtual Host Summary by Resource category to identify specific guests of interest on the virtual hosts.

For example, the CPU Profile view (Figure 40) from this category displays the key metrics for the VMware hosts, and guests on those hosts, in your data center. Select a VMware host computer to view the metrics for the selected host and its associated guests.



1 In the task pane, click the VMware Host Summary by Resource category.

2 Select one of the available views. This example uses the CPU Profile.

3 In the selector pane, select a group from the Group menu. This example uses a group called DataCenter2.

4 Select lex-rd-esx-06 in that group from the Computer menu.


The CPU Profile view displays key CPU-related metrics and system identification and configuration information for the individual guests in your data center.

Figure 40 Virtual Host Summary by Resource - CPU Profile

This view confirms that the guests identified earlier are the largest consumers of the CPU resources on the VMware Host Server. Zooming in on the Virtual CPU Capacity Used chart shows the activity for every guest on the Host Server.



Figure 41 Virtual CPU Capacity Used chart

Because several of the guests running on this Host Server were also identified as high memory utilization consumers on the Virtual Machine Overview (Figure 35 on page 89), click the Memory Profile view.

This view shows the following graphs:

■ Memory Utilization by VM■ Memory Overhead by VM■ Zero Memory by VM■ Balloon Memory by VM■ Memory Swapping Rate by VM■ Memory Swapped by VM■ Memory Configured by Partition

The Memory Utilization by VM graph (Figure 42) shows that the guests that are large CPU and virtual memory consumers are not consuming a large percentage of the memory resources on the VMware Host Server. It also shows that the overall memory consumption for the Host Server is around 50%.



Figure 42 Virtual Host Summary by Resource - Memory Utilization by VM

Based on this examination, the problem does not appear to be related to the capacity of the VMware Host Server, but rather with the resource allocations for a few of the guests on that Host Server.

Your options for a next step include:

■ changing the resource shares for the guests, to have a greater percentage of the physical resources on the VMware Host Server available to them.

■ using the Virtualization Planning feature to conduct a guest rebalancing study.

■ VMware Cluster Summary - Cluster Overview■ VMware Cluster Summary - Resource Usage by Host■ VMware Cluster Summary - Resource Usage by Virtual Machine■ VMware Resource Pool Summary - Resource Pool Overview■ VMware Resource Pool Summary - Resource Usage by Virtual Machine.


C h a p t e r 33 Implementing Performance Assurance in a Microsoft Virtual Environment


Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Support for Microsoft Virtual Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Support for Hyper-V (Microsoft 2008 Virtualization Server) . . . . . . . . . . . . . . . . . 98

Installation considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Installation considerations for a Microsoft Hyper-V environment . . . . . . . . . . . . 99Installation considerations for a Microsoft Virtual environment. . . . . . . . . . . . . 100

Managing performance of a Microsoft Virtual Server . . . . . . . . . . . . . . . . . . . . . . . . . 101Collecting and processing data from a Microsoft Virtual Server . . . . . . . . . . . . . 101

Viewing the results for Virtual Server data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Viewing Virtual Server CPU Usage in Visualizer . . . . . . . . . . . . . . . . . . . . . . . . . 108Viewing Virtual Server data in Perceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Managing performance in a Microsoft Hyper-V environment . . . . . . . . . . . . . . . . . . 110Setting up data collection for Hyper-V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Viewing results for a Hyper-V environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Viewing Hyper-V CPU usage in Visualizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Viewing Microsoft Hyper-V results in Perceiver . . . . . . . . . . . . . . . . . . . . . . . . . . 113

IntroductionWith BMC Performance Assurance, you can manage the performance of Hyper-V (Microsoft 2008 Virtualization Server) and Microsoft Virtual Servers. You can analyze performance information for the virtualized systems (guests) and obtain a system-level view of the Host Server for server sizing, management, and daily reporting.

Support for Microsoft Virtual Servers


Support for Microsoft Virtual Servers

BMC Performance Assurance provides the ability to collect Microsoft Virtual Server configuration and system-wide statistics and report on the data using the Investigate, Visualizer, and Perceiver components.

BMC Performance Assurance can help you manage the performance of each guest and report the appropriate performance data for the Microsoft Virtual Server host.

Performance data collected from within the guest’s operating system may be used to display the “relative” resource usage of individual processes. All guests share system resources, so obtaining accurate measurements of total actual resource usage is necessary to provide a complete picture of system usage.

With BMC Performance Assurance, a Perform Agent and a data collector run inside the Microsoft Virtual Server host operating system. This information is used to create system-level views to support analysis of individual guest usage.

Support for Hyper-V (Microsoft 2008 Virtualization Server)

With BMC Performance Assurance, you can:

■ collect Hyper-V specific metric groups and metrics (see tables for the list of metrics collected)

■ analysis of key metrics■ review key metrics in BMC Performance Perceiver Datacenter Overview charts

and detailed metrics in Hyper-V specific charts■ conduct CPU modeling of Hyper-V systems

You must collect data from the Microsoft 2008 Virtualization Server operating system that represents the Host Server (parent partition) by installing the Perform Agent on the parent partition or preferably using proxy collection from a Windows proxy host.

NOTE Analyzing and modeling data collected from the virtual system environments described in this book use the version BMC Performance Assurance console on Microsoft Windows. Similar support is available on UNIX consoles.

Installation considerations



Installation considerations for a Microsoft Hyper-V environment

To implement BMC Performance Assurance in a Hyper-V environment:

■ Select a Microsoft Windows server (running .NET Framework 2.0 service pack 1 or later) to act as a proxy host computer.

■ Run the installation program according to the instructions in BMC Performance Assurance Getting Started guide, installing the Perform Agent on the selected Microsoft Windows server.

■ Configure the computer to act as a proxy host according to the instructions in the Implementing Proxy Data Collection appendix in the BMC Performance Assurance Getting Started guide.

The proxy host collects data remotely from other Microsoft 2008 Virtualization Servers. This method provides a robust list of metrics for both the host servers and the guests running on those servers.

Note the following additional installation considerations for using BMC Performance Assurance in a Hyper-V environment.

■ You must install the Perform Agent on the Microsoft 2008 Virtualization Server operating system that represents the Host Server (parent partition) by installing the Perform Agent on the parent partition, although BMC Software recommends the use of a proxy host.

■ Do not install the Perform Agent on any of the guest operating systems. If you do, then the guest operating system is viewed as a standalone system by BMC Performance Assurance.

Installation considerations for a Microsoft Virtual environment


Installation considerations for a Microsoft Virtual environment

Note the following installation considerations for using BMC Performance Assurance in a Microsoft Virtual Server 2005 environment.

■ Run the installation program according to the instructions in BMC Performance Assurance Getting Started guide.

■ You must install the Perform Agent on the Microsoft Virtual Server host system to obtain system-level information and for accurate system resource analysis and reporting.

■ Do not install the Perform Agent on any of the guest operating systems. If you do, then the guest operating system is viewed as a standalone system by BMC Performance Assurance.

■ To accurately report the guest operating system information, you must ensure that Microsoft Virtual Machine Additions is installed on all guest operating systems. Virtual Machine Additions is a Microsoft Virtual Server feature that can improve the performance of the guest operating system, and the interoperability between the guest and the Host Server.

Refer to the following instructions to install Microsoft Virtual Machine Additions:

1 Open the Administration Website.

2 In the navigation pane, under Virtual Machines, point to Configure and then click the appropriate virtual machine.

3 In Status, point to the virtual machine name, and then click Turn On.

4 After the virtual machine has started, point to the virtual machine name, and then click Remote Control.

5 Log on to the virtual machine as an administrator or member of the Administrators group.

6 After the guest operating system is loaded, press the HOST KEY to release the mouse pointer, and then in the lower-left corner under Navigation, click Configure virtual_machine_name.

7 In Configuration, click Virtual Machine Additions, click Install Virtual Machine Additions, and then click OK.

8 Under Status, point to the virtual machine name, and then click Remote Control.

Managing performance of a Microsoft Virtual Server


9 Click in the Remote Control window to return to the guest operating system. The Virtual Machine Additions installation wizard starts. Proceed through the wizard.

10 After the wizard is complete, you will be prompted to restart the virtual machine to complete the installation.

Managing performance of a Microsoft Virtual Server

Collecting and processing data from a Microsoft Virtual Server

You collect data from the guest sessions and the Host Server just as you would from any other computer. For the steps in this process, see “How do I collect and process the data?” on page 102.

For complete descriptions of all data collection methods, see the BMC Performance Assurance for Microsoft Windows Implementation Guide for Microsoft Windows, or refer to the online Help.

What data Is collected from the Virtual Server?

The data collector gathers physical system configuration for the Host Server and selected performance data for each guest. The data available for each guest includes CPU usage, total disk I/O and network traffic through each network interface.

The metric groups that enable the data collection from the Microsoft 2005 Virtual Server are:

■ Virtual Server 2005 Virtual Machine Configuration, which includes the VM configuration file name, the Virtual Server version, display name, guest operating system, server type, power status, the guest’s universally unique identifier (UUID), memory size, number of virtual CPUs, disk reads, disk writes, network bytes received, network bytes sent.

■ Virtual Machine CPU statistics, which includes the guest’s UUID, the virtual machine configuration file name, the guest display name, CPU Utilization, minimum CPU allocation, maximum CPU allocation, CPU shares, and uptime.

■ Virtual Server 2005 Host Configuration, which includes the logical CPU number, core CPU number, memory available, and total memory.



■ Virtual Server 2005 Virtual Network, which includes the guest name, Adapter Name, virtual network name, virtual network configuration file name, and various packet and data transfer information.

■ Virtual Server 2005 Virtual Disk, which includes the guest name, disk image name, disk type, disk size, host free disk space, size in guest and size on host.

These metric groups are collected by default. For complete descriptions of these metric groups, see the chapter on Virtual Server Metrics in BMC Performance Assurance System Metrics for Microsoft Windows and Unix, Volume Two.

How do I collect and process the data?

The following tasks describe the recommended process for collecting and processing data from Microsoft Virtual Server systems.

Task 1: Set up a policy that includes the target Microsoft Virtual Server systems


NOTE According to the best practices guideline in the Virtual Server 2005 Administrator's Guide from Microsoft, Hyper-threading should be disabled to avoid poor server performance under heavy computing workloads.

Task Refer to

Create a policy that includes the Microsoft Virtual Server Host Server.

page 102











The discovery process could take a while depending on the number of computers in your network. After it is complete, you will have a list of all computers within the specified IP address range. You can sort by column headings. For example, if you only want to collect data from computers with the 7.5.00 Agent installed, click the Agent Version column head sorts the discovered computers by Agent version. You can then easily select computers with the 7.5.00 Agent for collection. Alternatively, you can select non-7.5.00 computers and delete them from the list.


6 Highlight the computer you are interested in and click the Add button. To select more than on computer, hold down the Shift key when making your selections.

7 Click OK.

8 One the Computers to Add to Policy window, click the check-boxes to select the individual computers from which to collect data.



WARNING Make sure you include only the Microsoft Virtual Server host computers in the policy; do not include VMware service console computers in the policy. If you mix the two types of virtual machine computers only the VMware data is processed.















7 From Automator, choose File => Save As.





The script is now available to be included in the Manager script.


To collect data using the Manager snap-in on the BMC Performance Assurance console, you must create a script or use an existing one. The steps in this section show how to create a script. You must also create a policy or use an existing one. These steps assume the use of the default policy provided with BMC Performance Assurance console.




4 Click Add to browse to the policy that has the computers you identified in “Task 1: Set up a policy that includes the target Microsoft Virtual Server systems” on page 102. On the Select Policy File window, select the policy file and click Open.



— Leave the Generate reports for... options blank. — Accept the default values for the Generate Visualizer files section.— Accept the Default workload characterization file option. — Click Next.


8 Select the time zone, and then click Next. Changing the time zone setting might be necessary if data is being collected from computers that are in time zones that differ from the time zone of the console computer.




10 On the Select Automator File dialog, browse to the Automator script you created in “Task 2: Set up the Automator script” on page 104, and then click Open.






To access the Status Report:



Viewing the results for Virtual Server data


The Perform - Data Collection Status opens in the results pane. The available Manager scripts are in the left portion of the report.

To view the status of data collection, click on a script. You can also click Schedule in the scope pane to display the scripts in the results pane. Then right-click on the script for which you want to view reports and select View Status Report.

See the online help, available from the help button on the top right portion of the Status Report, or refer to the appendix on Troubleshooting Tools in the BMC Performance Assurance Getting Started guide for more information about using these reports.

Viewing the results for Virtual Server dataYou can access performance data about the guest sessions or the Host Server by using any of the following components:

■ Investigate■ Visualizer■ Perceiver

For Investigate, refer to the online Help to create drill-downs on the Host Server. For more information, refer to the chapter on Virtual Server metrics in BMC Performance Assurance System Metrics for Microsoft Windows and Unix, Volume Two.

The following sections describe how to display and interpret the data using Visualizer and Perceiver.

Viewing Virtual Server CPU Usage in Visualizer


Viewing Virtual Server CPU Usage in Visualizer

To see the breakdown of CPU use on the Microsoft Virtual Server host system, complete the following steps:

1 Click Database=>Select and select the database into which you populated the Virtual Server data.

2 Click Database=>Detail and choose the data for the graph. Ensure that you select Virtual Server from the Virtual Type drop-down list.

3 From the Graphics menu, choose Virtual Server => Virtual Server Hierarchy.

The following table provides descriptions for some of the key metrics available on this graph. These metrics do not include numbers from other applications running on the computer outside of the Microsoft Virtual Server.

Metric Notes

%Total Total percent of Microsoft Virtual Server activity per processor.

TotaIIO Total I/O per guest, measured in four kilobytes pages per second. To see the total I/O for the Host Server, click in the total line at the top of the graph.

NetKbyte Network usage, in kilobytes per second, attributed by guest system.

Net Pack The net packets transferred per second. The packet size varies by application.

MemTotal Shows the total quantity, in megabytes, of physical RAM on the Host Server.

ShardMem Amount of shared memory, in megabytes. This metric does not apply in the Microsoft Virtual Server environment; it applies to VMware only.

OvrhdMem Amount of memory attributed to overhead, in megabytes. This is the amount of memory attributed to the Host Server on behalf of the guests. This metric does not apply in the Microsoft Virtual Server environment; it applies to VMware only.

SwapdMem Amount of memory used for swapping, in megabytes. This metric does not apply in the Microsoft Virtual Server environment; it applies to VMware only.

Viewing Virtual Server data in Perceiver


Viewing Virtual Server data in Perceiver

You can also use BMC Performance Perceiver to display performance data for the Host Server and the guests.

The Microsoft Virtual Server Overview view is similar to the VMware Overview and contains a Host Server partition table and three graphs.

Figure 43 Microsoft Virtual Server Overview

MemUsed Total amount of memory used in megabytes. This metric does not apply in the Microsoft Virtual Server environment; it applies to VMware only.

MemCnfg The amount of memory configured for the guest. The memory settings for guests are specified when an administrator configures a guest operating system in a virtual machine, and are stored in the Virtual Machine Configuration (VMC) file. Each guest can have up to 3.6 GB of memory configured, although the available memory for each guest depends on the amount of physical memory on the host.

Metric Notes

Managing performance in a Microsoft Hyper-V environment


If you select a Microsoft Virtual Server host, you get the following table and charts for all virtual machines.

The guest operating system in the view is only available if the virtual machine addition is installed on the guest and the guest operating system is running. Microsoft Virtual Machine Additions is an add-on component that enhances the functionality of the guest operating system by providing features including mouse control, heartbeat generator, registry keys, time synchronization, and better performance. For information on installing the Microsoft Virtual Machine Additions component, see “Installation considerations” on page 99.

For more information on Perceiver views and metrics, refer to the online Help or BMC Performance Perceiver Getting Started.

Managing performance in a Microsoft Hyper-V environment

Metric Description

System Hardware Configuration

Provides information on each partition on this host, including:

■ Display name ■ Node name■ IP address■ OS type■ OS version■ Number of virtual processors■ Amount of CPU shares■ Amount of allocated memory in MB

CPU Activity by virtual machine

Displays the CPU time in seconds used by each virtual computer.

IO Activity by virtual machine

Displays the total IO by each virtual computer.

Network KBytes by virtual machine

Displays the network rate (in KB) of each virtual computer.

NOTE A bug on the Windows 2008 and Windows 2008 SP1 Hyper-V editions that intermittently sets some counters to zero (0) when Hyper-V groups are collected remotely with WMI API, causes problems when displaying the data in the Investigate, Analyze, and Perceiver. Proxy collection for Hyper-V groups, therefore, requires upgrading the remote Hyper-V system to Windows 2008 R2 editions.

Setting up data collection for Hyper-V


Setting up data collection for Hyper-V

To implement BMC Performance Assurance in a Hyper-V environment, you must:

■ Select a Microsoft Windows server to act as a proxy host computer.

■ Run the installation program according to the instructions in BMC Performance Assurance Getting Started guide, installing the Perform Agent on the selected Microsoft Windows computer.

■ Configure the proxy host according to the instructions in the Implementing Proxy Data Collection appendix in the BMC Performance Assurance Getting Started guide.

■ Set up a Manager script to automatically collect, transfer, and process data from the Hyper-V environment. For more information on setting up Manager scripts, see BMC Performance Assurance for Microsoft Windows Implementation Guide for Microsoft Windows.

What data Is collected?

The data collector gathers physical system configuration for the Host Server and selected performance data for each guest. The data available for each guest includes CPU usage, total disk I/O and network traffic through each network interface.

For Investigate, refer to the online Help to create drill-downs on the Host Server. For more information, refer to the chapter on Virtual Server metrics in BMC Performance Assurance System Metrics for Microsoft Windows and Unix, Volume Two.

The following sections describe how to display and interpret the data using Visualizer and Perceiver.

Viewing results for a Hyper-V environment

Viewing Hyper-V CPU usage in Visualizer

To view Hyper-V data from Visualizer, complete the following steps:

1 Click Database=>Select and select the database into which you populated the VMware data.

2 Click Database=>Detail and choose the data for the graph. Ensure that you select Virtual Host from the Virtual Type drop-down list.

Viewing Hyper-V CPU usage in Visualizer


3 From the Graphics menu, choose Hyper-V => Hyper-V Hierarchy.

Figure 44 Hyper-V Hierarchy

Viewing Microsoft Hyper-V results in Perceiver


Another graph to look at is the Hyper-V Processor Use graph. From the Graphics menu, choose Hyper-V => Hyper-V Processor Use.

Figure 45 Hyper-V Processor Use


You can also use BMC Performance Perceiver to view performance data for Microsoft Hyper-V.

For more information on Perceiver views and metrics, refer to the online Help or the BMC Performance Perceiver Getting Started.

MS Hyper V Partition Overview

This category contains two views.

Partition Overview

Description: This view displays the average distributed values for the Hyper-V partitions in your data center by metric. It also includes a ranking table that shows where the partitions being measured fall in increments of 10 percentage points, based on a blended value of the essential metrics (Physical CPU Capacity Used, Virtual CPU Capacity Used, IO Rate, Physical Memory Used, Network Rate).



Figure 46 MS Hyper-V Partition Overview - Partition Overview

Partition Metrics

Description: This view displays multi-partition charts for the essential metrics (Physical CPU Capacity Used, Virtual CPU Capacity Used, IO Rate, Physical Memory Used, Network Rate) in your datacenter, in line charts by group of partitions. Physical CPU Capacity Used.



Figure 47 MS Hyper-V Partition Overview - Partition Metrics

MS Hyper-V Root Partition Overview


Partition Overview

Description: This view displays the average distributed values for the Hyper-V root partitions in your data center by metric. It also includes a ranking table that shows where the partitions being measured fall in increments of 10 percentage points, based on a blended value of the essential metrics (Physical CPU Capacity Used, Virtual CPU Capacity Used, IO Rate, Physical Memory Used, Network Rate).



Figure 48 MS Hyper-V Root Partition Overview - Partition Overview

Partition Metrics

Description: This view displays multi-partition charts for the essential metrics (Physical CPU Capacity Used, Virtual CPU Capacity Used, IO Rate, Physical Memory Used, Network Rate) in your datacenter, in line charts by group of root partitions.



Figure 49 MS Hyper-V Root Partition Overview - Partition Metrics

MS Hyper-V Host Summary by Resource

This category contains four views.

CPU Profile

Description: This view displays the CPU metrics for each partition in the selected Hyper-V host. The line Total if applicable, displays the value of the metric at the host level. The difference between the stacked partition(s) and the host represents the virtualization overhead for that metric.



Figure 50 MS Hyper-V Host Summary by Resource - CPU Profile

Memory Profile

Description: This view displays the memory profile for each partition in the selected Hyper-V host. The line Total if applicable, displays the value of the metric at the host level. The difference between the stacked partition(s) and the host represents the virtualization overhead for that metric.



Figure 51 MS Hyper-V Host Summary by Resource - Memory Profile

IO Usage

Description: This view displays the IO metrics for each partition in the selected host. The line Total if applicable, displays the value of the metric at the host level.



Figure 52 MS Hyper-V Host Summary by Resource - IO Usage

Processor Profile

Description: This view displays the per processor utilization for the selected host.



Figure 53 MS Hyper-V Host Summary by Resource - Processor Profile

MS Hyper-V Partition summary by Resource

This category contains three views.

CPU Profile

Description: This view displays charts for a selected Hyper-V partition designed to provide you with a detailed profile of its CPU capacity activity. This view also includes two tables containing information on partition system identification and CPU configuration of the Hyper-V host.



Figure 54 MS Hyper-V Partition Summary by Resource - CPU Profile

Memory Profile

Description: This view displays charts for a selected Hyper-V partition designed to provide a detailed profile of its memory usage. The memory usages in this view are reported as a percentage of memory configured for the partition.



Figure 55 MS Hyper-V Partition Summary by Resource - Memory Profile

IO Usage

Description: This view displays charts for IO metrics for a selected VMware virtual machine.



Figure 56 MS Hyper-V Partition Summary by Resource - IO Usage

MS Hyper-V Cluster Summary


Resource Usage by Host

Description: This view displays charts for partitions on a selected Hyper-V cluster host designed to provide a detailed profile of its CPU usage.



Figure 57 MS Hyper-V Cluster Summary - Resource Usage by Host

Resource Usage by Partition

Description: This view displays charts for a selected Hyper-V cluster host designed to provide a detailed profile of its CPU and memory usage.

Virtualization Planning support for MS Hyper-V


Figure 58 MS Hyper-V Cluster Summary - Resource Usage by Partition

Virtualization Planning support for MS Hyper-V

The Perceiver Virtualization Planning module recognizes existing MS Hyper-V virtualization components (guests and hosts) in a monitored environment. These components, along with a study profile describing MS Hyper-V virtualization attributes, can be used to perform Virtualization Planning exercises of current or future MS Hyper-V environments. For information about deploying new guests or rebalancing existing virtual hosts, see the BMC Performance Perceiver Getting Started guide.


C h a p t e r 44 Implementing Performance Assurance on an AIX System with Hardware Partitions


Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Installation Considerations for AIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Configuration Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Enable Remote Command Execution on the HMC . . . . . . . . . . . . . . . . . . . . . . . . 131Configuring the AIX Environment using the Perform Configuration File. . . . . 132Manually configuring the AIX Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Verify that the HMC was added to the list of known hosts . . . . . . . . . . . . . . . . . 135

Managing the performance of AIX hardware partitions . . . . . . . . . . . . . . . . . . . . . . . 136Collecting data from AIX hardware partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Displaying data from AIX Partitioned Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Viewing AIX partition metrics in Investigate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Key Analyze reports to review for AIX partitions . . . . . . . . . . . . . . . . . . . . . . . . . 140Displaying AIX hardware partition CPU usage in Visualizer . . . . . . . . . . . . . . . 144Displaying AIX hardware partition CPU use in Perceiver . . . . . . . . . . . . . . . . . . 146

FAQs for CPU reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147How does SMT affect the number of CPUs? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Where do I start? What view is "correct"? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148How do I interpret the name of the physical system? . . . . . . . . . . . . . . . . . . . . . . 160When I look at "per processor" usage, it's very uneven. Why? . . . . . . . . . . . . . . 160When I look at "per logical processor" usage, it's very uneven. Why? . . . . . . . . 162

Modeling AIX partitioned systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Evaluate the model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Review the Physical System Summary report . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Perform “What if...?” investigations of AIX partitioned systems . . . . . . . . . . . . 167Scenario for modeling data from an AIX partition. . . . . . . . . . . . . . . . . . . . . . . . . 168Additional scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170FAQs for Predict Modeling of AIX partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Managing the performance of workload partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

Overview


Collecting and processing data from a workload partition. . . . . . . . . . . . . . . . . . 181Viewing metrics in Investigate from a workload partition . . . . . . . . . . . . . . . . . . 188Displaying WPAR CPU Use in Perceiver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Displaying AIX partitions with Live Partition Mobility . . . . . . . . . . . . . . . . . . . . 191

OverviewBMC Performance Assurance supports data collection on AIX partitions running on the POWER5 (p5) and POWER6 (p6) servers. This data can be used for analysis, modeling, and Visualizer reporting. You can view performance data by physical system with breakdown by logical systems with either dedicated or shared processors using Analyze, Visualizer, and Perceiver. You can also perform “What-if...” analysis of CPU configuration changes using Predict, and include total physical and logical system utilization, which can be used for basic capacity planning exercises on partitioned servers.

Support for AIX hardware partitions

The collected system configuration data enables the reporting of specific information on the type of partition (LPAR, DLPAR, SPLPAR). For more information on these partition types, refer to “Overview of AIX hardware partitions” on page 11.

Analyze reports performance statistics for both the operating system level and the physical partition level, which enables you to look at the data from two points of view:

■ the individual AIX operating system (partitioned or stand alone) level, which provides resource utilization information presented in Analyze and Visualizer reports can be used for reporting, or as input for charge back calculations

■ the server level, based on system configuration data, which lets you analyze and model the full system view

Perceiver provides a number of views that enable you to see performance statistics for both the operating system level and the physical partition level,


Support for AIX workload partitions


Support for AIX workload partitions

IBM AIX workload partitions (WPARs) are available starting with AIX version 6.1. WPARs are similar in concept to Solaris Zones, in that there are two types of workload partitions: the global WPAR and the non-global WPAR.

What is supported for this platform

■ Investigate support for the WPAR Configuration and WPAR Statistics metric groups.

■ Data Analysis that reads and processes the key metrics, identifies and provides the relationships between objects to the database and the model.

■ Presentation of key metrics in BMC Performance Perceiver views and detailed metrics in IBM WPAR specific charts

■ Modeling of WPAR systems, each WPAR is represented as a workload in the model.

■ Visualizer charts that present WPAR specific views.

■ Collection, analysis, modeling and presentation of WPARs running within IBM hardware partitions (LPAR, DLPAR and SPLPAR).

What is not supported for this platform:

You cannot install the Perform Agent in a non-global WPAR, nor can you run a collector inside an AIX non-global WPAR.

Installation Considerations for AIX

Installation considerations for AIX hardware partitions

Note the following requirements for installing BMC Performance Assurance in an AIX partitioned environment:

■ You must install the Perform collector on a logical system partitions running AIX to gather detailed workload information from the operating system. This ensures proper identification of SMT as well as access to the metrics required to properly report on LPAR resource consumption.

Installation considerations for AIX workload partitions


For complete installation instructions, refer to the BMC Performance Assurance Getting Started guide.

■ You must also enable the appropriate security access from at least one logical partition to the Hardware Management Console (HMC), so that the collector can gather physical system configuration information.

■ You can place the LPARs in separate Manager policies, but all LPARs must be populated to the same Visualizer database (Visualizer 4.2.06 or later recommended).

■ If you choose to split LPARs from the same physical system across multiple policies, at least one LPAR for each physical system in each policy must be configured to collect the HMC configuration data.

■ To collect Disk Statistics from the AIX partitions, the libperfstat level must be at ML1 for AIX 5.3.

To enable this access to the HMC, complete the configuration steps described in the following section.

Installation considerations for AIX workload partitions

■ You must install the Perform Agent in the global zone. ■ You cannot install the Perform Agent inside a non-global WPAR. ■ Visualizer graph support requires version 4.2.05 with latest patch.■ BMC Performance Perceiver support requires version 7.5.10 and higher.

Configuration Requirements BMC Performance Assurance collects the configuration data from the HMC remotely, using SSH, which is the only method the HMC allows for remote command execution. This Physical Partition Configuration information collected from the HMC includes information about the HMC, the systems managed by the HMC, and the LPARs in those systems.

To enable data collection, however, there are several configuration tasks that you must perform prior to collecting data. These steps are necessary to enable remote execution of commands on the HMC, without being prompted for a password.

The configuration tasks are:

Enable Remote Command Execution on the HMC


1 Enable Remote Command Execution on the HMC

2 Configure the AIX environment either manually, or by using the Perform Configuration file

3 Verify that the HMC was added to the list of known hosts

4 Verify the settings in the Perform SSH Config file

You can perform these tasks manually, or by executing a script provided by BMC Performance Assurance. These tasks are described in the following sections.

Enable Remote Command Execution on the HMC

You must enable the remote command execution option so that the Perform collector can run commands remotely, using the ssh command. To enable remote command execution, perform the following steps on the HMC:

1 In the Navigation area, click the HMC Maintenance icon.

2 In the Contents area, double-click the System Configuration icon.

3 In the Contents area, click Enable / Disable Remote Command Execution.

4 Select the Enable ssh check box.

5 Click OK.

For more details, please refer to the System Configuration chapter in the IBM manual HMC for pSeries Installation and Operation Guide.

NOTE HMC version 4.2.1 or later is a system requirement for BMC Performance Assurance to collect partition configuration information.

Configuring the AIX Environment using the Perform Configuration File



The user account that installed the BMC Performance Assurance product on the AIX partition must be authorized to execute commands remotely on the HMC, using keyed encryption passwords. Several configuration steps must be performed to enable this authorization, so that Perform can collect the Physical Partition Configuration data from the HMC. BMC Performance Assurance provides a configuration file (configure_SSH) that simplifies these configuration steps on the AIX partition. This file is located in the following directory:

Use this file to:

— simulate how BMC Performance Assurance collects the Physical Partition Configuration data from the HMC. This data could then be used to determine if SSH is configured properly for the Perform collector to gather the Physical Partition Configuration data.

— create the key files in $BEST1_HOME/local/setup/.ssh

— create an account on the HMC and copy of the public key over to that account

This script is designed to be run with the default settings, which will create the public and private key pair, connect to the HMC, create a user role on the HMC called HMCviewer, copy the public key to the HMC and verify that we can successfully collect data from the HMC.

To run the script, perform the following steps:

1 Change directory to the following location:

2 Type the following command:

However, you can override these default settings, by executing the script with any of the flags described in the following table:

$BEST1_HOME/bgs/scripts

cd $BEST1_HOME/bgs/scripts

$ ./configure_SSH -b /usr/adm/best1_7.5.10 -t rsa



Table 4 Available Options for the Perform SSH Configuration File

Flag Description

-H HMC Specifies the name or the IP address of the HMC that manages the AIX partition.

-b BEST1_HOME Specifies the location of the Best1_HOME directory. By default, this location is /usr/adm/best1_7.5.10

-d keyfile_directory Specifies the location of the key file directory. The key files are copied to Perform's SSH configuration directory, located in /usr/adm/best1_7.5.10/local/setup/.ssh/id_rsa.

-D Specifies the directory where SSH is installed. By default, BMC Performance Assurance searches for SSH in the /usr/bin directory. Use this option if you have SSH installed in a different directory in your environment (for example, in /usr/local/bin, or /opt/SSH/bin).

-h Provides help for the script options.

-p password Specifies the password for the HMC user that is connecting to the HMC. This option is the recommended method for identifying the password for the new HMC user account that is being created. This method provides a prefix which always clearly indicates the user password, as in the following example:

hmcviewer@ipaddress's password:

-r Removes an account on HMC. This option requires the hscroot password.

-s Disables the creation of the user role on the HMC (that is, use preexisting role).

-t keytype Specifies the type of keypair that is generated. Options are rsa or dsa.

-u HMC_USER Specifies the user name that the Perform collector uses to connect to the HMC. The default is hmcviewer.

NOTE When you run the script, you are prompted to provide a password if you did not use the -p option. This password is the new password for the new hmcuser being created.

Manually configuring the AIX Environment


Manually configuring the AIX Environment

You can also perform the following configuration steps manually, so that the system and the HMC can communicate via SSH:

■ Install SSH on the partition (if it is not already installed) ■ Generate the RSA or DSA keypair (the public and private keys) for the partition■ Enable remote command execution (if not already enabled) on the HMC■ Create a user with Viewer privileges on the HMC■ Copy the public key to the HMC account on HMC

The following IBM publications provide more information on using SSH with AIX:

■ Managing AIX Server Farms (IBM Redbook)

■ Effective System Management Using the IBM Hardware Management Console for pSeries (IBM Redbook)

■ Hardware Management Console for pSeries Installation and Operations Guide

■ AIX 5L Support for Micro-Partitioning and Simultaneous Multi-threading (IBM White Paper)

Install SSH on the AIX Partition

SSH is required to collect Physical Partition Configuration information from the HMC. You can see if SSH is installed on the system by typing the following at the command line:

This command returns the SSH version level, and other information. If SSH is not installed, the software to install the SSH is located on the updated AIX Bonus Pack, for AIX 5L Version 5.1 and later.

For further information about setting up SSH on AIX, refer to Chapter 4: Secure network connection on AIX in Managing AIX Server Farms.

You can also visit the following IBM website for more information on SSH on AIX:

$ ssh -V

http://oss.software.ibm.com/developerworks/projects/SSHi

Verify that the HMC was added to the list of known hosts


Manually generate the RSA or DSA keypair (the public and private keys)

Use one of the following methods to generate the public/private keypair:

Use the ssh-keygen utility to generate the keypair. The method for generating keys may be different between various Secure Shell (SSH) implementations.

You must be logged on as the user that installed BMC Performance Assurance to create the keypair.

Manually create a user on the HMC

BMC Performance Assurance requires a user on the HMC, to initiate data collection on the AIX systems running on the partitions managed by the HMC. Have the HMC system administrator create a standard HMC user with the lowest role (Viewer) for Perform to use for data collection. A user that is assigned to the Viewer role has access to HMC information, but cannot change any of the configuration information.

You can also identify which HMC user to use in the Collect configuration file (Collect.cfg). For a complete description of options in this file, refer to the BMC Performance Assurance Getting Started guide.

If you are using multiple HMCs, you can also identify which HMC to use in the Collect.cfg file.

Manually copy the Public Key to the HMC User Account on the HMC

The public portion of the RSA or DSA keypair must be copied to the key file in the user’s home directory on the HMC.

On the AIX client system, use the secure copy command (scp) to move the authorized_keys2 file to a temporary file on the HMC. Log in to the remote server using the ssh command, and then concatenate the transferred user public key file to the $HOME/.ssh/authorized_keys file. For complete instructions, refer to the chapter on Secure network connection on AIX in the IBM Redbook Managing AIX Server Farms.

Verify that the HMC was added to the list of known hosts

Verify that the HMC name has been added to the list of known hosts in the known_hosts file located in the $BEST1_HOME/local/setup/.ssh directory.

Managing the performance of AIX hardware partitions


In the Config file located in $BEST1_HOME/local/setup/.ssh, verify that the settings for IdentityFile and UserKnownHostsFile are correct for your environment. The following list shows the options and default settings in the Config file:

■ NumberOfPasswordPrompts=0■ ChallengeResponseAuthentication=no■ PasswordAuthentication=no■ StrictHostKeyChecking=no■ IdentitiesOnly=yes■ IdentityFile=/usr/adm/best1_7.5.10/local/setup/.ssh/NAME_OF_PUBLIC_KEY■ UserKnownHostsFile=/usr/adm/best1_7.5.10/local/setup/.ssh/known_hosts

Managing the performance of AIX hardware partitions

Collecting data from AIX hardware partitions

There are two separate data sources for the partition configuration information:

■ One set of data is collected within the AIX partition. It provides a view of the individual AIX operating system (partitioned or stand alone), which contains resource utilization information.

■ The other set of data is collected from the HMC. It provides a global view of all partitions on the physical system, based on the system configuration data.

You can collect data from AIX partitioned systems as you would other computers. These methods are:

■ for ad-hoc data collection, use the best1collect command line executable

■ for automated data collection, create a Manager run using the BMC Performance Assurance console on either UNIX or Microsoft Windows.

These data collection methods are fully described in the BMC Performance Assurance Implementation Guide for UNIX, or by referring to the online Help.

Collecting data from AIX hardware partitions


Enabling or Disabling Data Collection

The collection of the Physical Partition Configuration data from the HMC is enabled by default. The default is to collect Physical Partition Configuration once per hour.

An option (BEGIN_HARDWARE_PARTITION) in the Collect configuration file (Collect.cfg) can be used to disable the collection of this metric group. If you chose to disable the collection of this data, a status message is sent to notify the Perform Agent that the group has been disabled. This message is displayed in the Data Collection Status report, available through the Manager component.

The following example shows the various options for controlling the collection of data from an AIX partitions.

The following table provides a brief definition of the options.

# # BEGIN_HARDWARE_PARTITION# ENABLE = "FALSE"# BEGIN_HMC# HMC_NAME = "hmcconsole"# HMC_USER_NAME = "viewer"# HMC_MANAGED_SYSTEM = "Server-9113-550-SN109663D"# SSH = "/usr/bin/ssh"# END_HMC# END_HARDWARE_PARTITION

Flag Description

HMC_NAME Specifies the name or the IP address of the HMC that manages the AIX partition.

HMC_USER_NAME Specifies the user name that the Perform collector uses to connect to the HMC. The default is hmcviewer.

HMC_MANAGED_SYSTEM Specifies the name of the partition for which data is to be collected.

SSH Specifies the directory where SSH is installed. By default, BMC Performance Assurance searches for SSH in the /usr/bin directory. Use this option if you have SSH installed in a different directory in your environment (for example, in /usr/local/bin, or /opt/SSH/bin).

Displaying data from AIX Partitioned Systems


Displaying data from AIX Partitioned SystemsYou can access performance data about the partitioned systems by using any of the following components, using the Perform Microsoft Windows console:

■ Investigate■ Analyze ■ Visualizer■ Perceiver

The following sections describe how to display metrics in Investigate, interpret the data using Analyze, and how to display Visualizer and Perceiver graphs.

Viewing AIX partition metrics in Investigate

The following sections discuss the metrics you can view in Investigate when you drill down on an AIX partition.

Viewing system-related metrics in Investigate from an AIX partition

The definitions for several of the metrics in the System Configuration metric group are different when used in an AIX partitioned environment. These differences are indicated in the table below. The last metric listed in the table, CPU Multi Threading, only applies to AIX SPLPARs.

Metric Description

Number Processors Normally this value represents the number of logical processors. However, for AIX 5.3 systems with SMT enabled, the value is actually twice the number of physical processors for LPARs and DLPARs, and twice the number of virtual processors allocated to the SPLPARs.

Max Number Processors

For LPARs and DLPARs, this value represents the number of physical processors available to the partition. For SPLPARS, this value represents the number of virtual processors.

Hardware Serial Number

This value is used as a unique identifier for the partitioned server (physical system).

Viewing AIX partition metrics in Investigate


System Statistics metric group: Shared Pool Idle Time

The Shared Pool Idle Time metric is specific to AIX SPLPARs. It displays the total time (in seconds) that the CPUs in the shared processor pool were idle.

For this metric to be valid, all partitions must have the authority to access the shared pool idle time. To verify that partition has the correct access authority, perform the following steps:

1 From the HMC, select Partition Properties.

2 Click the Hardware Tab.

3 Click the Processor/Memory Tab.

4 Ensure that the “Allow shared processor pool utilization authority” check box is selected.

Viewing Physical Partition Configuration Metrics in Investigate from a AIX partition

The following table displays metrics that are specific to AIX partitions in the Physical Partition Configuration metric group:

Partition Type For AIX partitioned systems, this metric indicates the partition type. Possible values for AIX are: LPAR, DLPAR, or SPLPAR. Other values are reported for other vendors partitioned systems from other OS vendors, or for standalone servers.

CPU Multi Threading For AIX 5.3 systems, this value indicates whether or not the partition is running in Multi-Threading mode. A value of one (“1”) if the processor is running in Multi-Threading mode.

Metric Description

Partition Type For AIX partitioned systems, this metric indicates the partition type. Possible values for AIX are: LPAR, DLPAR, or SPLPAR. Other values are reported for other vendors partitioned systems from other OS vendors, or for standalone servers.

Pool Id For AIX SPLPAR only, this value is the ID of the shared processor pool.

Sharing Mode For AIX SPLPAR only, this value indicates whether the partition is running in a Capped or Uncapped mode. A value of “1” indicates Capped mode; a value of “0” indicates Uncapped mode.

Metric Description

Key Analyze reports to review for AIX partitions



Using Analyze, you can view data from all three AIX partition types: LPAR, DLPAR, and SPLPAR. From this data, you can determine the type of partition, correlate the data from different sources to establish the physical to logical system relationship, build a partitioning model for use with Predict, create a hierarchical report for partitioned systems, and generate a Visualizer input file.

The reports provided by Analyze enable you to:

■ View partition configurations based on physical system and breakdown by logical systems.

■ View system performance statistics based on physical system and breakdown by logical systems.

■ Create a physical system and build the relationship between logical systems and physical system in Predict model.

■ View and model physical processors properly when SMT is enabled, and view physical CPU utilizations for the SMT enabled partitions.

The following sections describe the reports to investigate when analyzing data from AIX partitioned systems.

Analyze Physical System Summary Report

The Physical System Summary report provides information specific to AIX hardware partitions.

For IBM Power 5 servers, this report contains LPAR, DLPAR, and the shared processor pool. The SPLPAR information is reported in separate report, as described in “Shared Processor Partition Report for SPLPARS” on page 142.

Entitlement For AIX SPLPAR only, this value defines the portion of physical processor resource that is allocated to the partition, along with the defined number of virtual processors. Entitlement is configured in terms of processing units (PU). One (1.0) PU equals the capacity of a full processor.

Weight For Uncapped AIX SPLPARs only, this value specifies the uncapped weight of the partition.

Metric Description



Figure 59 Analyze Physical System Summary Report for an AIX Partition

The following table describes each of the columns in the report.

TIP When Analyze detects a dynamic configuration change to the partition within the analysis interval, in particular a change to the number of processors, Analyze issues a warning message and uses the maximum number of processors value for the whole interval for modeling and reporting. However, Analyze reports the number of processors as a fraction to Visualizer database. This number reflects the fraction of the interval the that the partition had the maximum number of processors.

Column Description

Physical System The name of the server (host). For BMC Performance Assurance console version 7.3.00, this name matches the Hardware Serial Number in the System Configuration within the partition.

In version 7.5.10, this name is the physical system name (for example, ILM-P570-07). No more than 15 characters are displayed.

Logical System This value is used to identify the partition, the name of the logical system for LPAR and DLPAR, or the pool ID for shared processor pool.

System Type The specific partition implementation. For AIX, the possible values are LPAR, DLPAR, SPLPAR. Other values are reported for other vendors partitioning systems or standalone servers, such as DSD (Oracle), nPAR, vPAR, nPAR/vPAR (HP).

Active Processors Indicates the number of physical processors currently used by the partition. For the physical system, this field is the sum of all partitions.



Shared Processor Partition Report for SPLPARS

This report, for SPLPARs only, also uses the two-tier hierarchy. The shared pool ID for each SPLPAR is also shown in this report. This report displays two types of CPU utilization: one relative to the number of processors configured for the partition (virtual processor), and one relative to the SPLPAR entitlement. The entitlement value enables you to see, how much of the capacity designated for each SPLPAR actually is used.

This report uses a two-tier presentation: logical systems and the shared processor pools are presented as children of the physical system. SPLPARs are presented as standalone systems, along with the respective shared pool ID. Partitions with the same share pool id are grouped together.

Dedicated Processors

The number of dedicated physical processors available to the partition. For physical system, this field is the sum of all partitions.

CPU Model The system vendor and model. Only reported for the physical system.

Memory The size of total physical memory (of the physical system) or the size of allocated memory for logical systems. Reported in Mbytes.

CPU Utilization The percentage of CPU usage (out of 100) times number of active processors. For shared processor pool, it is calculated based on the Shared Pool Idle Time, instead of accumulation of CPU usage of all SPLPARs in the pool.

Out of The number of active processors times 100. The logical system CPU utilization relative to number of physical processors shall be reported as out of either:

■ Number of dedicated processors for LPAR or DLPAR, or■ Number of virtual processors for SPLPAR

Multi-Threading Indicates the type of CPU multi-threading technology, if it is enabled. For IBM AIX partitions, this value is SMT. SMT (simultaneous multi-threading) is an enhancement in the POWER5 processor design to allow for improved overall hardware resource utilization. SMT technology allows two separate instruction streams (threads) to run concurrently on the same physical processor, improving overall throughput.

Column Description



Figure 60 Shared Processor Partition Report for SPLPARS

All of the following columns, except the Physical System name, apply to the shared partition, not the physical system. The following table describes each of the columns in the report:

Column Description

Physical System The name of the physical system (the Host Server).

Logical System The name of the logical system (for SPLPARs).

Partition Type The partition implementation.

Pool ID The ID of the shared processor pool.

Virtual Processors The number of virtual processors (shared pool processors) configured for the partition.

CPU Utilization The percentage of CPU usage (out of 100) times the number of virtual processors.

Entitlement Indicates the Entitlement value for the SPLPAR. The Entitlement, along with the defined number of virtual processors, defines the physical processor resource that will be allotted to the partition. Entitlement is configured in terms of processing units (PU). One (1.0) PU equals the capacity of a full processor. For example, a SPLPAR with 1.2 PU of entitlement and 4 virtual processors running in a 3-processor pool. Each virtual processor will get 0.3 PU of processing from the 3 processors in the share pool.

Entitlement Utilization

The percentage of CPU usage out of its Entitlement. This percentage specifies the uncapped weight of the partition. It is valid only for an uncapped SPLPAR.

Displaying AIX hardware partition CPU usage in Visualizer



To view AIX hardware partition data from Visualizer, complete the following steps:

1 Click Database=> Select and select the database into which you populated the AIX partition data.

2 Click Database=> Detail and choose the data for the graph. Ensure that you select PowerVM from the Virtual Type drop-down list.

3 From the Graphics menu, choose AIX Partition => AIX Partition Hierarchy.

Sharing Mode Indicates whether the partition is running in a capped or uncapped mode. Possible values for this column are either Capped or Uncapped.

A capped SPLPAR cannot use more PU than it is entitled to. An uncapped SPLAPR can use more PU if there is spare capacity in the shared pool.

Multi-Threading Indicates the type of CPU multi-threading technology, if it is enabled. For IBM AIX partitions, this value is SMT. SMT (simultaneous multi-threading) is an enhancement in the POWER5 processor design to allow for improved overall hardware resource utilization. SMT technology allows two separate instruction streams (threads) to run concurrently on the same physical processor, improving overall throughput.

Column Description



Figure 61 AIX Partition Hierarchy

Another graph to look at is the AIX Partition % Capacity Used graph. From the Graphics menu, choose AIX Partition => AIX Partition % Capacity Used.

Figure 62 AIX Partition % Capacity Used

Displaying AIX hardware partition CPU use in Perceiver


Displaying AIX hardware partition CPU use in Perceiver

You can also use BMC Performance Perceiver to view performance data for IBM Power VM partitions.

The CPU Profile view under the IBM Power VM Host Summary shows information on an IBM Power VM host and its partitions.

Figure 63 AIX hardware partition CPU use in Perceiver

After you select a host, the following tables and charts are available.

Metric Description

Host Partition Info Displays information of each of the partitions configured on the selected host, including:

■ Partition name■ Node name■ Partition type■ Pool ID■ Amount of entitlement■ Number of processors

% CPU Capacity Used Displays % Physical Used Total, % Virtual Used Average, % Entitlement Used Average and % Dedicated Used Average for the selected host.




FAQs for CPU reportingThis section addresses questions encountered by analysts.

How does SMT affect the number of CPUs?

A related question is, “Will I see double the number of processors I really have with simultaneous multithreading (SMT)?” BMC Performance Assurance aggregates the individual logical processors to physical processors before the data is presented in Analyzer, Predictor, Visualizer, or Perceiver . This ensures that any "per processor" reporting will be consistent, regardless of whether or not SMT is enabled. Investigate displays the raw data, so it depends exactly where you are looking what to expect.

The following table summarizes the relationships between the various metric groups and how the data is presented.

Top 10 Partition Virtual Capacity Used

Displays the Top 10 Partition Virtual Capacity Used for the selected host.

Top 10 Partition Entitlement Capacity Used

Displays the top 10 Partition Entitlement Capacity Used for the selected host.


Provides the system configuration information that is available for the IBM Power VM host, including:

■ System Model■ Host Name■ System Description■ Processor Model■ Processor Description■ Processor Clock Rate■ Number of Configured Processors■ Number of threads per core■ Number of cores per socket■ Rating■ Rating Type■ Multi threading type■ Amount of Configured Memory

Metric Description

Where do I start? What view is "correct"?



There are two necessary perspectives on a partitioned system:

■ the overall physical system■ the individual LPARS

NOTE Although CPU Utilization can be compared between UDR (sum of User and System from CPU Statistics metric group) and Analyzed data, CPU non-utilization; for example, CPU Wait and Idle cannot be directly compared between UDR and Analyzed data.

UDR data Analyzed Data

Metrics affected by SMT InvestigatePerceiver (udr datasource)Metric group/metric label

AnalyzerPredictorVisualizerPerceiver (vis datasource)

Number of processors

Logical processors (i.e. twice physical)

System Configuration/Number of ProcessorsSystem Configuration/Max Number ProcessorsCPU Statistics/number of processors displayed

Analyzer/Browse or chart CPU Util per CPU data function only

Physical processors System Configuration/Processors in PoolSystem Configuration/EntitlementPhysical Partition Configuration/Total Processors Physical Partition Configuration/Active Processors

All

CPU Utilization

Per Physical Processor CPU Statistics/any metric: half of Analyze/PredictSystem Statistics/CPU Utilization

Visualizer onlyPredict alerts only

Total CPU Statistics/any metric All

NOTE Beginning with the 7.5.00 console, Visualizer will show the correct total frame utilization only if all LPARS have been instrumented with collectors. See What are best practices' for performance reporting/analysis for this particular environment? for a discussion of data requirements.



The first perspective allows you to see the entire environment and assess overall capacity consumption. The CPU Use Hierarchy (or Partition CPU Use Hierarchy in 4.2.2) is a convenient graph to use, and you want to select the %Proc view, i.e. the view of CPU consumption across all LPARs, relative to the capacity of the entire system.

Figure 64 Selected CPU Use Data - overall physical system

In this case, the graphic indicates that a maximum of about 25% of the overall capacity is in use. Note the SMT designation in the upper left hand corner - this identifies this as a system with SMT enabled, but as discussed earlier, the number of processors being used here is the actual number of physical processors present, not the number of logical CPUs which are reported on in other tools. The number of physical processors can be viewed in a couple of places, but again, the CPU Use Hierarchy graphic has this information, as shown in Figure 65 on page 150.



Figure 65 CPU Use Hierarchy

The 1600 %nPProc indicates that 16 physical processors are configured throughout this day.

But how are the individual LPARs doing? The overall physical system view shows relative consumption of the CPU by each, but it doesn't relate it to their allocations of CPU capacity. Thus, the second view is needed for this, which is how much is each using with respect to its allocated capacity. Again, the CPU Use Hierarchy graphic can be used to see how much of each LPAR's total virtual processing (%LProc) capacity is in use, as shown in Figure 66 on page 151.



Figure 66 LPAR's %LProc capacity in use

Even the view shown in Figure 66 is not complete when considering SPLPARs, which are further constrained by the specified entitlement, and whether or not the LPAR is capped (i.e. absolutely limited by the entitlement) or is uncapped (i.e. free to exceed its entitlement if resources are available). This relationship can be viewed on a per LPAR basis by simultaneously graphing the %Entlmnt and the %Total CPU usage. Alternatively, multiple LPARs can be viewed simultaneously using a custom Visualizer .vgd file (available from Customer Support at ftp://ftp.bmc.com/pub/visualizer/vgd/) , showing what % of the entitlement is being utilized.

For uncapped LPARs, this value can exceed 100% when demand exceeds the entitlement and resources are available, as shown in Figure 67 on page 152.

ftp://ftp.bmc.com/pub/visualizer/vgd/



Figure 67 Percent Entitlement and the %Total CPU usage

An integrated view of the LPAR is also available, simultaneously showing all three allocations. Figure 68 on page 153 shows what portion of the allocated capacity is in use.

■ Physical processors (total for the system)■ Virtual processors (for that LPAR)■ Entitlement processors (for that SPLPAR)



Figure 68 Portion of the allocated capacity in use

Another useful view is across all LPARs within a physical system. The current definition for this graphic shows total physical processor capacity utilized, and average virtual and entitlement utilization.



Figure 69 LPARs within a physical system

Also, using this graphic over time, either for individual LPARs or for the physical system as a whole, gives the analyst a complete overview of what's happening and what the long-term trends are. Of course you can drill down as appropriate to find out what the underlying cause is for a significant change in utilization. Also, there are supplemental graphs available for identifying individual LPARs that need further study - Top 10 Entitlement Used and Top 10 Virtual Used. See Figure 70 on page 155 and Figure 71 on page 156.



Figure 70 Top 10 Entitlement Used



Figure 71 Top 10 Virtual Used

The %Physical_Used (from the AIX Partition CPU Usage Hierarchy graphic from the custom vgd) or %Proc (from the CPU Use Hierarchy/Partition CPU Use Hierarchy graphic) are useful when you need to present to less technical management,. Only when the absolute physical consumption reaches the danger zone does management need to spend money on additional hardware - problems with Entitlements and Virtual processor allocations require technical expertise to change the existing allocation scheme.

Figure 72 on page 157 depicts an example showing the overall utilization of each physical frame, %Physical_Used (using the AIX Partition CPU Usage Hierarchy graphic from the custom vgd)



Figure 72 Overall utilization of each physical frame

Another useful perspective for environments making substantial use of the Shared Pool, is from the pool perspective . Views are available for the pool as a whole, as well as by SPLPAR.



Figure 73 Shared Pool from the pool perspective

A "drill down" on an SPLPAR now shows all four perspectives simultaneously.

Figure 74 Drill down on an SPLPAR



When preparing to do capacity planning for this environment, viewing partition use expressed as SPECints, particularly across physical systems, is the perfect way to see exactly how much is being consumed and what size physical system will be needed to support any particular combination of LPARs.

Figure 75 SPECints used

This view, by SPECints, is the basis for Predict modeling, which is discussed in a later section. This view is also the basis for Virtualization Planning or Visualizer sizing techniques, which can be used to:

■ establish the best selection of baseline modeling interval(s) or■ perform high-level system sizing for either initial consolidations or follow-on

consolidations to existing partitioned systems.

How do I interpret the name of the physical system?


How do I interpret the name of the physical system?

The only name available from collectors dated prior to 17 May 2006 is the hardware serial number. In the example above, this is "IBM_0210A8A3D". Collectors dated 17 May and later collect both the hardware serial number and the managed system name. When this data is processed by consoles dated 17 April 2006 and later, the managed system name will be reported as the physical system name, e.g. "ILM-P570-07" (only if the managed name is 15 characters or less. The 15 character limit is first enforced in consoles dated 25 August 2006).

For Visualizer reporting, the individual LPARs can be defined as a group, which effectively renames it for all Visualizer reporting. In this example, the group name was specified as "ILM-P570-07" (or "PS_LPARS", i.e. PeopleSoft LPARs, shown in other examples), and that name would be shown in the title of the report (but would not change the label of the physical system in a hierarchy graphic).

If the collector cannot be updated, it is possible to physically alter the .vis files before they are populated. A simple Find and Replace in an editor for each .vis file can replace the serial number with the desired name (and the physical system name occurs only once per LPAR per .vis file). This would change the name everywhere in Visualizer, and the group naming method wouldn't be necessary. Sample results for this method are shown above in the "% Capacity Used" and "SPEC_Used" graphs.


This is no different for LPARs vs. any other UNIX system.

In traditional UNIX dispatching (in a non-partitioned environment), dispatching of active processes is distributed relatively uniformly among all configured processors. But if there are a limited number of processes using resources, it's not possible to distribute them among all of the available virtual CPUs.

Figure 76 on page 161 depicts an example where the use of individual processors is very uneven: virtual processor 2 seems to be doing most of the work



Figure 76 Uneven individual processors

This can be explained when the CPU utilization of the individual processes is explored - WSH generates the majority of the CPU load, and there is exactly 1 WSH process. See Figure 77 on page 162

When I look at "per logical processor" usage, it's very uneven. Why?


Figure 77 CPU utilization of individual processes

Different from traditional UNIX dispatching is virtual processor folding and the AIX Partition Load Manager (PLM) (pages 49 and 338-339, 393 in http://www.redbooks.ibm.com/redbooks/pdfs/sg247940.pdf). This feature dynamically adjusts how many of the virtual processors configured to the SPLPAR are used for actual work - if utilization is low, the number of virtual processors is decreased by 1 (per second) and if utilization is high, the number of virtual processors available is increased by 1. So under utilized LPARs will actually use many fewer of the virtual processors, and this could also produce uneven distribution of processor use shown in the example in Figure 77.


When viewing un-aggregated logical processor usage when SMT is enabled (see “How does SMT affect the number of CPUs?” on page 147), the relative activity within each pair of logical processors is usually very uneven, since the "second" processor only shows activity when SMT actually occurred, which is not all the time. The coloration of the hierarchy chart clearly shows relationships between the logical processors, e.g. 0 with 1, 2 with 3, and so on.

http://www.redbooks.ibm.com/redbooks/pdfs/sg247940.pdf





Figure 78 Processor Hierarchy

Particularly, see how when activity is relatively high on 0 for pahrmd04 (the red and yellow cells), there is also activity on 1, but of lesser amounts (shades of green). But when activity is lower on 0 (green) there is little or no activity on 1. There are similar relationships between 2/3, 4/5, and 6/7. Figure 79 on page 164 shows the relationship of CPU activity between 0 and 1 graphically.

Modeling AIX partitioned systems


Figure 79 Selected Processor Data

For a good discussion of how SMT works, go to http://www-03.ibm.com/servers/eserver/iseries/perfmgmt/pdf/SMT.pdf. The document at that link explains why the data in Figure 79 looks like it does.

Modeling AIX partitioned systemsWith Predict, you can perform any of the following tasks as a part of your “What-if...” modeling analysis of a partitioned system:

■ Reassign processors among partitions.■ Move partitions from one hosting system to another system.■ Move a stand-alone computer to a partition.■ Change a partition to a stand-alone computer.

The Predict Physical System Summary report provides information on the configuration of the hardware partition, and specific information on each computer in the partition. An example of the report is shown in Figure 80.

http://www-03.ibm.com/servers/eserver/iseries/perfmgmt/pdf/SMT.pdf

Evaluate the model


Evaluate the model




■ verify or correct the information in the model■ identify any resources that might be exceeding your service level objectives

For general information on calibrating models and creating valid baselines, refer to the Predict online Help.

Review the Physical System Summary report

When reviewing the Physical System Summary report, note the following:

■ The Physical System total line shows the total physical processors expressed as a percentage (% Utilization out of), For example, a value of 1600% translates to 16 physical processors, and the total CPU Utilization across all partitions is relative to a maximum of 1600%. The % Utilization out of value for each SPLPAR shows the number of virtual processors expressed as a percentage. For each DLPAR it shows the number of dedicated physical processors expressed as a percentage.

■ Additionally, each SPLPAR shows Entitlement as the number of physical processors, and % Entitlement as the portion of the entitlement being utilized.

■ Physical CPU processors are assigned to logical systems or share pools as a dedicated resource.

■ Logical systems with dedicated processors own all of that CPU capacity; no other logical system or share pools can use those resources.

■ Processors assigned to a share pool can be shared between SPLPARs running inside the pool.

TIP Evaluating a logical system is similar to evaluating a standalone system, in regard to guidelines and thresholds. Workloads are created on the logical system just as on a standalone system.

Review the Physical System Summary report


■ Memory is always dedicated to the logical system regardless if it is LPAR or SPLPAR.

■ The total physical system CPU utilization will be the sum of all the logical system with dedicated processors plus all of its share pool CPUs.

Figure 80 Predict Physical System Summary report for an AIX Partition

The following table describes the columns in this report. You may need to scroll to the right to see some of the report columns.

Column Description

Physical System The name of the Host Server in the model.

Logical System The name of the logical volume in the model. The name has to be unique for a given computer. Two logical volumes on different computers can have the same name.

Operating System The operating system running on the computer.

Partition Type The specific partition implementation. For AIX, the possible values are LPAR, DLPAR, SPLPAR. Other values are reported for other vendors partitioning systems or standalone servers, such as DSD (Oracle), nPAR, vPAR, nPAR/vPAR (HP).

CPU Model The type of CPU, usually identified in terms close to those the vendor would use.

Vendor The name of the vendor (example IBM, HP) for the CPU model. A model name is not complete without the vendor name. Predict uses this field to decide what algorithms to use for modeling the system.

Perform “What if...?” investigations of AIX partitioned systems


For more information on the Physical System Summary report, refer to the Predict online Help.

Perform “What if...?” investigations of AIX partitioned systems

After you have established a valid baseline model, you can change the system model and investigate how the changes will affect system performance.

For general information on modeling and “What if...?” analysis, refer to the Predict online Help or the BMC Performance Assurance for Microsoft Windows Implementation Guide for Microsoft Windows.

CPU Utilization For a physical system, this value includes the Unaccounted CPU utilization of the shared pools, in addition to the utilization of all of the partitions.

For logical systems, this number is the percentage out of the total number of online processors assigned to the logical system. In the case of AIX SPLPAR, this number is the percentage out of the virtual processors assigned to the logical systems.

% Utilization out of For all logical system except SPLAR it is the number of online processors times 100. For an SPLAR, it is the number of virtual processors times 100. For a physical system, it is the sum of the online processors of all the logical partitions times 100.

% Entitlement The percentage of the Entitlement that was used by this logical system.

Entitlement The maximum allocation of CPU from the shared pool that can be allocated to this partition. Entitlement is configured in terms of processing units (PU). One (1.0) PU equals the capacity of a full processor.

Cap For an SPLPAR, there is Capped or Uncapped entitlement. An uncapped system can use more processing units if there is spare capacity in the pool, meaning that it can use more than it is entitled to. Possible values are Yes (Capped) or No (Uncapped).

Queue Length The average number of transactions that are receiving service as well as those that are waiting to receive service.

Throughput The transaction throughput in transactions per hour. The transactions counted in the throughput are those which ran on this computer, whether they are called by local or remote users or transactions.

Column Description

Scenario for modeling data from an AIX partition


The following section investigates adding a SPLPAR to an existing partitioned system, and the potential performance benefits.


The East Coast Sales server is a 20-CPU IBM POWER5 server responsible for running components of multiple business critical applications. This server has been partitioned into three AIX systems, split by region: the Northern, Central, and Southern partitions. The icon under the computer tree shown below shows the three partitions, after the icon for the server was expanded.

One of the partitions has dedicated processors, and two have shared processors grouped into multiple share groups called pools. The LeadTracker application, which the sales personnel use to keep tabs on potential deals, is not used consistently during the week, but is heavily used at the beginning of each week. Perhaps adding a SPLPAR to the partition would be a good solution to alleviate the unique performance needs of this application.

The following example illustrates the process for exploring the effect of adding an additional SPLPAR to the group.

1 Collect data on each of the three AIX partitions.

2 Identify good baselines for modeling (those periods with consistent usage).

3 Characterize the workloads in Analyze—paying particular attention to those workloads which comprise overhead. This process relates system processes to the actual business applications or services. For more information on workloads, baselines, and models, see the online Help or the BMC Performance Assurance for Microsoft Windows Implementation Guide for Microsoft Windows.

4 Open the model in Predict and evaluate it.

5 Review the CPU utilization for each of the major application workloads in the Predict Physical System Summary report (Figure 80 on page 166).



6 Create a new partition on the physical system by completing the following steps:

A Right click the physical system, and select New Logical System. The New Logical System wizard is displayed.

B Click Next on the Welcome page, and then follow the instructions on the wizard to create the new logical partition. As shown below, add the name, description, and partition type (in this example, SPLPAR) on the Logical System Name page. Click Next.

C On the Shared Pool page, select whether you want to use an existing share pool, or create a new one. For this example, we will use the existing share pool. Click Next.

Additional scenarios


D On the Logical System Configuration page, specify the configuration settings for the new SPLPAR.

— Specify the number of virtual processors that will be available to the partition. Refer to the online Help for more information on the Auto-calibration option.

— For an SPLPAR, you can select Capped or Uncapped entitlement. An uncapped node can use more processing units if there is spare capacity in the pool, meaning that it can use more than it is entitled to.

— Entitlement is used to specify the amount of CPU capacity that can be used. It is specified in terms of processing units (PU). One PU equals the capacity of a full processor. The sum of entitlements for all logical nodes within a pool cannot exceed the number of online processors for the pool.

— Click Next.

E On the Utilization Objectives page, set the guidelines and thresholds for acceptable performance for the virtual processor, and optionally the paging rates. Click Finish. The new SPLPAR is now displayed in the tree, as shown below.

F Assign work to the new SPLPAR by right-clicking the desired workload (in this example, the LeadTracker workload) and selecting Properties. Click the Users tab and complete the Users per computer section to include the SPLPAR_LT computer and to route activity to the new SPLPAR.

7 Evaluate the result, tuning as necessary. Review the CPU utilization for each of the major application workloads in the Predict Physical System Summary report (Figure 80 on page 166) and compare the results to the initial version of the report, prior to creating the new SPLPAR.

Additional scenarios

With data collected and analyzed from the AIX partitioned systems, you can also perform other “What if...?” scenarios, such as:

■ What would happen to performance if I reassign processors among partitions?

■ What if I move an existing workload from an existing partition to another partition?

FAQs for Predict Modeling of AIX partitions


■ What if I move a partition from one hosting system to another system?

■ What if I move the workloads from a stand-alone computer to a partition?


This section answers commonly asked questions regarding modeling SPLPARs. Physical system/LPARs.

How do I check that modeling 'best practices' have been implemented?

1 Confirm that the baseline analysis contains all the important LPARs.

The definitive method for this is to compare the physical system configuration with the Analyze Physical System and Shared Processor Partition reports.

Figure 81 Analyze Physical System and Shared Processor Partition reports

Use UDRviewer (or printudr) on the Physical_System_Partition_Configuration metric group to obtain the complete configuration. There may be alternate sources of this information available, too.



Figure 82 shows sample UDRviewer output for Physical_System_Partition_Configuration (selected metrics).

Figure 82 Sample UDRviewer output

In this case, the comparison reveals that several SPLPARs are missing, all using Pool 0, which means that modeling and reporting for this configuration would be compromised (unless the LPARs sabsor01, dabsor01, and pavio07a have nothing actually running in them).



Another method for making the same observation is to compare the CPU Utilization shown for the Shared Pool, 161.66, with the total of the SPLPARS, 135.04 (128.52 + 4.93 + 1.59). Since the two values don't match, there is at least one additional SPLPAR generating significant CPU activity. Alternatively, if you have a Predict model, you can view the amount of CPU utilization which is not represented by a partition which was explicitly collected. See “How does Predict represent the shared pool (for SPLPARs)?” on page 176 for an example.

2 Confirm that the CPU model is properly identified for both the physical system (Analyze Physical System report) and the logical systems (Analyze Hardware Summary report)

Figure 83 Analyze Physical System and Hardware Summary reports

A CPU model with "SMT" in its label is almost always the appropriate type of IBM Power 5 CPU as AIX defaults to using SMT whenever possible. A User Translation Table mapping is usually required as the default Translation Table mapping is conservative, and indicates non-SMT:

Name="IBM,9117-570",VendorID=IBM,Rate=1900,Alias=p5-570@1900,FreqTolerance=1

So a User Translation table mapping changing this to SMT would be:

Name="IBM,9117-570",VendorID=IBM,Rate=1900,Alias=p5-570-SMT@1900,FreqTolerance=1



In the example reports in Figure 83, there is no published rating on spec for a p5-570-SMT@1650, so both a User Hardware Table entry and User Translation Table entry are required. Contact Customer Support for assistance with CPUs which are not published by spec.org, and thus are not in the default Hardware Table.

Which reports should I look at to understand what's happening at the CPU?

This discussion parallels the discussion in the CPU reporting section. You only need to know where to find the corresponding views.

As explained in “How do I check that modeling 'best practices' have been implemented?” on page 171, there are two necessary perspectives on a partitioned system: (1) the overall physical system and (2) the individual LPARs. You can use Visualizer graphics to see these views as described above and the Predict report, Physical System Summary.

Figure 84 Predict Physical System Summary report

The Physical System total line shows the total physical processors expressed as a % (% Utilization out of), e.g. 1600% translates to 16 physical processors, and the CPU Utilization there is the total across all partitions, relative to a maximum of 1600%. The % Utilization out of value for each SPLPAR shows the number of virtual processors expressed as a %, and for each DLPAR it shows the number of dedicated physical processors expressed as a %.

Additionally, each SPLPAR shows its Entitlement as the number of physical processors, and what portion of the entitlement is being utilized, % Entitlement.



Also, you can still use all of the traditional interactive Predict reports (for workloads, relative response time, response time breakdown, etc.) to view performance results for either a baseline or “what-if” scenario.

How does Predict "alert" for SPLPARs?

The traditional computer provides resources for workloads which generate a particular amount of CPU utilization, and the CPU Utilization objectives for that computer specify when alerts should be generated in Predict, e.g. yellow alert at 70% utilization and red alert at 80% utilization per processor. SPLPARs are a bit more complex, so they are alerted based on the % of the Entitlement utilized (per virtual processor).

Another difference is that for uncapped SPLPARs, only yellow alerts are generated, regardless of how much the objectives are exceeded. This is because by definition, uncapped means there is no hard limit on what can be used (up to the number of virtual processors available).

Capped SPLPARs generate yellow alerts between the guideline and threshold, red alerts above the threshold - just the same as a "traditional" computer.

Figure 85 shows an example of an uncapped SPLPAR utilizing 77.81% of its entitlement, which exceeds the threshold of 70%, and generates a yellow alert

Figure 85 Example of an uncapped SPLPAR

As with "traditional" computers, you can edit in different objectives on a per LPAR basis as needed.



To edit LPAR objectives on the Windows console:

1. Right-click the logical system => Properties

2. On the Objective tab, enter values for Entitlement utilization, Guideline, and Threshold.

To edit LPAR objectives on the UNIX console:

1. Open the Nodes window.

2. Select and edit the logical system,

3. On the Objectives tab, enter values for Entitlement Utilization Objectives, Guideline, and Threshold).

How does Predict represent the shared pool (for SPLPARs)?

The shared pool is a key element which determines the performance of the SPLPARs assigned to it. The shared pool has a particular number of processors configured, and the work running in each SPLPAR competes for access to those processors.

In the model, the pool is described as part of the physical system configuration, and each SPLPAR assigned to that pool is shown as part of it.



Figure 86 Resource Allocation

In this example, the physical system has 16 processors, and all 16 are assigned to the shared pool (for example, there are no DLPARs on this physical system). The virtual processors assigned to the SPLPARs can total to many more than the physical processors assigned to the shared pool - in this example there are 23 virtual processors compared with the 16 available in the pool.

Since there was not collected data available for all active SPLPARs, the missing LPARs are represented as an aggregate Unaccounted CPU Utilization, which in this example is 31%.

When a model with a shared pool is evaluated, all possible constraints to CPU performance are evaluated for each SPLPAR, i.e. the number of virtual processors, the entitlement processors, capping, and the number of processors in the pool. Calculated response times will reflect the waiting caused by competition for CPU resources at every level (labeled CPU Wait Time) and overall effects can be seen in the CPU Queue Length (for LPARs on the Physical System Summary report, and for workloads on the Workload Statistics by Computer report).

If any of the CPU constraints impose an absolute limit on workload processing, Predict messages will be issued for that SPLPAR, and for the workload(s) on that SPLPAR:

W-CUTSPLRPL: CPU on SPLPAR pahrmd04 is saturated due to its running pool 0 as a constraint and the model is evaluated with a cutback on throughput.





WARNING-WKLSAT Throughput for transaction PD-Perform-Agent@PD-Perform-Agent@pahrmd04 running on node pahrmd04 is less than specified arrival rate.

Since these sample messages indicate CPU saturation for every SPLPAR in the pool, this shows that the pool configuration needs to be increased, or an SPLPAR needs to be removed. When a single SPLPAR is messaged, this indicates a constraint in either the virtual processor or the entitlement configuration for that SPLPAR (and the Physical System Summary report will show which needs to be increased).

The pool configuration and constraints are not expressly represented in Visualizer.

How does Predict "alert" for Physical Systems?

The traditional computer provides resources for workloads which generate a particular amount of CPU utilization, and the CPU Utilization objectives for that computer specify when alerts should be generated in Predict, e.g. yellow alert at 70% utilization and red alert at 80% utilization per processor. Beginning with BPA Release 7.4.00, this functionality has been extended to the Physical System as an entity, in addition to alerting capabilities on each individual partition.

Here is an example of a Physical System utilizing 65.55% of its overall capacity, which exceeds the user-specified threshold of 60%, and generates a yellow alert.

Figure 87 Physical System generating a yellow alert

W-UTLABVGUD: CPU utilization of 65.55 on node IBM,0210A8A3D exceeds the guideline of 60.00.



Similar to "traditional" computers, you can edit in different objectives on a per Physical System basis, as needed.

How do I add a new DLPAR to an existing physical system?

Whenever you want to add a DLPAR (logical system) to an existing physical system, Predict checks to see if there are any unassigned processors, and if not, only allows you to add an SPLPAR to an existing shared pool. That's why Partition type does not display DLPAR or LPAR as available options if there are no processors currently available for assignment.

So in order to add a DLPAR, the existing processors need to be reassigned among existing LPARs and shared pool(s), or the physical system CPU needs to be upgraded to have more physical processors. Then you can go ahead to create the new logical system, and the DLPAR partition type will be one of the choices presented.

You can import a system or LPAR from another model (after it has been exported from its baseline model), then convert it to a logical system.

To view the necessary configuration information (Windows Console):

1 Right-click the physical system => Properties.

2 Click Resource Allocation.

Figure 88 Viewing configuration information



In this example you can see that there are 16 processors configured on the physical system, and that 14 (2 + 2 + 10) processors are already assigned. At this point you could add a DLPAR which used up to 2 physical processors. If you needed more than that, first reconfigure the number of Total processors before adding a DLPAR which needs more than 2 processors.

How do I reconfigure memory on an existing physical system?

Anytime an LPAR is added (or removed), or a shared pool is reconfigured, Predict automatically cascades the memory changes to the physical system. In the example in Figure 88, if one of the DLPARs is removed, both its processor and memory requirements are removed from the physical system as shown in Figure 89.

Figure 89 Reconfiguring memory on an existing physical system

Only 14 (12 plus 2) out of 16 processors are committed and the physical system memory is now 20480 (originally it was 24576 MB). If a DLPAR or SPLPAR is added, those memory requirements are automatically added onto the previous physical memory size for the physical system.

Managing the performance of workload partitions


How do I change an SPLPAR to a DLPAR on an existing physical system?

To to remove an SPLPAR from the Shared Pool and dedicate a fixed number of processors to it (Windows Console):

1 Right-click and select Convert to Regular Computer.

2 Right-click and select Convert to Logical System, selecting the existing Physical system, and specifying DLPAR for the Partition type.

To remove an SPLPAR from the Shared Pool and dedicate a fixed number of processors to it instead (UNIX console):

1 Use the Nodes window and select the SPLPAR.

2 Edit => Convert => Logical to Regular.

3 Edit => Convert => Regular to Logical, selecting the existing Physical system, and specifying DLPAR for the Partition type.

See “How do I add a new DLPAR to an existing physical system?” on page 179 for additional steps which may be required in order to accommodate the resources required for the new DLPAR.

Managing the performance of workload partitions

Collecting and processing data from a workload partition

You can automatically collect the data from the workload partitions you are interested in, process the data, and store the data in a Visualizer database. The best practice for implementing BMC Performance Assurance in this type of environment is to create a Manager script to automate the process.

The following sections provide the basic instructions for setting up a Manager script creating a custom workload, and using Automator to populate the Visualizer database.




Since the WPAR global zone can “see” all the operations within the global and non-global zones, only the global zone needs collectors to be deployed. Each process has a non-global zone ID which initiates the process. Data analysis uses process-based information to produce resource usage break-down by non-global zones. Installing the Perform Agent in the global zone minimizes the installation effort and runtime overhead.

The following tasks describe the recommended process for collecting and processing data from workload partitions.

Task 1: Set up a policy that includes the target workload partitions






Task Refer to

Create a policy that includes the global zone. page 182

Create a custom workload in Analyze page 183









7 Click OK.




Task 2: Create a custom workload in Analyze

An Analyze workload characterization contains parameters for evaluating the collected performance data and for creating the input files for Visualizer.

Depending on how and where you want to see workload utilization, you may need to set up a custom workload characterization file to process the collected data. There are three options for building the workloads in Analyze on the Properties page for the workload characterization file. The options are:

■ User Defined directs Analyze to aggregate workload usage based on the default or user defined workloads, regardless of whether or not the data comes from a system configured as a workload partition. This option is the default and applies to data collected from any supported OS configuration. If you are collecting data from zones, however, keep in mind that this option will aggregate the workload utilization at the global zone level, not at the individual zone level.

■ WPAR directs Analyze to aggregate the workload usage based on the WPAR zone the workload was executing in, regardless of the default or user defined workloads. This option is used to analyze data collected from a workload partition, with zones configured. Use this option if you plan on viewing the results in Analyze, Visualizer, or Perceiver, and want the workload usage grouped by zone.

If you want the default view of workloads, then proceed to “Task 3: Set up the Automator script” on page 185.



If you are interested in viewing the workload utilization aggregated by WPAR in Visualizer or Perceiver the Manager script file that automates the data collection and data processing tasks requires a workload characterization that builds workloads by either the zone or project option. This is necessary so that you can properly view the performance data in Visualizer or Perceiver.

To create a custom workload, complete the following steps:

1 Right-click the Analyze snap-in, then choose New Workload Characterization.

2 When the welcome page of the Analyze Workload Characterization Wizard opens, click Next.

3 In the Workload Characterization page assign a name for your workload characterization file, then click Next. For example, WPAR_wkld.

4 In the Analyze Properties page select the appropriate check boxes.

5 Click Finish. This launches the Computer Wizard. Use this wizard to define the computers that are to be included in the Analyze workload characterization file. These computers will be represented in the Visualizer and Perceiver graphs that you will later view.

6 Right-click the workload characterization file and select Properties.

7 From the Build workloads by drop-down list, select WPAR.

8 Click OK to save the setting.
















7 From Automator, choose File => Save As. The script is now available to be included in the Manager script.










4 Click Add to browse to the policy that has the computers you identified in “Task 1: Set up a policy that includes the target workload partitions” on page 182. On the Select Policy File window, select the policy file and click Open.



— Leave the Generate reports for... options blank. — Accept the default values for the Generate Visualizer files section.— Select Other workload characterization file and click Browse.



7 On the Select Analyze file dialog, click the custom workload you created in “Task 2: Create a custom workload in Analyze” on page 183, and then click Open.

8 On the Analyze and Predict window, click Next.


10 Select the time zone, and then click Next. You will need to change the time zone setting if data is being collected from computers in time zones that differ from the time zone of the console computer.






Viewing metrics in Investigate from a workload partition



The metric groups listed in the following tables are available from Investigate and apply to workload partitions.

WPAR Configuration metric group

WPAR Statistics metric group

Metric Description

WPAR Name Name of the workload partition.

WPAR ID The unique identifier for the workload partition.

Init PID Process identifier (PID) of initialization process.

Root Path to root file system.

Node Name Name assigned to the workload partition node.

CPU Shares The number of CPU shares assigned for the workload partition. The available resource to the workload partitions based on their number of CPU shares.

By default, the number of shares for each workload partition is unlimited, which means that the partition is allowed to use as much CPU as it needs.

Memory Shares The number of memory shares assigned for the workload partition.

Type Name Identifies the WPAR type. There are two types of WPARs: application WPARs and system WPARs.

CPU Limit The percentage-based limit for CPU share allocation, if specified.

Memory Limit The percentage-based limit for memory share allocation, if specified.

Mobile Indicates if the WPAR is capable of migration (0 = no, 1 = yes).

Number Processors Total number of processors used by the WPAR.

Total Memory Total amount of memory used by the WPAR.

Entitlement Defines the portion of physical processor resource that is allocated to the partition, along with the defined number of virtual processors. Entitlement is configured in terms of processing units (PU). One (1.0) PU equals the capacity of a full processor.

Metric Description

WPAR Name Name of the workload partition.

WPAR ID The unique identifier for the workload partition.



CPU User Time Measure of application related CPU processor load activity.

CPU System Time Measure of system-related CPU activity.

CPU Utilization Percent of measurement interval that processor spends in system state. Normalized to a maximum of 100%.

Run Q Measure of system responsiveness.

Run Occ Times runQue has been updated in system. RunOcc is updated every second whenever runQue has been updated.

Swap Space Utilization Portion of swap space utilized by system. Computed by following formula. Utilization = 100* (Total Virtual Memory - Free Virtual Memory) / Total Virtual Memory

Swap Space Ratio The ratio of used virtual memory to total virtual memory.

1 Min Average CPU Load Average CPU load as measured every 1 min



Process Context Switches Total number of process context switches.

Num System fork calls Total number of all system fork and forkv calls.

Page Ins Measure of I/O related to paging. Number of pages.

Page Outs Measure of I/O related to paging. Number of pages.

Pg Ins Pging Pages read from swap space.

Pg Outs Pging Pages written to swap space.

Pages Scanned Pages scanned in memory. Reported in pages.

Swap Space Ratio The ratio of used virtual memory to total virtual memory.

Buffer Cache Size Represents the size of the buffer cache in kilobytes. In traditional UNIX systems, the kernel's buffer cache is the mechanism through which most explicit disk I/O passes. In newer versions of UNIX system, the Virtual Memory Manager primarily handles the explicit I/O.

Avg. Run Q Len The average run queue length, defined as ratio of Run Q and Run Occ.

Avg. Swap Q Len The average swap queue length.

Used Memory Amount of used memory in system. (Default: Kbytes)

Buffer Cache Size Represents the size of the buffer cache in kilobytes. In traditional UNIX systems, the kernel's buffer cache is the mechanism through which most explicit disk I/O passes. In newer versions of UNIX system, the Virtual Memory Manager primarily handles the explicit I/O.

Total Pg Pging Total number of pages written to and read from the swap space.

Buffer Block Reads Transfer of data between system buffers and disk or other block devices.

Buffer Block Writes Transfer of data between system buffers and disk or other devices.

Logical Buffer Reads Logical reads to buffer cache in system.

Metric Description

Displaying WPAR CPU Use in Perceiver


For descriptions of these metrics, see BMC Performance Assurance System Metrics for Microsoft Windows and UNIX, Volume One.

Displaying WPAR CPU Use in Perceiver

You can also use BMC Performance Perceiver to view performance data for IBM Workload partitions (WPARs).

The CPU Profile view under IBM Workload Partition Summary shows information on an IBM WPAR host and its partitions.

Figure 90 IBM WPAR CPU use in Perceiver

Physical Reads Physical reads to disk or other devices in system. These are physical reads that represent raw I/O.

Physical Writes Physical writes to disk or other devices in system. These are physical writes that represent raw I/O.

Message The total number of message operations reported by the system. (Default: Primitivs/sec).

Semaphore The total number of semaphore operations reported by the system. (Default: Primitivs/sec).

Metric Description

Displaying AIX partitions with Live Partition Mobility


When you select a host, you get the following tables and charts.

For more information on Perceiver views and metrics, refer to the online Help or the BMC Performance Perceiver Getting Started guide.


Live Partition Mobility allows you to migrate partitions that are running AIX and Linux operating systems and their hosted applications from one physical server to another, without disrupting the infrastructure services. The migration operation maintains complete system transactional integrity. The migration transfers the entire system environment, including processor state, memory, attached virtual devices, and connected users.

Metric Description

IBM Host WPAR Info Displays information of each of the partitions configured on the selected host, including:

■ WPAR name■ Host name■ Logical System name■ Number of host processors■ Number of virtual processors

Physical CPU Capacity Used Displays % Physical Used Total, % Virtual Used Average, % Entitlement Used Average and % Dedicated Used Average for the selected host.

Virtual CPU Capacity Used Displays WPAR CPU capacity used for all the WPARs configured on the selected host.


Provides the system configuration information that is available for the WPAR host, including:




During the migration of a partition, the Perform collector continues running, as do all other processes. The collector detects the change of the host and records it to the Hardware Serial Number metric in the System Configuration metric group. All other configuration and statistics data is collected continuously.

While Analyze processes the interval with partition migration, it reports separate partitions to the Visualizer database, one for each host.

Perceiver is able to chart the system statistics metrics continuously for partitions that have been migrated from one host to another, and also displays the change of host in the Physical Host System Hardware Configuration table.

The Physical CPU Capacity Used by Partition view illustrates the intervals that the partition has been moved by it comparing with its peers. In the case of different configurations (particularly the number of processors) between the source and destination hosts, the physical CPU utilization chart shows the difference of the normalized values, as shown in Figure 91.

Figure 91 Evaluating performance of LPARs running WPARs

General FAQs


General FAQsThis section emphasizes upon various FAQs related to the AIX environment.

What are best practices for performance reporting and analysis for the AIX environment?

Instrument all LPARs with a collector (7.3.00 or later).

This ensures proper identification of SMT as well as access to the specific metrics required to properly report on LPAR resource consumption.

Any un-instrumented DLPARs will compromise complete frame reporting.

If any SPLPARs are not instrumented but one or more instrumented SPLPARs have Shared Pool Authority set, there is representation of the total CPU usage of all "missing" SPLPARs. This is not as detailed as the representation possible with full data collection. Compare Figure 92 on page 194 with Figure 72 on page 157.

NOTE WPARs do not have to run within an LPAR. BMC Performance Assurance supports both WPARs running in LPAR and WPARs running in a standalone system.



Figure 92 Display of “missing” SPLPARs

Ensure that at least one LPAR per physical system is collecting the HMC configuration data.

LPARs should be processed together in one Manager domain or policy.

If you choose to split LPARs from the same physical system across multiple domains/policies:

■ The HMC configuration requires that a least one LPAR per physical system per domain/policy is collecting the HMC configuration. Thus, some customers have chosen to configure HMC collection for all LPARs in order to support arbitrary analysis groupings.

■ (b)All LPARs from a frame must be populated to the same Visualizer database.

You can see exactly what has been accomplished in Visualizer: every properly instrumented LPAR will appear under the appropriate physical system name, with a designation of DLPAR or SPLPAR (CPU Use Hierarchy or optional AIX Partition CPU Usage Hierarchy graphic).



Figure 93 Properly instrumented LPARs

What are best practices for performance modeling for this particular environment?

Keep these important principles in mind:

■ When a Predict model is needed, all LPARs (from a particular physical system) must be identified within one Analyze. And as previously recommended for reporting, collectors should be deployed on all important LPARs.— There is representation of the overall CPU usage of any "missing" SPLPARs, but

this is not as detailed as the representation possible with full data collection (see also 7 above).

— The memory configuration for the physical system will reflect the sum of all LPARs which were jointly Analyzed.

■ As described in the modeling section above, competition for the CPU is explicitly modeled and performance results reported. Memory, I/O, and network performance effects are limited to those within each LPAR


C h a p t e r 55 Implementing Performance Assurance on HP Systems with Hardware Partitions


Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Support for hardware partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199Support for HP Integrity VM systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Installation considerations for HP Integrity VM systems . . . . . . . . . . . . . . . . . . . . . . 200Installation considerations for HP-UX partitions . . . . . . . . . . . . . . . . . . . . . . . . . . 200Installation considerations for HP Integrity VM systems . . . . . . . . . . . . . . . . . . . 200

Managing the performance of HP-UX partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201Data collection considerations for HP hardware partitions . . . . . . . . . . . . . . . . . 201Displaying data from HP hardware partitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Modeling HP-UX virtual systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207Overview of HP Integrity VM systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

HP IVM Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212Data collection considerations for HP IVM systems . . . . . . . . . . . . . . . . . . . . . . . 213

Displaying data from HP IVM partitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213Viewing HP IVM metrics in Investigate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214Viewing HP IVM data in Visualizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215Viewing HP IVM data in Perceiver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217Viewing HP IVM data in Analyze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Workload and Predict model characterization in Analyze . . . . . . . . . . . . . . . . . . 222Analyze and the Visualizer Database Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Virtualization Planning support for HP IVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225HP IVM Virtualization Study for Deploying New Guests . . . . . . . . . . . . . . . . . . 225

Reporting capacity usage for HP IVM systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227Reporting CPU for a HP IVM system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228Reporting CPU allocation for a HP IVM system . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Modeling HP IVM systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Implementation of best practices for HP IVM modeling and reporting . . . . . . . 229Evaluate the Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231


Review the Physical System Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232Perform “What if...?” investigations of HP IVM partitioned systems . . . . . . . . . 234Modeling process summary of HP IVM systems . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Overview


OverviewTo identify and accurately model the activity on partition-capable HP hardware (both PA-RISC and Itanium), you must be able to collect data from both physical and virtual partitions, which HP refers to as nPartitions (nPars) and vPartitions (vPars), and software partitions, such as Integrity VM.

In this environment, hardware resources such as processors, memory and disks can be dynamically reallocated to other partitions on an as needed basis from one partition to another. BMC Performance Assurance enables you to accurately model the entire activity of these types of partitioned servers.

For an overview of the environment, refer to “Overview of HP virtualization” on page 14.

Support for hardware partitions


■ Collect configuration data about all of the partitions that enables Analyze and Predict correlate the activity of all of the partitions to the Host Server, for capacity planning purposes.

■ View the overall configuration of the server (provided in the Physical Partition Configuration metric group), as well as some additional system information about the partition (provided in the System Configuration metric group).

■ Generate performance reports on the partition configurations, based on the physical server, with breakdowns by logical systems (partitions).

■ Build and evaluate the performance model for partitioning systems, including the relationship between logical systems and physical system.

■ Perform “What-if...” scenarios on physical and logical systems■ Draw performance graphs for partitioned and partitioning systems, using

Visualizer.


Support for HP Integrity VM systems


Support for HP Integrity VM systems

Integrity Virtual Machines are software partitions that provide operating system isolation. The Integrity Virtual Machines can be installed on a standalone Integrity server or under an nPar that is running HP-UX. Depending on the version of the IVM software, you can create IVM guests running HP-UX, Windows and Linux.


Data collection and Investigate are the only components supported for this platform.


Installation considerations for HP-UX partitions

Note the following requirements when installing BMC Performance Assurance in a HP-UX environment:

■ Run the installation program according to the instructions in BMC Performance Assurance Getting Started guide.

■ To obtain detailed information about applications or workloads running in the individual partitions, you must install the Perform Agent and Perform collector on each partition.

Installation considerations for HP Integrity VM systems

The Perform Agent must be installed on the HP IVM host computer to collect configuration data about all of the IVMs.

There are two ways to identify a system as a IVM host:

■ Check for the existence of the /opt/hpvm/bin/hpvmstatus executable: This is one of the CLIs provided by HP to manage VM guests.

■ Review the output from the /opt/hpvm/bin/hpvminfo utility to identify the host.

HP-UX 11.23 and 11.31 for Itanium based systems support HP IVMs.

Managing the performance of HP-UX partitions


Managing the performance of HP-UX partitions

Data collection considerations for HP hardware partitions

The Perform collector gathers data to provide the overall configuration of the partitioned server. Note the following data collection considerations for this environment:

■ You should run the Perform collector on any partition that is running the HP-UX operating system, so that Analyze can assemble complete picture of the server and all of the partitions on it. Unlike the other partition platforms (Oracle Solaris and AIX) where an external node controls the server, the server can be controlled and queried locally.

■ The collection of Physical Partition Configuration data is enabled by default. An option in the Collect.cfg file is available should you want to disable the collection of this metric group.

■ Data collection is supported on partitions running HP-UX (11.11, 11.23 and 11.31).

You can collect data from HP-UX partitioned systems as you would other computers. These methods are:

■ for ad-hoc data collection, use the best1collect command line executable

■ for automated data collection, create a Manager run using the BMC Performance Assurance console on either UNIX or Microsoft Windows.

These data collection methods are fully described in the BMC Performance Assurance Implementation Guide for UNIX, or by referring to the online Help.

Displaying data from HP hardware partitions

You can access performance data about the virtual systems by using any of the following components on the Perform Microsoft Windows console:




The following sections describe how to display and interpret the data using Investigate, Analyze, Visualizer, and Perceiver.

Viewing HP-UX Partition Metrics in Investigate

The following sections discuss the metrics you can view in Investigate that are of interest for a HP-UX partition.

Viewing System Configuration Metrics in Investigate from a HP-UX partition

In the System Configuration metric group, some existing metrics have different descriptions in a HP-UX partitioned environment. The following table describes these metrics:

There are also a number of metrics that can specifically apply to HP-UX partitions. The following table describes each of these metrics:

Viewing Physical Partition Configuration Metrics in Investigate from a HP-UX partition

In the Physical Partition Configuration metric group, some existing metrics have different descriptions in a HP-UX partitioned environment. The following table describes these metrics:

Metric Description

Number Processors

The number of active physical processors on the partition.

Max Number Processors

The total number of physical processors available to the partition for nPar and vPar.

Hardware Serial Number

The partitioned server (physical system) identifier.

Metric Description

Partition Type The specific partition implementation. For HP, the possible values are nPar, vPar, nPar/vPar. Other values are reported for other vendors partitioning systems or standalone servers, such as DSD (Oracle), LPAR, DLPAR, SPLPAR (AIX).

Logical system name

The name of the partition, which can be different from the System Name.



There are also a number of metrics in the Physical Partition Configuration metric group that support HP-UX partitions. The following table describes each of these metrics:

Key Analyze report to review for HP-UX partitions

Based on the collected data, Analyze identifies each type of partition, correlates the data to establish the physical to logical system relationship, builds the partitioning model for Predict, creates the hierarchical report for partitioned systems, and generates the Visualizer input file.

The following section describes the main report for analyzing data specific to HP-UX partitions.

Metric Description

Logical System Name

The unique identifier for the partition.

Physical System Name

The unique identifier for the server (host). This name matches the Hardware Serial Number in the system configuration within the partition.

Physical System Model Name

The model of the server.

Total Processors The number of physical processors available to the partition.

Active Processors The number of physical processors currently used by the partition (for nPar) or the number of physical processors that are assigned to the partition (for a vPar). In a vPar, the processors assigned to the vPar cannot be turned offline.

Total Memory The size of the memory allocated to the partition.

Metric Description

Parent Name The system complex name for a nPar. This field is blank for a vPar or a nPar/vPar combination, as the complex name is not available for vPars.

Partition Type The type of partition implemented. Possible values are nPar, vPar, or nPar/vPar.

Unassigned Processors

The number of physical processors that are not assigned to any partition

Active Memory The size of the memory currently used by the partition.

Unassigned Memory

The size of the memory that is not allocated to any partition.



Physical system report for HP-UX partitions

This report displays a two-tier hierarchy for HP-UX partitioned servers: the nPar, vPar and vPars running under an nPar (For a vPar running on an nPar, the vPar name is prefixed with the nPar name).

Figure 94 Analyze Physical System report for HP-UX Partitions


Column Description

Physical System The name of the physical system (host).

Logical System The name of the logical system for nPar and vPar. For a vPar running on an nPar, the vPar name is prefixed with the nPar name.

Partition Type The type of partition implemented. Possible values are: nPar, vPar, or nPar/vPar.

Active Processors The number of active processors for the partition. For the physical system, this field is the sum of all partitions.

Dedicated Processors

The number of dedicated physical processors for the partition.

CPU Model The system vendor and model. Only reported for a physical system.

Memory The size of total physical memory (for the physical system) or the size of allocated memory (for logical systems). Reported in Mbytes.

CPU Utilization The percentage of CPU usage (out of 100) times number of active processors



Displaying HP partition CPU usage in Visualizer

To view HP partition data from Visualizer, complete the following steps:

1 Click Database=> Select and select the database into which you populated the HP partition data.

2 Click Database=> Detail and choose the data for the graph. Ensure that you select HPNPAR from the Virtual Type drop-down list.

3 From the Graphics menu, choose HP-UX Partition => HP NPAR VPAR Partitions Hierarchy.

Figure 95 HP NPAR VPAR Partitions Hierarchy

Displaying HP partition CPU use in Perceiver

You can also use BMC Performance Perceiver to view performance data for HP partitions.

The CPU Profile view under HP UX Host Summary shows information on a HP host and its partitions.



Figure 96 HP partition CPU use in Perceiver

When you select a host, you get the following tables and charts.

Metric Description

HP-UX Partition Info Displays information of each of the partitions configured on the selected host, including:

■ Logical System name■ Node name■ Partition type■ Pool ID■ Number of dedicated processors

% Physical Used Total and % Dedicated Used Average

Displays the total physical CPU capacity used and dedicated used average for all the partitions configured on the selected host.

Modeling HP-UX virtual systems



Modeling HP-UX virtual systemsWith Predict, you can perform any of the following tasks as a part of your “What-if...” analysis of a partitioned system:


The Predict Physical System Summary report provides information on the configuration of the hardware partition, and specific information on each computer in the partition. An example of the report is shown in Figure 97.

Evaluate the Model


Some models might not have sufficient information to evaluate properly.

Top 10 Partition CPU Capacity Used

Displays the top 10 Partition CPU Capacity Used for the selected host.




Metric Description







Review the Physical System Summary

Predict generates a Physical System Summary report and a Visualizer input file. Figure 97 shows an example of the report.

Figure 97 Predict Physical System Summary report for a HP-UX Partition

The following table describes the columns in this report. You may need to scroll to the right to see some of the report columns.

Column Description








Perform “What if...?” investigations of HP-UX partitioned systems

After you have established a valid baseline model, you can change the system model and investigate how the changes will affect system performance. With data collected and analyzed from the HP-UX partitioned systems, you can explore various “What if...?” scenarios.


The following example describes how to move a vPar from one physical system to another, to see the effect on CPU utilization.



CPU Utilization The percent of time the CPU is busy. The maximum percentage depends on the number of processors on the computer. For example, if the computer has 1 processor, the CPU utilization is out of 100% If the number of processors is 4, then the utilization is out of 400%.

% Utilization out of The number of online processors multiplied by 100.

% Entitlement N/A for HP-UX partitions.

Entitlement N/A for HP-UX partitions.

Cap N/A for HP-UX partitions.

Queue Length The average number of transactions queued for CPU service at any one time. The number includes the transactions that are receiving service as well as those that are waiting to receive service.


Column Description



Scenario for Modeling Data from a HP-UX Partition

In the following scenario, to anticipate customer growth in the coming year, a company wants to explore what performance benefit can be realized by moving a logical system from one physical system to another. Currently, the accounting billing software runs on a vPar on a physical system that is reaching capacity. Another physical system currently used by the human resources group, is under utilized.

The following example illustrates the process for investigating possible performance benefits by moving the vPar to another physical system.

1 Collect data on each of the existing servers.

2 Identify good baselines for modeling (those periods with consistent usage).

3 Characterize the workloads in Analyze —determine which workloads will be moved, which ones do not need to be moved, and which ones now would be shared in a consolidation, particularly the email application. For more information on workloads, baselines, and models, see the online Help or the BMC Performance Assurance for Microsoft Windows Implementation Guide for Microsoft Windows.

4 In Predict, open the model file, and evaluate the model.

5 Review the CPU utilization for each of the major application workloads in the Predict Physical System Summary report (Figure 97 on page 208).

6 To move the partition to another system, expand the Computers tree, as shown below.

7 Right click the computer and select Move Logical System. On the Move Logical System dialog box, select the physical system to which you want to move the logical partition, and if appropriate, the nPar. Click OK.

Overview of HP Integrity VM systems


8 Evaluate the result, tuning as necessary, comparing the results with the previous Predict Physical System Summary report.

You can also explore other “What if...?” scenarios, such as:

■ What would happen to performance if I move an existing workload from one vPar to another? What would the impact be from this workload consolidation?

■ Create an additional vPar directly on a physical system.

■ Move a standalone computer to a partition.

Overview of HP Integrity VM systems■ Support for low to high-end HP Integrity servers: HP Integrity rx1600, rx2600,

rx4640, rx7620, rx8620, Integrity Superdome and other future HP Integrity servers.

■ Is an extension of HP’s existing partitioning continuum that combines the benefits of HP-UX Virtual Partitions (vPars) and HP Process Resource Manager (PRM).

■ Is a soft partitioning and virtualization technology that provides operating systems isolation.

■ Provides sub-CPU allocation granularity and shared I/O. A partition can hold up to 1/20th of a CPU.

■ The IVMs can be installed on a standalone Integrity server or under an nPar that is running HP-UX.

■ Different virtual machines can run guest operating systems with different versions or patch levels, and they support Linux, Windows and HP-UX.

HP IVM Architecture


HP IVM Architecture

HP Integrity Virtual Machine (HP IVM) is an extension of HP’s existing partitioning continuum that combines the benefits of HP-UX Virtual Partitions (vPars) and HP Process Resource Manager (PRM).

The HP IVM product is a soft partitioning, and virtualization technology that provides operating systems isolation, with sub-CPU allocation granularity and shared I/O. A partition can have up to 1/20th of a CPU. The IVMs can be installed on a standalone Integrity server, or under an nPar that is running HP-UX.

The hypervisor supporting virtualization for IVMs is based on a Type-2 technology, which is similar to the Microsoft® Virtual Server, user-mode Linux, and the older VMWARE GSX. These hypervisors are software applications running within an OS. It is a separate software layer, with the guest OS running at a third level above the hardware. The virtual machine can run HP-UX, Linux, Windows, and OpenVMS, however the guest OS support varies based on the version of IVM software. Figure 99 below gives a high level architectural build-up of HP IVM.

Figure 98 HP IVM Architecture

HP IVM is built on Type-2 Virtualization technology similar to Microsoft Virtual Server, and older VMware GSX.The Host OS is the first level, the Hypervisor is on the second level, and is a separate software layer running on the Host OS; and finally on top there is the Guest OS that runs at the third level above the hardware.

Data collection considerations for HP IVM systems


Data collection considerations for HP IVM systems

In order to collect configuration and performance data for HP Integrity VM (HP IVM) systems, BPA data collector should be installed on the host that is running HP IVM. All the configuration and statistical groups that are collected on a regular HP-UX system are collected for an IVM host system. In addition, the collector collects configuration metrics about all the virtual machines that are running on the host. Collectors can be installed on the IVM virtual machines as well. The data collected from the virtual machines will be populated and available in the database tables.

Listed below are some data collection considerations for this environment:

■ BPA data collector should be installed on the host that is running HP IVM.

■ All the configuration and statistical groups that are collected on a regular HP-UX system are collected for an IVM host system.

■ In addition, the collector collects configuration metrics about all the virtual machines that are running on the host.

■ Collectors can be installed on the IVM virtual machines as well. The data collected from the virtual machines will be populated and available in the database tables. No attempt to correlate metrics collected from inside the virtual machine to that collected from the host OS.

■ For IVM running within HP nPar systems, collector should be installed on the partition hosting the Integrity virtual machines.

Displaying data from HP IVM partitionsYou can access performance data about the virtual systems by using any of the following components on the Perform Microsoft Windows console:


The following sections describe how to display and interpret the data using the components listed above.

Viewing HP IVM metrics in Investigate


Viewing HP IVM metrics in Investigate

Table 5 describes the metrics in the IVM Configuration metric group, which you view in Investigate.

The IVM Configuration metric group represents the configuration of Integrity Virtual Machines. This metric group is only populated when collecting data from an IVM host system.

The investigate support is the same as for the other virtualized and non virtualized platforms. Figure 99 shows a drill-down of IVM configuration metric group.

Table 5 IVM Configuration metric group

Metric Description

VM Name Name of the Integrity Virtual Machine

Operating System Name of the operating system running on the IVM

Virtual Processors Number of virtual processors assigned to the IVM

Total Memory Number of KBytes memory of memory assigned to the IVM

Status Status of the IVM

Entitlement Percent (%) of processor resources to which the IVM is entitled

Max Entitlement Maximum percentage (%) of processor resources to which the IVM is entitled

UUID UUID (Unique Identifier) of the IVMPID Process ID (PID) for the IVM

VM Serial Number Serial number of the IVM

Unassigned Processors

The number of processors not assigned to any IVM

Unassigned Memory

Number of KBytres memory not assigned to any IVM

Installed Processors

Total number of installed processors on the IVM Host

Installed Memory Total number of KBytes memory on the IVM Host

Viewing HP IVM data in Visualizer


Figure 99 IVM Configuration Metric Group

For more information on any of the metrics, refer to Chapter 2 of the BMC Performance Assurance System Metrics for Microsoft Windows, UNIX, and Linux, Volume One.


Visualizer supports two additional out-of-box charts specific to HP IVM. They are:

■ HP IVM Hierarchy

■ HP IVM Configuration/State Hierarchy

Figure 100 shows the HP IVM Hierarchy chart.



Figure 100 HP IVM Hierarchy Chart

Figure 101 shows the HP IVM Configuration/State Hierarchy.

Viewing HP IVM data in Perceiver


Figure 101 HP IVM Configuration/State Hierarchy Chart


BMC Performance Perceiver can be utilized to view performance data for HP IVM partitions.

All the metrics reported for a stand-alone HP-UX system are available for an IVM host. Datacenter Overview, Datacenter Summary by Resource and Server Profile by Resource charts show HP IVM host level data. Two new IVM specific categories HP IVM Overview and ‘HP IVM Server Summary’ have been defined to present IVM host along with the virtual machines.

There are two HP IVM specific out-of-box views available through Perceiver. These are:

■ HP IVM Overview

■ HP IVM Server Summary



Table 6 and Table 7 describe these views in further detail.

Table 6 HP IVM Overview

View Category View Name Chart Label Chart Type Description

HP IVM Overview

Group of HP IVMs – Create and select a group of partitions

Virtual Machine Overview

Physical CPU Capacity Used

Histogram Normalized by the total number of processors in the system


Histogram Normalized by the number of virtual processors configured for IVM

Memory Utilization Histogram Normalized by the total memory configured

Virtual Machine Metrics


Line Normalized by the total number of processors in the system


Line Normalized by the number of virtual processors configured for IVM

Memory Utilization Line Normalized by the total memory configured



Table 7 HP IVM Server Summary

View Category View Name Chart Label Chart Type Description

HP IVM Overview

Group of HP IVMs – Create and select a group of partitions

Virtual Machine Overview


Histogram Normalized by the total number of processors in the system


Histogram Normalized by the number of virtual processors configured for IVM

Memory Utilization Histogram Normalized by the total memory configured

Virtual Machine Metrics


Line Normalized by the total number of processors in the system


Line Normalized by the number of virtual processors configured for IVM

Memory Utilization Line Normalized by the total memory configured



HP IVM Perceiver views

HP IVM Server Summary - CPU Profile

HP IVM Server Summary (Figure 102) shows the resource usage of the virtual machines alongside the usage of the physical host. The view ‘CPU Profile’ contains ‘virtual machine configuration’ table on top that displays the configuration parameters of the virtual machines.

The ‘host system configuration’ table at the bottom shows the hardware configuration of the host. If there are changes to the hardware configuration of the host during the selected interval, they are reflected as multiple entries in the table.

Figure 102 HP IVM Server Summary - CPU Profile



HP IVM Overview - Virtual Machine Overview

HP IVM Overview (Figure 103) presents metrics for a selected group of virtual machines. It is similar to ‘Datacenter Overview’ that shows a histogram and a ranking table for a group of servers. ‘Virtual Machine Overview’ displays a histogram and ranking table for a group of HP IVM virtual machines. The group of virtual machines can span multiple HP IVM hosts.

Figure 103 HP IVM Overview - Virtual Machine Overview

For more information on Perceiver views and metrics, refer to the online help, or the BMC Performance Perceiver Getting Started guide.

Viewing HP IVM data in Analyze



Analyze can be utilized to view detailed analytical data for HP IVM partitions. Some of the noteworthy capabilities of Analyze are summarized as under:

■ Shows the total number of processors accessed per nPar or per nPar/vPar (100% = 1 processor).

■ Uses the information available in the IVM configuration metric group to connect the host to the virtual machines.

■ Uses the PID information in the IVM configuration group to retrieve the process record corresponding to the virtual machine.

■ The resource usage reported for the process is used to compute the resource usage for each of the virtual machines.

■ At this time, only CPU and memory numbers are available at each VM level.

Workload and Predict model characterization in Analyze

Workload Characterization can be enabled by selecting ‘Build Workload By Partition’ (Figure 104). This way, Analyze automatically builds a workload for each VM. Here, the VM Name is used as the Workload Name. A user defined workload is automatically renamed if there is a conflict.

Based on the PID of the VM, a single process for the VM is assigned to the workload. Other non-VM processes are assigned to user defined workloads.

Analyze creates a model that contains the host information along with all the workloads that are created for the host. The host looks like a regular host, and the virtual machine details are written to the model.



Figure 104 Analyze - Build workload by Partition option



By default, an Analyze report shows one transaction per partition. (Figure 105)

Figure 105 Analyze - Default option

Analyze and the Visualizer Database Schema

Analyze populates HP IVM data to the visualizer database. The host information is populated to the ‘CAXPSYS/CAXPSYSD’ tables, the hardware configuration information to the ‘MODELS’ table; and the virtual machine information is populated to the ‘CAXEMVM/CAXEMVMD’ tables.

If HP IVM is deployed on a HP-UX system running on a physical host, the reference field ‘PHYSS’ will be active, and the reference field VMS will point to a dummy record. If, on the other hand, HP IVM is deployed on an nPar partition, the reference field ‘PHYSS’ will point to the physical host, and the reference field VMS will point to the nPar system that is hosting the HP IVM.

Virtualization Planning support for HP IVM



The Virtualization Planning module now correctly recognizes existing HP IVM virtualization components (guests and hosts) in a monitored environment. These components, along with a new study profile describing HP IVM virtualization attributes, can be used to perform Virtualization Planning exercises of current or future HP IVM environments.

The section below attempt to describe the workflow for conducting a HP IVM virtualization study for ‘Deploying New Guests’.

HP IVM Virtualization Study for Deploying New Guests

■ In Perceiver, select the Virtualization Planning’ tab, and click, on Begin Virtualization Study.

■ Select a group of computers to include in the study and click on ‘Deploy New Guests'.

■ Fill in the number for each type of guest to deploy. (Figure 106)

Figure 106 Deploy New Guest - Number of guests



■ Select Target Host you want the guests to be deployed to, and then click on the Deploy button. (Figure 107)

Figure 107 Deploy New Guest - Select Target Host

■ On selecting the target host, the results of the deployment will be displayed as Deployment Summary. (Figure 108)

Reporting capacity usage for HP IVM systems


Figure 108 Deploy New Guest - Deployment Summary

Reporting capacity usage for HP IVM systemsSimilar to other partitioned Virtualization architectures, HP IVM CPU capacity depend, while workloads keep changing, on the following levels of available CPU resources:

■ Total physical processors■ Processors assigned to each nPar■ Each standalone nPar with a provision for adequate processors■ Each vPar within an nPar with provisions for adequate virtual processors and nPar

processors.

Reporting CPU for a HP IVM system


Reporting CPU for a HP IVM system

Using Visualizer, CPU can be reported for HP systems from the CDB. This chart (Figure 109) displays the following:

■ The total percentage of physical system capacity used, and■ Percentage of physical system capacity used by partition.

Figure 109 Selected Partition CPU use

Reporting CPU allocation for a HP IVM system

Using Visualizer, CPU allocation can be reported for HP systems from the CDB. This chart (Figure 110) displays the following:

■ The total number of processors accessed per nPar or per nPar/vPar (100% = 1 processor), and

■ Dynamic shifting of processors between vPars within an nPar causing processor allocation to vary by an interval.

Modeling HP IVM systems


Figure 110 CPU allocation

Modeling HP IVM systems

Implementation of best practices for HP IVM modeling and reporting

The following best practices must be adopted towards HP IVM modeling and reporting:

■ It must always be confirmed that the baseline analysis contains all the important partitions, and that they have been properly instrumented.

■ One must instrument all important partitions with Collector v7.3.00 (or later). This ensures access to the new metrics required to properly report on partition resource consumption.

Implementation of best practices for HP IVM modeling and reporting


■ It must be ensured at all times that at least one partition per nPar has a collector (required to obtain complete partition configuration data).

■ Partitions may be processed in separate Manager domains/policies, but must be populated to the same Visualizer.

■ Each instrumented partition appears under the appropriate physical system name, designated as NPAR or NPARVPAR, as shown in Figure 111 below:

Figure 111 CPU use hierarchy

Here, the physical system name, with the partitions properly recognized, are indented one level below.

NOTE Missing partitions will compromise having complete results!

Evaluate the Model


■ It needs to be confirmed that the CPU model is properly identified for both the physical system (Analyze - Physical System report) and the logical system (Analyze - Hardware Summary report).

General ‘Best Practices’, Consolidation Sizing techniques for HP partitions, processes and tools for identifying virtualization candidates are the same as shown for AIX in earlier sections. The process and tools for sizing techniques are also the same.

Modeling techniques employed for HP partitions are similar to AIX. It may also be noted that Physical Systems can contain partitions, and a Computer represents one partition. Also, each nPar can be standalone, or can contain multiple vPars as shown in Figure 112 below.

Figure 112 Modeling in HP partitions

Evaluate the Model

After you open the HP IVM model, you must evaluate it to obtain the performance metrics calculated by Predict. When you evaluate the model, Predict displays information and any errors while the model is being evaluated.

Some models might not have sufficient information to evaluate properly.



When you click the Evaluate Model icon, Predict evaluates the IVM model, produces reports concerning the performance of the system represented by the model, and displays more information about the model components.

Your next step is to examine the components in the model to:


For more information on calibrating the model and creating a valid baseline, refer to the Predict Online Help.


Each instrumented partition will appear under the appropriate physical system name, designated as NPAR or NPARVPAR.

Predict generates a Physical System Summary report, and a Visualizer input file. Table 8 describes the columns in this report. You may need to scroll to the right to see some of the report columns.



Table 8 Predict Report column descriptions for HP IVM

For more information on the Physical System Summary report, refer to the Predict Online Help.

Column Description







CPU Utilization The percent of time the CPU is busy. The maximum percentage depends on the number of processors on the computer. For example, if the computer has 1 processor, the CPU utilization is out of 100% If the number of processors is 4, then the utilization is out of 400%.

% Utilization out of The number of online processors multiplied by 100.

% Entitlement N/A

Entitlement N/A

Cap N/A

Queue Length The average number of transactions queued for CPU service at any one time. The number includes the transactions that are receiving service as well as those that are waiting to receive service.


Perform “What if...?” investigations of HP IVM partitioned systems


Perform “What if...?” investigations of HP IVM partitioned systems

After you have established a valid baseline model, you can change the system model and investigate how the changes will affect system performance. With data collected and analyzed from HP IVM partitioned systems, you can explore various “What if...?” scenarios. Some of these are listed below:

■ Revise CPU configuration of the partitioned system— Use the Physical System, and Configuration tabs.

■ Revise configuration of individual nPars and vPars— Use the Physical System, and Resource Allocation buttons.

■ Move work onto the physical system. This can be performed as follows:— Select the Node— Click on Edit - Convert - Regular to Logical (UNIX GUI) or Convert to Logical

System (Windows GUI), for each computer to be a partition within a model— Import desired Workload(s) from systems into this model

■ Revise CPU utilization objectives. This can be done as follows:— Click on Edit - Node (UNIX GUI) or, go to the Properties (Windows GUI), and

use the Objectives tab■ System growth (use Scenario Planner).


Modeling process summary of HP IVM systems



■ Build a baseline model for the current partitioned system.■ Set Baseline to ‘ON’.■ Evaluate the model and observe messages/reports for warnings that a CPU

objective has been exceeded.■ Follow implementation ‘Best Practices’, such as:

— Use the Support website Knowledge articles.— Open a case with Customer Support for customized assistance with

implementation.— Allow extra time for the first implementation for a particular type of

Virtualization.■ Apply tools specifically designed to support HP IVM Virtualization

— This generally requires Collector v7.3, and Console v7.3.■ Use CDB for a complete view of CPU Usage (historical and future), and derive

measurements from physical HP IVM systems which generally include:— Three graphs per physical system, giving a complete reporting solution— More detailed graphs, used for specific analysis projects— ‘% Capacity Used’ for the physical system

■ Modeling the results for HP IVM virtual systems, which include:— viewing physical systems and individual partitions— viewing workload performance results within the HP IVM partitions

■ Predictor Scenario Planner results can be shown, as and when required. When using Predictor with HP IVM:— Use the appropriate modeling construct for each type of Virtualization (e.g.

Physical System)— Use the corresponding specific modeling report for each type of Virtualization

(e.g. Physical System Summary)

Chapter 6 Implementing Performance Assurance on a Oracle Partitioned System 237

C h a p t e r 66 Implementing Performance Assurance on a Oracle PartitionedSystem


Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Support for Solaris Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238Support for Solaris Dynamic System Domains (DSDs) . . . . . . . . . . . . . . . . . . . . . 239Support for Solaris Logical Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Installation considerations for Solaris. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240For installing in Solaris 10 environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240For installing in Solaris DSD environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240For installing in Solaris LDom environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Managing performance of Solaris Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Collecting and processing data from Solaris Container systems . . . . . . . . . . . . . 241Displaying data in Visualizer for Solaris Container systems . . . . . . . . . . . . . . . . 249Displaying data in Perceiver for Solaris Container systems . . . . . . . . . . . . . . . . . 251Finding out more using Investigate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

Managing performance of Oracle partitioned (DSD) systems . . . . . . . . . . . . . . . . . . 257Displaying Data in Analyze from Oracle Partitioned Systems . . . . . . . . . . . . . . 257Modeling Data from a Oracle Partitioned Environment . . . . . . . . . . . . . . . . . . . . 257

Managing performance of Oracle Logical Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . 259Displaying data in Investigate from Oracle LDoms. . . . . . . . . . . . . . . . . . . . . . . . 259Displaying Solaris LDom CPU Use in Perceiver . . . . . . . . . . . . . . . . . . . . . . . . . . 260Modeling data from a Oracle LDom environment. . . . . . . . . . . . . . . . . . . . . . . . . 262Managing performance with Chip Multi-Threading . . . . . . . . . . . . . . . . . . . . . . . 265Modeling an UltraSPARC processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

Overview


OverviewBMC Performance Assurance supports two types of virtual systems on Oracle Solaris systems:

■ Solaris Containers■ Solaris Dynamic System Domains (DSDs)■ Solaris Logical Domains (LDoms)

Support for Solaris Containers

Oracle's Solaris 10 release provides a way of virtualization by creating containers, or zones, inside the operating system image. The operating system image that contains the zones is called the global zone.

A global zone may contain many zones referred to as non-global zones. Each non-global zone appears as an independent node within the network and it maps application resources to platform resources. Applications running within discreet non-global zones are isolated from each other. Global and non-global zones share one copy of the Solaris 10 operating system, running in the global zone.

What is supported for this platform:

■ additional metric data and treatment of non-global zone as a node, with constraints

■ CPU, Paging IO and Total IO metrics at the non-global Zone level■ Visualizer version 4.2.05 with latest patch for reporting of Container and zone data■ process data available at the global zone level and top 30 processes within each

non-global zone (in Visualizer)■ Container views in BMC Performance Perceiver 7.5.00 and higher

What is not supported

■ specific zone reports in BMC Performance Analyzer for Servers or BMC Performance Predictor for Servers

■ if you run Solaris Containers in a DSD environment, the Containers are reported as if they are nodes or partitions, with no information on the global zone environment.

Support for Solaris Dynamic System Domains (DSDs)


Support for Solaris Dynamic System Domains (DSDs)

Due to the limitation of hardware access, only partitions running on SunFire architecture (SunFire 12K, 15K, 20K, and 25K) are supported.

Oracle refers to hardware partitions as Dynamic System Domains (DSDs). Each physical SunFire or SPARC system can support multiple partitions, or DSDs.

Support for Solaris Logical Domains

Oracle refers to logical hardware partitions as Logical Domains (LDoms). Each physical SunFire and SPARC system can support multiple logical domains.

LDoms are virtual environments within the Solaris operating system. Several LDoms share a physical processor, but each operates like an independent processor. The collector for Solaris 10 identifies each LDom as if it is an independent processor, as well as sharing processing resources of a physical processor. It returns utilization information and metrics for the physical processor, each LDom within the processor, and each LDom’s share in the physical processor’s total capacity.

What is supported for this platform:

■ Identifying a system as a LDom or a control LDom.

■ If the collector detects that it is running on the control LDom, it collects the Physical Partition Configuration metric group, which describes the configuration of the LDoms running on the server. The collector also collects existing Solaris core level statistics and other performance and configuration data from each LDom.

■ Investigate support for the LDom metric groups.

■ Data Analysis that reads and processes the key metrics, identifies and provides the relationships between objects to the database and the model. Support workload characterization of data collected within each LDom.

■ Presentation of key metrics in BMC Performance Perceiver Datacenter Overview charts and detailed metrics in Solaris LDom specific charts.

■ Modeling of Ldom systems based on threads instead of cores.

■ Visualizer charts that present LDom specific views.

■ Collection, analysis, modeling and presentation of zones running within LDoms.

Installation considerations for Solaris


BMC Performance Assurance supports Chip Multi-Threading (CMT) technology on Oracle UltraSPARC T1 andT2 processors, where which ave multiple cores and multiple threads. Each Oracle SPARC system may have 1, 2 or 4 chips (physical processors), each UtraSPARC processor has 4, 6, or 8 cores, and each core can process 4 (T1) or 8 (T2) threads. A single Oracle SPARC system may have as many as 256 individual processing threads, and the collector identifies each thread as an individual processor, providing utilization information and metrics.

Installation considerations for Solaris Note the following installation considerations for using BMC Performance Assurance in a Solaris virtualization environment.

For installing in Solaris 10 environments

■ You must install the Perform Agent in the global zone. ■ You cannot install the Perform Agent inside a Solaris non-global zone. ■ Visualizer graph support requires version 4.2.05 with latest patch.■ BMC Performance Perceiver support requires version 7.5.00 and higher.

For installing in Solaris DSD environments

BMC Performance Assurance supports Solaris Dynamic System Domains as implemented on the SunFire architecture (SunFire 12K, 15K, 20K, and 25K) with a System Controller running System Management Services software version 1.3, 1.4.1 or later, under a limited support agreement. Since the SunFire architecture provides a variety of site-specific configurations, BMC Software will provide this support on a case-by-case basis with the specified customer.

For installing in Solaris LDom environments


For installing in Solaris LDom environments

A LDom are a logical grouping of resources which has its own operating system and identity. Note the following considerations when installing BMC Performance Assurance in a LDom environment:

■ Install the Perform Agent on the control LDom, so that the collector can identify systems as LDoms and collect configuration data about the LDoms. The collector reports configuration and statistical data for only the resources assigned to the LDom.

■ BMC Software recommends that you use LDom Management software version 1.1 or higher, to help correlate the activity of the LDoms back to the servers they reside on.

■ Visualizer graph support requires version 4.2.05 with latest patch.■ BMC Performance Perceiver support requires version 7.5.00.

Managing performance of Solaris ContainersThe following sections look at how to deploy collectors and interpret the subsequent analysis and reporting to support Solaris Containers.

Collecting and processing data from Solaris Container systems

You can automatically collect the data from the Solaris 10 systems you are interested in, processes the data, and store the data in a Visualizer database. The best practice for implementing BMC Performance Assurance in this type of environment is to create a Manager script to automate the process.



Since the global zone can “see” all the operations within the global and non-global zones, only the global zone needs collectors to be deployed. Each process has a non-global zone ID which initiates the process. Data analysis uses process-based information to produce resource usage break-down by non-global zones. Installing the Perform Agent in the global zone minimizes the installation effort and runtime overhead.



The following tasks describe the recommended process for collecting and processing data from Solaris 10 systems configured as zones.

Task 1: Set up a policy that includes the target Solaris systems








Task Refer to

Create a policy that includes the global zone. page 242









7 Click OK.







■ User Defined directs Analyze to aggregate workload usage based on the default or user defined workloads, regardless of whether or not the data comes from a system configured as a Solaris 10 Container environment (zones or a project). This option is the default and applies to data collected from any supported OS configuration. If you are collecting data from zones, however, keep in mind that this option will aggregate the workload utilization at the Container level, not at the individual zone level.

■ Zone directs Analyze to aggregate the workload usage based on the zone the workload was executing in, regardless of the default or user defined workloads. This option applies only to data collected from a Solaris 10 system that has been software partitioned using the Solaris 10 Containers technology, with zones configured. Use this option if you plan on viewing the results in Analyze, Visualizer, or Perceiver, and want the workload usage grouped by zone.

■ Project directs Analyze to aggregate the workload usage based on the settings from the project configuration file, regardless of user defined workloads. One of the configuration options in Solaris 10 is to create a project as a way of managing resources for processes running in a zone. This option applies only to data collected from a Solaris 10 system that has been software partitioned using the Solaris 10 Containers technology, with projects configured. Use this option if you plan on viewing the results in Analyze, Visualizer, or Perceiver, and want the workload usage grouped by project.




If you are interested in viewing the workload utilization aggregated by zone in Visualizer or Perceiver the Manager script file that automates the data collection and data processing tasks requires a workload characterization that builds workloads by either the zone or project option. This is necessary so that you can properly view the performance data in Visualizer or Perceiver.




3 In the Workload Characterization page assign a name for your workload characterization file, then click Next. For example, Solaris10_zone_wkld.




7 From the Build workloads by drop-down list, select Zone or Project, depending on how you want workload usage to be grouped in Visualizer.










4 Click Add to browse to the policy that has the computers you identified in “Task 1: Set up a policy that includes the target Solaris systems” on page 242. On the Select Policy File window, select the policy file and click Open.












To access the Status Report feature:



The Perform - Data Collection Status opens in the results pane. The available scripts are in the left portion of the report. To view the status of data collection, click on a script. You can also click Schedule in the scope pane to display the scripts in the results pane. Then right-click on the script for which you want to view reports and select View Status Report.

Displaying data in Visualizer for Solaris Container systems




The key graphs to review are

■ CPU Use Hierarchy graphs■ Solaris Container Hierarchy

CPU Use Hierarchy graph

The CPU Use Hierarchy graph, Figure 113, is a good way to view the data if the container is not the same as the physical system. This graph shows the relationship of the containers to the physical system. This graph does not include a breakdown by zone.

1 Click Database=> Select and select the database into which you populated the Solaris Container data.

2 Click Database=> Detail and choose the data for the graph. Ensure that you select ZONE from the Virtual Type drop-down list.

3 From the Graphics menu, choose Solaris Partition => CPU Use Hierarchy.



Figure 113 CPU Use Hierarchy graph for Solaris Containers

The following table provides some guidance for interpreting the key metrics available on this graph.

Metric Notes

%Total The percentage of CPU utilization out of the maximum available CPUs.

Max The maximum amount of CPU available, including all physical CPUs on the system. For example, if there are two physical CPUs on the system the Max value is 200.

Use and Rating Shows CPU utilization as SPECInts used and total SPECint Rating. The amount used could exceed the maximum rating since the maximum rating is based on the number of physical processors, and the SPECInts used is based on the number of logical processors.

%Proc Shows the % CPU utilization per physical processor. In this example this is 135.72% divided by 200%, or 67.86%.

%nPProc Shows the number of physical processors associated with the selected node.

%LProc Shows the % CPU utilization per logical processor.

nLProc Shows the sum of all the logical processors of the zones.

%Entlmnt This metric is not applicable in this environment.

Displaying data in Perceiver for Solaris Container systems


Solaris Container Hierarchy

Another graph to look at is the Solaris Container Hierarchy graph. From the Graphics menu, choose Solaris Partition => Solaris Container Hierarchy.

Figure 114 Solaris Container Hierarchy


If BMC Performance Perceiver detects data representing Solaris partitions and containers (and zones within containers), it displays the data in charts that you can view.

%Effctv This metric is not applicable in this environment.

%nHCore This metric is not applicable in this environment.

%HCore This metric is not applicable in this environment.

Capture This metric is not applicable in this environment.

Metric Notes



What views should I review in Perceiver?

For Oracle partitioned systems, Perceiver displays both global zone and non-global zone systems in the computer drop-down list. BMC Performance Perceiver displays Solaris systems data configured in the following scenarios:

■ A standalone system configured with multiple non-global zones and the non-global zones can be seen in the CPU Profile view under Solaris Container Summary. In this case, Perceiver views the global-zone system as a regular UNIX computer and makes all metrics and views available for this system.

■ A single computer configured with many dynamic system domains (DSDs). Each DSD can contain a number of non-global zones which can be seen under the Solaris Domain Summary By Resource view category. In this case, Perceiver views each DSD as a separate logical partition.

The CPU Profile view shows information on a host and its zones. If you select a host, you get the following tables and charts.

Figure 115 The Perceiver Solaris Container Summary

Finding out more using Investigate


This view contains four charts.

To view the DSD, refer to the Solaris Partition Overview. For more information on Perceiver views and metrics, refer to the online Help or the BMC Performance Perceiver Getting Started guide.


In Investigate, the Zone Configuration drill down provides configuration information for a Solaris Computers with Containers. The global zone as well as all non-global zones are listed in the drill down.

Metric Description

Host Solaris Zones Info Displays information of each of the zones configured on the selected host, including:

■ Zone name■ Logical System name■ Pset ID■ Number of virtual processors■ Amount of CPU shares


Displays Physical CPU Capacity Used for all the zones configured on the selected host.


Displays Zone CPU Capacity Used for all the zones configured on the selected host.



■ System Model■ Host Name■ System Description■ Processor Model■ Processor Description■ Processor Clock Rate■ Number of Configured Processors■ Number of threads per core■ Number of cores per socket■ Rating■ Rating Type■ Multi threading type■ Amount of Configured Memory■



Figure 116 Zone Configuration drill down

For more information on any of the metrics or metric groups, refer to Chapter 2 of the BMC Performance Assurance System Metrics for Microsoft Windows, UNIX, and Linux, Volume One.

The metrics associated with this metric group are

■ Zone ID - unique zone identifier■ Zone Name - name assigned to the Solaris zone■ Unique ID – a counter of how many times it has been rebooted■ Pool ID – resource pool ID with which the zone is associated ■ Init PID – process identifier (PID) of initialization process■ CPU Shares - sum of shares of all active projects is used in calculating the portion

of CPU resources to be assigned to projects■ Root – path to root file system

Pool Configuration

The Pool Configuration drill down provides pool information for configured pools on a Solaris computer.

NOTE The tasks described in the following sections are for the UNIX version of the BMC Performance Assurance console. Similar support is available for the Windows console. For instructions on how to complete these tasks using the UNIX console, see BMC Performance Assurance for Microsoft Windows Implementation Guide for Microsoft Windows.



Figure 117 Investigate Pool Configuration

The metrics associated with this metric group, collected when pools are enabled, are

■ Pool Id - unique resource pool identifier■ Pool Name - resource pool name■ Pool Status (0 = inactive, 1 = active)■ Pool Default - is this the default pool (0 = no, 1 = yes)■ Pset Id - processor set identifier■ Pset Name - name assigned to the processor set■ Pset Size – number of processors in the processor set■ Pset Min – minimum processors in the processor set■ Pset Max – maximum number of processors in the processor set■ Pset Default – is this the default processor set (0 = no, 1 = yes)■ Pset Cpus – all cpus assigned to the processor set (semicolon separated list)

Process Statistics drill down

The Process Statistics drill down displays process information for Solaris computers running Containers. This view lets you identify the processes running in the global zone along with each of the non-global zones in the physical system. The drill down below shows process statistics for both the global zone and non-global zone (bmc-zone5).



Figure 118 Process Statistics drill down

The Investigate filter feature lets you view the process statistics for a particular zone. Process Statistics for the remaining global and non-global zones on the computer are not displayed in the drill down. In Figure 119 the drill down would display process statistics for the global zone, which has a Zone ID equal to 0.

Figure 119 Investigate filter

Managing performance of Oracle partitioned (DSD) systems


Managing performance of Oracle partitioned (DSD) systems

The Perform Solaris collector gathers partition (DSD) configuration data when it is installed on a System Controller. A metric group is available in Investigate that shows the Physical Partition Configuration data. For complete descriptions of these metrics, see BMC Performance Assurance System Metrics for Microsoft Windows and Unix, Volume One and Volume Two.

Displaying Data in Analyze from Oracle Partitioned Systems

For Oracle partitioned systems, Analyze groups the systems according to the physical hardware on which they are installed, and displays this information in the Analyze Physical System report as shown in Figure 120.

Figure 120 The Analyze Physical System Report for Oracle Partitions

When a System Controller is part of a data collection and is included in the list for processing, Analyze detects if there are any missing partitions from the current processing and displays N/A in the columns for those systems. This information helps you understand if there are any additional partitions that should be included, helping you form a complete understanding of the partitioned environment. For more information on the Physical System report, refer to the Analyze Online help.

Modeling Data from a Oracle Partitioned Environment

Predict identifies if a system is running as a stand-alone machine, as a partition, or in a virtualized environment. The relationship between the physical computer and a partition is clearly presented with icons, as shown in Figure 121.

Modeling Data from a Oracle Partitioned Environment


Figure 121 Partitioned System Icon in Predict

With Predict, you can perform any of the following tasks as a part of your “What-if...” analysis of a partitioned system:


The Predict Physical System Summary report provides information on the configuration of the hardware partition, and specific information on each computer in the partition. An example of the report is shown below.

Figure 122 Predict Physical System Summary report for a Oracle Partition


Visualizer reports identify if a machine is running in a partition. The physical computer name is displayed on the CPU diagram. The CPU utilization of the partitions are displayed to present the total physical CPU consumption.

Managing performance of Oracle Logical Domains


Managing performance of Oracle Logical Domains

Logical Domains (LDoms) are virtual environments within the Oracle Solaris operating system. Several LDoms share a physical processor, but each operates like an independent processor. The collector for Solaris 10 identifies each LDom as if it is an independent processor, as well as sharing processing resources of a physical processor. It returns utilization information and metrics for the physical processor, each LDom within the processor, and each LDom’s share in the physical processor’s total capacity.

Displaying data in Investigate from Oracle LDoms

The Perform Solaris collector gathers LDom configuration data when it is installed on a System Controller. A metric group is available in Investigate that shows the Physical Partition Configuration data. For complete descriptions of these metrics, see BMC Performance Assurance System Metrics for Microsoft Windows and Unix, Volume One and Volume Two.

Displaying Oracle LDom CPU usage in Visualizer

To view Oracle LDom data from Visualizer, complete the following steps:

1 Click Database=> Select and select the database into which you populated the Oracle LDom data.

2 Click Database=> Detail and choose the data for the graph. Ensure that you select LDOM from the Virtual Type drop-down list.

3 From the Graphics menu, choose Solaris Partition => Solaris LDOM Hierarchy.

Displaying Solaris LDom CPU Use in Perceiver


Figure 123 Solaris LDOM Hierarchy


You can also use BMC Performance Perceiver to view performance data for the Solaris LDom virtualization platform.

The CPU Profile view under Solaris LDom Host Summary shows information on an LDom host and its domains.



Figure 124 Solaris LDom CPU use in Perceiver

If you select a host, you get the following tables and charts.

Metric Description

LDom Host Partition Info Displays information of each of the LDom(s) configured on the selected host, including:

■ Partition name■ Node name■ Number of dedicated threads■ Number of dedicated processors

% Capacity Used Displays the % Physical Used Total and % Domain Used Average of all LDom(s) for the selected host.

Modeling data from a Oracle LDom environment




LDom data is modeled similarly to a regular node. For instructions on modeling a node, see BMC Performance Assurance Implementation Guide for UNIX.

However, due to its CMT characteristics, note the following differences when modeling a node from an LDom environment:

■ At the host level, a thread-utilization option is displayed in the LDom Properties window at the physical system level.— For a newly created Oracle Host with LDom, this field is set to enabled when

browsing CPU Model filtered by UltraSparc T1, T2 or T2+. — For existing nodes created from Analyze, this field will be set by Analyze and

displayed correspondingly.

Top 10 Domain CPU Capacity Used

Displays the top 10 Domain CPU Capacity Used of LDom(s) for the selected host.


Provides the system configuration information that is available for the LDom host, including:


Metric Description



Figure 125 LDom Properties dialog box

■ At the logical system level, Logical Domain is the partition type for LDom

Figure 126 Logical System Name dialog box

■ The Thread-Per-Core field obtains its value from the CPU Model at the host level. This field appears only on LDom logical systems.



Figure 127 LDom Thread-Per-Core field

■ The Total threads field appears in the LDom Properties dialog, which equals the total number of processors times the number of threads per core.

Figure 128 LDom Total thread count

■ Resource Allocation is based on threads instead of cores.

Managing performance with Chip Multi-Threading


Figure 129 LDom Resource Allocation

Managing performance with Chip Multi-Threading

BMC Performance Assurance can identify each thread within each core of each UltraSPARC processor. Analyze, Predict, and Visualizer may show processor utilization of up to 3200%, or 100% utilization of 32 processing threads.

Modeling an UltraSPARC processor


Figure 130 Analyze utilization report for Oracle UltraSPARC processor


Follow the procedure below to model a Oracle UltraSPARC T1 or T2 processor.

1 Before creating the new model, you must add the processor’s description into the User hardware Table.

2 In the BMC Performance Assurance console, open Predict.

3 Right-click the processor from the Computers tree hierarchy and select Properties.



The processor’s Properties dialog appears.

Figure 131 Predict Properties dialog for a CMT processor

4 Click Browse to select the processor model and CPU clock speed.

5 In the Online processors field, verify that the number of Software threads is equal to or higher than the processor’s hardware threads.

You can verify the number of software threads in Visualizer’s Commands Hierarchy graph, NumProc metric.

6 Click OK to define and close the model.

NOTE If the processor receives fewer software threads than the available number of hardware threads, than the model will predict better performance than the physical processor will actually achieve.


C h a p t e r 77 Implementing Performance Assurance on Xen Systems


Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269Support for Xen nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270Benefits of using BMC Performance Assurance in this environment . . . . . . . . . 270

Installation and configuration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271Collecting and processing data from Xen systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

How do I collect and process the data? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271Viewing results in Analyze. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279Viewing results in Perceiver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

Xen Partition Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281Xen Host Summary by Resource. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285Xen Partition Summary by Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

Modeling Xen servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289Working with Xen systems in Predict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289View the Predict report for Xen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292Virtualization Planning support for Xen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

OverviewXen virtualization consists of a Node, which is the host machine and that host machine runs 1 or more domains. Domain-0 (DOM-0) represents the host system. Each guest OS is called a DOM-U where the 'U' is a number. For example a machine that has 4 guests would have DOM-0 through DOM-5. The numbering scheme for the domains is not always linear. For example you could have 4 guests, one could be DOM-2, the next one could be DOM-4, then the next two could be DOM-5 and DOM-6. Each time a domain is shut down and restarted it is potentially given a new domain number.

Support for Xen nodes


Figure 132 Xen architecture

BMC Performance Assurance supports:

■ Citrx Xen■ Open Source Xen

Support for Xen nodes

Xen provides a way of virtualization by creating domains, inside the operating system image. The operating system image that contains the domains is called the node.

What is not supported

■ Proxy collection

Benefits of using BMC Performance Assurance in this environment

BMC Performance Assurance can help manage the performance of each Xen domain and report the appropriate performance data for the Xen node.

Installation and configuration considerations


Performance data collected from within the domain operating system may be used to display the “relative” resource usage of individual processes. All domains share system resources, so obtaining accurate measurements of total actual resource usage is necessary to provide a complete picture of system usage.

Installation and configuration considerations

Collecting and processing data from Xen systems

You can automatically collect the data from the Xen systems you are interested in, processes the data, and store the data in a Visualizer database. The best practice for implementing BMC Performance Assurance in this type of environment is to create a Manager script to automate the process.



The following tasks describe the recommended process for collecting and processing data from Citrix Xen and Open Source Xen.

Task Refer to

Create a policy that includes Xen nodes. page 272





NOTE Proxy collection is not supported for Xen data.



Task 1: Set up a policy that includes the target Xen systems









7 Click OK.










■ User Defined directs Analyze to aggregate workload usage based on the default or user defined workloads, regardless of whether or not the data comes from a system configured as a Xen domain. This option is the default and applies to data collected from any supported OS configuration. If you are collecting data from nodes, however, keep in mind that this option will aggregate the workload utilization at the node level, not at the individual domain level.

■ Partition directs Analyze to aggregate the workload usage based on the zone the workload was executing in, regardless of the default or user defined workloads. This option applies only to data collected from a Solaris 10 system that has been software partitioned using the Solaris 10 Containers technology, with zones configured.

■ Partition directs Analyze to aggregate the workload usage based on the node the workload was executing in, regardless of the default or user defined workloads. This option applies to data collected from a Xen (Citrix Xen or Open Source Xen) system that has been software partitioned using the Xen technology, with nodes and domains configured.

■ Project directs Analyze to aggregate the workload usage based on the project setting from the FSS Config file, regardless of user defined workloads. One of the configuration options in Solaris 10 is to create a project as a way of managing resources for processes running in a zone. This option applies only to data collected from a Solaris 10 system that has been software partitioned using the Solaris 10 Containers technology, with zones and projects configured.


If you are interested in viewing the workload utilization aggregated by partition in Visualizer or Perceiver the Manager script file that automates the data collection and data processing tasks requires a workload characterization that builds workloads by either the partition or project option. This is necessary so that you can properly view the performance data in Visualizer or Perceiver.






3 In the Workload Characterization page assign a name for your workload characterization file, then click Next. For example, CitrixXen_wkld.




7 From the Build workloads by drop-down list, select Partition or Project, depending on how you want workload usage to be grouped in Visualizer.










4 Click Add to browse to the policy that has the computers you identified in “Task 1: Set up a policy that includes the target Xen systems” on page 272. On the Select Policy File window, select the policy file and click Open.












To access the Status Report feature:



The Perform - Data Collection Status opens in the results pane. The available scripts are in the left portion of the report. To view the status of data collection, click on a script. You can also click Schedule in the scope pane to display the scripts in the results pane. Then right-click on the script for which you want to view reports and select View Status Report.

Viewing results in Analyze



Viewing results in AnalyzeAnalyze has one report that presents information specific to Xen. To view the report, you must create a workload characterization file that includes the Xen node. An Analyze workload characterization contains parameters for

■ Creating a performance model for use by Predict ■ Viewing charts of performance data ■ Creating performance reports■ Creating input files for Visualizer

When you run Analyze, it uses the workload characterization to evaluate collected performance data, and create a performance model, reports, and, optionally, Visualizer input files.

To generate the Xen Summary report, perform the following steps:

1 Right-click Analyze in the Tree view, and choose Open Workload Characterization.

2 Choose the appropriate workload characterization (.an) file for the Xen system.

3 Review the displayed interval or set another interval.

4 Run Analyze by clicking on the green arrow in the menu bar, or right-click on the Workload Characterization in the Tree view and choose Start Analyze.

5 Expand the Reports item and then expand the Xen selection.

Viewing results in Analyze


Figure 133 Analyze Xen Summary


Column Description

Xen Host The name of the Xen node that provides all of the management functions for the Xen domains. For reporting purposes, this name is used to refer to the physical host machine.

Partition This value is used to refer to the Xen domain. Each domain is identified by its display name specified in the Xen configuration file.

Guest OS The operating system type installed as a guest OS on the VM. Each VM can run Microsoft Windows or Linux as guest OSs.

Physical Processors

The number of physical processors on the Xen server system. This value is shown only for the top-level server information.

Logical Processors The number of logical processors on the Xen server system. This value is shown only for the top-level server information.

Virtual Processors The number of CPUs allocated to the Xen domain. This value is shown for each Xen domain.

CPU Util The percentage of CPU time used by a Xen domain. The CPU usage shown in this column is a physical value; it represents the total CPU usage of the amount of CPU that has been allocated for the Xen domain.

CPU Shares The number of CPU shares assigned to a Xen domain.

CPU Min The guaranteed minimum CPU percentage reserved for this Xen domain.

Viewing results in Perceiver


Viewing results in PerceiverYou can also use BMC Performance Perceiver to view performance data for Xen systems.


■ Xen Partition Overview■ Partition Overview■ Partition Metrics

■ Xen Host Summary by Resource■ CPU Profile■ Memory Profile■ IO and Network Usage

■ Xen Partition Summary by Resource■ CPU Profile■ Memory Profile■ IO and Network Usage

Xen Partition Overview


CPU Max The maximum CPU percentage for a Xen domain. The valid range of values is from zero (“0”) to the number representing the total physical CPU resources. The maximum may be greater than 100 for SMP virtual machines that may use more than one full physical CPU.

Total Memory The amount of RAM (in MB) for the physical machine. This value is shown only for the top-level Xen node service console row.

Partition Memory Configured

The memory required for single copy of memory shared between Xen domains.

Memory Utilization

The sum of all memory used for running Xen domains.

Xen Type Specifies the type.

Column Description



Partition Overview

Description: This view displays multi-partition charts for the essential metrics (Physical CPU Capacity Used, Virtual CPU Capacity Used, IO Rate, Physical Memory Used, Network Rate) in your datacenter, in line charts by group of root partitions.

Figure 134 Xen Partition Overview

This example shows that all computers in the group have been chosen. You can view information for a particular partition by clicking the drop-down list next to the Computer field.



The ranking table (partially shown in Figure 134 and shown expanded in Figure 135 on page 283) shows which partitions (domains) are approaching the resource usage limits on their Xen hosts (zones). It also shows where the computers being measured fall in increments of 10 percentage points, based on a blended value of the essential metrics (Physical CPU Capacity Used, Virtual CPU Capacity Used, IO Rate, Memory Utilization, Network Rate).

Figure 135 Xen Partition Overview Ranking Table

This example provides information for all computers in the group. However, if you want to view this information for a particular subset, for example the partitions that fall in the 80 - 100 percentile, you can select those computers and click the filter icon to see only those graphs. Figure 136 and Figure 137 show how this might look.

Figure 136 Filtering computers in the Ranking Table



Figure 137 Computers filtered using the Ranking table

Xen Partition Metrics

(Figure 138 on page 285) (Histogram - 95 percentile) shows the following partition information:

■ Physical CPU Capacity Used - Partition Physical CPU Capacity Used■ Virtual CPU Capacity Used - Partition Virtual CPU Capacity Used■ Memory Utilization - Partition Memory Usage■ Network Rate - Partition Network Rate■ IO Rate - Partition Total IO Rate

Xen Host Summary by Resource


Figure 138 Xen Partition Metrics



CPU Profile

CPU Profile shows the following information for the host that is chosen:

■ CPU Utilization by Partition - CPU Utilization - per Partition■ Virtual CPU Capacity Used by Partition - Virtual CPU Capacity Used - per

Partition■ % Virtual CPU Used - Xen % Virtual CPU Used■ Virtual Processors Configured - Virtual Processors Configured - per Partition ■ Host System Hardware Configuration - Xen Host System Hardware Configuration

Below the CPU Profile graphs (Figure 139 on page 286), the Host System Hardware Configuration table displays information about the host hardware configuration. You can expand this table by clicking the plus sign in the top right portion of the table.



Figure 139 Xen Host Summary by Resource CPU Profile

Memory Profile

The Memory Profile view shows the memory configuration, memory utilization, and memory swapping rate for the partitions located on the host computer chosen from the Computer drop-down list.

Figure 140 Memory Profile

Xen Partition Summary by Resource


IO and Network Usage

The IO and Network Usage view shows the IO network rate by partition, network interlaces configured by partition, the IO rate by partition, and the disks configured by partition for the partitions located on the host chosen in the Computer drop-down list.

Figure 141 IO and Network Usage



CPU Profile

CPU Profile for individual partitions shows:

■ Physical and Virtual CPU Capacity Used - Partition Physical CPU Capacity Used, Partition Virtual CPU Capacity Used

■ Virtual Processors Configured - Partition Virtual Processors Configured■ Partition System Identification and Configuration ■ Host Physical and Logical Processors Configured - Xen Host Physical Processors

Configured, Xen Host Logical Processors Configured■ Host System Hardware Configuration - Xen Host System Hardware Configuration



Below the CPU Profile graphs (Figure 142 on page 288), the Host System Hardware Configuration table displays information about the host hardware configuration. You can expand this table by clicking the plus sign in the top right portion of the table.

Figure 142 Xen Partition Summary by Resource - CPU Profile

Memory Profile

The Memory Profile view shows the memory utilization, and memory swapping rate for the partition chosen from the Computer drop-down list.

Figure 143 Xen Partition Summary by Resource - Memory Profile

Modeling Xen servers


IO and Network Usage

The IO and Network Usage view shows the IO network rate, network interlaces configured, the IO rate, and the disks configured for the partitions chosen from the Computer drop-down list.

Figure 144 Xen Partition Summary by Resource - IO and Network Usage

Modeling Xen serversUsing Predict to model a Xen system can help you decide which domains on the Xen node affect overall performance. You can use this information to experiment with different configurations of nodes and domains to see how to achieve the best mix. You can also use the Scenario Planner capability to perform long-term capacity planning.

See the online help for detailed, step-by-step procedures for using the windows, menus, and dialog boxes of the Predict user interface.

Working with Xen systems in Predict

The following sections describe how to prepare the model for “What if...?” analysis.



Identify the Xen nodes and domains

The Xen node is displayed at the same level as a standalone computer. The partitions (domains) associated with the node are displayed at a secondary level to the Host Server, as shown Figure 145.

Figure 145 Xen nodes and domains in predict

Evaluate the Model




■ verify or correct the information in the model■ identify any resources that might be exceeding your service level objectives. The

guideline and threshold apply only to the Xen node.


TIP A model containing Xen nodes and the associated domains is much like a model containing physical machines. You can change the node or domain configuration settings (such as CPU, memory, CPU shares, and so on), prior to baselining.



Display the properties of the Xen system

Right click on a Xen node, or a domain icon. Select Properties and then click the Configuration tab to display the system attributes. Figure 146 on page 291 shows the properties of a Xen node and a domain in that node.

Figure 146 Xen Host properties

For either the Xen host or the partition itself, you can click the Virtual System Allocation button on the Configuration tab to see how the system resources are being allocated across the partitions, as shown in Figure 147. You can reassign the physical system resources among the virtual machines using this dialog box.

Figure 147 Resource allocations for partitions

Xen Virtual machine (domain)Xen Host (node)

View the Predict report for Xen



Predict offers a variety of charts and reports that you can use to examine the results of your “What if…?” studies. These charts and reports contain a summary of network, computer, workload, transaction, and disk activity for each period.

After you have evaluated the model, there are two perspectives for the Xen system that you can view on the Predict Xen Summary report: the overall physical (host) system and the individual VMs.

You can view the Predict Xen summary report to examine the CPU performance in terms of “degradation”. Degradation is the ratio of system response time to service time. The two types of degradation shown on the report are: degradation due to the overall activity associated with the Xen host (shown on the report as Overall Response Time Wait), and degradation due to other activity attributed to other VMs (shown as Other VM Response Time Wait).

Finally, you can review other information such as I/O rates to virtual disks and configuration information for the individual VMs.

See the online Help for descriptions of the Predict reports and for information on working with them.

To view the report:

■ Expand the Reports tree in the scope pane.■ Expand the Computer tree. ■ Select the Xen Summary report. Predict displays the report in the results pane, as

shown in Figure 148.



Figure 148 Predict Xen Summary report

The following table describes the columns in this report. You may need to scroll to the right of the report to see some of these columns.

Column Description

Xen Host The name of the Xen host (zone) that provides all of the management functions for the VMs (domains). For reporting purposes, this name is used to refer to the physical Xen Host Server.

VM System This value is used to refer to the VM. Each VM is identified by its display name specified in the Xen configuration file. This display name is not guaranteed to be unique on the Xen host.

CPU model The model number of the hardware.

Vendor The hardware vendor.

Processor For the Xen Host, this is the total number of physical processors. For VMs, this is the number of virtual processors.

Util For the Xen Host, this is the percent of CPU utilization out of online processors * 100. For the VM, this is the percent of CPU utilization out of physical online processors * 100, with a maximum value of the number of virtual processors * 100.

% utilization out of For the Xen Host this equals the online processors * 100.

Total Disk I/O The total disk I/O for the Xen Host is the sum of the I/Os for all the VMs running on that host.

Virtualization Planning support for Xen


Virtualization Planning support for Xen

The Perceiver Virtualization Planning module recognizes existing Xen virtualization components (guests and hosts) in a monitored environment. These components, along with a study profile describing Xen virtualization attributes, can be used to perform Virtualization Planning exercises of current or future Xen environments. For information about deploying new guests or rebalancing existing virtual hosts, see the BMC Performance Perceiver Getting Started guide.

Total Memory For the Xen Host this is the total physical memory. For the VMs, this is the total virtual memory. The memory for the Xen Host is not the sum of the virtual memory of the VMs.

Overall Response Time Wait The percentage of CPU wait time due to all virtual machines (including itself) on the Xen Host Server.

Other VM Response Time Wait

The percentage of CPU wait time due to activity from other virtual machines.

Column Description

Index 295

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Index

Numerics1 Min Average CPU Load 18915 Min Average CPU Load 1895 Min Average CPU Load 189

AAIX partitions

introduction 12types of 12

AnalyzeBuild workload options 183, 243, 273

Analyze Physical System Reportfor AIX Partitions 140for HP-UX Partitions 204

Analyze reportsfor VMware 38, 40, 42, 43Shared Processor Partition Report for SPLPARS 142

Automator scriptsetting up for Solaris containers 185, 245, 275setting up for Virtual Server 104setting up for VMware 33

Avg. Run Q Len 189Avg. Swap Q Len 189

BBMC Software, contacting 2Buffer Block Reads

description 189Buffer Block Writes

description 189Buffer Cache Size 189Build workload by

Project setting 243User Defined setting 183, 243, 273Zone setting 183, 243

CCollecting data

from a HP-UX partition 201from a Microsoft Virtual Server 101from an AIX partition 136

from Solaris 10 systems 181, 241, 271verifying the data collection of Solaris 10 systems 248,

278verifying the data collection of Virtual Servers 106verifying the data collection of VMware systems 36

collecting VMware data 24Configuration requirements in an AIX environment 130configuration tasks

set up VMware proxy data collection 22configure_ssh configuration file 132Containers and zones

overview 16Copying the public key 135CPU Activity by virtual machine 110CPU System by VM 49CPU Use Hierarchy graph for Containers 249CPU User by VM 49CPU Utilization by VM 49creating a policy 32, 102, 182, 242, 272custom workload characterization file 183, 243, 273customer support 2

DDisplaying AIX hardware partition CPU usage in

Visualizer 144Displaying data

from AIX partitioned systems 138from HP-UX partitioned systems 201, 213from Microsoft Virtual Servers 107from VMs 37

Displaying HPhardware partition CPU usage in Visualizer 205

Displaying Hyper-V CPU usage in Visualizer 111, 259Displaying VM CPU usage in Visualizer 44DLPARs, defined 12Dynamic System Domains, described 15

EEnabling remote command execution on the HMC 131



HHardware Management Console (HMC), described 13HP-UX partitions

implementing Perform 199introduction 14

Iidentifying VMware hosts and VMs in Predict 61, 290implementing Perform

in a Microsoft Virtual Server environment 98in a VMware environment 20on a Sun DSD partition 239on Solaris 10 systems with Containers 241

implementing Perform on an HP partition 199Installation considerations

for Solaris 10 systems 130, 240for Solaris DSDs 240in a AIX environment 129in a HP-UX environment 200in a VMware environment 21

installation considerations for Perform Agent in Microsoft Virtual Server environment 99, 100

Installing SSH on the AIX partition 134introduction to AIX partitions 12IO Activity by virtual machine 110

LLogical Buffer Reads

description 189LPARs, defined 12

MManager script

setting up for Microsoft Virtual Servers 105setting up for Solaris containers 186, 246, 276setting up for VMware 31, 34

Manually configuring the AIX environment 134Manually creating a user on the HMC 135Manually generating the RSA or DSA keypair 135Message

definition 190metric groups

for AIX partitions 138for HP-UX partitions 202, 214, 218for Microsoft Virtual Servers 101for Solaris 10 zones 254

Microsoft Virtual Machine Additions, how to install 100Microsoft Virtual Server

collecting data from 101implementing BMC Performance Assurance 98

installing Perform Agent 99, 100introduction 11

ModelingAIX partitioned systems 164HP-UX partitioned systems 207VMware systems 61, 289

NNum System fork calls 189

Ooverview of Dynamic System Domains 15overview of HP partitions 14overview of Microsoft Virtual Server 11overview of Solaris 10 Containers 16overview of Solaris partitions 15overview of VMware 10

PPage Ins 189Page Outs 189Pages Scanned 189Perceiver views

Solaris Container Overview 252Perform Agent

installation considerations for Microsoft Virtual Server 99, 100

installation considerations for VMware 21Pg Ins Pging 189Pg Outs Pging 189Physical Reads

description 190Physical System Report

for AIX Partitions 140for HP-UX Partitions 204

Physical System Summary Reportfor AIX partitions 165for HP-UX Partitions 208, 232

Physical Writesdescription 190

Predict Physical System Summary Reportfor AIX Partitions 165for HP-UX Partitions 208, 232

Process Context Switches 189product support 2Project option for building workloads 243

RRun Occ 189Run Q 189

Index 297


SSemaphore

definition 190setting up a Manager script 31, 34, 105, 186, 246, 276setting up a policy

for Microsoft Virtual Server systems 102for Solaris systems 182, 242, 272for VMware systems 32

setting up an Automator script 33, 104, 185, 245, 275Shared Processor Partition Report for SPLPARS 142Solaris Container Overview 252SPLPARs, defined 12Sun partition

implementing Perform 239implementing Perform on a systems using Containers

241Sun Solaris partitions

Containers and zones 16Dynamic System Domains 15introduction 15

support, customer 2Swap Space Ratio (Unix) 189Swap Space Utilization

description 189System Hardware Configuration 110

Ttechnical support 2Total 189Total Pg Pging 189Types of AIX partitions 12

UUsed Memory (Unix) 189User Defined option for building workloads 183, 243, 273

Vverifying the data collection of Solaris 10 systems 248, 278verifying the data collection of Virtual Server systems 106verifying the data collection of VMware systems 36Virtual CPU Capacity Used 49Virtual Processors Configured by VM 49Virtual Systems, introduction 9Visualizer

CPU Use Hierarchy graph for Containers 249displaying graphs for AIX 144displaying graphs for HP 205displaying graphs for Hyper-V 111, 259displaying graphs for VMware 44VMware CPU by Host/VM graph 46

VMwareimplementing BMC Performance Assurance 20install considerations of Perform Agent 21introduction 10VMware ESX Server virtualization layer, defined 10VMware ESX Server, defined 10

VMware CPU by Host/VM graph 46VMware Disk Report 42VMware Memory Report 40VMware Per Processor Report 43VMware proxy host

requirements 24setting up for data collection 22

VMware Summary Report 38

Wworking with VMware systems in Predict 61, 289

ZZone option for building workloads 183, 243Zones

overview 16

*202938**202938**202938**202938*

*202938*

BMC Performance Assurance Virtual Servers

Documents

Transcript of BMC Performance Assurance Virtual Servers