Note: Before using this information and the product it supports, read the information in “Notices” on page xvii.

Fifth Edition (January 2017)

This edition applies to Version 1 Release 3, Modification 2 of IBM PowerVC Standard Edition and IBM Cloud PowerVC Manager (product number 5765-VCC).

Figures

1-1  PowerVM NovaLink partition 4

1-2  IBM PowerVC interface 5

1-3  Host Registration window 6

1-4  PowerVM NovaLink diagrams 6

2-1  VIOS settings that must be managed by IBM PowerVC 24

2-2  Modify the maximum virtual adapters 25

2-3  Host group sample 26

2-4  Migration of a partition by using a placement policy 29

2-5  Memory region size view on the HMC 33

2-6  IBM PowerVC storage access by using vSCSI 37

2-7  IBM PowerVC storage access by using NPIV 38

2-8  IBM PowerVC storage access by using an SSP 39

2-9  IBM PowerVC managing PowerKVM storage access 40

2-10  IBM PowerVC storage providers 41

2-11  Fabrics window that shows an embedded switch GUI 41

2-12  Storage pools 42

2-13  Storage templates 43

2-14  Storage template definition: Advanced settings, thin-provisioned 45

2-15  Volume creation 46

2-16  List of storage connectivity groups 47

2-17  Storage connectivity groups 48

2-18  Content of a storage connectivity group 49

2-19  Storage connectivity group redundancy 50

2-20  Storage connectivity groups and tags 51

2-21  Examples of storage connectivity group deployments 52

2-22  Standard SR-IOV network design 57

3-1  IBM PowerVC version check 76

3-2  IBM PowerVC version 76

3-3  Maintenance message for logged-in users 85

3-4  Maintenance message for web users 85

4-1  IBM PowerVC Standard Edition home window access to a group of functions 92

4-2  IBM Cloud PowerVC Manager home window access to a group of functions 93

4-3  IBM PowerVC Login window 95

4-4  Verify Environment 96

4-5  HMC connection information 97

4-6  PowerVM NovaLink connection information 98

4-7  IBM PowerVC Add Hosts window 99

4-8  Managed hosts 100

4-9  IBM PowerVC shows the managed hosts 100

4-10  Host information 101

4-11  Host CPU usage history 101

4-12  Place the host into maintenance mode 102

4-13  Virtual machine migration 103

4-14  Create Host Group 104

4-15  Add HMC Connection 106

4-16  Change the HMC credentials 107

4-17  Change the HMC 107

4-18  Select the new HMC for hosts 108

4-19  Add extra storage providers 109

4-20  Add Storage 110

4-21  IBM PowerVC window to select a storage pool 111

4-22  Add Fabric window 112

4-23  IBM PowerVC Add new Fabric 113

4-24  IBM PowerVC Storage providers tab 114

4-25  IBM PowerVC Fibre Channel port configuration 115

4-26  IBM PowerVC Storage Connectivity Groups window 116

4-27  IBM PowerVC Add Member to storage connectivity group window 117

4-28  Disable a storage connectivity group 118

4-29  Create storage template 119

4-30  IBM PowerVC Create Storage Template window 120

4-31  IBM PowerVC Storage Template Advanced Settings 121

4-32  IBM PowerVC Storage Templates window 121

4-33  IBM PowerVC Create Volume window 122

4-34  List of IBM PowerVC storage volumes 123

4-35  IBM PowerVC network definition 124

4-36  IP Pool tab 125

4-37  Available SR-IOV physical ports at the NovaLink host and their current state 126

4-38  Add SR-IOV Network 127

4-39  SR-IOV Network available after creation 127

4-40  Add SR-IOV Network adapter to the VM 128

4-41  Deployed VM with an SR-IOV network adapter available 129

4-42  IBM PowerVC Create Compute Template 130

4-43  IBM PowerVC Compute Templates 131

4-44  IBM PowerVC interface while environment verification in process 131

4-45  Verification Results view 132

4-46  Example of a validation message for an error status 134

4-47  Operations icons on the Virtual Machines view 135

4-48  Select a host window 135

4-49  Selected hosts window 136

4-50  Collapse and expand sections 136

4-51  Add existing VMs 137

4-52  Example of an informational message 138

4-53  Virtual machine detailed view with collapsed sections 139

4-54  Virtual machine detailed view of expanded Information section 140

4-55  Virtual machine detailed view of the expanded Specifications section 141

4-56  Virtual machine detailed view of expanded Network Interfaces section 142

4-57  Detailed Network Overview tab 142

4-58  Virtual machine Refresh icon 143

4-59  Virtual machine fully started 144

4-60  Virtual machine powered off 145

4-61  NovaLink managed host virtual console 146

4-62  Capture boot and data volumes 153

4-63  Capture window confirmation 154

4-64  New Image 154

4-65  Expanded information for a captured image 155

4-66  Volumes section and Virtual Machines section 156

4-67  Information to deploy an image 157

4-68  Add an Ethernet adapter for a virtual machine 160

4-69  Create Collocation Rule 161

4-70  Virtual Machines: Resize 162

4-71  VM Resize window to select a compute template 162

4-72  Exceeded value for resizing 163

4-73  Migrate a selected virtual machine 166

4-74  Select the target server before the migration 166

4-75  Virtual machine migration in progress 167

4-76  Virtual machine migration finished 167

4-77  Enter Maintenance Mode 168

4-78  Migrate virtual machines to other hosts 169

4-79  Exit Maintenance Mode 169

4-80  Create a compute template with enabled remote restart capability 171

4-81  Correct remote restart state under the Specifications section 172

4-82  Remotely Restart Virtual Machines option 172

4-83  Remotely Restart Virtual Machines 173

4-84  Destination host 173

4-85  Attaching a new volume to a virtual machine 174

4-86  Attached Volumes tab view 175

4-87  Detach a volume from a virtual machine 176

4-88  Confirmation window 176

4-89  Reset the virtual machine’s state 177

4-90  Image that is selected for deletion 178

4-91  Delete an image confirmation window 178

4-92  Unmanage an existing virtual machine 179

4-93  Delete a virtual machine 179

4-94  Select Volumes window to delete selected volumes 180

4-95  Users information 182

4-96  Detailed user account information 182

4-97  Groups tab view under Users on the IBM PowerVC management host 186

4-98  Detailed view of viewer user group on the management host 186

5-1  IBM PowerVC Login window 191

5-2  IBM PowerVC home window 192

5-3  IBM PowerVC Add Host window 193

5-4  Informational messages 193

5-5  Host added successfully 193

5-6  IBM PowerVC managing PowerKVM hosts 194

5-7  Detailed Hosts view 194

5-8  PowerKVM host information and capacity section 195

5-9  PowerKVM Virtual Switches and Virtual Machines sections 196

5-10  Add a storage device to IBM PowerVC 197

5-11  SAN Volume Controller storage pool choice 198

5-12  The new SAN Volume Controller storage provider 199

5-13  Add a network to the IBM PowerVC configuration 200

5-14  Network is configured 201

5-15  List of virtual switches 202

5-16  Edit virtual switch window 203

5-17  Message about conflicts with the updated virtual switch selections 203

5-18  Details of the virtual switch components 204

5-19  Create a host group 205

5-20  Upload Image window 207

5-21  ISO images that were imported to IBM PowerVC 208

5-22  Status of the imported ISO image 208

5-23  RHEL ISO image details 209

5-24  Select the image for deployment 210

5-25  Virtual machine deployment parameters 211

5-26  Deployment in-progress message 211

5-27  Successful deployment verification message 212

5-28  Virtual Machines view with highlighted State and Health columns 212

5-29  Detailed information 213

5-30  Detailed information with expanded or collapsed sections 214

5-31  Stop the virtual machine 214

5-32  Virtual machine started and active 215

5-33  Warning message before you capture the VM 221

5-34  Capture window 222

5-35  Snapshot in-progress message 222

5-36  Status from the Virtual Machines view 223

5-37  Snapshot status from the Images view 223

5-38  General and network sections of the window to deploy a VM 224

5-39  Activation Input section of the window to deploy a virtual machine 225

5-40  Deployment is started message 225

5-41  Virtual Machines view 226

5-42  Resize virtual machine window 227

5-43  Suspend or pause a virtual machine 228

5-44  Restart a virtual machine 228

5-45  Migrate a virtual machine 229

5-46  Migrate a virtual machine 230

5-47  Remotely Restart Virtual Machines option 230

5-48  Select virtual hosts to restart remotely 231

5-49  Virtual machines that were restarted remotely 231

5-50  Delete a virtual machine 232

5-51  Create Volume window 233

5-52  Attach a new volume to a virtual machine 234

5-53  Attach an existing volume to this virtual machine 235

6-1  IBM PowerVC Login window 238

6-2  Self-service portal home window. 239

6-3  Deploy Templates selection interface 239

6-4  Deploy template information 240

6-5  Deployment that is submitted and request that is created 241

6-6  Request details and information 241

6-7  Request details from the administrator’s home window view 242

6-8  Administrator’s approval submitted 243

6-9  Administrator user clean queue 243

A-1  SDN network components 251

A-2  SDN encapsulation 252

A-3  Ethernet packets before and after encapsulation 252

A-4  Multiple network nodes in an SDN network 253

A-5  Shows the virtual router that connects the green overlay network with the WAN 254

B-1  REST request to get the tenant-ids 274

B-2  API response example 274

B-3  Get volume ID attribute 275

B-4  Volume deletion status message 275

Tables

1-1  IBM PowerVC releases cross-referenced to OpenStack versions 8

2-1  Hardware and OS requirements 15

2-2  Minimum resource requirements for the IBM PowerVC VMs 15

2-3  Supported activation methods for managed hosts 16

2-4  HMC requirements 17

2-5  Supported virtualization platforms 17

2-6  Supported network hardware and software 18

2-7  Supported storage hardware for PowerVM 18

2-8  Supported storage hardware for PowerKVM. 19

2-9  Supported storage connectivity options 19

2-10  Supported security software 20

2-11  PowerVM NovaLink memory requirement for scaling 21

2-12  Processor compatibility modes 31

2-13  Preferred practices for Shared Ethernet Adapter 56

2-14  Required adapter models (feature codes) to use in SR-IOV deployments 58

2-15  IBM PowerVC security roles 62

3-1  RHEL packages that relate to IBM PowerVC 70

3-2  Options for the IBM PowerVC install command 72

3-3  IBM PowerVC Users 73

3-4  Available options for the powervc-uninstall command 76

3-5  Options for the powervc-backup command 82

3-6  Options for the powervc-restore command 84

3-7  IBM PowerVC available commands 86

3-8  Commands for IBM PowerVC Standard for managing PowerKVM 87

3-9  Options for the powervvc-audit-export command 88

4-1  Information section fields 139

4-2  Specifications section’s fields 140

4-3  Details section’s fields 143

4-4  Modules and descriptions 151

4-5  Description of the fields in the Information section 155

4-6  Description of the fields in the Specifications section 156

4-7  Host states during the transition 174

4-8  Role assignments 183

B-1  OpenStack API to remove a volume 275

Examples

3-1  Install prerequisites verification 71

3-2  Installation completed 73

3-3  The powervc-services command example 74

3-4  Uninstallation successful 75

3-5  Check the IBM PowerVC version from the command-line interface 77

3-6  IBM PowerVC upgrade to Version 1.3.2.0 78

3-7  Enable the IBM Cloud PowerVC Manager offering 80

3-8  Update successfully completed 81

3-9  Example of IBM PowerVC backup 83

3-10  Mismatch between backup and recovery environments 83

3-11  Example of IBM PowerVC recovery 84

3-12  The powervc-audit command use 87

3-13  IBM Installation Toolkit sample output 88

3-14  Resource Monitoring and Control status 89

4-1  The scratchpad.txt file 147

4-2  The scratchpad.txt file 148

4-3  Specific device names for the /etc/fstab file 148

4-4  The /etc/lilo.conf file 148

4-5  Specific devices names for the /etc/lilo.conf file 148

4-6  Add an admin user account with the useradd command 181

4-7  Update the admin user account with the usermod command 183

4-8  OpenStack API command line to set up roles to projects 184

4-9  Set a policy by using IBM PowerVC Cloud CLI 184

4-10  Set policies for a specific project for self-service users 186

4-11  Modify user to become part of the default powervc filter group 188

4-12  Create a group filter that is fed by existing users and groups 188

5-1  Import a Red Hat ISO image 206

5-2  ISO image location and naming in IBM PowerVC 209

5-3  virsh list --all output 215

5-4  Virtual console that shows Disc Found message 216

5-5  Symbolic links mapping 219

5-6  Sample device names before the change 220

5-7  Sample device names after the change 220

5-8  lilo.conf file before change 220

5-9  lilo.conf file after change 221

A-1  Security groups that are defined 248

A-2  Create a security group 249

A-3  Associate multiple security groups 250

A-4  Checking for correct ports 255

A-5  Property file example 256

B-1  Commands to access the IBM PowerVC GUI 258

B-2  Create and list a project 258

B-3  Create users and roles for access to a project 259

B-4  Change a role 259

B-5  Set the network domain 259

B-6  List an interface configuration 260

B-7  List an IP address 260

B-8  LIst a host name 260

B-9  List a token expiration 260

B-10  List a repository 261

B-11  Image subcommand 261

B-12  Storage subcommand 261

B-13  Compute subcommand 261

B-14  Current time to live value command 262

B-15  Data query to obtain the total number of volumes 263

B-16  Data query to obtain the total number of volumes and show up to 1000 entries 263

B-17  The inactivity_timeout command 263

B-18  The token_expiration_warning_time subcommand 263

B-19  Create an overlay network 264

B-20  Define a subnetwork for the private network 265

B-21  Define the external network 265

B-22  Create a subnetwork for the external network 266

B-23  Create a security group 268

B-24  Add rules to the security group 268

B-25  List by project, role, and user name 269

B-26  List by user name, project, and role 270

B-27  Token request from the command line 271

B-28  Tenant-id request from command line 272

Notices

This information was developed for products and services offered in the US. This material might be available from IBM in other languages. However, you may be required to own a copy of the product or product version in that language in order to access it.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user’s responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, MD-NC9, Armonk, NY 10504-1785, US

INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some jurisdictions do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Any references in this information to non-IBM websites are provided for convenience only and do not in any manner serve as an endorsement of those websites. The materials at those websites are not part of the materials for this IBM product and use of those websites is at your own risk.

IBM may use or distribute any of the information you provide in any way it believes appropriate without incurring any obligation to you.

The performance data and client examples cited are presented for illustrative purposes only. Actual performance results may vary depending on specific configurations and operating conditions.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

Statements regarding IBM’s future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only.

This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to actual people or business enterprises is entirely coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. The sample programs are provided “AS IS”, without warranty of any kind. IBM shall not be liable for any damages arising out of your use of the sample programs.

Trademarks

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the web at “Copyright and trademark information” at http://www.ibm.com/legal/copytrade.shtml

The following terms are trademarks or registered trademarks of International Business Machines Corporation, and might also be trademarks or registered trademarks in other countries.

Active Memory™

AIX®

DB2®

developerWorks®

DS8000®

FlashCopy®

IBM®

IBM FlashSystem®

POWER®

Power Systems™

POWER6®

POWER6+™

POWER7®

POWER7+™

POWER8®

PowerHA®

PowerLinux™

PowerVM®

Redbooks®

Redbooks (logo)®

Storwize®

System Storage®

Tivoli®

XIV®

The following terms are trademarks of other companies:

Linux is a trademark of Linus Torvalds in the United States, other countries, or both.

Microsoft, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Other company, product, or service names may be trademarks or service marks of others.

Preface

IBM® Power Virtualization Center (IBM® PowerVC™) is an advanced, enterprise virtualization management offering for IBM Power Systems™. This IBM Redbooks® publication introduces IBM PowerVC and helps you understand its functions, planning, installation, and setup.

IBM PowerVC Version 1.3.2 supports both large and small deployments, either by managing IBM PowerVM® that is controlled by the Hardware Management Console (HMC) by IBM PowerVM NovaLink, or by managing PowerKVM directly. With this capability, IBM PowerVC can manage IBM AIX®, IBM i, and Linux workloads that run on IBM POWER® hardware.

IBM PowerVC is available as a Standard Edition, or as a Cloud PowerVC Manager edition.

IBM PowerVC includes the following features and benefits:

•Virtual image capture, deployment, and management

•Policy-based virtual machine (VM) placement to improve use

•Management of real-time optimization and VM resilience to increase productivity

•VM Mobility with placement policies to reduce the burden on IT staff in a simple-to-install and easy-to-use graphical user interface (GUI)

•Role-based security policies to ensure a secure environment for common tasks

•The ability to enable an administrator to enable Dynamic Resource Optimization on a schedule

IBM Cloud PowerVC Manager includes all of the IBM PowerVC Standard Edition features and adds:

•A self-service portal that allows the provisioning of new VMs without direct system administrator intervention. There is an option for policy approvals for the requests that are received from the self-service portal.

•Pre-built deploy templates that are set up by the cloud administrator that simplify the deployment of VMs by the cloud user.

•Cloud management policies that simplify management of cloud deployments.

•Metering data that can be used for chargeback.

This publication is for experienced users of IBM PowerVM and other virtualization solutions who want to understand and implement the next generation of enterprise virtualization management for Power Systems.

Unless stated otherwise, the content of this publication refers to IBM PowerVC Version 1.3.2.

Authors

This book was produced by a team of specialists from around the world working at the International Technical Support Organization, Poughkeepsie Center.

Javier Bazan Lazcano is an IT Specialist at IBM Argentina. He has been with IBM since 2007 providing support and implementing solutions for North American accounts. He has more than 13 years of hands-on experience in working with UNIX and virtualization platforms. His areas of expertise include Power Systems, PowerVM, AIX, HMC, Linux Red Hat, VMWare, and HPUX.

Martin Parrella is a certified IT Specialist at IBM Argentina GTS. He has been with IBM since 2008 supporting local and international accounts, and has more than 10 years of experience working with different Linux/Unix platforms. He has a degree in Web Development from Universidad Nacional de la Matanza, and his areas of expertise are Power Systems, AIX,
IBM PowerHA®, and PowerVM.

The project that created this publication was managed by:
Scott Vetter, PMP

Thanks to the following people for their contributions to this project:

Dave Archer, Senthil Bakthavachalam, David Bennin, Luis Bolinches, Eric Brown, Kenneth Burger, Chun Shi Chang, Rich Conway, Joe Cropper, Rebecca Dimock, William Edmonds, Chris Bigson, Nigel Griffiths, Nicolas Guérin, Kyle Henderson, Philippe Hermes, Amy Hieter, Greg Hintermeister, Thierry Huche, Bhrugubanda Jayasankar, Liang Jiang, Kyle Johnson, Bobichan (Bobby) John, Monica O Joshi, Imranuddin W Kazi, Rishika Kedia, Sailaja Keshireddy, Yan Koyfman, Jay Kruemcke, Eric R Larese, Stephen Lutz, Bob McNamara, Samuel D. Matzek, Gerald McBrearty, Luvella McFadden, John R. Niemi, Geraint North, Minh Nguyen, Sujeet Pai, Atul Patel, Carl Pecinovsky Taylor Peoples, Antoni Pioli, Osvaldo Rodriguez, Jeremy Salsman, Douglas Sanchez, Edward Shvartsman, Anna Sortland, Brent Tang, Jeff Tenner, Andrew Thorstensen, Stephen Tremain, Ramesh Veeramala, Christine Wang, Stephen Whitted, Barry Williams, Michael Williams, Li Jun Zhu

Thanks to the authors of the previous editions of this book. The authors of the first and second edition, IBM PowerVC Version 1.2.0 and 1.2.1 Introduction and Configuration, which was published in October 2014, were Bruno Blanchard, Guillermo Corti, Sylvain Delabarre, Ho Jin Kim, Ondrej Plachy, Marcos Quezada, and Gustavo Santos. The authors of the third edition, IBM PowerVC Version 1.2.3 Introduction and Configuration, which was published in October 2015, were Marco Barboni, Guillermo Corti, Benoit Creau, and Liang Hou Xu.

Now you can become a published author, too!

Here’s an opportunity to spotlight your skills, grow your career, and become a published author—all at the same time! Join an ITSO residency project and help write a book in your area of expertise, while honing your experience using leading-edge technologies. Your efforts will help to increase product acceptance and customer satisfaction, as you expand your network of technical contacts and relationships. Residencies run from two to six weeks in length, and you can participate either in person or as a remote resident working from your home base.

Find out more about the residency program, browse the residency index, and apply online at:

ibm.com/redbooks/residencies.html

Comments welcome

Your comments are important to us!

We want our books to be as helpful as possible. Send us your comments about this book or other IBM Redbooks publications in one of the following ways:

•Use the online Contact us review Redbooks form found at:

ibm.com/redbooks

•Send your comments in an email to:

redbooks@us.ibm.com

•Mail your comments to:

IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400

Stay connected to IBM Redbooks

•Find us on Facebook:

http://www.facebook.com/IBMRedbooks

•Follow us on Twitter:

http://twitter.com/ibmredbooks

•Look for us on LinkedIn:

http://www.linkedin.com/groups?home=&gid=2130806

•Explore new Redbooks publications, residencies, and workshops with the IBM Redbooks weekly newsletter:

https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm

•Stay current on recent Redbooks publications with RSS Feeds:

http://www.redbooks.ibm.com/rss.html

Summary of changes

This section describes the technical changes that are made in this edition of the book and in previous editions. This edition might also include minor corrections and editorial changes that are not identified.

Summary of Changes
for SG24-8199-04
for IBM PowerVC Version 1.3.2 Introduction and Configuration
as created or updated on June 12, 2017.

January 2017, Fifth Edition

This revision includes the following new and changed information.

New information

•IBM Cloud PowerVC Manager content added to introductions, installation, and management sections (see Chapter 6, “IBM Cloud PowerVC Manager” on page 237)

•New screen captures throughout to reflect latest IBM Power Virtualization Center
(IBM PowerVC) graphical user interface (GUI)

•Enhancements to IBM PowerVC reflecting Version 1.3.2 (see 1.3, “PowerVC versions and releases” on page 8)

•Added introduction and usage sections for the new SR-IOV features (see 2.7.4, “Planning Single Root I/O Virtualization networks” on page 56 and 4.12.2, “SR-IOV network setup” on page 126)

•Added overall information and appendix for the Software-Defined Networking (SDN) Technical Preview (see Appendix A, “Software-Defined Networking (technical preview)” on page 245)

•Instructions about how to use the new Dynamic Resource Optimizer (DRO) features (see 4.5.2, “Host Groups” on page 104)

•New appendix section created showing how to use the metering and API tools (see Appendix B, “Useful commands and scripts” on page 257)

Changed information

•General updates to content to increase clarity of the information

•Updated several sections to reflect current hardware and software requirement for PowerVC and related components

•Chapter 2 content was added into Chapter 1

•Removed the lab chapter

IBM PowerVC introduction

IBM Power Virtualization Center (IBM PowerVC) is an advanced virtualization and cloud management offering for Power Systems servers based on OpenStack technology. This comprehensive virtualization and cloud management offering is simple to install and use, and enables virtual machine (VM) setup and management. IBM PowerVC simplifies the management of the virtualization for Power Systems servers that run on IBM AIX, IBM i, and Linux operating systems.

IBM PowerVC Version 1.3.2 provides many new functional enhancements that add support for LDAP products and storage-related hardware. Also available is the IBM Cloud PowerVC Manager for private cloud deployments, which includes all the functions of the IBM PowerVC Standard Edition plus new features that are described in this publication.

This book provides introductory and configuration information for IBM PowerVC. After it presents an overview of IBM PowerVC in this chapter, it covers the following topics in subsequent chapters:

•Release reviews in 1.3, “PowerVC versions and releases” on page 8.

•Planning information in Chapter 2, “IBM PowerVC planning” on page 13.

•Guidelines in Chapter 3, “IBM PowerVC installation” on page 67.

•General configuration and setup that are common to all variants of IBM PowerVC in Chapter 4, “IBM PowerVC for managing IBM PowerVM” on page 91.

•Information that is specific to using IBM PowerVC Standard for managing PowerKVM in Chapter 5, “IBM PowerVC Standard Edition for managing IBM PowerKVM” on page 189.

•The self-service portal is described in Chapter 6, “IBM Cloud PowerVC Manager” on page 237.

This publication also includes an interesting overview about IBM PowerVM NovaLink and its interaction with IBM PowerVC. This chapter covers the following topics:

•1.1, “IBM PowerVC overview” on page 2

•1.2, “IBM PowerVC Editions” on page 7

•1.3, “PowerVC versions and releases” on page 8

•1.4, “IBM PowerVC adoption” on page 11

1.1 IBM PowerVC overview

This publication is for system administrators who are familiar with the concepts that are included in these IBM Redbooks publications:

•IBM PowerVM Virtualization Introduction and Configuration, SG24-7940

•IBM PowerVM Virtualization Managing and Monitoring, SG24-7590

IBM PowerVC Virtualization Center is an advanced virtualization and cloud management offering, which is built on OpenStack, that provides simplified virtualization management and cloud deployments for IBM AIX, IBM i, and Linux VMs running on IBM Power Systems. PowerVC is designed to improve administrator productivity and simplify the cloud management of VMs on Power Systems servers. With PowerVC, you can:

•Create VMs and resize the VMs CPU and memory.

•Attach disk volumes to those VMs.

•Import existing VMs and volumes so that they can be managed by IBM PowerVC.

•Monitor the use of resources in your environment.

•Migrate VMs while they are running (live migration between physical servers).

•Improve resource usage to reduce capital expense and power consumption.

•Increase agility and execution to respond quickly to changing business requirements.

•Increase IT productivity and responsiveness.

•Simplify Power Systems virtualization management.

•Accelerate repeatable, error-free virtualization deployments.

IBM PowerVC can manage AIX, Linux, and IBM i VMs running under PowerVM virtualization and Linux VMs running under PowerKVM virtualization. This release supports the enterprise Power Systems servers that are built on IBM POWER7® and IBM POWER8® technologies.

1.1.1 IBM PowerVC functions and advantages

Why IBM PowerVC? Why do you need another virtualization management offering? When more than 70% of IT budgets is spent on operations and maintenance, IT clients legitimately expect vendors to focus their new development efforts to reduce this cost and foster innovation within IT departments.

IBM PowerVC gives IBM Power Systems clients the following advantages:

•It is deeply integrated with Power Systems.

•It provides virtualization management tools.

•It eases the integration of servers that are managed by PowerVM or PowerKVM in automated IT environments, such as clouds.

•It is a building block of IBM Infrastructure as a Service (IaaS), based on Power Systems.

IBM PowerVC is an addition to the existing PowerVM set of enterprise virtualization technologies that provide virtualization management. It is based on open standards and integrates server management with storage and network management.

Because IBM PowerVC is based on the OpenStack initiative, Power Systems can be managed by tools that are compatible with OpenStack standards. When a system is controlled by IBM PowerVC, it can be managed in one of three ways:

•By a system administrator by that uses the IBM PowerVC graphical user interface (GUI)

•By a system administrator that uses scripts containing the IBM PowerVC Representational State Transfer (REST) application programming interfaces (APIs)

•By higher-level tools that call IBM PowerVC by using standard OpenStack API

The PowerVC offerings are positioned within the available solutions for Power Systems cloud as follows:

•IBM PowerVC Standard Edition: Advanced Virtualization Management

•IBM Cloud PowerVC Manager: Basic Cloud

•IBM Cloud Orchestrator: Advanced Cloud

•VMware Vrealize: Advanced Cloud

It provides a systems management product that enterprise clients require to manage effectively the advanced features that are offered by IBM premium hardware and OpenPower based hardware. It reduces resource use and manages workloads for performance and availability.

1.1.2 IBM PowerVM NovaLink overview

PowerVM NovaLink is a new virtualization management paradigm for PowerVM systems and allows for dramatic scale improvements for PowerVM based IBM PowerVC environments. For more information about PowerVM NovaLink and its benefits, see IBM developerWorks®:

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Power%20Systems/page/Introducing%20PowerVM%20NovaLink

Leveraging the PowerVM NovaLink architecture, IBM PowerVC can significantly increase its scaling for PowerVM based systems. In an existing HMC-managed environment,
IBM PowerVC can manage up to 30 hosts and up to 3000 VMs. In a PowerVM NovaLink based environment, IBM PowerVC can manage up to 200 hosts and 5000 VMs. You can use
IBM PowerVC to manage your new PowerVM NovaLink systems while still managing your HMC managed systems.

PowerVM NovaLink architecture

PowerVM NovaLink enables highly scalable modern cloud management and deployment for critical enterprise workloads by using a proven PowerVM infrastructure and OpenStack technology. The PowerVM Hypervisor and Virtual I/O Server (VIOS) provide an infrastructure that is second to none in running enterprise workloads. These items, combined with POWER8 hardware, provide an excellent base on which to build a cloud. However, you cannot operate a cloud without great management tools, which is where IBM PowerVC comes into play. This OpenStack-based management offering integrates with PowerVM NovaLink to deliver a PowerVM cloud that is truly scalable, efficient, and simple to manage.

The PowerVM NovaLink architecture changes the virtualization management point for IBM PowerVC. With PowerVM NovaLink, a thin “management” VM exists on the system. You can see the thin PowerVM NovaLink partition in Figure 1-1, which is denoted as NVL.

Figure 1-1 PowerVM NovaLink partition

Figure 1-1 shows that the architecture between IBM PowerVC and a PowerVM system is dramatically simplified. The Nova compute processes now run directly on the PowerVM NovaLink thin VM so that the IBM PowerVC can dramatically scale out the number of hosts that it can manage by using this one-to-one link. It also reduces the load on an administrator’s HMC, allowing the hosts to connect significantly more systems to a given HMC than they would otherwise.

Also, the PowerVM NovaLink code is tuned directly for IBM PowerVC and OpenStack use. This increased efficiency allows IBM PowerVC to scale a single system to 1,000 VMs, double the current 500 VMs per system limitation that exists today. More important, it is aligned with the capabilities of the PowerVM platform itself.

PowerVM NovaLink user experience

The integration of PowerVM NovaLink provides a unified PowerVM experience. Whether you choose to have IBM PowerVC managed through PowerVM NovaLink (to take advantage of the scale and speed) or by using the traditional HMC path, IBM PowerVC provides you with a consistent experience.

As shown, the experience within the interface is similar. In Figure 1-2, the home window looks identical, although IBM PowerVC is managing PowerVM NovaLink systems. However, note the dramatic increase in hosts.

Figure 1-2 IBM PowerVC interface

There are some areas where changes are evident in the user interface. The most obvious one is the Host Registration window. Although host registration for an HMC managed system remains unchanged, there is a new path for PowerVM NovaLink host registration. Administrators provide the IP address and credentials of the PowerVM NovaLink VM, which IBM PowerVC uses to register the system. This window is similar to the window that is used for PowerKVM system registration. Figure 1-3 shows the Host Registration window.

Figure 1-3 Host Registration window

Beyond this item, few other differences exist. The Host window does not show through which HMC the IBM PowerVC is managing (because it manages through PowerVM NovaLink).

In addition, to ensure a unified experience, a single IBM PowerVC can mix the management types, which means that a single IBM PowerVC can manage some systems through an HMC and others through PowerVM NovaLink.

Figure 1-4 shows the PowerVM NovaLink diagrams.

Figure 1-4 PowerVM NovaLink diagrams

As shown, the same HMC can be used for IBM PowerVC traditional management, or PowerVM NovaLink management. However, if a system has PowerVM NovaLink installed, IBM PowerVC must be pointed to the PowerVM NovaLink on the system. This mixed mode provides a good path for existing customers that want to start taking advantage of PowerVM NovaLink without too much disruption.

Key prerequisites

For IBM PowerVC, the key prerequisites are as follows:

•IBM PowerVM Standard Edition (5765-PVS) for basic functions, and IBM PowerVM Enterprise Edition (5765-PVE) or IBM PowerVM PowerLinux™ Edition (5765-PVL) for full function or IBM PowerKVM (5765-KVM).

•Firmware V8.2, or higher, is required for the new Remote Restart function for IBM PowerVM that is managed by IBM PowerVC.

For IBM PowerVM, the key prerequisites are as follows:

•Any IBM system that includes an IBM POWER7, POWER7+™, or POWER8 processor.

•PowerVM NovaLink requires systems with a POWER8 processor and Firmware 840, or later, that is not managed by an HMC.

PowerVM NovaLink provides significant advantages for PowerVM users who want to scale up their environments. It is highly concurrent and highly scalable, and can reduce infrastructure complexity. Concurrently, the existing IBM PowerVC experience is preserved, enabling administrators to take advantage of these benefits quickly.

1.2 IBM PowerVC Editions

IBM offers two different editions for this product:

•IBM PowerVC Standard Edition

•IBM Cloud PowerVC Manager

1.2.1 IBM PowerVC Standard Edition

IBM PowerVC Standard Edition manages PowerVM systems that run either IBM POWER6®, POWER7, or POWER8 processors that are controlled by an HMC. In addition, IBM PowerVC can manage PowerKVM Linux scale-out servers.

During installation, IBM PowerVC Standard Edition can be configured to manage VMs that are virtualized on top of either PowerVM or PowerKVM.

On PowerVM, dual VIOSs for each host are supported to access storage and the network. VMs can be either N_Port ID Virtualization (NPIV)-attached storage or shared storage pool (SSP) back-end storage and virtual SCSI (vSCSI), which were introduced in IBM PowerVC V1.2.2. The following hardware products are supported for NPIV:

•EMC (VNX and VMAX)

•Hitachi storage (VSP G1000, VSP G series, VSP)

•IBM XIV® Storage System

•IBM Storwize® family

•IBM FlashSystem® A9000

•IBM SAN Volume Controller

•IBM System Storage® DS8000®

For storage on an SSP, any VIOS-supported storage area network (SAN) storage devices are supported by the SSP and supported by IBM PowerVC.

For more information, see 2.1, “IBM PowerVC requirements” on page 14.

For the latest list of requirements, see the following website:

https://www.ibm.com/support/knowledgecenter/en/SSXK2N_1.3.2/com.ibm.powervc.standard.help.doc/powervc_hwandsw_reqs_hmc.html

1.2.2 IBM Cloud PowerVC Manager

IBM Cloud PowerVC Manager has all the functions of IBM PowerVC Standard plus the new self-service portal functions in the familiar IBM PowerVC user interface.

A key component of the new cloud self-service portal is the deploy template. Deploy templates allow a cloud administrator to determine a set of fixed VM options that the self-service users can select to deploy repeatedly to a VM with just a few clicks.

These templates include all the deployment details, such as the target host, storage template, and storage connectivity group, so that users do not need to worry about any of that (and administrators do not need to worry about VMs being created with incorrect settings).

The Cloud administrator can create a project to group resources and to allow access only by users who need it.

IBM Cloud PowerVC Manager also gives administrators the ability to set policies on projects. These policies specify what self-service users can do without additional approval and what actions require administrator approval. When a self-service user tries to perform an action that requires administrator approval, such as extending the expiration date of a VM, a request is created. If the administrator approves that request, then the action completes.

1.3 PowerVC versions and releases

This section describes the updates that have been introduced since IBM Power Virtualization Center (IBM PowerVC) Version 1.3.0, with special focus on Version 1.3.2.

1.3.1 IBM PowerVC release to OpenStack edition cross-reference

Table 1-1 cross-references the IBM PowerVC releases to editions of OpenStack.

Table 1-1 IBM PowerVC releases cross-referenced to OpenStack versions

IBM PowerVC release

PowerVC announcement

OpenStack edition

V1.3.0

October 2015

Liberty

V1.3.1

April 2016

Mitaka

V1.3.2

October 2016

Newton

1.3.2 IBM PowerVC Version 1.3.0

IBM PowerVC Version 1.3.0, available in December 2015, introduces a long list of enhancements and new features:

•Dynamic Resource Optimizer (DRO)

•IBM PowerVM NovaLink support

•Enhanced fabric management through storage connectivity groups

•Manage up to 25 fabrics

•IBM System Storage DS8000 support

•Manage up to 5000 VMs

•New supported guest operating systems

•Functional enhancements

1.3.3 IBM PowerVC Version 1.3.1

IBM PowerVC Version 1.3.1, available in June 2016, bring several key additions to the PowerVC experience:

•IBM Cloud PowerVC Manager

•Self-service portal

•Access roles

•Viewing usage information (metering data)

•IBM Cloud PowerVC Manager capabilities

•DRO enhancement

•Improved lifecycle control of data volumes

•Expanded PowerVM NovaLink support

•Projects

1.3.4 IBM PowerVC Version 1.3.2

The new version of IBM Power Virtualization Center Version 1.3.2 provides many new features and enhancements.

Additional LDAP servers

IBM Tivoli® Directory Server V6.3 and its replacements, IBM Security Directory Server and IBM Security Directory Suite, are now supported. For more information, see 4.16.6, “Lightweight Directory Access Protocol” on page 187.

Virtual machines with vSCSI connections to Hitachi volumes

Existing VMs with vSCSI volume connections to the Hitachi array are now supported for management in IBM PowerVC. HDS storage now supports NPIV.

Software-defined networking (technical preview)

Software-defined networking (SDN) virtualizes your network in a similar way that compute resources are virtualized. It allows you to change VM communication without changing your physical network. IBM PowerVC supports SDN on PowerVM NovaLink managed systems when IBM PowerVC is installed in Technical Preview mode. For more information, see Appendix A, “Software-Defined Networking (technical preview)” on page 245.

Single Root I/O Virtualization support

IBM PowerVC supports Single Root I/O Virtualization (SR-IOV) network interface connectivity for VMs with NovaLink managed hosts. This support includes the ability to set the Virtual network interface card (NIC) capacity, which is the first quality of service (QoS) setting that is available for IBM PowerVC. However, this support does not yet include Live Partition Mobility and remote restart functions for SR-IOV backed networks at the time of writing. For more information, see 2.7.4, “Planning Single Root I/O Virtualization networks” on page 56 and 4.12.2, “SR-IOV network setup” on page 126.

Virtual console

IBM PowerVC supports access to a virtual console for NovaLink-managed VMs. To access a virtual console for your VM, go to the Virtual Machine Details page and select the Console tab to start a VNC session. For more information, see 4.15.5, “Opening a console window” on page 145.

Consistency group API support on additional storage devices

The Cinder consistency group and consistency group snapshot APIs are supported on EMC VMAX, EMC VNX, Hitachi Data Systems, and IBM DS8000 storage devices. For more information, see “REST APIs example” on page 271.

Note: The create_from_src API is not supported on EMC VMAX storage devices.

Snapshot support on additional storage devices

The Cinder snapshot APIs are supported on EMC VMAX, EMC VNX, Hitachi Data Systems, IBM DS8000, and IBM XIV storage devices.

Host memory rebalancing

IBM PowerVC DRO rebalances overburdened hosts by reducing the host's memory utilization for NovaLink-managed VMs. For more information, see 4.5.2, “Host Groups” on page 104.

Automated remote restart

Automated remote restart monitors hosts for failure by using the Platform Resource Scheduler (PRS) HA service. If a host fails, IBM PowerVC automatically remote restarts the VMs from the failed host to another host within a host group.

Shared storage pool provider support on NovaLink

IBM PowerVC can use the NovaLink shared storage pool management capability in these new ways:

•To automatically discover and use shared storage pool storage providers through NovaLink cluster members

•To support volume connectivity from shared storage pools to VMs that are hosted by NovaLink partitions

Initiator zoning

Initiator zoning is a mode of Fibre Channel (FC) zoning. With initiator zoning, a zone is created for each initiator and includes all of the controller targets that are supplied by the volume driver in the initiator target map. This results in fewer zones being created. You can choose whether to use initiator target zoning or initiator zoning when registering a fabric through the user interface or the Register a SAN fabric or switch API.

User and group filtering

You now control which users and groups are visible to IBM PowerVC when using the local operating system as the identity repository. Previously, user and group filtering was available only when using LDAP. For more information, see 4.16.7, “User and Group filtering” on page 187.

Injecting an SSH key

When deploying a VM from IBM PowerVC, you can inject an SSH public key into the deployed VM. Users can then use the corresponding private key to connect to the deployed VM.

Replacing messaging certificates

You can now replace the certificates that are used to secure the Advanced Message Queuing Protocol (AMQP). This task is useful if you believe that a certificate is compromised or if you need to change a property.

Dependency prerequisite check

The prerequisite checks are enhanced to check for any packages that are not installed or available through any yum repositories. Running the installation with the -t option displays any missing packages along with any other failed prerequisite checks.

API and CLI command updates

A new API called host-sriov is added to configure SR-IOV adapters during deployment.

A new command is added into the CLI that is called powervc-services, which allows you to control services for NovaLink managed hosts.

1.4 IBM PowerVC adoption

Two features are useful for a smooth adoption of IBM PowerVC in an existing environment:

•When IBM PowerVC manages a physical server, it can manage the full set or only a subset of the partitions that are hosted on that server.

•When IBM PowerVC is adopted in an environment where partitions are already in production, IBM PowerVC can discover the existing partitions and selectively start to manage them.

Therefore, the adoption of IBM PowerVC in an existing environment does not require a major change. It can be a smooth transition that is planned over several days or more.

IBM PowerVC provides a way to check a system to ensure all the prerequisites are met before an installation by running a script. For more information, see 3.2, “Installing IBM PowerVC” on page 71.

IBM PowerVC planning

This chapter describes the key aspects of IBM® Power Virtualization Center (IBM PowerVC) installation planning:

•Section 2.1, “IBM PowerVC requirements” on page 14 presents the hardware and software requirements for the various components of an IBM PowerVC environment: management station, managed hosts, network, storage area network (SAN), and storage devices.

•Sections 2.3, “Host and partition management planning” on page 22 through 2.10, “Product information” on page 65 provide detailed planning information for various aspects of the environment’s setup:

 – Hosts

 – Partitions

 – Placement policies

 – Templates

 – Storage and SAN

 – Storage connectivity groups and tags

 – Networks

 – User and group

 – Security

It covers the following topics:

•2.1, “IBM PowerVC requirements” on page 14

•2.2, “IBM PowerVM NovaLink requirements” on page 20

•2.3, “Host and partition management planning” on page 22

•2.4, “Placement policies and templates” on page 25

•2.5, “IBM PowerVC storage access SAN planning” on page 35

•2.6, “Storage management planning” on page 40

•2.7, “Network management planning” on page 52

•2.8, “Planning users and groups” on page 60

•2.9, “Security management planning” on page 63

•2.10, “Product information” on page 65

2.1 IBM PowerVC requirements

This section describes the necessary software and hardware components to implement
IBM PowerVC to manage AIX, IBM i, and Linux platforms.

IBM Cloud PowerVC Manager continues to be included along with IBM PowerVC Standard in the IBM PowerVC 1.3.2 installation media. For information about available releases, see this website:

http://www.ibm.com/software/support/lifecycle/

IBM Cloud PowerVC Manager provides a self-service portal that allows for the provisioning of new virtual machines (VMs) in a PowerVM-based private cloud without direct system administrator intervention.

2.1.1 Hardware and software requirements

The following sections describe the hardware, software, and minimum resource requirements at the time of writing for Version 1.3.2 of IBM Cloud PowerVC Manager and IBM PowerVC Standard Edition. For the complete requirements, see IBM Knowledge Center:

•IBM Cloud PowerVC Manager:

http://www.ibm.com/support/knowledgecenter/SSXK2N_1.3.2/com.ibm.powervc.standard.help.doc/powervc_planning_hmc.html

Click IBM Cloud PowerVC Manager 1.3.2 → Planning.

•IBM PowerVC managing PowerVM:

http://www.ibm.com/support/knowledgecenter/SSXK2N_1.3.2/com.ibm.powervc.standard.help.doc/powervc_planning_hmc.html

Click IBM PowerVC Standard Edition 1.3.2 → Managing PowerVM → Planning for IBM PowerVC standard Managing PowerVM.

• IBM PowerVC managing PowerKVM:

http://www.ibm.com/support/knowledgecenter/SSXK2N_1.3.2/com.ibm.powervc.standard.help.doc/powervc_planning_hmc.html

Click IBM PowerVC Standard Edition 1.3.2 → Managing PowerKVM → Planning for IBM Virtualization Center.

2.1.2 Hardware and software requirements for IBM PowerVC

The following information provides a consolidated view of the hardware and software requirements for both IBM PowerVC Standard Edition and IBM Cloud PowerVC Manager.

IBM PowerVC management and managed hosts

The IBM PowerVC architecture supports a single management host for each managed domain. It is not possible to configure redundant IBM PowerVC management hosts that control the same objects.

The VM that hosts the IBM PowerVC management host must be dedicated to this function. No other software or application can be installed on this VM. However, you can install software for the management of this VM, such as monitoring agents and data collection tools for audit or security. Table 2-1 lists the IBM PowerVC Standard Edition hardware and software requirements.

Table 2-1 Hardware and OS requirements

Host type

Supported hardware

Supported operating systems

IBM PowerVC management server

IBM POWER6, POWER7, POWER7+, or POWER8 processor-based server models, or any x86_64 server meeting the recommended CPU, memory, and requirements

Red Hat Enterprise Linux (RHEL) Version 7.1 or later for IBM Power ppc64be (Big Endian) and ppc64le (Little Endian)

Red Hat Enterprise linux (RHEL) Version 7.1 or later for x86_64

Managed hosts

PowerVM:

IBM Power processor-based servers:

IBM POWER6, POWER7, POWER7+, and POWER8 servers

PowerKVM:

POWER8 servers with IBM PowerKVM V2.1.1.2 or later

See Table 2-3 on page 16.

Note: The management server should have a minimum of four cores and 8 GB of memory.

Table 2-2 describes the minimum and recommended resources that are required for IBM PowerVC VMs. In the table, the meaning of the processor capacity row depends on the type of host that is used as the IBM PowerVC management host:

•If the IBM PowerVC management host is PowerVM, processor capacity refers to either the number of processor units of entitled capacity or the number of dedicated processors.

•If the IBM PowerVC management host is PowerKVM or x86, processor capacity refers to the number of physical cores.

Table 2-2 Minimum resource requirements for the IBM PowerVC VMs

Item

Minimum

Preferred

Number of VMs

Up to 100

Up to 400

401 - 1000

1001 - 2000

2001 - 3000

3001-5000

Processor capacity

1

2

4

8

8

12

Virtual CPUs

2

2

4

8

8

12

Memory (GB)

10

10

12

20

28

44

Swap space (GB)

10

10

12

20

28

44

Disk space (GB)

40

43

60

80

100

140

The installer has the following space requirements:

•/tmp: 250 MB.

•/usr: 250 MB.

•/opt: 2.5 GB.

•/home: 3 GB (minimum). As a preferred practice, assign 20% of the space to /home. For example, for 400 VMs, 8 GB are preferable. For 1,000 VMs, 20 GB are preferable. For 2,000 VMs, 30 GB are preferable.

•/var: 40 GB.

•The remaining space is used for swap space.

Supported activation methods

Table 2-3 lists the supported activation methods for VMs on managed hosts.

Virtual Solutions Activation Engine (VSAE) is deprecated, and it might be withdrawn from support in subsequent releases. As a preferred practice, construct images with cloud-init, which is the strategic image activation technology of IBM. It offers a rich set of system initialization features and a high degree of interoperability.

Table 2-3 Supported activation methods for managed hosts

Operating system

Little Endian (LE) or Big Endian (BE)

Version

Initialization

AIX

BE

6.1 TL0 SP0 or later
7.1 TL0 SP0 or later

7.2 TL0 SP0 or later
Note: AIX 5.3 is not supported.

cloud-init

IBM i

BE

7.1 TR8 or later
7.2 TR1 or later
7.3 or later

cloud-init
IBM i AE (deprecated)

RHEL

BE

6.4 or later

7.1 or later

cloud-init¹

RHEL

LE

7.1 or later

cloud-init

SUSE Linux Enterprise Server

BE

11 SP3 or later

cloud-inita

SUSE Linux Enterprise Server

LE

12 SP0 or later

cloud-init

Ubuntu

LE

14.04.1 or later

16.04.1 or later

cloud-init

¹ VSAE is no longer available for these releases.

Hardware Management Console

Table 2-4 shows the Hardware Management Console (HMC) version and release requirements to support IBM PowerVC managing PowerVM. This section does not apply for managing systems that are controlled by PowerKVM.

Table 2-4 HMC requirements

Item

Requirement

Software level

•HMC: 8.5.0, 8.6.0 or 8.7

•vHMC: 8.5.0, 8.6.0 or 8.7

Hardware-level requirements

Requirements:

•Up to 300 VMs: CR5 with 4 GB memory

•More than 300 VMs: CR6, CR7, or CR8 with 8 GB memory

Recommendations:

•Up to 300 VMs: CR6, CR7, or CR8 with 8 GB memory

•More than 300 VMs: CR6, CR7, or CR8 with 16 GB memory

As a preferred practice, update to the latest HMC fix pack for the specific HMC release. You can check the fixes for HMC by using the IBM Fix Level Recommendation Tool: at the following website:

https://www.software.ibm.com/webapp/set2/flrt/home

You can get the latest fix packages from IBM Fix Central at the following website:

http://www.ibm.com/support/fixcentral/

Virtualization platform

Table 2-5 includes the Virtual I/O Server (VIOS) version requirements for IBM PowerVC managing PowerVM.

Table 2-5 Supported virtualization platforms

Platform

Supported versions

VIOS for POWER8 hosts and earlier

Version 2.2.4.22 or later

Version 2.2.5.0 or later

Tip: Set the Maximum Virtual Adapters value to at least 200 on the VIOS because
IBM PowerVC gives you warning messages below 200. However, VIOSs that are managed by IBM PowerVC can serve more than 100 VMs, and each VM can require four or more virtual I/O devices from the VIOS. When you plan the VIOS configuration, base the size of the Maximum Virtual Adapters value on real workload requirements.

Note: The version of RSCT (Remote Management and Control) that is installed on the VIOS should have the latest fix.

Network resources

Table 2-6 lists the network infrastructure that is supported by IBM PowerVC.

Table 2-6 Supported network hardware and software

Item

Requirement

Network switches

IBM PowerVC does not manage network switches, but it supports network configurations that use virtual LAN (VLAN)-capable switches.

Virtual networks

•PowerVM: Shared Ethernet adapters (SEAs) for VM networking.

•PowerKVM: Supports Open vSwitch (OVS) 2.0. The backing adapters for the virtual switch can be physical Ethernet adapters, bonded adapters (OVS also supports bonding), or Linux bridges (not preferred).

•Supports SR-IOV based vNICs (NovaLink only).

•When using the software-defined networking (SDN) technical preview, flat, VLAN, or Virtual Extensible LAN (VXLAN) overlays are supported.

Storage providers

Table 2-7 lists the hardware that is supported by IBM PowerVC.

Table 2-7 Supported storage hardware for PowerVM

Item

Requirement

Storage systems

•IBM Storwize family of controllers.

•IBM Flash System 9000.

•IBM SAN Volume Controller.

•IBM XIV Storage System.

•DS8000 7.5.0 and 8.0.0.

•Hitachi VSP, VSP G1000, VSP G Series (G200, G400, G600, and 800).

•EMC VNX Series is supported on RHEL Server for x86_64 management hosts only due to EMC limitations.

•EMC VMAX.

SAN switches

•Brocade Fibre Channel (FC) switches are supported by the Brocade OpenStack Cinder zone manager driver.

•Cisco SAN FC switches are supported by the Cisco Cinder zone manager driver.

Storage connectivity

•FC attachment through at least one N_Port ID Virtualization (NPIV)-capable host bus adapter (HBA) on each host.

•Virtual SCSI (vSCSI).

•Shared Storage Pools.

Note:

•IBM i hosts on IBM XIV Storage Systems must be attached by vSCSI due to IBM i and IBM XIV storage limitations.

•IBM i hosts on EMC VNX and VMAX storage systems must be attached by vSCSI due to IBM i and EMC storage limitations.

Storage Drivers

Some storage drivers support different devices depending on the OpenStack release. PowerVC Version 1.3.2 supports the OpenStack Newton release. For extended information and guidelines on storage drivers, go to the following website:

http://docs.openstack.org/newton/config-reference/block-storage/volume-drivers.html

Table 2-8 lists the hardware that is supported by IBM PowerVC Standard Edition managing PowerKVM.

Table 2-8 Supported storage hardware for PowerKVM.

Item

Use

Requirement

Storage systems

Boot volumes

File-level storage.

Network File System (NFS) V3 or V4 is required for migration. It must be manually configured on the kernel-based VM (KVM) host before it is registered on IBM PowerVC.

Data volumes

IBM Storwize family and SVC controllers only.

Storage connectivity

Boot volumes

Local NFS.

Data volumes

Internet Small Computer System Interface (iSCSI).

Supported storage connectivity options

Table 2-9 shows the supported storage connectivity options.

Table 2-9 Supported storage connectivity options

Boot volume /

Data volume

Shared storage pool

NPIV

vSCSI

Shared storage pool (SSP)

X

X

NPIV

X

vSCSI

X

X

Note: Both NPIV and vSCSI data volumes are supported for a VM with a vSCSI boot volume, but because storage connectivity groups support only one type of connectivity, if you have a vSCSI boot volume, you can have either NPIV or vSCSI data volumes, but not both.

Security

Table 2-10 includes the supported security features.

Table 2-10 Supported security software

Item

Requirement

Lightweight Directory Access Protocol (LDAP) server (optional)

•OpenLDAP version 2.0 or later

•Microsoft Active Directory 2003 or later

•IBM Tivoli Directory Server 6.3

•IBM Security Directory Server

•IBM Security Directory Suite

2.1.3 Other hardware compatibility

IBM PowerVC is based on OpenStack, so rather than being compatible with specific hardware devices, IBM PowerVC is compatible with drivers that conform to OpenStack standards. They are called pluggable devices in IBM PowerVC. Therefore, IBM PowerVC can take advantage of hardware devices that are available from vendors that provide OpenStack-compatible drivers for their products. IBM cannot state the support of other hardware vendors for their specific devices and drivers that are supported by IBM PowerVC, so check with the vendors to learn about their drivers. For more information about pluggable devices, see IBM Knowledge Center:

http://www.ibm.com/support/knowledgecenter/SSXK2N_1.3.2/com.ibm.powervc.standard.help.doc/powervc_planning_storage_hmc.html

2.1.4 Web browsers

IBM PowerVC works on many web browsers:

•Mozilla Firefox ESR 38 and 45

IBM PowerVC does not load if Ask me every time is selected as the custom history setting.

•Google Chrome, Version 50 or later

IBM PowerVC does not load if Block all cookies is selected.

•Microsoft Internet Explorer, Version 11.0

2.2 IBM PowerVM NovaLink requirements

PowerVM NovaLink is a software interface that is used for virtualization management. You can install PowerVM NovaLink on a PowerVM server. PowerVM NovaLink enables highly scalable modern cloud management and deployment of critical enterprise workloads. You can use PowerVM NovaLink to provision large numbers of VMs on PowerVM servers quickly and at a reduced cost.

2.2.1 PowerVM NovaLink system requirements

For successful operation, PowerVM NovaLink requires hardware and software to meet specific criteria.

POWER8 server requirements

PowerVM NovaLink can be installed only on POWER8 processor-based servers with firmware level FW840 or later. If the server does not have firmware level FW840 or later, you must update the server firmware before installing PowerVM NovaLink.

PowerVM NovaLink partition requirements

PowerVM NovaLink requires its own partition on the managed system. The PowerVM NovaLink partition requires the following system resources:

•0.5 shared processors that are uncapped with a non-zero weight and two virtual processors.

•4.5 GB of memory, which you can adjust to 2.5 GB after installation. See Table 2-11 for the memory requirements for scaling VMs.

•At least 30 GB of storage.

•A virtualized network that is bridged through the SEA.

•Maximum virtual slots that are set to 200 or higher.

Table 2-11 PowerVM NovaLink memory requirement for scaling

Number of VMs

Up to 250

251 - 500

More than 500

Memory need (GB)

2.5

5

10

If you install the PowerVM NovaLink environment on a new managed system, the PowerVM NovaLink installer creates the PowerVM NovaLink partition automatically. When the PowerVM NovaLink installer creates the PowerVM NovaLink partition on a new managed system, the PowerVM NovaLink installer always uses storage that is virtualized from the VIOS. You can set the installer to use either physical volume vSCSI or logical volumes for the PowerVM NovaLink partition. If you set the PowerVM NovaLink installer to use I/O redundancy, the storage for the PowerVM NovaLink partition is automatically mirrored for redundancy by using RAID 1.

If you install the PowerVM NovaLink software on a system that is managed by an HMC, use the HMC to create a Linux logical partition (LPAR) with the required resources. When you use the HMC to create the Linux LPAR, set the powervm_mgmt_capable flag to true.

RHEL 7.2 (LE), RHEL 7.3 (LE), or Ubuntu 15.10 or 16.04 LTS (recommended) is supported on the PowerVM NovaLink partition.

If you are using NovaLink with the SDN technical preview, RHEL 7.3 ppc64le or Ubuntu 16.04 is required (see Appendix A, “Software-Defined Networking (technical preview)” on page 245 for more information about SDN).

Supported operating systems for hosted logical partitions

PowerVM NovaLink supports all operating systems that are supported on the machine type and model of the managed system.

Virtual I/O Server partition requirements

PowerVM NovaLink requires VIOS Version 2.2.4 or later.

If you install the PowerVM NovaLink environment on a new managed system, configure one disk with at least 60 GB of storage for each VIOS instance that you plan to create on the server. You can configure the disks in your local serial-attached Small Computer System Interface (SAS) storage or on your SAN. If you create two instances of VIOS, create each disk on a separate SAS controller or FC card for redundancy. Otherwise, the resource requirements for VIOSs that are installed by the PowerVM NovaLink installer are the same as the resource requirements for VIOSs that are not installed by the PowerVM NovaLink.

Reliable Scalable Cluster Technology for Resource Monitoring and Control connections

To enable IPv6 link-local address support for Resource Monitoring and Control (RMC) connections, update the Reliable Scalable Cluster Technology (RSCT) packages on AIX and Linux LPARs to be at Version 3.2.1.0 or later.

IBM PowerVC requirement

IBM PowerVC Version 1.3 or later is required to manage a PowerVM NovaLink host with IBM PowerVC. Specifically for IBM PowerVC 1.3.2, your NovaLink partitions (pvm-novalink package) must be, at a minimum, Version 1.0.0.4, or it cannot be added as a managed host. Also, make sure that your native Linux OS meets the following levels:

•Ubuntu 15.10 or 16.04 LTS (recommended) or later

•RHEL 7.2 (LE) and RHEL 7.3 (LE) or later

Note: If you are using NovaLink with the SDN technical preview, RHEL 7.3 ppc64le or Ubuntu 16.04 is required. Run the dpkg -l pvm-novalink command to determine the version that is installed on a NovaLink partition.

Hardware Management Console requirement

HMC Version 8.5.0 or later is required to co-manage a system with PowerVM NovaLink.

2.3 Host and partition management planning

When you plan for the hosts in your IBM PowerVC managing PowerVM, you must consider the limitations in the number of hosts and VMs that can be managed by IBM PowerVC, and the benefits of using multiple VIOSs.

2.3.1 Physical server configuration

If you plan to use Live Partition Mobility (LPM), you must ensure that all servers are configured with the same logical-memory block size. This logical-memory block size can be changed from the Advanced System Management Interface (ASMI) interface.

2.3.2 HMC or PowerKVM planning

Data centers can contain hundreds of hosts and thousands of VMs. For IBM PowerVC Version 1.3.2, the following maximums are suggested:

•IBM PowerVC V1.3.2 managing PowerVM:

 – A maximum of 30 managed hosts is supported.

 – Each host can have a maximum of 500 VMs on it.

 – A maximum of 3,000 VMs can be on all of the combined hosts.

 – Each HMC can have a maximum of 500 VMs on it.

•IBM PowerVC V1.3.2 managing PowerVM by using PowerVM NovaLink:

 – A maximum of 200 PowerVM NovaLink-managed hosts is supported.

 – A maximum of 1000 VMs (PowerVM NovaLink, VIOSs, or client workloads) per PowerVM host are supported. This limit is determined by the PowerVM platform firmware versions that are available when IBM PowerVC Version 1.3.2 was released. For information about configuring your system for scale, see IBM PowerVM Best Practices, SG24-8062.

 – A maximum of 5000 VMs can be on all of the PowerVM NovaLink-managed hosts combined.

•IBM PowerVC Standard Edition V1.3.2 managing PowerKVM:

 – A maximum of 30 managed hosts is supported.

 – Each host can have a maximum of 225 VMs on it.

 – A maximum of 3,000 VMs can be on all of the combined hosts.

Note: No hard limitations exist in IBM PowerVC. These maximums are suggested from a performance perspective only.

Therefore, you must consider how to partition your HMC, and KVM in subsets, where each is managed by a IBM PowerVC management host.

Advanced installations typically use redundant HMCs to manage the hosts. Since Version 1.2.3, redundant HMCs are supported. If one HMC that you selected for IBM PowerVC becomes unavailable, change to the working HMC through the IBM PowerVC graphical user interface (GUI).

Note: With redundant HMCs, IBM PowerVC uses only one HMC to manage each specific host. If the original HMC is unavailable, manually switch to the other HMC on the IBM PowerVC GUI.

2.3.3 Virtual I/O Server planning

IBM PowerVC supports more than one VIOS server.

Consider a second VIOS to provide redundancy and I/O connectivity resilience to the hosts. Use two VIOSs to avoid outages to the hosts when you must perform maintenance, updates, or changes in the VIOS configuration.

If you plan to make partitions mobile, define the VIOS that provides the mover service on all hosts, and ensure that the Mover service partition option is enabled in the profile of these VIOSs.

The VIOS must be configured with “Sync current configuration Capability” turned ON. On the HMC, verify the settings of the VIOSs, as shown in Figure 2-1.

Figure 2-1 VIOS settings that must be managed by IBM PowerVC

Important: Configure the maximum number of virtual resources (virtual adapters) for the VIOS to at least 200. This setting provides sufficient resources on your hosts while you create and migrate VMs throughout your environment. Otherwise, IBM PowerVC indicates a warning during the verification process.

Changing the maximum virtual adapters in a Virtual I/O Server

From the HMC, in the left pane, click Server Management → Servers → managed_server, select the VIOS, and then click Configuration → Manage Profiles from the drop-down menu.

Select the profile that you want to use, and click Actions → Edit. Then, select the Virtual Adapters tab.

Replace the value in the Maximum virtual adapters field with a new value. See Figure 2-2.

Figure 2-2 Modify the maximum virtual adapters

2.4 Placement policies and templates

One goal of IBM PowerVC is to simplify the management of VMs and storage by providing the automated creation of partitions and virtual storage disks and the automated placement of partitions on physical hosts. This automation replaces the manual steps that are needed when you use PowerVM directly. In the manual steps, you must create disks, select all parameters that define each partition to deploy, and configure the mapping between the storage units and the partitions in the VIOSs.

This automation is performed by using deploy templates and placement policies.

2.4.1 Host groups

Use host groups to group hosts logically regardless of any features that they might share. For example, the hosts do not need the same architecture, network configuration, or storage. Host groups have these important features:

•Every host must be in a host group.

Any hosts that do not belong to a user-defined host group are members of the default host group. The default host group cannot be deleted.

•VMs are kept within the host group.

A VM can be deployed to a specific host or to a host group. After deployment, if that VM is migrated, it must always be migrated within the host group.

•Placement policies are associated with host groups.

Every host within a host group is subject to the host group’s placement policy. The default placement policy is striping.

An enterprise client can group its hosts to meet different business needs, for example, for test, development, and production, as shown in Figure 2-3. With different placement policies, even with different hardware, the client can archive at different service levels.

Figure 2-3 Host group sample

2.4.2 Placement policies

When you want to deploy a new partition, you can indicate to IBM PowerVC the host on which you want to create this partition. You can also ask IBM PowerVC to identify the hosts on which the partitions will best fit in a host group, based on a policy that matches your business needs. If you ask IBM PowerVC to identify the hosts on which the partitions will best fit in a host group, IBM PowerVC compares the requirements of the partitions with the availability of resources on the possible set of target hosts. IBM PowerVC considers the selected placement policy to make a choice.

IBM PowerVC offers five policies to deploy VMs:

•Striping placement policy

The striping placement policy distributes your VMs evenly across all of your hosts. For each deployment, IBM PowerVC determines the hosts with enough processing units and memory to meet the requirements of the VM. Other factors for determining eligible hosts include the storage and network connectivity that are required by the VM. From the group of eligible hosts, IBM PowerVC chooses the host that contains the fewest number of VMs and places the VM on that host.

•Packing placement policy

The packing placement policy places VMs on a single host until its resources are fully used, and then it moves on to the next host. For each deployment, IBM PowerVC determines the hosts with enough processing units and memory to meet the requirements of the VM. Other factors for determining eligible hosts include the storage and network connectivity that are required by the VM. From the group of eligible hosts, IBM PowerVC chooses the host that contains the most VMs and places the VM on that host. After the resources on this host are fully used, IBM PowerVC moves on to the next eligible host that contains the most VMs.

This policy can be useful when you deploy large partitions on small servers. For example, you must deploy four partitions that require eight, nine, and seven cores on two servers, each with 16 cores. If you use the striping policy, the first two partitions are deployed on the two servers, which leaves only eight free cores on each. IBM PowerVC cannot deploy the 9-core partition because an LPM operation must be performed before the 9-core partition can be deployed.

By using the packing policy, the first two 8-core partitions are deployed on the first hosts, and IBM PowerVC can then deploy the 9-core and 7-core partitions on the second host. This example is simplistic, but it illustrates the difference between the two policies: The striping policy optimizes performance, and the packing policy optimizes human operations.

•CPU utilization balance placement policy

This placement policy places VMs on the host with the lowest CPU utilization in the host group. The CPU utilization is computed as a running average over the last 15 minutes.

•CPU allocation balance placement policy

This placement policy places VMs on the host with the lowest percentage of its CPU that is allocated post-deployment or after relocation.

For example, consider an environment with two hosts:

 – Host 1 has 16 total processors, four of which are assigned to VMs.

 – Host 2 has four total processors, two of which are assigned to VMs.

Assume that the user deploys a VM that requires one processor. Host 1 has (4+1)/16, or 5/16 of its processors that are allocated. Host 2 has (2+1)/4, or 3/4 of its processors that are allocated. Therefore, the VM is scheduled to Host 1.

•Memory utilization balanced

This placement policy places virtual machines on the host that has the lowest memory utilization in the host group. The memory utilization is computed as a running average over the last 15 minutes.

 – HMC managed hosts do not accurately report their memory utilization. Therefore, host groups that use this policy should not contain HMC managed hosts. If there are any HMC managed hosts in the host group, PowerVC always targets the HMC hosts for placement because their utilization is recorded as 0.

 – All virtual machines on a PowerVC host should have RMC running for the most accurate memory utilization estimates.

•Memory allocation balance placement policy

This placement policy places VMs on the host with the lowest percentage of its memory that is allocated post-deployment or after relocation.

For example, consider an environment with two hosts:

 – Host 1 has 24 GB total memory, 11 GB of which are assigned to VMs.

 – Host 2 has 8 GB total memory, 2 GB of which are assigned to VMs.

Assume that the user deploys a VM that requires 1 GB of total memory. Host 1 has (11+1)/24, or 1/2 of its memory that is allocated. Host 2 has (2+1)/8, or 3/8 of its memory that is allocated. Therefore, the VM is scheduled to Host 2.

Note: A default placement policy change does not affect existing VMs. It affects only new VMs that are deployed after the policy setting is changed. Therefore, changing the placement policy for an existing environment does not result in moving existing partitions.

Tip: The following settings might increase the throughput and decrease the duration of deployments:

•Use the striping policy rather than the packing policy.

•Limit the number of concurrent deployments to match the number of hosts.

When a new host is added to the host group that is managed by IBM PowerVC, if the placement policy is set to the striping mode, new VMs are deployed on the new host until it catches up with the existing hosts. IBM PowerVC allocates partitions only on this new host until the resources use of this host is about the same as on the previously installed hosts.

When a new partition is deployed, the placement algorithm uses several criteria to select the target server for the deployment, such as availability of resources and access to the storage that is needed by the new partitions. By design, the IBM PowerVC placement policy is deterministic. Therefore, the considered resources are the amounts of processing power and memory that are needed by the partition, as defined in the partition profile (virtual processors, entitlement, and memory). Dynamic resources, such as I/O bandwidth, are not considered, because they result in a non-deterministic placement algorithm.

Note: The placement policies are predefined. You cannot create your own policies.

The placement policy can also be used when you migrate a VM. Figure 2-4 shows the IBM PowerVC user interface for migrating a partition. Use this interface to select between specifying a specific target or letting IBM PowerVC select a target according to the current placement policy.

Figure 2-4 Migration of a partition by using a placement policy

2.4.3 Template types

Rather than define all characteristics for each partition or each storage unit that must be created, the usual way to create them in IBM PowerVC is to instantiate these objects from a template that was previously defined. The amount of effort that is needed to define a template is similar to the effort that is needed to define a partition or storage unit. Therefore, reusing templates saves significant effort for the system administrator, who must deploy many objects.

IBM PowerVC provides a GUI to help you create or customize templates. Templates can be easily defined to accommodate your business needs and your IT environment.

Three types of templates are available:

Compute templates These templates are used to define processing units, memory, and disk space that are needed by a partition. They are described in 2.4.4, “Information that is required for compute template planning” on page 30.

Deploy templates These templates are used to allow authorized self-service users to quickly, easily, and reliably deploy an image. They are described in 2.4.5, “Information that is required for deploy template planning” on page 35.

Storage templates These templates are used to define storage settings, such as a specific volume type, storage pool, and storage provider. They are described in 2.6.2, “Storage templates” on page 43.

Use the templates to deploy new VMs. This approach propagates the values for all of the resources into the VMs. The templates accelerate the deployment process and create a baseline for standardization.

Templates can be defined by using the Standard view or, for a more detailed and specific configuration, you can use the Advanced view, which is shown in “Advanced compute templates” on page 32.

2.4.4 Information that is required for compute template planning

The IBM PowerVC management host provides 11 predefined compute templates. Your redefined templates can be edited and removed. You can create your own templates.

Before you create templates, plan for the amount of resources that you need for the classes of partitions that you need. For example, different templates can be used for partitions that are used for development, test, and production, or you can have different templates for database servers, application servers, and web servers.

IBM PowerVC offers two template options:

Basic Create micropartitions (shared partitions) by specifying the minimum amount of information.

Advanced Create dedicated partitions or micropartitions, with the level of detail that is available on the HMC.

Basic compute templates

The following information helps your planning efforts regarding basic compute templates:

Template name The name to use for the template.

Virtual processors Number of virtual processors. A VM usually performs best if the number of virtual processors is close to the number of processing units that is available to the VM.

Memory (MB) Amount of memory, in MB. The value for memory must be a multiple of the memory region size that is configured on your host. You can also specify IBM Active Memory™ Expansion (AME) Factor. To see the region size for your host, open the Properties window for the selected host in the HMC, and then open the Memory tab and record the “memory region size” value. Figure 2-5 on page 33 shows an example.

Processing units Number of entitled processing units. A processing unit is the minimum amount of processing resource that the VM can use. For example, a value of 1 (one) processing unit corresponds to 100% use of a single physical processor. Processing units are split between virtual processors, so a VM with two virtual processors and one processing unit appears to the VM user as a system with two processors, each running at 50% speed.

Disk (GB) Disk space that is needed, in GB.

Compatibility mode Select the processor compatibility that you need for your VM. Table 2-12 describes each compatibility mode and the servers on which the VMs that use each mode can operate.

Table 2-12 Processor compatibility modes

Processor compatibility mode

Description

Supported servers

POWER6

Use the POWER6 processor compatibility mode to run operating system versions that use all of the standard features of the POWER6 processor.

VMs that use the POWER6 processor compatibility mode can run servers that are based on POWER6, IBM POWER6+™, POWER7, or POWER8 processors.

POWER6+

Use the POWER6+ processor compatibility mode to run operating system versions that use all of the standard features of the POWER6+ processor.

VMs that use the POWER6+ processor compatibility mode can run on servers that are based on POWER6+, POWER7, or POWER8 processors.

POWER7, including POWER7+

Use the POWER7 processor compatibility mode to run operating system versions that use all of the standard features of the POWER7 processor.

VMs that use the POWER7 processor compatibility mode can run servers that are based on POWER7 or POWER8 processors.

POWER8

Use the POWER8 processor compatibility mode to run operating system versions that use all of the standard features of the POWER8 processor.

VMs that use the POWER8 processor compatibility mode can run servers that are based on POWER8 processors.

Default

The default processor compatibility mode is a preferred processor compatibility mode that enables the hypervisor to determine the current mode for the VM. When the preferred mode is set to Default, the hypervisor sets the current mode to the most fully featured mode that is supported by the operating environment. In most cases, this mode is the processor type of the server on which the VM is activated. For example, assume that the preferred mode is set to Default and the VM is running on a POWER8 processor-based server. The operating environment supports the POWER8 processor capabilities, so the hypervisor sets the current processor compatibility mode to POWER8.

The servers on which VMs with the preferred processor compatibility mode of Default can run depend on the current processor compatibility mode of the VM. For example, if the hypervisor determines that the current mode is POWER8, the VM can run on servers that are based on POWER8 processors.

Note: For a detailed explanation of processor compatibility modes, see IBM PowerVM Virtualization Introduction and Configuration, SG24-7940.

Advanced compute templates

The following information about advanced compute templates helps you plan for their use:

Template name The name for the template.

Virtual processors The number of virtual processors. A VM usually performs best if the number of virtual processors is close to the number of processing units that is available to the VM. You can specify the following values:

Minimum The smallest number of virtual processors that you accept for deploying a VM.

Desired The number of virtual processors that you want for deploying a VM.

Maximum The largest number of virtual processors that you allow when you resize a VM. This value is the upper limit to resize a VM dynamically. When it is reached, you need to power off the VM, edit the profile, change the maximum to a new value, and restart the VM.

Memory (MB) Amount of memory, expressed in MB. The value for memory must be a multiple of the memory region size that is configured on your host. The minimum value is 16 MB. To see the region size for your host, open the Properties window for the selected host on the HMC, and then open the Memory tab to view the memory region size. Figure 2-5 on page 33 shows an example. You can specify the following values:

Minimum The smallest amount of memory that you want for deploying a VM. If the value is not available, the deployment does not occur.

Desired The total memory that you want in the VM. The deployment occurs with an amount of memory less than or equal to the wanted amount and greater than or equal to the minimum amount that is specified.

Maximum The largest amount of memory that you allow when you resize a VM. This value is the upper limit to resize a VM dynamically. When it is reached, you must power off the VM, edit the profile, change the maximum to a new value, and restart the VM.

Figure 2-5 Memory region size view on the HMC

Processing units Number of entitled processing units. A processing unit is the minimum amount of processing resource that the VM can use. For example, a value of 1 (one) processing unit corresponds to 100% use of a single physical processor. The setting of processing units is available only for shared partitions, not for dedicated partitions. You can specify the following values:

Minimum The smallest number of processing units that you accept for deploying a VM. If this value is not available, the deployment does not occur.

Desired The number of processing units that you want for deploying a VM. The deployment occurs with a number of processing units that is less than or equal to the wanted value and greater than or equal to the minimum value.

Maximum The largest number of processing units that you allow when you resize a VM. This value is the upper limit to which you can resize dynamically. When it is reached, you must power off the VM, edit the profile, change the maximum value to a new value, and restart the VM.

Important: Processing units and virtual processor are values that work closely and must be calculated carefully. For more information about virtual processor and processing units, see IBM PowerVM Virtualization Managing and Monitoring, SG24-7590.

Disk (GB) Disk space that is needed in GB.

Note: Use the advanced template to define only the amount of storage that you need. You cannot use the advanced template to specify a number of volumes to create.

Compatibility mode Select the compatibility that is needed for your VM. Table 2-12 on page 31 lists each processor compatibility mode and the servers on which the VMs that use each processor compatibility mode can successfully operate.

Enable virtual machine remote restart
Users can remote restart a VM on another host easily if the current host fails. This feature enhanced the availability of applications in addition to the solutions that are based on IBM PowerHA and LPM.

Note: This function is based on the PowerVM simplified remote restart function and is supported only by POWER8 servers at the time of writing. For the requirements of remote restart, see IBM Knowledge Center:

http://www.ibm.com/support/knowledgecenter/SSXK2N_1.3.2/com.ibm.powervc.standard.help.doc/powervc_planning_storage_hmc.html

Shared processors or dedicated processor
Decide whether the VM uses processing resources from a shared processor pool or dedicated processor resources.

Option A: Shared processors settings

The following values are available for option A:

Uncapped Uncapped VMs can use processing units that are not being used by other VMs, up to the number of virtual processors that is assigned to the uncapped VM. You can also specify the shared processor pool.

Capped Capped VMs can use only the number of processing units that are assigned to them.

Weight (0 - 255) If multiple uncapped VMs require unused processing units, the uncapped weights of the uncapped VMs determine the ratio of unused processing units that are assigned to each VM. For example, an uncapped VM with an uncapped weight of 200 receives two processing units for every processing unit that is received by an uncapped VM with an uncapped weight of 100.

Option B: Dedicated processor settings

The following values are available for option B:

Idle sharing This setting enables this VM to share its dedicated processors with other VMs when this VM is powered on and idle (also known as a dedicated donating partition).

Availability priority To avoid shutting down mission-critical workloads when your server firmware unconfigures a failing processor, set availability priorities for the VMs (0 - 255). A VM with a failing processor can acquire a replacement processor from a VM with a lower availability priority. The acquisition of a replacement processor allows the VM with the higher availability priority to continue running after a processor failure.

2.4.5 Information that is required for deploy template planning

Administrators can configure image deployment properties and save them as a deploy template. A deploy template includes everything necessary to create quickly and easily a VM, including the deployment target, storage connectivity group, compute template, and so on.

To create a deploy template, complete the following steps:

1. From the Images window, select the image that you want to use to create a deploy template and click Create Template from Image.

2. Fill out the information in the window that opens, then click Create Deploy Template.

3. The deploy template is now listed on the Deploy Templates tab of the Images window.

After creation, you can edit a deploy template by selecting the template and clicking Edit.

2.5 IBM PowerVC storage access SAN planning

In IBM PowerVC Standard and Cloud editions, VMs can access their storage by using either of three protocols:

•Classical vSCSI, as described in “vSCSI storage access” on page 36

•NPIV, as described in “NPIV storage access” on page 37

•vSCSI to SSP, as described in “Shared storage pool: vSCSI” on page 39

A minimum configuration of the SAN and storage is necessary before IBM PowerVC can use them. For example, IBM PowerVC creates virtual disks on storage devices, but these devices must be set up first. You must perform the following actions before you use IBM PowerVC:

•Configuration of the FC fabric for the IBM PowerVC environment must be planned first: cable attachments, SAN fabrics, and redundancy. It is common to create at least two independent fabrics to provide SAN redundancy. IBM PowerVC supports adding up to
25 fabrics.

•IBM PowerVC provides storage for VMs through the VIOS.

With IBM PowerVC, the storage is accessed by using NPIV, vSCSI, or an SSP that uses vSCSI. The VIOS and SSP must be configured before IBM PowerVC can manage them.

Important: There are special considerations to have in mind when using DS8870 storage with IBM i VMs that are managed by PowerVC. For more information, see the following website:

https://ibm.biz/BdsY5H

•The SAN switch administrator user ID and password must be set up. They are used by IBM PowerVC.

•The storage controller administrator user ID and password must be set up.

•In IBM PowerVC, you must create a VM manually to capture your first image. Prepare by performing these tasks:

 – VIOS must be set up for NPIV or vSCSI to provide access from the VM to the SAN.

 – For NPIV, SAN zoning must be configured to provide access from virtual FC ports in VM to storage controllers.

 – The OS must be installed in the first VM, and the cloud-init must be installed and used.

After IBM PowerVC can access storage controllers and switches, it can perform these tasks:

•Collect inventory on the FC fabric

•Collect inventory on storage devices (pools and volumes)

•Monitor health

•Detect misconfigurations

•Manage zoning

•Manage LUNs on storage devices

2.5.1 vSCSI storage access

With IBM PowerVC Standard Edition Version 1.2.2 or later and IBM Cloud PowerVC Manager, you can use vSCSI to access SAN storage in the IBM PowerVC environment.

Before you use vSCSI-attached storage in IBM PowerVC, you must complete the following steps:

1. Turn off SCSI reserves for volumes that are being discovered on all the VIOSs that are used for vSCSI connections. This step is required for LPM operations and for dual VIOSs.

For the IBM Storwize family, XIV, and EMC that use the AIX Platform Cluster Manager (PCM) model, you must run the following command on every VIOS where vSCSI operations are run:

chdef -a reserve_policy=no_reserve -c disk -s fcp -t mpioosdisk

Support for IBM System Storage DS8000 was introduced in IBM PowerVC Version 1.3.0. For IBM System Storage DS8000 systems, you must run the following command on every VIOS where vSCSI operations are run:

chdef -a reserve_policy=no_reserve -c disk -s fcp -t aixmpiods8k

Note: On the DS8000, if the host entry type for a VIOS is AIX, then that VIOS supports more than 256 vSCSI attached volumes. If the host entry type is Linux or another host type that supports LUNPolling instead of reportLUN, then at most 255 vSCSI attached volumes are supported on that VIOS. Therefore, as preferred practice, set the host entry type for a VIOS to AIX.

Note: You must use the chdef command, not the chdev command.

Important: This step is mandatory. Different commands exist for other multipath I/O (MPIO) drivers. See the documentation of the drivers to learn how to turn off SCSI reserves.

2. You must configure all zoning between the VIOS and the storage device ports so that you can import vSCSI environments easily and use any number of fabrics with vSCSI.

Figure 2-6 shows how VMs in IBM PowerVC access storage by using vSCSI.

Figure 2-6 IBM PowerVC storage access by using vSCSI

The flow of storage management from physical storage LUNs to VMs in IBM PowerVC with vSCSI is described:

•LUNs are provisioned on a supported storage controller.

•LUNs are masked to VIOS FC ports and are discovered as hdisk logical devices in VIOS.

•LUNs are mapped (by using mkvdev) from VIOS to VMs over an vSCSI virtual adapter pair.

These steps are completed automatically by IBM PowerVC. No zoning is involved because individual VMs do not access physical LUNs directly over the SAN.

2.5.2 NPIV storage access

Figure 2-7 on page 38 shows how VMs access storage through NPIV with IBM PowerVC.

The following list describes the actions that are performed by IBM PowerVC to manage the flow of storage from physical storage LUNs to VMs:

•Access to SAN from VMs is configured on VIOSs by using an FC adapter pair and NPIV (by running the vfcmap command).

•LUNs are provisioned on a supported storage controller.

•LUNs are masked to VM virtual FC ports.

•SAN zoning is adjusted so that VMs have access from their virtual FC ports to storage controller host ports. Changes in zoning are performed automatically by IBM PowerVC.

•LUNs are viewed as logical devices in VMs.

These actions are completed automatically by IBM PowerVC.

Figure 2-7 IBM PowerVC storage access by using NPIV

2.5.3 Shared storage pool: vSCSI

Figure 2-8 shows how VMs access storage in an SSP with IBM PowerVC.

Here is the flow of storage management from physical storage LUNs to VMs in IBM PowerVC:

•The SSP is configured manually: Creation of a cluster, inclusion of VIOSs in the cluster, and additions of disk to the pool.

•IBM PowerVC discovers the SSP when it discovers the VIOSs.

•IBM PowerVC can create logical units (LUs) in the SSP when it creates a VM.

•IBM PowerVC instructs the VIOS to map the SSP LUs to LUNs for the VIO clients’ partitions that access them through vSCSI devices.

•SSPs are supported on hosts that are managed either by HMC or NovaLink.

Figure 2-8 IBM PowerVC storage access by using an SSP

2.5.4 Storage access in IBM PowerVC Standard Edition managing PowerKVM

Figure 2-9 shows how VMs access storage with IBM PowerVC Standard Edition managing PowerKVM.

The following list is a description of the flow of storage management from host internal storage to VMs in IBM PowerVC Standard Edition managing PowerKVM:

•PowerKVM accesses the internal storage on the host.

•IBM PowerVC manages the internal storage when a PowerKVM host is added for management.

•LUN requests are created automatically by IBM PowerVC and mapped to the VMs.

Here is the flow of storage management from SAN storage to VMs in IBM PowerVC managing PowerKVM by using iSCSI:

•SAN storage is available through the Ethernet network by configuring access over the iSCSI protocol.

•IBM PowerVC manages the SAN storage when the storage provider is added.

•LUN requests are created automatically by IBM PowerVC and mapped to VMs.

Figure 2-9 IBM PowerVC managing PowerKVM storage access

2.6 Storage management planning

IBM PowerVC manages storage volumes, which can be attached to VMs. These storage volumes can be backed by IBM Storwize storage devices, SAN Volume Controller devices, IBM XIV storage devices, IBM DS8000 system, EMC VMAX storage devices, EMC VNX storage devices, or SSP files.

IBM PowerVC requires IP connectivity to the storage providers to manage the storage volumes.

2.6.1 IBM PowerVC terminology

IBM PowerVC uses a few terms and concepts that differ from terms that are used in PowerVM:

Storage provider Any system that provides storage volumes. Storage providers can be an IBM Storwize system, SAN Volume Controller, IBM XIV system, IBM DS8000 system, EMC VMAX, EMC VNX, Hitachi storage, or SSP storage. Figure 2-10 shows a IBM PowerVC environment that manages one IBM SAN Volume Controller. Depending on the storage type, IBM PowerVC may refer to storage providers as storage controllers.

Figure 2-10 IBM PowerVC storage providers

Fabric The name for a collection of SAN switches. Figure 2-11 shows a IBM PowerVC Fabrics window that displays information for a switch that is named FAB0, with IP address 9.114.62.197. Click this address on the Fabrics window to open the graphical view of the switch, which is shown as an overlay in the figure.

Figure 2-11 Fabrics window that shows an embedded switch GUI

Storage pool A storage resource that is defined on the storage provider in which IBM PowerVC can create volumes. IBM PowerVC cannot create or modify storage pools; it can only discover them. The storage pools must be managed directly from the storage providers. Figure 2-12 shows the detail of an IBM Storwize V7000 storage provider that is configured with two storage pools for different purposes.

Figure 2-12 Storage pools

Shared storage pool In IBM PowerVC, shared storage resource refers to the PowerVM shared storage pool (SSP) feature. The SSP cannot be created or modified by IBM PowerVC. You must create the SSP on the VIOS before IBM PowerVC can create volumes on the SSP.

Volume Volumes are also referred to as a disk or a LUN. They are carved from the storage pools and presented as virtual disks to the partitions that are managed by IBM PowerVC.

Storage template This template defines the properties of a storage volume, such as location, thin provisioning, and compression. For example, by using the templates that are shown in Figure 2-13, you can create volumes that are either a normal thin-provisioned volume or a mirrored volume. For more information, see 2.6.2, “Storage templates” on page 43.

Figure 2-13 Storage templates

Storage connectivity group
A set of VIOSs with access to the same storage controllers. For more information, see 2.6.3, “Storage connectivity groups and tags” on page 46.

Tags Tags are a way to partition the FC ports of a host in sets that can be associated with sets of VIOSs. For more information, see 2.6.3, “Storage connectivity groups and tags” on page 46.

2.6.2 Storage templates

Storage templates are used to speed up the creation of a disk. A storage template defines several properties of the disk unit. Disk size is not part of the template. For different types of storage devices, the information that is defined in a template differs. This section introduces the IBM Storwize storage template only, which is a common type of storage that is used in the IBM PowerVC environment.

IBM Storwize storage template definition

The following information is defined in a template:

•Name of the storage template.

•Storage provider. The template is associated with a single storage provider. It cannot be used to instantiate disks from multiple storage providers.

•Storage pool within a storage provider. The template is associated with a single storage pool. You can add another pool to support volume mirroring in the Advanced settings area.

•Thin or thick (full) provisioning. To choose thick provisioning, select the Generic type of volume.

•Advanced Settings area:

The following information is defined in the Advanced Settings area:

 – I/O group: The I/O group to which to add the volume. For the SAN Volume Controller, the maximum I/O groups that are supported is four.

 – % of virtual capacity : Determines how much real storage capacity is allocated to the volume at creation time, as a percentage of the maximum size that the volume can reach.

 – Automatically expand : Select Yes or No. This setting prevents the volume from using all of its capacity and going offline. As a thin-provisioned volume uses more of its capacity, this feature maintains a fixed amount of unused real capacity, which is called the contingency capacity.

 – Warning threshold: When real capacity reaches a specific percentage of virtual capacity, a warning alert is sent.

 – Grain size: A thin-provisioned grain size can be selected in the range 32 KB - 256 KB. A grain is a chunk that is used for allocating space. The grain size affects the maximum virtual capacity for the volume. Generally, smaller grain sizes save space but require more metadata access, which can affect performance adversely. The default grain size is 256 KB, which is the preferred option. The grain size cannot be changed after the thin-provisioned volume is created.

 – Use all available WWPNs for attachment: Specifies whether to enable multipath zoning. When this setting is enabled, IBM PowerVC uses all available WWPNs from all of the I/O groups in the storage controller to attach the volume to the VM. Enabling multipath causes each WWPN that is visible on the fabric to be zoned to the VM.

 – Enable mirroring : When checked, you must select another pool for volume mirroring. The volume that is created has one more copy in the mirroring pool. IBM Storwize clients can use two pools based on two different back-end storage devices to provide high availability.

A storage template can then be selected during volume creation operations.

Figure 2-14 shows a window that is presented to an IBM PowerVC administrator when the administrator defines the advanced settings for a thin-provisioned storage template definition.

Figure 2-14 Storage template definition: Advanced settings, thin-provisioned

Storage template planning

When you register a storage provider with IBM PowerVC, a default storage template is created for that provider. Edit this default template to suit your needs immediately after IBM PowerVC discovers the service provider.

Note: After a disk is created and uses a template, you cannot modify the template settings.

You can define several storage templates for one storage provider. If the storage provider contains several storage pools, at least one storage template is needed for each pool before those pools can be used to create volumes.

When you create a storage volume, you must select a storage template. All of the properties that are specified in the storage template are applied to the new volume, which is created on the storage provider that is specified in the storage template. To create a disk, you must enter the name of the template to use, volume name, and size only. Decide whether to select the Enable sharing check box. See Figure 2-15.

Figure 2-15 Volume creation

A storage template must also be specified when you deploy a new VM to control the properties of the virtual server’s boot volumes and data volumes. IBM PowerVC can manage pre-existing storage volumes. You can select them when you register the storage device or at any later time. Preexisting storage volumes do not have an associated storage template.

2.6.3 Storage connectivity groups and tags

IBM PowerVC uses storage connectivity groups and tags.

Storage connectivity groups

When you create a VM, IBM PowerVC needs a way to identify on which host it has to deploy this machine. One of the requirements is that from this host, the VM connects to its storage. Also, when you request IBM PowerVC to migrate a VM, IBM PowerVC must ensure that the target host also provides the VM with connectivity to its volume.

The purpose of a storage connectivity group is to define settings that control how volumes are attached to VMs, including the connectivity type for boot and data volumes, physical FC port restrictions, fabrics, and redundancy requirements for VIOSs, ports, and fabrics. A storage connectivity group contains a set of VIOSs that are allowed to participate in volume connectivity.

Custom storage connectivity groups provide flexibility when different policies are needed for different types of VMs. For example, an IBM PowerVC administrator might define storage connectivity groups that direct storage connectivity to use VIOS_1 and VIOS_2 for production VMs and VIOS_3 for development VMs. Many other connectivity policies are available with storage connectivity groups.

When you deploy a new VM with IBM PowerVC, a storage connectivity group must be specified. The VM is associated with that storage connectivity group during the VM's existence. A VM can be deployed only on Power Systems hosts that satisfy the storage connectivity group settings.

The VM can be migrated only within its associated storage connectivity group and host group.

The default storage connectivity group for NPIV connectivity is created when IBM PowerVC first starts, and as resources are managed in the environment, they are added to this group when applicable. Default groups that allow vSCSI connectivity are created only when an existing VM with vSCSI connectivity is managed in the environment. A default storage connectivity group that is specific for an SSP is created when the SSP is first automatically managed into the environment. When creating custom storage connectivity groups, group VIOSs that have access to the same storage providers or associate specific fabrics that filter out VIOSs that do not have storage provider connectivity.

Figure 2-16 shows the result of the discovery by IBM PowerVC of an environment with the following conditions:

•Three POWER servers exist.

•Each server hosts two VIOSs.

•Each VIOS has two FC ports.

•Four VIOSs connect to an IBM SAN Volume Controller.

IBM PowerVC automatically created the storage connectivity groups. Only one storage connectivity group for NPIV storage access was created because no other connectivity types are defined by default. This storage connectivity group corresponds to the way that partitions can access storage from these hosts.

Figure 2-16 List of storage connectivity groups

The default storage connectivity groups can be disabled but not deleted. For more information, see 4.9, “Storage connectivity group setup” on page 115.

The system administrator can define additional storage connectivity groups to further constrain the selection of host systems. You can use storage connectivity group to group host systems together in, for example, production and development groups. On large servers that are hosting several VIOSs, you can use storage connectivity groups to direct partitions to use a specific pair of VIOSs on each host.

Tip: A storage connectivity group can be modified after its creation to, for example, add or remove VIOSs. Therefore, when your environment changes, you can add new hosts and include their VIOSs in existing storage connectivity groups.

Figure 2-17 shows a diagram of storage connectivity group technology. It includes two Power Systems servers, each with three VIOSs. Two VIOSs from each server are part of the production storage connectivity group (called Production SCG in the figure) and one VIOS from each server is part of the development storage connectivity group (Development SCG). The VMs that are named VM1, VM2, VM4, and VM5 are associated with the production storage connectivity group, and their I/O traffic passes through the FC ports of A1, A2, B1, and B2 VIOSs. The development partitions VM3 and VM6 are associated with the development storage connectivity group, and their traffic is limited to using the FC ports that are attached to VIOSs A3 and B3.

Figure 2-17 Storage connectivity groups

Figure 2-18 shows how IBM PowerVC presents the detail of a storage connectivity group. This storage connectivity group contains three hosts, each with two VIO servers and two FC ports. Only four VIO servers have connectivity to the defined fabric.

Figure 2-18 Content of a storage connectivity group

Storage connectivity group redundancy

During the creation of a new storage connectivity group, the group is assigned to VIOSs that belong to this storage connectivity group, and follow the redundancy requirements regarding the number of VIOSs per host and VIOSs’ connectivity to fabrics. IBM PowerVC V1.3.2 supports the following requirements for VIOSs per host in storage connectivity group:

•One VIOS

•Two VIOSs

•Three VIOSs

•Four VIOSs

In addition to the number of VIO servers per host in the storage connectivity group, the fabric access requirement for storage connectivity group must be defined on a VIOS level or on the host level. IBM PowerVC V1.3.2 supports the following fabric access requirements for a storage connectivity group:

•Every fabric per VIOS

•Every fabric per host

•At least one fabric per VIOS

•Exactly one fabric per VIOS

Storage connectivity group definitions for redundancy and fabric connectivity can be modified after the storage connectivity group is created. To modify the properties of the storage connectivity group, click Configuration → Storage Connectivity Groups → Group_Name → Edit.

Figure 2-19 shows the storage connectivity group redundancy requirements that can be defined for the group.

Figure 2-19 Storage connectivity group redundancy

The Health tab of the storage connectivity group definition provides information of storage connectivity group health and possible problems. An IBM PowerVC administrator may use the Health tab to check detailed status of storage connectivity group at any time.

Storage port tags

IBM PowerVC introduces a concept that does not exist within PowerVM: storage port tags. IBM PowerVC allows arbitrary tags to be placed on FC ports.

Note: An FC port can have no tag or one tag. This tag can change over time, but a port cannot have two or more tags simultaneously.

A storage connectivity group can be configured to connect only through FC ports with a specific tag. Storage connectivity groups that share a VIOS can use different physical FC ports on the VIOS. The IBM PowerVC administrator handles this function by assigning different port tags to the physical FC ports of the VIOS. These tags are labels that can be assigned to specific FC ports across your hosts. A storage connectivity group can be configured to connect only through FC ports that have the same tags when you deploy with NPIV direct connectivity. Port tagging is not effective when you use SSP.

Combining a storage connectivity group and tags

By using both the storage connectivity group and tag functions, you can easily manage different configurations of SAN topology that fit your business needs for partitioning the SAN and restricting disk I/O traffic to part of the SAN.

Figure 2-20 shows an example of possible tag usage. The example consists of two IBM Power Systems servers, each with two VIOSs. Each VIOS has three FC ports. The first two FC ports are tagged ProductionSCG and connect to a redundant production SAN. The third port is tagged DevelopmentSCG and connects to a development SAN. Client VMs that belong to either storage connectivity groups (ProductionSCG or DevelopmentSCG) share VIOSs but do not share FC ports.

Figure 2-20 Storage connectivity groups and tags

The VIOSs in a storage connectivity group provide storage connectivity to a set of VMs with common requirements. An administrator can use several approaches to configure storage connectivity groups. Figure 2-21 shows these possible scenarios:

Uniform All VMs use all VIOSs and all FC ports.

Virtual I/O Server segregation
Different groups of different VMs use different sets of VIOSs but all FC ports on each VIOS.

Port segregation Different groups of different VMs use all VIOSs but different FC ports according to tags on those ports.

Combination In a combination of VIOS and port segregation, different groups of different VMs use different sets of VIOSs and different FC ports according to tags on those ports.

Figure 2-21 Examples of storage connectivity group deployments

2.7 Network management planning

A network represents a set of Layer 2 and Layer 3 network specifications, such as how your network is subdivided by using VLANs, and information about the subnet mask, gateway, and other characteristics. When you deploy an image, you choose one or more existing networks to apply to the new VM.

Setting up networks in advance reduces the amount of information that you must enter during each deployment and helps to ensure a successful deployment.

The first selected network is the management network that provides the primary system default gateway address. You can add additional networks to divide the traffic and provide more functions.

IBM PowerVC supports IP addresses by using hardcoded (/etc/hosts) or Domain Name Server (DNS)-based host name resolution. IBM PowerVC also supports Dynamic Host Configuration Protocol (DHCP) or static IP address assignment. For DHCP, an external DHCP server is required to provide the address on the VLANs of the objects that are managed by IBM PowerVC.

Note: When you use DHCP, IBM PowerVC is not aware of the IP addresses of the VMs that it manages.

2.7.1 Infoblox support

New in IBM PowerVC 1.3.1.2 is support to automatically update DNS records.

Typically, when a VM is deployed or deleted, you must manually create or delete the DNS record. With Fix Pack 2, you can register an Infoblox vNIOS server in IBM PowerVC. Infoblox then automatically updates the DNS records when VMs are deployed or deleted, including details such as the IP address and VM name.

You can register an Infoblox server on the IBM PowerVC user interface on the Network page. Click Configure DNS Authority and add network details. These details are then saved as a zone name in the Infoblox appliance.

For more information about using an Infoblox vNIOS server with IBM PowerVC, see
IBM Knowledge Center:

https://www.ibm.com/support/knowledgecenter/SSXK2N_1.3.1/com.ibm.powervc.standard.help.doc/powervc_configuring_dns_authority_hmc.html

2.7.2 Multiple network planning

Each VM that you deploy must be connected to one or more networks. By using multiple networks, you can split traffic. The IBM PowerVC management host uses three common types of networks when it deploys VMs:

Data network This network provides the route over which workload traffic is sent. At least one data network is required for each VM, and more than one data network is allowed.

Management network
This type of network is optional but highly suggested to provide a higher level of function and security to the VMs. A management network provides the RMC connection between the management console and the client LPAR. VMs are not required to have a dedicated management network, but a dedicated management network simplifies the management of advanced features, such as LPM and dynamic reconfiguration. IBM PowerVC can connect to a management network. First, you must set up networking on the switches and the SEA to support it.

Live Partition Migration (LPM) network
This optional network provides the route over which migration data is sent from one host to another host. By separating this data onto its own network, you can shape that network traffic to specify a higher or lower priority over data or management traffic. If you do not want to use a separate network for LPM, you can reuse an existing data or management network connection for LPM.

Since Version 1.2.2, IBM PowerVC can dynamically add a network interface controller (NIC) to a VM or remove a NIC from a VM. IBM PowerVC does not set the IP address for new network interfaces that are created after the machine deployment. Any removal of a NIC results in freeing the IP address that was set on it.

Tip: Create all of the networks that are needed for future VM creation. Contact your network administrator to add all of the needed VLANs on the switch ports that are used by the SEA (PowerVM) or network bridges (PowerKVM). This action drastically reduces the amount of time that is needed for network management (no more actions for IBM PowerVC administrators and network teams).

2.7.3 Shared Ethernet Adapter planning

Set up the SEAs for a registered host before you use the host within IBM PowerVC. The configuration for each SEA determines how each host treats networks. IBM PowerVC requires that the SEAs are created before you start to manage the systems.

If you are using SEA in sharing/auto mode with VLAN tagging, create it without any VLANs that are assigned on the Virtual Ethernet Adapters.

IBM PowerVC adds or removes the VLANs on the SEAs when necessary (at VM deletion and creation):

• If you deploy a VM on a new network, IBM PowerVC adds the VLAN on the SEA.

• If you delete the last VM of a specific network (for a host), the VLAN is automatically deleted.

• If the VLAN is the last VLAN that was defined on the Virtual Ethernet Adapter, this VEA is removed from the SEA.

• If you are using SEA and the following setting is true:

 – High availability mode set to sharing: IBM PowerVC ensures that at least two Virtual Ethernet Adapters are kept in the SEA.

 – High availability mode set to auto: IBM PowerVC ensures that at least one Virtual Ethernet Adapter is kept in the SEA.

IBM PowerVC then connects VMs to that SEA, deploys client-level VLANs to it, and allows dynamic reconfiguration of the network to SEA mapping. When you create a network in IBM PowerVC, a SEA is automatically chosen from each registered host, based on the VLAN that you specified when you defined the network. If the VLAN does not exist yet on the SEA, IBM PowerVC deploys that VLAN to the SEA that is specified.

VLANs are deployed only as VMs need them to reduce the broadcast domains.

Important: When multiple Ethernet adapters exist on either or both the migration source host or destination host, IBM PowerVC cannot control which adapter is used during the migration. To ensure the use of a specific adapter for your migrations, configure an IP address on the adapter that you want to use.

Note: To manage PowerVM, IBM PowerVC requires that at least one SEA is defined on the host.

You can dynamically change the SEA to which a network is mapped or you can remove the mapping, but this assignment is a default automatic assignment when you set up your networks. It might not match your organization’s naming policies.

The SEA that is chosen as the default adapter has the same network VLAN as the new network. If a SEA with the same VLAN does not exist, IBM PowerVC chooses as the default the SEA with the lowest primary VLAN ID Port Virtual LAN Identifier (PVID) that is in an available state.

Certain configurations might ensure the assignment of a particular SEA to a network. For example, if the VLAN that you choose when you create a network in IBM PowerVC is the PVID of the SEA or one of the additional VLANs of the primary Virtual Ethernet Adapter, that SEA must back the network. No other options are available. Plan more than one VIOS if you want a failover VIOS or expanded VIOS functions.

Tip: Systems that use multiple virtual switches are supported. If a network is modified to use a different SEA and that existing VLAN is deployed by other networks, those other networks move to the new adapter as well. To split a single VLAN across multiple SEAs, break those SEAs into separate virtual switches. IBM PowerVC supports the use of virtual switches in the system. Use multiple virtual switches when you want to separate a single VLAN across multiple distinct physical networks.

If you create a network, deploy VMs to use it, and then change the SEA to which that network is mapped (your workloads are affected). The network experience a short outage while the reconfiguration takes place.

In environments with dual VIOSs, the secondary SEA is not shown except as an attribute on the primary SEA.

Note: If VLANs are added to SEA adapters and to VIOS profiles after the host is brought into management of IBM PowerVC, the new VLAN is not automatically discovered by IBM PowerVC. To discover a newly added VLAN, run the Verify Environment function in the IBM PowerVC system.

Table 2-13 is a table of suggestions for when you create and use SEAs. The use of SEAs is a preferred practice.

Table 2-13 Preferred practices for Shared Ethernet Adapter

Type of deployment

High availability mode auto

High availability mode sharing

New host

SEA creation with one VEA. Do not put any VLANs on the VEA.

SEA creation with two VEAs. Do not put any VLANs on the VEAs.

Existing host (Keep the numbering convention.)

Set automated_powervm_vlan_cleanup of nova-*.conf to False.

Set automated_automated_powervm_vlan_cleanup of nova-*.conf to False.

Existing host (Let IBM PowerVC manage the numbering of the adapters.)

Do nothing.

Do nothing.

2.7.4 Planning Single Root I/O Virtualization networks

On PowerVM NovaLink managed systems, you can deploy VMs that leverage Single Root Input / Output Virtualization (SR-IOV). SR-IOV supports pass-through of Ethernet data from guest VMs directly to hardware, which improves performance by allowing data to pass directly from guest VMs to physical adapters with minimal processing between, allowing a guest VM to achieve near wire-speed Ethernet performance. SR-IOV also supports some additional configuration options, such as quality of service (QoS) for enforcing bandwidth allocations to guest VMs.

SR-IOV adapters have multiple physical ports, one for each Ethernet cable. Each physical port is divided into logical ports that are called Virtual Functions. A logical port provides a connection from a VM to a physical Ethernet port. Each physical port has a set number of logical ports that is defined by the adapter firmware. For example, the IBM feature code EN0M SRIOV cards have four logical ports per 1-GB physical port and 20 logical ports per 10-GB physical port. When all of the logical ports on a physical port are used, no further VMs can use that physical port. SRIOV adapters can help improve performance because Ethernet traffic bypasses the VIOS and hypervisor, which saves CPU cycles.

Figure 2-22 Standard SR-IOV network design

As shown on Figure 2-22, IBM PowerVC can connect a VM that uses an SR-IOV adapter by using options 2, 3, or 4, depending on the specified redundancy levels. Users can implement option 1 outside of IBM PowerVC by carving a virtual function out of a physical port and assigning it as a backing networking device for a SEA. PowerVC treats that SEA the same as any other SEA, regardless of the backing device.

SR-IOV versus share Ethernet adapter

It is important to understand the differences between SR-IOV and SEA. In PowerVC, without SR-IOV, you have an SEA and a virtual Ethernet adapter on the VIOS. These adapters connect to a physical network adapter and to a client network adapter on the VM. This setup allows you to segment your network through VLAN IDs and helps you virtualize your network hardware, providing migration and failover support. An SEA environment also supports higher VM density. However, all network traffic is routed through the SEA on the VIOS, which adds processing cycles.

SR-IOV with vNIC provides a separation of the control plane and data plane for Ethernet within a host. Therefore, an SR-IOV environment performs better because the VIOS is used to set up and manage only the communication channel and provide failover and migration support. SR-IOV does not scale to hundreds or thousands of VMs per host. Instead, it is used to set up a few very fast VMs.

Note: You can use VLAN IDs to segment your network whether you are using SR-IOV or SEA, but VMs cannot be migrated in an SR-IOV environment.

Redundancy support

When deploying a VM that uses SR-IOV networks, IBM PowerVC creates a vNIC adapter for that VM. If you select Redundant adapter when deploying a VM, the vNIC adapter that is created for the VM includes multiple logical ports. These logical ports are isolated as much as possible to provide redundancy by using multiple physical ports, multiple SR-IOV adapters (if possible), and multiple VIOSs (if possible).

Quality of Service

When you create an SR-IOV network, you can use the Virtual NIC capacity field to specify the minimum bandwidth of the network. If that capacity is not available when deploying a VM, the deployment is not allowed.

SR-IOV requirements for IBM PowerVC

There are specific requirements to meet to plan and deploy SR-IOV:

•POWER8 or later systems, including:

 – Power E850 (8408-E8E): Any PCI slot.

 – Power S822 or S822L (8284-22A, 8247-22L): Seven slots with both sockets populated (C2, C3, C5, C6, C7, C10, and C12), four slots if one (C6, C7, C10, and C12).

 – Power S824 S824L (8286-42A, 8247-42L): Eight slots with both sockets populated (C2, C3, C4, C5, C6, C7, C10, and C12), four slots if one (C6, C7, C10, and C12).

 – Power S814 or S812L (8286-41A, 8247-21L): Four slots (C6, C7, C10, and C12).

 – Power E870 (9119-MME): Any system node slot.

 – Power E880 (9119-MHE): Any system node slot.

 – PCIe Gen3 I/O expansion drawer slots C1, and C4 of the 6-slot Fan-out module.

•PowerVM NovaLink

•SR-IOV capable I/O adapters (see Table 2-14)

Table 2-14 Required adapter models (feature codes) to use in SR-IOV deployments

Adapter

Logical ports per adapter¹

Low profile multiple OS

Full high multiple OS

Low profile Linux only

Full high Linux only

PCIe3 4-port (10 Gb FCoE and 1 GbE) SR optical fiber and RJ45

48 20/20/4/4

#EN0J²

#EN0H³

#EL38

#EL56

PCIe3 4-port (10 Gb FCoE and 1 GbE) SFP + copper twinax and RJ45

48 20/20/4/4

#EN0Lb

#EN0Kc

#EL3C

#EL57

PCIe3 4-port (10 Gb FCoE and 1 GbE) LR optical fiber and RJ45

48 20/20/4/4

#EN0N

#EN0M

N/A

N/A

PCIe3 4-port 10 GbE SR optical fiber

64 16/16/16/16

#EN16⁴

#EN15

N/A

N/A

PCIe3 4-port 10 GbE copper twinax

64 16/16/16/16

#EN18d

#EN17

N/A

N/A

¹ This column provides the total logical ports per adapter followed by the number of logical ports that are available for each physical port.

² SR-IOV announced February 2015 for Power E870/E880 system node is now available on all POWER servers.

³ SR-IOV announced April 2014 for Power 770/780/ESE system node. With April 2015 announcement, it is available on all POWER8 servers.

⁴ The adapter is only available for Power E870/E880 system node, not a 2U server.

Note: The second column in Table 2-14 on page 58 provides the total logical ports per adapter followed by the number of logical ports that are available for each physical port.

Tip: The adapter must be in SRIOV mode. Run the pvmctl sriov command on the NovaLink partition to view and update the adapter mode.

•Here are the minimum operating system supported levels:

 – PowerVM 2.2.4:

 • VIOS Version 2.2.4.

 • System Firmware Release 840.

 • IBM Power System E850 (8408-E8E) requires system firmware 840.10.

 – For full function including redundancy, firmware level 850 is recommended.

 – Operating systems:

 • AIX 7.1 TL4 or AIX 7.2.

 • IBM i 7.1 TR10 or IBM i 7.2 TR3 or IBM i 7.3.

Consideration for IBM PowerVC

Consider the following items when you plan to use SR-IOV:

•LPM is not supported at the time of writing. Therefore, functions that rely on migration are not supported, including the following ones:

 – Manual migration

 – DRO (CoD operations are supported in available environments.)

 – Host maintenance mode evacuation

 – Remote restart

•HMC managed VMs are not supported. When attempting to manage VMs from an HMC managed host, any SR-IOV attached VMs are listed as unsupported.

•You cannot directly connect the SR-IOV logical port to a VM.

Deploying, managing, and unmanaging virtual machines

The following tasks take place when you manage or unmanage a VM that uses an SR-IOV adapter in PowerVC:

•When a VM is deployed with an SR-IOV interface, or if an SR-IOV network is attached to an existing VM, one or two vNICs are set up on the relevant VIOSs, depending on whether Redundant adapter was selected. That vNIC is attached to an SR-IOV physical port through newly created logical ports on one side and the vNIC client adapter in a deployed VM.

•If a VM that uses an SR-IOV network interface is deleted, the corresponding vNICs are removed from VIOS and the SR-IOV logical ports are released.

•You can manage preexisting VMs with SR-IOV adapters on NovaLink managed hosts. If such a VM is brought under IBM PowerVC management, neutron ports are created in PowerVC and attached to the VM.

•If a VM with an SR-IOV interface is unmanaged, the VM is retained by PowerVM, and the corresponding neutron port is retained in IBM PowerVC, but is released from use. If the same VM is brought under IBM PowerVC management again, the same port is used, with the same IP address.

Before detaching an SR-IOV attached VM, see IBM Knowledge Center for instructions:

http://www.ibm.com/support/knowledgecenter/POWER8/p8hat/p8hat_dlpariopmovep6.htm

2.8 Planning users and groups

The following sections describe the planning that is required for users and groups.

2.8.1 User management planning

When you install IBM PowerVC, it is configured to use the security features of the operating system on the management host by default. This configuration sets the root operating system user account as the only initially available account with access to the IBM PowerVC server.

As a preferred practice, create at least one system administrator user account to replace the root user account as the IBM PowerVC management administrator. For more information, see 4.16.1, “Adding user accounts” on page 181. After a new administrator ID is defined, remove the IBM PowerVC administrator rights from the root user ID, as explained in 4.16.3, “Disabling the root user account from IBM PowerVC” on page 183.

Important: IBM PowerVC also requires user IDs that are defined in /etc/passwd that must not be modified, such as nova, neutron, keystone, and cinder. All of these users use OpenStack and they must not be changed or deleted.

For security purposes, you cannot connect remotely to these user IDs. These users are configured for no login.

User account planning is important to define standard accounts and the process and requirements for managing these accounts. An IBM PowerVC management host can take advantage of user accounts that are managed by the Linux operating system security tools or can be configured to use the services that are provided by LDAP.

2.8.2 Projects and role management planning

This section describes the settings that are required for each user and group to operate and perform actions and work with projects.

Managing projects

A project, sometimes referred to as a tenant, is a unit of ownership. VMs, volumes, images, and networks belong to a specific project. Only users with a role assignment for a given project can work with the resources belonging to that project. At the time of installation, the ibm-default project is created, but IBM PowerVC also supports the creation of more projects for resource segregation.

You can use the openstack project command to manage projects as needed. As a OpenStack administrator, you can create, delete, list, set, and show projects:

•Create a project by running the following command:

openstack project create project-name

•Delete an existing project by running the following command:

openstack project delete project-name

•List projects by running the following command:

openstack project list

•Set project properties (name, or description) by running the following commands:

openstack project set --name <name> project-name

openstack project set --description <description> project-name

•Display project details by running the following command:

openstack project show project-name

After you create a project, you must grant at least one user a role on that project.

Managing roles

Roles are assigned to a user or group, in which case they are inherited by all users in that group. A user or group can have more than one role, in which case they can perform any action that at least one of their roles allows.

Roles are used to specify what actions users can perform. Table 2-15 shows the available roles and actions each role is allowed to perform.

Table 2-15 IBM PowerVC security roles

Role

Action

admin

Users with this role can perform all tasks and have access to all resources.

deployer

Users with this role can perform all tasks except the following ones:

•Adding, updating, or deleting storage systems or fabrics

•Adding, updating, or deleting hosts or host groups

•Adding, updating, and deleting networks

•Adding, updating, and deleting storage templates

•Adding and removing existing VMs to be managed by IBM PowerVC

•Adding and removing existing volumes to be managed by IBM PowerVC

•Updating FC port configuration

•Viewing users and groups

This role is deprecated for future removal.

viewer

Users with this role can view resources and the properties of resources, but can perform no tasks. They cannot view users and groups.

vm_manager

Users with this role can perform the following tasks:

•Deploy, delete, resize a virtual machine

•Control the running state of a virutal machine

•Attach and detach a network to or from a virtual machine

•Editing the details of a deployed virtual machine

•Viewing all resources except users and groups

storage_manager

Users with this role can perform the following tasks:

•Creating, deleting, or resizing a volume

•Viewing all resources except users and groups

image_manager

Users with this role can perform the following tasks:

•Capturing, importing, or deleting an image

•Editing description of an image

•Viewing all resources except users and groups

deployer_restricted

Users with this role can perform the following tasks:

•Deploying a VM from an image

•Viewing all resources except users and groups

vm_user

Users with this role can perform the following tasks:

•Starting, stopping, or restarting a VM

•Viewing all resources except users and groups

self_service

The actual abilities that a user with self_service can perform depends on the project policies that are set by the project administrator. Project policies specify what users are allowed to do and whether administrator approval is required for each action. In general, self_service authority allows the following actions:

•Managing VMs that are owned by that user, including capturing them and performing lifecycle operations on them

•Deploying VMs by using a deploy template

•Reviewing and withdrawing action requests

•Viewing the user’s metering data

This role is specific to IBM Cloud PowerVC Manager, and does not otherwise appear.

For example, a user has the vm_manager and storage_manager roles on one project and the viewer role on another project. Users can log in to only one project at a time in the IBM PowerVC user interface. If they have a role on multiple projects, they can switch to one of those other projects without having to log out and log back in. When users log in to a project, they see only resources, messages, and so on, that belong to that project. They cannot see or manage resources that belong to a project where they have no role assignment. There is one exception to this rule, which is that the admin role can operate across projects in many cases. Be mindful of this when handing out admin role assignments.

Important: OpenStack does not support moving resources from one project to another project. You can move volumes by unmanaging them and then remanaging them in the new project, but it is not possible to perform the same action for VMs because the network on which that VM depends is tied to the original project.

Note: OpenStack’s image and networking services support sharing between multiple projects, but IBM PowerVC Version 1.3.2 does not support this situation. If you use REST APIs, be aware of this and do not mark images or networks as shared.

2.9 Security management planning

IBM PowerVC provides security services that support a secure environment and, in particular, the following security features:

•LDAP support for authentication and authorization information (users and groups).

•The IBM PowerVC Apache web server is configured to use secured HTTPS protocol. Only Transport Layer Security (TLS) 1.2 is supported.

•Host key and certificate verification of hosts, storage, and switches.

•Audit logs, which are recorded and available if you have enabled auditing.

2.9.1 Ports that are used by IBM Power Virtualization Center

The set of ports differs with the IBM PowerVC editions (PowerVM and PowerKVM).

Information about the ports that are used by IBM PowerVC management hosts for inbound and outbound traffic is on the following IBM Knowledge Center websites:

•IBM Cloud PowerVC Manger, for managing IBM PowerVC:

http://www.ibm.com/support/knowledgecenter/SSVSPA_1.3.1/com.ibm.powervc.cloud.help.doc/powervc_planning_security_firewall_cloud.html

•IBM PowerVC Standard Edition, for managing PowerVM:

http://www.ibm.com/support/knowledgecenter/SSXK2N_1.3.2/com.ibm.powervc.standard.help.doc/powervc_planning_security_firewall_hmc.html

•IBM PowerVC Standard Edition, for managing PowerKVM:

http://www.ibm.com/support/knowledgecenter/SSXK2N_1.3.2/com.ibm.powervc.kvm.help.doc/powervc_planning_security_firewall_kvm.html

Important: If a firewall is configured on the management host, ensure that all ports that are listed on the associated IBM Knowledge Center website are open.

Important: The installation process no longer automatically disables the firewall on the management host. You must now specify that option during the installation. As a preferred practice, configure the firewall yourself.

2.9.2 Providing a certificate

An IBM PowerVC management host is installed with a default self-signed certificate and a key. IBM PowerVC can also use certificate authority (CA)-signed certificates.

Self-signed certificates are certificates that you create for private use. After you create a self-signed certificate, you can use it immediately. Because anyone can create self-signed certificates, they are not considered publicly trusted certificates. You can replace default, expired, or corrupted certificates with a new certificate. You can also replace the default certificate with certificates that are requested from a CA.

The certificates are installed in the following locations:

•/etc/pki/tls/certs/powervc.crt

•/etc/pki/tls/private/powervc.key

Clients can replace libvirt certificates for PowerKVM installations.

The process to replace the certificates is described in the following IBM Knowledge Center websites:

•IBM PowerVC Standard Managing PowerVM:

http://www.ibm.com/support/knowledgecenter/SSXK2N_1.3.2/com.ibm.powervc.standard.help.doc/powervc_certificate_hmc.html

•IBM PowerVC Standard Managing PowerKVM:

http://www.ibm.com/support/knowledgecenter/SSXK2N_1.3.2/com.ibm.powervc.kvm.help.doc/powervc_rsyslog_cert_kvm.html

http://www.ibm.com/support/knowledgecenter/SSXK2N_1.3.2/com.ibm.powervc.kvm.help.doc/powervc_certificate_kvm.html

2.10 Product information

For more planning information, see the following resources.

Direct customer support

For technical support or assistance, contact your IBM representative or go to the IBM Support website:

http://www.ibm.com/support

Packaging

The IBM PowerVC Editions contain a DVD that includes product installation documentation and files. Your Proof of Entitlement (PoE) for this program is a copy of a paid sales receipt, purchase order, invoice, or other sales record from IBM or its authorized reseller from whom you acquired the program, provided that it states the license charge unit (the characteristics of intended use of the program, number of processors, and number of users) and quantity that was acquired.

It is possible to obtain the electronic version of PoE at the Entitled Systems Support website:

https://www.ibm.com/servers/eserver/ess/ProtectedServlet.wss

Click My entitled software in the left pane, and then click My entitled software.

Software maintenance

This software license offers Software Maintenance, which was previously referred to as Software Subscription and Technical Support.

Processor core (or processor)

Processor core (or processor) is a unit of measure by which the program can be licensed. Processor core (or processor) is a functional unit within a computing device that interprets and runs instructions. A processor core consists of at least an instruction control unit and one or more arithmetic or logic units. With multi-core technology, each core is considered a processor core. Entitlements must be acquired for all activated processor cores that are available for use on the server.

In addition to the entitlements that are required for the program directly, the license must obtain entitlements for this program that are sufficient to cover the processor cores that are managed by program.

A PoE must be acquired for all activated processor cores that are available for use on the server. Authorization for IBM PowerVC is based on the total number of activated processors on the machines that are running the program and the activated processors on the machines that are managed by the program.

Licensing

The IBM International Program License Agreement, including the License Information document and PoE, governs your use of the program. PoEs are required for all authorized use.

This software license includes Software Subscription and Support (also referred to as Software Maintenance).

IBM PowerVC installation

This chapter explains the IBM Power Virtualization Center (IBM PowerVC) Standard Edition and IBM Cloud PowerVC Manager installation.

It covers the following topics:

•3.1, “Setting up the IBM PowerVC environment” on page 68

•3.2, “Installing IBM PowerVC” on page 71

•3.3, “Uninstalling IBM PowerVC” on page 75

•3.4, “Upgrading IBM PowerVC” on page 76

•3.5, “Updating IBM PowerVC” on page 81

•3.6, “IBM PowerVC backup and recovery” on page 82

•3.7, “IBM PowerVC command-line interface” on page 86

•3.8, “Virtual machines that are managed by IBM PowerVC” on page 88

3.1 Setting up the IBM PowerVC environment

IBM PowerVC Version 1.3.2 can be installed on Red Hat Enterprise Linux (RHEL) Version 7.1 or later, either on the ppc64, ppc64le, or x86_64 platform.

Note: Unlike the Hardware Management Console (HMC), IBM PowerVC is not a stand-alone appliance. It must be installed on an operating system. On Power Systems hardware, there is the option of RHEL Little Endian or RHEL Big Endian; both are supported. The general trend is moving toward Little Endian. You must have a valid Linux license to use the operating system and a valid license to use IBM PowerVC.

Before you install IBM PowerVC, install RHEL on the management virtual machine (VM) or management host. IBM PowerVC requires several additional packages to be installed. These packages are automatically installed if you have a valid Linux repository. If you must manually install these packages, see “Installing Red Hat Enterprise Linux on the management server or host” in the IBM PowerVC Standard Edition section of IBM Knowledge Center:

https://ibm.biz/Bd4A59

Important: The management VM must be dedicated to IBM PowerVC and the operating system on which it runs. Do not install other software on it.

To set up the management hosts, complete the following tasks:

1. Create the VM (only if you plan to install IBM PowerVC in a virtualized server).

2. Install RHEL Server 7.1 or later on the management host.

3. Customize RHEL Server to meet the IBM PowerVC requirements.

3.1.1 Creating the virtual machine to host IBM PowerVC

IBM PowerVC can be installed on a VM running on an IBM Power System or on x86_64 platform. To install the management VM on a platform that matches your needs, select one of the following methods:

•Install the management VM on the IBM Power Systems platform by completing the following steps:

a. Create the VM by using the HMC:

i. In the navigation pane, open Systems Management and click Servers.

ii. In the work pane, select the managed system, click Tasks, and click Configuration → Create Partition.

iii. Follow the steps in the Create Partition wizard to create a logical partition (LPAR) and partition profile.

b. Create the VM by using PowerKVM:

To create the management VM on a PowerKVM host, you can use one of the following options:

 • A command-line utility that is called virsh.

 • An HTML-based management tool that is called Kimchi.

Both tools are provided with PowerKVM.

Important: IBM PowerVC does not support dual management by both IBM PowerVC and Kimchi after IBM PowerVC is installed.

•Create the management VM on an x86_64 machine:

To create the management VM on an x86_64 server, follow the instructions for your server.

After the VM is created, you must install the operating system into the management VM.

3.1.2 Downloading and installing Red Hat Enterprise Linux

As part of the IBM PowerVC setup, you must download and install RHEL, so you need a valid license and a valid copy of the software. IBM PowerVC is not a stand-alone appliance. It is installed on top of the operating system, but it does not include the license to use RHEL.

You can get the software and a valid license from the Red Hat website:

http://www.redhat.com

Install RHEL by using your preferred method. For more information, see the Red Hat Enterprise Linux 7 Installation Guide, found at:

https://ibm.biz/BdXKQ4

Note: After the installation finishes, do not add any other packages to the server. If any other packages are needed by IBM PowerVC, the additional packages are obtained by the IBM PowerVC installer automatically.

Important: IBM Installation Toolkit for Linux must not be installed on the IBM PowerVC management host.

3.1.3 Customizing Red Hat Enterprise Linux

Before you install IBM PowerVC, customize RHEL to meet the following IBM PowerVC requirements:

•Configuring the network

The first task before you install IBM PowerVC is to configure the network. IBM PowerVC uses the default network interface eth0. To use a different network interface, such as eth1, set the HOST_INTERFACE environment variable before you run the installation script. The following example shows the setting:

export HOST_INTERFACE=eth1

•Setting the Domain Name Server and host name

Two options exist for managing name resolution: Either use DNS or use the /etc/hosts file. You must pay attention to the correct setting of the name resolution of all components that are managed by IBM PowerVC.

 – If you do not plan to use DNS for host name resolution, ensure that all hardware components (including virtualized components) are correctly defined in the /etc/hosts file.

 – If you plan to use DNS for host name resolution, all hardware components must be defined correctly in your DNS. In addition, you must enable forward and reverse resolution. Host names must be consistent within the whole IBM PowerVC domain.

Important: Regardless of the host name resolution method that you use, the
IBM PowerVC management host must be configured with a valid, fully qualified domain name.

•Configuring the YUM repository for the IBM PowerVC installation

To successfully install IBM PowerVC, your system must be subscribed to the main server Red Hat Network (RHN) channel and the Optional Software RHN channel. You most likely must add this channel to your subscription as it is not included by default. Complete the following steps:

a. Configure the YUM repository by selecting and adding the new channel for Optional Software by running the following command:

rhn-channel -a -c rhel-ppc64-server-optional-7 -u <user name> -p <password>

a. Verify that YUM is seeing the new optional repository file by running the following command:

yum repolist

Important: A list of packages that must not be installed on the server before you start the IBM PowerVC installation is available in the Knowledge Center. For information about the packages’ requirements and restrictions, see IBM Knowledge Center:

https://ibm.biz/Bd4A59

The RHEL 7.1 OS media does not contain all the packages that are required by IBM PowerVC. You can download the packages that are required by IBM PowerVC from the Optional Software channel by using the RHN subscription. On RHEL 7.1, some base installation packages must be upgraded during the installation. These updated packages are available in the Base channel. RHEL 7.2 and above contains the packages that are needed for IBM PowerVC. Table 3-1 lists the package prerequisites for the IBM PowerVC installation.

Table 3-1 RHEL packages that relate to IBM PowerVC

RHEL for IBM Power (ppc64 and ppc64le)

RHEL x86_64

python-zope-interface

python-zope-interface

python-jinja2

python-jinja2

python-pyasn1

python-pyasn1-modules

python-pyasn1-modules

python-webob

python-webob

python-webtest

python-webtest

python-libguestfs

SOAPpy

SOAPpy

pyserial

pyserial

python-fpconst

python-fpconst

python-twisted-core

python-twisted-core

python-twisted-web

python-twisted-web

For information about how to add the optional repositories, see this website:

http://red.ht/1FSNvif

3.2 Installing IBM PowerVC

This section describes how to install IBM PowerVC on your management host by using .tar files that are obtained from the download site.

Before you install IBM PowerVC, ensure that all of the hardware and software prerequisites are met and that your environment is configured correctly. If you need further information, see 2.1.1, “Hardware and software requirements” on page 14. Also, ensure that you prepared the management host and installed the supported version of RHEL Server on it.

Important: The management VM is dedicated for IBM PowerVC and the operating system on which it runs. Do not install other software onto it.

To download and install IBM PowerVC, complete the following steps:

1. To begin the installation, open a web browser and go to the Entitled Software Support website:

http://www.ibm.com/servers/eserver/ess/OpenServlet.wss

2. Sign in with your IBM ID.

3. Click Software downloads.

4. Select the Power (AIX) brand.

5. Select the customer number that you want to work with, and click Continue.

6. Select the edition of IBM PowerVC that you purchased under 5692-A6P, and click Continue.

7. Download either the PPC64, PPC64LE, or the x86_64 .tar file.

Note: If your web ID is not yet registered with a customer number, click Register Customer ID number. If you are the first web ID to register your customer number, you become the primary ID. However, if you are not the first web ID, you are forwarded to the primary contact, who must approve your web ID.

8. After you download the .tar file, extract it to the location from which you want to run the installation script.

9. Change your current directory to the directory where the files were extracted.

10. Run the prerequisite check and confirm that all prerequisites are met for installation, as shown in Example 3-1. Correct any errors before proceeding with the installation.

Example 3-1 Install prerequisites verification

# ./install -t

Checking available memory

At least 10 GB of physical memory is recommended.

Checking CPU speed

Checking file size limit of the file system.

Current maximum file size : unlimited

/etc directory has the user/group as root/root required for installation

/opt directory has the user/group as root/root required for installation

/var directory has the user/group as root/root required for installation

/tmp directory has the user/group as root/root required for installation

Checking disk space

...

Output truncated

...

All RPM prereq requirements are met

11. Start the installation by running the installation script. Table 3-2 shows options to use with the IBM PowerVC install command.

./install

Table 3-2 Options for the IBM PowerVC install command

Option

Description

-c firewall

The firewall configuration is performed during installation. Unless this option is specified, admin must manually configure the firewall per the documentation. This option is used with silent installations to tell the installer to configure the firewall automatically during the installation. If this option is not defined with the silent installation option -s, the firewall is not configured during the installation.

-p <mode>

Enable preview mode. Supported values are sdn. For more information about SDN, see “Useful software-defined network commands (technical preview only)” on page 264.

-s <offering>

Runs a silent installation. This option requires that the offering value is set to 'standard', powerkvm' or 'cloud_powervm'.

-t

Runs the prerequisite checks and exits.

-u

Uninstalls to attempt to clean up after a failed installation, and then exits.

-f

Forces the installation to override or bypass certain checks. This option is used with the uninstall option to bypass failures during the uninstallation.

-n

The following values are valid:

•preferipv4 (default). This option is the default for the IBM PowerVC installation. Select this option to install IBM PowerVC by using the IPv4 IP address. If the IPv4 address is unavailable, the installation uses the IPv6 IP address.

•preferipv6. Select this option to install IBM PowerVC by using the IPv6 IP address. If the IPv6 address is unavailable, the installation uses the IPv4 IP address.

•requireipv4. Select this option to install IBM PowerVC by using the IPv4 IP address only. If the IPv4 IP address is unavailable, the installation fails.

•requireipv6. Select this option to install IBM PowerVC by using the IPv6 IP address only. If the IPv6 IP address is unavailable, the installation fails.

-h

Displays the help messages and exits.

12. Select the IBM PowerVC offering to install from the following two options:

 – 1 - IBM PowerVC Standard

 – 2 - IBM Cloud PowerVC Manager

13. Accept the Licence Agreement.

14. Select the edition to install from the following two options (this selection is shown only if IBM PowerVC Standard is being installed because IBM Cloud PowerVC Manager does not support PowerKVM):

 – 1 - Standard managing PowerVM

 – 2 - Standard managing PowerKVM

15. Select whether the IBM PowerVC installer should configure the IBM PowerVC host fire wall during the installation.

Note: If the fire wall is not automatically configured during the installation of IBM PowerVC, it must be configured manually after the installation. For required inbound and outbound ports, see IBM Knowledge Center:

https://ibm.biz/Bd4A53

16. After the installation completes, you see a message similar to Example 3-2. Ensure that you download and install any fix packs that are available from Fix Central, as described in 3.5, “Updating IBM PowerVC” on page 81.

Example 3-2 Installation completed

************************************************************

PowerVC installation successfully completed at 2016-11-10T11:33:18-06:00.

Refer to

/opt/ibm/powervc/log/powervc_install_2016-11-10-110506.log

for more details.

Use a web browser to access IBM PowerVC at

https://system_ip_address

Firewall configuration may be required to use PowerVC.

Refer to the Knowledge Center topic 'Ports used by PowerVC'.

************************************************************

Note: The installation logs can be found under /opt/ibm/powervc/log/.

If the installation does not complete successfully, run the following command to remove the files that were created during the failed installation before you reinstall IBM PowerVC:

[IBM PowerVC_install_file_folder]/install -u -f

Note: Use this command only to remove files from a failed installation. If you must uninstall a working instance of IBM PowerVC, run the uninstall command. For more information, see 3.3, “Uninstalling IBM PowerVC” on page 75.

The installation script creates the required IBM PowerVC users and groups, as shown in Table 3-3.

Table 3-3 IBM PowerVC Users

User

Description

mysql

MariaDB Server user

apache

Apache Server user

saslauth

Saslauthd user

radvd

radvd user

unbound

Unbound DNS resolver

memcached

Memcached daemon

egoadmin

IBM EGO Daemons

epmd

Erlang Port Mapper Daemon

swift

OpenStack Swift Daemons

cinder

OpenStack Cinder Daemons

neutron

OpenStack Neutron Daemons

nova

OpenStack Nova Daemons

ceilometer

OpenStack ceilometer Daemons

glance

OpenStack Glance Daemons

keystone

OpenStack Keystone Daemon

rabbitmq

RabbitMQ messaging server

ttv-validation

IBM OpenStack Validator Daemons

clerk

IBM OpenStack SSK Daemons

After the installation completes, you can verify the status of IBM PowerVC services by running the powervc-services command, as shown in Example 3-3.

Example 3-3 The powervc-services command example

# powervc-services httpd status

● httpd.service - The Apache HTTP Server

Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)

Active: active (running) since Wed 2016-11-16 10:42:31 CST; 24h ago

Docs: man:httpd(8)

man:apachectl(8)

Main PID: 4323 (httpd)

Status: "Total requests: 202026; Current requests/sec: 2.4; Current traffic: 7.6KB/sec"

CGroup: /system.slice/httpd.service

...

Output truncated

...

● memcached.service - Memcached

Loaded: loaded (/usr/lib/systemd/system/memcached.service; enabled; vendor preset: disabled)

Active: active (running) since Wed 2016-11-16 10:42:07 CST; 24h ago

Main PID: 1753 (memcached)

CGroup: /system.slice/memcached.service

└─1753 /usr/bin/memcached -u memcached -p 11211 -m 64 -c 1024 -l localhost

IBM PowerVC commands are in /usr/bin and /opt/ibm/powervc/bin.

3.3 Uninstalling IBM PowerVC

The procedure to remove IBM PowerVC from the management host is described in this section. The uninstallation of IBM PowerVC does not remove or change anything in the environment that is managed by IBM PowerVC. Objects that were created with IBM PowerVC (VM, volumes, and so on) are unchanged by this process. Any RHEL prerequisite packages that are installed during the IBM PowerVC installation remain installed.

To uninstall IBM PowerVC, run the following command:

/opt/ibm/powervc/bin/powervc-uninstall

Example 3-4 shows the last few output lines of the uninstallation process.

Example 3-4 Uninstallation successful

IBM PowerVC uninstallation

Are you sure you want to uninstall? [1-Yes or 2-No]1

Preparing packages...

Stopping PowerVC services...

Shut down LIM on <powervc02> ...... done

Preparing... ########################################

Cleaning up / removing...

python-migrate-0.10.0-1.ibm.el7 ########################################

NOTE: The PowerVC iptables settings have not been removed

during uninstallation. The administrator should perform the necessary steps

to modify the firewall to the desired settings.

Refer to the Knowledge Center topic for firewall ports for necessary settings to remove.

Uninstallation of IBM PowerVC completed.

################################################################################

################################################################################

Ending the IBM PowerVC Uninstallation on:

2016-11-10T11:48:52-06:00

################################################################################

################################################################################

Uninstallation was logged in /var/log/powervc-uninstall.log

The uninstallation process writes its log to this file:

/var/log/powervc-uninstall.log

If you encounter issues when you run the powervc-uninstall command, you can clean up the environment by using the following command:

/opt/ibm/powervc/bin/powervc-uninstall -f

This command forces the uninstallation of all components of IBM PowerVC. For the complete list of available options with the powervc-uninstall command, see Table 3-4.

Table 3-4 Available options for the powervc-uninstall command

Option

Description

-f

Forcefully removes IBM PowerVC.

-l

Disables uninstallation logging. Logging is enabled by default.

-y

Uninstalls without prompting.

-s

Saves configuration files to an archive.

-h

Displays the help message and exits.

3.4 Upgrading IBM PowerVC

You can perform an in-place upgrade to IBM PowerVC Version 1.3.2 on RHEL 7.1 from
IBM PowerVC V1.3.0.x or V1.3.1.x and later versions. Upgrades to IBM PowerVC Version 1.3.2 from earlier versions or from different host systems are described in more detail in 3.4.3, “Upgrading or migrating from earlier versions” on page 79.

The currently installed version and offering can be verified either from the web interface or from the IBM PowerVC host command line.

To check the version from the IBM PowerVC management web interface, click Help → About, as shown in Figure 3-1.

Figure 3-1 IBM PowerVC version check

The IBM PowerVC version and offering that is installed is shown, as shown in Figure 3-2.

Figure 3-2 IBM PowerVC version

The installed IBM PowerVC version and offering type can be checked by the command line on the IBM PowerVC host, as shown in Example 3-5.

Example 3-5 Check the IBM PowerVC version from the command-line interface

# cat /opt/ibm/powervc/version.properties

[1.3.2.0 Install]

name = IBM PowerVC

version = 1.3.2.0

build = 20161109-1114

install-date = 2016-11-10

offering = standard

cloud_enabled = yes

3.4.1 Before you begin

Before you begin your software upgrade, complete the following tasks:

•Review the hardware and software requirements for IBM PowerVC Version 1.3.2.

•Ensure that all compute and storage hosts are running before you start the upgrade.

•Verify your environment before you start the upgrade to ensure that the upgrade process does not fail because of environmental issues.

•Ensure that no tasks, such as resizing, migrating, or deploying, are running on the VM when you start the upgrade. Any tasks that are running on the VM during the upgrade cause the VM to enter an error state after the upgrade is complete.

•Ensure that you manually copy any customized powervc.crt and powervc.key files from the previous version of IBM PowerVC to IBM PowerVC Version 1.3.2.

•Any operating system users from the Admin, Deployer, or Viewer groups on the previous version must be added again to the groups on the RHEL 7.1 system.

•If you are using PowerVM NovaLink, upgrade the pvm-novalink packages on the PowerVM NovaLink hosts to Version 1.0.0.4.

3.4.2 Performing in-place upgrade

An IBM PowerVC host running IBM PowerVC Version 1.2.3.1 or 1.3.0.1 or later can be upgraded to IBM PowerVC Version 1.3.2 in-place.

During the upgrade process to IBM PowerVC Version 1.3.2, the existing Standard installation can be upgraded to IBM Cloud PowerVC Manager offering or kept as the IBM PowerVC standard offering.

During an in-place upgrade, the IBM DB2® database that is used by previous versions is removed and data is migrated to the MariaDB database that is used by IBM PowerVC Version 1.3.1 and above.

Tip: Before you begin a migration of a large IBM PowerVC managed system, minimize (cleanup) the size of the DB2 ceilmometer DB to speed the database migration to MariaDB.

To perform an in-place upgrade, complete the following steps:

1. Obtain the IBM PowerVC Version 1.3.2 installation package for the current architecture.

2. Extract the installation package to the local file system of the IBM PowerVC host.

3. Go to the directory that contains the extracted installation script:

./install

4. Start the upgrade process, as shown in Example 3-6.

Example 3-6 IBM PowerVC upgrade to Version 1.3.2.0

[root@c566-IBM PowerVC2 powervc-1.3.2.0]# ./install

###############################################################################

Starting the IBM PowerVC 1.3.2.0 Installation on:

2016-11-18T23:48:43-04:00

###############################################################################

IBM PowerVC version 1.3.0.0 is installed.

Do you want to upgrade to version 1.3.2.0: 1-Yes or 2-No?

1

Would you like to enable IBM Cloud PowerVC Manager

for IBM PowerVC 1.3.2.0: 1-Yes or 2-No?

2

LOG file is /opt/ibm/powervc/log/powervc_install_2016-11-18-234843.log

Checking disk space

Checking file size limit of the file system.

Current maximum file size : unlimited

Extracting license content

International License Agreement for Early Release of

Programs

Part 1 - General Terms

Press Enter to continue viewing the license agreement, or

enter "1" to accept the agreement, "2" to decline it, "3"

to print it, "4" to read non-IBM terms, or "99" to go back

to the previous screen.

1

Do you want the IBM PowerVC setup to configure the firewall? 1-Yes or 2-No?

1

NOTE: The following list of system configurations will be modified as part of

installation.

/etc/passwd

/etc/sudoers

Continue with the installation: 1-Yes or 2-No?

1

The validation of IBM PowerVC Services post installation was successful.

************************************************************

IBM PowerVC installation successfully completed at 2016-11-19T00:30:07-04:00.

Refer to

/opt/ibm/powervc/log/powervc_install_2016-11-18-234843.log

for more details.

Use a web browser to access IBM PowerVC at

https://c566-powervc.pok.stglabs.ibm.com

************************************************************

5. During the upgrade to Version 1.3.2, the existing IBM PowerVC configuration data is preserved. If a selection was made during the upgrade to enable IBM Cloud PowerVC Manager, the offering is changed from IBM PowerVC Standard Edition to IBM Cloud PowerVC Manager. This option is available only for IBM PowerVC editions managing PowerVM environments.

3.4.3 Upgrading or migrating from earlier versions

This section provides methods to upgrade or migrate from earlier versions of IBM PowerVC.

Upgrading from earlier versions

To upgrade IBM PowerVC to Version 1.3.1 from versions earlier than Version 1.2.3.1 or Version 1.3.0.1, the following steps are required:

1. Review the hardware and software requirements for IBM PowerVC Version 1.3.1.

2. Obtain the IBM PowerVC Version 1.2.3.x or Version 1.3.0.x (where x is 1 or later) installation package for current architecture.

3. Upgrade the current IBM PowerVC installation to Version 1.2.3.x or 1.3.0.x (where x is 1 or later) on the current system.

4. Perform an in-place upgrade of IBM PowerVC to Version 1.3.1, as described in 3.4.2, “Performing in-place upgrade” on page 77.

Migrating from earlier versions

To upgrade IBM PowerVC and migrate the existing data on to a new host system, the following steps are required:

1. Go to the previous version of IBM PowerVC host system and run the following command:

/opt/ibm/powervc/bin/powervc-backup

2. Install a new IBM PowerVC host system OS and the prerequisite packages for the current IBM PowerVC version.

3. Install the same version of IBM PowerVC with the same architecture as the source system on to a new IBM PowerVC host system.

4. Shut down IBM PowerVC services on the existing IBM PowerVC host by running the following command:

/opt/ibm/powervc/bin/powervc-services all stop

5. Move the backup file from the old host system to the new IBM PowerVC host system.

6. Restore the original system data that was backed up in step 1 on to the new host system by running the following command:

/opt/ibm/powervc/bin/powervc-restore --targetdir [location of backup file from step 1]

7. Perform an in-place upgrade of IBM PowerVC, as described in 3.4.2, “Performing in-place upgrade” on page 77.

Notes:

•If you upgrade IBM PowerVC while the user interface is active, it tells you that it is set to maintenance mode and you cannot use it. After you run the powervc-restore command successfully, you can access the IBM PowerVC user interface again.

•If an error occurs when you run the powervc-backup command, check for errors in the powervc-restore logs in the /opt/ibm/powervc/log file. After you correct or resolve the issues, run the powervc-restore command again.

•If you want to install IBM PowerVC Version 1.3.1 on a system with RHEL 6.0 installed, complete the following steps:

a. Copy the backup archive to another system.

b. Uninstall RHEL 6.0.

c. Install RHEL 7.1 and then install the same IBM PowerVC version that the backup was made with on the new system.

d. Copy the backup archive to this system and restore the archive, as described in steps 5 on page 79 and 6 on page 79.

e. Perform an in-place upgrade of IBM PowerVC, as described in 3.4.2, “Performing in-place upgrade” on page 77.

Upgrading from the Standard to IBM Cloud PowerVC Manager offering

IBM PowerVC Version offers a feature called IBM Cloud PowerVC Manager. This offering is available only for installations managing PowerVM environments running IBM PowerVC Version 1.3.1 or later.

The IBM Cloud PowerVC Manager offering can be directly enabled during a new installation of IBM PowerVC or during an upgrade from previous versions of IBM PowerVC.

To enable the IBM Cloud PowerVC Manager offering on a system running IBM PowerVC Version 1.3.1 or later, complete the following steps:

1. Log in to the IBM PowerVC host as the root user.

2. Extract the IBM PowerVC Version 1.3.1 or later installation package and go to the cloud folder:

/powervc-1.3.2.0/cloud/

3. Start the IBM Cloud PowerVC Manager installation by running the following command. Example 3-7 shows the output of the command.

./install-cloud

Example 3-7 Enable the IBM Cloud PowerVC Manager offering

# ./install-cloud

################################################################################

Starting the IBM Cloud PowerVC Manager Installation on:

2016-11-10T:48:19-04:00

################################################################################

LOG file is /opt/ibm/powervc/log/powervc_cloudmanager_install_2016-11-10-120434.log

...

Output truncated

...

Complete!

Stopping IBM PowerVC services...

Shut down LIM on <c566-powervc2.pok.stglabs.ibm.com> ...... done

Starting IBM PowerVC services...

IBM Cloud PowerVC Manager installation successfully completed at 2016-05-19T:50:24-04:00.

Refer to

/opt/ibm/powervc/log/powervc_cloudmanager_install_2016-05-19-4819.log

for more details.

#

3.5 Updating IBM PowerVC

IBM PowerVC updates are published on the IBM Fix Central repository. Log in with your IBM ID at the following website to get the update package:

http://www.ibm.com/support/fixcentral

Complete the following steps:

1. Before you update IBM PowerVC, check that enough disk space is available.

Important: If /opt, /var, or /home are separate mount points, 2500 MB of installation space is required in /opt, 187 MB of free space is required in /var, and 3000 MB of free space is required in /home.

2. Download the package to a directory, extract the file, and run the update command. To extract the file, run this command:

tar -zxvf [location_path]/powervc-update-ppc-rhel-version.tgz

This command extracts the package in the current directory and creates a directory that is named powervc-version.

3. Run the update script by running the following command:

/[location_path]/powervc-[version]/update

When the update process is finished, it displays the message that is shown in Example 3-8.

Example 3-8 Update successfully completed

***************************************************************************

IBM PowerVC installation successfully completed at 2016-05-19T01:12:34-04:00.

Refer to

/opt/ibm/powervc/log/powervc_update_2016-05-19-012048.log

for more details.

***************************************************************************

3.6 IBM PowerVC backup and recovery

Consider backing up your IBM PowerVC data regularly as part of a broader system backup and recovery strategy. You can use the operating system scheduling tool to perform regular backups or any other automation tool.

Backup and recovery tasks can be performed only by using the command-line interface (CLI). No window is available to open in the graphical user interface (GUI) for backup and recovery.

3.6.1 Backing up IBM PowerVC

Run the powervc-backup command to back up your essential IBM PowerVC data. You can then restore it to a working state in case of a data corruption situation or disaster.

The powervc-backup command is in the /opt/ibm/powervc/bin/ directory. Here is the command syntax:

powervc-backup [-h] [--noprompt] [--targetdir LOCATION] [--active]

Table 3-5 lists the command options.

Table 3-5 Options for the powervc-backup command

Option

Description

-h, --help

Displays help information about the command.

--noprompt

If specified, no user intervention is required during the running of the backup process.

--targetdir LOCATION

The target location in which to save the backup archive. The default value is /var/opt/ibm/powervc/backups.

--active

If specified, the services are not stopped and the backup is performed as active. The backup might fail if operations are in-progress, so minimize activity during the backup interval and retry the backup as necessary.

The following data is backed up:

•IBM PowerVC databases, such as the Nova database where information about your registered hosts is stored

•IBM PowerVC configuration data, such as /etc/nova

•Secure Shell (SSH) private keys that are provided by the administrator

•Glance image repositories

Note: Glance is the OpenStack database name for the image repository.

Important: During a backup, most IBM PowerVC services are stopped, and all other users are logged off from IBM PowerVC until the operation completes.

The following example shows the command with a non-default mounted file system target directory. This command displays a prompt to confirm that you want to stop all the services. Type y to accept and continue, as shown in Example 3-9.

Example 3-9 Example of IBM PowerVC backup

# powervc-backup --targetdir /powervc/backup

Continuing with this operation will stop all PowerVC services. Do you want to continue? (y/N):y

Stopping PowerVC services...

Backing up the databases and data files...

Database and file backup completed. Backup data is in archive /powervc/backup/20161111161458869640/powervc_backup.tar.gz

Starting PowerVC services...

PowerVC backup completed successfully.

When the backup operation completes, a new time-stamped subdirectory is created in the target directory and a backup file is created in that subdirectory, for example:

/powervc/backup/20161111161458869640/powervc_backup.tar.gz

As a preferred practice, copy this file outside of the management host according to your organization’s backup and recovery guidelines.

Note: If an error occurs while you run the powervc-backup command, you can check the powervc-backup logs file in /opt/ibm/powervc/log.

3.6.2 Recovering IBM PowerVC data

Run the powervc-restore command to recover IBM PowerVC data that was previously backed up so that you can restore a working state after a data corruption situation or disaster.

You can restore a backup archive only to a system that is running the same level of IBM PowerVC and operating system (and hardware if the OS is running on a dedicated host rather than a VM) as the system from which the backup was taken. Ensure that the target system meets those requirements before you restore the data. IBM PowerVC checks this compatibility of the source platform and the target platform, as shown in Example 3-10.

Example 3-10 Mismatch between backup and recovery environments

Continuing with this operation will stop all IBM PowerVC services and overwrite critical IBM PowerVC data in both the database and the file system. Do you want to continue? (y/N):y

The backup archive is not compatible with either the restore system's architecture, operating system or IBM PowerVC Version. Exiting.

The backup process does not back up Secure Sockets Layer (SSL) certificates and associated configuration information. When you restore a IBM PowerVC environment, the SSL certificate and configuration remain the same SSL certificate and configuration that existed within the IBM PowerVC environment before the restore operation, not the SSL configuration of the environment from which the backup was taken.

The powervc-restore command is in the /opt/ibm/powervc/bin/ directory and has the following syntax and options:

powervc-restore [-h] [--noprompt] [--targetdir LOCATION]

Table 3-6 shows the powervc-uninstall command options.

Table 3-6 Options for the powervc-restore command

Option

Description

-h, --help

Shows the help message and exits.

--noprompt

If specified, no user intervention is required during the execution of the restore process.

--targetdir LOCATION

The target location where the backup archive is. The default value is /var/opt/ibm/powervc/backups/<most recent>.

Important: During the recovery, most IBM PowerVC services are stopped and all other users are logged off from IBM PowerVC until the operation completes.

The following example shows the command with a non-default target directory. This command displays a prompt to confirm that you want to stop all of the services. Type y to accept and continue (see Example 3-11).

Example 3-11 Example of IBM PowerVC recovery

#powervc-restore --targetdir /powervc/backup/20161111161458869640/

Continuing with this operation will stop all PowerVC services and overwrite critical PowerVC data in both the database and the file system. Do you want to continue? (y/N):y

Using archive /powervc/backup/20161111161458869640//powervc_backup.tar.gz for the restore.

Stopping PowerVC services...

Restoring the databases and data files...

Starting PowerVC services...

PowerVC restore completed successfully.

When the restore operation completes, IBM PowerVC runs with all of the data from the targeted backup file.

3.6.3 Status messages during backup and recovery

During the backup and recovery tasks, all IBM PowerVC processes and databases are shut down. Any user that is working with IBM PowerVC receives the maintenance message that is shown in Figure 3-3 and is logged out.

Figure 3-3 Maintenance message for logged-in users

Accessing IBM PowerVC during the backup and recovery tasks is not allowed. Any user that attempts to log on to IBM PowerVC receives the maintenance message that is shown in Figure 3-4.

Figure 3-4 Maintenance message for web users

3.6.4 Consideration about backup and recovery

The IBM PowerVC backup and recovery task must be part of a backup plan for your infrastructure. The IBM PowerVC backup and recovery commands save only information that relates to IBM PowerVC. As a preferred practice, save the management station operating systems by using the tool that you prefer at the same time that you back up IBM PowerVC.

3.7 IBM PowerVC command-line interface

IBM PowerVC offers a CLI to perform tasks outside of the GUI. The CLI is used mainly for maintenance and for troubleshooting problems.

Table 3-7 shows the IBM PowerVC commands that are available for the following versions:

•IBM PowerVC Standard Edition for managing PowerVM

•IBM Cloud PowerVC Manager

•IBM PowerVC Standard Edition for managing PowerKVM

Table 3-7 IBM PowerVC available commands

Command

Description

powervc-audit-export

Exports audit records to a specified file.

powervc-backup

Backs up essential IBM PowerVC data so that you can restore to a working state in case of a data corruption situation or disaster.

powervc-cloud-config

Allows an administrator to work with projects, policies, and VMs.

powervc-config

Facilitates IBM PowerVC management node configuration changes.

powervc-diag

Collects diagnostic data from your IBM PowerVC installation.

powervc-encrypt

Prompts the user for a string, then encrypts the string and returns it. Use the command to encrypt passwords, tokens, and strings that are stored by IBM PowerVC.

powervc-get-token

Authenticates and retrieves an identity token.

powervc-keystone

Avoids Lightweight Directory Access Protocol (LDAP) user group conflicts. You can also use this command to list users, user groups, and roles. This command is deprecated and is not supported for future releases.

powervc-ldap-config

Configures IBM PowerVC to work with an existing LDAP server. This command is deprecated and is not supported for future releases.

powervc-log-management

Provides a utility to view/modify the settings for log management.

powervc-register

Registers an OpenStack supported storage provider or fabric.

powervc-restore

Recovers IBM PowerVC data that was previously backed up.

powervc-services

Starts, stops, restarts, and views the status of IBM PowerVC services.

powervc-uninstall

Uninstalls IBM PowerVC from your management server or host.

powervc-validate

Validates that your environment meets certain hardware and software requirements.

powervc-volume-image-import

Creates a deployable image by using one or more volumes.

Table 3-8 shows the IBM PowerVC commands that are available for IBM PowerVC Standard for managing PowerKVM.

Table 3-8 Commands for IBM PowerVC Standard for managing PowerKVM

Command

Description

powervc-iso-import

Imports ISO images into IBM PowerVC.

powervc-log-management

Views and modifies the settings for log management for IBM PowerVC. The default action is to view the current settings.

powervc-register

Registers a storage provider that is supported by OpenStack.

Note: For an updated list of IBM PowerVC commands, see IBM Knowledge Center:

https://ibm.biz/BdXK37

3.7.1 Exporting audit data

IBM PowerVC provides auditing support for the OpenStack services. Use the powervc-audit-export command to export audit data to a specified file.

An audit record is a recording of characteristics, including user ID, time stamp, activity, and location, of each request that is made by IBM PowerVC.

Reviewing audit records is helpful when you are trying to solve problems or resolve errors. For example, if a host was deleted and you must determine the user who deleted it, the audit records show that information.

The powervc-audit-export command is in the /usr/bin directory. The syntax and options are shown in Example 3-12.

Example 3-12 The powervc-audit command use

powervc-audit-export [-h] [-u <user name>] [-n <number of records>] [-o <output file>] [-f <filter file>] [-x {json,csv}]

Table 3-9 explains the powervc-audit-export command options.

Table 3-9 Options for the powervvc-audit-export command

Option

Description

-h, --help

Displays help information about the command.

-u <user name>, --user_name <user name>

Sets the user that requests audit data. This flag is optional. The default is the logged-in user.

-p <project name>, --project_name <project name>

Sets the name of the project for which to authenticate and request audit data. This is an optional flag. The default is ibm-default.

-n <number of records>, --top_n <number of records>

Sets the upper limit for the number of audit records to return. The request and response audit records are returned in pairs. This flag is optional.

-o <output file>, --output <output file>

Sets the file that contains the exported audit data. This flag is optional. The default file is export_audit.json or export_audit.csv, depending on the specified output format.

-f <filter file>, --filter <filter file>

Sets the file that contains the filter records. The format of the records is JSON. For examples of filter records, see the IBM PowerVC IBM Knowledge Center. This flag is optional.

-x {text,csv}, --output_format {text,csv}

The format of the exported audit data. This flag is optional. The formats are text (JSON format) and csv. If not specified, the default is json.

3.8 Virtual machines that are managed by IBM PowerVC

This section provides preferred practices for the operating system on the managed VMs.

3.8.1 Linux on Power virtual machines

If you plan to use Logical Partition Mobility (LPM) or Dynamic Logical Partitioning with your Linux VM, you must install the IBM Installation Toolkit, especially the Reliable Scalable Cluster Technology (RSCT) utilities and RSCT core tools. Run the following command to start the IBM Installation Toolkit installation process:

[IBM Installation Toolkit directory]/install.sh

Follow the instructions. Example 3-13 shows the common installation output.

Example 3-13 IBM Installation Toolkit sample output

[root@linux01 mnt1]# ./install

Do you want to copy the repository of IBM packages to your machine? [y/n]

y

Do you want to configure your machine to receive updates of IBM packages? [y/n]

n

IBMIT needs the ports 4234 and 8080 to be accessed remotely. Would you like to open those ports? [y/n]

y

The licenses BSD, GPL, ILAN and MIT must be accepted. You can read their text using the options below and then accept or decline them.

1) Read license: BSD

2) Read license: GPL

3) Read license: ILAN

4) Read license: MIT

5) I have read and accept all the licenses

6) I do not accept any of the licenses

#? 5

Configuring an installation repository for your Linux distribution

Where is the installation media to be used?

1) DVD

2) Network (HTTP or FTP)

3) Directory

4) I already have a repository configured. Skip.

5) I don't know

#? 1

Insert the DVD in the drive

Press Enter to continue

Verifying if there is a repository on DVD

Available DVD devices: /dev/sr1 /dev/sr0

Checking /dev/sr1

Adding repository configuration to repository manager

Repository successfully configured

Package ibmit4linux was successfully installed

After you install the Installation Toolkit, install ibm-power-managed-rhel.ppc64 by running the following command:

yum install -y ibm-power-managed-rhel7.ppc64

After the installation completes, check the Resource Monitoring and Control (RMC) status by running the following command:

lssrc -a

The output appears as shown in Example 3-14.

Example 3-14 Resource Monitoring and Control status

Subsystem Group PID Status

ctrmc rsct 3916 active

IBM.DRM rsct_rm 3966 active

IBM.ServiceRM rsct_rm 4059 active

IBM.HostRM rsct_rm 4096 active

ctcas rsct inoperative

IBM.ERRM rsct_rm inoperative

IBM.AuditRM rsct_rm inoperative

IBM.SensorRM rsct_rm inoperative

IBM.MgmtDomainRM rsct_rm inoperative

For more information about the toolkit, including installation information, see the IBM Installation Toolkit for Linux on Power website:

https://www-304.ibm.com/webapp/set2/sas/f/lopdiags/installtools/home.html

3.8.2 IBM AIX virtual machines

To install VMs when your system runs on the IBM AIX operating system, no additional setup is necessary. After the IP address is configured, an RMC connection is automatically created.

Note: IBM PowerVC, PowerVM, and the HMC rely on the RMC services. When these services are down, most of the concurrent and dynamic tasks cannot be run. Check the RMC status every time that you must change the VM dynamically. For more information about RMC, see these IBM Redbooks publications:

•IBM PowerVM Virtualization Introduction and Configuration, SG24-7940

•IBM Power Systems HMC Implementation and Usage Guide, SG24-7491

Tip: By default, AIX does not contain SSH or SSL tools. As a preferred practice, install them if you want to access a managed machine with commands other than telnet.

3.8.3 IBM i virtual machines

IBM PowerVC can also manage the IBM i VMs. After you add the Power Systems hosts, import the IBM i VMs. No unique requirements exist for IBM i, AIX, or Linux on Power VMs.

IBM PowerVC for managing IBM PowerVM

This chapter describes the general setup of IBM Power Virtualization Center (IBM PowerVC) for managing IBM PowerVM. IBM PowerVC Version 1.3.2 has two offerings that can be installed called IBM PowerVC Standard Edition and IBM Cloud PowerVC Manager. This chapter describes the most notable differences between the IBM Cloud PowerVC Manager offering and IBM PowerVC Standard Edition as they appear throughout this chapter. The following sections explain the discovery or configuration of the managed objects. They describe the verification of the environment and the operations that can be performed on virtual machines (VMs) and images.

It covers the following topics:

•4.1, “IBM PowerVC graphical user interface” on page 92

•4.2, “Introduction to the IBM PowerVC setup” on page 93

•4.3, “Managing resources outside of IBM PowerVC” on page 94

•4.4, “Connecting to IBM PowerVC” on page 95

•4.5, “Host setup” on page 96

•4.6, “Hardware Management Console management” on page 106

•4.7, “Storage and SAN fabric setup” on page 108

•4.8, “Storage port tags setup” on page 114

•4.9, “Storage connectivity group setup” on page 115

•4.10, “Storage template setup” on page 119

•4.11, “Storage volume setup” on page 122

•4.12, “Network setup” on page 123

•4.13, “Compute template setup” on page 129

•4.14, “Environment verification” on page 131

•4.15, “Management of virtual machines and images” on page 134

•4.16, “Users, groups, and roles setup” on page 181

4.1 IBM PowerVC graphical user interface

This section presents the IBM PowerVC graphical user interface (GUI) and explains how to access functions from the IBM PowerVC home window. The management functions of IBM PowerVC are grouped by classes, which can be accessed from different locations. In all IBM PowerVC windows, you can find hot links to several areas and components:

•Environment configuration, messages, DRO events, and Project selection are found at the top of the IBM PowerVC window.

•Management functions that relate to VM images, VMs, hosts, networks, and storage are found in the column of icons at the left of the window (which also includes a link to the home window).

•The Requests management function is available only at the IBM Cloud PowerVC Manager offering home window.

The functions that are available differ between the IBM PowerVC offerings that are installed. The IBM PowerVC Standard Edition offering home window is shown in Figure 4-1. The hot links are highlighted in red in the illustration.

Figure 4-1 IBM PowerVC Standard Edition home window access to a group of functions

In all IBM PowerVC windows, most of the icons and text are hot links to groups of functions. Several ways exist to access a group of functions. The blue arrows in Figure 4-2 show, for example, the two hot links that can be used from the home window to access the VM management functions.

Figure 4-2 IBM Cloud PowerVC Manager home window access to a group of functions

4.2 Introduction to the IBM PowerVC setup

Before you can perform tasks in IBM PowerVC, you must discover and register the resources that you want to manage. You can register storage systems and hosts, and you can create networks to use when you deploy images. When you register resources with IBM PowerVC, you make them available to the management functions of IBM PowerVC (such as deploying a VM on a discovered host or storing images of captured VMs).

This discovery or registration mechanism is the key to the smooth deployment of
IBM PowerVC in an existing environment. For example, a host can host several partitions while you deploy IBM PowerVC. You first register the host without registering any of the hosted partitions. All IBM PowerVC functions that relate to host management are available to you, but no objects exist where you can apply the functions for managing partitions. You can then decide whether you want to manage all of the existing partitions with IBM PowerVC. If you prefer a progressive adoption plan instead, start by managing only a subset of these partitions.

Ensure that the following preliminary steps are complete before you proceed to 4.4, “Connecting to IBM PowerVC” on page 95:

1. Configure the IBM Power Systems environment to be managed through the Hardware Management Console (HMC) or PowerVM NovaLink.

2. Set up the users’ accounts with an administrator role on IBM PowerVC, as described in 2.8, “Planning users and groups” on page 60.

3. Set up the host name, IP address, and an operator user ID for the HMC or PowerVM NovaLink connection.

4.3 Managing resources outside of IBM PowerVC

When you switch from using IBM PowerVC to manage your resources to accessing the managed resource directly, you might see unexpected or adverse results in IBM PowerVC.

As you manage resources in IBM PowerVC, you might want to perform certain operations directly on the resource. For example, you are managing a VM with IBM PowerVC, but you use another method to stop the VM. In this case, IBM PowerVC might not be notified that the VM was stopped and might not immediately reflect the updated status of the VM. IBM PowerVC typically polls a resource to obtain an update the next time that you use IBM PowerVC to manage the resource. As a result, operations from IBM PowerVC might fail until the state of the VM in IBM PowerVC is the same as the state on the VM itself.

When you perform a management operation outside of IBM PowerVC, such as adding or deleting resources, the action can adversely affect the operation of IBM PowerVC and the data center. For example, you might delete a VM by using a Platform Manager for the VM. The VM goes into Error state and you must take the additional step of deleting the VM in IBM PowerVC. Similar results can occur when you remove a disk or network device for a VM that IBM PowerVC is managing.

For appropriate results, use IBM PowerVC to perform management tasks on the VMs and associated resources in your IBM PowerVC environment.

4.4 Connecting to IBM PowerVC

After IBM PowerVC is installed and started on a Linux partition, you can connect to the
IBM PowerVC management GUI by completing the following steps:

1. Open a web browser on your workstation and point it to the IBM PowerVC address:

https://<ipaddress or hostname>/

2. Log in to IBM PowerVC as an administrative user (Figure 4-3). The first time that you use IBM PowerVC, this administrative user is root. As a preferred practice, after the initial setup of IBM PowerVC, define other user IDs and passwords rather than using the root user. For more information about how to add, modify, or remove users, see 2.8.1, “User management planning” on page 60.

Figure 4-3 IBM PowerVC Login window

3. Now, you see the IBM PowerVC home window.

Important: Your environment must meet all of the hardware and software requirements and be configured correctly before you start to work with IBM PowerVC and register your resources.

4. As a preferred practice, your first action is to check the IBM PowerVC installation by clicking Verify Environment, as shown in Figure 4-4.

Figure 4-4 Verify Environment

Then, you can click View Results to verify that IBM PowerVC is installed correctly.

4.5 Host setup

Setting up the communication between managed hosts and IBM PowerVC varies, depending on whether HMC or PowerVM NovaLink is used to communicate with hosts. This section covers the steps for using HMC to communicate with hosts. The differences in this process when PowerVM NovaLink is used are shown.

Note: If the host system has PowerVM NovaLink installed, the system can still be added for HMC management by following normal procedures. If the host has PowerVM NovaLink installed and is HMC-connected, the management type from IBM PowerVC for this host must always be PowerVM NovaLink. HMC can be used to manage the hardware and firmware on the host system.

First, enable IBM PowerVC to communicate with the HMCs in the environment to manage the host systems running IBM PowerVM hypervisor. After the hosts, storage, and networks are configured correctly in the IBM PowerVC domain, you can add a VM.

If PowerVM NovaLink is used to manage hosts, the communication is established between PowerVM NovaLink and IBM PowerVC.

For more information about supported hosts, see 2.1.2, “Hardware and software requirements for IBM PowerVC” on page 14.

To add hosts for IBM PowerVC management, complete the following steps:

1. On the home window (Figure 4-4 on page 96), click Add Hosts.

2. If the host to be added is managed by HMC, follow the instructions in step a. If PowerVM NovaLink is used for management, follow the instructions in step b on page 98.

a. In the Add Hosts window (Figure 4-5), select the Host Management type as HMC and provide the name and credentials for the HMC. In the Display name field, enter the string that is used by IBM PowerVC to refer to this HMC in all of its windows. Click Add Connection. IBM PowerVC connects to the HMC and reads the host information.

Figure 4-5 HMC connection information

The user ID and password can be the default HMC hscroot administrator user ID combination. The ID can also be other IDs by using the hscsuperadmin role that you created to manage the HMC. If using an HMC user other than hscroot, allow remote access to the web in the user profile settings. Otherwise, IBM PowerVC reports authentication failure when adding the HMC connection.

Note: As a preferred practice, do not specify hscroot for the user ID. Instead, create a user ID on the HMC with the hscsuperadmin role and use it for managing the HMC from IBM PowerVC. Use this approach to identify actions on the HMC that were initiated by a user who was logged in to the HMC or from the IBM PowerVC management station. If a security policy requires that the hscroot password is changed regularly, the use of a different user ID for IBM PowerVC credentials avoids breaking the IBM PowerVC ability to connect to the HMC after a system administrator changes the hscroot password.

b. In the Add Hosts window (Figure 4-6), select the Host Management type as NovaLink and provide the name and credentials for the PowerVM NovaLink partition. In the Display name field, enter the string that is used by IBM PowerVC to refer to this PowerVM NovaLink partition in all of its windows. Click Add Connection. IBM PowerVC connects to the PowerVM NovaLink partition and reads the host information.

Figure 4-6 PowerVM NovaLink connection information

The user ID that is specified for the PowerVM NovaLink connection must be a member of the pvm_admin group or have both SSH access and sudoers NOPASSWD capabilities.

Note: Although this is not preferable, the HMC managed systems allow the same host to be added into more than one IBM PowerVC system. PowerVM NovaLink managed hosts allow a host to be added only into one IBM PowerVC system. If you try to add a PowerVM NovaLink managed host into another IBM PowerVC system, a message is displayed that this host is already managed by another IBM PowerVC installation and will be removed from that system.

3. IBM PowerVC prompts you to accept the HMC X.509 certificate, or if PowerVM NovaLink is used, the PowerVM NovaLink host SSH key. Review the message details to determine whether you are willing to override this warning. If you are willing to trust the certificate or accept the SSH key, click Connect to continue.

4. If the host being added is managed by HMC, follow the instructions in step a. If the host being added is managed by PowerVM NovaLink, follow the instructions in step b.

a. Next, you see information about all hosts that are managed by that HMC. Figure 4-7 shows the window for an HMC that manages four IBM POWER servers. To choose the hosts to manage with IBM PowerVC, click their names. By holding down the Ctrl key while you click the host names, you can select several host names simultaneously.

When the HMC manages several hosts, you can use the filter to select the name that contains the character string that is used as a filter. You can also select multiple systems pressing the Ctrl key and clicking the host names.

Figure 4-7 IBM PowerVC Add Hosts window

b. After selecting Add Host for a new system that is managed by PowerVM NovaLink, IBM PowerVC displays three messages in the lower right corner with information about the IBM PowerVC image transfer and installation on the PowerVM NovaLink host.

5. After a few seconds, the home window is updated and it shows the number of added objects, as shown in Figure 4-8.

Figure 4-8 Managed hosts

6. Click the Hosts tab to open a Hosts window that is similar to Figure 4-9, which shows the status of the discovered hosts and the management connection to this host.

Figure 4-9 IBM PowerVC shows the managed hosts

Add hosts by clicking Add Host. The windows to add a host are the same as the windows in step 2 on page 97. Select one host from the list to activate functions that can be performed for this host.

7. Click one host name to see the detailed host information, as shown in Figure 4-11. Operations that can be performed for this host are shown here as well.

After hosts, storage, and networks are configured correctly in the IBM PowerVC domain, you can add a VM by expanding the Virtual Machines section. VMs that are hosted by this host can be added to IBM PowerVC by selecting Manage Existing under the Virtual Machines section, as shown in Figure 4-10.

Figure 4-10 Host information

The Host details view contains information about host CPU and Memory usage history for the selected time range, as shown in Figure 4-11.

Figure 4-11 Host CPU usage history

Note: IBM PowerVC cannot monitor memory usage on HMC-managed systems, so HMC-managed hosts do not show the memory utilization graph.

4.5.1 Host maintenance mode

Before you perform maintenance activities on a host, such as updating the operating system or firmware or replacing hardware, you should move the host into maintenance mode. Maintenance mode is sometimes referred to as one-click evacuation.

IBM PowerVC can be used to put IBM PowerVC managed hosts into maintenance mode. Hosts can be put into maintenance mode from the IBM PowerVC Hosts view by selecting the host from list and selecting Enter Maintenance Mode, as shown Figure 4-12.

Figure 4-12 Place the host into maintenance mode

Before the host can be put into maintenance mode, the following conditions must apply:

•The host’s hypervisor must be in the Operating state.

•If VMs on the host are to be migrated to other servers, the following conditions apply:

 – The hypervisor must be licensed for Live Mobility.

 – The VMs on the host cannot be in the error, paused, building states.

 – All running VMs must be in the OK state and the Resource Monitoring and Control (RMC) connection status must be Active.

 – All requirements for live migration must be met.

•If the request was made to migrate active VMs when entering maintenance mode, the following cannot also be true, or the request fails:

 – There is a VM on the host that is a member of a collocation rule that specifies affinity and has multiple members.

 – The collocation rule has a member that is already undergoing a migration or is being remote restarted.

The following process describes what happens when the host is put into maintenance mode:

•If requested, all the VMs on the host are migrated to a different host. If there are any errors during migration, the maintenance operation fails and enters the error state until an administrator resolves the problem. By default, IBM PowerVC migrates the VMs with the highest memory usage.

•After maintenance mode is requested, you cannot perform any actions on the host’s VMs except stop, delete, or live migrate, and you cannot deploy or migrate VMs to the host. Therefore, this host is not listed in the IBM PowerVC user interface selection lists for any actions. You can perform maintenance activities on the host.

•When a host is ready for use, exit the maintenance mode from the IBM PowerVC user interface. When the host is available in IBM PowerVC again, you must manually move VMs to the host. The VMs that were previously on this host are not automatically moved back to this host.

To put the host into maintenance mode, complete the following steps:

1. Select the host that you want to put into maintenance mode and select Enter Maintenance Mode.

2. If you want to migrate the VMs to other hosts, select Migrate active virtual machines to another hosts and Destination for migration, as shown in Figure 4-13. This option is unavailable if there are no hosts available for the migration.

Figure 4-13 Virtual machine migration

3. Click OK.

After maintenance mode is requested, the host’s maintenance state is Entering while the VMs are migrated to another host, if requested. This status changes to On after the migration is complete and the host is fully in the maintenance state.

To remove a host from maintenance mode, select the host and select Exit Maintenance Mode.

After the host is brought out of maintenance mode, you can add VMs to the host. IBM PowerVC does not automatically migrate back VMs that were running on host before it was put into maintenance mode.

Note: You can edit the period after which the migration operation times out and the maintenance mode enters an error state by running the following commands:

/usr/bin/openstack-config --set /etc/nova/nova.conf DEFAULT prs_ha_timeout_seconds <duration_in_seconds>

service openstack-nova-ibm-ego-ha-service restart

The <duration_in_seconds> is the timeout period in seconds.

4.5.2 Host Groups

You can use host groups to group logically hosts regardless of any features that they might have in common. For example, the hosts do not have to have the same architecture, network configuration, or storage. Host groups have the following features:

•Every host must be in a host group.

•VMs are kept within the host group.

•Placement policies are associated with the host groups.

To create a Host Group, go to the Hosts section and select the Host Groups tab, then click Create. A window opens, as shown in Figure 4-14.

Figure 4-14 Create Host Group

To create a Host Group, you must provide the following details:

•Host Group Name

•Placement Policy

For the placement policies that are supported by IBM PowerVC, see 2.4.2, “Placement policies” on page 26.

•Automated Remote Restart

This is a new feature that is introduced with IBM PowerVC 1.3.2. If enabled, automated remote restart monitors hosts for failure by using the Platform Resource Scheduler (PRS) HA service. If a host fails, PowerVC automatically remote restarts the VMs from the failed host to another host within a host group.

Note: Automated Remote Restart is supported only on IBM POWER8 processor-based servers.

Without automated remote restart enabled, when a host goes into an Error or Down state, you must manually trigger the operation of evacuating all the VMs on a host.

Automated restart relies on these values:

 – Run interval

The frequency that the state of the host is checked. The default value is 1 minute.

 – Stabilization

The number of consecutive run intervals that the host must be down before an automated remote restart operation is initiated. The default value is five.

•Dynamic Resource Optimizer (DRO)

If enabled, DRO continuously monitors your cloud environment's usage. You can specify that DRO monitors CPU usage or available memory. When a host is found to be overused, the DRO tries to correct the situation by performing the action that you specified. It can migrate VMs or, when applicable, work with Capacity on Demand (CoD) to activate mobile cores. For more information about DRO, see 4.15, “Management of virtual machines and images” on page 134.

•Members

The Hosts for the new Host Group.

4.6 Hardware Management Console management

Beginning with IBM PowerVC Version 1.2.3, users can add redundant HMCs for Power Systems servers. If one HMC fails, the user can change the HMC to one of the redundant HMCs.

4.6.1 Adding an HMC

With IBM PowerVC Version 1.2.3 or later, you can add redundant HMCs for Power System servers. To add an HMC, in the HMC Connections section in the Hosts window, click Add HMC, as shown in Figure 4-15. Enter the HMC host name or IP address, display name, user ID, and password. Click Add HMC Connection. The new HMC is added.

You also can click Remove HMC to remove an HMC.

Figure 4-15 Add HMC Connection

4.6.2 Changing the HMC credentials

If you want to change the credentials that are used by IBM PowerVC to access the HMC, open the Hosts window and click the HMC Connections tab. Select the row for the HMC that you want to work with, and then click Edit. A window opens (Figure 4-16) where you can specify another user ID, which must already be defined on the HMC with the hscsuperadmin role.

Figure 4-16 Change the HMC credentials

4.6.3 Changing the HMC

IBM PowerVC uses only one HMC for one server. If one HMC fails, you must change the management console to another HMC. As shown in Figure 4-17, on the Hosts window, select all of the servers that you want to change, click Edit Host Connection, select the HMC you want, and click OK.

Figure 4-17 Change the HMC

The management console of the Power System servers changes to the new HMC, as shown in Figure 4-18.

Figure 4-18 Select the new HMC for hosts

4.6.4 Change management connection, HMC, and PowerVM NovaLink

You cannot use IBM PowerVC to change your hosts to be PowerVM NovaLink managed if you are using shared processor pools or shared storage pools (SSPs). If you are using the DRO with Capacity on Demand (CoD), you can switch to PowerVM NovaLink. DRO continues to monitor and adjust workloads, but cannot take advantage of CoD.

To prepare the system for PowerVM NovaLink management, complete the following steps:

1. Install the PowerVM NovaLink software on a system that is managed by an HMC.

Note: When IBM PowerVC recognizes that PowerVM NovaLink is installed on it, a warning is displayed and the host is put into maintenance mode. Any operations that are running likely fail.

2. From the IBM PowerVC user interface, open the Host window, select the host that you want to update, and then select Edit Host Connection.

3. For the Host management type, select NovaLink. Enter the appropriate information and click OK.

IBM PowerVC now recognizes the host as PowerVM NovaLink managed and the host comes out of maintenance mode.

4.7 Storage and SAN fabric setup

When you use external Storage Area Network (SAN) storage, you must prepare the storage controllers and Fibre Channel (FC) switches before they can be managed by IBM PowerVC.

IBM PowerVC needs management access to the storage controller. When you use user authentication, the administrative user name and password for the storage controller must be set up. For IBM Storwize storage, another option is to use cryptographic key pairs. For instructions to generate use key pairs, see the documentation for your device.

To configure the storage controller and SAN switch, complete the following steps:

1. Configure the FC SAN fabric for the IBM PowerVC environment.

2. Connect the required FC ports that are owned by the Virtual I/O Server (VIOS) and the storage controllers to the SAN switches.

3. Set up the host names, IP addresses, and administrator user ID and password combination for the SAN switches.

4. Set up the host names, IP addresses, and the administrator user ID and password combination for the storage controllers.

5. Create volumes for the initial VMs that are to be imported (installed) to IBM PowerVC later.

Note: IBM PowerVC creates VMs from an image. No image is provided with
IBM PowerVC. Therefore, you must manually configure at least one initial partition from which you create this image. The storage volumes for this initial partition must be created manually. When IBM PowerVC creates more partitions, it also creates the storage volumes for them.

Note: For IBM PowerVC Version 1.2.2 and higher, you can import an image (that you created earlier) from storage into IBM PowerVC.

For more information about supported storage in IBM PowerVC Standard Edition, see 2.1.1, “Hardware and software requirements” on page 14.

4.7.1 Adding a storage controller to IBM PowerVC

To set up storage providers and the SAN fabric, complete the following steps:

1. To add a storage controller, click the Add Storage link on the IBM PowerVC home window, as shown in Figure 4-4 on page 96. If a storage provider is already defined, the icon differs slightly. Click the plus sign (+) to the right of Storage Providers, as shown in Figure 4-19.

Figure 4-19 Add extra storage providers

2. The window that is shown in Figure 4-20 requires this information:

 – Type: Six types are supported: DS8000, EMC VMAX, EMC VNX, Storwize, IBM XIV Storage System, and Hitachi Block Storage. In this example, we select Storwize for our IBM V7000 storage system. The required information may vary depending on the storage type.

 – Storage controller name or IP address and display name.

 – User ID and password or Secure Shell SSH encryption key. (The encryption key option is only for IBM Storwize storage.)

Figure 4-20 Add Storage

3. Click Add Storage. IBM PowerVC presents a message that indicates that the authenticity of the storage cannot be verified. Confirm that you want to continue. IBM PowerVC connects to the storage controller and retrieves information.

4. IBM PowerVC presents information about storage pools that are configured on the storage controller. You must select the default pool where IBM PowerVC creates logical unit numbers (LUNs) for this storage provider, as shown in Figure 4-21.

Click Add Storage, and IBM PowerVC finishes adding the storage controller.

Figure 4-21 IBM PowerVC window to select a storage pool

Tip: For more information about the storage template, see 4.9, “Storage connectivity group setup” on page 115.

4.7.2 Adding a SAN fabric to IBM PowerVC

Add the SAN fabric to IBM PowerVC. After you add the storage, IBM PowerVC automatically prompts you to add fabrics. To do so, complete the following steps:

1. Open the window that is shown in Figure 4-22 and click Add Fabric.

Figure 4-22 Add Fabric window

You must complete the following information about the first SAN switch to add it under
IBM PowerVC control:

 – Fabric type: Brocade and Cisco SAN switches are supported.

 – Zoning policy: Initiator and Initiator-target are supported.

Note: Initiator zoning creates a one-to-many relationship between the host and the target storage controller node, and initiator-target zoning creates a one-to-one relationship between the host and the storage controller. Initiator zoning is typically used for Cisco fabrics, which helps to keep the zone footprint much smaller.

 – Principal switch name or IP address and display name.

 – User ID and password.

 – For Cisco Fabric, you also have to specify the Primary Port and the VSAN.

2. In the Add Fabric window, click Add Fabric, and then confirm the connection in the window that opens. IBM PowerVC connects to the switch and retrieves the setup information. The window is shown in Figure 4-23.

Figure 4-23 IBM PowerVC Add new Fabric

3. Figure 4-24 shows the IBM PowerVC Storage window after you successfully add the SAN storage controllers and SAN switches. The Storage Providers tab is selected. To show managed SAN switches, click the Fabrics tab.

Figure 4-24 IBM PowerVC Storage providers tab

Additional storage controllers can be added by clicking Storage, then the Storage Providers tab, and then Add Storage. The window to add a storage controller is the same window that was used for the first storage controller in steps 1 on page 109 and 2 on page 110 in 4.7.1, “Adding a storage controller to IBM PowerVC” on page 109.

You can add SAN switches by clicking Storage, then the Fabrics tab, and then Add Fabric. The window to add a switch is the same window that was used for the first switch (fabric) in 4.7.2, “Adding a SAN fabric to IBM PowerVC” on page 112.

Note: IBM PowerVC Version 1.3.2 supports a maximum of 25 fabrics.

4.8 Storage port tags setup

The next step is to customize IBM PowerVC is the FC port tag setup. This setting is optional. Individual FC ports in VIOSs that are managed by IBM PowerVC can be tagged with named labels. For more information about IBM PowerVC tags and storage connectivity groups, see 2.6.3, “Storage connectivity groups and tags” on page 46.

Note: Tagging is optional. It is needed only when you want to partition the I/O traffic and restrict certain traffic to use a subset of the available FC ports.

To set up tagging, start from the IBM PowerVC home window and click Configuration → Fibre Channel Port Configuration to open the window that is shown in Figure 4-26 on page 116.

For each FC adapter in all VIOSs that are managed by IBM PowerVC, you can enter or select a port tag (arbitrary name). IBM PowerVC automatically recognizes the fabric that the port is connected to if the fabric is defined in IBM PowerVC. You can either double-click a Port Tag field and enter a new tag or use the drop-down menu to select a tag from a list of predefined tags. You can also set the tag to None or define your own tag. You can also select N_Port ID Virtualization (NPIV) or virtual SCSI (vSCSI) for the Connectivity field to restrict the port to special SAN access. To disable the FC port in IBM PowerVC, set the connectivity to None. By default, all ports are set to Any connectivity, which allows all connectivity methods. In this example, two sets of FC ports were defined, with Product and Test tags. Certain ports allow NPIV access only, and other ports allow vSCSI, or Any. Do not forget to click Save to validate your port settings, as shown in Figure 4-25.

Figure 4-25 IBM PowerVC Fibre Channel port configuration

Note: Situations exist where you add adapters to a host after IBM PowerVC is installed and configured. Assign them to a VIOS. Enable the VIOS to discover them by running the cfgdev command. Then, IBM PowerVC automatically discovers them. If you open the Fibre Channel Port Configuration window, IBM PowerVC shows these new adapters.

4.9 Storage connectivity group setup

Next, define the storage connectivity groups. A storage connectivity group is a set of VIOSs with access to the same storage controllers. The storage connectivity group also controls the boot volumes and data volumes to use NPIV or vSCSI storage access. For a detailed description, see 2.7, “Network management planning” on page 52.

IBM PowerVC creates a default storage connectivity Any Host, All VIOS during the initial setup and adds all hosts and VIO servers into that group by default. Defining additional storage connectivity groups is an optional task that can be performed any time after the initial installation. All VMs that are deployed in IBM PowerVC require a storage connectivity group to be assigned during the deployment. VM deployed into a storage connectivity group remains on that group during its lifecycle and cannot be changed.

To set up a storage connectivity group, complete the following steps:

1. Start from the IBM PowerVC home window and click Configuration → Storage Connectivity Groups to open the window that is shown in Figure 4-26.

Figure 4-26 IBM PowerVC Storage Connectivity Groups window

Default storage connectivity groups are defined for the following components:

 – All ports of all VIOSs that can access the storage providers by using NPIV.

 – A vSCSI boot volume storage connectivity group is added if the environment meets the requirements of vSCSI SAN access.

 – For all VIOSs that belong to the SSPs that IBM PowerVC discovered if SSP was configured.

2. You can then create your own storage connectivity group. Click Create. In the next window, enter information or select predefined options for the new storage connectivity group:

 – Name of the storage connectivity group.

 – Boot and Data volume connectivity types: NPIV or vSCSI.

 – “Automatically add applicable VIOSs from newly registered hosts to this storage connectivity group”: If checked, from now on, newly VIOSs are added to this group if they can access the same storage (fabrics and tags) as the other members of the group.

 – “Allow deployments using this storage connectivity group (enable)”: If checked, the storage connectivity group is enabled for deployment on VMs; otherwise, it is disabled. You can change this selection later, if necessary.

 – Restrict image deployments to hosts with FC-tagged ports: This setting is optional. If you use tags, you can select a specific tag. VMs that are deployed to this storage connectivity group (with a selected tag) can access storage only through FC ports with the specified tag.

 – VIOS Redundancy For Volume Connectivity:

 • At least: Select this option to define the minimum number of VIOSs per host that can connect to the volume. From the drop-down menu, select 1, 2, 3, or 4 VIOSs.

 • Exactly: Select this option to define the exact number of VIOSs per host that can connect to the volume. From the drop-down menu select 1, 2, 3, or 4 VIOSs.

 – NPIV Fabric Access Requirement: This setting controls how the FC paths are created when a VM is created. You can choose Every fabric per VIOS, Every fabric per Host, At least one fabric per VIOS or Exactly one fabric per VIOS.

3. When the information is complete, click Add Member to open the window that is shown in Figure 4-27. You must select which VIOSs become members of the group. If a tag was previously selected, only eligible VIOSs are available to select.

After you select the VIOSs, click Add Member. Selected VIOSs are added to the storage connectivity group.

Then, click Add Group, and the group is created. Now, the group is available for VM deployment.

Figure 4-27 IBM PowerVC Add Member to storage connectivity group window

A storage connectivity group can be disabled to prevent the deployment of VMs in this group. To disable a group, you must clear the check box for Allow deployments using storage connectivity group (enable) on the Detailed Properties window of the storage connectivity group, as shown in Figure 4-28. The default storage connectivity group cannot be deleted, but it can be disabled.

Figure 4-28 Disable a storage connectivity group

4.10 Storage template setup

After you configure your storage connectivity group, you can also create storage templates. Storage templates provide a predefined storage configuration to use when you create a disk. You must define different information on the storage templates for different types of storage. For example, as shown in Figure 4-29, this storage template is for the SAN Volume Controller storage device. You do not need any configuration information except the template name and pool name. For a full description, see 2.6.2, “Storage templates” on page 43.

Figure 4-29 Create storage template

A default storage template is automatically created by IBM PowerVC for each storage provider. However, if the storage contains several storage pools, create a storage template for each storage pool that you want to use. For IBM Storwize storage, you also must create a storage template for each I/O group that you want to use, and each volume mirroring pool pair that you want to use.

Figure 4-30 on page 120 shows the window to create a storage template for IBM Storwize storage. To access it, from the IBM PowerVC home window, click Configuration → Storage Templates → Create. Then, complete these steps:

1. Select a storage provider.

2. Select a storage pool within the selected storage provider.

3. Provide the storage template name.

4. Select the type of provisioning:

 – Generic means full space allocation (also known as thick provisioning).

 – Thin Provisioned is self-explanatory.

Both types have additional options available. If you click Advanced Settings, an additional window (Figure 4-31 on page 121) offers these options:

 • I/O group.

 • Real capacity % of virtual storage. (Thin Provisioned Only).

 • Automatically expand. (Thin Provisioned Only).

 • Warning threshold. (Thin Provisioned Only).

 • Thin-provisioned grain size. (Thin Provisioned Only).

 • Use all available worldwide port names (WWPNs) for attachment.

 • Enable mirroring. You must select another pool to enable mirroring.

For more information about how these settings affect IBM PowerVC disk allocation, see 2.6.2, “Storage templates” on page 43.

 – Compressed for storage arrays that support compression.

Figure 4-30 IBM PowerVC Create Storage Template window

Figure 4-31 shows the advanced settings that are available for thin-provisioned templates. The advanced settings can be configured only for storage that is backed by SAN-accessed devices. When the storage is backed by an SSP in thin-provisioning mode, IBM PowerVC does not offer the option to specify these advanced settings.

Figure 4-31 IBM PowerVC Storage Template Advanced Settings

5. After you click Create, the storage template is created and it is available for use when you create storage volumes. The window that summarizes the available storage templates is shown in Figure 4-32.

Figure 4-32 IBM PowerVC Storage Templates window

4.11 Storage volume setup

After you add the storage providers and define the storage templates, you can create storage volumes.

Note: Only data volumes must be created manually. Boot volumes are handled by
IBM PowerVC automatically. When you deploy a partition as described in 4.15.7, “Deploying a new virtual machine” on page 156, IBM PowerVC automatically creates the boot volumes and data volumes that are included in the images.

When you create a volume, you must select a template that determines where (which storage controller and pool) and what the parameters are (thin or thick provisioning, grain size, and so on) for the volume to create.

When you create a volume, you must select these elements:

•A storage template.

•The new volume name.

•A short description of the volume (optional).

•The volume size (GB).

•Enable sharing or not. If this option is selected, the volume can be attached to multiple VMs. This option is for PowerHA or similar solutions.

To create a volume, complete the following steps:

1. From the IBM PowerVC home window, click Storage Volumes → the Data Volumes tab → Create to open the window that is shown in Figure 4-33.

Figure 4-33 IBM PowerVC Create Volume window

2. After you click Create Volume, the volume is created. A list of existing volumes is displayed, as shown in Figure 4-34. This figure shows that the provisioned disks are in the available state.

3. From the Storage window, you can manage volumes. Valid operations are the creation, deletion, or unmanaging of already managed volumes or the discovery of volumes that are defined on a storage provider and not yet managed by IBM PowerVC. You also can edit the volumes to enable or disable sharing or resize the volumes. Currently, only increasing the volume capacity is supported.

Figure 4-34 List of IBM PowerVC storage volumes

4.12 Network setup

When you create a VM, you must select a network. If the network uses static IP assignment, you must also select a new IP address for the VM or let IBM PowerVC select a new IP address from the IP pools. For a full description of network configuration in IBM PowerVC, see 2.7, “Network management planning” on page 52.

4.12.1 Basic network setup

Initially, IBM PowerVC contains no network definition, so you must create at least one network definition. To create a network definition in IBM PowerVC, from the home window, click Networks → Add Network to open the window that is shown in Figure 4-35.

Figure 4-35 IBM PowerVC network definition

You must provide the following data when you create a network:

•Network name

•Virtual LAN (VLAN) ID

•Maximum transmission unit (MTU) size in bytes

•For IP address type, select Dynamic or Static (Select Dynamic if the IP address is assigned automatically by a Dynamic Host Configuration Protocol (DHCP) server.)

•Subnet mask

•Gateway

•Primary/Secondary DNS (This field is optional if you do not use DNS.)

•Starting IP address and ending IP address in the IP pool

Note: You cannot modify the IP pool after you create the network. Ensure that you enter the correct IP addresses. You can remove and add a network only if you want to update the IP addresses in an IP pool.

•Shared Ethernet adapter (SEA) mapping (Select adapters within VIOSs with access to the specific network and that are configured with the correct VLAN ID.)

After you click Add Network, the network is created. From the Networks window, you can also edit the network (change network parameters) and delete networks.

Consider these factors:

•IBM PowerVC detects the SEA to use for each host. Verify that IBM PowerVC made the correct choice.

•If IBM PowerVC chooses the wrong SEA to use for a specific host, you can change the SEA later.

You can also check the IP address status in the IP Pool on the IP Pool window, as shown in Figure 4-36.

Figure 4-36 IP Pool tab

Important: In the SEA mapping list, the Primary VLAN column refers to the Port Virtual LAN Identifier (PVID) that is attached to the adapter. The VLAN number that you specify does not need to match the primary VLAN.

4.12.2 SR-IOV network setup

To configure an SR-IOV network, complete the following steps:

1. Add a NovaLink managed host that uses SR-IOV ports.

2. Select the host and associate/document physical network names with ports on the SRIOV Ports tab of the Host Details page. This configuration determines which physical ports are assigned to the physical network. IBM PowerVC uses this information to ensure that VMs are not put on the wrong physical networks during deployments or migrations. Figure 4-37 shows an example of how it should look.

Figure 4-37 Available SR-IOV physical ports at the NovaLink host and their current state

Physical port PCI Physical port location for the specified physical network.

Status The overall status of the physical port.

Configured port The network speed at which the port negotiates.

Available Capacity The percentage of bandwidth capacity that is not yet allocated to any logical port.

Available Remaining available logical ports.

Total Logical Ports The total number of logical ports to use.

Physical Network Name
Current name that is associated to the physical port. Specifying a physical network name allows you to configure which ports are attached to which network in your environment. You can choose an existing physical network name or give this network a new name.

Note:

•The capitalization that you use to specify the physical network name cannot be changed. For example, if you name a network DATA1 and later use data1, the system updates data1 to DATA1. Therefore, if you manually changed the network label on PowerVM from DATA1 to data1, the network no longer lines up with the physical network name that is specified in IBM PowerVC and this function does not work correctly.

•You cannot rename a physical network that is in use by other resources.

•The PowerVM port label is updated to match the physical network name. The port sublabel is not changed and remains available for your use.

3. Now that you confirmed that your SR-IOV adapters are visible to IBM PowerVC, proceed to add the network. Go to the Network details window, click Add Network, and specify the physical network name for it. When you specify the physical network name, the list of ports from step 2 on page 126 are shown. Figure 4-38 shows that when you select the efried1 physical network name, the real port behind it becomes visible.

Figure 4-38 Add SR-IOV Network

4. The new SR-IOV network is created and visible, as shown in Figure 4-39.

Figure 4-39 SR-IOV Network available after creation

5. You can now choose the SR-IOV network that you created when you deploy a VM, or you can attach the SR-IOV network to a VM that was already deployed in IBM PowerVC. In this particular case, we cover a deployment of a new VM from image. Go to the Images section and select the one you want. Select Deploy and complete the standard sections. In the Deploy Target window, select the NovaLink host that contains the SR-IOV ports. Scroll down to the Network section. Click Add Network and a dialog box opens, as shown in Figure 4-40.

Figure 4-40 Add SR-IOV Network adapter to the VM

On the Primary network (system default gateway) drop-down menu, the SR-IOV network you created previously should show up. Complete the following steps:

a. Specify an IP address that falls under the network segment you previously defined.

b. Select SR-IOV as the Adapter type.

c. Specify Redundant adapter if your network is set up for redundancy. You can check only the Redundant adapter check box if two physical ports are available for a host/network combination. Redundancy cannot be used with one or fewer physical ports because two ports are required to provide alternative paths for the Ethernet traffic. If this is selected, the vNIC adapter that is created for the VM includes multiple logical ports.

d. Select the Virtual NIC capacity to specify quality of service (QoS). This is the minimum capacity of this network. During run time, the VM has at least this amount of network connectivity capacity. If the requested capacity is not available, the deployment is not allowed.

Important:

•You can use this setting to prevent important workloads on your VMs from losing resources to less important workloads that share the same physical port.

•The maximum capacity value is calculated based on the amount of capacity currently available for a host/network combination.

6. After the VM is deployed with the applied configuration, it should become visible in the VMs section of IBM PowerVC. Click Virtual Machines and find your VM. Browse through its properties and it should show that the SR-IOV network port was added, as shown in Figure 4-41.

Figure 4-41 Deployed VM with an SR-IOV network adapter available

Detaching an SR-IOV attached virtual machine

Whether you must remove an SR-IOV attached VM, see IBM Knowledge Center:

http://www.ibm.com/support/knowledgecenter/P8DEH/p8hat/p8hat_dlpariopmovep6.htm

4.13 Compute template setup

A compute template provides a predefined compute configuration to use when you deploy a new VM. By default, IBM PowerVC provides six compute templates with different sizes, from tiny to xxlarge, you can use. You select a compute template when you deploy a VM. You can change the values that are set in the compute template that is associated with a VM to resize it. You can also create compute templates on the Configuration window.

For the full description about compute templates, see 2.4.4, “Information that is required for compute template planning” on page 30.

Figure 4-42 on page 130 shows the window that opens when you create a compute template. To access the compute template configuration from the IBM PowerVC home window, click Configuration → Compute Templates → Create Compute Template. You must specify the following settings for images that are deployed with the compute template:

•For Template settings, select Advanced.

•Provide the compute template name.

•Provide the number of virtual processors.

•Provide the number of processing units.

•Provide the amount of memory.

•Select the compatibility mode.

If you selected Advanced Settings, additional information is required:

•Provide the minimum, desired, and maximum number of virtual processors.

•Provide the minimum, desired, and maximum number of processing units.

•Provide the minimum, desired, and maximum amounts of memory (MB).

•Enter the processor sharing type and weight (0 - 255).

•Enter the availability priority (0 - 255).

Figure 4-42 IBM PowerVC Create Compute Template

After you click Create Compute template, the Compute Templates window opens for use when you create a VM. The window that summarizes the available compute templates is shown in Figure 4-43.

Figure 4-43 IBM PowerVC Compute Templates

4.14 Environment verification

After you add the hosts, storage providers, networks, and templates, as a preferred practice, verify your IBM PowerVC environment before you try to capture, deploy, or onboard VMs.

Virtualization management function failures might occur when dependencies and prerequisite configurations are not met.

IBM PowerVC reduces the complexity of virtualization and cloud management. It can check for almost all required dependencies and prerequisite configurations and clearly communicate the failures. It can also accurately pinpoint validation failures and remediation actions when possible.

Figure 4-44 shows the IBM PowerVC Home interface where you start the verification process by clicking Verify Environment. Access the verification report by clicking View Results.

Figure 4-44 IBM PowerVC interface while environment verification in process

The validation of the IBM PowerVC environment takes from a few seconds to a few minutes to complete depending on the size of the environment.

The environment validation function architecture is used to add and change validators to check solution-specific environment dependencies and prerequisite configurations. This architecture is intended to allow the tool to be tuned to improve on performance, reliability, and scalability of validation execution with the increase in the number of endpoints, their configurations, and their inter-connectivity.

4.14.1 Verification report validation categories

After the validation process finishes, you can access a report of the results, as shown in Figure 4-45. This report consists of a table with four columns where you see the following values:

•Status

•System

•Validation Category

•Description

Figure 4-45 Verification Results view

The following list shows the validation categories in this report and a description for the types of messages to expect from each of the categories:

Access and Credentials
Validation of reachability and credentials from the management server to the IBM PowerVC domain, including user IDs, passwords, and SSH keys for all resources.

File System, CPU, and Memory on Management Server
Minimum processing and storage requirements for the IBM PowerVC management server.

OS, services, database
This category groups all messages that relate to the availability of the service daemons that are needed for the correct operation and message passing on the IBM PowerVC domain. This category includes operating system services, OpenStack services, platform Enterprise Grid Orchestrator (EGO) services, and MariaDB configuration.

HMC version HMC software level and K2 services are running.

HMC managed Power Systems server resources
Power Systems hosts when they are managed by an HMC. Validation messages include the operating state, PowerVM Enterprise Edition enablement, PowerVM Live Partition Mobility (LPM) capabilities, ability to run a VIOS, maximum number of supported Power Systems servers, firmware level, and processor compatibility. This category is visible from IBM PowerVC Standard Edition.

Virtual I/O Server count, level, and RMC state
Minimum number of configured VIOSs on each managed host, software level, RMC connection and state to the HMC, license agreement state, and maximum number that is required for virtual adapter slots. This category is viewable from IBM PowerVC Standard Edition.

Virtual Network: Shared Ethernet Adapter
The SEA is configured on the IBM PowerVC management server network and in the Active state. The maximum number of required virtual slots.

Virtual I/O Server Shared Ethernet Adapter count, state
This category relates to the validation of at least one SEA on one VIOS. You can view this category from IBM PowerVC Standard Edition.

Host storage LUN Visibility
LUN visibility test. LUNs are created on storage providers and are visible to VIOSs.

Host storage FC Connectivity
Messages that relate to the enabled access to the SAN fabric by the VIOSs and the correct WWPN to validate that VIOS - Fabric - Storage connectivity is established. This category is viewable from
IBM PowerVC Standard Edition.

Storage Model Type and Firmware Level
Messages that relate to the minimum SAN Volume Controller and storage providers’ firmware levels and the allowed machine types and models (MTMs).

Brocade Fabric Validations
Validation for the switch presence, zoning enablement, and firmware level.

Figure 4-46 shows the depth of information that is provided by IBM PowerVC. This example shows error messages and then confirmation of an acceptable configuration. By clicking or hovering the mouse pointer over each row of the verification report, you can see windows with extra information. In addition to the entry description, IBM PowerVC suggests a solution to fix the cause of an error or an informational message.

Figure 4-46 Example of a validation message for an error status

4.15 Management of virtual machines and images

The following sections describe the operations that can be performed on VMs and images by using the IBM PowerVC management host:

•4.15.1, “Virtual machine onboarding” on page 135

•4.15.2, “Refreshing the virtual machine view” on page 143

•4.15.3, “Starting the virtual machine” on page 144

•4.15.4, “Stopping the virtual machine” on page 144

•4.15.5, “Opening a console window” on page 145

•4.15.8, “Resizing the virtual machine” on page 162

•4.15.9, “Migration of virtual machines” on page 164

•4.15.10, “Host maintenance mode” on page 168

•4.15.11, “Restarting virtual machines remotely from a failed host” on page 170

•4.15.12, “Attaching a volume to the virtual machine” on page 174

•4.15.13, “Detaching a volume from the virtual machine” on page 175

•4.15.14, “Resetting the state of a virtual machine” on page 177

•4.15.15, “Deleting images” on page 178

•4.15.16, “Unmanaging a virtual machine” on page 178

•4.15.17, “Deleting a virtual machine” on page 179

Most of these operations can be performed from the Virtual Machines window, as shown on Figure 4-47. However, removing a VM, adding an existing VM, and attaching or detaching a volume from a VM are performed from other windows.

Figure 4-47 Operations icons on the Virtual Machines view

4.15.1 Virtual machine onboarding

IBM PowerVC can manage VMs that were not created by IBM PowerVC, such as VMs that were created before the IBM PowerVC deployment. To add an existing VM, complete the following steps:

1. From the IBM PowerVC home window, click the hosts icon within the main pane (host icon on the left) or click the Hosts link, as shown in Figure 4-48.

Figure 4-48 Select a host window

2. Click the line of the host on which the VMs that you want to manage are deployed. The background color of the line changes to light blue. Click the host name in the Name column, as shown in Figure 4-49.

Figure 4-49 Selected hosts window

3. The detailed host window opens. In Figure 4-50, the Information and Capacity sections are collapsed for improved viewing. To collapse and expand the sections, click the section names, and you see the collapse and expand buttons. The Virtual Machines section is expanded, but it contains no data because IBM PowerVC does not yet manage any VM on this host.

Figure 4-50 Collapse and expand sections

4. Under the Virtual Machines section (or in the home Hosts section), click Manage Existing to open a window with two options:

 – Manage all fully supported VMs that are not currently being managed by IBM PowerVC. VMs that require preparation must be selected individually.

 – Select specific VMs.

5. Check Select specific virtual machines.

6. After you load data from the HMC, IBM PowerVC displays a new window with two tabs. The Supported tab shows you all of the VMs that can be added to be managed by the
IBM PowerVC. Select one or more VMs that you want to add. The background color changes to light blue for the selected VMs, as shown in Figure 4-51.

Note: Checking Manage any supported virtual machines that are not currently being managed by IBM PowerVC and then clicking Manage results in adding all candidate VMs without asking for confirmation.

Figure 4-51 Add existing VMs

Note: If a VM does not meet all of the requirements, the VM appears on the Not supported tab. The tab also shows the reason why IBM PowerVC cannot manage the VM.

Note: The detailed eligibility requirements to add a VM into an IBM PowerVC managed PowerVM host are available in IBM Knowledge Center:

https://ibm.biz/BdXK6a

After you click Manage, IBM PowerVC starts to manage the processing of the selected VMs.

7. IBM PowerVC displays a message in the lower-right corner during this process, as shown in Figure 4-52. These messages remain visible for a few seconds.

Tip: You can display the messages again by clicking Messages on the black bar with the IBM logo at the top of the window.

Figure 4-52 Example of an informational message

8. After you discover a VM, click the Virtual Machines icon to return to the Manage Existing window. Select the recently added VM. The background color changes to light blue.

Double-click the recently added VM to display its detailed information. The VM’s details window can be accessed by double-clicking Home → Hosts → host name → VM name where host name is the name of the server that contains the VM that you want to view and VM name is the correct VM.

9. For improved viewing, you can collapse sections of the window. Figure 4-53 presents the detailed view of a VM with all sections collapsed. You can collapse and expand each section by clicking the section names: Information, Specifications, Network Interfaces, Collocation Rules, and Details.

Figure 4-53 Virtual machine detailed view with collapsed sections

10. The Information section displays information about the VM status, health, and creation dates. Table 4-1 explains the fields in the Information section.

Table 4-1 Information section fields

Field

Description

Name

The name of the VM.

Description

A user editable field for providing descriptive information.

State

The actual state for the VM.

Health

The actual health status for the VM:

OK
The target resource, all related resources, and the IBM PowerVC management services for the resources report zero problems.

Warning
The target resource or a related resource requires user attention. Nova or Cinder host services that manage the resources report problems and require user attention.

Critical
The target resource or a related resource is in an error state.

Unknown
IBM PowerVC cannot determine the health status of the resource.

ID

This internal ID is used by IBM PowerVC management hosts to identify uniquely the VM.

Host

Host server name where the VM is allocated.

Excluded from DRO

Yes or No. Is the host excluded from the DRO?

Created

Creation date and time.

Last updated

Last update date and time.

Expiration date:

Date and time that the VM expires. None indicates that no date was specified.

Note: Each host, network, VM, and any other resource that is created in the
IBM PowerVC management host has its own ID number. This ID uniquely identifies each resource to the IBM PowerVC management host.

11. In Figure 4-54, the Information section is expanded to display details about the recently added VM.

Figure 4-54 Virtual machine detailed view of expanded Information section

12. Collapse the Information view and expand the Specifications section. This section contains information that relates to the VM capacity and resources. Table 4-2 provides the fields in the Specifications section.

Table 4-2 Specifications section’s fields

Field

Description

Remote restart enabled

Remote restart is enabled or disabled.

Remote restart state

Status of the remote restart.

Excluded from automated remote restart

Status of the automated remote restart.

Memory

Amount of memory (expressed in MB).

Processors

Amount of entitled processing capacity.

Minimum memory (MB)

Amount of minimum wanted memory.

Maximum memory (MB)

Amount of maximum memory.

Minimum processors

Amount of minimum virtual processor capacity.

Maximum processors

Amount of maximum virtual processor capacity.

Availability priority

Priority number for availability when a processor fails.

Processor mode

Shared or dedicated processor mode selected.

Minimum processing units

Amount of minimum entitled processing capacity.

Maximum processing units

Amount of maximum entitled processing capacity.

Sharing mode

Uncapped or capped mode selected.

Shared processor pool

The shared processing pool to which the VM belongs.

Processor compatibility mode

The processor compatibility mode is determined when the instance is powered on.

Desired compatibility mode

The processor compatibility mode that is wanted for the VM.

Operating system

The name and level of the operating system that is installed on the partition.

13. Figure 4-55 provides an example of the Specifications section for the recently added VM.

Figure 4-55 Virtual machine detailed view of the expanded Specifications section

14. Collapse the Specifications section and expand the Network Interfaces section. This section contains information that relates to the virtual network connectivity, as shown in Figure 4-56.

Figure 4-56 Virtual machine detailed view of expanded Network Interfaces section

15. Double-click Network Interfaces. Two tabs are shown. The Overview tab displays the Network detailed information, including the VLAN ID, the VIOSs that are involved, the SEAs, and other useful information. The IP Pool tab displays the range of IP addresses that make up the IP pool (if you previously defined it). Figure 4-57 shows the Network Overview tab.

Figure 4-57 Detailed Network Overview tab

16. The Collocation Rules section displays the collocation rules that are used to allocate the VM (if you configured collocation rules).

17. The last section of the Virtual Machine window is the Details section, which presents the status and the hypervisor names for the VM, as listed in Table 4-3.

Table 4-3 Details section’s fields

Field

Description

Power state

Power status for the VM

Task status

Whether a task is running on the VM and the status of the task

Hypervisor host name

The name of the host in the hypervisor and the HMC

Hypervisor partition name

The name of the VM in the hypervisor and the HMC

4.15.2 Refreshing the virtual machine view

Refresh reloads the information for the currently selected VM. Click Refresh to reload the information. Figure 4-58 shows the detailed Information section of the Overview tab for the selected VM.

Figure 4-58 Virtual machine Refresh icon

Note: On many IBM PowerVC windows, you can see a Refresh icon, as shown by the red highlighting in Figure 4-58 on page 143. Most windows update asynchronously through long polling in the background. Refresh is available if you think that the window does not show the latest data from those updates. (You suspect something went wrong with a network connection, or you want to ensure that the up-to-date data displays.) By clicking the Refresh icon, a Representational State Transfer (REST) call is made to the IBM PowerVC server to get the latest data that is available from IBM PowerVC.

Out-of-band operations

In the context of IBM PowerVC, the term out-of-band operation refers to any operation on an object that is managed by IBM PowerVC that is not performed from the IBM PowerVC tool. For example, an LPM operation that is initiated directly from an HMC is considered an out-of-band operation.

With the default polling interval settings, it might take several minutes for IBM PowerVC to be aware of the change to the environment as a result of an out-of-band operation.

4.15.3 Starting the virtual machine

From the Virtual Machines window, you can use the Start option to power on the currently selected VM. After the VM finishes the start process, the VM is available for operations that are performed through the IBM PowerVC management host. The process takes more time than the boot process of the operating system. IBM PowerVC waits until the RMC service is available to communicate with the VM. Even though the status field is Active (because the VM is powered on), the health field displays a message warning that is similar to “Reason: RMC state of VM vmaix01 is Inactive”. Wait for a few minutes for the health field to display a status of OK before you manage the VM from IBM PowerVC. Figure 4-59 shows the VM after it starts.

Figure 4-59 Virtual machine fully started

4.15.4 Stopping the virtual machine

From the VM’s detailed window, click Stop to shut down the VM.

Important: IBM PowerVC shows a window that asks for confirmation that you want to shut down the machine before IBM PowerVC acts.

When the VM completes the shutdown process, the state changes to Shutoff, as shown in Figure 4-60. This process takes a few minutes to complete.

Figure 4-60 Virtual machine powered off

Note: If an active RMC connection exists between IBM PowerVC and the target VM, a shutdown of the operating system is triggered. If no active RMC connection exists, the VM is shut down without shutting down the operating system.

4.15.5 Opening a console window

IBM PowerVC supports access to a virtual console for NovaLink-managed VMs from the user interface. This allows convenient command-line access without leaving the PowerVC web interface. Additionally, it provides access to a VM even if the VM's networking is not functioning correctly.

NovaLink managed hosts have an extra tab where you can access the system console, as shown in Table 4-61.

Figure 4-61 NovaLink managed host virtual console

4.15.6 Capturing a virtual machine image

You can capture an operating system image of a VM that you created or deployed. This image is used to install the operating system of the future VMs that are created from IBM PowerVC. Before you capture the VM, you must first prepare and enable it.

Note: To prepare the VM and to verify that all of the capture requirements are met, see t IBM Knowledge Center:

https://ibm.biz/BdXK6a

Requirements for capture

To be eligible for image capture, a VM must meet several requirements:

•The VM must use any of the operating system versions that are supported by
IBM PowerVC.

•Your IBM PowerVC environment is configured.

•The host on which the VM runs is managed by IBM PowerVC.

•The VM uses virtual I/Os and virtual storage; the network and storage devices are provided by the VIOS.

•The /var directory on the IBM PowerVC management hosts must have enough space (PowerKVM only).

When you capture VMs that use local storage, the /var directory on the management server is used as the repository for storing the images. The file system that contains the /var directory must have enough space to store the captured images. This amount can be several gigabytes, depending on the VM to capture.

•If you plan for a Linux VM with multiple paths to storage, you must configure Linux for multipath I/O (MPIO) on the root device.

Tip: Because the default Red Hat Enterprise Linux (RHEL) configuration creates a restricted list for all WWPN entries, you must remove them to enable the deployment of a captured image. The following RHEL link describes how to remove them:

https://ibm.biz/BdXapw

•If you want to capture an IBM i VM, multiple boot volumes are supported.

•The VM is powered off. When you power off a VM, the status appears as Active until the VM shuts down. You can select the VM for capture even if the status is displayed as Active.

Important: When you use cloud-init, you must shut down the VM manually before the capture.

•Operating systems that use a Linux Loader (LILO) or Yaboot boot loader, such as SUSE Linux Enterprise Server 10, SUSE Linux Enterprise Server 11, RHEL 5, and RHEL 6, require special steps when you use VMs with multiple disks. These operating systems must be configured to use a Universally Unique Identifier (UUID) to reference their boot disk. SUSE Linux Enterprise Server 11 virtual servers mount devices by using the -id option by default, which means that they are represented by symbolic links. To address this issue, you must perform one of the following configurations before you capture a SUSE Linux Enterprise Server VM for the first time:

 – Configure Linux for MPIO on the root device on VMs that are deployed to multiple VIOSs or multipath environments.

 – Update /etc/fstab and /etc/lilo.conf to use UUIDs instead of symbolic links.

To change the devices so that they are mounted by UUID, complete the following steps:

a. Search the file system table /etc/fstab for the presence of symbolic links. Symbolic links look like this example:

/dev/disk/by-*

b. Store the mapping of /dev/disk/by-* symlinks to their target devices in a scratch file and ensure that you use the device names in it, for example:

ls -l /dev/disk/by-* > /tmp/scratchpad.txt

c. The contents of the scratchpad.txt file are similar to Example 4-1.

Example 4-1 The scratchpad.txt file

/dev/disk/by-id:

total 0

lrwxrwxrwx 1 root root 9 Apr 10 12:07 scsi-360050768028180ee380000000000603c -> ../../sda

lrwxrwxrwx 1 root root 10 Apr 10 12:07 scsi-360050768028180ee380000000000603c-part1 -> ../../sda1

lrwxrwxrwx 1 root root 10 Apr 10 12:07 scsi-360050768028180ee380000000000603c-part2 -> ../../sda2

lrwxrwxrwx 1 root root 10 Apr 10 12:07 scsi-360050768028180ee380000000000603c-part3 -> ../../sda3

lrwxrwxrwx 1 root root 9 Apr 10 12:07 wwn-0x60050768028180ee380000000000603c -> ../../sda

lrwxrwxrwx 1 root root 10 Apr 10 12:07 wwn-0x60050768028180ee380000000000603c-part1 -> ../../sda1

lrwxrwxrwx 1 root root 10 Apr 10 12:07 wwn-0x60050768028180ee380000000000603c-part2 -> ../../sda2

lrwxrwxrwx 1 root root 10 Apr 10 12:07 wwn-0x60050768028180ee380000000000603c-part3 -> ../../sda3

total 0

lrwxrwxrwx 1 root root 9 Apr 10 12:07 scsi-0:0:1:0 -> ../../sda

lrwxrwxrwx 1 root root 10 Apr 10 12:07 scsi-0:0:1:0-part1 -> ../../sda1

lrwxrwxrwx 1 root root 10 Apr 10 12:07 scsi-0:0:1:0-part2 -> ../../sda2

lrwxrwxrwx 1 root root 10 Apr 10 12:07 scsi-0:0:1:0-part3 -> ../../sda3

/dev/disk/by-uuid:

total 0

lrwxrwxrwx 1 root root 10 Apr 10 12:07 3cb4e486-10a4-44a9-8273-9051f607435e -> ../../sda2

lrwxrwxrwx 1 root root 10 Apr 10 12:07 c6a9f4e8-4e87-49c9-b211-89086c2d1064 -> ../../sda3

d. Edit the /etc/fstab file. Replace the /dev/disk/by-* entries with the device names to which the symlinks point, as laid out in your scratchpad.txt file. Example 4-2 shows how the lines look before you edit them.

Example 4-2 The scratchpad.txt file

/dev/disk/by-id/scsi-360050768028180ee380000000000603c-part2 swap swap defaults 0 0

/dev/disk/by-id/scsi-360050768028180ee380000000000603c-part3 / ext3 acl,user_xattr 1 1

In this example, those lines are changed to refer to the specific device names, as shown in Example 4-3.

Example 4-3 Specific device names for the /etc/fstab file

/dev/sda2 swap swap defaults 0 0

/dev/sda3 / ext3 acl,user_xattr 1 1

e. Edit the /etc/lilo.conf file so that the root lines correspond to the device UUID and the boot line corresponds to the device names. Example 4-4 shows how the lines look before you edit them.

Example 4-4 The /etc/lilo.conf file

boot = /dev/disk/by-id/scsi-360050768028180ee380000000000603c-part1

root = /dev/disk/by-id/scsi-360050768028180ee380000000000603c-part3

In Example 4-5, those lines were changed to refer to the specific device names.

Example 4-5 Specific devices names for the /etc/lilo.conf file

boot = /dev/sda1

root = /dev/sda3

f. Run the lilo command.

g. Run the mkinitrd command.

Preparing a virtual machine with cloud-init

The cloud-init script enables VM activation and initialization, and it is widely used for OpenStack. Before you capture a VM, install the cloud-init initialization package. This package is available in the /opt/ibm/powervc/images/cloud-init path in the IBM PowerVC host.

Important: If you are installing the cloud-init package on AIX or Linux to capture a VM on which the AE is already installed, you must first uninstall the AE. To check whether the AE Red Hat Package Managers (RPMs) are installed, run the following command on the VM (IBM i does not require you to remove AE, just install the cloud-init PTF):

# rpm -qa | grep activation

Note: For IBM i, follow the instructions that are found at the following website to install and enable the cloud-init:

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM%20i%20Technology%20Updates/page/Cloud-Init%20Support

Complete the following steps:

1. Before you install cloud-init, you must install the dependencies for cloud-init. These dependencies are not included with the operating systems:

 – For SUSE Linux Enterprise Server, install the dependencies that are provided in the SUSE Linux Enterprise Server repository, found at:

ftp://ftp.unicamp.br/pub/linuxpatch/cloud-init-ppc64/sles11 (or sles12)

 – For RHEL, add the EPEL yum repository for the latest level of the dependent RPMs.

Use these commands for RHEL6, for example:

wget http://dl.fedoraproject.org/pub/epel/6Server/ppc64/epel-release-6-8.noarch.rpm

rpm -Uvh epel-release-6*.rpm

Use these commands for RHEL 7, for example:

wget http://dl.fedoraproject.org/pub/epel/7/ppc64/e/epel-release-7-5.noarch.rpm

rpm -Uvh epel-release-7*.rpm

 – For AIX, follow the instructions that are found at the following website to download the cloud-init dependencies:

ftp://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/RPMS/ppc/cloudinit

2. Install the appropriate cloud-init RPM for your operating system, which is in /opt/ibm/powervc/images/cloud-init.

However, if the VM already has an installed cloud-init RPM, you must uninstall the existing RPM first:

 – For RHEL, install the appropriate RPM from /opt/ibm/powervc/images/cloud-init/rhel:

 • RHEL 6: cloud-init-0.7.4-5.el6.noarch.rpm

 • RHEL 7: cloud-init-0.7.4-5.el7.noarch.rpm

 – For SUSE Linux Enterprise Server, install the appropriate RPM from /opt/ibm/powervc/images/cloud-init/sles:

 • SUSE Linux Enterprise Server 11: cloud-init-0.7.4-2.4.ppc64.rpm

 • SUSE Linux Enterprise Server 12: cloud-init-0.7.5-8.10.ppc64le.rpm

 – For Ubuntu Linux, install the appropriate RPM from /opt/ibm/powervc/images/cloud-init/ubuntu:

Ubuntu 15: cloud-init_0.7.7~bzr1091-0ubuntu1_all.deb

 – For AIX, download the AIX cloud-init RPM from the following website:

ftp://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/RPMS/ppc/cloudinit

3. After you install cloud-init, modify the cloud.cfg file, which is in opt/freeware/etc/cloud/cloud.cfg, by using the following values:

 – For RHEL, set the following values:

disable_root: 0

ssh_pwauth: 1

ssh_deletekeys: 1

 – For SUSE Linux Enterprise Server, perform these tasks:

 • Remove the following field:

users: -root

 • Add the following fields:

ssh_pwauth: true

ssh_deletekeys: true

 – For both RHEL and SUSE Linux Enterprise Server, add the following new values to the cloud.cfg file:

disable_ec2_metadata: True

datasource_list: ['ConfigDrive']

 – For SUSE Linux Enterprise Server only, after you update and save the cloud.cfg file, run the following commands:

chkconfig -s cloud-init-local on

chkconfig -s cloud-init on

chkconfig -s cloud-config on

chkconfig -s cloud-final on

 – For RHEL 7, ensure that the following conditions are set on the VM that you are capturing:

 • Set SELinux to permissive or disabled on the VM that you are capturing or deploying.

 • Ensure that if Network Manager is installed, it is disabled.

 • Ensure that the net-tools package is installed.

Note: This package is not installed by default when you select the Minimal Install software option during the installation of RHEL 7 from an International Organization for Standardization (ISO) image.

 • Edit all of the /etc/sysconfig/network-scripts/ifcfg-eth* files to update their NM_CONTROLLED = no settings.

4. Remove the Media Access Control (MAC) address information. For more information about how to remove the MAC address information, see the OpenStack website:

http://docs.openstack.org/image-guide/content/ch_openstack_images.html

Important: The /etc/sysconfig/network-scripts file path that is mentioned in the OpenStack website about the HWADDR must be applied only to RHEL. For SUSE Linux Enterprise Server, the HWADDR path is /etc/sysconfig/network.

For example, for the ifcfg-eth0 adapter, on RHEL, remove the HWADDR line from /etc/sysconfig/network-scripts/ifcfg-eth0, and on SUSE Linux Enterprise Server, remove the HWADDR line from /etc/sysconfig/network/ifcfg-eth0.

The 70-persistent-net.rules and 75-persistent-net-generator.rules files are required to add or remove network interfaces on the VMs after deployment. Ensure that you save these files so that you can restore them after the deployment is complete. These rules files are not supported by RHEL 7. Therefore, after you remove the adapters, you must update the adapter configuration files manually on the VM to match the current set of adapters.

5. Enable and configure the modules (Table 4-4) and host name behavior by modifying the cloud.cfg file as follows:

 – Linux: /etc/cloud/cloud.cfg.

 – AIX: /opt/freeware/etc/cloud/cloud.cfg.

 – As a preferred practice, enable reset-rmc and update-bootlist on Linux.

 – Host name: If you want to change the host name after the deployment, remove "-update_hostname" from the list of cloud_init_modules. If you do not remove it, cloud-init resets the host name to the original host name deployed value when the system is restarted.

Table 4-4 Modules and descriptions

Module

Description

restore_volume_group

This module restores non-rootVG volume groups when you deploy a new VM.

For AIX, run the /opt/freeware/lib/cloud-init/create_pvid_to_vg_mappings.sh command to save the information that is used to restore custom volume groups on all VMs that are deployed from the image that is captured. Saving this information is useful if you have a multidisk VM that has a dataVG volume group defined. The module restores the dataVG after the deployment.

set_multipath_hcheck_interval

Use this module to set the hcheck interval for multipath. If you deploy a multidisk VM and this module is enabled, you can deploy specifying a cloud-config data entry that is named "multipath_hcheck_interval" and give it an integer value that corresponds to seconds. Post-deployment, each of the VM’s disks must have their hcheck_interval property set to the value that was passed through the cloud-config data. Run the lsattr -El hdisk# -a hcheck_interval command for verification. If you do not specify the value within the cloud-config data, the module sets each disk’s value to 60 seconds.

set_hostname_from_dns

Use this module to set your VM’s host name by using the host name values from your Domain Name Server (DNS). To enable this module, add this line to the cloud_init_modules section:

- set_hostname_from_dns

Then, remove these lines:

- set_hostname

- update_hostname

set_hostname_from_interface

Use this module to choose the network interface and IP address to be used for the reverse lookup. The valid values are interface names, such as eth0 and en1. On Linux, the default value is eth0. On AIX, the default value is en0.

set_dns_shortname

This module specifies whether to use the short name to set the host name. Valid values are True to use the short name or False to use the fully qualified domain name. The default value is False.

You can also deploy with both static and DHCP interfaces on SUSE Linux Enterprise Server 11 and SUSE Linux Enterprise Server 12:

 – If you want cloud-init to set the host name, in the /etc/sysconfig/network/dhcp file, set the DHCLIENT_SET_HOSTNAME option to no.

 – If you want cloud-init to set the default route by using the first static interface, which is standard, set the DHCLIENT_SET_DEFAULT_ROUTE option in the /etc/sysconfig/network/dhcp file to no.

If you do not set these settings to no and then deploy with both static and DHCP interfaces, the DHCP client software might overwrite the value that cloud-init sets for the host name and default route, depending on how long it takes to get DHCP leases for each DHCP interface.

 – reset-rmc: This module automatically resets RMC. This action is enabled by default on AIX. It can be enabled on Linux by adding - reset-rmc to the cloud_init_modules: section.

 – update-bootlist: This module removes the temporary virtual optical device, which is used to send configuration information to the VM, from the VM’s bootlist. This action is enabled by default on AIX. It can be enabled on Linux by adding - update-bootlist to the cloud_init_modules: section.

6. For AIX, run the /opt/freeware/lib/cloud-init/create_pvid_to_vg_mappings.sh command to save the information that is used to restore custom volume groups on all VMs that are deployed from the image that will be captured.

7. Manually shut down the VM:

sudo shutdown -h now

Capturing the virtual machine image

To capture a VM image, complete the following steps:

1. After you complete the previous steps to install and prepare the VM for capture, log on to the IBM PowerVC GUI. Go to the Virtual Machines view. Select the VM that you want to capture and click Capture on the top menu. A Warning message appears asking you to perform the manual preparation. Click Continue.

2. Use IBM PowerVC to choose the name for your future image and select the volumes (either boot volumes or data volumes) that you want to capture.

When you capture a VM, all volumes that belong to its boot set are included in the image that is generated by the capture. If the VM is brought into IBM PowerVC management, the boot set consists of all volumes that are marked as the boot set when IBM PowerVC manages the VM.

If the VM is deployed from an image that is created within IBM PowerVC, the boot set consists of all volumes that the user chooses as the boot set when the user creates the image. Unlike the volumes that belong to the VM’s boot set, the user can choose which data volumes to include in the image that is generated by the capture. Figure 4-62 shows an example of choosing to capture both boot volumes and data volumes. Click Capture.

Figure 4-62 Capture boot and data volumes

3. IBM PowerVC shows a confirmation window that lists all of the VM volumes that were chosen for capture (Figure 4-63). Click Capture again to start the capture process.

Figure 4-63 Capture window confirmation

4. When the image capture is complete, the state in the Images view changes to Active, as shown in Figure 4-64.

Figure 4-64 New Image

5. The IBM PowerVC management host captures the image in the same way that it manages adding a volume to the system, but it adds information to use this volume as an image. This information enables the image to appear in the Image view to deploy new VMs.

6. Click the Images icon on the left bar to return to the Images view. Select the image to display its information in detail. Double-click the image to open a window that is similar to the window that is shown in Figure 4-65.

Figure 4-65 Expanded information for a captured image

7. Table 4-5 explains each field in the Information section.

Table 4-5 Description of the fields in the Information section

Field

Description

Name

Name of the image capture

State

Current state of the image capture

ID

Unique identifier number for the resource

Description

Quick description of the image

Checksum

Verification sum for the resource

Captured VM

Name of the VM that was used to create the image

Created

Created date and time

Last updated

Last updated date and time

8. Table 4-6 explains each field of the Specifications section.

Table 4-6 Description of the fields in the Specifications section

Field

Description

Image type

Description of the image type

Container format

Type of container for the data

Disk format

The specific format for the disk

Operating system

The operating system on the image

Hypervisor type

The name of the hypervisor that is managing the image

Architecture

Architecture of the image

Endianness

Big Endian or Little Endian

9. The Volumes section displays all of the storage information about the image.

10. The Virtual Machines section displays the list of VMs that were deployed by using this image. The Virtual Machines section is shown in Figure 4-66.

Figure 4-66 Volumes section and Virtual Machines section

4.15.7 Deploying a new virtual machine

You can deploy a new VM by reusing one of the images that was captured, as described in 4.15.5, “Opening a console window” on page 145. You can deploy to a specific host, or the placement policy can choose the best location for the new VM. For more information about the placement policy function, see 2.4, “Placement policies and templates” on page 25.

Important: If you do not set a default domain name in the nova.conf file, IBM PowerVC uses the domain that is set for the VIOS on the host to which you are deploying. If IBM PowerVC cannot retrieve that value, it uses the domain name of the IBM PowerVC management host. If it cannot retrieve that value, no domain name is set and you must set the domain name manually after you deploy the image.

IBM PowerVC Version 1.3.2 has the following limits regarding deployments:

•IBM PowerVC supports a maximum of 50 concurrent deployments. As a preferred practice, do not exceed eight concurrent deployments for each host.

•Running more than 10 concurrent deployment operations might require additional memory and processor capacity on the IBM PowerVC management host.

•If you use only SAN storage and you plan to batch-deploy over 100 VMs that are based on one image, you must make multiple copies of that image and deploy the VMs in batches of 10.

The following settings might increase the throughput and decrease the duration of deployments:

•Use the striping policy instead of the packing policy.

•Limit the number of concurrent deployments to match the number of hosts.

The host group and storage connectivity group that you select determine the hosts that are available as target hosts in the deployment operation. For more information, see 2.6.3, “Storage connectivity groups and tags” on page 46.

You can initiate a new deployment from the Images window to list the available images. Complete the following steps:

1. Select the image that you want to install on the VM that you create. The selected image background changes to light blue. Then, click Deploy.

2. IBM PowerVC opens a new window where you must define information about the new VM. Figure 4-67 presents an example of this window.

Figure 4-67 Information to deploy an image

In advance, during the planning phase of the partition creation, you defined the following information:

 – VM name

 – Instances

If you have a DHCP server or an IP pool that is configured, you can deploy several VMs simultaneously.

 – Host or host group

Manually select the target host where the new VM will be deployed, or select the host group so that IBM PowerVC selects the host based on the configured policy. For details about the automatic placement of partitions, see 2.4, “Placement policies and templates” on page 25.

 – Key Pair

When deploying a VM from IBM PowerVC, you can inject an SSH public key into the deployed VM. Users can then use the corresponding private key to connect to the deployed VM. This removes the need to have a known password embedded in the image.

To add a key, click the help button right next to Key Pair and enter the Key Pair window. Then, create an Import Public Key button to add your key.

 – Storage connectivity group

Select one storage connectivity group for the new VM to access its storage. IBM PowerVC can use a storage connectivity group to determine the use of vSCSI or NPIV to access SAN storage. For details about the selection of the storage path and FC ports to use, see 2.6.3, “Storage connectivity groups and tags” on page 46.

 – Compute template

Select the compute template that you want to use to deploy the new VM with standard resource definitions. For detailed information about planning for CPU and memory resources by using templates, see 2.4.4, “Information that is required for compute template planning” on page 30.

You can see in Figure 4-67 on page 157 that IBM PowerVC displays the values pre-set in the template in fields that can be overwritten. You can change the amount of resources that you need for this new VM.

 – Image volumes

Since IBM PowerVC Version 1.2.3, you can capture a multiple-volume image. In this case, two volumes are included in the image. You must select the storage template that you want for each volume to deploy the new VM with predefined storage capacity. You can select different storage templates for those volumes to meet your business needs. IBM PowerVC presents a drop-down menu that lists the storage templates that are available in the storage provider in which the image volumes are stored.

 – New and existing volumes

You can add new or existing volumes in addition to the volumes that are included in the image. To add volumes, click Add volume. The Add Volume window, where you attach a volume to the VM, opens.

 – Network:

 • Primary network

Select the network. If the selected network does not have a configured DHCP server, you must also manually provide an IP address, or IBM PowerVC selects an IP address from the IP pool.

 • Additional networks

If two or more networks were defined in IBM PowerVC, you can click the plus sign (+) icon to add more networks. Select the network. Get the IP address from the DHCP server, provide the IP address manually, or select one from the IP pool automatically.

Note: IBM PowerVC verifies that the IP address that you provide is not already used for another VM, even if the IP address is used in a VM that is powered off.

 – Activation input

You can upload configuration scripts or add configuration data at the time of deploying a VM by using the activation input option. This script or data automatically configures your VM according to your requirements after it is deployed. For more information about the accepted data formats in cloud-init and examples of commonly used cloud configuration data formats, see the cloud-init documentation.

Note: The file or scripts that you upload and add here are used by the cloud-init initialization package and the AE for AIX VMs only. The AE for AIX VMs supports shell scripts that start with #! only, and it does not support the other cloud-init data formats. For any other operating system, the AE does not use the data that you upload for activation.

Note: On the right part of the window, IBM PowerVC displays the amount of available resources on the target host and the amount of additional resources that are requested for the new partition. So, you can see the amount of resources that are used and free on this host after the installation of the new partitions.

For more information about activation input, see IBM Knowledge Center:

http://www.ibm.com/support/knowledgecenter/SSXK2N_1.3.2/com.ibm.powervc.standard.help.doc/powervc_deploy_considerations.html

3. Click Deploy in the lower part of the window to start the deployment of the new VM. This process might take a few minutes to finish.

Important: For other vendor’s storage devices, no technique is available that is like the IBM FlashCopy® service in IBM Storwize storage. They use LUN migration instead. A deployment might take an hour to complete. The amount of time depends on the volumes’ sizes and the storage device performance. Contact your storage administrator before you design your IBM PowerVC infrastructure.

4. When the deployment finishes, you can see a new VM in the Virtual Machines window. This new VM is a clone of the captured image. The new VM is already configured and powered on.

Tip: The new VM is a clone of the image, so you can log on to this VM with the same user ID and password combination that is defined in the VM from which the image was captured.

Adding virtual Ethernet adapters for virtual machines

After the VM was deployed successfully, you can add more virtual Ethernet adapters for the VM if you defined more networks in IBM PowerVC. In a VM, IBM PowerVC allows only one virtual Ethernet adapter for each network. Complete the following steps:

1. To add a virtual Ethernet adapter for a VM, select the VM name on the Virtual Machines window.

2. Go to the VM’s details window. As shown in Figure 4-68, in the Network Interfaces section, click Add.

3. Select the network that you want to connect. Assign an IP address or IBM PowerVC selects an IP address from the IP pool.

4. Click Add Interface. A new virtual Ethernet adapter is added for the VM.

Figure 4-68 Add an Ethernet adapter for a virtual machine

Note: After you add the virtual Ethernet adapter, you must refresh the hardware list in the partition. For example, run the cfgmgr command in AIX to assign the IP address to the newly discovered Ethernet adapter manually.

Adding collocation rules

Use collocation rules to specify that selected VMs must always be kept on the same host (affinity) or that they can never be placed on the same host (anti-affinity). These rules are enforced when a VM is relocated or when it is first created. For example, in PowerHA scenarios, you must force the pair of high availability (HA) VMs to exist on different physical machines. Otherwise, a single point of failure (SPOF) risk exists. Use the anti-affinity collocation rule to create this scenario.

To create a collocation rule, click Configuration → Collocation Rules → Create Collocation Rule, as shown in Figure 4-69. Enter the collocation rule name, select the policy type (either Affinity and Anti-Affinity), select the VMs, and click Create. The collocation rule creation is complete.

Figure 4-69 Create Collocation Rule

Important: When VMs are migrated or restarted remotely, one VM is moved at a time, which has the following implications for VMs in collocation rules that specify affinity:

•The VMs cannot be migrated or restarted remotely on another host.

•When you put a host into maintenance mode, if that host has multiple VMs in the same collocation rule, you cannot migrate active VMs to another host.

To migrate a VM or restart a VM remotely in these situations, the VM must first be removed from the collocation rule. After the VM is migrated or restarted remotely, the VM can be added to the correct collocation rule.

4.15.8 Resizing the virtual machine

The IBM PowerVC management host can resize the managed VMs dynamically. Complete the following steps:

1. From the Virtual Machines window, click Resize on the upper bar on the window, as shown in Figure 4-70.

Figure 4-70 Virtual Machines: Resize

2. In the next window (Figure 4-71), enter the new values for the resources or choose an existing compute template. Select the option that fits your business needs.

Figure 4-71 VM Resize window to select a compute template

When you enter the new value, it is verified and checked against the minimum and maximum values that are defined in the partition profile. If the requested new values exceed these limits for the VM, IBM PowerVC rejects the request, highlights the field with a red outline, and issues an error notice, as shown in Figure 4-72.

Figure 4-72 Exceeded value for resizing

3. After you complete the information that is required in this window, click Resize to start the resizing process. You see a message window in the lower-right part of the window and a “Complete” message in the message view.

Tip: The IBM PowerVC management server compares the entered values with the values in the profile of the selected VM. If you modify the VM profile, you must shut down and restart the VM for the changes to take effect.

Important: To refresh the profile, shut down and restart the VM rather than just restart it. Restarting the VM keeps the current values rather than reading the new values that you set in the profile.

4. The resize process can take a few minutes. When it finishes, you can see the new sizes in the Specifications section of the VM.

Note: With the IBM PowerVC resize function, you can change the current settings of the machine only. You cannot use the resize function to change the minimum and maximum values that are set in the partition profile or to change a partition from shared to dedicated.

4.15.9 Migration of virtual machines

IBM PowerVC can manage the LPM feature. Use the LPM feature to migrate VMs from one host to another host.

Migration requirements

To migrate VMs by using the IBM PowerVC management server, ensure that the source and destination hosts and the VMs are configured correctly.

To migrate a VM, the following requirements must be met:

•The VM is in Active status in the IBM PowerVC management host.

•The PowerVM Enterprise Edition or PowerVM for IBM Linux on Power hardware feature is activated on your hosts. This feature enables the use of the LPM feature.

•The networks for both source and target hosts must be mapped to SEAs by using the same virtual Ethernet switch.

•As a preferred practice, set the maximum number of virtual resources (virtual adapters) to at least 200 on all of the hosts in your environment. This value ensures that you can create enough VMs on your hosts.

•The logical memory block size on the source host and the destination host must be the same.

•Both the source and destination hosts must have an equivalent configuration of VIOSs that belong to the same storage connectivity group.

Note: If the source host has two VIOSs and the target host has only one VIOS, it is not possible to migrate a partition by accessing its storage through both VIOSs on the source. However, if a partition on the source host is using only one VIOS to access its storage, it can be migrated (assuming that other requirements, such as port tagging, are met).

•The processor compatibility mode on the VM that you want to migrate must be supported by the destination host.

•The AIX/Linux VM must have an enabled RMC connection. IBM i does not require RMC.

•To migrate a VM with a vSCSI attachment, the destination VIOS must be zoned to the backing storage.

•At least one pair of VIOS VMs must be storage-ready and members of the storage connectivity group. Each of these VIOS VMs must have at least two physical FC ports ready.

•Each of the two physical FC ports must be connected to a distinct fabric, and the fabric must be set correctly on the FC ports’ Configuration pages.

The following restrictions apply when you migrate a VM:

•You cannot migrate a VM to a host that is a member of a different host group.

•If the VM is running a Little Endian guest, the target host must support Little Endian guests.

•If the VM was created as remote restart-capable, the target host must support remote restart.

•Certain IBM Power System servers can run only Linux workloads. When you migrate an AIX or IBM i VM, these hosts are not considered for placement.

•You cannot exceed the maximum number of simultaneous migrations that are designated for the source and destination hosts. The maximum number of simultaneous migrations depends on the number of migrations that are supported by the VIOSs that are associated with each host.

•A source host in a migration operation cannot serve concurrently as a destination host in a separate migration operation.

•If you deployed a VM with a processor compatibility mode of POWER7 and later changed the mode to POWER6, you cannot migrate the VM to a POWER6 host. The MAC address for a POWER7 VM is generated by IBM PowerVC during the deployment.

•To migrate to a POWER6 host, the MAC address of the VM must be generated by the HMC. To migrate from a POWER7 to a POWER6 host, you must initially deploy to a POWER7 system with the processor compatibility mode set to a POWER6 derivative, or you must initially deploy to a POWER6 host.

•PowerVM does not support the migration of a VM whose attachment type changes its multipathing solution between the source and destination VIOSs. For example, a VM on a path-control module (PCM)-attached VIOS can be successfully migrated only to a PCM-attached VIOS. However, PowerVM does not enforce this requirement. To avoid unsupported migrations, create separate storage connectivity groups for PCM and PowerPath multipathing solutions.

•Collocation rules are enforced during migration:

 – If the VM is a member of a collocation rule that specifies affinity and multiple VMs are in that collocation rule, you cannot migrate it. Otherwise, the affinity rule is broken. To migrate a VM in this case, remove it from the collocation rule and then add it to the correct group after the migration.

 – If the VM is a member of a collocation rule that specifies anti-affinity, you cannot migrate it to a host that has a VM that is a member of the same collocation rule. For example, assume the following scenario:

 • VM A is on Host A.

 • VM B is on Host B.

 • VM A and VM B are in a collocation rule that specifies anti-affinity.

Therefore, VM A cannot be migrated to Host B.

 – Only one migration or remote restart at a time is allowed for VMs in the same collocation rule. Therefore, if you try to migrate a VM or restart a VM remotely and any other VMs in the same collocation rule are being migrated or restarted remotely, that request fails.

Migrating the virtual machine

To migrate a VM, complete the following steps:

1. Open the Virtual Machines window and select the VM that you want to migrate. The background changes to light blue.

2. Click Migrate, as shown in Figure 4-73.

Figure 4-73 Migrate a selected virtual machine

3. You can select the target host or the placement policy can determine the target, as shown in Figure 4-74.

Figure 4-74 Select the target server before the migration

4. Figure 4-75 shows that during the migration, the Virtual Machines window shows the partition with the state and task both set to Migrating.

Figure 4-75 Virtual machine migration in progress

5. After the migration completes, you can check the Virtual Machines window to verify that the partition is now hosted on the target host, as shown in Figure 4-76.

Note: A warning message in the Health column is normal. It takes a few minutes to change to OK.

Figure 4-76 Virtual machine migration finished

4.15.10 Host maintenance mode

You move a host to maintenance mode to perform maintenance activities on a host, such updating firmware or replacing hardware.

Maintenance mode requirements

Before you move the host into maintenance mode, check whether the following requirements are met:

•If the request was made to migrate active VMs when the host entered maintenance mode, the following conditions must also be true:

 – The hypervisor must be licensed for LPM.

 – The VMs on the host cannot be in the Error, Paused, or Building states.

 – On all active VMs, the health must be OK and the RMC connections of the AIX/Linux VMs must be Active.

 – All requirements for live migration must be met, as described in “Migration requirements” on page 164.

•The host’s hypervisor state must be Operating. If it is not, VM migrations might fail.

•If the request was made to migrate active VMs when the host entered maintenance mode, the following conditions cannot also be true, or the request fails:

 – A VM on the host is a member of a collocation rule that specifies affinity and has multiple members.

 – The collocation rule has a member that is already undergoing a migration or is being restarted remotely.

Putting the host in maintenance mode

If all of the requirements are met, you can put a host in maintenance mode by following these steps:

1. On the Hosts window, select the host that you want to put into maintenance mode, and click Enter Maintenance Mode, as shown in Figure 4-77.

Figure 4-77 Enter Maintenance Mode

2. If you want to migrate the VMs to other hosts, select Migrate active virtual machines to another host, as shown in Figure 4-78. This option is unavailable if no hosts are available for the migration.

Figure 4-78 Migrate virtual machines to other hosts

3. Click OK.

After maintenance mode is requested, the host’s maintenance state is Entering Maintenance while the VMs are migrated to another host, if requested. This status changes to Maintenance On after the migration is complete and the host is fully in the maintenance state.

To remove a host from maintenance mode, select the host and select Exit Maintenance Mode. Click OK on the confirmation window, as shown in Figure 4-79.

Figure 4-79 Exit Maintenance Mode

You can add VMs again to the host after it is brought out of maintenance mode.

Tip: You can edit the period after which the migration operation times out and the maintenance mode enters an error state by running the following commands:

/usr/bin/openstack-config --set /etc/nova/nova.conf DEFAULT prs_ha_timeout_seconds <duration_in_seconds>

For example, to set the timeout for two hours, run this command:

/usr/bin/openstack-config --set /etc/nova/nova.conf DEFAULT prs_ha_timeout_seconds 7200

Then, restart openstack-nova-ibm-ego-ha-service:

service openstack-nova-ibm-ego-ha-service restart

4.15.11 Restarting virtual machines remotely from a failed host

IBM PowerVC can restart VMs remotely from a failed host to another host. To successfully restart VMs remotely by using IBM PowerVC, you must ensure that the source host and destination host are configured correctly.

Automated Remote Restart is a new feature in IBM PowerVC 1.3.2 that provides automated capability. For more information, see 4.5.2, “Host Groups” on page 104.

Remote restart requirements

To restart a VM remotely, the following requirements must be met:

•The source and destination hosts must have access to the storage that is used by the VMs.

•The source and destination hosts must have all of the appropriate virtual switches that are required by networks on the VM.

•The hosts must be running firmware 820 or later.

•The HMC must be running with HMC 820 Service Pack (SP) 1 or later, with the latest program temporary fix (PTF).

•The hosts must support the simplified remote restart capability.

•Both hosts must be managed by the same HMC.

•The service processors must be running and connected to the HMC.

•The source host must be in the Error, Power Off, or Error - dump in progress state on the HMC.

•The VM must be created with the simplified remote restart capability enabled.

•The remote restart state of the VM must be Remote restartable.

•SSPs are not officially supported through PowerVM simplified remote restart.

Restarting a virtual machine remotely

Before you can restart a VM on PowerVM remotely, you must deploy or configure the VM with remote restart capability. You can deploy or configure the VM with remote restart capability in two ways:

•Create a compute template with the enabled remote restart capability and deploy a VM with that compute template, as shown in Figure 4-80.

Figure 4-80 Create a compute template with enabled remote restart capability

•Modify the remote restart property after the VM is deployed. In Figure 4-81, you can see a VM with the correct remote restart state, which is Remote restartable.

Figure 4-81 Correct remote restart state under the Specifications section

Note: You can change the remote restart capability of a VM only if the VM is shut off.

Important: A VM can be restarted remotely in PowerVM only if the Remote Restart state is Remote restartable. When a VM is deployed initially, the HMC must collect partition and resource configuration information. The remote restart state changes from Invalid to different states. When it changes to Remote restartable, IBM PowerVC can initiate the remote restart operation for that VM.

The Remote Restart task is available under the Hosts view, as shown in Figure 4-82.

Figure 4-82 Remotely Restart Virtual Machines option

To restart a VM remotely, select the failed host and then select Remotely Restart Virtual Machines. Then, you can select to either restart a specific VM remotely or restart all of the VMs on the failed host remotely, as shown in Figure 4-83.

Figure 4-83 Remotely Restart Virtual Machines

The scheduler can choose a destination host automatically by placement policy, or you can choose a destination host (Figure 4-84).

Figure 4-84 Destination host

A notification on the user interface indicates that a VM was successfully restarted remotely.

When you select to restart all VMs on a failed host remotely, the host experiences several transitions. Table 4-7 shows the host states during the transition.

Table 4-7 Host states during the transition

State

Description

Remote Restart Started

IBM PowerVC is preparing to rebuild the VMs. This process can take up to one minute.

Remote Restart Rebuilding

IBM PowerVC is rebuilding VMs. After the VMs are restarted remotely on the destination host, the source host goes back to displaying its state.

Remote Restart Error

An error occurred while one or more VMs were moved to the destination host. You can check the reasons for the failure in the corresponding compute log file in the /var/log/nova directory.

4.15.12 Attaching a volume to the virtual machine

The IBM PowerVC management server can handle storage volumes.

Note: IBM i does not support shared volumes.

By using the management server, you can attach a new or existing volume to a VM. Complete the following steps:

1. Click the Virtual Machines icon on the left, and then select the VM to which you want to attach a volume and select Attach Volume. Attach Volume offers a choice to attach an existing volume to a VM or create a volume, as shown in Figure 4-85.

Figure 4-85 Attaching a new volume to a virtual machine

Note: You can select the Enable sharing check box so that other VMs can use the volume also, if needed.

2. Select the storage template to select the backing device, choose the volume name, and choose the volume size in GBs. You can add a short description for the new volume. The Storage bar on the right side of the window changes dynamically when you change the size. Click Attach. IBM PowerVC creates a volume, attaches it to the VM, and then displays a message at the bottom of the window to confirm the creation of the disk.

3. To see the new volume, open the VM’s detailed information window and select the Attached Volumes tab. This tab displays the current volumes that are attached to the VM, as shown in Figure 4-86.

Figure 4-86 Attached Volumes tab view

4. To complete the process, you must run the correct command on the VM command line:

 – For IBM AIX operating systems, run this command as root:

cfgmgr

 – For Linux operating systems, run this command as root, where host_N is the controller that manages the disks on the VM:

echo “- - -” > /sys/class/scsi_host/host_N/scan

4.15.13 Detaching a volume from the virtual machine

To detach a volume from the VM, you must first remove it from the operating system.

Note: As preferred practice, cleanly unmount all file systems from the disk, remove the logical volume, and remove the disk from AIX before you detach the disk from
IBM PowerVC.

Removing the volume from the operating system

For the IBM AIX operating system, run this command as root, where hdisk_N is the disk that you want to remove:

rmdev -dl hdisk_N

For the Linux operating system, restart after you detach the volume.

Detaching the volume from a virtual machine

The IBM PowerVC management server can handle storage volumes. By using the
IBM PowerVC management server, you can detach an existing volume from a VM. Complete the following steps:

1. Click the Virtual Machines icon, and then double-click the VM from which you want to detach a volume.

2. Click the Attached Volumes tab to display the list of volumes that are attached to this VM. Select the volume that you want to detach.

3. Click Detach, as shown in Figure 4-87.

Figure 4-87 Detach a volume from a virtual machine

4. IBM PowerVC shows a confirmation window (Figure 4-88).

Figure 4-88 Confirmation window

5. You see a Detaching status in the State column. When the process finishes, the volume is detached from the VM.

The detached volume is still managed by the IBM PowerVC management host. You can see the volume from the Storage window.

4.15.14 Resetting the state of a virtual machine

In certain situations, a VM becomes unavailable or it is in an unrecognized state for the
IBM PowerVC management server. When these situations occur, you can run a Reset State procedure. This process sets the machine back to an Active state.

Figure 4-89 shows a VM’s detailed information window with a Reset State hot link that appears on the State line of the Information section. Click Reset State to start the reset process.

Note: No changes are made to the connection or database.

Figure 4-89 Reset the virtual machine’s state

The IBM PowerVC management server displays a confirmation window. Click OK to continue or Cancel to abort.

Note: This process can take a few minutes to complete. If the state does not change, try to restore the VM or deploy the VM again from an image.

4.15.15 Deleting images

To delete an image that is not in use, open the Images window, select the image that you want to delete, and click Delete, as shown in Figure 4-90.

Figure 4-90 Image that is selected for deletion

The IBM PowerVC management server displays a confirmation window to delete this image, as shown in Figure 4-91.

Figure 4-91 Delete an image confirmation window

IBM PowerVC shows a message that the image is being deleted and confirmation of a successful completion of the operation. The image is deleted from IBM PowerVC and the original volume that is used by this is image is left untouched.

4.15.16 Unmanaging a virtual machine

The Unmanage function is used to discontinue the management of a VM from IBM PowerVC. After a VM becomes unmanaged, the VM is no longer listed in the Virtual Machines window, but the VM still exists. The VM and its resources remain configured on the host. The VM can still be managed from the HMC. The VM remains running.

To unmanage a VM, open the Virtual Machines window, and select the VM that you want to remove from IBM PowerVC. The Unmanage option is enabled. Click Unmanage to remove this VM from the IBM PowerVC environment.

Figure 4-92 shows the Unmanage option to unmanage a VM.

Figure 4-92 Unmanage an existing virtual machine

4.15.17 Deleting a virtual machine

IBM PowerVC can delete VMs completely from your systems.

Important: By deleting a VM, you completely remove the VM from the host system and from the HMC or PowerVM NovaLink configuration, and IBM PowerVC no longer manages it. Volumes that are used by VM can be deleted with granularity.

To remove a VM, open the Virtual Machines window and select the VM that you want to remove. Click Delete, as shown in Figure 4-93.

Figure 4-93 Delete a virtual machine

The IBM PowerVC management server displays a confirmation window to select the volumes with the VM that will be deleted. Volumes that will be deleted can be selected with a granularity of Boot volumes, All Volume, or Select Volumes as shown in (Figure 4-93 on page 179). To select Volumes manually, select Selected Volumes, click Select Volumes, and delete volumes from the Select Volumes windows, as shown in Figure 4-94. To permanently delete the VM, click Delete. IBM PowerVC shows a confirmation to delete VM and its selected resources.

Figure 4-94 Select Volumes window to delete selected volumes

Important: You can delete a VM while it is running. The process stops the running VM and then deletes it.

When IBM PowerVC deletes storage, it behaves differently, depending on how volumes were created:

•Volumes that were created by IBM PowerVC (the boot volumes) are deleted and removed from the VIOS and storage back ends.

•Volumes that were attached to the partition are detached only during the partition deletion.

The zoning to storage is removed by the deletion operation.

4.16 Users, groups, and roles setup

Each user is added, modified, or removed by the system administrator by using Linux operating system commands. After the user ID is defined on the operating system, the user ID becomes available in IBM PowerVC if it is granted an IBM PowerVC role (see 2.8.2, “Projects and role management planning” on page 61), such as admin, deployer, or viewer.

Operating system-based user management requires command-line experience, but it is easy to maintain. No dependency exists on other servers or services. To see user accounts in the IBM PowerVC management hosts, click Configuration → Users in the top navigation bar of the IBM PowerVC GUI. Use the underlying Linux commands to manage your account (useradd, usermod, or userde, for example).

4.16.1 Adding user accounts

To add a user account to the operating systems on the IBM PowerVC management host, run the following command as root from the Linux command-line interface (CLI):

# useradd [options] login_name

Assume that you want to create a user ID for a system administrator who is new to
IBM PowerVC. You want to allow this administrator to view the IBM PowerVC environment only, not to act on any of the managed objects. Therefore, you want to give this administrator only a viewer privilege.

By using the command that is shown in Example 4-6, create the user viewer1, with /home/viewer1 as the home and base directory, the viewer group as the main group, and a comment with additional information, such as IBM PowerVC.

Example 4-6 Add an admin user account with the useradd command

useradd -d /home/viewer1 -g viewer -m -c "IBM PowerVC" viewer1

If you have a clean installation, run the following command to assign a viewer role to a user:

# openstack role add --user viewer1 --project <project_name_or_id> viewer

If the group exists after an upgrade, give that group the viewer role assignment by running the following command:

# openstack role add --group viewer --project <project_name_or_id> viewer

The new user is created with the viewer role in the IBM PowerVC management host because it is part of the viewer user group. Double-click the viewer1 user account to see detailed information, as shown in Figure 4-95 on page 182. After the administrator is skilled enough with IBM PowerVC to start managing the environment, you can change the administrator’s s/group/role group to give the administrator more management privileges, as described in 4.16.2, “Updating the user accounts” on page 183.

In Version 1.3.2, roles can be assigned directly to users. But, creating groups with roles might help you administer large sets of users.

For example, the admin and developer group can be assigned to a user. Use these commands to create a user with the deployer and admin role.

Note: Do not forget to set a password for the new user if you want to log in with these accounts on the IBM PowerVC GUI.

In the example in Figure 4-95, three user IDs (admin1, deployer1, and viewer1) were added to the initial root user ID.

Figure 4-95 Users information

Figure 4-95 shows the new accounts.

Figure 4-96 shows the new user admin1 that was added to the admin group.

Figure 4-96 Detailed user account information

4.16.2 Updating the user accounts

If you are using the group role assignment approach (and pre-created those groups and their role assignments or upgraded a system with them), then Example 4-7 works.

To update a user account in the operating systems on the IBM PowerVC management host, run the following command as root:

# usermod [options] login_name

Use the command that is shown in Example 4-7, update the admin user account with the comment IBM PowerVC admin user account, and move it to the admin user group.

Example 4-7 Update the admin user account with the usermod command

usermod -g admin admin

But, if you are using the user role assignment approach, then you must run the following command:

# openstack role delete --user <user> --project <project> <previous_role>

Then, run the following command:

# openstack role add --user <user> --project <project> <new_role>`

After this modification, the admin user account is part of the admin user group and can manage the IBM PowerVC management host, as shown in Figure 4-96 on page 182.

4.16.3 Disabling the root user account from IBM PowerVC

If you upgraded to IBM PowerVC Version 1.3.2, you probably removed the root user account from the admin user group. so the steps in this section are not needed because groups are not created during the installation. If not, run the following command:

# openstack role delete --user root --project ibm-default admin

Important: As a preferred practice, do not use the root user account on IBM PowerVC. It is a security preferred practice to remove it from the admin group.

4.16.4 Working with roles

To assign a role to a user or group, run the openstack role add command or use the equivalent REST APIs. The role assignments are provided in Table 4-8.

Table 4-8 Role assignments

Action

Description

role add

Adds a role to a user or group on a project.

role assignment list

Lists role assignments.

role list

Lists roles.

role remove

Removes a role from a user or group on a project.

role set

Sets role properties.

role show

Displays role details.

For more information, see the CLI and API documentation. Example 4-8 shows how to add a role.

Example 4-8 OpenStack API command line to set up roles to projects

openstack role add --project <project_name> --user <user>

openstack role add --group <group> <role>

4.16.5 Setting project policies

IBM PowerVC Cloud Manager administrators can set several project-specific policies. These policies apply only to users with self_service authority. You can set properties such as whether users require administrator approval to perform certain tasks.

To set policies for a project, run the powervc-cloud-config command and specify one of the policy types that are listed in the following section, as shown in Example 4-9. If the specified policy type already is set for the project, it is changed to the new value.

Example 4-9 Set a policy by using IBM PowerVC Cloud CLI

powervc-cloud-config -p <project> set-policy <policy_type>

For more information about using powervc-cloud-config, run powervc-cloud-config --help.

The policies that are described in the following sections can be set.

default_expiration_days

This setting specifies the number of days before VMs that are created by self-service users in the project expire. When a VM is deployed in this project, this value is used to set the VM’s expiration date. The default is 30 days. When editing a VM’s expiration date, users cannot select a date further out than the value set in this policy. For example, if default_expiration_days is set to 90, users cannot select a date more than 90 days away from the current expiration date when editing a VM’s expiration date.

The default is 30 days.

default_request_wait_time

This setting specifies the number of days that VM expiration extension requests can be in a pending state. If the request is not approved after the specified number of days, it is automatically approved.

If this value is not set, requests are never automatically approved, which is the default.

deploy_approval_limit

This setting specifies the number of VMs a self-service user can own without requiring approval for further deployments. For example, assume that this value is three. If a user deployed three VMs and then deleted one, the user can deploy one more VMs without approval. After this limit is reached, further VM deployments require approval.

If the value is not set, or 0, then all deployments require approvals.

Here are the values that you can set:

•-1: Deployments never require approval.

•Not set or 0: All deployments require approval.

•n > 0: Users can own n VMs without requiring approval for deployments, but any further deploys require approvalexpired_resources_lifetime.

expired_resources_lifetime

This setting specifies how many days expired VMs exist before being deleted. After this period, the VM is deleted. This value applies to all VMs that are created by self-service users in this project. If this value is not set, expired resources are never automatically deleted.

There is no default value, which means expired VMs are never deleted.

extension_approval_limit

This setting specifies the number of VM expiration date extensions that a self-service user can request without administrator approval. After this limit is reached, further expiration date extension requests require approval.

There is no default value, but if it is not set or set to 0, all extensions require approvals.

Here are the values that you can set:

•-1: Extension requests never require approval.

•Not set or 0: All extension requests require approval.

•n > 0: Users can request expiration extension of a VM n times without approval, but any future extension requests require approval.

snapshot_approval_limit

This setting specifies the number of VM captures or snapshots that can be performed without administrator approval. After this limit is reached, further capture requests require approval.

Here are the values that you can set:

•-1: Captures never require approval.

•Not set or 0: All captures require approval.

•n > 0: Users can capture n VMs without approval, but any future captures require approval.

There is no default value, but if it is not set or set to 0, then all capture requests require approvals.

Example 4-10 shows how to create or update the snapshot_approval_limit policy. By running this command, you can create a policy if it does not exist or update the existing policy. If you do not specify a value for -p, the policy is created for the ibm-default project.

Example 4-10 Set policies for a specific project for self-service users

powervc-cloud-config -p test set-policy snapshot_approval_limit 10

The IBM PowerVC management host can display the user accounts that belong to each group. Log in to the IBM PowerVC management host and click Configuration on the top navigation bar of the IBM PowerVC GUI, and then click the Users and Groups tab, as shown in Figure 4-97.

Figure 4-97 Groups tab view under Users on the IBM PowerVC management host

This view displays the default groups. To access detailed information for each group, double-click the group name. Figure 4-98 shows an example of a group that includes the pwrvcviewer ID.

Figure 4-98 Detailed view of viewer user group on the management host

4.16.6 Lightweight Directory Access Protocol

LDAP is an open standard for accessing global or local directory services over a network or the internet. A directory can handle as much information as you need, but it is commonly used to associate names with phone numbers and addresses. LDAP is a client/server solution. The client requests information and the server answers the request. LDAP can be used as an authentication server.

If an LDAP server is configured in your enterprise, you can use that LDAP server for
IBM PowerVC user authentication. IBM PowerVC can be configured to query an LDAP server for authentication rather than using operating system user accounts authentication.

In IBM PowerVC Version 1.3.2, LDAP configuration is not a required installation step, but a general configuration step. Therefore, the powervc-ldap-config command is no longer required. To configure LDAP, run the powervc-config identity repository subcommand. For more information, see IBM Knowledge Center:

•http://www.ibm.com/support/knowledgecenter/SSXK2N_1.3.2/com.ibm.powervc.standard.help.doc/powervc_ldap_hmc.html

•http://www.ibm.com/support/knowledgecenter/SSVSPA_1.3.2/com.ibm.powervc.cloud.help.doc/powervc_ldap_cloud.html

Selecting the authentication method

Plan the authentication method and necessary accounts before the IBM PowerVC installation. For simplicity, for your first installation use the operating system authentication method to manage user accounts in most of the IBM PowerVC installations.

In an enterprise environment, use the LDAP authentication method.

4.16.7 User and Group filtering

By default, IBM PowerVC uses the local operating system to manage users and groups. To avoid exposing all of the system's users and groups, such as those for system accounts,
IBM PowerVC supports both user and group filtering. Only users and groups that match the corresponding filter are exposed in IBM PowerVC.

When you install or upgrade IBM PowerVC, a default user and group filter that is named powervc-filter is created, the default user (root) is added to that group, and the filters are configured so that only that the powervc-filter group and its members are visible to PowerVC.

On an upgrade from an IBM PowerVC version earlier than Version 1.3.2, a new group that is named powervc-filter is created and any user that had an IBM PowerVC role assignment is added to that group. The default filters are configured so that these users and groups are visible to IBM PowerVC:

•The powervc-filter group and all of its members

•Any group that already had an IBM PowerVC role assignment and all of their members

Note: IBM PowerVC backups include the user and group filters. However, they do not create users or groups, or adjust group memberships. If operating system users and groups are configured differently when the backup is restored, this might lead to issues.

For example, if the system on which the restore is being performed does not have the same users in the powervc-filter group, different users are seen in IBM PowerVC. Some role assignments might no longer work because the user or group to which they were granted does not exist or is not visible based on the user and group filters.

Make a user or group visible to IBM PowerVC

Because the default filter matches all members of the powervc-filter group, the easiest way to make a user visible to IBM PowerVC is to make the user a member of that group.

Use the command that is shown in Example 4-11 to modify user1 to be a secondary member of the group powervc-filter.

Example 4-11 Modify user to become part of the default powervc filter group

usermod -a -G powervc-filter user1

Creating, updating, and viewing a filter

To make additional groups visible to IBM PowerVC, you must update the group filter. Run the powervc-config identity repository command with the appropriate attributes. Every time that you run this command, it replaces the existing filter. Therefore, view the current filter before updating the filter by running powervc-config identity repository.

As shown in Example 4-12, we create a filter so that IBM PowerVC can see all of the users that are members of the groups power1, power2, or power3, and can also see any groups that are named power1, power2, or power3:

Example 4-12 Create a group filter that is fed by existing users and groups

powervc-config identity repository -t os \

--user-filter "(|(memberOf=power1)(memberOf=power2)(memberOf=power3))" \

--group-filter "(|(name=power1)(name=power2)(name=power3))"

Note: You have to update both filters if you update either filter.

IBM PowerVC Standard Edition for managing IBM PowerKVM

Using IBM PowerVC for managing PowerKVM for the setup, storage management, and the way that IBM PowerVC handles the capture of International Organization for Standardization (ISO) images requires special considerations. This chapter covers the installation and setup specifics and the basic steps to import, capture, and deploy ISO images:

•5.1, “Install IBM PowerVC Standard to manage PowerKVM” on page 190

•5.2, “Setting up PowerVC Standard managing PowerKVM” on page 191

•5.3, “Host group setup” on page 205

•5.4, “Importing ISO images” on page 206

•5.5, “Capturing a virtual machine” on page 216

•5.6, “Deploying images” on page 224

•5.7, “Resizing virtual machines” on page 227

•5.8, “Suspending and resuming virtual machines” on page 228

•5.9, “Restarting a virtual machine” on page 228

•5.10, “Migrating virtual machines” on page 229

•5.11, “Restarting virtual machines remotely” on page 230

•5.12, “Deleting virtual machines” on page 232

•5.13, “Creating and attaching volumes” on page 233

•5.14, “Attaching volumes” on page 234

For configuration and use, see Chapter 4, “IBM PowerVC for managing IBM PowerVM” on page 91.

5.1 Install IBM PowerVC Standard to manage PowerKVM

This section outlines the slight differences between the installation of IBM PowerVC Standard Edition for managing PowerKVM and the installation of IBM PowerVC Standard Edition for managing PowerVM.

Important: IBM PowerVM NovaLink is a PowerVM-only offering. Although PowerVM and OpenStack have full support for PowerKVM, this technology does not support PowerKVM.

Before you install IBM PowerVC, a Linux Installation must be ready, as described in Chapter 3, “IBM PowerVC installation” on page 67. This section does not cover the Linux installation because it does not differ from the Linux installation for managing PowerVM. For the installation details, see 3.2, “Installing IBM PowerVC” on page 71.

After the IBM PowerVC installation for Linux is ready, complete the following steps:

1. From the Linux command-line interface (CLI), change the working directory to the location of the installation script.

2. Install IBM PowerVC Standard for managing PowerKVM by running this command:

./install

3. Select the offering type to install from the following two options:

 – 1 - Standard managing PowerVM

 – 2 - Standard managing PowerKVM

 – 9 - Exit

Enter 2 to install with PowerVC Standard managing PowerKVM.

The rest of the installation process is the same for all versions. For more information, see 3.2, “Installing IBM PowerVC” on page 71.

5.2 Setting up PowerVC Standard managing PowerKVM

This section covers the steps to add a PowerKVM host, a storage provider, and a network.

5.2.1 Adding the PowerKVM host

To add the PowerKVM host, complete the following steps:

1. In the IBM PowerVC graphical user interface (GUI), type your user and password, and click Log In (Figure 5-1).

Figure 5-1 IBM PowerVC Login window

Note: The home window (Figure 5-2) does not offer the option to add a fabric.

Figure 5-2 IBM PowerVC home window

2. Click Add host to add the PowerKVM host, as shown in the Figure 5-3.

Figure 5-3 IBM PowerVC Add Host window

During the Add Host task, a package is transferred and installed in the PowerKVM host. As Figure 5-4 shows, messages appear in the lower-right side of the browser.

Figure 5-4 Informational messages

After the host is added, you see the message in Figure 5-5.

Figure 5-5 Host added successfully

3. To review the messages, click the black menu bar at the top of the browser. Figure 5-6 shows the home window with the available PowerKVM hosts.

Figure 5-6 IBM PowerVC managing PowerKVM hosts

4. For a detailed view of the added PowerKVM, click the Hosts icon in the left navigation panel (highlighted in Figure 5-6). Figure 5-7 shows the new PowerKVM hosts.

Figure 5-7 Detailed Hosts view

5. Click a PowerKVM host to display more information, as shown in Figure 5-8.

Figure 5-8 PowerKVM host information and capacity section

You can expand and collapse any sections. The display information about virtual switches and virtual machines (VMs) is shown in Figure 5-9.

Figure 5-9 PowerKVM Virtual Switches and Virtual Machines sections

5.2.2 Adding storage

To add storage, complete the following steps:

1. Add the storage by clicking the Add Storage plus sign (+) in the center of the
IBM PowerVC home window. Figure 5-10 shows a window to specify the storage array IP address and credentials. In our lab environment, we use an IBM SAN Volume Controller. Enter the name, user ID, and password. Click Connect.

Figure 5-10 Add a storage device to IBM PowerVC

2. After you provide the IP connection settings and credentials, specify the SAN Volume Controller storage pool that is assigned to your environment. In Figure 5-11, the SAN Volume Controller shows three pools. In our example, we select DS4800_site2_p02. Click Add Storage.

Figure 5-11 SAN Volume Controller storage pool choice

After you add the SAN Volume Controller and storage pool successfully, a new storage provider appears on the IBM PowerVC home window, as shown in Figure 5-12 (Storage Providers: 1). The storage provider does not have a managed volume yet.

Figure 5-12 The new SAN Volume Controller storage provider

5.2.3 Adding a network

To add a network, complete the following steps:

1. Click Add Network to open the window that is shown in Figure 5-13.

Figure 5-13 Add a network to the IBM PowerVC configuration

2. Add the network name, virtual LAN (VLAN) ID, subnet mask, default gateway, Domain Name Server (DNS), and the address deployment choice (Dynamic Host Configuration Protocol (DHCP) or Static). The configured virtual switch is automatically retrieved from the PowerKVM configuration.

3. After you add the network to the configuration, the home window is updated, as shown in Figure 5-14.

Figure 5-14 Network is configured

Managing virtual switches

IBM PowerVC Standard for managing PowerKVM can manage multiple virtual switches to accommodate your business requirements. Complete the following steps:

1. To edit the virtual switch configuration, from the IBM PowerVC home window, click the Hosts icon, and then double-click the host that you want to use. Expand the Virtual Switches section, if it is not expanded. The virtual switches are defined on the host, as shown in Figure 5-15.

Figure 5-15 List of virtual switches

2. Select the switch that you need to edit and click Edit Switch. From the list of available components, select the physical component that you want to link to the virtual switch, and click Save, as shown in Figure 5-16.

Figure 5-16 Edit virtual switch window

3. The message that is shown in Figure 5-17 appears. Verify that no other activity is running on the host, and click OK.

Figure 5-17 Message about conflicts with the updated virtual switch selections

4. After the process finishes, the component is shown in the Components column. Click View Components to see the details that are shown in Figure 5-18.

Figure 5-18 Details of the virtual switch components

Environment verification

Check the overall configuration by clicking Verify Environment.

Note: This verification is the same procedure for all IBM PowerVC versions.

5.3 Host group setup

With Host Group set up, you can group hosts into host groups. You can set different placement policies for each host group. To create a host group, complete the following steps:

1. Click Hosts → Host Groups and click Create Host Group, as shown in Figure 5-19.

Figure 5-19 Create a host group

2. Enter the host group name, select the placement policy, and the hosts.

3. Click Create Host Group at the bottom of the window.

5.4 Importing ISO images

PowerVC Standard managing PowerVM does not provide a method to install Linux VMs from ISO images.

PowerVC Standard managing PowerKVM offers you the option to use ISO images to create Linux VMs. After the environment is verified, you can import ISO images to the IBM PowerVC domain.

5.4.1 Importing ISO images by using the command-line interface

The first step to import an ISO image to IBM PowerVC is to transfer the file to the
IBM PowerVC hosts. Then, you can run the powervc-iso-import command to add the ISO to IBM PowerVC. Example 5-1 shows an example of importing a Red Hat Enterprise Linux (RHEL) ISO image by using the command-line interface (CLI).

Example 5-1 Import a Red Hat ISO image

[admin@powerkvm bin]# powervc-iso-import --name rhel65dvd2 --os rhel --location /softimg/rhel-server-6.5-ppc64-dvd.iso

Password

+----------------------------+--------------------------------------+

| Property | Value |

+----------------------------+--------------------------------------+

| Property 'architecture' | ppc64 |

| Property 'hw_vif_model' | virtio |

| Property 'hypervisor_type' | qemu |

| Property 'os_distro' | rhel |

| checksum | 66bb956177d7b55946a5602935e67013 |

| container_format | bare |

| created_at | 2014-05-27T21:14:57.012159 |

| deleted | False |

| deleted_at | None |

| disk_format | iso |

| id | a898e706-c835-42c6-87c2-e53d8efb98ae |

| is_public | True |

| min_disk | 0 |

| min_ram | 0 |

| name | rhel65dvd2 |

| owner | 9c03022ea2a146b78c495cc9a00b0487 |

| protected | False |

| size | 3347902464 |

| status | active |

| updated_at | 2014-05-27T21:15:47.330608 |

| virtual_size | None |

+----------------------------+--------------------------------------+

5.4.2 Importing ISO images by using the GUI

To import ISO images by using the graphical user interface (GUI), complete the following steps:

1. To import ISO images or qcow2 images into IBM PowerVC by using the GUI, click Images on the left navigation pane in IBM PowerVC. Then, click Upload. Enter the image name, operating system, and image type, as shown in Figure 5-20. Click Browse to navigate to the ISO image. Select the ISO image. Finally, click Upload.

Figure 5-20 Upload Image window

Note: This process takes a few seconds or minutes, depending on the network bandwidth and the size of the image.

2. After the ISO image is successfully imported, the ISO image appears on the left navigation pane of the IBM PowerVC home window, as shown in Figure 5-21.

Figure 5-21 ISO images that were imported to IBM PowerVC

3. The status of the ISO images can be verified by clicking the Images icon on the left navigation pane to open the Images view that is shown in Figure 5-22.

Figure 5-22 Status of the imported ISO image

4. Click the rhel65dvd2 image to get details, such as the ID, as shown in Figure 5-23.

Figure 5-23 RHEL ISO image details

The images are in the /var/lib/glance/images/ directory. Example 5-2 displays the ISO image file based on the ID in the Images interface that is shown in Figure 5-23.

Example 5-2 ISO image location and naming in IBM PowerVC

[admin@dIBM PowerVCkvm ~]$ ls /var/lib/glance/images

a898e706-c835-42c6-87c2-e53d8efb98ae

5.4.3 Deploying an RHEL ISO image

After an ISO image is imported, you can deploy it to a VM. This VM is a base that is ready for future image captures and the automatic deployments of other VMs. Complete the following steps:

1. From the Images window, on the left navigation pane (Figure 5-24), select the image and click Deploy.

Figure 5-24 Select the image for deployment

2. After the image is selected for deployment, you must specify the following parameters for the target VM before any deployment can start (Figure 5-25):

 – VM name.

 – Target host or host group.

 – Compute template.

The following default values can be overridden when they are available:

 • Processors

 • Processor units

 • Memory size

 • Disk size

 – Network template.

 – The VM’s IP address or IBM PowerVC can select an IP address automatically from the IP pool.

Figure 5-25 Virtual machine deployment parameters

3. Complete the required information, and click Deploy to start the VM’s deployment. During the deployment process, IBM PowerVC displays several messages. Figure 5-26 shows the deployment in-progress message.

Figure 5-26 Deployment in-progress message

4. Figure 5-27 shows the successful deployment message.

Figure 5-27 Successful deployment verification message

5. The VM’s deployment can be monitored from the left navigation area, as shown in Figure 5-28.

Figure 5-28 Virtual Machines view with highlighted State and Health columns

6. Click the name to see the detailed Information and Specifications sections about the deployed image, as shown in Figure 5-29.

Figure 5-29 Detailed information

7. The sections can be collapsed and expanded as needed. Figure 5-30 shows the expanded Network Interfaces and Details sections and the collapsed Information and Specifications sections.

Figure 5-30 Detailed information with expanded or collapsed sections

8. The Active status and OK health mean that the VM is deployed. Although this status seems definitive, you still must install the initial Linux installation manually.

9. The machine is prepared and ready for the operating system (OS) installation. A shutdown is required. Select the deployed VM and click Stop, as shown in Figure 5-31.

Figure 5-31 Stop the virtual machine

Note: This extra manual installation step is necessary only for ISO image deployment, not for captured VMs.

Tip: When you select the VM, the action buttons become active. If no VM is selected, all of the buttons remain inactive (gray).

Linux installation for the virtual machine

The following steps describe the manual installation of a Linux VM by using an ISO image:

1. Start the VM by clicking Start on IBM PowerVC. When the VM is started, the state is Active, as shown in Figure 5-32.

Figure 5-32 Virtual machine started and active

Note: The Health status might remain in the Warning state for several minutes.

2. After the VM status is Active and Health is OK, proceed with the manual installation steps.

3. Open a remote console connection from the PowerKVM command line to the VM by using the virsh console command. First, list all of the VMs by running the virsh list --all command. Example 5-3 shows the output for the virsh command.

Example 5-3 virsh list --all output

[admin@powerkvm ~]# virsh list --all

Id Name State

----------------------------------------------------

- linux20-36d9ca31-00000017 shut off

[admin@powerkvm ~]#

4. Copy the name of the VM and run the following command:

virsh console [virtual_machine_name]

5. This command opens a remote virtual console with the selected VM. Press any key to get the initial input. You see the “Disc Found” message after RHEL starts, as shown in Example 5-4.

Example 5-4 Virtual console that shows Disc Found message

Welcome to Red Hat Enterprise Linux for ppc64

+-----------¦ Disc Found +-----------+

¦ ¦

¦ To begin testing the media before ¦

¦ installation press OK. ¦

¦ ¦

¦ Choose Skip to skip the media test ¦

¦ and start the installation. ¦

¦ ¦

¦ +----+ +------+ ¦

¦ ¦ OK ¦ ¦ Skip ¦ ¦

¦ +----+ +------+ ¦

¦ ¦

¦ ¦

+------------------------------------+

<Tab>/<Alt-Tab> between elements | <Space> selects | <F12> next screen

6. Follow the instructions to complete the Linux installation. When the installation finishes, the VM is ready to be captured and deployed several times.

5.5 Capturing a virtual machine

A VM can be captured when it is in the Active state or a powered-off state.

This section describes how to capture a VM that is running and managed by IBM PowerVC. This section covers the necessary steps to capture the VM:

1. Install cloud-init on the VM that you want to capture. You must perform this step only the first time that you capture a VM.

2. Perform any pre-capture preparations, such as deleting or cleaning up log files, on the VM.

For SUSE Linux Enterprise Server VMs, change the devices so that they are mounted by device name or Universally Unique Identifier (UUID).

Before you can capture a VM, you must ensure that the following requirements are met:

•Your IBM PowerVC environment is configured as described in 5.2, “Setting up PowerVC Standard managing PowerKVM” on page 191.

•The host on which the VM is configured is registered in IBM PowerVC.

•When you capture VMs that use local storage, the /var/lib/glance/images/ directory on the IBM PowerVC management server is used as the repository for storing the qcow2 and ISO images. The file system that contains the /var/lib/glance/images/ directory must have enough space to store the captured images.

5.5.1 Installing cloud-init on the virtual machine

The cloud-init script enables VM activation and initialization. It is widely used for OpenStack.

Before you capture a VM, install the cloud-init initialization package. This package is available at /opt/ibm/powervc/images/cloud-init in IBM PowerVC.

Important: If you are installing the cloud-init package to capture a VM, and the activation engine (AE) is installed, you must uninstall the AE. To uninstall the AE, see “sudo shutdown -h now” on page 152.

Installing the required dependencies

Before you install cloud-init, you must install the necessary dependencies for cloud-init, such as the following examples, from the repository:

•Python boto

•Yellowdog Updater, Modified (YUM)

•Extra Packages for Enterprise Linux (EPEL)

•Any other package manager

Not all dependencies are available in the regular RHEL repository.

For SUSE Linux Enterprise Server, install the dependencies that are provided at the following site:

ftp://ftp.unicamp.br/pub/linuxpatch/cloud-init-ppc64/sles

For RHEL 6 and 7, complete the following steps:

1. Install the dependencies from the FTP location:

ftp://ftp.unicamp.br/pub/linuxpatch/cloud-init-ppc64

2. Add the EPEL YUM repository to get the dependent Red Hat Package Managers (RPMs):

 – Run the following commands to set up the repository for RHEL 6:

wget http://dl.fedoraproject.org/pub/epel/6Server/ppc64/epel-release-6-8.noarch.rpm

rpm -Uvh epel-release-6*.rpm

 – Run the following commands to set up the repository for RHEL 7:

wget http://dl.fedoraproject.org/pub/epel/7/ppc64/e/epel-release-7-5.noarch.rpm

rpm -Uvh epel-release-7*.rpm

Note: The EPEL RPM packages might be renamed with the updated version. You can obtain the new versions from the following website with the correct version selected:

http://dl.fedoraproject.org/pub/epel/

Installing cloud-init

Install the appropriate cloud-init RPM for your OS from /opt/ibm/powervc/images/cloud-init:

•For RHEL 6, install cloud-init-0.7.4-*.el6.noarch.rpm.

•For RHEL 7, install cloud-init-0.7.4-*.el7.noarch.rpm from the /opt/ibm/powervc/images/cloud-init/rhel location.

Modifying the cloud.cfg file

After you install cloud-init, modify the cloud.cfg file that is available at /etc/cloud/cloud.cfg with the following values, according to your OS.

For RHEL, update the cloud.cfg file with the following values:

•disable_root: 0

•ssh_pwauth: 1

•ssh_deletekeys: 1

For SUSE Linux Enterprise Server, edit the following fields in the cloud.cfg file:

1. Remove the following field:

users: -root

2. Add the following fields:

 – ssh_pwauth: true

 – ssh_deletekeys: true

For both RHEL and SUSE Linux Enterprise Server, add the following new values to the cloud.cfg file:

•disable_ec2_metadata: True

•datasource_list: ['ConfigDrive']

For SUSE Linux Enterprise Server only, after you update and save the cloud.cfg file, run the following commands:

•chkconfig -s cloud-init-local on

•chkconfig -s cloud-init on

•chkconfig -s cloud-config on

•chkconfig -s cloud-final on

For RHEL 7, ensure that the following conditions are set on the VM that you are capturing or deploying:

•SUSE Linux Enterprise Server is set to permissive or disabled on the VM that you are capturing or deploying.

•Ensure that if Network Manager is installed, it is disabled.

•Ensure that the net-tools package is installed.

Note: This package is not installed by default when you select the Minimal Install software option during the installation of RHEL 7 from an ISO image.

•Edit all of the /etc/sysconfig/network-scripts/ifcfg-eth* files and update NM_CONTROLLED=no in them.

Removing the MAC address information

After you install the cloud-init initialization package, remove the Media Access Control (MAC) address information by completing the following steps:

1. Replace /etc/udev/rules.d/70-persistent-net.rules with an empty file. (The .rules file contains network persistence rules, including the MAC address.)

2. Replace /lib/udev/rules.d/75-persistent-net-generator.rules with an empty file, which generates the .rules file.

Note: The recommended action is to replace the previous files with empty files rather than deleting the files. If you delete the files, you might receive an udev kernel warning at boot time.

3. Remove this HWADDR line from Fedora-based images:

/etc/sysconfig/network-scripts/ifcfg-eth0

Tip: The /etc/sysconfig/network-script file path for the HWADDR file applies for RHEL only. For example, for the ifcfg-eth0 adapter on RHEL, remove the HWADDR line from /etc/sysconfig/network-script/ifcfg-eth0. For SUSE Linux Enterprise Server, the HWADDR path is /etc/sysconfig/network. On SUSE Linux Enterprise Server, remove the HWADDR line from /etc/sysconfig/network/ifcfg-eth0.

Important: You must remove the network persistence rules in the image because they cause the network interface in the instance to come up as an interface other than eth0. Your image has a record of the MAC address of the network interface card (NIC) when it was first installed, and this MAC address is different each time that the instance boots.

5.5.2 Changing devices to be mounted by name or UUID

For SUSE Linux Enterprise Server virtual servers, use literal names for device names rather than symbolic links. By default, devices are mounted by using -id, which means that they are represented by symbolic links.

You must change the devices so they are mounted by device name or UUID rather than by -id. You must perform this task before you capture a SUSE Linux Enterprise Server VM for the first time. After you capture a SUSE Linux Enterprise Server VM for the first time, you can capture and deploy an image of the resulting VM without performing this task.

To change the devices so that they are mounted by device name or UUID, complete the following steps:

1. Search the file system table /etc/fstab for the presence of symbolic links. Symbolic links look like /dev/disk/by-*.

2. Store the mapping of the /dev/disk/by-* symbolic links to their target devices in a scratch file by running this command:

ls -l /dev/disk/by-* > /tmp/scratchpad.txt

The contents of the scratchpad.txt file might look like Example 5-5.

Example 5-5 Symbolic links mapping

/dev/disk/by-id:

total 0

lrwxrwxrwx 1 root root 9 Apr 10 12:07 scsi-360050768028180ee380000000000603c -> ../../sda

lrwxrwxrwx 1 root root 10 Apr 10 12:07 scsi-360050768028180ee380000000000603c-part1 -> ../../sda1

lrwxrwxrwx 1 root root 10 Apr 10 12:07 scsi-360050768028180ee380000000000603c-part2 -> ../../sda2

lrwxrwxrwx 1 root root 10 Apr 10 12:07 scsi-360050768028180ee380000000000603c-part3 -> ../../sda3

lrwxrwxrwx 1 root root 9 Apr 10 12:07 wwn-0x60050768028180ee380000000000603c -> ../../sda

lrwxrwxrwx 1 root root 10 Apr 10 12:07 wwn-0x60050768028180ee380000000000603c-part1 -> ../../sda1

lrwxrwxrwx 1 root root 10 Apr 10 12:07 wwn-0x60050768028180ee380000000000603c-part2 -> ../../sda2

lrwxrwxrwx 1 root root 10 Apr 10 12:07 wwn-0x60050768028180ee380000000000603c-part3 -> ../../sda3

/dev/disk/by-path:

total 0

lrwxrwxrwx 1 root root 9 Apr 10 12:07 scsi-0:0:1:0 -> ../../sda

lrwxrwxrwx 1 root root 10 Apr 10 12:07 scsi-0:0:1:0-part1 -> ../../sda1

lrwxrwxrwx 1 root root 10 Apr 10 12:07 scsi-0:0:1:0-part2 -> ../../sda2

lrwxrwxrwx 1 root root 10 Apr 10 12:07 scsi-0:0:1:0-part3 -> ../../sda3

/dev/disk/by-uuid:

total 0

lrwxrwxrwx 1 root root 10 Apr 10 12:07 3cb4e486-10a4-44a9-8273-9051f607435e -> ../../sda2

lrwxrwxrwx 1 root root 10 Apr 10 12:07 c6a9f4e8-4e87-49c9-b2-89086c2d1064 -> ../../sda3

/

Important: For the following steps, ensure that you use the device names in your own scratchpad.txt file. The following values are merely examples.

3. Edit /etc/fstab, replacing the /dev/disk/by-* entries with the device names that the symbolic links point to, as laid out in your scratchpad.txt file.

Example 5-6 shows what these lines might look like before you edit them.

Example 5-6 Sample device names before the change

/dev/disk/by-id/scsi-360050768028180ee380000000000603c-part2 swap swap defaults 0 0

/dev/disk/by-id/scsi-360050768028180ee380000000000603c-part3 / ext3 acl,user_xattr 1 1

Example 5-7 shows what these lines might look like after you edit them.

Example 5-7 Sample device names after the change

/dev/sda2 swap swap defaults 0 0

/dev/sda3 / ext3 acl,user_xattr 1 1

4. Edit the /etc/lilo.conf file so that the boot and root lines correspond to the device names.

Example 5-8 shows what these lines might look like before you edit them.

Example 5-8 lilo.conf file before change

boot = /dev/disk/by-id/scsi-360050768028180ee380000000000603c-part1

root = /dev/disk/by-id/scsi-360050768028180ee380000000000603c-part3

Example 5-9 shows what these lines might look like after you edit them.

Example 5-9 lilo.conf file after change

boot = /dev/sda1

root = /dev/sda3

5. Run the lilo command.

6. Run the mkinitrd command.

Note: The installation steps for cloud-init might change with the update of cloud-init or IBM PowerVC. Check the latest information about the cloud-init installation at IBM Knowledge Center:

https://www.ibm.com/support/knowledgecenter/SSXK2N_1.3.1/com.ibm.powervc.standard.help.doc/powervc_install_cloudinit_hmc.html

5.5.3 Capturing the virtual machine

Before you can capture a VM, the VM must meet specific requirements. If you do not prepare the VM before you capture it, you might get errors when you deploy the resulting image.

To capture a VM by using the cloud-init initialization package, complete the following steps:

1. Install cloud-init on the VM that you want to capture. You perform this step only the first time that you capture a VM. For more information about how to install cloud-init, see 5.5.1, “Installing cloud-init on the virtual machine” on page 217.

2. If the VM that you want to capture is running a SUSE Linux Enterprise Server operating system, change the device mounting. For more information, see 5.5.2, “Changing devices to be mounted by name or UUID” on page 219.

3. Perform any pre-capture preparation, such as deleting or cleaning up log files, on the VM.

4. From the IBM PowerVC home window, click Virtual Machines, select the VM to capture, and click Capture.

5. When the message that is shown in Figure 5-33 appears, click Continue to proceed.

Figure 5-33 Warning message before you capture the VM

6. Name the new image. Figure 5-34 shows a text box to enter the name, and it displays the required default resources for this image.

Note: You can override the amount of required resources when you deploy a new VM with this image.

Figure 5-34 Capture window

7. Click Capture to continue. IBM PowerVC starts to capture the VM. IBM PowerVC presents the message that is shown in Figure 5-35.

Figure 5-35 Snapshot in-progress message

The process can take from a few seconds to a few minutes. To see the status of the capture operation, click Virtual Machines. Then, check the Task column to see the status of the snapshot, as shown in Figure 5-36.

Important: It is not necessary to shut down the VM that you want to capture. You can capture images dynamically from VMs that are running, but you might need to review and check any inconsistency in the data or applications outside of the operating system.

Figure 5-36 Status from the Virtual Machines view

You can see the capture status by clicking Images, as shown in Figure 5-37.

Figure 5-37 Snapshot status from the Images view

5.6 Deploying images

The process to create a VM by using an existing image is simple. The process is automated by IBM PowerVC.

To deploy a new VM, complete the following steps:

1. Click Image, select the image that you want to deploy, and then click Deploy. Complete the requested information. Figure 5-38 shows the first two sections of the Deploy window.

Figure 5-38 General and network sections of the window to deploy a VM

2. Figure 5-39 shows the expanded Activation Input section. In this section, you can upload scripts or add configuration data. After the VM is deployed, the script or data automatically configures the VM according to your requirements.

Figure 5-39 Activation Input section of the window to deploy a virtual machine

After you click Deploy, IBM PowerVC displays a message similar to the message that is shown in Figure 5-40.

Figure 5-40 Deployment is started message

3. When the deployment is complete, you can click Virtual Machines to see the new deployed image, as shown in Figure 5-41.

Figure 5-41 Virtual Machines view

Note: The network is configured automatically by IBM PowerVC during the task to build the VM. When the deployment task finishes, the VM is running and connected to the network.

5.7 Resizing virtual machines

PowerVC Standard managing PowerKVM can resize VMs with a simple procedure.

To resize your VMs, complete the following steps:

1. From the window that lists all VMs, select the VM to resize.

2. Click Resize to open the window that is shown in Figure 5-42.

Figure 5-42 Resize virtual machine window

Note: You can select a compute template to populate the required resource values or edit each field manually.

Important: If you change the size of the disk, ensure that you go into the OS of the VM and complete the required steps so that the OS can use the new space that was configured on the disk. For more information, see your OS documentation.

If the disk belongs to an IBM i VM, the size of the disk cannot be changed, so the value is ignored.

5.8 Suspending and resuming virtual machines

IBM PowerVC can suspend and resume a running VM. To suspend a VM, select it and then click Suspend. Two methods exist to suspend a VM, as shown in Figure 5-43.

Figure 5-43 Suspend or pause a virtual machine

After you select an option, click OK. The VM state changes to Paused or Suspended. To resume the VM, select it and click Resume.

Important: It is not possible to restart VMs that are in a Suspended or Paused state. The only available option is to perform a hard restart.

5.9 Restarting a virtual machine

IBM PowerVC can restart a VM. To do so, complete the following steps:

1. To restart a VM, select the VM and click Restart.

2. When the Restart window opens (Figure 5-44), select either a soft restart or a hard restart.

Figure 5-44 Restart a virtual machine

Note: It is possible to restart VMs in a Suspended or Paused state. However, the only available option is to perform a hard restart.

5.10 Migrating virtual machines

IBM PowerVC also support the migration of VMs between PowerKVM hosts if the VM meets the requirements of migration, for example, Network File System (NFS) shared storage was configured for the PowerKVM hosts. For the detailed requirements of VM migration, see
IBM Knowledge Center:

http://www.ibm.com/support/knowledgecenter/SSXK2N_1.3.1/com.ibm.powervc.kvm.help.doc/powervc_relocating_vm_kvm.html

To migrate a VM, complete the following steps:

1. Go to the Virtual Machines window, select the VM to migrate, and click Migrate. Select the destination host, as shown in Figure 5-45, and then click Migrate.

Figure 5-45 Migrate a virtual machine

2. The VM is migrated to the destination host live, as shown in Figure 5-46.

Figure 5-46 Migrate a virtual machine

5.11 Restarting virtual machines remotely

With IBM PowerVC, you can restart VMs remotely if a PowerKVM host fails. To do so, complete the following steps:

1. After a PowerKVM host fails, go to the Hosts window, select the failed host, and click Remotely Restart Virtual Machines, as shown in Figure 5-47.

Figure 5-47 Remotely Restart Virtual Machines option

2. Select the VM or all VMs, select the destination host, as shown in Figure 5-48, and click Remote Restart.

Figure 5-48 Select virtual hosts to restart remotely

3. The selected VMs are restarted remotely on the destination PowerKVM host, as shown in Figure 5-49.

The remote restart function provides a new way to enhance the availability of applications.

Figure 5-49 Virtual machines that were restarted remotely

Note: Before you use the remote restart function, you must set up IBM PowerVC to meet the requirements. For the detailed remote restart requirements, see IBM Knowledge Center:

https://www.ibm.com/support/knowledgecenter/SSXK2N_1.3.1/com.ibm.powervc.kvm.help.doc/powervc_recover_data_kvm.html

5.12 Deleting virtual machines

IBM PowerVC can delete a VM. The process deletes the VM and the associated storage.

To delete a VM, complete the following steps:

1. To delete a VM, select it and click Delete.

2. When you see a confirmation message that is similar to the message that is shown in Figure 5-50, click OK if the message shows the correct machine.

Figure 5-50 Delete a virtual machine

5.13 Creating and attaching volumes

IBM PowerVC can create volumes in the available storage providers. These volumes can be assigned to a VM later, or it is possible to create and attach volumes in one single step.

To create a volume, click Storage Volumes, and then click Create. A window that is similar to the window that is shown in Figure 5-51 opens.

Figure 5-51 Create Volume window

It is possible to attach the volume later to an existing VM.

5.14 Attaching volumes

IBM PowerVC can attach a volume to existing VMs. It is also possible to create the volume and attach it in the same operation.

To attach volumes, complete the following steps:

1. Click Virtual Machines, select the VM, and click Attach Volume.

2. In the Attach Volume window (Figure 5-52), click Attach a new volume to this virtual machine to add a volume. Enter the storage template, volume name, description, and size (GB). Click Attach.

Figure 5-52 Attach a new volume to a virtual machine

3. To attach an existing volume, click Attach an existing volume to this virtual machine. A list of volumes is shown, as shown in Figure 5-53.

Figure 5-53 Attach an existing volume to this virtual machine

It is possible to attach volumes to paused and suspended VMs.

Note: When you attach volumes to Linux VMs, additional work is required for the OS to discover the volumes. For more information, check the documentation for your Linux distribution.

IBM Cloud PowerVC Manager

This chapter describes one of the key features that is introduced in IBM Cloud PowerVC Manager, which allows the user to manage one or several virtual machines (VMs) that are created by themselves in few clicks.

A set of functions that is available on IBM Cloud PowerVC Manager is referred to as the self-service portal.

The abilities that a user with self-service authority can perform depends on the project policies that are set by the project administrator. Project policies specify what users can do and whether administrator approval is required for each action. In general, a self-service user can perform the following actions:

•Manage VMs that are owned by that user.

•Deploy VMs by using a deploy template.

•Review and withdraw action requests.

•View their own metering data.

This chapter focuses on those tasks that are performed by users without any previous experience with IBM PowerVC, such as:

•Logging in to Cloud Power VC Manager

•Exploring the Cloud PowerVC Manager user interface

•Deploying VMs from a template

•Reviewing and withdrawing action requests

Also, this chapter shows the tasks that are run by the administrator user on those requests that are created by self-service users, if their intervention is required.

It covers the following topics:

•6.1, “Logging in as a self-service user” on page 238

•6.2, “Self-service portal graphical user interface” on page 239

•6.3, “Deploying virtual machines from a template” on page 239

•6.4, “Viewing the information that is used for deployment” on page 240

•6.5, “Viewing deployment requests” on page 241

•6.6, “Administrator actions for user requests” on page 242

6.1 Logging in as a self-service user

After you receive the notification from your administrator that your access is granted and role is set, you can connect to the IBM PowerVC graphic user interface (GUI) by completing the following steps:

1. Open a web browser on your workstation and point it to the IBM PowerVC address:

https://<ip address or hostname>/

2. Log in to IBM PowerVC with your given user ID and password, as shown in Figure 6-1.

Figure 6-1 IBM PowerVC Login window

6.2 Self-service portal graphical user interface

This chapter briefly presents the self-service portal GUI that is included in this edition of Cloud PowerVC Manager and shows the basic functions that are allowed for a self-service user, set as self-service user, from the home window, as illustrated in Figure 6-2.

Figure 6-2 Self-service portal home window.

The following sections describe the steps to perform to get your VM ready to use.

6.3 Deploying virtual machines from a template

To create your VM, you must select a deploy template, as shown in Figure 6-3.

Deploy templates are created by the administrator. They contain all of the settings necessary to deploy a VM from a given image. For example, the deploy template specifies the numbers of memory processors that are allocated to a VM created by using this template.

Figure 6-3 Deploy Templates selection interface

6.4 Viewing the information that is used for deployment

A user must specify a name for the VM and how many instances to create. Additionally, you can add a pair key, a description, and a message for the administrator in case you require approval, as shown in Figure 6-4.

Figure 6-4 Deploy template information

Next, after you run the Deploy action, depending on the policy, either the deployment is started immediately or a request is created that requires administrator approval. After approval, the deployment is started.

If you are interested in project policies, see 2.8.2, “Projects and role management planning” on page 61.

Figure 6-5 shows the message in the bottom right corner that provides information about your request. Additionally, the indicator by the Requests menu item is incremented.

Figure 6-5 Deployment that is submitted and request that is created

6.5 Viewing deployment requests

You can see the status of your request. From your home window, click Requests and a new web page shows all the information about your request and its status, as shown in Figure 6-6.

Figure 6-6 Request details and information

After your request is approved, you can use your VM for the period that is set in the project policy.

Note: If you need more time to use your VM, you can request an expiration extension with the user interface. Depending on the project’s policies, the extension might be approved immediately or it might be added to your list of requests.

6.6 Administrator actions for user requests

This section describes the actions to be performed by the administrator on your requests.

6.6.1 Viewing request details as an administrator

After the administrator receives your request, he must check the details of your request to approve, deny, or deploy your VM Deploy request, as shown in Figure 6-7.

Figure 6-7 Request details from the administrator’s home window view

6.6.2 Approving a request as an administrator

The administrator can then approve or deny the request by using the top buttons. The administrator may add a message to the self-service user. If the administrator approves the request, the VM is deployed automatically, as shown in Figure 6-8.

Figure 6-8 Administrator’s approval submitted

6.6.3 Viewing approved new virtual machines

When all requests are attended and either approved or rejected, the administrator’s queue is clear, as shown in Figure 6-9.

Figure 6-9 Administrator user clean queue

Software-Defined Networking (technical preview)

Software-defined networking (SDN) virtualizes your network in a similar way that compute resources are virtualized. With SDN, you can deploy networks and change your network layout without making any physical changes to your network environment. IBM PowerVC supports the SDN technical preview on PowerVM NovaLink managed systems.

Important: In IBM PowerVC Version 1.3.2, SDN is offered as a technical preview that is meant for a test environment for administrators to understand SDN. It is not meant for production environments.

SDN has the following functions:

•Security groups to control virtual machine (VM) communication. Rules can be used to specify which IP addresses, IP protocols, and ports a VM can communicate with. For more information, see “Security groups” on page 248.

•Overlay network support (such as Virtual Extensible LAN (VXLAN)). Overlay networks work with Open vSwitch (OVS) to allow VMs that are on different physical networks to communicate with each other over a private virtual network. For more information, see “Network overlays” on page 251.

Note: This function is not supported when Red Hat Enterprise Linux (RHEL) is used for the network node operating system. For more information about network nodes, see “Network nodes” on page 253.

•Support for virtual routers to connect your overlay network to your wide area network (WAN). For more information, see “Virtual routers” on page 253.

Note: This function is not supported when RHEL is used for the network node operating system. For more information about network nodes, see “Network nodes” on page 253.

•Support for floating IP addresses to assign a public IP address from your WAN to a VM on the overlay network. For more information, see “Floating IP addresses” on page 254.

Note: This function is not supported when RHEL is used for the network node operating system. For more information about network nodes, see “Network nodes” on page 253.

•Quality of service (QoS) support. With these settings, you can define how fast a VM can send data without any special hardware. For more information, see “Quality of service” on page 267.

Considerations: The following restrictions apply to SDN:

•These REST APIs are not available:

 – HMC Registration:

POST /v2.1/{tenant_id}/ibm-hmcs

 – Managing an existing VM:

 • POST /v2.1/{tenant_id}/os-hosts/{host_name}/onboard

 • POST /v2.1/{tenant_id}/os-hosts/{host_name}/unmanage

 • GET /v2.1/{tenant_id}/os-hosts/{host_name}/all-servers

 – Host Shared Ethernet Adapters:

GET /v2.1/{tenant_id}/host-seas

•The verify environment tool is not supported.

•When using the Host network placement API, all networks are considered valid for all hosts.

This appendix covers the following topics:

•“SDN requirements for IBM PowerVC”

•“Security groups” on page 248

•“Components of private and public communication when using SDN” on page 250

•“Setting up a network node” on page 255

SDN requirements for IBM PowerVC

You must meet the following requirements before you can implement the SDN technical preview. You must also install IBM PowerVC in preview mode to activate the SDN functions. For more information, see 3.2, “Installing IBM PowerVC” on page 71.

Note: You cannot upgrade from a previous version of IBM PowerVC to the SDN technical preview mode. Additionally, you cannot upgrade from SDN technical preview mode to other versions.

Compute node requirements

The compute node must meet the following requirements:

•It must have at least one NovaLink based PowerVM system that is installed with the SDN technical preview.

Note: When IBM PowerVC is running in the SDN technology preview mode, all virtual Ethernet routing runs through the NovaLink component. IBM PowerVC cannot provision Shared Ethernet Adapters (SEAs). This is a limitation of the technical preview only.

•All necessary ports are opened, as described in IBM Knowledge Center:

http://www.ibm.com/support/knowledgecenter/SSXK2N_1.3.1/com.ibm.powervc.standard.help.doc/powervc_planning_security_firewall_hmc.html

Configuring NovaLink for the SDN technical preview

There are two ways to configure your NovaLink based system for the SDN technical preview:

•Platform installer

When you use the NovaLink PowerVM Platform Installer with the SDN technical preview option, the installer builds the system with the necessary components to enable IBM PowerVC to connect to the system and manage SDN. This setup includes installing the software, attaching a physical network interface card (NIC) to the NovaLink partition, and performing basic configuration of the OVS component on the NovaLink system.

•Manual configuration

If you choose to manually configure your NovaLink based system for the SDN technical preview, you must perform these configuration steps:

 – Assign a physical network card to the NovaLink management partition.

 – Ensure that the NovaLink operating system is RHEL 7.3 LE or Ubuntu 16.04 LTS.

Note: If you are having connectivity issues, the firewall is likely causing the problem. Apply firewall rules only to external facing devices, such as br-ex. Do not apply them against the internal devices, such as br-tun, br-int, or tap devices. To determine whether the firewall is the problem, disable the firewall for a short time and if connectivity is restored, that indicates that the rules are incorrect. For RHEL, the firewall might need to be disabled by running systemctl disable firewalld.

 – Register a host. IBM PowerVC installs OVS and creates a placeholder vSwitch bridge named br-ex. You must add a physical port or link aggregation to br-ex.

Network node requirements

If you plan to use overlay networks, virtual routers, or floating IP addresses, a network node is required. Use at least three nodes for redundancy and load-balancing purposes, even though only one node is required. Network nodes and servers have these requirements:

•At least two cores with 8 GB of memory. Extra processors and memory can increase throughput.

•Either x86_64 or ppc64le. This can be a PowerVM VM with direct-attach Network I/O.

•Supported operating system: Ubuntu 16.04 (ppc64le or x86_64).

Note: RHEL 7.3 (ppc64le or x86_64) is not supported as a network node for the technical preview.

•Attached to the public WAN and has IP connectivity to the NovaLink compute host.

•OVS is configured with one port named br-ex. The br-ex port requires the following items:

 – It must have IP connectivity to your NovaLink hosts and your WAN.

 – It must be on a network that has free IP addresses for your floating IP addresses.

 – It must be attached to a physical port.

•IBM PowerVC sets up br-ex in the network node at installation time.

•You cannot use a PowerVM VM with virtual I/O. However, if the VM has a dedicated network card, it can run as a network node.

Because the network node serves as the bridge between the WAN and the overlay networks, the switch port must have the appropriate VLANs to host the floating IP addresses and virtual routers, which are typically the VLANs that you configure to the compute host, but with SDN they are configured to the smaller set of network nodes instead.

Security groups

Security groups are part of the IBM PowerVC technical preview functions. They let you control which VMs can communicate with each other by creating a security group and then assigning it to a VM. The security group has a set of rules that specify how the VM is allowed to communicate with others.

IBM PowerVC comes with a default security group named “default”. The default security group allows all inbound and outbound traffic. If you want your default security group to be more restrictive, you can delete the existing rules of that group and add the new rules. Alternatively, you can create a security group with the rules that you want.

Setting up a security group

To set up a security group on a VM, you must set up a security group for a port on the VM by completing the following steps:

1. Create a security group by running the following command. To find the value for project_ID, run openstack project list.

neutron security-group-create <name> --tenant-id <project_ID>

--description <description>

The new security group has two rules that allow outbound traffic through IPv4 and IPv6, as shown in Example A-1.

Example A-1 Security groups that are defined

neutron security-group-create test-sg --tenant-id 66988123f81842ef82bdb2265abe502e --description "Test security group"

2. Add rules to the new security group and remove the security rules that are not required. The rules in a security group control what the VM can access. Use these commands to work with security group rules. For a list of all available security group rules, run neutron security-group-rule-list.

a. Create a security group rule by running the following command:

neutron security-group-rule-create

Example A-2 shows the output of this command.

Example A-2 Create a security group

/usr/bin/neutron security-group-rule-create --direction ingress --ethertype IPv4

--description "Test security group rule" my_security_group

/usr/bin/neutron security-group-rule-create --direction ingress --ethertype IPv6

--description "Test security group rule" my_security_group

b. Delete a security group rule by running the following command:

neutron security-group-rule-delete <security_group_rule>

3. Apply the security group to a specific port by running the following command:

neutron port-update <port_uuid> --security-group <security_group>

a. If you do not know the port UUID, run neutron port-list.

b. If you want to associate multiple security groups with a port, repeat the option --security-group.

Updating or removing a security group

To modify the security group or remove it from the port, complete the following steps:

1. Update the security group by running the following command:

security-group-update [--name NAME] [--description DESCRIPTION] <security_group>

2. Update the rules of a security group. You cannot update an existing rule. You must remove the rule that is not required and add the rules as required.

3. Detach all security groups from a port by running the following command:

neutron port-update <port_uuid> --no-security-groups

Applying security groups to an instance during a deployment

There are two ways to apply a security group during a deployment.

1. Use ports that are associated with security groups:

a. Create a port by running the following command:

neutron port-create --security-group <security_group> <network>

If you want to associate multiple security groups with a port, repeat the option --security-group.

Example A-3 shows the output of the command.

Example A-3 Associate multiple security groups

neutron port -create --security-group <sg1> --security-group <sg2> <network>

b. Deploy a VM by using the port that you created by running the following command:

nova boot -–nic port-id=<port-uuid> <other parameters as necessary>

2. Deploy the VM by using the nova boot command with the --security-groups option.

Components of private and public communication when using SDN

You can use SDN to set up a virtual private network between VMs that are not physically connected, which helps you change your network faster and more efficiently. For example, if you need more IP addresses or you have a new project that needs a network, an administrator create the necessary setup instantly.

There are several features available to you when using SDN. If you plan to use network overlays, you must consider using network nodes to support virtual routers and floating IP addresses. Here are the features:

Network overlays Private virtual networks that allow VMs to communicate on a private network without requiring physical infrastructure updates.

Network nodes VMs or physical hosts where virtual routers run.

Virtual routers Allow VMs on a network overlay to communicate with the WAN.

Floating IP addresses Public IP addresses (from the WAN) that can be dynamically assigned to a VM. Floating IP addresses allow systems on the WAN to communicate with a VM on a network overlay.

A network overlay with virtual router and floating addresses is shown in Figure A-1.

Figure A-1 SDN network components

Network overlays

One key component of SDN is the use of network overlays. A network overlay is a virtual network that connects VMs together on a private network segment even if the host systems are on different base VLANs. A network overlay can connect VMs that are on different physical networks if the host servers have IP connectivity.

The network overlay works by encapsulating the VM's Ethernet packet in the PowerVM NovaLink host's IP packet. The encapsulation process bundles the client VM's Ethernet packet into its overlay and then sends it to the other host. The outer address routes the packet from one host to the other. Then, the inner address ensures that the packet is delivered to the correct VM. The packet encapsulation is done by the OVS in the NovaLink partition.

Figure A-2 shows the SDN encapsulation process.

Figure A-2 SDN encapsulation

In Figure A-2, the packet must go from VM Red1 to VM Red2, but they are not physically connected. However, a Red network overlay was set up between the two VMs. The network overlay embeds the packet in another packet that is sent from NovaLink 1 to NovaLink 2. When the packet arrives at NovaLink 2, it is delivered to Red2.

Figure A-3 shows how the network overlay embeds packets.

Figure A-3 Ethernet packets before and after encapsulation

Overlay networks have their own VXLAN identifier. If each VXLAN ID is unique, network IP addresses for VMs that are on different overlay networks can overlap. For example, in Figure A-2, the VMs Red1 and Blue1 have the same IP address. This overlap does not cause any conflicts with internal communication because they are on different overlay networks. When external sources try to access IP addresses on an overlay network, IBM PowerVC uses Floating IP addresses to avoid confusion.

Network nodes

Network nodes are systems (either VMs or physical hosts) where virtual routers run. They route traffic to and from the external network (WAN). Because each network node can have several virtual routers, this system must be fast enough to handle routing traffic for multiple networks. You can set up your environment with a single network node, but it is a preferred practice to have multiple network nodes. This practice avoids network bottlenecks and helps ensure that your network does not fail if one node goes down. When creating multiple network nodes, they must all be on the same physical network. If you do set up multiple network nodes, one node is in standby mode until the active node fails.

An environment with multiple network nodes is shown in Figure A-4.

Figure A-4 Multiple network nodes in an SDN network

In Figure A-4, there are two self-contained network overlays. VM 1 and VM 4 can communicate with each other, and VM 2 and VM 3 can communicate with each other. However, VM 1 cannot communicate with VM 2 or VM 3. All four VMs can communicate with the WAN. The two network nodes are identical. This duplication serves two purposes. They share the network traffic load, and if one node stops working, all of the networks are still fully functional. IBM PowerVC uses the OpenStack Neutron Virtual Router Redundancy Protocol (VRRP) to handle redundancy.

Virtual routers

Overlay networks are virtual networks. For network overlays to communicate with the WAN, a virtual router is needed. A virtual router runs on a network node, which provides access to the WAN. It also has an OVS, which can communicate on the overlay network. The virtual router bridges the WAN and the overlay network.

Note: The virtual router allows the VM to communicate to the WAN by using Network Address Translation (NAT), but traffic coming from the WAN cannot reach the VM unless you set up a floating IP address.

Virtual routers are meant to be used only with overlay networks. VLAN and flat networks are bridged directly onto the physical Ethernet, similar to shared Ethernet networking.

In Figure A-5, VM1 and VM2 can communicate with each other over the green overlay network. Both VMs can communicate to the WAN through the virtual router, but machines on the WAN cannot communicate with VM1 or VM2.

Figure A-5 Shows the virtual router that connects the green overlay network with the WAN

Floating IP addresses

A floating IP address is a public-facing IP address that is attached to a VM on an overlay network. The virtual router then uses NAT to change the IP address. Floating IP addresses serve two purposes:

•They allow external addresses to connect to addresses on the virtual overlay network.

•The floating IP addresses are always unique, so even if IP addresses overlap between overlay networks, the external packets can reach the appropriate VM.

Note: Floating IP addresses should be assigned to the NIC on the VM with the default gateway. IBM PowerVC deploys this as the first NIC on the VM. If there are additional NICs and the default gateway is changed to a different NIC, the floating IP should be reassociated with that other NIC.

Setting up a network node

Network nodes are systems (either VMs or physical hosts) where virtual routers run. They route traffic to and from the external network (WAN). Because each network node can have several virtual routers, this system must be fast enough to handle routing traffic for multiple networks.

You can set up your environment with a single network node, but it is a preferred practice to have multiple network nodes. This practice avoids network bottlenecks and helps ensure that your network does not fail if one node goes down. When creating multiple network nodes, they must all be on the same physical network. If you do set up multiple network nodes, one node is in standby mode until the active node fails.

You must ensure that the system you use as a network node is set up correctly, then add it to IBM PowerVC. Ensure that the system meets the requirements that are listed in “SDN requirements for IBM PowerVC” on page 246.

Other configuration that might be required:

•If you are having connectivity issues, the firewall is likely causing the problem. Apply firewall rules only to external facing devices, such as br-ex. Do not apply them against the internal devices, such as br-tun, br-int, or tap devices. To determine whether the firewall is the problem, disable the firewall for a short time and if connectivity is restored, that indicates that the rules are incorrect. For RHEL, the firewall might need to be disabled by running systemctl disable firewalld.

•You might need to modify the /etc/network/interfaces file to ensure that ports are not removed from br-ex after restarting. Example A-4 shows an example for Ubuntu 16.04 that ensures that the br-ex network starts correctly after your system is restarted.

Example A-4 Checking for correct ports

source /etc/network/interfaces.d/*

# The loopback network interface

auto lo

iface lo inet loopback

auto br-ex

llow-ovs br-ex

iface br-ex inet static

ovs_type OVSBridge

ovs_ports ens3

# The primary network interface

address 192.0.2.64

netmask 255.255.255.0

etwork 192.0.2.0

roadcast 192.0.2.255

gateway 192.0.2.254

# dns-* options are implemented by the resolvconf package, if installed

dns-nameservers 198.51.100.50

dns-search dns.mycompany.com

auto ens3

allow-br-ex l2port

iface ens3 inet manual

ovs_bridge br-ex

vs_type OVSPort

# The following is sometimes required so ports are not removed from br-ex after rebooting:

post-up ovs-vsctl add-port br-ex ens

To add the network node to IBM PowerVC, run the following command:

powervc-register -r network-node -o add -n <node_name> -p <properties_file>

Example properties file

Example A-5 is an example of a properties file.

Example A-5 Property file example

access_ip = 1.2.3.4

user_id = user1

password = passw0rd

If you must unregister the network node from IBM PowerVC, run the following command:

powervc-register -r network-node -o remove -n <node_name>

Useful commands and scripts

This appendix provides some useful commands and scripts, and covers the following topics:

•“Useful OpenStack commands” on page 258

•“Useful powervc-config commands” on page 259

•“Useful software-defined network commands (technical preview only)” on page 264

•“Useful scripts” on page 269

•“REST APIs example” on page 271

Useful OpenStack commands

This section includes some commands that you might find useful.

Adding a user to access the IBM Power Virtualization Center GUI instead of root

You can run the commands that are shown in Example B-1 to access the IBM Power Virtualization Center (IBM PowerVC) GUI. You most likely want to change the password to something much more secure.

Example B-1 Commands to access the IBM PowerVC GUI

# adduser powervc -p SECRET

# source /opt/ibm/powervc/powervcrc

# export OS_USERNAME=root

# export OS_PASSWORD=SECRET

# openstack role add --project ibm-default --user powervc admin

Adding and listing a project

To create a project and list it, run the commands that are shown in Example B-2.

Example B-2 Create and list a project

# openstack project create --description "Six Project" six

+-------------+----------------------------------+

| Field | Value |

+-------------+----------------------------------+

| description | Six Project |

| domain_id | default |

| enabled | True |

| id | 4e5ed9491daf44319eab573ebd0825e6 |

| is_domain | False |

| name | six |

| parent_id | default |

+-------------+----------------------------------+

# openstack project list

+----------------------------------+-------------+

| ID | Name |

+----------------------------------+-------------+

| 135537788461455183a90a4886142a65 | powervm |

| 1f0ca545a81a4fffa8af6cf5fd2bea91 | ibm-default |

| 4e5ed9491daf44319eab573ebd0825e6 | six |

| aa0ed38f28154f0aaac3c0e60decfb65 | service |

+----------------------------------+-------------+

Creating users and roles for access to a project

You can create users and add roles to them by running the commands that are shown in Example B-3. You might want to use a more secure password.

Example B-3 Create users and roles for access to a project

# adduser sixadmin -p SECRET

# adduser halfdozen -p SECRET

# openstack role add --project six --user sixadmin admin

# openstack role add --project six --user halfdozen admin

# openstack user list

+--------------------------+-------------------+

| ID | Name |

+--------------------------+-------------------+

. . .

| 1dd45dfca1d83b0e38 . . . | powervc            |

| 79d13683f8ab37b1d5 . . . | sixadmin |

| 897db369914c6109c4 . . . | halfdozen |

+--------------------------+-------------------+

Changing a role

Perhaps you need to change a role after you discover that a user is not an administrator. To do so, run the commands that are shown in Example B-4.

Example B-4 Change a role

# openstack role remove --project six --user halfdozen admin

# openstack role add --project six --user halfdozen deployer

Useful powervc-config commands

This section is a quick reference to several commands.

The following commands find the current settings with example output from IBM PowerVC V1.3.2.0 on RHEL 7.3 BE on POWER8. Most of the settings are the default values except the network ones. Adding -h after the command shows you how to set the same variable.

The command that is shown in Example B-5 can be used to set the network domain as the root user.

Example B-5 Set the network domain

# /usr/bin/powervc-config compute server-domain --set ats.uk.ibm.com

The default domain name was updated for the specified hosts. Verify that no tasks are in-progress, then run the '/opt/ibm/powervc/bin/powervc-services nova restart' command to restart the nova services and complete the operation.

General subcommands

This section lists general powervc-config subcommands.

Listing an interface configuration

To list an interface configuration, run the command that is shown in Example B-6.

Example B-6 List an interface configuration

# powervc-config general ifconfig

powervc IP version : 4

powervc management address: vm17.ats.uk.ibm.com

powervc hostname: vm17

ifconfig Change the hostname or IP address of the IBM PowerVC controller

Listing an IP address

To list an IP address, run the command that is shown in Example B-7.

Example B-7 List an IP address

# powervc-config general ipaddress

Current value: 9.137.62.17

ipaddress The IP address of the IBM PowerVC controller Warning: This option will be deprecated in future releases.

Listing a host name

To list a host name, run the command that is shown in Example B-8.

Example B-8 LIst a host name

# powervc-config general hostname

Current value: vm17

hostname The hostname of the IBM PowerVC controller Warning: This option will be deprecated in future releases.

Identify subcommands

The following commands are identify subcommands for the powervc-config command.

Listing a token expiration

To list a token expiration, run the command that is shown in Example B-9.

Example B-9 List a token expiration

# powervc-config identity token_expiration

Current value: 6:00:00

Default value: 6:00:00

token_expiration Configure the expiration interval for the identity token

The output is in Hours:Minutes:Seconds format.

Listing a repository

To list a repository, run the command that is shown in Example B-10.

Example B-10 List a repository

# powervc-config identity repository

IBM PowerVC is configured for operating system authentication.

repository Configure the repository for authentication credentials, for example an LDAP server.

# powervc-config image image_size_cap

Current value: 1099511627776 B

Default value: 1099511627776 B

image_size_cap Configure the maximum image size, which can be uploaded through IBM PowerVC controller

Image subcommand

Example B-11 shows the image subcommand.

Example B-11 Image subcommand

# powervc-config image user_storage_quota

Current value: 0 B

Default value: 0 B

user_storage_quota Configure the maximum amount of per-user image storage.

Storage subcommand

Example B-12 shows the storage subcommand.

Example B-12 Storage subcommand

# powervc-config storage portgroup

portgroup Configure the EMC VMAX PortGroup list

Compute subcommand

Example B-13 shows the compute subcommand.

Example B-13 Compute subcommand

# powervc-config compute server-domain

[global] (none)

828641A_214423W localdomain

828641A_212B8BW localdomain

824721L_213C93A pok.stglabs.ibm.com

824721L_2142B2A pok.stglabs.ibm.com

828642A_21C1B6V pok.stglabs.ibm.com

Metering subcommands

The following commands are useful subcommands to display the metering in your
IBM PowerVC environment.

Working with meter data

You can show the current time to live value for the meter data by running the command that is shown in Example B-14.

Example B-14 Current time to live value command

# powervc-config metering meter_ttl

Current value: 14 days, 0:00:00

Default value: 14 days, 0:00:00

Note: By default, the meter data is stored for 14 days.

To change it (for example, to 30 days - 30*24=720), run the following command:

# powervc-config metering meter_ttl --set 720 --unit hr

Setting metering_time_to_live to 720 hr

To get metering data by using “the curl method”, complete the following steps:

1. Source the environment (for a specific project; the example here is ibm-default) by running the following command:

# source /opt/ibm/powervc/powervcrc

2. Get the token by running the following command:

# openstack token issue

Because the Token ID is a long value and might be difficult to extract because of the ASCII table, you can parse the command output for easy copy by running the following command:

# openstack token issue | head -5 | grep id | awk '{print $4}'

3. Use the obtained Token ID and get all data for a given project for all users in that project (in JSON Format) by running the following command:

# curl -1 -k -X GET \ "https://localhost:5000/powervc/openstack/metering/v2/samples?q.field=project_id&q.value=<Project ID>" -H "X-Auth-Token:<Token ID>" | python-m json.tool

You also can get CPU EC values for a given project for all users in that project (in JSON Format) by running the following command:

# curl -1 -k -X GET \ "https://localhost:5000/powervc/openstack/metering/v2/meters/total_vcpu?q.field=project_id&q.value=<Project ID>" -H "X-Auth-Token:<Token ID>" | python-m json.tool

Running data queries

You can run data queries by using the following command examples.

To run a data query to obtain the total number of volumes, run the command that is shown in Example B-15.

Example B-15 Data query to obtain the total number of volumes

# curl -1 -k -X GET \

"https://localhost:5000/powervc/openstack/metering/v2/meters/total_volumes?q.field=project_id&q.value=<Project ID>" -H "X-Auth-Token:<Token ID>" | python -m json.tool | grep counter_name | wc -l

Note: By default, a query for data gives back a maximum of 100 entries.

To run a data query to obtain the total number of volumes and show up to 1000 entries if available, run the command that is shown in Example B-16.

Example B-16 Data query to obtain the total number of volumes and show up to 1000 entries

# curl -1 -k -X GET \

"https://localhost:5000/powervc/openstack/metering/v2/meters/total_volumes?limit=1000q.field=project_id&q.value=<Project ID>" -H "X-Auth-Token:<Token ID>" | python-mjson.tool | grep counter_name | wc -l

Web subcommands

The following subcommands control inactivity time outs and password prompts.

inactivity_timeout

Example B-17 shows the inactivity_timeout subcommand.

Example B-17 The inactivity_timeout command

# powervc-config web inactivity_timeout

Current value: 2:00:00

Default value: 2:00:00

inactivity_timeout Time that UI users will be allowed to idle before being prompted and logged out. Value 0 or less will disable the timer.

token_expiration_warning_time

Example B-18 shows the token_expiration_warning_time subcommand.

Example B-18 The token_expiration_warning_time subcommand

# powervc-config web token_expiration_warning_time

Current value: 0:15:00

Default value: 0:15:00

token_expiration_warning_time Time before token expiration to prompt user for password to obtain new token. Value 0 or less will disable the timer.

Useful software-defined network commands (technical preview only)

This section provides you with a handful of commands for implementing and supporting software-defined networks (SDNs).

Network configuration

The following commands assist you in configuring the main network aspects of SDN.

Creating an overlay network

To create a Virtual Extensible LAN (VXLAN) overlay network named private with a segmentation ID of 20,000, run the command that is shown in Example B-19.

Example B-19 Create an overlay network

# neutron net-create private --provider:network_type \

vxlan --provider:segmentation_id 20000

Created a new network:

+---------------------------+--------------------------------------+

| Field | Value |

+---------------------------+--------------------------------------+

| admin_state_up | True |

| availability_zone_hints | |

| availability_zones | |

| created_at | 2016-11-16T22:32:18Z |

| description | |

| id | 4c1c6dd5-1b04-4e0d-923a-6590e268e52c |

| ipv4_address_scope | |

| ipv6_address_scope | |

| mtu | 1450 |

| name | private |

| port_security_enabled | True |

| project_id | cbfc12b911b44c299fa6d412a507b125 |

| provider:network_type | vxlan |

| provider:physical_network | |

| provider:segmentation_id | 20000 |

| qos_policy_id | |

| revision_number | 3 |

| router:external | False |

| shared | False |

| status | ACTIVE |

| subnets | |

| tags | |

| tenant_id | cbfc12b911b44c299fa6d412a507b125 |

| updated_at | 2016-11-16T22:32:18Z |

+---------------------------+--------------------------------------+

Defining a subnetwork for the private network

To create a subnetwork that is named my_subnet within the new overlay network, run the command that is shown in Example B-20.

Example B-20 Define a subnetwork for the private network

# neutron subnet-create private 10.0.0.0/24 --name my_subnet --dns-nameservers list=true 8.8.8.8 8.8.4.4

Created a new subnet:

+-------------------+--------------------------------------------+

| Field | Value |

+-------------------+--------------------------------------------+

| allocation_pools | {"start": "10.0.0.2", "end": "10.0.0.254"} |

| cidr | 10.0.0.0/24 |

| created_at | 2016-11-18T00:22:48Z |

| description | |

| dns_nameservers | 8.8.8.8 |

| | 8.8.4.4 |

| enable_dhcp | True |

| gateway_ip | 10.0.0.1 |

| host_routes | |

| id | 4ec7b422-4613-4a28-a0ef-3a4fa2e0ff88 |

| ip_version | 4 |

| ipv6_address_mode | |

| ipv6_ra_mode | |

| name | my_subnet |

| network_id | 4c1c6dd5-1b04-4e0d-923a-6590e268e52c |

| project_id | cbfc12b911b44c299fa6d412a507b125 |

| revision_number | 2 |

| service_types | |

| subnetpool_id | |

| tenant_id | cbfc12b911b44c299fa6d412a507b125 |

| updated_at | 2016-11-18T00:22:48Z |

+-------------------+--------------------------------------------+

Defining the external network

To create an external network named “public”, run the command that is shown in Example B-21.

Example B-21 Define the external network

# neutron net-create public --provider:network_type flat --provider:physical_network external --router:external=True

+---------------------------+--------------------------------------+

| Field | Value |

+---------------------------+--------------------------------------+

| admin_state_up | True |

| availability_zone_hints | |

| availability_zones | |

| created_at | 2016-11-18T07:47:44Z |

| description | |

| id | b7bf326b-9b02-4f6d-a0a5-597e3a1bb2a8 |

| ipv4_address_scope | |

| ipv6_address_scope | |

| is_default | False |

| mtu | 1500 |

| name | public |

| port_security_enabled | True |

| project_id | cbfc12b911b44c299fa6d412a507b125 |

| provider:network_type | flat |

| provider:physical_network | external |

| provider:segmentation_id | |

| qos_policy_id | |

| revision_number | 3 |

| router:external | True |

| shared | False |

| status | ACTIVE |

| subnets | |

| tags | |

| tenant_id | cbfc12b911b44c299fa6d412a507b125 |

| updated_at | 2016-11-18T07:47:44Z |

+---------------------------+--------------------------------------+

Creating a subnetwork for the external network

To define a subnetwork for the previously created public network that is named new_subnet, run the command that is shown in Example B-22.

Example B-22 Create a subnetwork for the external network

# neutron subnet-create --disable-dhcp --gateway 9.47.79.254 \

--name new_subnet --allocation-pool start=9.47.70.153,\

end=9.47.70.155 --allocation-pool start=9.47.66.25,\

end=9.47.66.28 public 9.47.64.0/20

Note:

•All of the network nodes must be on the same physical network, and therefore must be on the same subnet.

•If you have a disconnected set of IP addresses within a subnet, you need to set up multiple allocation pools.

Creating the virtual router

This virtual router can be used for multiple overlay networks and allows the VMs on the overlay network to access the wide area network (WAN).

To create the virtual router, complete the following steps:

1. Run the following command:

# neutron router-create private_to_public

2. Get the network UUID from the output of the command and run the router-gateway-set command to give the router an external gateway. Running the following commands reserves a port on the public facing network for this router:

# neutron net-list

# neutron router-gateway-set private_to_public external_network_uuid

3. Run the subnet-list command to determine the private VXLAN subnet from step 2 and then run router-interface-add to add that subnet to the router:

# neutron subnet-list

# neutron router-interface-add private_to_public private_subnet

This attaches a port from the private overlay network to this router. That port is the gateway address for the virtual machines (VMs).

Important: You must set up the router interface for the overlay network before deploying VMs in the network.

Creating a floating IP address

To create a floating IP on the external network that was created in step 1 on page 266, run the following command:

# neutron floatingip-create public

Associating the new floating IP address

To associate the new floating IP with one of your VMs, run the following command:

# neutron floatingip-associate floating_ip_address VM_port_ID

Where floating_ip_address is the floating IP UUID and VM_port_ID is the port ID of the VM with which the floating IP address associates. The value for floating_ip_address must be a member of the public IP address pool that you specified in “Creating a floating IP address”. To determine the IP address to use, run these commands:

# neutron floatingip-list

# neutron port-list

Note: Floating IP addresses are separate from the VMs. A VM with an associated floating IP address has no awareness of the floating IP address.

Tip: To ensure that the new application does not use too much of the production environment's bandwidth, set up QoS controls, as described in “Quality of service”.

Quality of service

This section provides commands to establish and control the bandwidth of a given application by using policies.

Quality of service network policy (limits)

To create an SR-IOV control policy to limit the bandwidth that applications running at the VMs can use, run the following command:

# neutron qos-policy-create new_limit

Creating quality of service policy rules

To create a rule within the quality of service (QoS) policy so that ports that are attached to this policy cannot send data faster than 5,000 kilobits per second, run the following command:

# neutron qos-bandwidth-limit-rule-create new_limit --max-kbps 5000

Applying the quality of service policy

To bind and enable the defined QoS policy into a specific port, for example, port 80 for a web server, run the following command:

# port-update 80 --qos-policy new_limit

Listing quality of service rules

To list existing QoS rules to find their respective UUIDs for management, run the following command:

# neutron qos-bandwidth-limit-rule-list

Updating a quality of service rule

To update a defined QoS rule with new configuration values, run the following command:

# qos-bandwitdh-limit-rule-update <qos-bandwidth-rule-uuid> <qos-policy-name> --max-kbps <rate>

Removing a quality of service rule from a port

To remove a QoS rule from a specific port, run the following command:

# neutron port-update <port_uuid> --no-qos-policy

Security management

This section shows some useful commands to implement the appropriate levels of security through the creation of groups and rules within your SDN configuration.

Creating a security group

You can set up security groups as an additional layer of security, as shown in Example B-23. This group segmentation can limit with what a VM can communicate.

Example B-23 Create a security group

# neutron security-group-create My_group

Created a new security_group:

+-------------------+--------------------------------------+

| Field | Value |

+-------------------+--------------------------------------+

| created_at | 2016-11-18T07:25:25Z |

| description | |

| id | dc489d02-8ca3-4ea3-9393-7416b83dfa2b |

+-------------------+--------------------------------------+

Adding rules to a security group

You can create a rule that allows the members of the group to be pinged from all IP addresses, as shown in Example B-24. Use the group ID that is returned from Example B-23 instead of the group name.

Example B-24 Add rules to the security group

# neutron security-group-rule-create --protocol icmp --direction \

ingress 23a99c7f-3097-4f9b-9460-6e33cc4b54ad

Created a new security_group_rule:

+-------------------+--------------------------------------+

| Field | Value |

+-------------------+--------------------------------------+

| created_at | 2016-11-18T07:26:10Z |

| description | |

| direction | ingress |

| ethertype | IPv4 |

| id | 23a99c7f-3097-4f9b-9460-6e33cc4b54ad |

| port_range_max | |

| port_range_min | |

| project_id | cbfc12b911b44c299fa6d412a507b125 |

| protocol | icmp |

| remote_group_id | |

| remote_ip_prefix | |

| revision_number | 1 |

| security_group_id | dc489d02-8ca3-4ea3-9393-7416b83dfa2b |

| tenant_id | cbfc12b911b44c299fa6d412a507b125 |

| updated_at | 2016-11-18T07:26:10Z |

+-------------------+--------------------------------------+

Removing a security group

To remove an existing security group by providing the UUID, run the following command:

# neutron security-group-delete dc489d02-8ca3-4ea3-9393-7416b83dfa2b

Deleted security_group(s): dc489d02-8ca3-4ea3-9393-7416b83dfa2b

Useful scripts

The scripts that are provided in this section format output as report quality output.

Listing the defined projects and user assignments

To list the projects and users that are defined, run the openstack role assignment list command. A script is helpful to align the output into something more readable.

Note:

•The -f option stops TTY style output.

•The -c column-name option selects what is output.

•The --name option removes the hexadecimal D and provides the names (note the double "-").

•Removing the @Service lines removes internal users.

By project, role, and user name

The script that is shown in produces list quality output from the openstack command.

Example B-25 List by project, role, and user name

# openstack role assignment list -c Project -c Role -c User --names -f value \

| grep -v @Service | sed 's/@Default//g' | \

awk '{ printf "%-15s %-15s %-15s\n", $3, $1, $2 }' | sort

eight admin eightadmin

eight admin nig

eight admin powervc

eight deployer eightdep

eight self_service eightself

eight self_service scotts

ibm-default admin nig

ibm-default admin powervc

ibm-default admin root

ibm-default self_service scotts

seven admin nig

seven admin powervc

seven admin sevenadmin

seven deployer sevendep

seven self_service scotts

seven self_service powrpro

seven self_service sevenself

six admin nig

six admin powervc

six admin sixadmin

six deployer halfdozen

six self_service scotts

six self_service sixtine

six self_service sixtus

By user name, project, and role

The script that is shown in Example B-26 produces list quality output from the openstack command.

Example B-26 List by user name, project, and role

# openstack role assignment list -c Project -c Role -c User --names -f value | grep -v @Service | sed 's/@Default//g' | awk '{ printf "%-15s %-15s %-15s\n", $2, $3, $1 }' | sort

eightadmin eight admin

eightdep eight deployer

eightself eight self_service

halfdozen six deployer

scotts eight self_service

scotts ibm-default self_service

scotts seven self_service

scotts six self_service

nig eight admin

nig ibm-default admin

nig seven admin

nig six admin

powervc          eight admin

powervc         ibm-default admin

powervc         seven admin

powervc         six admin

root ibm-default admin

powrpro seven self_service

sevenadmin seven admin

sevendep seven deployer

sevenself seven self_service

sixadmin six admin

sixtine six self_service

sixtus six self_service

REST APIs example

There is no CLI for working with IBM PowerVC on a script basis, but you can use several types of interfaces to build solutions on top of IBM PowerVC:

•Supported OpenStack APIs: These APIs are a subset of the APIs that are provided by OpenStack and can be used with IBM PowerVC without any modifications.

•Extended OpenStack APIs: These APIs are a subset of the APIs that are provided by OpenStack, but their functions are extended by IBM PowerVC.

•IBM PowerVC APIs: These APIs do not exist in OpenStack and are exclusive to
IBM PowerVC.

Note: For more information about IBM PowerVC APIs, see IBM Knowledge Center:

https://www.ibm.com/support/knowledgecenter/en/SSXK2N_1.3.1/com.ibm.powervc.standard.help.doc/powervc_pg_kickoff_hmc.html

Here is an example of removing a volume by using the supported OpenStack APIs.

Complete the following steps:

1. After IBM PowerVC services are installed and running on a managing system, the first step is to request an authorization token by using the openstack token issue command, as shown in Example B-27. This token is required to use the required APIs.

Example B-27 Token request from the command line

# openstack token issue

+------------+---------------------------------------------------------------------------------+

| Field | Value

+------------+--------------------------------------------------------------------------------------------------+

| expires | 2016-11-21 23:06:13+00:00

| id | gAAAAABYMymFWIDo33jqqA1S7xs24ajCkTq1GmhcsslNHWVIdaR2c0gTFK04yAGY0A2YanERAw7vmoSdYUOAmzYn-

| | 5ns_k37EL4FjWOj49aQFqd44XcFGxHIKm6kPl6_wyyYwqrD39OXJBl1XBT_hh0z-AqYBpQS9PZrYt-

| | gv39KgKOq4pRFoUtXd0ffwNMIFin36hY5MFBtLDXDRRZWKb481M0dGAMGHMgRdUGsfbKcwCH0aVf_Z54

| project_id | c0c4c1559ef24cc2b6541e80c43858d4

| user_id | 0688b01e6439ca32d698d20789d52169126fb41fb1a4ddafcebb97d854e836c9

+------------+---------------------------------------------------------------------------------+

Note: Access tokens are valid for 6 hours. Request a new token at least 1 hour before it expires to ensure that the token does not expire in the middle of an operation.

2. To use the OpenStack APIs, you need the tenant-id. For Version 3.0 and later APIs, the terms tenant and project are interchangeable. To get the ID, create a python script or use a REST plug-in in your browser, such as RESTED 1.0.0. You can accomplish this task by using either the CLI or the GUI.

To use the CLI, run the commands that are shown in Example B-28.

Example B-28 Tenant-id request from command line

# cat tenants

#!/usr/bin/python

import httplib

import json

import os

import sys

def main():

token = raw_input("Please enter PowerVC token : ")

print "PowerVC token used = "+token

conn = httplib.HTTPSConnection('localhost')

headers = {"X-Auth-Token":token, "Content-type":"application/json"}

body = ""

conn.request("GET", "/powervc/openstack/identity/v3/projects", body, headers)

response = conn.getresponse()

raw_response = response.read()

conn.close()

json_data = json.loads(raw_response)

print json.dumps(json_data, indent=4, sort_keys=True)

if __name__ == "__main__":

main()

# chmod u+x tenants

# ./tenants

Please enter PowerVC token : gAAAAABYMyl-OO6kjXd9oQaZV4W0uZL6uyeobItJ5HR_SjcGVc0pzZGdp_loP2hTJIEz1KgS8qwRK4fmjy3WoDUzVx8u_fDLArW1U86rkUYFshHregGnE_Dskny0SO_ymLATZwcuGeEQO1cBpijeRbZIyP2A0uqjRx0wnVtKEMmeVd48J-Zd7PszIqT8W6EdEDClrQG_hmIiEKCmWqpfOCrsObrtoV_YIno95df5psdOfIkKJCXnk20

PowerVC token used = gAAAAABYMyl-OO6kjXd9oQaZV4W0uZL6uyeobItJ5HR_SjcGVc0pzZGdp_loP2hTJIEz1KgS8qwRK4fmjy3WoDUzVx8u_fDLArW1U86rkUYFshHregGnE_Dskny0SO_ymLATZwcuGeEQO1cBpijeRbZIyP2A0uqjRx0wnVtKEMmeVd48J-Zd7PszIqT8W6EdEDClrQG_hmIiEKCmWqpfOCrsObrtoV_YIno95df5psdOfIkKJCXnk20

{

"links": {

"next": null,

"previous": null,

"self": "https://9.47.76.108/powervc/openstack/identity/v3/projects"

},

"projects": [

{

"description": "IBM Service Tenant for service users and groups",

"domain_id": "7ca0bd908588480486e9399a238e3f4b",

"enabled": true,

"id": "17cd686591c948d3a970d8ac204eaf6e",

"is_domain": false,

"links": {

"self": "https://9.47.76.108/powervc/openstack/identity/v3/projects/17cd686591c948d3a970d8ac204eaf6e"

},

"name": "service",

"parent_id": "7ca0bd908588480486e9399a238e3f4b"

},

{

"description": "IBM Tenant for storing VM NVRAM data for remote restart",

"domain_id": "7ca0bd908588480486e9399a238e3f4b",

"enabled": true,

"id": "473511b7bb5e4733b650e00454e59f47",

"is_domain": false,

"links": {

"self": "https://9.47.76.108/powervc/openstack/identity/v3/projects/473511b7bb5e4733b650e00454e59f47"

},

"name": "powervm",

"parent_id": "7ca0bd908588480486e9399a238e3f4b"

},

{

"description": "IBM Default Tenant",

"domain_id": "default",

"enabled": true,

"id": "c0c4c1559ef24cc2b6541e80c43858d4",

"is_domain": false,

"links": {

"self": "https://9.47.76.108/powervc/openstack/identity/v3/projects/c0c4c1559ef24cc2b6541e80c43858d4"

},

"name": "ibm-default",

"parent_id": "default"

}

]

}

To use the GUI, complete the following steps:

a. Open your browser plug-in and provide the following information, as shown in Figure B-1.

URL: https://powervc.ip/powervc/openstack/identity/v3/projects

Method: GET

Header: X-Auth-Token

Figure B-1 REST request to get the tenant-ids

b. After you submit the request, you get an answer with the details that are shown in Figure B-2.

Figure B-2 API response example

3. To remove a specific volume, use the supported OpenStack Block storage (Cinder) API. Its details are shown in Table B-1.

Table B-1 OpenStack API to remove a volume

Method

Path

Description

DELETE

/v2/{tenant_id}/volumes/{volume_id}

Deletes a specified volume.

You can get the volume_id by calling another Cinder API, or by looking at the volume attributes on IBM PowerVC GUI as shown in Figure B-3.

Figure B-3 Get volume ID attribute

After you get the volume_id, you can call the delete volume API by using a script from the command line or by using any REST plug-in on your browser. You can check the task status on the Messages tab on IBM PowerVC, as shown in Figure B-4.

Figure B-4 Volume deletion status message

Related publications

The publications that are listed in this section are considered suitable for a more detailed description of the topics that are covered in this book.

IBM Redbooks

The following IBM Redbooks publications provide additional information about the topic in this document. Some publications that are referenced in this list might be available in softcopy only.

•IBM Power Systems HMC Implementation and Usage Guide, SG24-7491

•IBM PowerVM Enhancements What is New in 2013, SG24-8198

•IBM PowerVM Virtualization Introduction and Configuration, SG24-7940

•IBM PowerVM Virtualization Managing and Monitoring, SG24-7590

•Implementing the IBM System Storage SAN Volume Controller with IBM Spectrum Virtualize V7.6, SG24-7933

You can search for, view, download, or order these documents and other Redbooks, Redpapers, web docs, draft and additional materials, at the following website:

ibm.com/redbooks

Online resources

These websites are also relevant as further information sources:

•IBM Knowledge Center:

http://www.ibm.com/support/knowledgecenter/

•IBM PowerVC V1.3.1 Cheat Sheet:

https://www.ibm.com/developerworks/community/blogs/aixpert/entry/PowerVC_1_3_1_Cheat_Sheet?lang=en

•Information about IBM Platform Resource Scheduler:

http://www.ibm.com/systems/platformcomputing/products/rs/

•Latest IBM PowerVC Standard Edition requirements:

http://ibm.co/1jC4Xx0

•Managing IBM PowerVC as an administrator:

https://www.ibm.com/support/knowledgecenter/en/SSVSPA_1.3.2/com.ibm.powervc.cloud.help.doc/powervc_cloud_managing_admin.html

•OpenStack:

http://www.openstack.org/foundation/

https://wiki.openstack.org/wiki/Main_Page

•Top-level link for IBM Cloud PowerVC Manager Version 1.3.1 documentation:

https://www.ibm.com/support/knowledgecenter/en/SSVSPA_1.3.1/com.ibm.powervc.cloud.help.doc/kc_welcome-cloud-supermap.html

•Top-level link for IBM PowerVC Standard Edition Version 1.3.1 documentation:

https://www.ibm.com/support/knowledgecenter/en/SSXK2N_1.3.1/com.ibm.powervc.standard.help.doc/kc_welcome-standard-supermap.html

Help from IBM

IBM Support and downloads

ibm.com/support

IBM Global Services

ibm.com/services

IBM PowerVC Version 1.3.2 Introduction and Configuration

Back cover

Acrobat bookmark

ISBN 0738442348

SG24-8199-04

®