Front cover

IBM Power Virtual Server

Guide
for IBM AIX and Linux
Henry Vo
Andrey Klyachkin
Gayathri Gopalakrishnan
Borislav Stoymirski
Jean-Manuel Lenez
Lokesh Bhatt
Youssef Largou
Prerna Upmanyu
Tim Simon

Redbooks
IBM Redbooks

Power Virtual Server for AIX and Linux

February 2025

SG24-8512-01
 Note: Before using this information and the product it supports, read the information in “Notices” on
page xv.

Second Edition (February 2025)

This edition applies to Version

IBM AIX 7.2
IBM AIX 7.1
CentOS-Stream-8
SUSE Linux Enterprise Server 12 - Minimum level: SP4 + Kernel 4.12.14-95.54.1
SUSE Linux Enterprise Server 15 - Minimum level: SP1 + kernel 4.12.14-197.45-default
Red Hat Enterprise Linux 8.1, 8.2, 8.3, 8.4, 8.6

© Copyright International Business Machines Corporation 2025. All rights reserved.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.
v
vi Power Virtual Server for AIX and Linux
Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Now you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Stay connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

February 2025, Second Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Chapter 1. IBM Power Virtual Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 IBM Cloud and the IBM Power Virtual Server offering . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 IBM Power Virtual Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2.1 Potential consumers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 IBM Power Virtual Server use cases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Key concepts and features for Power Virtual Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 Power Virtual Server workspaces and instances . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.2 Compute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.3 Server placement groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.4 VM pinning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.5 Shared processor pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.6 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.7 Power Virtual Servers networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.8 Operating system images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.9 High availability and disaster recovery options . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 2. Deployment options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1 Creating a Power Virtual Server instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.1 Power Virtual Server workspace and instance . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.2 IBM Cloud Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.3 IBM Cloud Dashboardc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.4 IBM Cloud catalog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.5 Creating your Power Virtual Server Workspace . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1.6 Power Virtual Server instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.7 Fields in the Virtual Servers Instances page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.8 Virtual Server instance status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2 Preparing for AIX and Linux Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.1 Planning to deploy AIX or Linux virtual servers. . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.2 Overview of Supported Configurations and Versions for AIX and Linux. . . . . . . . 32
2.3 Deployment Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4 Deployment with IBM Power Virtual Server web user interface . . . . . . . . . . . . . . . . . . 34
2.5 Deployment with IBM Cloud CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.6 Deployment with Terraform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.7 Deployment with Ansible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.8 Deployment with IBM Power Virtual Server API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Chapter 3. IBM Power Virtual Server in the IBM Cloud network. . . . . . . . . . . . . . . . . . 71

© Copyright IBM Corp. 2025. vii

 3.1 IBM Power Virtual Server Virtual Private Network (VPN) Connectivity . . . . . . . . . . . . . 72
3.1.1 Importance of VPN in Cloud-Based Environments Like Power Virtual Server . . . 72
3.1.2 Setting up a VPN in Power Virtual Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.2 Power Virtual Server Network Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.2.1 Basic Network Architecture in Power Virtual Server . . . . . . . . . . . . . . . . . . . . . . . 78
3.2.2 Public versus private networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.2.3 Network Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.2.4 Direct Link Connect, Megaport, and Edge Gateway . . . . . . . . . . . . . . . . . . . . . . . 82
3.3 Power Virtual Server network connection options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.3.1 Importance of choosing the right network scenario based on workload requirements
84
3.3.2 Factors to consider when choosing a network design for your workload . . . . . . . 86
3.3.3 Production, non-production, and proof-of-concept environments . . . . . . . . . . . . . 87
3.3.4 Hybrid and multi-cloud environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.3.5 Summary of network environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.4 Private Connection using SSL, Jump Server, and Direct Link Connect . . . . . . . . . . . . 92
3.5 Private Connection using Megaport and Direct Link Connect. . . . . . . . . . . . . . . . . . . . 97
3.5.1 Setting Up High-Performance Private Connections Using Megaport Services. . . 97
3.5.2 Benefits of Connecting Through Megaport and Direct Link Connect in Production 98
3.6 Multi-COLO, Multi-region Private Connection using Megaport . . . . . . . . . . . . . . . . . . . 99
3.6.1 Building Multi-Region, Multi-Colocation Connectivity Using Megaport . . . . . . . . . 99
3.6.2 Ensuring Network Redundancy and High Availability . . . . . . . . . . . . . . . . . . . . . 100
3.7 Multi-COLO Private Connection using IBM Cloud Backbone . . . . . . . . . . . . . . . . . . . 101
3.7.1 Leveraging IBM Cloud Backbone for Robust Private Connections. . . . . . . . . . . 101
3.7.2 Scenarios Where IBM Cloud Backbone is Optimal. . . . . . . . . . . . . . . . . . . . . . . 102

Chapter 4. Migration to Cloud with IBM Power Virtual Server . . . . . . . . . . . . . . . . . . 105

4.1 Example case scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.1.2 Architectural decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.1.3 Architectural diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.2 Migrating AIX to a Power Virtual Server through Cloud Object Storage . . . . . . . . . . . 113
4.2.1 An overview of IBM Cloud Object Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.2.2 Creating an instance of IBM Cloud Object Storage in IBM Cloud. . . . . . . . . . . . 113
4.2.3 Creating an OVA image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.3 Migrating AIX to a Power Virtual Server using a mksysb file . . . . . . . . . . . . . . . . . . . 122
4.4 Using Power Virtual Server to migrate a Linux image to the Power Virtual Server. . . 134
4.4.1 Using PowerVC to capture and import an OVA image . . . . . . . . . . . . . . . . . . . . 134
4.4.2 Creating an instance of IBM Cloud Object Storage in IBM Cloud. . . . . . . . . . . . 134
4.5 Migrating SAP workloads to IBM Cloud by using Power Virtual Server . . . . . . . . . . . 140
4.5.1 The unique value proposition of IBM Power Virtual Server for SAP workloads . 140
4.5.2 Use Case: SAP Migration, Greenfield Implementation, and divestiture . . . . . . . 142
4.6 Configurations and Capabilities of IBM Power Systems Virtual Server . . . . . . . . . . . 143
4.6.1 IBM Power Virtual Server certified profiles for SAP HANA . . . . . . . . . . . . . . . . . 144
4.6.2 IBM Power Virtual Server certified profiles for SAP NetWeaver . . . . . . . . . . . . . 144

Chapter 5. Managing Workloads on IBM Power Virtual Server for IBM AIX and Linux
deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
5.1 IBM Power Virtual Server compatibility with IBM AIX and Linux . . . . . . . . . . . . . . . . . 148
5.1.1 Benefits of managing AIX and Linux workloads on Power Virtual Server. . . . . . 148
5.2 Hints and tips for IBM AIX and Linux workloads on Power Virtual Server . . . . . . . . . 150
5.2.1 Tips for efficient allocation of CPU, memory, and storage . . . . . . . . . . . . . . . . . 150
5.2.2 Recommendations for managing high-performance or resource-intensive workloads
151

viii Power Virtual Server for AIX and Linux

5.3 Monitoring and Performance management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
5.3.1 Tools and techniques for monitoring workload performance . . . . . . . . . . . . . . . 152
5.3.2 Tips on setting up alerts, logs, and performance monitoring dashboards. . . . . . 154
5.4 User management and security settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
5.4.1 Creating user roles and setting permissions for AIX and Linux environments . . 155

Chapter 6. IBM Power Virtual Server Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

6.1 Backup and recovery best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6.1.1 Recommendations for setting up regular backups . . . . . . . . . . . . . . . . . . . . . . . 160
6.2 Secure automated backup with Compass for AIX and Linux . . . . . . . . . . . . . . . . . . . 161
6.2.1 Architecture diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
6.2.2 Deploying the backup instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
6.2.3 Pricing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
6.3 Backing up system image to Cloud Object Storage . . . . . . . . . . . . . . . . . . . . . . . . . . 165
6.4 FalconStor StorSafe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
6.4.1 Tips on utilizing IBM Cloud's backup solutions for data resilience and quick recovery
167

Appendix A. Global Replication Services solution using Power Virtual Server . . . . 169
A.1 Solution overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
A.2 Setup for Global Replication Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
A.2.1 DR location sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
A.2.2 Disaster recovery workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
A.2.3 Creating and enabling volume replication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
A.2.4 Creating and updating the volume group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
A.3 Failover and failback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
A.3.1 Steps to take after a primary site failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
A.4 Disabling the replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
A.4.1 Removing the volumes from the volume group on the primary site . . . . . . . . . . 185
A.4.2 Disabling the replication of a volume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
A.5 Billing and charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
A.6 Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
A.6.1 Starting a volume group in any site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
A.6.2 Volume group replication status is not in sync across two sites . . . . . . . . . . . . . 187
A.6.3 Determining whether an update on the volume group fails . . . . . . . . . . . . . . . . 187
A.6.4 The update on a volume group is not working as its status is in error state . . . . 187
A.6.5 Determining which volume is defined as primary for a volume group . . . . . . . . 188
A.6.6 Onboarding new or existing volumes in a volume group . . . . . . . . . . . . . . . . . . 188
A.6.7 Adding more volumes to a volume group after the onboarding operation . . . . . 188
A.6.8 Deleting a volume from one site but not from the other site . . . . . . . . . . . . . . . . 188
A.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Appendix B. Migration planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

B.1 Migration Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
B.2 Application assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
B.3 Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
B.3.1 Compute sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
B.3.2 Storage sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Contents ix
x Power Virtual Server for AIX and Linux
Preface

This IBM® Redbooks® publication describes deployment, networking, and data

management tasks on the IBM Power Virtual Server by using sample scenarios.
The team during the content development used available documentation, IBM Power Virtual
Server environment, and additional software and hardware resources to document several
types of scenarios:
 IBM Power Virtual Server networking and data management deployment scenarios
 Migration scenarios
 Backup scenarios
 Disaster recovery scenarios
This book addresses topics for IT architects, IT specialists, developers, sellers, and anyone
who wants to implement and manage workloads on an IBM Power Virtual Server. Moreover,
this publication provides documentation to transfer how-to skills to the technical teams, and
solution guidance to the sales team. This book compliments the documentation available at
IBM Documentation and aligns with the educational materials that are provided by IBM
Systems Technical Education.

Authors
This book was produced by a team of specialists from around the world working at IBM
Redbooks, Remote Center.

Tim Simon is a Redbooks Project Leader in Tulsa, Oklahoma, USA. He has over 40 years of
experience with IBM primarily in a technical sales role working with customers to help them
create IBM solutions to solve their business problems. He holds a BS degree in Math from
Towson University in Maryland. He has worked with many IBM products and has extensive
experience creating customer solutions using IBM Power, IBM Storage, and IBM System z®
throughout his career.

Andrey Klyachkin is a solution architect at eNFence, an IBM Business Partner who is based
in Germany. He has more than 25 years experience in UNIX systems, designing and
supporting IBM AIX® and Linux systems for different customers worldwide. He is a co-author
of many IBM AIX and IBM Power certification courses, and is an IBM Champion and IBM AIX
Community Advocate. He is also a Red Hat Certified Engineer and Red Hat Certified
Instructor.

Gayathri Gopalakrishnan With over 24 years of extensive experience in technical solution

architecture and IT consulting, she is a results-oriented IT Architect known for leading impact
projects from conception through implementation. She brings exceptional expertise in
managing, designing, developing, and testing innovative solutions that align with critical
business objectives. Gayathri is recognized for her strategic vision and leadership in applying
cutting-edge technical solutions to solve complex challenges across industries. Her deep
understanding of both business and technical landscapes enables her to effectively prioritize
tasks, align teams, and deliver results that exceed expectations. She is adept at transforming
business requirements into robust, scalable technical frameworks that drive measurable
success.

© Copyright IBM Corp. 2025. xi

 Borislav Stoymirski is an IBM Power Servers Hardware Product Engineer at IBM Bulgaria,
specializing in solving complex hardware and software issues on IBM Power Servers,
including IBM AIX, VIOS, HMC, IBM i, PowerVC, PowerVM® NovaLink, PowerVM, Linux on
IBM Power Servers, and Red Hat OpenShift. Since joining IBM in 2015, he has provided
reactive break-fix, proactive, preventative, and cognitive support to several clients worldwide.
Borislav earned a Master's degree in Computer and Software Engineering from the Technical
University of Sofia, Bulgaria, a Master's degree in Transport Machinery and Technologies
from the Technical University of Sofia, Bulgaria, and another Master's degree in Ecology and
Environmental Protection from the University of Chemical Technology and Metallurgy,
Bulgaria. He has authored several publications and has led technical training programs both
inside and outside IBM. His interests lie in Green Blockchain, Artificial Intelligence, Deep
Learning, Machine Learning, Cybersecurity, Internet of Things (IoT), Edge Computing, Cloud
and Quantum Computing.

Jean-Manuel Lenez Pre-sales engineer since 1999 at IBM Switzerland, Jean-Manuel Lenez
specializes in UNIX Power/ AIX/ IBM i server technologies and related products such as
PowerVM, IBM PowerHA®, PowerSC, Linux On Power, IBM Cloud®. Strongly involved in his
pre-sales mission, he leads projects at major clients around various topics: artificial
intelligence, deep learning, SAP HANA, server consolidation, high availability HA/DR.. Driven
and passionate about technology, he is always ready to follow companies in new market
challenges and to invest in the latest technological developments: Hybrid-Cloud, Openshift,
Dev-Ops,

Lokesh Bhatt is a seasoned technology leader with over 20 years of experience in IBM
systems and cloud solutions. He holds a masters degree in Computer Science and
Engineering. In his current role as the Technical Sales Leader for IBM Cloud across India and
South Asia, he has been instrumental in driving cloud adoption and architecting robust
IBM-based solutions for a wide range of clients. Lokesh has served in key roles, including as
a Systems Lab Services Consultant, where he contributed to major global initiatives like
PowerCare across India, the Philippines, and Australia. His technical expertise spans IBM
Power Systems, AIX environments, virtualization, and hybrid cloud integration, making him a
trusted advisor within the IBM ecosystem. Lokesh is also a recognized thought leader,
regularly engaging in technical presentations, client workshops, and industry forums to share
best practices and cutting-edge innovations.

Youssef Largou is the founding director of PowerM, a platinum IBM Business Partner in
Morocco. He has 22 years of experience in systems, HPC, middleware, and hybrid cloud,
including IBM Power, IBM Storage, IBM Spectrum®, IBM WebSphere®, IBM Db2®, IBM
Cognos®, IBM WebSphere Portal, IBM MQ, ESB, IBM Cloud Pak®, SAP HANA and Red Hat
OpenShift. He has worked within numerous industries with many technologies. Youssef is an
IBM Champion 2020, 2021,2022, 2023 and 2024, an IBM Redbooks Platinum Author and has
designed many reference architectures. His company has been recognized as an IBM
Beacon Award Finalist in Storage, Software-Defined Storage, and LinuxONE five times. He is
a regular speaker at IBM Think®, IBM TechXchange and Common Europe Congress. He
holds an engineer degree in Computer Science from the Ecole Nationale Supérieure des
Mines de Rabat and Executive MBA from EMLyon.

Prerna Upmanyu is a Software Performance Expert in the Power Servers performance team
based out in India. She holds an M.Tech degree in Software Systems from BITS Pilani.
Prerna has over 15 years of experience working with customers designing and deploying
solutions on IBM Power server. She focuses on areas such as AIX Performance , Automation
and Data Lakes-based design and deployments. Prerna’s areas of expertise include system
performance, availability, and automation.

Henry Vo IBM Redbooks Project Lead. He joined IBM right after graduate from University of
Texas at Dallas 2012 with MIS (Management Information System) major. Henry shared his

xii Power Virtual Server for AIX and Linux

 technical expertise in business problem solving, risk/root-cause analyze, writing technical
plan for business. Within IBM, he hold multiple roles such as Project management, Project
lead, ST/FT/ETE Test, Back End Developer, DOL agent for NY.

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

Maria Ward
PowerVS Product Manager, Austin, US

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 IBM Redbooks 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:
[email protected]
 Mail your comments to:
IBM Corporation, IBM Redbooks
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400

Stay connected to IBM Redbooks

 Find us on LinkedIn:
https://www.linkedin.com/groups/2130806
 Explore new Redbooks publications, residencies, and workshops with the IBM Redbooks
weekly newsletter:
https://www.redbooks.ibm.com/subscribe
 Stay current on recent Redbooks publications with RSS Feeds:

Preface xiii
 https://www.redbooks.ibm.com/rss.html

xiv Power Virtual Server for AIX and Linux

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-NC119, 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.

© Copyright IBM Corp. 2025. xv

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 https://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.
AIX® IBM FlashSystem® PowerHA®
Aspera® IBM Services® PowerVM®
Db2® IBM Spectrum® Redbooks®
FlashCopy® IBM Z® Redbooks (logo) ®
IBM® POWER® Satellite™
IBM Cloud® Power8® Storwize®
IBM Consulting™ Power9® SystemMirror®

The following terms are trademarks of other companies:

The registered trademark Linux® is used pursuant to a sublicense from the Linux Foundation, the exclusive
licensee of Linus Torvalds, owner of the mark on a worldwide basis.

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

Ansible, OpenShift, Red Hat, are trademarks or registered trademarks of Red Hat, Inc. or its subsidiaries in
the United States and other countries.

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

VMware, and the VMware logo are registered trademarks or trademarks of VMware, Inc. or its subsidiaries in
the United States and/or other jurisdictions.

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

xvi Power Virtual Server for AIX and Linux

Summary of changes

This section describes the technical changes made in this edition of the book and in previous
editions. This edition might also include major corrections for chapter organization and
consistency.

February 2025, Second Edition

This revision includes the following new and changed information.

New information
 Provide information on networking options in Power Virtual Server.
 Added additional information about migrating workloads to Power Virtual Server.
 Added hints and tips for managing workloads on Power Virtual Server.
 Provided additional information about backup options in Power Virtual Server.

Changed information
 Updated support to show Power10 support with Power Virtual Server.
 Updated screenshots to reflect the newest Power Virtual Server on IBM® Cloud version.

© Copyright IBM Corp. 2025. xvii

xviii Power Virtual Server for AIX and Linux
 1

Chapter 1. IBM Power Virtual Server

From the AS/400 and RS/6000 models in the 1990s to the POWER10 processor-base
systems released in late 2021, IBM Power servers are the first choice for many companies
with high-risk environments that need low-risk infrastructure. Most of the Fortune 100
companies have Power servers running their most mission-critical workloads. IBM Power
Virtual Servers continue this tradition.

Until now, moving your Power server workloads to the cloud was an impractical, ideal
solution. The chance to have your IBM i, AIX, or Linux on Power on a public or hybrid Cloud
might have seemed difficult and costly. However, these challenges can now be addressed
with the Power Virtual Server offering.

This chapter introduces and presents the conceptual foundations of the Power Virtual Server
service:
 “IBM Cloud and the IBM Power Virtual Server offering”
 “IBM Power Virtual Server”.
 “Key concepts and features for Power Virtual Server”.
 “Storage”
 “Snapshots, cloning, and restoring”

© Copyright IBM Corp. 2025. 1

1.1 IBM Cloud and the IBM Power Virtual Server offering
IBM Cloud provides solutions that enable higher levels of compliance, security, and
management, with proven architecture patterns and methods for rapid delivery for running
mission-critical workloads. IBM Cloud comprises of 46 datacenters worldwide and is available
across 10 regions with 27 availability zones. Multizone regions are available in North and
South America, Europe, Asia, and Australia. IBM Cloud provides the ability to deploy locally
with global scalability.

Figure 1-1 shows all services offered by IBM Cloud.

Figure 1-1 IBM Cloud's full stack of offerings enables hybrid cloud and AI

IBM Cloud offers the most open and secure public cloud for business with a next-generation
hybrid cloud platform, advanced data and AI capabilities, and deep enterprise expertise
across 20 industries. Some of the key reasons why clients prefer IBM cloud are:
 Open Innovation
Cloud services are delivered with native open application programming interface, major
contribution to cloud-native open-source work (Istio, Knative, Razee and more).
 Security leadership
IBM Cloud provides the highest level of compliance for data encryption (FIPS 140-2
Level4) and is configurable so that even IBM cannot see the data. IBM Cloud provides
edge-to-cloud threat management with security integration from IBM.
 Enterprise grade
Cloud support for IBM Power, (AIX, IBM i and Linux), IBM Z®, SAP and other mission
critical applications. Broadest portfolio of compute instances (including IBM POWER® and
x86), VMware Cloud Service Provider (VCSP) pinnacle partner.

1.2 IBM Power Virtual Server

IBM Power Virtual Server is a cloud-based infrastructure service that allows businesses to
run workloads on IBM Power Systems hardware in the IBM Cloud. It combines the
performance and reliability of IBM's Power architecture with the flexibility and scalability of a
virtualized environment. Since 2019, IBM has offered IBM Power Virtual Server to provide
IBM Power resources in the cloud. The offering has grown to 21 data centers worldwide (with

2 Power Virtual Server for AIX and Linux

additional locations expected) and combines an infrastructure as a service (IAAS) model
which includes IBM Power compute nodes with SAN attached IBM Storage and associated
network connections within IBM Cloud locations. And now, as part of IBM’s distributed
hybrid infrastructure strategy, Power Virtual Server Private Cloud extends all the
benefits of IBM Power Virtual Server into your (or a partner’s) data center. The
enhanced capabilities of IBM Power Virtual Server Private Cloud provide managed
infrastructure as a service at client locations, with metered consumption and no upfront costs
to support Hybrid by Design delivery of services.

Power Virtual Server delivers flexible compute capacity for IBM Power workloads. Integrated
with the IBM Cloud platform for on-demand provisioning, this offering provides a secure and
scalable server virtualization environment that is built upon the advanced Reliability,
Availability, and Scalability (RAS) features and leading performance of the Power platform
and can be deployed either off-premises in IBM Cloud datacenters or on-premises in your
data center or in another data center of your choice.

Figure 1-2 Synergy of IBM POWER Server and IBM Cloud in IBM Power Virtual Server

IBM Power Virtual Server benefits

IBM Power Virtual Server has offered a cloud-based, off-premises solution since 2019,
allowing customers to dynamically provision IBM Power servers and storage with a
pay-as-you-go charging model. This enables clients to quickly migrate existing IBM
Power-based workloads to the cloud.

IBM Power Virtual Server Private Cloud extends this offering, providing enterprises with
secure, integrated data center services at their chosen location, also on a pay-as-you-go
basis. Leveraging the data center expertise gained through IBM Power Virtual Server, the
IBM Power Virtual Server Private Cloud solution delivers performance, scalability, flexibility,
security, and industry-leading reliability. It integrates servers, storage, network, security, and
solution patterns to enable self-service capabilities in the client's data center.

Replicating these cloud capabilities and maintaining this integrated solution would require an
enterprise to invest millions of dollars and months or years of development time.

Chapter 1. IBM Power Virtual Server 3

 Fully metered consumption
IBM Power Virtual Server Private Cloud provides fully metered consumption, allowing you to
pay for the infrastructure as you use it and eliminating capital expense for the infrastructure.
The terms of the offering are:
– 3-year or 5-year term with 1-year renewal
– Pay-as-you-use monthly billing with Committed Monthly Spend (CMS)
– IBM owned and managed

Lowest TCO, fastest Time to Value

Moving IBM Power workloads to the cloud can be challenging and expensive. Prior to the
availability of Power Virtual Server, that migration usually meant an expensive and risky
refactoring of the applications to be able to run them on x86 base hardware.

IBM Power Virtual Server Private Cloud offers the best TCO value for customers wishing to
move to on-premises cloud solutions compared to our competitors as shown in Table 1-1.

Table 1-1 TCO comparison

IBM Power Virtual Server at client AWS Outposts
 Highest security servers  Higher energy costs
 Highest reliability servers  Higher software costs
 High performance processors  Lower performance processors
 Metered usage billing  Delivered capacity billing

Lowest TCO TCO 1.5x higher

AWS Outposts AWS Outposts

 Higher energy costs  Higher energy costs
 Higher software costs  Higher software costs
 Lower performance processors  Lower performance processors
 Delivered capacity billing  Metered usage billing

TCO 1.2x higher TCO 1.2x higher

IBM offers Power Virtual Server Private Cloud with no upfront capital on a pay-as-you-go
consumption model with a monthly minimum fee for a 3-year or 5-year term. The
configuration can be designed as a small or medium Pod depending on the client workloads.

If you are choosing whether to use Power Virtual Server versus choosing to build your own
infrastructure, consider the points illustrated in Figure 1-3 on page 5. Beyond just the up-front
capital expense for the equipment, you need to consider the costs of creating the support
structure for all of the other components involved in the solution, for example storage,
networking, security and monitoring.

Choosing IBM Power Virtual Server – either in IBM data centers or client locations – provides
an excellent option to implement a Power based infrastructure with no up-front investment
and with usage-based costs.

4 Power Virtual Server for AIX and Linux

Figure 1-3 DIY comparison

Power customers who are interested in modernization can benefit from deploying the
workloads to Power Virtual Server instead of moving their applications to a new platform that
can be expensive and high risk. You can access many enterprise services from IBM with
pay-as-you-use billing with which you can quickly scale up and out. IBM Power Virtual Server
enables clients to take full advantage of this trend with the ability to provision AIX®, IBM i, or
Linux instances connected to the cloud.

Power Virtual Servers are collocated with IBM Cloud. Power Virtual Servers have separate
networking hardware and direct-attached storage systems but come with connectivity options
to allow Power Virtual Server instances to integrate with IBM Cloud services. This enables
Power Virtual Server instances to maintain key enterprise software certification and support
as the Power Virtual Server architecture is identical to certified on-premises infrastructure.
The virtual servers, also known as logical partitions (LPAR), run on Power hardware with the
IBM PowerVM® hypervisor.

With the Power Virtual Server, you can quickly create and deploy one or more virtual servers
that are running either IBM AIX, IBM i, or Linux operating systems. After you provision the
Power Virtual Server, you can access infrastructure and physical computing resources
without the need to manage or operate them. However, you must manage the operating
system and the software applications and data. Figure 1-4 represents a responsibility
assignment (RACI) matrix for Power Virtual Server.

Figure 1-4 RACI Matrix Power Virtual Servers

Chapter 1. IBM Power Virtual Server 5

1.2.1 Potential consumers
The potential consumers of the Power Virtual Server service offering are the IT
administrators, managed service providers (MSPs), cloud service providers (CSPs),
independent software vendors (ISVs), and application developers.

IT administrators
IT administrators manage infrastructure technology and are interested in migrating to the
cloud to increase the time-for-value of their Power workloads, shift capital expense to
operating expense, and improve business resilience and scalability. When clients move to a
hybrid cloud model, they can manage a truly hybrid environment with flexible burst
environments for spikes in usage, development and test environments, and production
workloads.

MSPs and CSPs

Service providers are interested in expanding the level of service that they can offer their
clients. Many MSPs have client workloads running on Power, and they can provide additional
services around the cloud.

Independent software vendors (ISVs)

Companies that sell software as a service can take this capability to deploy infrastructure to
host their software on the cloud for client basis.

Application developers
Companies with Power servers have subject matter experts in AIX, IBM i, and Linux
development. They want to continue developing mission-critical applications and then deploy
on-premises.

1.2.2 IBM Power Virtual Server use cases

IBM Power Virtual Server offers robust solutions to meet a variety of business needs, helping
enterprises leverage the cloud for greater agility, scalability, and operational efficiency. Below
are key use cases illustrating how PowerVS can unlock value across multiple dimensions:
 Business Continuity Planning:
Power Virtual Server ensures seamless operations with reliable failover capabilities,
including backup, high availability, and disaster recovery. This approach minimizes capital
investment, reduces complexity in planning, and eliminates excess capacity, helping
businesses maintain uninterrupted service during disruptions.
 Data Center Optimization
Organizations can accelerate time-to-value by re-hosting workloads on PowerVS, which
aligns with on-premises certified architecture stacks. Power Virtual Server maintains ISV
certifications and support, ensuring a smooth migration while expanding global reach.
This approach helps optimize data center operations with minimal disruption.
 Application Modernization
Power Virtual Server enables integration with over 200+ IBM Cloud services, facilitating
cloud-native transformations. Its API-first architecture connects seamlessly with existing
tools, allowing businesses to shift from purchasing peak capacity to on-demand
provisioning, driving flexibility and efficiency.

6 Power Virtual Server for AIX and Linux

  Operational Excellence and Cost Optimization
With Power Virtual Server, enterprises can align IT resources with business objectives
while reducing operational overhead. The platform offers improved response times and
off-hours service coverage, supporting pay-as-you-go billing for cost-effective decisions.
This model ensures that organizations stay lean and agile, making resource allocation
smarter and more responsive.

Power Virtual Server stands at the intersection of performance, reliability, and flexibility,
empowering organizations to adopt hybrid cloud strategies, modernize applications, and
optimize operations with confidence.

1.3 Key concepts and features for Power Virtual Server

For organizations that want to extend their IBM Power workloads to the IBM Cloud, Power
Virtual Server offers a straightforward path to implementing a hybrid cloud. However, before
they commit to the service, organizations should understand how Power Virtual Server works
and what it can provide.

No single solution exists for all organizations that plan to use the cloud. All solutions have cost
and benefits to consider.

In this section, we present some of the key concepts for the Power Virtual Server:

1.3.1 Power Virtual Server workspaces and instances

Before you create a virtual server, you must understand the difference in terminology between
a Power Virtual Server workspace and a Power Virtual Server instance. You can think of the
Power Virtual Server workspace as a container for all Power Virtual Server instances at a
specific geographic region. The Power Virtual Server workspace is available from the
Resource list in the Power Virtual Server user interface. The workspace can contain multiple
Power Virtual Server instances. For example, you can have two Power Virtual Server
workspaces, one in Dallas, Texas, and Washington, DC. Each workspace can contain
multiple Power Virtual Server instances.

You cannot create a workspace across multiple geographic regions. If you need instances in
two different geographic regions, then create two workspaces. You can have multiple
workspaces in the same geographic region. For example, you can have a workspace for
development and test environments and a workspace for the production environment.

Note: For a complete list of supported data centers, see Creating a Power Systems Virtual
Server workspace.

1.3.2 Compute
The following IBM Power servers can host Power Virtual Server instances:

Power9 based
 IBM Power System S922 (9009-22A)
 IBM Power System E980 (9080-M9S)

Chapter 1. IBM Power Virtual Server 7

 Power10 based
 IBM Power System S1022 (9105-22A) (Power10)
 IBM Power System E1080 (9080-HEX)
 IBM Power System E1050 (9043-MRX)

Processors can be defined as dedicated, shared uncapped, or shared capped. For more
information about processor types, see What's the difference between capped and uncapped
shared processor performance? How do they compare to dedicated processor performance?

If the machine type is S922 or S1022 and the operating system is IBM i, IBM i supports a
maximum of 4 cores per VM.

1.3.3 Server placement groups

Server placement groups provide you control over the host or server on which a new virtual
machine (VM) is placed. By using server placement groups, you can build high availability
within a data center.

You can apply an affinity or anti-affinity policy to each VM instance within a server
placement group:
affinity policy All VMs in that placement group are started on the same server.
anti-affinity policy All VMs in that placement group are started on different servers.

Note: You can add or remove VMs within the placement group. But cannot change the
policy or name of a placement group after it is created.

Server placement group can use the following APIs for managing server placement groups:
 Get all server placement groups: Displays all existing server placement groups.
 Get server placement group details: Displays details about a specific server placement
group.
 Delete server placement group: Deletes server placement groups even if they contain
member instances.
 Remove server from placement group: Removes a virtual server instance from a server
placement group.

1.3.4 VM pinning
The options to pin a VM to the host where it is running are none (default), soft or hard:
 If the pin is not set or set to none, then the VM is automatically migrated or remote
restarted during maintenance windows or a host failure.
 When you soft pin a VM, Power Virtual Server automatically migrates the VM back to the
original host after the host is back to its operating state.
 If the VM has a licensing restriction for the host, then the hard pin option restricts any VM
movement during maintenance windows or a host failure. Hard pin VMs are stopped if the
frame is down.

8 Power Virtual Server for AIX and Linux

1.3.5 Shared processor pool
A shared processor pool (SPP) is a pool of processor capacity that is shared between a group
of virtual server instances. Unlike a virtual server instance that has a dedicated and defined
maximum amount of processing capacity, you can set the number of reserved cores in SPPs
that are available at the pool level.

Add to a pool placement group

Select the checkbox if you want to deploy the SPP directly into an existing pool placement
group.

Note: If the pool has the required affinity relation with other pools, the best practice is to
deploy the pool directly into the placement group. You must create the pool placement
group first. It prevents the pool from being deployed on a host that does not satisfy the
affinity requirements and having to move it later.

Some benefits of using an SPP

Some of the benefits of using a shared processor pool are:
 An SPP Provides control over licensing costs by limiting the number of processors an
uncapped partition can use, which reduces the number of software licenses.
 An SPP provides a better overall ability to reserve and manage processor resources.

SPP and Power Virtual Server

The Power Virtual Server always has at least one defined SPP as the default pool. You can
add up to 63 more SPPs to a single Power Virtual Server workspace. The SPP is used and
shared by a set of virtual server instances of the same machine type (host).

You can specify the host affinity and anti-affinity between two or more SPPs with shared
processor pool placement groups. For more information, see Configuring shared processor
pool placement group.

1.3.6 Storage
IBM Power Virtual Servers use Storage Area Network (SAN) attached NVMe-based flash
systems. The storage systems are IBM Storage FlashSystem controller using IBM flash
technology. and are attached via 16 Gb or 32 Gb SAN infrastructure. The storage
configuration is designed on the best practices for highly available storage.

Availability configuration
To provide the highest level of availability, each Power Virtual Server instance is configured
with four Virtual Fibre Channel adapters: two are mapped to Virtual Fibre Channel adapters
on one VIOS, and the other two are mapped to Virtual Fibre Channel on the other VIOS.

Chapter 1. IBM Power Virtual Server 9

 Figure 1-5 shows an example with two instances (VMs) with dual Virtual I/O Server.

Figure 1-5 Storage definition on Power Virtual Servers

Storage Tiers
IBM Power Virtual Server offers you the option to select an I/O operation per second (IOPS)
based storage based on your requirement. Flexible IOPS is a tier-less storage offering that
removes the notion of disk type and replace it with a storage pool. Each of the storage pools
supports multiple storage tiers. The storage tiers are based on different IOPS levels.

Storage tiers are designed to provide distinct levels of storage pricing. The client is charged
more for higher performance and less for lower performance or inactive data. Storage tier
pricing is based on I/O operations per second (IOPS).

Tier0, Tier1, and Tier3 performance is based on IOPS per GB, meaning that the performance
of your storage volumes is connected to the size of the volume. This works well for many
workloads, but there are some workloads that have a smaller amount of data and are
hampered by the IOPS/GB calculation. For these workloads, PowerVS provides the Fixed
IOPS tier which provides 5000 IOPS per data volume, regardless of the size.

Note: The Fixed IOPS tier is only available for volumes with a size of 200 GB or less.
Above 200 GB using Tier0 provides higher performance (200 GB @ 25 IOPS/GB = 5000
IOPS).

10 Power Virtual Server for AIX and Linux

Table 1-2 shows the supported storage tiers with corresponding IOPS.

Table 1-2 Storage tiers within PowerVS

Tier level IOPS Performance

A 100-GB volume receives 2500 IOPS.

Tier 0 25 IOPS/GB This is 2.5x faster than tier 1 and 8.3x faster than tier
3.

A 100-GB volume receives 1000 IOPS. This is 3.3x

Tier 1 10 IOPS/GB
faster than tier 3.

Tier 3 3 IOPS/GB A 100-GB volume receives 300 IOPS.

5000 IOPS regardless of

Fixed IOPSa A 100-GB volume receives 5000 IOPS.
size
a. The use of fixed IOPS is limited to volumes with a size of 200 GB or less, which is the break even size with
Tier 0 (200 GB @ 25 IOPS/GB = 5000 IOPS).

For each Power Virtual Server Instance, you must select a storage tier for the boot volume.
The performance of a storage volume is limited to the maximum number of IOPS based on
volume size and storage tier as shown in Table 1-2. For example, a 100 GB Tier 3 volume can
process up to 300 IOPs, and a 100 GB Tier 1 volume can process up to 1000 IOPS. After the
IOPS limit is reached for the storage volume, the I/O latency increases.

Flexible IOPs offers you multiple tiers of storage to choose from, each with its own pricing,
performance, and capabilities. With flexible IOPs, you can:
 Create a volume (or multiple volumes) and specify the desired IOPS level.
 Change the IOPS level of existing volumes within the same storage pool.
 Clone one or more volumes to your preferred IOPs level. Note that if any of the volumes is
greater than 200GB, the target tier cannot be Fixed IOPs.
 Deploy the boot volume of a virtual server instance in any of the supported IOPs levels.
Additional data volumes attached to the new virtual server instance can have different
IOPS levels from that of the boot volume.
 Import an image from IBM Cloud Object Storage to any supported IOPs level.

Storage pools

Note: Tier 3 storage tier is not suitable for production workloads. When you are choosing a
storage tier, ensure that you consider not just the average I/O load, but, more importantly,
the peak IOPS of your storage workload.

You can now attach storage volumes to a VM instance from storage tiers and pools that are
different than the storage pool used by the VM instance's boot volume. To do this, you must
modify the VM instance and set the storagePoolAffinity property to false. The VM instance
storagePoolAffinity property is set to true by default.

Storage pools include the following options:

 Affinity
Use this option to select an existing VM instance or an existing volume as the affinity
object. The new volume is created in the same storage pool where the affinity object
exists. If you are using a VM instance as an affinity object, the storage pool that is selected
is based on the VM instance's root (boot) volume.

Chapter 1. IBM Power Virtual Server 11

  Anti-affinity
Use this option to specify one or more existing VM instances or one or more volumes as the
anti-affinity objects. The new volume is created in a different storage pool than the storage pool
where one or more anti-affinity objects exist.
 Auto-select pool
Use this option to allow the system to automatically select a storage pool that has sufficient
capacity for the specified storage tier.

Note: For Snapshots, cloning and restoring all volumes must be from the same storage
pool. If anti-affinity is enabled, the cloning and restoring will not work.

The use of volume affinity policy (affinity or anti-affinity) requires the availability of multiple storage
pools. You might experience the following errors when you use a volume affinity policy:
 If an additional storage provider is not available to fulfill the requested policy, you might receive
an error that indicates the inability to locate a storage provider to create a volume by using the
requested volume affinity policy.
 If additional storage providers exist but the storage providers do not have sufficient space to
fulfill the requested policy, you might receive an error that indicates the inability to locate a
storage provider with enough available capacity to satisfy the requested volume size.

Snapshots, cloning, and restoring

The Power Virtual Server provides the capability to capture full, point-in-time copies of entire
logical volumes or data sets. Using IBM FlashCopy® feature, you can use the Power Virtual Server
API to create delta snapshots, create volume clones, and restore your disks.

Taking a snapshot
By using the snapshot interface, you can create a relationship between your source disks and
target disks at time T1. Target disks are created as part of the snapshot API. The snapshot API
tracks the delta changes done to the source disk beyond time T1. This enables the user to restore
the source disks to their T1 state at a later point in time.

Several use cases exist for the snapshot feature. For example, an administrator plans to upgrade
the middleware on their system but wants to be able to revert to its original state before they
proceed with an upgrade. If the middleware fails, the administrator can restore the source disk to
its earlier state.

When you take a snapshot, consider the following best practices:

 Before you take a snapshot, ensure that all of the data is flushed to the disk. If you take a
snapshot on a running virtual machine (VM) and did not flush the file system, you might
lose some content that is still only held in memory.
 It is recommended that you quiesce all the applications on the snapshot volume.

When you take a snapshot, consider the following restrictions and considerations:
 Parallel VM snapshot operations from different VM nodes for the same shared volume are
not allowed.
 You cannot restore a VM if you are taking a snapshot while clone (full-copy) FlashCopy
operations are running in the background. The FlashCopy operations must first complete.
 Some of the attributes of source disks cannot be changed while the disks are in a
snapshot relationship. For example, you cannot resize the source disks when snapshot
relationships are defined for those disks.
 Volumes that are in a snapshot relationship cannot be detached from the VM.

12 Power Virtual Server for AIX and Linux

 Cloning a volume
The clone operation creates a full copy of the volume. You can select multiple volumes and
initiate a group clone operation. When multiple volumes are selected, the clone operation
ensures that a consistent data copy is created.

The clone operation continues to copy data from the source disks to target disks in the
background. The amount of time to complete the clone operation depends on the size of the
source disks and the amount of data to be copied.

When the clone operation is performed on a volume that is in use, the Power Virtual Server
creates a consistent group snapshot and re-creates the copy of the cloned volume by using
the group snapshot.

It is a best practice to quiesce all the applications on the volume that you want to clone.

Note: You cannot modify the source or target disk attributes, such as disk size, while the
clone operation is in progress.

Restoring a snapshot
The restore operation restores all of the volumes that are part of a VM snapshot back to the
source disks. While it restores the VM, the Power Virtual Server creates a backup snapshot,
which can be used if the restore operation fails. If the restore operation succeeds, the backup
snapshots are deleted. If the restore operation fails, you can use the restore_fail_action
query parameter with a value of retry to retry the restore operation. To roll back a previous
disk state, you can pass in the restore_fail_action query parameter with a value of
rollback. When the restore operation fails, the VM enters an error state.

Best practices during a restore

During the restore operation, it is critical that your source disks be quiesced. Your source
disks cannot be in use. Shut down all of your applications, including file systems and volume
managers. If you are running an AIX VM, ensure that the disks are freed from the LVM by
varying it off.

If you plan to restore the boot disks, your VM must be shut down. If the VM has volumes that
are hosting external database applications, quiesce all of your applications and ensure that
there are no active I/O transactions on the disk. Failure to do so can lead to data corruption
and put the VM in maintenance mode.

Restrictions and considerations

If the restore operation fails, contact your storage support administrator. A failed restore
operation can leave behind incomplete states, which might require cleanup by an
IBM operations team.

If you choose to restore a shared volume on one VM, you cannot perform the snapshot,
restore, clone, or capture operations on the other VMs that are using the shared volume while
the restore operation is running.

1.3.7 Power Virtual Servers networking

IBM Power Virtual Server provides a variety of network scenarios that address diverse needs,
from low-cost, flexible POC setups to robust, high-performance production environments. By
selecting the right scenario, organizations can optimize their network architectures, achieve
secure and reliable connectivity, and support business requirements, whether it's for a single

Chapter 1. IBM Power Virtual Server 13

 cloud, hybrid, or multi-cloud deployment. These scenarios are foundational for organizations
seeking the scalability and flexibility of the cloud while maintaining control, security, and
performance for their critical workloads.

IBM Power Virtual Servers have separate networking hardware:

 Cisco Nexus9000 N9K-C9364C (Spine 10 G)
 Cisco Nexus9000 9348GC-FXP (Leaf 1 G)
 Cisco Nexus9000 93180YC-FX (Leaf 25 G)
 Cisco UCS - APIC controller
 Cisco ASR1001-HX Routers
 Avocent ACS8032DAC-400

For more detail on types of networks please check out Chapter 3, “IBM Power Virtual Server
in the IBM Cloud network” on page 71.

1.3.8 Operating system images

Power Virtual Server provides AIX, IBM i, and Linux operating system images, or you can
provide your own customized operating system (OS) image in OVA format.

The versions of AIX, IBM i, and Linux operating systems that are supported by Power Virtual
Server are described in the following list:
 AIX 7.1, or later.
 IBM i 7.1, or later. Clients running IBM i 6.1 must first upgrade the OS to a supported level
before migrating to the Power Virtual Server.
 Power Virtual Server supports the following ppc64le Linux distributions:
– SUSE Linux Enterprise 12 and 15
– Red Hat Enterprise Linux 8.1, 8.2, 8.3, 8.4, and 8.6

Note: If you use an unsupported version, you might experience outages during planned
maintenance windows with no advanced notification given.

Provided operating system images

The provided version levels of the operating system image files are subject to change:
 Power Virtual Server typically provides image files for the last three major versions of a
supported OS. Any update to the OS image is planned only when the operating system
level is certified for IBM PowerVM environment.
 Any unsupported and older images are periodically removed from the offering. You will be
notified three weeks before the images are removed.
 VMs deployed by using IBM provided image files that are being removed can continue to
operate without any issues. It is recommended to follow operating system vendor’s
guidelines to update the OS as needed.

A full Linux subscription provides Red Hat Enterprise Linux and SUSE Linux Enterprise
Server image files that can be used for SAP and non-SAP applications. Power Virtual Server
instances do not have direct access to the IBM Cloud® Satellite™ server and require a proxy
server. See Full Linux subscription for Power Systems Virtual Servers for more details.

14 Power Virtual Server for AIX and Linux

 Bring your own image
You can bring your own customized IBM AIX, IBM i, or Linux operating system (OS) image to
deploy within a Power Virtual Server.

Before you use a custom image as the boot volume, review the following information:
 Understand the basic concepts of IBM Cloud Object Storage. For more information, see
Getting started with IBM Cloud Object Storage.
 If you do not have an existing image, you can use IBM Power Virtualization Center
(PowerVC) to capture and export an image for use with a Power Virtual Server. For more
information, see Capturing a virtual machine and Exporting images.
To capture and export an image by using PowerVC, the PowerVC private environment
must contain N_Port ID Virtualization (NPIV) data volumes. Power Virtual Server does not
support captured images from environment with shared storage pools vSCSI data
volumes.
 Alternatively, if you already deployed a virtual server instance, you can capture it and
redeploy a new virtual server instance.

For more information about migrating your workloads to Power Virtual Server, see Importing
images and Deploying a custom image within a Power Systems Virtual Server.

1.3.9 High availability and disaster recovery options

Typically, organizations review their IT services in terms of a recovery time objective (RTO) a
recovery point objective (RPO). RTO is the time until the service resumes. RPO is the
acceptable amount of lost data, which is measured as a period of time. Figure 1-6 illustrates
the concepts related to disaster recovery including Recovery Point Objective (RPO) and
Recovery Time Objective (RTO).

Figure 1-6 RPO and RTO Diagram

Chapter 1. IBM Power Virtual Server 15

 RTO is the amount of time an application can be down without causing substantial business
damage and the time it takes for the system to recover from a loss.

RPO is the specified amount of time allowed since the last save of the data before a failure
occurs.

Both high availability (HA) and disaster recovery (DR) are essential for business continuity.
HA addresses local (single cloud region) outages that are planned and unplanned that have
the following characteristics:
 Planned outage management, software, and hardware.
 Unplanned outage management, hardware failure for example.
 Can provide an RPO of zero.

DR addresses the loss of sites:

 Catastrophic events that cause the cloud region to become unavailable.
 Advanced configurations that involve continuous data replication that provides a zero or
near-zero RPO.
 Less advanced options that involve saving point in time copies to provide an RPO equal to
the time since the last save operation.

When you design architecture for a cloud service, consider your availability requirements and
how to respond to potential interruptions in the service. To be successful, you cannot assume
that the Power Virtual Server instance is always there or is always working the way that you
expect.

The Power Virtual Server provides multiple solutions to support business continuity plans as
shown in Figure 1-7.

Figure 1-7 Power Virtual Server HA and DR business continuity plan

16 Power Virtual Server for AIX and Linux

Power Virtual Server remote restart
The Power Virtual Server restarts the VMs on a different host system if a hardware failure
occurs. This process provides basic HA capabilities if there is a Power servers failure.

Consider the following restrictions and considerations for remote start:

 When the hard pin option is sent, VMs cannot be started on a different host.
 The remote restart does not protect your VMs if there is storage hardware failure.

HA clusters
HA clusters are groups of two or more computers and resources, such as disks and networks
that are connected and configured, so if one fails, an HA manager, such as IBM PowerHA® or
Pacemaker, performs a failover. The failover transfers the state data of applications from the
failing computer to another computer in the cluster and restarts the applications there. This
process provides high availability of services running within the HA cluster.

Consider the following restrictions and considerations for HA clusters:

 You can use a monthly subscription model when you purchase PowerHA IBM
SystemMirror® for AIX Standard Edition. For more information, see IBM PowerHA
SystemMIrror Standard Edition V7 offers new monthly pricing options.
 By using the Power Virtual Server, you do not have access to the HMC, VIOS, and the
host system. Therefore, any PowerHA functions that require access to these capabilities,
such as Resource Optimized High Availability (ROHA) and Active Node Halt Policy
(ANHP), are not available.
 It is a best practice to use server placement groups with anti-affinity policy to make sure
the VMs can run on different systems.
 It is a best practice to use the storage pool anti-affinity policy to make sure that you have
disks from different controllers, and if possible, to create mirror VGs.

Global Replication Service

Disasters are unplanned events that can cause severe damage, incur a loss to a business,
and affect all organizations. Because most workloads run on a cloud infrastructure, it is
essential to have robust and resilient cloud infrastructure that is prepared to handle these
catastrophic hits and have minimal impact on business.

The IBM Power Virtual Server provides a set of APIs that can enable a disaster recovery (DR)
solution for your virtual server instances. IBM Cloud infrastructure internally uses Global
Mirror Change Volume (GMCV) as storage technology that provides asynchronous replication
and advance network configuration for fast data transfer.

Global Replication Service (GRS) service is used to create and manage replicated resources
that include the following items:
 Volume lifecycle operations support on replicated volumes.
 APIs to manage volume groups through create, update, delete, start, and stop operations.
 Virtual server instance lifecycle operations by using replicated volumes.
 Onboard auxiliary volume on secondary site for volume recovery.

Note: You can use the GRS location APIs to determine the locations that support storage
replication and their mapped location. For more information, see Region and data center
locations for resource deployment.

Chapter 1. IBM Power Virtual Server 17

 The following list describes some best practices and information for GRS:
 Set the bootable flag explicitly on onboarded volumes, if required.
 Start the onboarding of auxiliary volumes only when the master volumes and volume
group are in consistent copying state.
 When you add or remove a master or auxiliary volume from a volume group at one site,
perform the same operation from the other site to keep the data in sync.
 If you delete a secondary volume but not the primary volume, then you are still charged for
a replicated volume until you delete the primary volume.
 Use primary sites for all the volume operations and perform operations on the auxiliary
volume on the secondary site only during failover.

There are some limitations of GRS:

 You cannot perform a snapshot restore operation in auxiliary volumes.
 The volume-group update operation can fail upon a mismatch in volume-group and
volume replication states. If the volume group is in an error state, you can use the
volume-group action API to reset the volume group status for availability.
 When you delete a volume from a site, the replicated volume that is managed on its
corresponding remote site moves to error state in an interval of 24 hours.
 When the volume is resized from a site, the replicated-enabled volume on its
corresponding remote site is also resized after an interval of 24 hours.
 When you perform any operation on a volume that is deleted, it fails.

Business Continuity through backup and restore

Your Power Virtual Server configuration and data are not backed up automatically. It is the
responsibility of the customer to backup their own data.

Backup strategies for Power Virtual Server that might apply to your configuration:
 Image capture produces a storage IBM FlashCopy of the VM and works for any Operating
System (OS). You can use image capture to store VM images within your account (locally)
as a part of your image catalog, or directly to IBM Cloud Object Storage, or both.
 IBM Spectrum® Protect provides scalable data protection for physical file servers,
applications, and virtual environments.
 A common IBM i backup strategy is to use IBM Backup, Recovery, and Media Services
(BRMS) with Cloud Storage Solutions for i. Together, these products automatically back up
your LPARs to IBM Cloud Object Storage.
 FalconStor Virtual Tape Library (VTL) is an optimized backup and deduplication solution. It
provides tape library emulation, high-speed backup or restore, data archival to supported
S3 clouds for long-term storage, global data deduplication, enterprise-wide replication,
and long-term cloud-based container archive, without requiring changes to the existing
environment.
 Power Virtual Server provides the capability to capture full, point-in-time snapshots of
entire logical volumes or data sets.

18 Power Virtual Server for AIX and Linux

 Note: Importing and exporting images requires a considerable amount of processing
power and network bandwidth. As a result, you can submit only one import or export
request before it is queued. Typically, users import or export system disks, such as rootvg
disks that are smaller in size (less than 1 TB) to simplify the transfer to and from Cloud
Object Storage. If your image size is greater than 1 TB, your transfer might take a long
time and is prone to failure. The largest image size that you can import, or export is 10 TB.

For more information about creating and configuring a Power Virtual Server running the
FalconStor VTL software in the IBM Cloud, see FalconStor StorSafe VTL for IBM Deployment
Guide.

For best practices and guidelines on AIX backup performance on IBM Power Virtual Server,
see AIX Backup Performance Best Practices and Guidelines on IBM Power Systems Virtual
Server.

For a complete tutorial on backing up and restoring IBM i VM data, see IBM i Backups with
IBM Power Virtual Server.

Chapter 1. IBM Power Virtual Server 19

20 Power Virtual Server for AIX and Linux
 2

Chapter 2. Deployment options

IBM Power Virtual Servers offers multiple deployment options, from basic to advanced. These
deployment options are provided to meet any specific business need for creating and
updating the Power Virtual Server instances. ranging from directly creating a single instance
with a graphical interface to fully automated scripts using Ansible and Terraform to create
complex solutions to meet your business needs for managing your Power Virtual Server
instances.

The following topics are covered in this chapter:

 “Creating a Power Virtual Server instance”
 “Preparing for AIX and Linux Deployments”
 “Deployment Option”
 “Deployment with IBM Power Virtual Server web user interface”
 “Deployment with IBM Cloud CLI”
 “Deployment with Terraform”
 “Deployment with Ansible”
 “Deployment with IBM Power Virtual Server API”

© Copyright IBM Corp. 2025. 21

2.1 Creating a Power Virtual Server instance
This section walks you through the process of creating a Power Virtual Server instance. Later
in the chapter, we discuss many of the options and tools that can help you automate the
process. Before you can create your Power Virtual Server instance, you need to understand
the IBM Cloud interface and components.

2.1.1 Power Virtual Server workspace and instance

Before creating a virtual server, make sure you understand the difference between a Power
Virtual Workspace and a Power Virtual Server instance.

A Power Virtual Server workspace is a container for all Power Virtual Server instances within
a specific geographic region. Accessible from the Resource list in the Power Virtual Server
interface, a workspace can host multiple instances. For example, you might have separate
workspaces in Dallas, Texas, and Washington, D.C., each capable of containing multiple
Power Virtual Server instances.

Note: In the context of this document, a co-location facility or service, often referred to as a
COLO, is an off-premises data center that provides computing services, such as Power
Virtual Servers.

2.1.2 IBM Cloud Account

The first step in creating your Power Virtual Server instance is to ensure that you have an IBM
Cloud account as an IBM Cloud account is required. If you do not have an account, see
Create an IBM Cloud account to register an account.

If you already have an account, you can access that account at https://cloud.ibm.com/login.

2.1.3 IBM Cloud Dashboardc

When you login to your IBM Cloud account you are presented the IBM Cloud dashboard
which provides links to different offerings and capabilities available in IBM Cloud. Using these
links you can setup and manage different cloud resources within the IBM Cloud, including
Power Virtual Server instances and their associated resources.

Dashboards are customizable. You can create a dashboard that displays information that is
relevant to you. For example, the dashboards you create can be scoped to specific resources.
Also, you can share the dashboards with users in your account, so you can group resources
for projects or teams.

You can securely authenticate users, control access to Power Virtual Server resources with
resource groups and use access groups to allow access to specific resources for a set of
users. This service is based on an Identity and Access Management (IAM) mechanism, which
provides all user and resource management in the IBM Cloud. You can assign IAM
authorizations based on the following criteria:
 Individual users
 Access groups
 Specific types of resources
 Resource groups

22 Power Virtual Server for AIX and Linux

 For more information about IAM, see Identity and access management (IAM) services.

Figure 2-1 shows the IBM Cloud dashboard.

Figure 2-1 IBM Cloud Dashboard

2.1.4 IBM Cloud catalog

From the IBM Cloud dashboard, select Catalog to open the IBM Cloud catalog, which is an
inventory of all offerings that are provided by IBM Cloud.

The catalog is a list of various products, including computing, storage, networking, solutions
for application development, testing and deployment, security management services,
traditional and open-source databases, and cloud-native services. The offerings are a mix of
services, software, and consulting offerings:
Services A portfolio of managed services for infrastructure, developer tools, and
more to build your applications on the public cloud.
Software List of software solutions that take advantage of a simplified
installation process.
Consulting Consulting offering are provided to assist you with implementing IBM
Cloud services – including technical services, strategic planning, and
more – from IBM and a network of strategic IBM partners.

Chapter 2. Deployment options 23

 Figure 2-2 shows the IBM Cloud Catalog.

Figure 2-2 IBM Cloud catalog

You can search the catalog as shown in Figure 2-3.

Figure 2-3 IBM Cloud catalog search

2.1.5 Creating your Power Virtual Server Workspace

The first step in creating a Power Virtual Server instance is to create a Power Virtual Server
Workspace. A workspace is a logical container that is created to organize resources in the
Power Virtual Server offering and is a prerequisite for creating any Power Virtual Server
resources.

A workspace holds one or more Power Virtual Server instances which are all located in a
single Power Virtual Server location. As all resources in a workspace are from a single
location, you will need a workspace defined in every location where you have a Power Virtual
Server instance.

You can have more than one workspace in a single location. This allows you to group your
resources in that location. For example, you can create a workspace for different departments

24 Power Virtual Server for AIX and Linux

in your company that are using Power Virtual Server resources, or even to separate
production instance from development and test instances.

Regions & Data Centers

IBM Cloud has a resilient global network of locations to host your highly available cloud
workloads. Resources in different locations can be consolidated into an account-based billing
and usage view.

You should deploy your workloads to the location that is nearest to your customers to achieve
low latency connectivity. IBM Cloud provides multi-zone regions (MZR), single-campus
multi-zone regions (SC-MZR), and classic data centers for classic infrastructure resources.

IBM Power Virtual Server boasts a significant global presence, operating in 21 data centers
worldwide as of the writing of this book. This is shown in Figure 2-4. With over 650 clients
already utilizing the service, IBM solidifies its position as the leading provider of IBM Power
infrastructure in the cloud, surpassing other vendors in both the number and geographic
reach of its cloud locations.

Figure 2-4 Region support Power Virtual Server

Workspace for Power Virtual Server service

To create your workspace for Power Virtual Serer search from the dashboard for Power
Virtual Server as shown in Figure 2-5.

Figure 2-5 Search for Power Virtual Server

Chapter 2. Deployment options 25

 After you select Workspace for Power Systems Virtual Server, a new window opens as
shown in Figure 2-6.

Figure 2-6 Create workspace view

Select Create a workspace, where you can specify a name for your service and choose the
location where you want to deploy your Power Virtual Server instances.

Figure 2-7 shows the next screen where you set the location for this workspace.

Figure 2-7 Define Power Virtual Server workspace

26 Power Virtual Server for AIX and Linux

 Decide whether you will be creating a workspace within an IBM data center or in a
client-owned Power Virtual Server Private Cloud environment. Subsequently, select the
desired location from the provided list.

Clicking continue allows you to fill in more details about your workspace such as the
workspace name and any resource groups associated with the workspace. Clicking Continue
on that panel allows you to define any integrations such as monitoring for your workspace.

The next step is to agree to the terms and conditions shown on the right panel and then click
Create. After you click Create, the Resource List page is displayed, which contains a list of
your account resources. Use this page to view and manage your platform and infrastructure
resources in your IBM Cloud.

Another way to access the Resource List page is to click the Navigation menu in the
upper-left, and then click Resource List in the Dashboard menu. You can search for
resources from anywhere in the IBM Cloud by entering the resource or tag in the search field
from the menu bar.

Figure 2-8 shows the result of a Power Virtual Server that was created. All Power Virtual
Servers are under Services and software resources. Each resource is displayed in its row,
and an Actions icon is included at the end of the row. Click the Actions icon to start, stop,
rename, or delete a resource.

Figure 2-8 Search for resources in the IBM Cloud

2.1.6 Power Virtual Server instance

You can work with your resources in various ways from your resource list. To directly manage
the Power Virtual Server service, click the resource's name to go to the resource details page
as shown in Figure 2-9 on page 28.

Chapter 2. Deployment options 27

 Figure 2-9 Virtual server instances section

Click the Create instance button to create a Power Virtual Server instance (VSI), for example
an LPAR or VM, then complete the required fields under the Virtual servers instances section
as shown in Figure 2-10.

Figure 2-10 Virtual servers instances section and summary cost

The total due per month is dynamically updated in the Summary panel based on your
selections. This assists you in creating a cost-effective Power Virtual Server instance that
satisfies your business needs.

28 Power Virtual Server for AIX and Linux

2.1.7 Fields in the Virtual Servers Instances page
After you specify the instance, enter the required data in the remaining fields.

Number of instances
Specify the number of instances that you want to create for the Power Virtual Server. If you
specify more than one instance, more options are available, such as hosting all instances on
the same server or not and VM pinning. You can choose to soft pin or hard pin a VM to the
host where it is running. When you soft pin a VM for high availability, Power Virtual Server
automatically migrates the VM back to the original host after the returns to its operating state.
The hard pin option restricts the movement of the VM during remote restart, automated
remote restart, Dynamic Resource Optimizer, and live partition migration.

SSH key
Choose an existing SSH key or create one to connect to your Power Virtual Server securely.

Machine type
Specify the machine type. The machine type that you select determines the number of
maximum cores and maximum memory that is available.

Cores
There is a core-to-vCPU ratio of 1:1. For shared processors, fractions of cores round up to the
nearest whole number. For example, 1.25 cores equal 2 vCPUs.

Memory
Select the amount of memory for the Power Virtual Server.

Boot image
When you click Boot image, you select boot images from a group of stock images or the list
of images in your catalog.

Attached volumes
You can either create a new data volume or attach an existing one that you defined in your
account.

Network interfaces
At least one private or public network is required. Network interfaces are created by adding a
public network, private network, or both. When you add an existing private network, you can
choose a specific IP address or have one automatically assigned.

2.1.8 Virtual Server instance status

After you click Create an instance, some messages are displayed about your instance,
network, and disk space creation. Then, the main VSI page is displayed as shown in
Figure 2-11. Note the status sequence: Build, Warning, and then Active.

Figure 2-11 VSI status

Chapter 2. Deployment options 29

 Now that you have your VSI running, you see an Actions icon included at the end of the row.
When you click the icon, a pull-down menu is displayed from which you can select to
Immediately shutdown, Restart, Open console, or Delete your instance as shown in
Figure 2-12. If you click the open console, you get a new window with the login prompt for
your system.

Figure 2-12 Open VSI console

The following chapters in this publication expand and show more details about managing the
Virtual Server instances and the associated resources.

2.2 Preparing for AIX and Linux Deployments

When planning to deploy AIX and Linux workloads on IBM Power Virtual Server, there are
essential considerations to ensure smooth setup, optimal performance, and alignment with
business needs. This preparation phase involves evaluating the specific requirements of your
workloads, understanding the available configurations, and choosing supported versions to
ensure compatibility and stability. A well-prepared deployment strategy helps organizations
leverage the full capabilities of IBM Power Virtual Server for enterprise workloads.

2.2.1 Planning to deploy AIX or Linux virtual servers

Effective planning for a Power Virtual Server deployment is similar to what you would do when
planning to deploy a new virtual machine in your on-premises infrastructure.

Workload Assessment
The following should be considered in your workload assessment:
 Performance Requirements
Analyze the CPU, memory, and storage demands of the applications that will run on AIX or
Linux. Identify any workloads that are compute-intensive, memory-bound, or I/O-heavy to
allocate resources accordingly.

30 Power Virtual Server for AIX and Linux

 Application Compatibility
Confirm that applications intended for deployment are fully compatible with the chosen
version of AIX or Linux. For legacy applications, it may be necessary to select specific OS
versions or configurations to ensure optimal functionality.

Network and Connectivity Planning

Ensure that you have considered the following:
 Network Configuration
Define network requirements such as IP ranges, VLANs, and subnet configurations that
support your architecture. Ensure that these configurations are aligned with both
on-premises and cloud networking standards, especially if setting up a hybrid
environment.
 Connectivity Requirements
Plan for secure connectivity between on-premises infrastructure and IBM Cloud if needed.
Options like Direct Link or VPN connections should be considered for stable, secure
communication between environments, especially for production workloads.

Resource Allocation and Scalability

Ensure the following:
 Initial Resource Planning
Decide on the initial allocation of vCPUs, memory, and storage based on workload
requirements. IBM Power Virtual Server allows for dynamic scaling, so understanding how
resource demands may fluctuate helps in planning for scalability.
 Auto-Scaling and Elasticity
Assess if the workloads require auto-scaling features for handling variable demand. IBM
Power Virtual Server supports scalable configurations, making it possible to increase or
decrease resources based on workload activity.

Security and Compliance

Plan for the following security and compliance requirements:
 Data Protection
Define security policies for data protection, including encryption requirements for data in
transit and at rest. IBM Power Virtual Server offers encryption and other security features
that can be enabled based on workload sensitivity.
 Compliance Requirements
Ensure that your AIX and Linux deployments comply with industry regulations such as
HIPAA, GDPR, or PCI DSS, especially if handling sensitive data. IBM Cloud offers
compliance certifications and tools to help meet regulatory standards.

Backup and Disaster Recovery

Consider your backup and disaster recovery requirements:
 Backup Strategy
Determine backup frequency, retention policies, and the required storage capacity for
backups. IBM Power Virtual Server integrates with backup solutions to provide data
resiliency and quick recovery.

Chapter 2. Deployment options 31

  Disaster Recovery Planning
For critical workloads, set up disaster recovery strategies that ensure business continuity
in case of failure. This might include multi-region setups or replication to other IBM Cloud
regions.

Licensing and Cost Management

Understand the following:
 OS and Application Licensing
Review licensing requirements for AIX, Linux, and any applications being deployed.
Ensure you have valid licenses and understand IBM's cloud licensing policies.
 Budget and Cost Monitoring
Use IBM Cloud's cost estimation tools to understand the expected costs of the deployment
and plan budgets accordingly. Cost controls and monitoring tools can help manage cloud
spending effectively.

2.2.2 Overview of Supported Configurations and Versions for AIX and Linux

Supported AIX Versions and Configurations:

IBM Power Virtual Server supports various versions of AIX, typically the latest stable versions
and long-term supported releases. AIX 7.x versions are commonly supported, providing
compatibility for applications that require specific features or libraries.

Organizations can choose long term support (LTS) versions of AIX, such as AIX 7.2, which
offer extended support cycles, stability, and regular security patches. This is ideal for
enterprise environments that prioritize stability.

Ensure that the kernel and patch levels align with application requirements, as certain
patches or specific kernel configurations may be needed for compatibility with enterprise
software.

Power Virtual Server uses IBM's Power hardware, ensuring that AIX is optimized for this
architecture. PowerVM is used as the hypervisor, providing advanced features like dynamic
resource allocation, shared processor pools, and partition mobility.

Supported Linux Distributions and Configurations:

Red Hat Enterprise Linux (RHEL) is widely supported on IBM Power Virtual Server, including
recent releases and LTS versions. RHEL's enterprise-grade stability and support make it
suitable for production workloads.

SUSE Linux Enterprise Server (SLES) is another commonly supported distribution, known for
its robustness in enterprise environments. It offers tools for managing workloads, security
features, and high availability.

Ubuntu, particularly LTS versions, is also supported on IBM Power Virtual Server. It is often
chosen for its flexibility and ease of use, especially in DevOps and modern application
environments.

For Linux deployments, ensure the selected distribution has compatible kernel versions and
drivers for IBM Power architecture. Distributions optimized for POWER architecture take full
advantage of hardware capabilities, which improves performance for data-intensive
applications.

32 Power Virtual Server for AIX and Linux

 Configuration Options:
Single- and Multi-Tenant Configurations: IBM Power Virtual Server offers single-tenant and
multi-tenant configurations, allowing businesses to select an option based on their isolation,
compliance, and cost requirements.

Storage Configurations
Power Virtual Server utilizes high performance SAN-attached storage using IBM
FlashSystem® storage controllers. The storage offering allows you to choose the right
performance tier for each volume that is attached. The storage tiers are based on the number
of input/output operations per second (IOPs). See “Storage Tiers” on page 10 for details on the
storage tiers offered.

For database access, choose a storage tier that has a higher IOPS rating such as Tier0 or
Tier1. For system files, Tier3 storage might be a good option. For smaller volumes with high
activity, Power Virtual Server offers the Fixed IOPs tier which provides 5000 IOPS no matter
the size of the volume.

Network Configurations
IBM Power Virtual Server allows for private IP addresses for internal communication and
public IP addresses for Internet-facing applications. Private connectivity can be secured with
Direct Link or VPN, depending on business needs.

High Availability and Failover Configurations

For high availability, workloads can be deployed across multiple zones or regions, ensuring
that applications remain accessible even in case of a data center outage. AIX and Linux
workloads can be configured in clusters for failover and load balancing, particularly beneficial
for applications requiring uninterrupted uptime.

Optimized Virtual Server Sizes

IBM Power Virtual Server offers different virtual server sizes, with CPU, memory, and storage
capacities tailored for small workloads up to enterprise-level applications. For specific
requirements, custom server configurations allow precise resource allocation, ensuring that
businesses only pay for what they need.

Summary
Preparing for AIX and Linux deployments on IBM Power Virtual Server involves assessing
workload requirements, choosing compatible OS versions, and configuring the environment
to meet performance, security, and compliance needs. Organizations can maximize the
benefits of IBM Power Virtual Server's scalable and high-performance infrastructure by
selecting supported versions of AIX and Linux and aligning deployment choices with business
goals. Proper planning and configuration provide a solid foundation for successfully managing
enterprise workloads in the cloud.

2.3 Deployment Option

Before starting your first deployment, you should be familiar with the basic concepts of IBM
Power Virtual Server from the Chapter 1. You should understand the terms used throughout
the book and have the first impression how they map to your needs.

This section provides an overview of the various methods available for deploying AIX and
Linux operating systems to IBM Power Virtual Server. IBM Power Virtual Server offers a

Chapter 2. Deployment options 33

 scalable and cost-effective solution for running IBM AIX, IBM i, and Linux workloads in the
IBM public cloud. The deployment options covered in this guide include:
 IBM Cloud User Interface: Deploy AIX and Linux instances directly through the IBM Cloud
web-based interface, providing an intuitive and interactive approach.
 IBM Cloud CLI: Use the IBM Cloud Command Line Interface (CLI) for scripts and efficient
method to deploy and manage instances.
 Terraform: Automate the deployment of AIX and Linux instances using Terraform, enabling
infrastructure as code for repeatable and scalable deployments.
 Ansible: Deploy and manage AIX and Linux instances with Ansible, providing configuration
management and automation capabilities.

IBM Cloud Power Virtual Server provides rich set of REST APIs which you can use together
with almost every possible tool. Options tailored to meet various user/customer needs,
ranging from manual deployments to fully automated solutions, ensuring flexibility and
adaptability for diverse environments.

2.4 Deployment with IBM Power Virtual Server web user

interface
Deployment consists of the following steps:
1. Enter your user ID and password and you will get a screen like shown in Figure 2-13.
.

Figure 2-13 Cloud Login with username and password

2. From this screen you can create a new workspace by clicking the button “Create a new
workspace” or select a workspace from the list on the left. The whole work with Power
Virtual Server is done inside of workspaces. Each workspace is created in some Power
Virtual Server datacenter.

34 Power Virtual Server for AIX and Linux

 In this screen, you first choose if you want to create an “IBM Datacenter” (public cloud) or
“Client location” (private cloud) workspace. If you have a Private Cloud installation in your
datacenter, you can choose “Client location”. In this book we assume that you use “IBM
Datacenter” or public cloud IBM Power Virtual Server. For more information on IBM Power
Virtual Server Private Cloud see Introduction to IBM Power Virtual Server Private Cloud,
REDP-5745.
The next choice is which datacenter you want to host your instance. In the drop down list
“Datacenter” you can choose a datacenter which you find best for your project. If you don’t
have any specific location requirements, you can choose any datacenter. It is
recommended that you choose a datacenter that is closest to your users to limit latency for
them.
If you have specific requirements on where your data can reside (like GDPR), you may
want to choose from the data centers located in your country or in neighboring countries. If
you have regulatory requirements that preclude the use of any of the IBM locations,
consider using the Power Virtual Server Private Cloud where you can place Power Virtual
Server infrastructure in a qualifying datacenter.
Click “Continue” and provide some details about the workspace. At least you must provide
a name for your future workspace and a resource group. You can also enter some tags
and access management tags.
After you click “Continue” one more time you can install optional integrations into your
workspace. As we wrote this IBM Redbooks® publication, there was only one integration
with IBM Cloud Monitoring available but more are being added over time.
After you chose everything and enter all data, click “Finish”. Summary of create
workspace show as Figure 2-14.

Figure 2-14 Summary of Create Workspace

The last step to do is to check “I agree to the Terms and conditions” and click “Create”
button on the right side. After you clicked “Create” it takes some seconds to provision your
new workspace. You will be presented with a list of your workspaces and their status.

Chapter 2. Deployment options 35

 Figure 2-15 shows a list of resources after creating a Power Virtual Server instance.

Figure 2-15 List of Workspaces

3. When your new created workspace changes its status to “Active”, you can select it in the
left menu and start working with it.
Let’s take some time to learn all menu options you have when you work with a workspace.
There are 5 big areas:
– Compute
– Networking
– Storage Volumes
– Event Logs
– Additional products and services
• In the last menu “Additional products and services” you can learn which added
services you can deploy on IBM Power Virtual Server, like OpenShift, PowerHA,
PowerSC and others.
• In the “Event Logs” section you can find latest log entries. In a fresh created
workspace there should be no logs. But later when you create different objects like
volumes, networks and virtual servers, you will find here more and more logs. Only
latest 400 log entries are shown in the window. You can filter them by using filter
icon right on the table’s top by resource types, actions and severity.
The other three menu entries - Compute, Network, and Storage Volumes - are where you
spend most of your time working with Power Virtual Server.
• In “Storage Volumes” you can create data volumes for your future virtual servers, or
you can change them to be boot able or shareable between different virtual servers.
You can also configure Global Replication Services between datacenter to enable
disaster recovery for your virtual servers.
• In “Network” you create subnets where your virtual servers will be located. You
need the subnets not only for creating your virtual servers, but also to connect your
IBM Power Virtual Servers workspace to your on-premises datacenter using Transit
Gateway or other ways.
• In “Compute” you manage your virtual servers, SSH keys, you use to access the
virtual servers, and boot images.
No server can be deployed without a boot image. We show using standard images from
the IBM Power Virtual Server catalog. We don’t need to import them, it will happen
automatically. If you have any prepared boot images, you can import them using “Boot
images” menu in “Compute” section.

36 Power Virtual Server for AIX and Linux

4. Our first task is to create an SSH key which will be used to connect to the newly created
virtual servers. If you already have some SSH key, you can take its public part. If you don’t
have an SSH key, create it using your SSH software. On Linux or AIX, it can be done by
using the command ssh-keygen.

Attention: Depending on which operating system you will deploy and the SSH software
installed on it, you may need different SSH keys of different types. Not every SSH service
understands “-sk” types for security keys. Older SSH services may only understand
ssh-rsa and ssh-dsa types of SSH keys.

After you created SSH key and have its public key, switch to Compute > SSH keys and
click the blue button “Create SSH key”. Paste your public key into “Public key” field and
enter some name into the field “Key name”. After you finished, click “Add SSH key” as
shown in Figure 2-16.

Figure 2-16 Add SSH key

5. The next step on the way to our first virtual server is to create a subnet. Switch to
“Networking” > “Subnets” and click the button “Create subnet”. Enter name for your future
network into the “Name” field and a network IP address (or CIDR) into the “CIDR” field.
The values you enter here you usually should discuss with your network administration
team. But if you create a server for the first time and only for testing, you can enter here
everything you want. Important is that it is a valid network address in CIDR (or bit)
notation.

Chapter 2. Deployment options 37

 All other values will be automatically generated by IBM Power Virtual Server as seen in
Figure 2-17.

Figure 2-17 Subnet create info

Important: Attention: IBM Power Virtual Server automatically sets DNS server address to
127.0.0.1. In normal circumstances you don’t have a DNS server on each of your virtual
servers. If your workspace connected to your on-premises environment or if you already
deployed a DNS server in your cloud environment, you can set your existing DNS server
address here. If you don’t have it, we urge you to deploy at least one DNS server or service
as the first task in the cloud. If you don’t want to do it and just testing, you can use some
open DNS servers like Google DNS 8.8.8.8 and 8.8.4.4.

You can specify multiple DNS servers by separating them with “,” commas.

6. We added our SSH key into Power Virtual Server subnet and created a new subnet. Now
we can deploy the first virtual server. Switch to "Compute" → "Virtual server instances"
and click the button “Create instance”.
Enter your future server’s name into the “Instance name” field. You can create multiple
virtual servers at once if you change the field “Number of instances”.
If you have any server placement groups or shared processor pools, you can add your
server into those during creation.
• You usually need the server placement groups if you want to deploy a highly
available application using IBM PowerHA SystemMirror for AIX or PaceMaker on
Linux.

38 Power Virtual Server for AIX and Linux

 • Shared processor pools have the same meaning and the same function as in your
on-premise infrastructure.
• You can pin your new virtual server instance to the IBM Power server, where it is
created. It is usually the case when your application is licensed based on hardware
serial numbers. In all other cases it is recommended to switch off virtual server
pinning and set it to none.
The last action in this step is to select your SSH key, which you created earlier.
Figure 2-18 shows creating our virtual server instance.

Figure 2-18 VSI create with instance name

7. After you entered all values, click “Continue” and switch to the next step.
Here you choose which operating system you deploy and which image you use to deploy
it. Select operating system, select available image, storage tier and storage pool. If you
have multiple storage volumes and would like to have them all on the same storage
system, select here “Affinity” and select one of the existing storage volumes.
Otherwise, if you want to split up your boot volumes from your data volumes, you can
select “Anti-affinity” and select one of your data volumes. Then you boot volume will be
placed on another storage system.
• Under “Advanced settings” you can also create replication of your boot volume into
another datacenter if you have such DR requirements.

Chapter 2. Deployment options 39

 • In “Cloud-init user data” you can specify additional configuration steps needs to be
performed after the system is deployed. For more information on this field refer to
the official cloud-init documentation.
This is shown in Figure 2-19.

Figure 2-19 More setting for VSI

8. Click “Continue” to switch to the next step. In the next step you can choose hardware type
where you want to deploy your virtual server and its hardware (CPU, RAM) configuration.
Under “Machine type” you usual have two types of systems - smaller scale-out systems
like S922, S1022 and bigger enterprise systems like E980 or E1080.
Next you select type of cores you wish to be allocated to your virtual server - “shared
uncapped”, “shared capped” or “dedicated”. The types have the same meaning as on IBM
Power LPARs. Depending on the type you can choose different values for “Cores” which
core ponds to the “Desired entitled capacity” and for “Virtual Cores”, which corresponds to
the “Desired virtual processing units”. Figure 2-20 on page 41 show setting the amount of
memory you want to allocate to your virtual server instance

40 Power Virtual Server for AIX and Linux

.

Figure 2-20 Select memory

9. Figure 2-21 shows the panel that is used to create new data volumes or attach existing
data volumes to your virtual server. If you don’t need any data volumes, you can skip the
step and click “Continue”.

Figure 2-21 Storage volumes

Chapter 2. Deployment options 41

 10.In the last step you attach your virtual server to available networks. Click the button
“Attach” and select one of the available subnets. You can select to automatically assign an
IP address from the subnet, or provide the fixed IP address from the subnet.
Figure 2-22 shows creating a special “public” subnet by clicking “Public network” switch. In
this case your Power Virtual Server instance will be available directly from the Internet.
There are several ports automatically open if you select the option. More about the open
ports you can read in the documentation -
https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-network-security.

Figure 2-22 Network Interface

After you made your selection click “Finish”. Figure 2-23 on page 43 shows your edit
options, If you want change some previous settings, you can click “Edit” near any of the
previous steps.

42 Power Virtual Server for AIX and Linux

Figure 2-23 Review setting

If you finished configuring your virtual server, you can find cost estimation on the right side
of your window. Figure 2-24 on page 44 shows the cost estimation (actual costs will vary
based on account and location). After that click the option “I agree to the Terms and
conditions”. and then you can click the button “Create”.

Chapter 2. Deployment options 43

 Figure 2-24 Cost estimate

11.The creation of the virtual server starts almost immediately after you clicked “Create” and
can take several minutes. After you click “Refresh” button in your “Virtual server instances”
view, you can find your virtual server first in “Building” state, then in “Warning” state, and
after some time in “Active” state. The “Warning” state usually means that your LPAR is
already created but RMC connection is still not available.
You can select your virtual server in the list and check its settings as shown in Figure 2-25
on page 45. You can’t change the settings while the server is being built, but you can open
the console to the system and start working with it, it is already created and the operating
system is booted.

44 Power Virtual Server for AIX and Linux

 Figure 2-25 Virtual server settings

After the system is in “Active” state you can change RAM and CPU settings, attach your
virtual server to new networks, or attach and create new storage volumes to it.
From “VM actions” button you start, stop or restart your virtual server instance. You can
also capture your virtual server as new image or as backup into IBM Cloud Object
Storage. If you have problems accessing your virtual server, you can open console using
the same button and investigate the problems.
If you don’t need your virtual server anymore, you can always remove it by using “Delete”
button left from “VM actions” button.

2.5 Deployment with IBM Cloud CLI

The web user interface is good if you deploy only a few systems. If you deploy several
systems or want to script the deployment, you usually use other tools. IBM provides IBM
Cloud CLI (command line interface) to enable such use cases.
1. You can install IBM Cloud CLI on Windows, MacOS or Linux. All common architectures -
x86_64, aarch64, ppc64le and s390x - are supported for the Linux version. Example 2-1
on page 46 shows how to install IBM Cloud CLI on Linux.

Chapter 2. Deployment options 45

 Example 2-1 Installing IBM Cloud CLI on Linux
$ curl -fsSL https://clis.cloud.ibm.com/install/linux | sh

The MacOS install command is shown in Example 2-2 and the Windows install process is
shown in Example 2-3.

Example 2-2 Installing IBM Cloud CLI on MacOS

$ curl -fSSL https://clis.cloud.ibm.com/install/osx | sh

Example 2-3 Installing IBM Cloud CLI on Windows

iex (New-Object
Net.WebClient).DownloadString('https://clis.cloud.ibm.com/install/powershell')

If you don’t have direct Internet access from the system where you want to install IBM
Cloud CLI, you can download a suitable archive from this Github release page and use it
to install IBM Cloud CLI.
After you installed IBM Cloud CLI it is recommended to check regularly for updates as
shown in Example 2-4.

Example 2-4 Checking for updates for IBM Cloud CLI

$ ibmcloud update
Checking for updates...
No update required. Your CLI is already up-to-date.
To view available plugin updates, run 'ibmcloud plugin list'.

2. Before starting with IBM Cloud Power Virtual Server you must install IBM Cloud Power
Virtual Server CLI plug-in as shown in Example 2-5.

Example 2-5 Installing Power Virtual Server plug-in

$ ibmcloud plugin install pi
Looking up 'pi' from repository 'IBM Cloud'...
Plug-in 'power-iaas[pi] 1.3.0' found in repository 'IBM Cloud'
Attempting to download the binary file...
28.16 MiB / 28.16 MiB
[=================================================================================
==============================================] 100.00% 2s
29526144 bytes downloaded
Installing binary...
OK
Plug-in 'power-iaas 1.3.0' was successfully installed into
/Users/user/.bluemix/plugins/power-iaas. Use 'ibmcloud plugin show power-iaas' to
show its details.

Now you can see all available Power Virtual Server commands with ibmcloud pi
command as shown in Example 2-6.

Example 2-6 IBM Cloud CLI Power Virtual Server commands

$ ibmcloud pi
Manage IBM Cloud Power Virtual Server service.

Usage:
pi [command]

46 Power Virtual Server for AIX and Linux

Account Management Commands
ssh-key, ssh IBM Cloud Power Virtual Server SSH-Keys.

Compute Instances Commands

instance, ins IBM Cloud Power Virtual Server Instances.
placement-group, pg IBM Cloud Power Virtual Server Placement Groups.
shared-processor-pool, spp IBM Cloud Power Virtual Shared Processor Pools.
snapshot, snap [DEPRECATED] IBM Cloud Power Virtual Server
Snapshots.
system-pools, sysp List of available system pools within a
particular data center.

Host Group Commands

available-hosts, ahost List of hosts available for reservation.
host, hs IBM Cloud Power Virtual Server Host.
host-group, hg IBM Cloud Power Virtual Server Host Group.

Networking Commands
cloud-connection, cc IBM Cloud Power Virtual Server Cloud Connections.
ike-policy, ike IBM Cloud Power Virtual Server Internet Key
Exchange policies.
ipsec-policy, ips IBM Cloud Power Virtual Server Internet Protocol
Security policies.
network-interface, ni IBM Cloud Power Virtual Network Interfaces.
subnet, snet IBM Cloud Power Virtual Server Subnets.
vpn IBM Cloud Power Virtual Server Virtual Private
Networking.

Storage Commands
disaster-recovery, drl List disaster recovery locations for the current
region or all regions.
image, img IBM Cloud Power Virtual Server Images.
storage-pools, spools List all storage pools for the targeted region.
storage-tiers, stiers List all storage tiers for the targeted region.
volume, vol IBM Cloud Power Virtual Server Volumes.
volume-group, vg IBM Cloud Power Virtual Server Volume Groups.

Additional Commands:
datacenter, dat IBM Cloud Power Virtual Server Datacenters.
job IBM Cloud Power Virtual Server Jobs.
workspace, ws IBM Cloud Power Virtual Server Workspaces.

Flags:
-h, --help Display help information for the command.
--json Format output in JSON

Use "pi [command] --help" for more information about a command.

3. But before starting with Power Virtual Server you must login into IBM Cloud. There are
several ways to login into IBM Cloud using CLI.
The first and well known from the web interface is using your login credentials - usually
your e-mail address and password. Just enter ibmcloud login, then enter your e-mail
and your password.

Chapter 2. Deployment options 47

 More useful for automated deployment operations is to use API keys. If you don’t have
any, you can create a new API key but going to https://cloud.ibm.com/iam/apikeys in
your web browser and clicking the Create button. Enter key name and description, select
that the API key will be used for CLI and click Create. The new key will be created and
shown to you. You can click “Copy” to copy the key into buffer or “Download” to download it
to your disk. After close the window, you can’t show the key one more time! Save your key
before closing the window. After you saved the key, you can close the window. If you don’t
need the API key anymore, you can delete or disable it. We recommend, that you regular
check your API keys and remove the keys, you don’t need.
4. After you created the API key, you can export it as variable IBMCLOUD_API_KEY in your
shell session and use ibmcloud login command to login to IBM Cloud as shown in
Example 2-7.

Example 2-7 Using API key to login to IBM Cloud

$ export IBMCLOUD_API_KEY=fvc1inYW1qCyDAcRtMgHew5iyQ5a3A0O-iQZcjbOXvDn
$ ibmcloud login
API endpoint: https://cloud.ibm.com
Region: eu-de
Logging in with API key from environment variable...
Authenticating...
OK

Targeted account Andrey Klyachkin's Account (f3862ec10c674ec49a6977ace068571f) <->

2004094

API endpoint: https://cloud.ibm.com

Region: eu-de
User: [email protected]
Account: Andrey Klyachkin's Account (f3862ec10c674ec49a6977ace068571f)
<-> 2004094
Resource group: No resource group targeted, use 'ibmcloud target -g
RESOURCE_GROUP'

5. After you logged in you can list available workspaces and select one of them as your target
workspace for the future operations. You always can select another workspace if you wish
as shown in Example 2-8.

Example 2-8 Listing and selecting a workspace

$ ibmcloud pi ws ls
Listing workspaces under account Andrey Klyachkin's Account as user
[email protected]...
CRN
ID Name
crn:v1:bluemix:public:power-iaas:mad02:a/f3862ec10c674ec49a6977ace068571f:1a7ce8a1
-ceff-44b6-8fe1-1a06b4011ef3:: 1a7ce8a1-ceff-44b6-8fe1-1a06b4011ef3 Mad02
crn:v1:bluemix:public:power-iaas:mad02:a/f3862ec10c674ec49a6977ace068571f:d52a66f1
-fc55-41e9-bb1b-a4e658c41544:: d52a66f1-fc55-41e9-bb1b-a4e658c41544 Power
Virtual Server Redbook

$ ibmcloud pi ws tg
crn:v1:bluemix:public:power-iaas:mad02:a/f3862ec10c674ec49a6977ace068571f:d52a66f1
-fc55-41e9-bb1b-a4e658c41544::

48 Power Virtual Server for AIX and Linux

Targeting service
crn:v1:bluemix:public:power-iaas:mad02:a/f3862ec10c674ec49a6977ace068571f:d52a66f1
-fc55-41e9-bb1b-a4e658c41544::...

6. If you don’t have any workspaces, you can create a new workspace. You need a name of
resource group in IBM Cloud and a name of Power Virtual Server datacenter to create
new workspace. You can get list of your resource groups by using ibmcloud resource
groups and the list of Power Virtual Server datacenter by using ibmcloud pi dat ls as
shown in Example 2-9.

Example 2-9 Listing resource groups and datacenter

$ ibmcloud resource groups
Retrieving all resource groups under account f3862ec10c674ec49a6977ace068571f as
[email protected]...
OK
Name ID Default Group State
abc 4af02fdcdcc64739ad83afc5c0bf4574 false ACTIVE
Default f7f08119179c4b35ad9c72dfff457798 true ACTIVE

$ ibmcloud pi dat ls
Listing datacenters...
Status Type Region
active off-premises wdc07
active off-premises wdc06
active off-premises us-south
active off-premises us-east
active off-premises tor01
active off-premises tok04
active off-premises syd05
active off-premises syd04
active off-premises sao04
active off-premises sao01
active off-premises osa21
active off-premises mon01
active off-premises mad04
active off-premises mad02
active off-premises lon06
active off-premises lon04
active off-premises eu-de-2
active off-premises eu-de-1
active off-premises dal12
active off-premises dal10
active off-premises che01

7. After you’ve collected all required information, you can create a new workspace: as shown
in Example 2-10.

Example 2-10 Creating new Power Virtual Server workspace using IBMCloud CLI
$ ibmcloud pi ws cr RedbookWS -d eu-de-1 -g f7f08119179c4b35ad9c72dfff457798 -p
public
Creating workspace RedbookWS...

Name RedbookWS
Plan ID f165dd34-3a40-423b-9d95-e90a23f724dd

Chapter 2. Deployment options 49

 Similar to web user interface, you can create storage volumes, subnets and virtual server
instances using IBM Cloud CLI.
You can show all available “stock” or Power Virtual Server catalog images using the
command
ibmcloud pi img lc
This is shown in Example 2-11.

Example 2-11 Show Catalog Images

$ ibmcloud pi img lc
Listing catalog images under account Andrey Klyachkin's Account as user
[email protected]...
ID Name Address
4f98657e-1927-4188-a9a5-38392867e626 7200-05-07
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/4f98657e-
1927-4188-a9a5-38392867e626
17be81d1-8438-429e-8e10-93207e1ca62e 7200-05-08
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/17be81d1-
8438-429e-8e10-93207e1ca62e
0da299aa-cc52-42c4-b6a4-74300e064ec2 7300-02-01
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/0da299aa-
cc52-42c4-b6a4-74300e064ec2
599181f0-3277-4dca-8247-e43af8b17e75 CentOS-Stream-9
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/599181f0-
3277-4dca-8247-e43af8b17e75
6e09a0b0-564f-49a6-be9c-6c477a6ee9ea IBMi-72-09-2924-10
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/6e09a0b0-
564f-49a6-be9c-6c477a6ee9ea
b2a8ae72-d5f9-4027-94bd-d016ef1d40b7 IBMi-72-09-2924-11
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/b2a8ae72-
d5f9-4027-94bd-d016ef1d40b7
fca94c29-872e-41f2-8b75-add8d9111be2 IBMi-72-09-2984-10
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/fca94c29-
872e-41f2-8b75-add8d9111be2
62ee7a2f-6272-40d6-8cb9-d03bb21b1df7 IBMi-72-09-2984-11
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/62ee7a2f-
6272-40d6-8cb9-d03bb21b1df7
abcac397-167c-4384-ab7e-c1b196d5a32b IBMi-73-13-2924-3
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/abcac397-
167c-4384-ab7e-c1b196d5a32b
0cd1bfae-7893-4344-ad4a-06d30607855f IBMi-73-13-2924-4
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/0cd1bfae-
7893-4344-ad4a-06d30607855f
c2fe86d6-dfee-4476-b161-06d3970846dd IBMi-73-13-2984-3
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/c2fe86d6-
dfee-4476-b161-06d3970846dd
6fc68009-f241-44f6-890b-f1a27498c12e IBMi-73-13-2984-4
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/6fc68009-
f241-44f6-890b-f1a27498c12e
366855d2-00f2-4b8f-b4bf-3a1d669cce6b IBMi-74-09-2924-1
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/366855d2-
00f2-4b8f-b4bf-3a1d669cce6b

50 Power Virtual Server for AIX and Linux

bd042cd4-e077-4c8c-add2-be8eb4ce3246 IBMi-74-09-2984-1
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/bd042cd4-
e077-4c8c-add2-be8eb4ce3246
006de405-3202-494a-b89f-bfbfcb45aa0e IBMi-74-10-2924-1
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/006de405-
3202-494a-b89f-bfbfcb45aa0e
bfb25b39-9df8-4185-b66c-eba2488abce7 IBMi-74-10-2984-1
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/bfb25b39-
9df8-4185-b66c-eba2488abce7
7068872d-ab22-4043-bcb6-e1a5422ce0d4 IBMi-75-03-2924-2
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/7068872d-
ab22-4043-bcb6-e1a5422ce0d4
cd50b8d3-cf2a-4657-b81f-6a097f9bf128 IBMi-75-03-2984-1
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/cd50b8d3-
cf2a-4657-b81f-6a097f9bf128
5355fc84-242e-4414-961b-b61c0944c71d IBMi-75-04-2924-1
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/5355fc84-
242e-4414-961b-b61c0944c71d
759bcc64-76a9-4ce8-881d-692c1aef9d22 IBMi-75-04-2984-1
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/759bcc64-
76a9-4ce8-881d-692c1aef9d22
3415720a-efaa-4d56-98d7-7becabae24d7 IBMi_COR-74-09-1
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/3415720a-
efaa-4d56-98d7-7becabae24d7
7b05498f-3b56-4df9-9b7f-0cbd8e83b605 IBMi_COR-74-10-1
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/7b05498f-
3b56-4df9-9b7f-0cbd8e83b605
f2202fe0-2554-4834-a066-3473ee96720b OCP-DHCP-SERVER
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/f2202fe0-
2554-4834-a066-3473ee96720b
988abf72-02fb-478d-a9cf-338fb61b402c RHEL8-SP8
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/988abf72-
02fb-478d-a9cf-338fb61b402c
b015b50c-cccd-4a96-9683-0a30eb80a5fa RHEL8-SP8-BYOL
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/b015b50c-
cccd-4a96-9683-0a30eb80a5fa
128ac3a2-2dea-4aa0-86b1-91abba402a98 RHEL9-SP2
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/128ac3a2-
2dea-4aa0-86b1-91abba402a98
4c9051a0-b8f8-48a3-9ede-6e177a2a9a92 RHEL9-SP2-BYOL
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/4c9051a0-
b8f8-48a3-9ede-6e177a2a9a92
42c3304c-1236-46e2-b6ad-ccc4799324fd RHEL9-SP4
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/42c3304c-
1236-46e2-b6ad-ccc4799324fd
1fdc4292-585e-48be-b0b0-5d969de5e4ae RHEL9-SP4-BYOL
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/1fdc4292-
585e-48be-b0b0-5d969de5e4ae
2272ec49-dd96-409a-8429-dddbda5eac8a SLES15-SP5
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/2272ec49-
dd96-409a-8429-dddbda5eac8a
e7e59665-8452-44dd-8d42-25965594e332 SLES15-SP5-BYOL
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/stock-images/e7e59665-
8452-44dd-8d42-25965594e332

Chapter 2. Deployment options 51

 8. After you’ve found an image you want to use for your next virtual server instance, you can
copy it into your list of available images as shown in Example 2-12.

Example 2-12 Copying image from catalog into workspace

$ ibmcloud pi img cr 1fdc4292-585e-48be-b0b0-5d969de5e4ae
Creating image from 1fdc4292-585e-48be-b0b0-5d969de5e4ae under account Andrey
Klyachkin's Account as user [email protected]...

CRN -
Image 86bb4a65-5084-44e5-9732-83ec00da55c0
Name RHEL9-SP4-BYOL
Arch ppc64
Container Format bare
Disk Format raw
Hypervisor phyp
OS rhel
Type stock
Size 100
Created 2024-11-03T15:48:08.000Z
Last Updated 2024-11-03T15:48:08.000Z
Description -
Storage Tier
Storage Pool

In Example 2-13 we list the available images.

Example 2-13 Listing images available for new deployments

$ ibmcloud pi img ls
Listing images under account Andrey Klyachkin's Account as user
[email protected]...
ID Name Address
a69ea067-2592-45c4-b719-52507d26bfd4 7300-02-01
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/images/a69ea067-2592-4
5c4-b719-52507d26bfd4
86bb4a65-5084-44e5-9732-83ec00da55c0 RHEL9-SP4-BYOL
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/images/86bb4a65-5084-4
4e5-9732-83ec00da55c0

9. Before creating a new instance we need a subnet. We can check all available subnets in a
workspace by using the command shown in Example 2-14.

Example 2-14 Listing subnets in workspace and getting information about subnet
$ ibmcloud pi snet ls
Listing subnets under account Andrey Klyachkin's Account as user
[email protected]...
ID Name Address
cff136ca-e9f0-49ea-b139-8100f75e4da6 redbook_net
/pcloud/v1/cloud-instances/a57c0dadfc1b407c89d1809c0aadad2f/networks/cff136ca-e9f0
-49ea-b139-8100f75e4da6

$ ibmcloud pi snet get redbook_net

Getting Subnet redbook_net under account Andrey Klyachkin's Account as user
[email protected]...

52 Power Virtual Server for AIX and Linux

CRN -
ID cff136ca-e9f0-49ea-b139-8100f75e4da6
Name redbook_net
VLAN 1020
Type vlan
CIDR Block 192.168.1.0/24
DNS 8.8.8.8, 161.26.0.10, 161.26.0.11
IP Range [192.168.1.2-192.168.1.254]
Gateway 192.168.1.1
MTU 1450
Jumbo false

10.If you didn’t find a suitable subnet or need a new subnet, you can create it as shown in
Example 2-15.

Example 2-15 Creating new subnet with IBMCloud CLI

$ ibmcloud pi snet cr mgmt_net -n private -c 172.16.100.0/24 -d 8.8.8.8 -g
172.16.100.1 -i 172.16.100.10-172.16.100.250 -m 1450
Creating subnet mgmt_net under account Andrey Klyachkin's Account as user
[email protected]...

CRN -
ID 01781d38-5d02-4a5d-97e3-ab62a44cee67
Name mgmt_net
VLAN 288
Type vlan
CIDR Block 172.16.100.0/24
DNS 8.8.8.8, 161.26.0.10, 161.26.0.11
IP Range [172.16.100.10-172.16.100.250]
Gateway 172.16.100.1
MTU 1450
Jumbo false

11.The last piece of information we need is SSH key. If you don’t have it, you can upload a
new key by using ibmcloud pi ssh cr command. Otherwise check the keys with the
commands
ibmcloud pi ssh ls and ibmcloud pi ssh get <NAME> commands.
12.Now we’ve got all required informations and are ready to create a Power Virtual Server
instance using IBMCloud CLI. We use ibmcloud pi ins cr command to do it as we can
see in Example 2-16.

Example 2-16 Creating a new Red Hat Enterprise Linux 9.4 instance using IBMCloud CLI
$ ibmcloud pi ins cr pvsrb02 -i RHEL9-SP4-BYOL -n redbook_net,mgmt_net -k mac -s
s922 -r shared -p 0.25 -m 4 -t tier0
Creating instance pvsrb02 under account Andrey Klyachkin's Account as user
[email protected]...
Instance pvsrb02 created.

ID b5b31081-af9a-473f-b31f-a1a295dad02c
Name pvsrb02
CRN -
CPU Cores 0.25
Memory 4
Processor Type shared

Chapter 2. Deployment options 53

 System Type s922
Subnets cff136ca-e9f0-49ea-b139-8100f75e4da6,
01781d38-5d02-4a5d-97e3-ab62a44cee67
Boot Disk Size 100
Volumes -
Storage Tier tier0
Pin Policy none
Image a9f983e7-7415-49f9-aaf5-7b8e2a640138
Created 0001-01-01T00:00:00.000Z
Last Updated 0001-01-01T00:00:00.000Z
Status BUILDING
Progress 0
Storage Pool General-Flash-50
Storage Pool Affinity -
Shared Processor Pool -
Shared Processor Pool ID -
Placement Group -
Deployment Type -
Address Internal, Address:, Mac, Address:,
Internal, Address:, Mac, Address:,

The first parameter of the command is the name of the future Power Virtual Server
instance. Table 2-1 shows some of the different parameters used to define your instance.

Table 2-1 Parameters for IBMCloud pi ins cr

Parameter Meaning

-i Image to use to create the instance

-n comma-separated list of networks

-k SSH key to add

-s System type - s922, s1022, e980, e1080

-r CPU type - shared, capped, dedicated

-p Number of processing units (entitled capacity)

-m RAM in GB

-t Storage tier for boot volume. You can check

available storage tiers by issuing ibmcloud pi
stiers

There are many more options you can use during instance creation. IBM Cloud CLI provides
you a very flexible way of creating and managing Power Virtual Server instances.

If you want to automate and use data from IBM Cloud CLI in your automation, most CLI
commands support a setting ( --json) to output data in JSON format as shown in
Example 2-17.

Example 2-17 Getting status of virtual server instance with IBMCloud CLI and jq
$ ibmcloud pi ins get pvsrb02 --json | jq -r .status
ACTIVE

54 Power Virtual Server for AIX and Linux

 Example 2-18 is showing how, when using IBM Cloud CLI, you can easily stop and start your
instances.

Example 2-18 Stopping and starting Power Virtual Server instance

$ ibmcloud pi ins act pvsrb02 -o stop
Performing action stop for instance pvsrb02 under account Andrey Klyachkin's
Account as user [email protected]...
OK
Action stop complete for instance pvsrb02.
$ ibmcloud pi ins get pvsrb02 --json | jq -r .status
SHUTOFF
$ ibmcloud pi ins act pvsrb02 -o start
Performing action start for instance pvsrb02 under account Andrey Klyachkin's
Account as user [email protected]...
OK
Action start complete for instance pvsrb02.
$ ibmcloud pi ins get pvsrb02 --json | jq -r .status
ACTIVE

Attention: When using the commands like stop and start, the commands are sent to the
systems immediately. However, the systems may not stop immediately even when the
command is successful. You must check the status of the Power Virtual Server instance
before doing any follow-on steps to ensure that the system is in the expected status.

If you don’t need Power Virtual Server instance anymore, you can delete it using ibmcloud pi
ins del as shown in Example 2-19 below.

Example 2-19 Delete command

$ ibmcloud pi ins del pvsrb02
Deleting instance pvsrb02 under account Andrey Klyachkin's Account as user
[email protected]...
OK
Instance pvsrb02 was deleted.

By default data volumes are not deleted with the instance. If you want to delete data volumes
together with the instance, you must specify -d option to the command.

2.6 Deployment with Terraform

Terraform is the defacto standard tool for cloud deployments. Terraform is one of the top-rated
infrastructure-as-code (IaC) tools and allows you to automate provisioning your infrastructure
including servers, firewalls, databases and many more components.

To provision the infrastructure, Terraform works with “providers”. Terraform relies on these
plugins – providers – to interact with cloud providers, SaaS providers, and other APIs. IBM
delivers a provider for IBM Cloud. You can find the opensource project on Github at:
https://github.com/IBM-Cloud/terraform-provider-ibm.

Chapter 2. Deployment options 55

 Usually you do not need to download and compile the code on your own. The complete
documentation for the provider can be found on the Terraform Registry site at:
https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs

To start a new IBM Cloud deployment with Terraform, you must first create a new directory
which will contain the whole Terraform code. The code is written in Terraform configuration
language which is easy to write and to read.

The code can be in several different files or in one big file. For readability reasons we suggest
the use of multiple files.
1. First let’s define some variables as shown in Example 2-20.

Example 2-20 Defining Terraform variables for IBM Cloud in file vars.tf
variable "ibmcloud_apikey" {
type = string
description = "API key to use for IBM Cloud"
default = ""
sensitive = true
}

variable "ibmcloud_region" {
type = string
description = "Region in IBM Cloud"
default = "mad"
}

variable "ibmcloud_zone" {
type = string
description = "Zone in IBM Cloud"
default = "mad02"
}

Some of data like ibmcloud_apikey are sensitive and marked as such. It means this data
will not be in the output of Terraform. If you have the values you can write them directly into
the file but you must not do it.
Some of the values like IBM Cloud API key you can redefine on the fly by using the
environment variable IBMCLOUD_API_KEY. Generally you can redefine each Terraform
variable by using environment variables which start with TF_VAR_. If your Terraform
variable is ibmcloud_zone, then you can use environment variable
TF_VAR_ibmcloud_zone to redefine its value.
Another way to redefine variables on the fly during the provisioning is to use Terraform
variables files (terraform.tfvars). You can define different sets of variables and use them for
different types of deployments. It also makes easy to use Terraform in CI/CD pipelines to
automate cloud deployments.
2. Before creating any resources we must tell Terraform which providers (Terraform plug-ins)
we are going to use and configure them as shown in Example 2-21.

Example 2-21 File with providers descriptions - providers.tf

terraform {
required_providers {
ibm = {
source = "IBM-Cloud/ibm"
}

56 Power Virtual Server for AIX and Linux

 local = {
source = "hashicorp/local"
}
null = {
source = "hashicorp/null"
}
}
}

provider "ibm" {
ibmcloud_api_key = var.ibmcloud_apikey
region = var.ibmcloud_region
zone = var.ibmcloud_zone
}

3. After we defined all prerequisite information we are ready to start with our first real
Terraform code. To deploy systems in IBM Cloud Power Virtual Server we first need some
workspace where we do it. See define workspace in Example 2-22.

Example 2-22 Defining Power Virtual Server workspace in Terraform

data "ibm_resource_group" "cloudrg" {
name = "Default"
}

resource "ibm_pi_workspace" "redbook_ws" {

pi_name = "Redbook TF workspace"
pi_datacenter = var.ibmcloud_zone
pi_resource_group_id = data.ibm_resource_group.cloudrg.id
pi_plan = "public"
}

In our example, we first find an IBM Cloud’s resource group with the name “Default”. If you
have another resource group, define its name here. If we have the resource group, we use
it and the datacenter we defined earlier in the variable files to create a new workspace
called “Redbook TF workspace”.
4. In Example 2-23, we show providing the SSH key that must be uploaded to Power Virtual
Server cloud. It is done by using the resource ibm_pi_key:

Example 2-23 Deploying SSH key to Power Virtual Server

resource "ibm_pi_key" "rb_ssh" {
pi_key_name = "redbook_ssh_key"
pi_ssh_key = file("~/.ssh/id_rsa.pub")
pi_cloud_instance_id = ibm_pi_workspace.redbook_ws.id
}

We used our local SSH key which is saved in our home directory. You can provide another
file or write the SSH public key as a string.
5. In Example 2-24 we show the next step to create a network for our future deployment.

Example 2-24 Defining Power Virtual Server network in Terraform

resource "ibm_pi_network" "rbnet" {

Chapter 2. Deployment options 57

 pi_network_name = "redbook-net"
pi_network_type = "vlan"
pi_cidr = "172.16.100.0/24"
pi_gateway = "172.16.100.1"
pi_ipaddress_range {
pi_starting_ip_address = "172.16.100.10"
pi_ending_ip_address = "172.16.100.250"
}
pi_dns = [ "8.8.8.8" ]
pi_network_mtu = "1450"
pi_cloud_instance_id = ibm_pi_workspace.redbook_ws.id
}

6. Our last step before we deploy a new LPAR is to get image information of the operating
system we want to deploy. Example 2-25 shows the step to show which images exist in the
images catalog.

Example 2-25 Getting AIX 7.3 TL2 SP1 image from the Power Virtual Server image catalog
data "ibm_pi_catalog_images" "pvs_catalog" {
pi_cloud_instance_id = ibm_pi_workspace.redbook_ws.id
}

locals {
img_index = index(data.ibm_pi_catalog_images.pvs_catalog.images[*].name,
"7300-02-01")
pvs_image = data.ibm_pi_catalog_images.pvs_catalog.images[local.img_index]
}

resource "ibm_pi_image" "aix730201" {

pi_image_name = "7300-02-01"
pi_image_id = local.pvs_image.image_id
pi_cloud_instance_id = ibm_pi_workspace.redbook_ws.id
}

7. When we got the Power Virtual Server image catalog, we searched for an image with the
name “7300-02-01” which is AIX 7.3 TL2 SP1 image. We copy the image into our
workspace to use it later to deploy an LPAR.
At this point we have all prerequisites and are ready to deploy our first LPAR. We use the
resource ibm_pi_instance to define our LPAR in Power Virtual Server. Example 2-26
shows this step.

Example 2-26 Creating an LPAR in Power Virtual Server with Terraform

resource "ibm_pi_instance" "lpar" {
pi_instance_name = "tfrb-aix"
pi_memory = 2
pi_processors = 0.25
pi_proc_type = "shared"
pi_image_id = ibm_pi_image.aix730201.image_id
pi_key_pair_name = ibm_pi_key.rb_ssh.name
pi_sys_type = "s1022"
pi_cloud_instance_id = ibm_pi_workspace.redbook_ws.id
pi_health_status = "WARNING"

58 Power Virtual Server for AIX and Linux

 pi_storage_type = "tier1"
pi_network {
network_id = ibm_pi_network.rbnet.network_id
}
}

8. You probably need some volumes for your workloads, These are defined as shown in
Example 2-27.

Example 2-27 Creating Power Virtual Server data volumes

resource "ibm_pi_volume" "datavg" {
pi_volume_size = 20
pi_volume_name = "datavg"
pi_volume_type = "tier1"
pi_volume_shareable = true
pi_cloud_instance_id = ibm_pi_workspace.redbook_ws.id
}

resource "ibm_pi_volume_attach" "datavg_lpar1_attach" {

pi_volume_id = ibm_pi_volume.datavg.volume_id
pi_instance_id = ibm_pi_instance.lpar.instance_id
pi_cloud_instance_id = ibm_pi_workspace.redbook_ws.id
}

9. You are now ready to deploy your first IBM Power Virtual Server system! You can initialize
the Terraform project and create the resources as shown in Example 2-28.

Example 2-28 Creating Power Virtual Server resources with Terraform

$ terraform init
Initializing the backend...
Initializing provider plugins...
- Finding latest version of hashicorp/null...
- Finding latest version of ibm-cloud/ibm...
- Finding latest version of hashicorp/local...
- Installing hashicorp/null v3.2.3...
- Installed hashicorp/null v3.2.3 (signed by HashiCorp)
- Installing ibm-cloud/ibm v1.71.1...
- Installed ibm-cloud/ibm v1.71.1 (self-signed, key ID AAD3B791C49CC253)
- Installing hashicorp/local v2.5.2...
- Installed hashicorp/local v2.5.2 (signed by HashiCorp)
Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://www.terraform.io/docs/cli/plugins/signing.html
Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

Chapter 2. Deployment options 59

 If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

$ terraform apply -var-file=redbook.tfvars

data.ibm_resource_group.cloudrg: Reading...
data.ibm_resource_group.cloudrg: Read complete after 1s
[id=f7f08119179c4b35ad9c72dfff457XXX]

Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated
with the following symbols:
+ create
<= read (data resources)

Terraform will perform the following actions:

# data.ibm_pi_catalog_images.pvs_catalog will be read during apply

# (config refers to values not yet known)
<= data "ibm_pi_catalog_images" "pvs_catalog" {
+ id = (known after apply)
+ images = (known after apply)
+ pi_cloud_instance_id = (known after apply)
}

# ibm_pi_image.aix730201 will be created

+ resource "ibm_pi_image" "aix730201" {
+ crn = (known after apply)
+ id = (known after apply)
+ image_id = (known after apply)
+ pi_cloud_instance_id = (known after apply)
+ pi_image_bucket_access = "public"
+ pi_image_id = (known after apply)
+ pi_image_name = "7300-02-01"
}

# ibm_pi_instance.lpar will be created

+ resource "ibm_pi_instance" "lpar" {
+ crn = (known after apply)
+ fault = (known after apply)
+ health_status = (known after apply)
+ ibmi_rds = (known after apply)
+ id = (known after apply)
+ instance_id = (known after apply)
+ max_memory = (known after apply)
+ max_processors = (known after apply)
+ max_virtual_cores = (known after apply)
+ min_memory = (known after apply)
+ min_processors = (known after apply)
+ min_virtual_cores = (known after apply)
+ operating_system = (known after apply)
+ os_type = (known after apply)
+ pi_cloud_instance_id = (known after apply)
+ pi_health_status = "WARNING"
+ pi_image_id = (known after apply)

60 Power Virtual Server for AIX and Linux

 + pi_instance_name = "tfrb-aix"
+ pi_key_pair_name = (known after apply)
+ pi_license_repository_capacity = (known after apply)
+ pi_memory = 2
+ pi_pin_policy = "none"
+ pi_placement_group_id = (known after apply)
+ pi_proc_type = "shared"
+ pi_processors = 0.25
+ pi_replicants = 1
+ pi_replication_policy = "none"
+ pi_replication_scheme = "suffix"
+ pi_storage_pool = (known after apply)
+ pi_storage_pool_affinity = true
+ pi_storage_type = "tier1"
+ pi_sys_type = "s1022"
+ pi_virtual_cores_assigned = (known after apply)
+ pin_policy = (known after apply)
+ progress = (known after apply)
+ shared_processor_pool_id = (known after apply)
+ status = (known after apply)

+ pi_network {
+ external_ip = (known after apply)
+ ip_address = (known after apply)
+ mac_address = (known after apply)
+ network_id = (known after apply)
+ network_name = (known after apply)
+ type = (known after apply)
}
}

# ibm_pi_key.rb_ssh will be created

+ resource "ibm_pi_key" "rb_ssh" {
+ creation_date = (known after apply)
+ id = (known after apply)
+ key = (known after apply)
+ name = (known after apply)
+ pi_cloud_instance_id = (known after apply)
+ pi_key_name = "redbook_ssh_key"
+ pi_ssh_key = <<-EOT
ssh-rsa AAAA [email protected]
EOT
}

# ibm_pi_network.rbnet will be created

+ resource "ibm_pi_network" "rbnet" {
+ crn = (known after apply)
+ id = (known after apply)
+ network_id = (known after apply)
+ pi_cidr = "172.16.100.0/24"
+ pi_cloud_instance_id = (known after apply)
+ pi_dns = [
+ "8.8.8.8",
]
+ pi_gateway = "172.16.100.1"

Chapter 2. Deployment options 61

 + pi_network_access_config = (known after apply)
+ pi_network_jumbo = (known after apply)
+ pi_network_mtu = 1450
+ pi_network_name = "redbook-net"
+ pi_network_type = "vlan"
+ vlan_id = (known after apply)

+ pi_ipaddress_range {
+ pi_ending_ip_address = "172.16.100.250"
+ pi_starting_ip_address = "172.16.100.10"
}
}

# ibm_pi_volume.datavg will be created

+ resource "ibm_pi_volume" "datavg" {
+ auxiliary = (known after apply)
+ auxiliary_volume_name = (known after apply)
+ consistency_group_name = (known after apply)
+ crn = (known after apply)
+ delete_on_termination = (known after apply)
+ group_id = (known after apply)
+ id = (known after apply)
+ io_throttle_rate = (known after apply)
+ master_volume_name = (known after apply)
+ mirroring_state = (known after apply)
+ pi_cloud_instance_id = (known after apply)
+ pi_replication_enabled = (known after apply)
+ pi_volume_name = "datavg"
+ pi_volume_pool = (known after apply)
+ pi_volume_shareable = true
+ pi_volume_size = 20
+ pi_volume_type = "tier1"
+ primary_role = (known after apply)
+ replication_sites = (known after apply)
+ replication_status = (known after apply)
+ replication_type = (known after apply)
+ volume_id = (known after apply)
+ volume_status = (known after apply)
+ wwn = (known after apply)
}

# ibm_pi_volume_attach.datavg_lpar1_attach will be created

+ resource "ibm_pi_volume_attach" "datavg_lpar1_attach" {
+ id = (known after apply)
+ pi_cloud_instance_id = (known after apply)
+ pi_instance_id = (known after apply)
+ pi_volume_id = (known after apply)
+ status = (known after apply)
}

# ibm_pi_workspace.redbook_ws will be created

+ resource "ibm_pi_workspace" "redbook_ws" {
+ crn = (known after apply)
+ id = (known after apply)
+ pi_datacenter = "mad02"

62 Power Virtual Server for AIX and Linux

 + pi_name = "Redbook TF workspace"
+ pi_plan = "public"
+ pi_resource_group_id = "f7f08119179c4b35ad9c72dfff457XXX"
+ pi_workspace_details = (known after apply)
}

Plan: 7 to add, 0 to change, 0 to destroy.

Changes to Outputs:
+ images = (known after apply)

Do you want to perform these actions?

Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.

Enter a value: yes

ibm_pi_workspace.redbook_ws: Creating...
ibm_pi_workspace.redbook_ws: Still creating... [10s elapsed]
ibm_pi_workspace.redbook_ws: Still creating... [20s elapsed]
ibm_pi_workspace.redbook_ws: Still creating... [30s elapsed]
ibm_pi_workspace.redbook_ws: Still creating... [40s elapsed]
ibm_pi_workspace.redbook_ws: Still creating... [50s elapsed]
ibm_pi_workspace.redbook_ws: Still creating... [1m0s elapsed]
ibm_pi_workspace.redbook_ws: Still creating... [1m10s elapsed]
ibm_pi_workspace.redbook_ws: Creation complete after 1m18s
[id=ea90a4b0-69b7-4373-8377-b511afe96XXX]
data.ibm_pi_catalog_images.pvs_catalog: Reading...
ibm_pi_volume.datavg: Creating...
ibm_pi_key.rb_ssh: Creating...
ibm_pi_network.rbnet: Creating...
data.ibm_pi_catalog_images.pvs_catalog: Read complete after 7s [id=2024-11-13
17:05:38.835317 +0000 UTC]
ibm_pi_image.aix730201: Creating...
ibm_pi_key.rb_ssh: Creation complete after 7s
[id=ea90a4b0-69b7-4373-8377-b511afe96XXX/redbook_ssh_key]
ibm_pi_network.rbnet: Still creating... [10s elapsed]
ibm_pi_volume.datavg: Still creating... [10s elapsed]
ibm_pi_image.aix730201: Still creating... [10s elapsed]
ibm_pi_volume.datavg: Creation complete after 18s
[id=ea90a4b0-69b7-4373-8377-b511afe96XXX/13b4cf31-3c47-483c-be98-fedb56bbfXXX]
ibm_pi_network.rbnet: Still creating... [20s elapsed]
ibm_pi_image.aix730201: Still creating... [20s elapsed]
ibm_pi_network.rbnet: Still creating... [30s elapsed]
ibm_pi_image.aix730201: Creation complete after 24s
[id=ea90a4b0-69b7-4373-8377-b511afe96XXX/0e98da89-3aa4-43af-bc44-73014e6d0XXX]
ibm_pi_network.rbnet: Still creating... [40s elapsed]
ibm_pi_network.rbnet: Creation complete after 41s
[id=ea90a4b0-69b7-4373-8377-b511afe96XXX/62cad1b2-a009-49a3-93c1-be72114b1XXX]
ibm_pi_instance.lpar: Creating...
ibm_pi_instance.lpar: Still creating... [10s elapsed]
ibm_pi_instance.lpar: Still creating... [20s elapsed]
ibm_pi_instance.lpar: Still creating... [30s elapsed]
ibm_pi_instance.lpar: Still creating... [40s elapsed]
ibm_pi_instance.lpar: Still creating... [50s elapsed]
ibm_pi_instance.lpar: Still creating... [1m0s elapsed]

Chapter 2. Deployment options 63

 ibm_pi_instance.lpar: Still creating... [1m10s elapsed]
ibm_pi_instance.lpar: Still creating... [1m20s elapsed]
ibm_pi_instance.lpar: Still creating... [1m30s elapsed]
ibm_pi_instance.lpar: Still creating... [1m40s elapsed]
ibm_pi_instance.lpar: Still creating... [1m50s elapsed]
ibm_pi_instance.lpar: Still creating... [2m0s elapsed]
ibm_pi_instance.lpar: Still creating... [2m10s elapsed]
ibm_pi_instance.lpar: Still creating... [2m20s elapsed]
ibm_pi_instance.lpar: Still creating... [2m30s elapsed]
ibm_pi_instance.lpar: Still creating... [2m40s elapsed]
ibm_pi_instance.lpar: Still creating... [2m50s elapsed]
ibm_pi_instance.lpar: Still creating... [3m0s elapsed]
ibm_pi_instance.lpar: Still creating... [3m10s elapsed]
ibm_pi_instance.lpar: Still creating... [3m20s elapsed]
ibm_pi_instance.lpar: Still creating... [3m30s elapsed]
ibm_pi_instance.lpar: Still creating... [3m40s elapsed]
ibm_pi_instance.lpar: Still creating... [3m50s elapsed]
ibm_pi_instance.lpar: Still creating... [4m0s elapsed]
ibm_pi_instance.lpar: Still creating... [4m10s elapsed]
ibm_pi_instance.lpar: Still creating... [4m20s elapsed]
ibm_pi_instance.lpar: Still creating... [4m30s elapsed]
ibm_pi_instance.lpar: Still creating... [4m40s elapsed]
ibm_pi_instance.lpar: Creation complete after 4m42s
[id=ea90a4b0-69b7-4373-8377-b511afe96XXX/68498355-36e4-4368-8a06-830e9a614XXX]
ibm_pi_volume_attach.datavg_lpar1_attach: Creating...
ibm_pi_volume_attach.datavg_lpar1_attach: Still creating... [10s elapsed]
ibm_pi_volume_attach.datavg_lpar1_attach: Creation complete after 13s
[id=ea90a4b0-69b7-4373-8377-b511afe96XXX/68498355-36e4-4368-8a06-830e9a614XXX/13b4
cf31-3c47-483c-be98-fedb56bbfXXX]

Apply complete! Resources: 7 added, 0 changed, 0 destroyed.

10.After couple of minutes, your new Power Virtual Server is ready to work. The only
additional consideration is that your LPAR is not configured right now. You can use Ansible
to configure it or you can specify provision in the Terraform code as shown in
Example 2-29.

Example 2-29 Terraform local provisioner for AIX in Power Virtual Server
resource "null_resource" "configure_lpar" {
connection {
host = ibm_pi_instance.lpar.pi_network[0].ip_address
user = "root"
private_key = file("~/.ssh/id_rsa")
agent = "false"
timeout = "10m"
}

provisioner "remote-exec" {
inline = [
"set -v",
"set -o errexit",
"cfgmgr",
"mkvg -S -y datavg hdisk1",
"mklv -t jfs2 -c1 -ex -y lvdata datavg 10G",

64 Power Virtual Server for AIX and Linux

 "crfs -v jfs2 -d lvdata -m /data -A yes -p rw -a agblksize=4096 -a
logname=INLINE",
"mount /data",
"chfs -a size=1G /tmp",
"chfs -a size=2G /opt",
"chfs -a size=2G /var",
"/usr/opt/perl5/bin/lwp-download
https://public.dhe.ibm.com/aix/freeSoftware/aixtoolbox/ezinstall/ppc/dnf_aixtoolbo
x.sh",
"chmod +x dnf_aixtoolbox.sh",
"./dnf_aixtoolbox.sh -y",
"/opt/freeware/bin/dnf -y update",
"ln -s /opt/freeware/bin/dnf /usr/bin/dnf",
"echo 'done!'",
]
}
}

If you don’t need the environment, you can always delete it completely using the same code
you created and the Terraform destroy command as shown in Example 2-30.

Example 2-30 Destroying provisioned Power Virtual Server resources

$ terraform destroy -var-file=redbook.tfvars
data.ibm_resource_group.cloudrg: Reading...
data.ibm_resource_group.cloudrg: Read complete after 2s
[id=f7f08119179c4b35ad9c72dfff457XXX]
ibm_pi_workspace.redbook_ws: Refreshing state...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX]
ibm_pi_volume.datavg: Refreshing state...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/a1f3873c-d73e-45ec-bc3e-842fb662eXXX]
ibm_pi_key.rb_ssh: Refreshing state...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/redbook_ssh_key]
data.ibm_pi_catalog_images.pvs_catalog: Reading...
ibm_pi_network.rbnet: Refreshing state...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/35c1c463-f3b9-4051-8405-c11c2351aXXX]
data.ibm_pi_catalog_images.pvs_catalog: Read complete after 5s [id=2024-11-13
17:42:16.803127 +0000 UTC]
ibm_pi_image.aix730201: Refreshing state...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/feee1111-0fff-4ec6-a883-568147164XXX]
ibm_pi_instance.lpar: Refreshing state...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/357056d0-9515-4739-9bca-9b7afd5cdXXX]
ibm_pi_volume_attach.datavg_lpar1_attach: Refreshing state...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/357056d0-9515-4739-9bca-9b7afd5cdXXX/a1f3
873c-d73e-45ec-bc3e-842fb662eXXX]
null_resource.configure_lpar: Refreshing state... [id=8272293421693923XXX]

Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated
with the following symbols:
- destroy

Terraform will perform the following actions:

# ibm_pi_image.aix730201 will be destroyed

Chapter 2. Deployment options 65

 - resource "ibm_pi_image" "aix730201" {
- id =
"6ef5e0d8-5484-46b6-bc45-686734976XXX/feee1111-0fff-4ec6-a883-568147164XXX" ->
null
- image_id = "feee1111-0fff-4ec6-a883-568147164XXX" -> null
- pi_cloud_instance_id = "6ef5e0d8-5484-46b6-bc45-686734976XXX" -> null
- pi_image_bucket_access = "public" -> null
- pi_image_id = "0da299aa-cc52-42c4-b6a4-74300e064XXX" -> null
- pi_image_name = "7300-02-01" -> null
}

# ibm_pi_instance.lpar will be destroyed

- resource "ibm_pi_instance" "lpar" {
- fault = {} -> null
- health_status = "OK" -> null
- id =
"6ef5e0d8-5484-46b6-bc45-686734976fee/357056d0-9515-4739-9bca-9b7afd5cd442" ->
null
- instance_id = "357056d0-9515-4739-9bca-9b7afd5cd442" ->
null
- max_memory = 16 -> null
- max_processors = 2 -> null
- max_virtual_cores = 5 -> null
- min_memory = 2 -> null
- min_processors = 0.25 -> null
- min_virtual_cores = 1 -> null
- operating_system = "AIX 7.3, 7300-02-01-2346" -> null
- os_type = "aix" -> null
- pi_cloud_instance_id = "6ef5e0d8-5484-46b6-bc45-686734976XXX" ->
null
- pi_health_status = "WARNING" -> null
- pi_image_id = "4703b92b-9415-4630-b188-f32d81f7aXXX" ->
null
- pi_instance_name = "tfrb-aix" -> null
- pi_key_pair_name = "redbook_ssh_key" -> null
- pi_license_repository_capacity = 0 -> null
- pi_memory = 2 -> null
- pi_pin_policy = "none" -> null
- pi_proc_type = "shared" -> null
- pi_processors = 0.25 -> null
- pi_replicants = 1 -> null
- pi_replication_policy = "none" -> null
- pi_replication_scheme = "suffix" -> null
- pi_storage_pool = "General-Flash-56" -> null
- pi_storage_pool_affinity = true -> null
- pi_storage_type = "tier1" -> null
- pi_sys_type = "s1022" -> null
- pi_virtual_cores_assigned = 1 -> null
- pin_policy = "none" -> null
- progress = 0 -> null
- status = "ACTIVE" -> null
# (3 unchanged attributes hidden)

- pi_network {
- ip_address = "172.16.100.102" -> null

66 Power Virtual Server for AIX and Linux

 - mac_address = "fa:38:93:e0:d7:21" -> null
- network_id = "35c1c463-f3b9-4051-8405-c11c2351aXXX" -> null
- network_name = "redbook-net" -> null
- type = "fixed" -> null
# (1 unchanged attribute hidden)
}
}

# ibm_pi_key.rb_ssh will be destroyed

- resource "ibm_pi_key" "rb_ssh" {
- creation_date = "2024-11-13T17:23:22.634Z" -> null
- id =
"6ef5e0d8-5484-46b6-bc45-686734976XXX/redbook_ssh_key" -> null
- key = <<-EOT
ssh-rsa AAAA [email protected]
EOT -> null
- name = "redbook_ssh_key" -> null
- pi_cloud_instance_id = "6ef5e0d8-5484-46b6-bc45-686734976XXX" -> null
- pi_key_name = "redbook_ssh_key" -> null
- pi_ssh_key = <<-EOT
ssh-rsa AAAA [email protected]
EOT -> null
}

# ibm_pi_network.rbnet will be destroyed

- resource "ibm_pi_network" "rbnet" {
- id =
"6ef5e0d8-5484-46b6-bc45-686734976XXX/35c1c463-f3b9-4051-8405-c11c2351aXXX" ->
null
- network_id = "35c1c463-f3b9-4051-8405-c11c2351aXXX" -> null
- pi_cidr = "172.16.100.0/24" -> null
- pi_cloud_instance_id = "6ef5e0d8-5484-46b6-bc45-686734976XXX" -> null
- pi_dns = [
- "8.8.8.8",
] -> null
- pi_gateway = "172.16.100.1" -> null
- pi_network_jumbo = false -> null
- pi_network_mtu = 1450 -> null
- pi_network_name = "redbook-net" -> null
- pi_network_type = "vlan" -> null
- vlan_id = 1522 -> null
# (1 unchanged attribute hidden)

- pi_ipaddress_range {
- pi_ending_ip_address = "172.16.100.250" -> null
- pi_starting_ip_address = "172.16.100.10" -> null
}
}

# ibm_pi_volume.datavg will be destroyed

- resource "ibm_pi_volume" "datavg" {
- auxiliary = false -> null
- id =
"6ef5e0d8-5484-46b6-bc45-686734976XXX/a1f3873c-d73e-45ec-bc3e-842fb662eXXX" ->
null

Chapter 2. Deployment options 67

 - io_throttle_rate = "200 iops" -> null
- pi_cloud_instance_id = "6ef5e0d8-5484-46b6-bc45-686734976XXX" -> null
- pi_replication_enabled = false -> null
- pi_volume_name = "datavg" -> null
- pi_volume_pool = "General-Flash-56" -> null
- pi_volume_shareable = true -> null
- pi_volume_size = 20 -> null
- pi_volume_type = "tier1" -> null
- replication_sites = [] -> null
- volume_id = "a1f3873c-d73e-45ec-bc3e-842fb662eXXX" -> null
- volume_status = "in-use" -> null
- wwn = "60050768138102602800000000003563" -> null
# (8 unchanged attributes hidden)
}

# ibm_pi_volume_attach.datavg_lpar1_attach will be destroyed

- resource "ibm_pi_volume_attach" "datavg_lpar1_attach" {
- id =
"6ef5e0d8-5484-46b6-bc45-686734976XXX/357056d0-9515-4739-9bca-9b7afd5cdXXX/a1f3873
c-d73e-45ec-bc3e-842fb662eXXX" -> null
- pi_cloud_instance_id = "6ef5e0d8-5484-46b6-bc45-686734976XXX" -> null
- pi_instance_id = "357056d0-9515-4739-9bca-9b7afd5cdXXX" -> null
- pi_volume_id = "a1f3873c-d73e-45ec-bc3e-842fb662eXXX" -> null
- status = "in-use" -> null
}

# ibm_pi_workspace.redbook_ws will be destroyed

- resource "ibm_pi_workspace" "redbook_ws" {
- crn =
"crn:v1:bluemix:public:power-iaas:mad02:a/f3862ec10c674ec49a6977ace0685XXX:6ef5e0d
8-5484-46b6-bc45-686734976XXX::" -> null
- id = "6ef5e0d8-5484-46b6-bc45-686734976XXX" -> null
- pi_datacenter = "mad02" -> null
- pi_name = "Redbook TF workspace" -> null
- pi_plan = "public" -> null
- pi_resource_group_id = "f7f08119179c4b35ad9c72dfff457XXX" -> null
- pi_user_tags = [] -> null
- pi_workspace_details = {} -> null
}

# null_resource.configure_lpar will be destroyed

- resource "null_resource" "configure_lpar" {
- id = "8272293421693923596" -> null
}

Plan: 0 to add, 0 to change, 9 to destroy.

Changes to Outputs:
- images = 2 -> null

Do you really want to destroy all resources?

Terraform will destroy all your managed infrastructure, as shown above.
There is no undo. Only 'yes' will be accepted to confirm.

Enter a value: yes

68 Power Virtual Server for AIX and Linux

null_resource.configure_lpar: Destroying... [id=8272293421693923596]
null_resource.configure_lpar: Destruction complete after 0s
ibm_pi_volume_attach.datavg_lpar1_attach: Destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/357056d0-9515-4739-9bca-9b7afd5cdXXX/a1f3
873c-d73e-45ec-bc3e-842fb662eXXX]
ibm_pi_volume_attach.datavg_lpar1_attach: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/35...X/a1f3873c-d73e-45ec-bc3e-842fb662eX
XX, 10s elapsed]
ibm_pi_volume_attach.datavg_lpar1_attach: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/35...X/a1f3873c-d73e-45ec-bc3e-842fb662eX
XX, 20s elapsed]
ibm_pi_volume_attach.datavg_lpar1_attach: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/35...X/a1f3873c-d73e-45ec-bc3e-842fb662eX
XX, 30s elapsed]
ibm_pi_volume_attach.datavg_lpar1_attach: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/35...X/a1f3873c-d73e-45ec-bc3e-842fb662eX
XX, 40s elapsed]
ibm_pi_volume_attach.datavg_lpar1_attach: Destruction complete after 42s
ibm_pi_volume.datavg: Destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/a1f3873c-d73e-45ec-bc3e-842fb662eXXX]
ibm_pi_instance.lpar: Destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/357056d0-9515-4739-9bca-9b7afd5cdXXX]
ibm_pi_volume.datavg: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/a1f3873c-d73e-45ec-bc3e-842fb662eXXX, 10s
elapsed]
ibm_pi_instance.lpar: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/357056d0-9515-4739-9bca-9b7afd5cdXXX, 10s
elapsed]
ibm_pi_volume.datavg: Destruction complete after 11s
ibm_pi_instance.lpar: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/357056d0-9515-4739-9bca-9b7afd5cdXXX, 20s
elapsed]
ibm_pi_instance.lpar: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/357056d0-9515-4739-9bca-9b7afd5cdXXX, 30s
elapsed]
ibm_pi_instance.lpar: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/357056d0-9515-4739-9bca-9b7afd5cdXXX, 40s
elapsed]
ibm_pi_instance.lpar: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/357056d0-9515-4739-9bca-9b7afd5cdXXX, 50s
elapsed]
ibm_pi_instance.lpar: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/357056d0-9515-4739-9bca-9b7afd5cdXXX,
1m0s elapsed]
ibm_pi_instance.lpar: Destruction complete after 1m2s
ibm_pi_network.rbnet: Destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/35c1c463-f3b9-4051-8405-c11c2351aXXX]
ibm_pi_key.rb_ssh: Destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/redbook_ssh_key]
ibm_pi_network.pubnet: Destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/8450cad3-b3b5-4e60-a22f-6c833301dXXX]
ibm_pi_image.aix730201: Destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/feee1111-0fff-4ec6-a883-568147164XXX]
ibm_pi_key.rb_ssh: Destruction complete after 0s

Chapter 2. Deployment options 69

 ibm_pi_image.aix730201: Destruction complete after 0s
ibm_pi_network.rbnet: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/35c1c463-f3b9-4051-8405-c11c2351aXXX, 10s
elapsed]
ibm_pi_network.pubnet: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX/8450cad3-b3b5-4e60-a22f-6c833301dXXX, 10s
elapsed]
ibm_pi_network.pubnet: Destruction complete after 12s
ibm_pi_network.rbnet: Destruction complete after 17s
ibm_pi_workspace.redbook_ws: Destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX]
ibm_pi_workspace.redbook_ws: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX, 10s elapsed]
ibm_pi_workspace.redbook_ws: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX, 20s elapsed]
ibm_pi_workspace.redbook_ws: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX, 30s elapsed]
ibm_pi_workspace.redbook_ws: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX, 40s elapsed]
ibm_pi_workspace.redbook_ws: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX, 50s elapsed]
ibm_pi_workspace.redbook_ws: Still destroying...
[id=6ef5e0d8-5484-46b6-bc45-686734976XXX, 1m0s elapsed]
ibm_pi_workspace.redbook_ws: Destruction complete after 1m2s

Destroy complete! Resources: 9 destroyed.

2.7 Deployment with Ansible

If you want to automate your Power Virtual Server deployment, but don’t use Terraform, you
can use Ansible to achieve the same goal. Using Ansible for Power Virtual Server
deployments is described in Section 5.2 of the Redbook “Using Ansible for Automation in IBM
Power Environments, SG24-8551. You can find many other examples there working with IBM
Power Virtual Server resources.

2.8 Deployment with IBM Power Virtual Server API

If the automation tool of your choice doesn’t support IBM Power Virtual Server, you can
implement automated deployment using IBM Power Virtual Server API. The API is
documented on the site https://cloud.ibm.com/apidocs/power-cloud.

The site is interactive and if you choose an API call, you will not only get the documentation
on the call but also examples using the API call with curl. Using these examples and the
documentation you can automate Power Virtual Server deployments in a script or in any
programming language which supports REST API calls.

70 Power Virtual Server for AIX and Linux

 3

Chapter 3. IBM Power Virtual Server in the

IBM Cloud network
In this chapter, we will cover the following topics:
 “IBM Power Virtual Server Virtual Private Network (VPN) Connectivity”
 “Power Virtual Server Network Overview”
 “Power Virtual Server network connection options”
 “Private Connection using SSL, Jump Server, and Direct Link Connect”
 “Private Connection using Megaport and Direct Link Connect”
 “Multi-COLO, Multi-region Private Connection using Megaport”
 “Multi-COLO Private Connection using IBM Cloud Backbone”

© Copyright IBM Corp. 2025. 71

3.1 IBM Power Virtual Server Virtual Private Network (VPN)
Connectivity
A Virtual Private Network (VPN) is a secure network connection established over public or
shared networks such as the internet. VPNs use encryption technologies to ensure that all
data transmitted between endpoints remains confidential and protected from unauthorized
access. The role of a VPN is to create a “virtual tunnel” that securely connects remote
devices, networks, or users to a central server or system, as though they are part of a private
network.

In the context of IBM Power Virtual Server, a VPN allows organizations to securely extend
their on-premises environments into the cloud. This secure connectivity enables users to
access applications, data, and resources hosted on Power Virtual Servers without exposing
them to the public internet. By leveraging VPNs, organizations ensure secure communication
between their on-prem infrastructure and the IBM cloud-based Power Virtual Server, while
maintaining data integrity and confidentiality.

3.1.1 Importance of VPN in Cloud-Based Environments Like Power Virtual

Server
In cloud-based environments like IBM Power Virtual Server, security is paramount as
sensitive data and business-critical workloads are often hosted in these environments. The
key benefits of using a VPN in such scenarios include:
 Secure Remote Access
VPNs provide secure access to Power Virtual Servers for remote users, whether they are
accessing the environment from another office, from home, or while traveling. This
ensures that authorized personnel can safely access the server without risking data
breaches.
 Data Encryption
VPNs encrypt data transmitted over public or shared networks, ensuring that any data
exchanged between the on-premises data center and the Power Virtual Server remains
protected. This is critical for sensitive data and compliance with regulatory requirements.
 Cost Efficiency
Using a VPN to extend a private network to IBM Power Virtual Servers eliminates the need
for dedicated physical connections or leased lines, reducing costs while maintaining a high
level of security.
 Seamless Cloud Integration
VPNs make it easier to integrate existing on-premises networks with cloud environments
like Power Virtual Server. This enables hybrid cloud setups, where part of the
infrastructure remains on-premises while leveraging the scalability and flexibility of the
cloud for additional workloads.
 Traffic Isolation
VPNs allow organizations to isolate their traffic from the broader internet. This isolation
reduces the risk of exposure to cyber-attacks, such as distributed denial-of-service
(DDoS) attacks, malware, or unauthorized access.

72 Power Virtual Server for AIX and Linux

  Flexibility and Scalability
A VPN provides flexible access for teams and users spread across multiple locations. It
also allows organizations to scale their infrastructure as needed without compromising
security, making it ideal for growing businesses or evolving IT needs.

In summary, the use of VPNs in IBM Power Virtual Server environments enhances security,
facilitates seamless integration with existing on-premises systems, and provides a
cost-effective and scalable solution for connecting resources across disparate locations. As
more organizations adopt hybrid cloud models, VPNs continue to play a critical role in
ensuring secure, encrypted, and reliable network connectivity.

3.1.2 Setting up a VPN in Power Virtual Server

Setting up a Virtual Private Network (VPN) in IBM Power Virtual Server requires configuring a
secure communication link between your on-premises infrastructure or remote users and the
IBM cloud environment. This involves selecting the appropriate VPN technology, configuring
the necessary network components, and ensuring that security measures such as encryption
and authentication are in place. Below is a step-by-step guide to setting up a VPN in Power
Virtual Server:

Choosing the Right VPN Technology

IBM Power Virtual Server supports several VPN technologies, including:
 SSL VPN (Secure Sockets Layer VPN)
SSL VPNs are often used for remote access. They allow secure connections from users'
devices through web browsers, without the need for client-side software.
 IPsec VPN (Internet Protocol Security VPN)
IPsec VPNs are widely used for site-to-site or network-to-network connections. They offer
robust encryption and authentication, ensuring secure communication between your
on-premises environment and the Power Virtual Server.

The choice of VPN technology depends on your specific use case:

 As SSL VPN is ideal for users needing remote access from various locations, such as
employees working from home.
 An IPsec VPN is more suitable for connecting entire networks, such as establishing a
permanent, secure link between an on-premises data center and the Power Virtual Server
cloud.

Prerequisites for VPN Setup

Before setting up the VPN, ensure you have the following:
 VPN Gateway
A VPN gateway is required on both the on-premises network and the IBM Power Virtual
Server. This could be a physical device (e.g., firewall, router) or a virtual appliance
configured to handle VPN traffic.
 Security Credentials
Ensure you have the necessary encryption keys, certificates, and authentication methods
(such as username/password or multi-factor authentication) ready for configuring the VPN.

Chapter 3. IBM Power Virtual Server in the IBM Cloud network 73

  Network Addresses
Define the IP addresses and subnets for both your on-premises network and the Power
Virtual Server environment. This will help establish routing rules to ensure traffic flows
securely through the VPN.

Create a VPN Gateway in IBM Power Virtual Server

To create a VPN, follow the following steps:
1. Access the IBM Cloud Console.
a. Log in to the IBM Cloud Console and navigate to the Power Systems Virtual Server
dashboard.
b. From here, locate and select the Power Virtual Server instance you want to connect via
VPN.
2. Set Up a VPN Gateway.
a. Under the Networking tab of your Power Virtual Server instance, configure a VPN
gateway. The VPN gateway serves as the entry and exit point for encrypted traffic
between your on-premises environment and the IBM Power Virtual Server.
b. IBM provides built-in VPN gateway options or allows you to deploy a third-party VPN
gateway appliance from vendors such as Cisco, Palo Alto, or Fortinet, depending on
your organization's requirements.
3. Configure the Gateway.
a. Select the type of VPN connection (SSL or IPsec).
b. Assign the public IP address of the VPN gateway on the IBM Cloud side, which will be
used for secure communication with the on-premises gateway.
c. Define the VPN connection parameters, including encryption protocols (e.g., AES),
hashing algorithms (e.g., SHA-256), and key exchange methods (e.g., IKEv2).

Configuring the On-Premises VPN Gateway

Next, configure the VPN gateway in your on-premises environment to establish a connection
to the IBM Power Virtual Server VPN gateway.
4. Connect to Your On-Premises VPN Gateway:
a. Access the VPN gateway appliance (this could be a firewall, router, or dedicated VPN
appliance like Cisco ASA, Fortinet, etc.).
b. Use the VPN gateway's management console to configure a new VPN connection.
c. Define the IBM Cloud Gateway as a Peer:
d. Enter the public IP address of the IBM Power Virtual Server VPN gateway as the peer
address.
e. Configure encryption settings that match the configuration set in the IBM Cloud
gateway (e.g., AES-256 for encryption, SHA-256 for hashing).
5. Define Routing and Access Policies:
a. Define routing policies for the VPN connection. This includes specifying which IP
addresses and subnets from your on-premises network can access resources in IBM
Power Virtual Server and vice versa.
b. You can also configure access policies to control which types of traffic (e.g., HTTP,
SSH) can traverse the VPN connection.

74 Power Virtual Server for AIX and Linux

6. Authentication and Security:
a. Establish authentication methods between the two gateways. This could involve using
pre-shared keys (PSKs) or digital certificates for mutual authentication.
b. Ensure that encryption settings (e.g., IKE Phase 1 and Phase 2 parameters) are
configured identically on both the on-premises and IBM Cloud sides to ensure
compatibility.

Testing the VPN Connection

Once the configuration is complete on both sides, it's crucial to test the VPN connection to
ensure it is functioning correctly.
7. Ping Test
Initiate a ping test from an on-premises machine to a server or resource hosted in the IBM
Power Virtual Server environment. This helps verify basic connectivity through the VPN.
8. Application Testing
Test access to applications hosted in Power Virtual Server (e.g., web servers, databases)
to ensure data transmission is secure and performs as expected.
9. Monitoring and Logs
a. Check the VPN logs on both the on-premises gateway and the IBM Cloud gateway for
any connection errors or dropped packets.
b. Monitor the latency, bandwidth usage, and encryption health to ensure optimal
performance.

Advanced VPN Configurations

Once the VPN is up and running, you can enhance its functionality by configuring additional
features:
 Failover and High Availability
Set up redundant VPN gateways in both your on-premises and IBM Cloud environments to
ensure continuous connectivity even if one gateway fails.
 Traffic Shaping and QoS (Quality of Service)
Implement traffic prioritization policies to ensure mission-critical data (e.g., real-time
applications) receives the highest priority through the VPN tunnel.
 Logging and Auditing
Enable detailed logging and auditing features to monitor the health and security of the
VPN, ensuring compliance with security standards and regulations.

Security Considerations
VPNs are a critical security layer in cloud environments, and it's important to maintain strong
security measures:
 Encryption Strength
Ensure strong encryption standards (e.g., AES-256) to prevent data interception or
tampering.
 Key Management
Regularly rotate encryption keys and use secure key storage mechanisms to prevent
unauthorized access.

Chapter 3. IBM Power Virtual Server in the IBM Cloud network 75

  Access Controls
Limit VPN access to only authorized users and devices, using multi-factor authentication
(MFA) where possible.
 Firewall Rules
Apply strict firewall rules at both the on-premises and cloud gateways to limit access to
only necessary services and ports.

Setting up a VPN in IBM Power Virtual Server is an essential step for securing
communications between your cloud environment and on-premises infrastructure or remote
users. By following the outlined steps-choosing the right VPN technology, configuring
gateways, establishing security protocols, and testing connections-organizations can create a
secure and reliable network to support their cloud workloads. With strong encryption, access
controls, and monitoring, VPNs provide a robust solution for protecting sensitive data in the
cloud.

Security Aspects
Securing a Virtual Private Network (VPN) in IBM Power Virtual Server is vital for ensuring
data confidentiality, integrity, and compliance with security standards. Robust security
measures help protect the data traveling between on-premises systems and cloud
environments. Here's an in-depth look at two key areas: encryption protocols and access
control with traffic filtering features.

Encryption protocols used in Power Virtual Server VPN

Encryption protocols are fundamental to VPN security, as they protect data in transit by
rendering it unreadable to unauthorized entities. IBM Power Virtual Server VPN employs
two primary encryption protocols depending on the type of VPN: SSL/TLS and IPsec.
 SSL/TLS (Secure Sockets Layer/Transport Layer Security):
SSL/TLS is primarily used for SSL VPNs, which are commonly deployed for remote
access. It provides a secure connection that users can access through web browsers,
making it highly accessible and eliminating the need for specialized client software.
SSL/TLS encryption uses asymmetric encryption to establish a secure handshake,
followed by symmetric encryption for efficient data transfer. The process begins with a
client and server exchange of digital certificates to authenticate each other, followed by an
encryption key exchange.
SSL/TLS provides the following security benefits:
• Data Confidentiality: SSL/TLS encryption ensures that data between the client and
server is encrypted and protected from eavesdropping or tampering.
• Authentication: SSL VPN requires digital certificates, allowing only authorized
clients to establish a connection.
• Data Integrity: TLS includes message authentication codes (MACs) that verify the
data has not been altered during transmission.
 IPsec (Internet Protocol Security):
IPsec is often used in site-to-site VPNs to create a secure connection between entire
networks, such as an on-premises data center and IBM Power Virtual Server. IPsec
operates at the network layer and secures IP packets through two primary modes:
– Transport Mode: Encrypts the data portion of each packet, leaving the header intact.
This mode is useful for internal networks.
– Tunnel Mode: Encrypts both the header and the data, ideal for communication over
public networks.

76 Power Virtual Server for AIX and Linux

IPsec provides the following security benefits:
– Encryption Standards: IPsec supports strong encryption algorithms, such as AES-256,
to secure data. It also employs hashing algorithms like SHA-256 for message integrity.
– Authentication: IPsec uses mutual authentication methods, such as preshared keys
(PSK) or digital certificates, to validate both endpoints before data is transmitted.
– Key Management: IPsec relies on Internet Key Exchange (IKE) protocols (e.g., IKEv2)
to establish and maintain secure communication channels, providing automatic key
exchange and re-keying to prevent session hijacking.

Access control and traffic filtering features.

Access control and traffic filtering further enhance security by regulating who and what can
access resources over the VPN, ensuring that only authorized users and approved traffic are
permitted.
 Access control mechanisms
Here are some examples of access control mechanisms:
– Multi-Factor Authentication (MFA): In IBM Power Virtual Server, VPN connections often
require multi-factor authentication to add an extra layer of security. MFA combines
something users know (password), something they have (authentication app or token),
or something they are (biometric verification).
– Role-Based Access Control (RBAC): RBAC assigns users specific roles with defined
permissions, restricting access to sensitive resources based on user roles. For
example, a developer might have VPN access to development environments, while an
administrator has access to production systems.
– Conditional Access Policies: Conditional access policies can enforce specific
conditions before granting access, such as requiring access from a trusted IP range,
enforcing device compliance checks, or ensuring the connection originates from a
secure network location.
 Traffic filtering features
Here are some examples of traffic filtering features
– Firewall Rules: Power Virtual Server VPN gateways are configured with firewalls that
define the types of traffic allowed or denied over the VPN connection. Rules specify
permitted IP addresses, subnets, and protocols, ensuring only authorized connections
pass through the VPN.
– Network Segmentation: Traffic filtering is often used to segment traffic, allowing specific
departments or functions access to only relevant resources. For instance, a finance
team may access the finance server but have no access to engineering systems.
– Intrusion Detection and Prevention Systems (IDPS): Advanced VPN setups
incorporate IDPS to monitor traffic patterns for unusual activity or potential threats. If
suspicious activity is detected, the system can alert administrators or automatically
block traffic to prevent potential security breaches.
 Encryption and traffic filtering policies
Here are some examples of encryption and traffic filtering policies
– Protocol Filtering: Some VPNs are configured to allow only specific protocols over the
connection, like HTTPS or SSH, further reducing the risk of unauthorized access.
– Application-Level Filtering: VPNs with application filtering capabilities can limit traffic to
specific applications, ensuring that only approved applications transmit data over the
VPN.

Chapter 3. IBM Power Virtual Server in the IBM Cloud network 77

 – Logging and Auditing: Traffic logs provide a record of all activities passing through the
VPN, helping administrators monitor usage patterns, detect unauthorized access, and
identify potential security risks.

Quality of Service (QoS) for Traffic Prioritization:

VPNs can include QoS settings that prioritize traffic based on application criticality. For
instance, time-sensitive applications like VoIP can receive priority over standard data
transmissions, ensuring a high-quality user experience without compromising security.

Summary
In IBM Power Virtual Server, encryption protocols like SSL/TLS and IPsec ensure secure and
private data transmission across networks, protecting against unauthorized access. Access
control mechanisms and traffic filtering features provide granular control over user and data
access, enhancing security further. By combining these advanced security aspects,
organizations using IBM Power Virtual Server VPNs can establish robust, secure connections
that protect sensitive data and maintain regulatory compliance.

3.2 Power Virtual Server Network Overview

The network architecture in IBM Power Virtual Server is designed to integrate seamlessly with
both IBM's cloud services and customer on-premises environments, supporting flexible,
secure, and high-performance connections. Understanding the network structure and
components in Power Virtual Server is essential for establishing reliable connectivity,
managing resources, and ensuring data security across cloud and on-premises
infrastructure.

The networking framework within IBM Power Virtual Server is engineered to support both
scalability and security, catering to hybrid cloud needs and enabling seamless integration of
on-premises resources with cloud-hosted workloads. This overview explains the basic
network architecture, how it supports AIX and Linux workloads, and the structure of public
and private network options.

3.2.1 Basic Network Architecture in Power Virtual Server

The network architecture in IBM Power Virtual Server is built upon a Virtual Private Cloud
(VPC), which is a virtualized, logically isolated environment within IBM Cloud. This
VPC-based design provides users with an environment that simulates a private on-premises
network, but with the flexibility and scalability of cloud resources.

Key components of the basic network architecture include:

 VPC Structure
A VPC allows for logical separation and segmentation of resources through subnets and
VLANs, enabling users to control traffic flow, access levels, and connectivity options.
 Subnets and IP Addressing
Subnets within the VPC provide the foundation for organizing resources. Each subnet,
with its own unique IP address range, allows users to create logically isolated sections
within the VPC. Subnets can be configured as public (internet-facing) or private
(internal-only), giving users control over network exposure.

78 Power Virtual Server for AIX and Linux

  Gateways
Power Virtual Server's architecture includes various gateways-such as Edge Gateways for
internet and VPN access, Direct Link for private, high-speed connections, and Transit
Gateway for multi-region networking-to support both public and private connectivity needs.

The architecture also incorporates security groups and access control lists (ACLs) to regulate
traffic. Security groups provide virtual firewalls at the instance level, while ACLs enforce rules
at the subnet level, controlling inbound and outbound access.

How the network is designed to integrate both AIX and Linux workloads
IBM Power Virtual Server offers seamless integration of both AIX and Linux workloads by
using advanced visualization and networking technologies that are optimized for IBM Power
Systems. The network design is built to support heterogeneous environments, where AIX and
Linux workloads can coexist, communicate, and share resources without compatibility issues.

Virtualized Network Layers

Power Virtual Server uses virtual LANs (VLANs) and subnets within the VPC to segregate
AIX and Linux workloads while ensuring they remain accessible to each other if needed. Each
workload can operate within its assigned VLAN, where traffic is securely segmented, but
cross-communication between VLANs can be configured to allow AIX and Linux instances to
interact as necessary.

Network compatibility
IBM Power Virtual Server utilizes virtual switches to handle traffic between different virtual
machines (VMs) and bare-metal instances running AIX or Linux. This virtual switch-based
approach ensures that AIX-specific network configurations and Linux-based networking
services can coexist without conflict. A Virtual I/O Server (VIOS) is often employed to manage
and route network traffic across AIX and Linux workloads, offering a consistent and
high-performance interface between the network and different operating systems.

Unified Management and Security

IBM provides unified management tools to oversee both AIX and Linux environments within
the same VPC, making it easier to manage policies, monitor performance, and implement
security measures across the entire network. Security controls such as ACLs, firewalls, and
VPN configurations apply consistently across AIX and Linux workloads, enabling
administrators to implement and enforce policies that protect both types of workloads under a
unified security model.

3.2.2 Public versus private networks

Power Virtual Server offers both public and private network options to suit various workload
requirements and security levels.

Public networks are internet-accessible and are suitable for workloads that require external
access, such as web applications, APIs, or resources that users access from outside the
VPC. Security groups and firewall rules are essential for regulating traffic to public networks,
ensuring that only approved IPs and protocols can access public resources. Common
protocols (HTTP, HTTPS, SSH) are configured with strict access control policies. Public IP
addresses are assigned to resources requiring internet connectivity. These resources are
typically placed in a public subnet, where they remain accessible to authorized users from the
internet.

Private networks are isolated from the internet, ensuring data security by restricting access to
internal applications and sensitive workloads. Private networks are ideal for hosting

Chapter 3. IBM Power Virtual Server in the IBM Cloud network 79

 databases, internal applications, and other resources that do not require external access.
Private networks are accessible only through secure connections, such as a VPN or Direct
Link. VPN enables encrypted access for remote users, while Direct Link provides dedicated,
high-speed, private connectivity between on-premises systems and the Power Virtual Server
environment. Resources on a private network are assigned private IP addresses. These IPs
are not exposed to the public internet and are reachable only through the VPC or approved
network connections.

Traffic Segmentation and Isolation

Power Virtual Server supports network segmentation through subnets, VLANs, and security
groups to isolate traffic and regulate access based on business needs. For example,
databases and applications can reside on private subnets, with application servers on a
public subnet that is protected by firewalls and access controls.

Inter-subnet Communication
While private subnets are isolated, they can still communicate with other subnets within the
VPC, allowing applications on public and private subnets to interact without compromising
security.

Hybrid Connectivity Options

Public and private networks in Power Virtual Server can be integrated with on-premises
environments, providing a hybrid cloud solution. Secure connectivity options such as IPsec
VPN, Direct Link, and Transit Gateway enable traffic routing between IBM Power Virtual
Server, on-premises networks, and even multi-cloud environments.

Public networks allow workloads to interact with the internet for data collection, customer
access, or integration with third-party services. Private networks, on the other hand, serve as
secure environments for handling sensitive data, running internal applications, and
supporting compliance requirements.

Summary
The networking infrastructure of IBM Power Virtual Server offers a flexible and secure
foundation to support AIX and Linux workloads in a cloud environment. Using VPCs, VLANs,
subnets, and various gateways, Power Virtual Server enables customers to configure public
and private networks, manage connectivity, and apply consistent security controls across
different operating systems. This design allows organizations to integrate their on-premises
and cloud environments seamlessly, create secure and high-performing network
configurations, and maintain the flexibility to adapt to evolving business and security needs.

3.2.3 Network Components

IBM Power Virtual Server offers a range of network components that work together to create
a flexible, scalable, and secure environment for managing cloud workloads. These
components are designed to support complex networking needs in hybrid and multi-cloud
environments, enabling seamless integration with on-premises infrastructure. Key
components include the Virtual Private Cloud (VPC), VLANs, subnets, and gateways, as well
as specialized connectivity options like Direct Link Connect, Megaport, and Edge Gateway.

Virtual Private Cloud (VPC)

A Virtual Private Cloud (VPC) in IBM Power Virtual Server is a logically isolated network that
functions as a private segment within IBM's public cloud infrastructure. It enables users to
deploy resources within an environment that mimics a traditional data center, providing strong

80 Power Virtual Server for AIX and Linux

security controls, flexibility, and management. The VPC provides the following features and
benefits:
 Isolation
Each VPC is isolated from others, which provides security and separation for workloads,
even within a shared public cloud infrastructure.
 Network Customization
Users can define IP ranges, create subnets, and configure routing to customize the
network to their specific requirements.
 Security
VPCs allow for strict control over inbound and outbound traffic through security groups
and access control lists (ACLs), which apply rules to control access to instances within the
VPC.

VLANs (Virtual Local Area Networks)

VLANs are virtualized segments within the VPC that help segregate network traffic and
control access to resources based on their function, purpose, or user group. Each VLAN
represents a broadcast domain and enables network isolation within the VPC. VLANs provide
the following benefits:
 Network Segmentation
VLANs can be used to group related resources (e.g., application servers, databases)
together while isolating them from other network traffic. This enhances security by
preventing unwanted access to sensitive data.
 Traffic Control
VLANs simplify traffic routing and filtering within the VPC, allowing administrators to
control data flow between different segments based on their security and performance
requirements.
 Enhanced Security
By creating isolated VLANs for different teams or workloads, organizations can ensure
that sensitive traffic is separated from less sensitive or public-facing services.

Subnets
Subnets divide the IP address space within a VPC into smaller, more manageable segments.
Each subnet has its own IP address range and can be configured as either public or private,
depending on the workload's access needs.

Public subnets are connected to the internet through a public IP, making them suitable for
resources like web servers or APIs that need to be publicly accessible. Public subnets require
additional security controls, such as firewalls and access control lists (ACLs), to protect
exposed resources.

Private subnets are not accessible from the internet and are used for internal resources like
databases or application servers. Private subnets can only be accessed through secure
channels, such as VPN or Direct Link, enhancing security by limiting exposure. Subnets
provide the following benefits”
 Simplified Traffic Management
By grouping resources into subnets, administrators can apply consistent security and
routing policies.

Chapter 3. IBM Power Virtual Server in the IBM Cloud network 81

  Enhanced Security
Public and private subnet configurations provide flexibility in controlling network access
based on workload sensitivity and compliance requirements.

Gateways
Gateways are critical components that manage data flow between different network
environments, including on-premises networks, IBM Cloud services, and the internet. Power
Virtual Server supports various gateways to accommodate diverse connectivity needs. There
are multiple types of gateways:
 Internet Gateway
Manages outbound traffic from VPCs to the internet, enabling internet access for
resources on public subnets.
 Edge Gateway
Provides secure VPN and Direct Link connections to link on-premises resources with IBM
Cloud environments. The Edge Gateway facilitates secure communication between
isolated networks and allows businesses to deploy hybrid environments effectively.
 Transit Gateway
Used for connecting multiple VPCs and regions, the Transit Gateway simplifies network
management by centralizing traffic routing across hybrid and multi-region deployments.

3.2.4 Direct Link Connect, Megaport, and Edge Gateway

This section discusses different network connectivity options provided in Power Virtual
Server.

Direct Link Connect

Direct Link Connect is IBM's dedicated private connectivity solution that provides high-speed,
low-latency connections between on-premises data centers and IBM Power Virtual Server
environments. By bypassing the public internet, Direct Link Connect offers a secure,
consistent network path, which is ideal for latency-sensitive or data-intensive applications.
Direct Link Connect has the following use cases and benefits:
 Hybrid Cloud Connectivity
Direct Link Connect is commonly used to bridge on-premises infrastructure with IBM
Cloud, facilitating hybrid cloud architectures where workloads can move between
environments seamlessly.
 Data Transfer Efficiency
With higher bandwidth and lower latency than standard internet connections, Direct Link
Connect supports efficient data migration and large-scale data transfers.
 Enhanced Security and Compliance:
As Direct Link Connect bypasses the public internet, it reduces exposure to potential cyber
threats, meeting regulatory and compliance needs for sensitive workloads.

Megaport
Megaport is a network-as-a-service provider that enables direct connectivity between IBM
Cloud (including Power Virtual Server) and other cloud providers, data centers, and
on-premises environments. By leveraging Megaport's software-defined network,
organizations can quickly establish private, high-speed connections to multiple cloud

82 Power Virtual Server for AIX and Linux

 providers and data centers without relying on traditional networking setups. Megaport has the
following Use Cases and Benefits:
 Multi-Cloud Connectivity:
Megaport allows users to connect to multiple cloud providers from a single location,
making it ideal for multi-cloud environments where workloads and data need to be
distributed across different platforms (e.g., IBM Cloud, AWS, Google Cloud).
 Flexible and Scalable Connectivity
With Megaport, users can easily adjust bandwidth as their network demands change,
providing a cost-effective, scalable solution for high-performance networking.
 Fast Deployment
Megaport's software-defined network allows for rapid provisioning, so organizations can
establish new connections quickly without long lead times associated with traditional
networking.

Edge Gateway
The Edge Gateway acts as a secure entry and exit point for traffic between IBM Power Virtual
Server and external networks, including on-premises systems and remote users. Edge
Gateway provides secure connections through IPsec VPN and Direct Link, enabling
organizations to build hybrid environments that bridge IBM Cloud and on-premises resources.
The Edge Gateway provides the following features and benefits:
 VPN Support
Edge Gateway can be configured to support IPsec VPNs, offering encrypted access
between remote users or external sites and Power Virtual Server resources. This makes
Edge Gateway ideal for securing remote access and protecting data in transit.
 Direct Link Integration
Edge Gateway works in tandem with Direct Link, offering an additional layer of security
and control over traffic flowing between on-premises and IBM Cloud environments.
 Centralized Security Management
Edge Gateway's role as the entry point for both VPN and Direct Link traffic allows
administrators to enforce security policies at a single, central location, simplifying network
management and enhancing security.

Summary
The network components within IBM Power Virtual Server-VPC, VLANs, subnets, gateways,
Direct Link Connect, Megaport, and Edge Gateway-are foundational to creating a secure,
flexible, and efficient networking environment. Together, these components enable
organizations to design scalable and secure network architectures that integrate seamlessly
with on-premises systems, support hybrid and multi-cloud deployments, and provide the
flexibility to manage both public and private workloads. By combining private connectivity
options, secure gateways, and network segmentation, IBM Power Virtual Server offers a
robust solution for managing complex cloud networking needs while maintaining high levels of
control and security.

3.3 Power Virtual Server network connection options

IBM Power Virtual Server offers versatile network scenarios tailored to accommodate a range
of business needs, from development and testing to production and multi-region
deployments. These network scenarios are designed to provide organizations with the

Chapter 3. IBM Power Virtual Server in the IBM Cloud network 83

 flexibility to configure their network environments according to specific requirements,
ensuring secure, scalable, and high-performance connectivity across on-premises, hybrid,
and multi-cloud infrastructures.

The network connectivity options in IBM Power Virtual Server are categorized broadly into:
 Non-production or proof-of-concept (POC) environments
 Production environments.

Each category supports a variety of network configurations and connectivity options, allowing
organizations to select the optimal setup based on factors such as data sensitivity,
compliance requirements, performance needs, and cost considerations.

Key Considerations in Choosing Network Scenarios

Organizations deploying workloads in IBM Power Virtual Server often face choices around
connectivity, data access, and security, making it important to choose the right network
scenario. Each scenario comes with different capabilities for data security, access control,
and performance:

Workload Sensitivity
Development, testing, and POC environments typically require flexibility and cost efficiency,
but production environments demand higher performance and enhanced security due to the
critical nature of the workloads.

Data Access and Compliance

Sensitive workloads, especially those in production, benefit from private, dedicated
connections (e.g., Direct Link, Megaport) that avoid public internet exposure, meeting
compliance requirements in regulated industries.

Network Performance and Latency

Certain applications, such as real-time data processing, require high-bandwidth, low-latency
connections. Production scenarios often rely on dedicated connectivity solutions to support
these demands.

Hybrid and Multi-Cloud Compatibility

Many organizations leverage hybrid setups, where on-premises data centers connect
securely to cloud environments. Multi-cloud scenarios, which involve connecting with other
cloud providers, are also increasingly popular, allowing businesses to diversify their cloud
strategies.

3.3.1 Importance of choosing the right network scenario based on workload

requirements
Selecting the appropriate network scenario is essential for optimizing resources, ensuring
performance, and meeting security and compliance requirements. Here's why it's important to
align network scenarios with workload needs:
 Performance and Latency Requirements
Production Workloads: Mission-critical applications, such as ERP systems, require
high-speed, low-latency connections to deliver consistent performance. Production
scenarios with dedicated connectivity, like Direct Link, meet these demands, providing
stable, high-bandwidth connections.

84 Power Virtual Server for AIX and Linux

 Non-Production Workloads: Development and testing environments don't typically require
high-performance connectivity. VPN connections provide a secure but lower-cost option,
ideal for non-production workloads where some latency is acceptable.
 Security and Compliance
Sensitive Workloads: Workloads handling confidential data or those subject to strict
regulatory compliance should use production network setups. These setups incorporate
enhanced security measures like dedicated connections (Direct Link) that minimize
exposure to the public internet, VPN encryption, and multi-layer firewalls.
Development Environments: Development or testing environments don't usually require
the same level of security. A non-production setup with VPN access allows developers to
access resources securely but without the higher costs associated with a production
environment.
 Cost Optimization
POC and Development: Choosing a non-production or POC scenario for testing and
development can significantly reduce costs by eliminating the need for dedicated
connections and high-performance infrastructure. VPN-based access offers flexibility and
cost savings, making it ideal for temporary or lower-priority workloads.
Production Scaling: For workloads that need to scale dynamically in production, a
production setup with dedicated resources ensures that performance is not compromised
as demands increase.
 Disaster Recovery and High Availability
Critical Applications: For organizations with stringent availability requirements,
multi-region and multi-COLO scenarios provide a reliable disaster recovery option. By
distributing workloads across regions and using IBM Transit Gateway, organizations can
ensure that critical applications remain available even in the event of a regional outage.
Cost Considerations: Multi-region setups offer valuable redundancy, but they also come at
a higher cost due to the need for additional infrastructure. Therefore, they should be
reserved for workloads that justify the investment in resilience and uptime.
 Hybrid and Multi-Cloud Flexibility
Hybrid Environments: Organizations that maintain a mix of on-premises and cloud
resources benefit from hybrid connectivity options. Production scenarios with Direct Link
or Edge Gateway support efficient hybrid setups, ensuring secure and consistent
connectivity between on-premises and cloud resources.
Multi-Cloud Strategies: For organizations leveraging multiple cloud providers, multi-region
and multi-COLO setups with Megaport or Transit Gateway facilitate seamless integration,
enabling flexibility, resilience, and avoiding vendor lock-in.

The choice of network scenario in IBM Power Virtual Server plays a crucial role in aligning
cloud resources with workload requirements. Production, non-production, and multi-region
setups each offer distinct advantages, from cost-efficiency in development environments to
high availability and performance in production. Selecting the right scenario based on factors
like workload sensitivity, performance needs, security, and budget ensures that organizations
can deploy their applications and data with the optimal balance of security, cost, and
resilience, meeting their operational and business goals effectively.

Chapter 3. IBM Power Virtual Server in the IBM Cloud network 85

3.3.2 Factors to consider when choosing a network design for your workload
The following areas should be analyzed when determining the best environment for each
workload, production or non-production.
 Workload Sensitivity:
– Applications involving sensitive or regulated data are best suited for production
scenarios, where strict security measures and compliance requirements can be met.
– For less critical workloads, such as testing and development, non-production
environments offer adequate security with flexibility and lower costs.
 Performance and Latency Requirements:
– Workloads with high-performance needs, like real-time data processing or
high-frequency transaction applications, benefit from production scenarios with
dedicated, low-latency connections.
– For testing and POC purposes, where some delay is acceptable, non-production
scenarios with VPN-based access provide sufficient performance at a lower cost.
 Cost Constraints:
– Non-production scenarios are cost-effective, making them suitable for teams with
budget constraints or for applications in the development phase.
– Production scenarios, though more costly, are essential for workloads that directly
impact business operations. Balancing cost against performance and reliability needs
is key when choosing between scenarios.
 Security and Compliance Requirements:
– Production environments offer enhanced security features that are critical for regulated
industries (e.g., healthcare, finance) or applications that handle sensitive information.
– Non-production environments have fewer security requirements, often meeting basic
standards sufficient for testing or sandbox use cases, making them suitable for
applications without strict compliance needs.
 Operational Uptime and Availability:
– If an application requires high availability with failover capabilities, a production
scenario with redundancy and multi-region configurations is recommended.
– Development and testing environments typically do not require high uptime, so
non-production scenarios with limited availability are more cost-effective.
 Scalability Needs:
– Production scenarios are designed to scale with business needs, supporting growth
and fluctuating demand. If a workload is expected to grow or if resource needs are
variable, a production environment is more suitable.
– Non-production environments are generally fixed in scale, serving temporary needs
like testing or POC deployments without extensive scalability options.
 Hybrid or Multi-Cloud Compatibility:
– For hybrid or multi-cloud architectures, production scenarios with direct, private
connectivity options (e.g., Direct Link, Megaport) ensure secure and efficient
communication between on-premises systems, IBM Cloud, and other cloud providers.
– Non-production environments can integrate with other clouds or on-prem systems but
typically through VPN connections, which are more suitable for experimentation than
long-term hybrid setups.

86 Power Virtual Server for AIX and Linux

 Choosing between non-production/POC and production network scenarios in IBM Power
Virtual Server depends on a thorough understanding of workload requirements, including
performance, security, cost, and scalability needs. Non-production scenarios offer flexibility
and cost savings, ideal for development and testing, while production environments provide
the robust infrastructure needed for business-critical applications. By carefully assessing
these factors, organizations can select the optimal network scenario that aligns with both
technical requirements and business goals, ensuring efficient resource utilization, data
security, and reliable performance.

3.3.3 Production, non-production, and proof-of-concept environments

The choice of technologies for network connectivity for production, non-production, and
proof-of-concept (POC) environments is often different because each environment has
different requirements. The key differences lie in the levels of isolation, redundancy,
performance requirements, and security measures.

A well-designed network strategy aligns with the specific needs and risks associated with
each environment.

Production Environment:
Production environments demand the highest levels of availability, performance, and security.
Connectivity is absolutely critical. Multiple redundant connections to the internet and within
the data center are essential. This often involves diverse network paths, multiple ISPs, and
redundant network devices (routers, switches, firewalls). Failover mechanisms should be
automatic and rapid. Sufficient bandwidth is crucial to handle peak traffic loads and ensure
low latency for critical applications. This may involve dedicated high-speed connections.
Robust security measures are paramount. This includes firewalls, intrusion
detection/prevention systems, network segmentation (VLANs), access control lists (ACLs),
and regular security audits. DMZs (demilitarized zones) are often used to isolate publicly
accessible servers. Comprehensive network monitoring and management tools are
necessary to proactively identify and resolve issues. Real-time alerts and performance
dashboards are crucial. QoS mechanisms prioritize critical traffic (e.g., database traffic,
VoIP) to ensure consistent performance even under heavy load.

Additional considerations
A production environment has additional considerations that differentiate it from other
environments. Specifically consider:
 Compliance
Industry-specific regulations (e.g., HIPAA, PCI DSS) may impose strict requirements on
network security and data protection.
 Disaster Recovery
Production environments need to have a disaster recovery plan to ensure that business
can continue in case of unanticipated outages or even planned outages. A well-defined
disaster recovery plan should include network connectivity considerations, such as
backup connections to a secondary data center.

Chapter 3. IBM Power Virtual Server in the IBM Cloud network 87

 Non-production (development, testing, staging) environments
Non-production environments require connectivity, but the demands are typically less
stringent than production. The focus is on functionality and testing rather than extreme
performance and availability.

Non-production environments should be logically isolated from the production network to

prevent accidental or malicious impact on live systems. This can be achieved through VLANs,
separate subnets, or even entirely separate physical networks. While not as critical as in
production, sufficient bandwidth is needed to support development and testing activities.
Security is still important, but the level of security may be less stringent than production.
However, care must be taken to prevent vulnerabilities in non-production from being exploited
to gain access to the production environment.

In general, the network architecture can be simpler than production, reducing complexity and
cost.

Additional considerations
For a non-production or testing environment, consider the following requirements:
 Data Masking
Sensitive data should be masked or anonymized in non-production environments to
protect privacy.
 Realistic Testing Environment
The network configuration should mimic the production environment as closely as possible
to ensure accurate testing.

Proof-of-Concept (POC) environments

POC environments have the least demanding connectivity requirements. The focus is on
demonstrating the feasibility of a new technology or solution. The network setup can be
minimal and tailored to the specific POC. Isolation from production is essential to prevent any
disruption to live systems. This can be achieved through a completely isolated network or a
virtual network. Security is less of a concern in a POC environment, but basic security
measures should still be in place.

Additional considerations
For a POC environment, consider the following requirements:
 Rapid Deployment
The network should be easy to set up and tear down.
 Cost-Effectiveness
Keep the cost of network infrastructure for POCs to a minimum.
 Focus on Functionality
The primary goal is to demonstrate functionality, not necessarily performance or
scalability.

88 Power Virtual Server for AIX and Linux

Summary
A network architecture needs to be developed keeping in mind the type of environment you
are servicing. Table 3-1 summarizes the different requirements for production,
non-production, and proof-of-concept environments.

Table 3-1 Network features for different environments

Feature Production Non-Production Proof-of-Concept

Availability Highest Medium Low

Performance Highest Medium Low

Security Highest Medium Low

Redundancy High Medium Low

Isolation Essential Essential Essential

Complexity High Medium Low

Cost High Medium Low

In conclusion, network connectivity should be carefully planned and implemented based on

the specific requirements of each environment. Production environments require the most
robust and secure network infrastructure, while non-production and POC environments can
have simpler and less expensive setups. Proper isolation between environments is crucial to
protect production systems from any accidental or malicious activity.

Non-production or proof-of-concept environments

Non-production and Proof-of-Concept POC scenarios are designed for development, testing,
and experimentation, providing a cost-effective and flexible environment to trial workloads
without the need for production-grade resources.

These scenarios typically use VPN-based connections, like SSL or IPsec VPNs, which
provide secure remote access while maintaining flexibility and cost efficiency. POC
environments may also integrate jump servers or intermediary network layers for added
security and control over remote access. Some example configurations are:
 SSL VPN with Jump Server
Enables secure access to a POC environment with minimal setup, allowing remote
developers to test applications in a simulated cloud setting.
 Direct Link for Limited Testing
In scenarios where low latency is beneficial but not critical, a limited Direct Link setup can
support POC testing.

These setups often use VPN-based connections (such as SSL or IPsec VPNs) for secure,
low-cost remote access. VPNs provide the necessary security for remote users and
developers accessing the environment but without the expense of dedicated links. It is
common for non-production environments to have a smaller budget than production
environments. They can be less costly to operate as they do not require the same level of
redundancy or high-performance infrastructure as production setups. The use of VPNs to
connect on-demand enables cost savings and provides flexibility.

A non-production setup might utilize a secure SSL VPN connection to allow remote
developers access to the test environment, often using a jump server for additional security
and network segregation.

Chapter 3. IBM Power Virtual Server in the IBM Cloud network 89

 Production scenarios
Production network scenarios are configured for high-performance, reliable connectivity, and
enhanced security. These setups are suitable for mission-critical applications requiring low
latency, high bandwidth, and strict data protection.

Production scenarios often rely on dedicated connectivity solutions like Direct Link or
Megaport to ensure secure, high-speed connections between on-premises environments and
the Power Virtual Server cloud. Multi-colocation (multi-COLO) and multi-region production
setups enable distributed workloads across IBM Cloud regions, supporting redundancy, high
availability, and failover capabilities. Some example configurations are:
 Direct Link with Edge Gateway
Provides a private, dedicated connection between on-premises and IBM Cloud, suitable
for applications that require consistent performance and high security.
 Multi-COLO and Multi-Region with Megaport
For global operations, this scenario connects multiple co-location facilities across regions,
offering low-latency access and resiliency through redundant, geographically dispersed
links.

Production setups usually include enhanced security features, such as multi-layered firewalls,
VPNs, and stringent access controls. These measures protect sensitive data and support
compliance with industry standards and regulations.

A production network might include a Direct Link connection with an Edge Gateway, creating
a secure and high-performance path between on-premises infrastructure and IBM Power
Virtual Server resources.

3.3.4 Hybrid and multi-cloud environments

Hybrid and multi-cloud scenarios are increasingly common, allowing organizations to
leverage IBM Power Virtual Server alongside other cloud providers. This setup offers flexibility
and resilience while enabling companies to avoid vendor lock-in.

IBM's partnerships with connectivity providers like Megaport, along with IBM Cloud's Transit
Gateway, support easy integration with other clouds, enabling data flow across platforms and
regions. Some example configurations are:
 Transit Gateway with Multi-Cloud Access:
Facilitates seamless connectivity across IBM Cloud regions, other cloud platforms, and
on-premises environments, simplifying network management in multi-cloud architectures.
 Direct Link and Multi-Cloud with Megaport:
Combines secure, dedicated connections to IBM Cloud with multi-cloud connectivity,
supporting complex, multi-environment workloads.

Multi-region and multi-colocation setups

Multi-region and multi-colocation (multi-COLO) setups are designed for organizations that
need geographic redundancy, failover capabilities, and high availability across multiple
locations. These setups are ideal for distributed applications and critical workloads that
demand resiliency and data replication across IBM Cloud regions. Multi-region setups
typically use IBM Transit Gateway for efficient routing across multiple VPCs and regions. This
configuration centralizes network management, enabling smooth data flow across regions
and facilitating high availability and disaster recovery.

90 Power Virtual Server for AIX and Linux

 Multi-region deployments provide resilience against data center outages or regional failures,
allowing critical applications to remain accessible. By distributing workloads across regions,
organizations can achieve both load balancing and data locality, improving latency for global
users.

A multi-region setup might use Transit Gateway to link VPCs across IBM Cloud regions,
coupled with Megaport to establish private, dedicated connections to other cloud providers,
enabling a robust multi-cloud architecture.

3.3.5 Summary of network environments

IBM Power Virtual Server provides various network scenarios tailored to meet different
organizational needs, primarily divided into non-production/proof-of-concept (POC) and
production scenarios. Each of these scenarios offers unique benefits, suited to specific
requirements around performance, security, and cost. Understanding the key differences
between these scenarios and the factors involved in choosing the right one is essential for
optimizing cloud resources and aligning network configurations with workload demands.

Key Differences Between Non-Production/POC and Production

Scenarios
This section summarizes the key differences between production and non-production
environments when designing your network.

Purpose and Use Case

Non-Production/POC environments are designed for development, testing, and trial
applications where flexibility and cost efficiency are prioritized over performance and
availability. Non-production environments are often temporary or experimental, allowing
teams to prototype, test features, and experiment with new configurations without high
resource expenditure.

Production scenarios are for mission-critical applications and high-priority workloads that
require robust performance, low latency, and enhanced security. Production environments are
running core business functions that need high availability – transaction processing, customer
databases, and enterprise applications.

Connectivity Options
Connectivity in non-production scenarios often relies on VPN connections (e.g., SSL or IPsec
VPN), which are cost-effective and secure enough for development or testing environments
but may not support high-bandwidth or low-latency requirements. VPN access provides
flexibility for remote access, making it easy for developers to connect as needed without
requiring costly dedicated links.

Production scenarios typically employ dedicated, high-performance connectivity options like

Direct Link or Megaport, which provide high bandwidth, low latency, and private connections
that bypass the public internet. This setup is ideal for ensuring stable performance and
meeting compliance needs, particularly for data-sensitive applications.

Performance and latency

Performance is not as critical in non-production environments, where some latency is
acceptable, and high-speed access is less essential. For this reason, VPN connections are
often sufficient for test and development needs.

Chapter 3. IBM Power Virtual Server in the IBM Cloud network 91

 Production scenarios demand high performance with low latency to support business-critical
workloads that depend on consistent and responsive service. Dedicated connections like
Direct Link or Megaport ensure stable and fast data transmission, making them essential for
applications with strict performance requirements.

Security and compliance

While security is still important, non-production setups prioritize flexibility and cost-efficiency.
Basic encryption via VPNs and security group configurations are generally sufficient for
securing access to development environments.

Production scenarios require robust security measures to protect sensitive data, often
including dedicated private connections (Direct Link, Megaport) that minimize exposure to the
public internet. Multi-layered security controls, such as firewalls, access control lists (ACLs),
and stringent identity management policies, help ensure compliance with industry regulations
and protect critical business data.

Cost structure
Non-production scenarios are more cost-effective, using VPN connections and shared
resources that reduce expenses. These environments are ideal for minimizing costs during
the development and testing phases, where resource demands are lower.

Production environments typically incur higher costs due to the need for dedicated,
high-performance infrastructure, including private connections, enhanced security
configurations, and redundancy features. However, these costs are justified by the need to
maintain reliability, performance, and security for business-critical applications.

Scalability and availability

Non-production scenarios have limited scalability and are not designed for high availability, as
they are typically temporary environments that support testing rather than live workloads.

Production environments are built with scalability and availability in mind, often incorporating
redundant network paths and high-availability configurations to support business continuity.
Production setups may also include multi-region or multi-colocation (multi-COLO)
configurations for failover and disaster recovery.

3.4 Private Connection using SSL, Jump Server, and Direct

Link Connect
In IBM Power Virtual Server, establishing private connections in non-production or
proof-of-concept (POC) environments is crucial for securely accessing resources and testing
new applications under controlled, secure conditions. A private connection that integrates
SSL-based VPN, jump servers, and Direct Link Connect can provide a robust solution for
organizations seeking secure, isolated network access for development and testing purposes.
This setup combines encrypted VPN communication with a gateway server and
high-performance connectivity options to support flexible and secure access to cloud
resources.

92 Power Virtual Server for AIX and Linux

How SSL-Based VPN Can Be Used for Secure Connections in POC
Environments
SSL-based VPNs (Secure Sockets Layer Virtual Private Networks) are widely used in
non-production environments to create secure, encrypted communication tunnels over the
public internet. SSL VPNs provide developers, testers, and remote teams with a
straightforward and cost-effective method to access POC environments securely.

Encrypted Data Transmission

SSL VPNs use encryption protocols like TLS (Transport Layer Security) to protect data
transmitted between a client device and the IBM Power Virtual Server environment. This
ensures that sensitive data remains secure while in transit, preventing unauthorized access or
data interception by external threats.

By using SSL/TLS encryption, data integrity and confidentiality are maintained, making SSL
VPNs suitable for POC environments where secure access is necessary but full-scale,
dedicated connectivity is not required.

Ease of Deployment and Accessibility

One of the key advantages of SSL VPNs is their accessibility through standard web browsers,
eliminating the need for specialized client software. This allows team members to quickly
connect to the POC environment from various devices with minimal setup.

SSL VPNs can be configured to provide remote access to specific subnets or VLANs within
the POC environment, ensuring that only approved users can access designated resources.
This helps isolate test environments while facilitating remote development and testing.

Use Cases in POC Scenarios

SSL VPNs enable developers to connect securely to test environments from anywhere,
supporting collaboration and development efforts without needing to be on-site.

QA teams can use SSL VPNs to conduct testing and debugging sessions, securely accessing
applications and services to validate performance and functionality.

Even in a non-production environment, safeguarding data during trials is essential, and SSL
VPNs provide a reliable way to ensure secure access.

The Role of Jump Servers in Isolated Environments

A jump server (or jump box) acts as an intermediary between users and the network
resources they are trying to access. It is a critical security measure for managing access to
isolated environments like POC setups, enhancing security and control while enabling
connections through trusted, monitored channels.

Access Control and Network Segmentation

A jump server functions as a crucial point for accessing internal resources within a POC
environment. Users connect to the jump server first, which then grants them access to the
target systems within the isolated network. By using a jump server, organizations can restrict
direct access to POC resources, ensuring that only authorized personnel can connect
through the gateway. This minimizes the risk of unauthorized access and reduces the attack
surface.

Enhanced Security and Monitoring

Jump servers add an additional layer of security by acting as a barrier between the public
network and the POC environment. This means that only authenticated users who pass
through the jump server can access the internal network, creating a buffer that protects

Chapter 3. IBM Power Virtual Server in the IBM Cloud network 93

 critical resources. Activities conducted on or through a jump server can be monitored and
logged, providing organizations with a clear audit trail of who accessed the POC environment
and what actions were performed. This is essential for identifying potential security issues
and ensuring compliance with security policies. Jump servers often support advanced
authentication mechanisms, including MFA, to ensure that only verified users gain access to
the POC environment.

Isolation and Resource Protection

In POC environments, maintaining network isolation is key to preventing disruptions to
production systems and protecting sensitive data. Jump servers facilitate this by allowing
controlled access without direct exposure of the POC environment to public-facing
connections. The jump server acts as the first line of defense, allowing administrators to
enforce strict access policies and safeguard network resources from potential threats.

Integration with Direct Link Connect

Direct Link Connect complements the use of SSL-based VPNs and jump servers by providing
a high-speed, low-latency, private connection between on-premises infrastructure and the
IBM Power Virtual Server environment. This is particularly valuable for POC environments
that require reliable and secure data transfer without the fluctuations associated with public
internet connections.

Secure, High-Performance Connectivity

Direct Link Connect ensures that data travels through a dedicated path, bypassing the public
internet and reducing the risk of data interception or latency issues. This is especially
important when testing applications that simulate production-like conditions and require
consistent performance. Direct Link Connect facilitates seamless communication between
on-premises data centers and POC setups in IBM Cloud, enabling developers and testers to
work with data stored locally and in the cloud with minimal delay.

Scalable and Reliable

Direct Link Connect offers scalable bandwidth to match the specific needs of a POC project.
This flexibility allows teams to adjust connectivity based on project phases, ensuring that
performance requirements are met without unnecessary expenses. Using Direct Link
Connect in conjunction with SSL VPNs and jump servers ensures a stable and secure
environment for rigorous POC testing, enabling organizations to validate how their solutions
will perform under production-like conditions.

Private connection using IPsec VPN, Direct Link Connect, and Edge
Gateway
IPsec (Internet Protocol Security) is a robust protocol suite used to establish secure tunnels
for data transmission between on-premises infrastructure and cloud environments like IBM
Power Virtual Server. Setting up an IPsec VPN involves several key steps to ensure a secure
and reliable connection.

Setting up an IPsec VPN

This section presents the setup process for an IPsec VPN.
1. Pre-Configuration Requirements:
a. Determine the internal IP address ranges (subnets) for both the on-premises network
and the cloud environment.
b. Ensure that both the on-premises and cloud environments have VPN gateway devices
that support IPsec (e.g., firewalls or dedicated VPN appliances).

94 Power Virtual Server for AIX and Linux

 c. Verify that the VPN gateways on both ends have public IP addresses to facilitate the
connection.
2. Configure the On-Premises VPN Gateway:
a. Log in to the management console of the on-premises VPN gateway (e.g., Cisco ASA,
Fortinet, or other supported devices).
b. Create a New VPN Connection:
i. Define the peer IP address (the public IP of the IBM Power Virtual Server VPN
gateway).
ii. Set the VPN type to IPsec and specify the encryption standards (e.g., AES-256)
and hashing algorithms (e.g., SHA-256) for data integrity.
c. Define Authentication:
Use pre-shared keys (PSK) or digital certificates for mutual authentication between the
on-premises gateway and the cloud gateways.
d. Configure IKE Policies:
i. Set up IKE Phase 1 parameters (e.g., key exchange method, Diffie-Hellman group,
lifetime).
ii. Configure IKE Phase 2 parameters for the actual data tunnel, specifying encryption
algorithms, perfect forward secrecy, and tunnel lifetime.
3. Configure the IBM Power Virtual Server VPN Gateway:
a. Access the IBM Cloud Console: Navigate to the Power Systems Virtual Server
instance and access the Networking section.
b. Set Up the VPN Gateway:
i. Deploy a VPN gateway if one is not already configured.
ii. Specify the IPsec configuration matching the on-premises gateway (e.g., encryption
algorithms, authentication methods).
c. Define Routing Policies:
Create route tables that direct traffic between the on-premises subnets and the cloud
environment through the VPN tunnel.
4. Configure Security Policies:
Apply rules for inbound and outbound traffic to ensure that only authorized traffic passes
through the VPN.
5. Test the VPN Connection:
a. Run ping tests from the on-premises environment to cloud-based resources to verify
connectivity.
b. Test access to critical applications and data flows to ensure they are transmitted
securely and without interruption.
c. Check the VPN logs on both the on-premises and cloud gateways for any errors or
dropped packets to troubleshoot initial connectivity issues.
6. Enable Monitoring and Maintenance:
a. Set up alerts for VPN status changes or connectivity issues to ensure continuous
uptime.
b. Implement key rotation policies to enhance security and maintain robust encryption.

Chapter 3. IBM Power Virtual Server in the IBM Cloud network 95

 Integration with Direct Link Connect and Edge Gateway for enhanced
connectivity
Direct Link Connect and Edge Gateway can be integrated with an IPsec VPN setup to create
a more comprehensive and reliable networking solution. This combination supports
enhanced connectivity and ensures high performance for hybrid and multi-cloud
environments.

Integration with Direct Link Connect

Direct Link Connect offers a dedicated, private pathway between on-premises infrastructure
and the IBM Power Virtual Server environment. This bypasses the public internet, ensuring
lower latency, higher bandwidth, and increased security for data transfers. Direct Link
Connect is Ideal for scenarios where secure, high-volume data transfer is needed between
on-premises systems and the cloud environment.

To integrate Direct Link Connect with IPsec VPN initiate a Direct Link Connect service
through the IBM Cloud Console and associate it with the existing VPN gateway. Configure
routing tables to ensure that traffic intended for the cloud environment is directed through
Direct Link Connect, providing a seamless path for data flows.

While Direct Link Connect offers a secure private connection, maintaining an IPsec VPN as a
backup can provide redundancy. This ensures that in the event of an issue with the private
link, the VPN can handle traffic as a failover.

Integration with Edge Gateway

Edge Gateway serves as the connection point for managing secure access to the IBM Power
Virtual Server environment. It supports IPsec VPNs and Direct Link connections, creating a
cohesive, secure entry point for hybrid deployments. Edge Gateway can manage traffic
routing, VPN connections, and enforce security policies across different networks.

To Integrate Edge Gateway with IPsec VPN set up the Edge Gateway in the IBM Power
Virtual Server environment, configuring it to act as the endpoint for the IPsec VPN. Integrate
the Edge Gateway with Direct Link Connect to ensure that traffic can be routed privately and
securely without exposing data to public networks.

Apply security policies to filter traffic and define which data flows are allowed through the VPN
and Direct Link. For enhanced connectivity, configure the Edge Gateway to switch between
IPsec VPN and Direct Link based on network conditions. This ensures that data can continue
flowing securely even if one connection experiences an issue.

Test the connection to ensure that the Edge Gateway correctly switches between Direct Link
Connect and IPsec VPN under test conditions to verify redundancy. Monitor performance and
track data flow performance through the integrated setup using monitoring tools to assess
bandwidth, latency, and packet integrity.

Benefits of Integration
Combining Direct Link Connect and Edge Gateway with your IPsec VPN provides the
following benefits:
 Improved Security
Combining IPsec VPN with Direct Link Connect and Edge Gateway provides multiple
layers of security for data transmissions, protecting against external threats and
unauthorized access.

96 Power Virtual Server for AIX and Linux

  High Availability
The integration ensures that connectivity remains robust even in the face of potential
disruptions. The Edge Gateway can automatically redirect traffic through the IPsec VPN if
Direct Link Connect experiences issues, maintaining uptime.
 Optimized Performance
Direct Link Connect offers higher bandwidth and lower latency than traditional VPNs,
making the integrated solution well-suited for data-intensive applications that need reliable
and fast communication between environments.

3.5 Private Connection using Megaport and Direct Link

Connect
Megaport and Direct Link Connect together form a powerful combination for setting up
high-performance, secure private connections between on-premises infrastructure and IBM
Power Virtual Server environments. This integration offers businesses an optimized way to
connect their data centers and cloud resources with robust, low-latency, and high-bandwidth
pathways that bypass the public internet.

3.5.1 Setting Up High-Performance Private Connections Using Megaport

Services
Megaport is a global Network-as-a-Service (NaaS) provider that allows organizations to
create direct, scalable private connections to multiple cloud service providers, data centers,
and internet exchange points. By leveraging a software-defined network (SDN), Megaport
provides on-demand connectivity, ensuring a flexible and cost-effective alternative to
traditional leased lines.

Megaport enables customers to connect their on-premises data centers to the IBM Cloud
through private, virtual cross-connects that integrate seamlessly with Direct Link Connect.

Steps for Setting Up a Private Connection

This section discusses the process to setting up a connection with Megaport Services.
1. Sign Up with Megaport
Register for a Megaport account and set up a profile to gain access to their connectivity
services.
2. Provision a Virtual Cross-Connect (VXC)
From the Megaport portal, create a VXC to the nearest Megaport Point of Presence (PoP)
that connects to the IBM Cloud. Select bandwidth options based on workload
requirements. Bandwidth can range from as low as 1 Gbps to as high as 100 Gbps,
depending on the needs of the business.
3. Connect to Direct Link:
Establish the connection between the Megaport VXC and Direct Link Connect. This
integration ensures a high-speed, private link that extends from the on-premises
infrastructure to IBM Power Virtual Server.
Verify the configuration settings, including IP addressing and routing protocols, to ensure
seamless data flow.

Chapter 3. IBM Power Virtual Server in the IBM Cloud network 97

 4. Configure Routing and Access Policies:
Implement routing rules that direct traffic between on-premises networks and the IBM
Cloud. Configure BGP (Border Gateway Protocol) for dynamic routing and route
exchange.
Define access policies and security rules to control which subnets and services are
accessible through the connection.
5. Test and Monitor the Connection:
Run tests to verify connectivity and measure latency and throughput to confirm the
performance meets expectations. Use network monitoring tools to track the status of the
connection, ensuring reliability and identifying any potential performance issues.

3.5.2 Benefits of Connecting Through Megaport and Direct Link Connect in

Production
Combining Megaport services with Direct Link Connect provides a reliable high-performance
network connection to your IBM Power Virtual Server instances bringing the following
benefits:
1. High Performance and Low Latency
Connecting through Megaport and Direct Link Connect provides a dedicated data path that
bypasses the public internet, resulting in consistent low-latency and high-bandwidth
connections. This is essential for production environments that require real-time data
processing and minimal delay.
The combination allows businesses to achieve seamless data flow between their
on-premises systems and cloud-based IBM Power Virtual Server, supporting high-demand
applications like enterprise resource planning (ERP), data analytics, and high-frequency
trading.
2. Scalability and Flexibility
Megaport's SDN technology allows organizations to scale bandwidth up or down quickly
based on changing workload requirements. This flexibility is particularly beneficial for
production environments that experience fluctuating data transfer needs or sudden spikes
in demand.
Megaport's network enables connections to multiple cloud service providers from the
same platform. Businesses that use a multi-cloud strategy can extend their production
workloads across different cloud environments without needing separate connections for
each provider.
3. Enhanced Security:
The private nature of Megaport and Direct Link Connect ensures that data remains
protected from potential cyber threats associated with public internet usage. This setup is
ideal for industries handling sensitive data, such as finance, healthcare, and government,
where data integrity and confidentiality are critical.
Integrated Security Policies: The integration supports the application of robust security
measures, such as IP filtering, encryption, and access controls, to maintain a high-security
standard for production data transfers.
4. Reliable Redundancy and High Availability:
For mission-critical applications, businesses can configure redundant pathways using both
Megaport and Direct Link Connect to provide failover capabilities. This ensures that
production environments remain operational even in the event of a primary connection
failure.

98 Power Virtual Server for AIX and Linux

 Megaport's extensive network footprint allows businesses to establish connectivity with
IBM Cloud from multiple geographic locations. This facilitates high availability and disaster
recovery plans, ensuring that production systems are resilient and capable of maintaining
uptime during regional disruptions.
5. Simplified Management and Control:
Using Megaport's intuitive portal, organizations can easily manage their connections,
monitor usage, and adjust configurations as needed. The integration with IBM Cloud
simplifies the management of cross-cloud and hybrid network setups, providing unified
oversight.
Compared to traditional leased line solutions, Megaport and Direct Link Connect provide
cost-effective connectivity options that can be tailored to specific bandwidth and usage
requirements, optimizing expenses while ensuring production performance.

3.6 Multi-COLO, Multi-region Private Connection using

Megaport
Multi-COLO (multi-colocation) and multi-region private connections are essential for
organizations looking to achieve high availability, data redundancy, and optimal performance
across multiple data centers and cloud regions. Using Megaport as a Network-as-a-Service
(NaaS) provider, businesses can build a flexible and scalable network that spans different
colocation facilities and cloud regions, enabling seamless communication and data transfer.
This type of setup is ideal for global operations, enterprises with distributed workloads, and
scenarios that require robust disaster recovery plans.

3.6.1 Building Multi-Region, Multi-Colocation Connectivity Using Megaport

Megaport acts as a bridge between multiple data centers, cloud providers, and colocation
facilities by leveraging a software-defined network (SDN) that provides on-demand,
high-speed private connections. With Megaport, organizations can link multiple colocation
sites to IBM Power Virtual Server and other cloud services, creating a network architecture
that spans various geographic locations.

Within the Megaport SDN you create Virtual Cross-Connects (VXCs) to connect between
sites. VXCs are Layer 2 Ethernet circuits providing private, flexible, and on-demand
connections between any of the locations on the Megaport network with 1 Mbps to 100 Gbps
of capacity. Megaport's VXCs are key to creating point-to-point and multi-point connectivity
across different colocation facilities and cloud regions. These virtual connections can be
provisioned and managed through Megaport's platform, offering flexibility and scalability.

Steps for Building Multi-COLO, Multi-Region Connectivity

Consider the following when setting up Megaport connectivity for multiple data centers:
1. Provision Connections at Each Colocation Facility
Identify and establish connections at each colocation facility where the business has
infrastructure. This involves provisioning a Megaport-enabled connection at each location,
which acts as an access point to Megaport's SDN.
2. Set Up VXCs
Use Megaport's portal to create VXCs that link these colocation facilities to cloud
providers such as IBM Power Virtual Server. Define the bandwidth and latency
requirements for each VXC based on workload needs.

Chapter 3. IBM Power Virtual Server in the IBM Cloud network 99

 3. Configure Cloud Connectivity
Establish direct connections to IBM Cloud regions using Direct Link Connect integrated
with Megaport. This setup ensures that data flows between on-premises systems and
cloud resources with high speed and security.
4. Multi-Region Linking
Deploy VXCs that connect different cloud regions (e.g., data centers in Europe linked to
IBM Cloud regions in North America or Asia-Pacific). This ensures that applications can
run seamlessly across regions with minimal latency.
5. Centralized Management
Manage all connections through Megaport's user-friendly portal. This interface allows IT
teams to monitor traffic, adjust bandwidth, and create or remove VXCs as needed. This
centralized approach simplifies network administration and scalability.

3.6.2 Ensuring Network Redundancy and High Availability

High availability and network redundancy are critical for maintaining business continuity,
especially for production workloads that cannot afford downtime. Multi-COLO and
multi-region setups using Megaport provide several strategies to achieve these goals:
1. Redundant Connectivity Paths:
Establish multiple VXCs between colocation facilities and cloud regions to ensure that if
one path fails, traffic can be rerouted through another. This approach supports seamless
failover and minimizes the impact of network disruptions.
Connect to multiple Megaport PoPs to ensure redundancy. By leveraging PoPs in different
geographic areas, organizations can build a fault-tolerant network that remains operational
even if one PoP experiences an issue.
2. Load Balancing and Traffic Management:
Use load balancing across VXCs to distribute traffic evenly and prevent overloading any
single connection. This enhances network performance and ensures that no single point
of failure exists in the network architecture.
Implement routing policies using BGP (Border Gateway Protocol) to manage data flows
intelligently. BGP can help prioritize certain routes for latency-sensitive traffic and ensure
that data finds the most efficient path in case of network congestion.
3. Disaster Recovery and Failover Mechanisms:
Configure connections in active-active mode for continuous data flow across multiple
regions and colocation sites, or in active-passive mode where a backup path remains
ready for use in case of primary connection failure.
By spanning multiple regions, organizations can implement disaster recovery strategies
that replicate data and workloads across different locations. This ensures that if one region
faces a disruption (e.g., a natural disaster), the others remain operational, supporting
business continuity.
4. High Availability Features of Megaport:
Megaport's SDN is designed with inherent redundancy, providing a reliable foundation for
multi-region and multi-colocation connections. In the event of a disruption, Megaport
allows for rapid provisioning of new connections and VXCs, minimizing downtime and
facilitating fast recovery.

100 Power Virtual Server for AIX and Linux

 5. Integration with IBM Power Virtual Server and Other Cloud Services:
Businesses can extend their network to multiple cloud providers using Megaport's
connectivity services. This multi-cloud approach ensures that production workloads can
move between different clouds based on performance, cost, or availability, enhancing
overall system reliability.
By integrating Megaport's services with Direct Link Connect, organizations benefit from
the secure, high-bandwidth connections that are crucial for running production
applications smoothly. This direct access helps maintain consistent data transfer rates and
reduces the risk of disruptions associated with public internet pathways.

Benefits of Multi-COLO, Multi-Region Connectivity Using Megaport

Megaport can provide improved performance, providing high-bandwidth, low-latency
connections to support performance-sensitive applications, ensuring that distributed systems
operate efficiently across regions. Organizations can expand their network as business needs
change, adding new VXCs or increasing bandwidth to accommodate growth. Megaport's
flexible bandwidth pricing allows organizations to manage costs efficiently, scaling bandwidth
up or down as needed without committing to expensive long-term contracts.

The private nature of Megaport's connections ensures data is transmitted securely,

supporting compliance with industry regulations and protecting sensitive information. The
centralized control panel and SDN capabilities of Megaport make it easy to monitor and
adjust network configurations, enhancing operational agility and responsiveness.

3.7 Multi-COLO Private Connection using IBM Cloud Backbone

IBM Cloud Backbone provides a robust and resilient network infrastructure for establishing
multi-colocation (multi-COLO) private connections, enabling seamless, high-performance
communication between data centers, cloud environments, and enterprise locations.
Leveraging IBM Cloud Backbone, organizations can create a secure and dedicated path for
data transfer that spans multiple geographical locations, supporting diverse workloads and
enhancing overall network reliability and performance.

3.7.1 Leveraging IBM Cloud Backbone for Robust Private Connections

IBM Cloud Backbone is a global, high-capacity network that connects IBM Cloud data centers
across the world. This network provides a secure, high-bandwidth foundation for enterprises
needing reliable private connectivity between multiple sites or across regions.

Unlike public internet connections, IBM Cloud Backbone ensures that data remains within a
controlled, private infrastructure. This minimizes the risk of interception, data loss, or latency
issues, making it suitable for applications that require stringent security and consistent
performance.

Key Features of IBM Cloud Backbone

The backbone is designed to handle large volumes of data at high speeds, supporting
workloads that involve substantial data transfer, real-time processing, and high-frequency
access. IBM Cloud Backbone covers multiple IBM Cloud data centers and regions, providing
businesses with a unified and interconnected network infrastructure that facilitates seamless
communication across global operations.

Chapter 3. IBM Power Virtual Server in the IBM Cloud network 101
 The architecture of IBM Cloud Backbone is built with redundancy and failover capabilities,
ensuring high availability and reducing the risk of network outages or performance
bottlenecks.

Integration with Multi-COLO environments

By integrating IBM Cloud Backbone with services like Direct Link and Edge Gateway,
businesses can extend their private connections beyond single data centers to include
multiple colocation facilities, enhancing connectivity for hybrid and multi-cloud deployments.

IBM Cloud Backbone facilitates smooth data transfer across different colocation sites,
ensuring that workloads can communicate efficiently without disruptions or latency spikes.
This is essential for applications that require synchronized data replication or distributed
processing.

3.7.2 Scenarios Where IBM Cloud Backbone is Optimal

The IBM Cloud Backbone acts as the central network layer that connects IBM data centers
and colocation sites. It serves as a transit layer for data, allowing enterprises to leverage this
private network to link different sites securely and efficiently. The integration points for the IBM
Cloud Backbone are:
 Direct Link Connect
Establishing connections through Direct Link Connect enables on-premises data centers
and third-party colocation facilities to link directly to the IBM Cloud Backbone. This
reduces latency and improves data transfer speeds compared to public connections.
 Edge Gateway
The Edge Gateway acts as the access point for routing and securing traffic between local
and remote resources. Combined with IBM Cloud Backbone, it enhances the flexibility of
routing options and security protocols, facilitating complex networking requirements.

Use cases
Here are some possible use cases for private connections with the IBM Cloud Backbone:

High-performance global applications

For organizations that run applications spanning multiple geographic regions, such as
financial services with global trading systems or multinational corporations with distributed
data processing, the IBM Cloud Backbone ensures consistent high-speed performance and
minimal latency.

Data Replication and Disaster Recovery

Enterprises that require real-time or near-real-time data replication between colocation sites
for disaster recovery and business continuity can benefit from the resilience and speed of the
IBM Cloud Backbone. The built-in redundancy and high availability features support rapid
failover and data synchronization.

Hybrid Cloud Architectures

Companies with hybrid cloud deployments, where workloads are distributed between
on-premises data centers and IBM Cloud, can leverage the IBM Cloud Backbone to maintain
seamless integration. This is particularly valuable when data sovereignty, compliance, or
security concerns mandate strict control over data paths.

102 Power Virtual Server for AIX and Linux

Multi-Cloud Strategies
Organizations that use multi-cloud strategies involving IBM Cloud and other cloud providers
can use IBM Cloud Backbone to provide consistent performance and centralized
management. The backbone acts as a conduit for data that needs to traverse different
platforms securely and efficiently.

Latency-Sensitive Applications
Applications that require real-time responsiveness, such as video conferencing platforms,
gaming services, or high-frequency trading systems, benefit greatly from the low-latency
connections facilitated by the IBM Cloud Backbone.

Benefits of IBM Cloud Backbone

By maintaining data traffic within IBM's global network, the backbone eliminates many of the
performance inconsistencies associated with public internet connections, such as variable
latency or packet loss. Data traveling over the IBM Cloud Backbone remains protected from
common security risks found on public networks, such as DDoS attacks or interception. This
is crucial for sectors that handle sensitive data, such as healthcare, finance, or government.

The architecture supports dynamic scaling, allowing businesses to increase bandwidth and
expand their network coverage as needs evolve. This scalability is essential for enterprises
experiencing rapid growth or those with fluctuating workload demands.

IBM Cloud Backbone also provides simplified network management for clients. Organizations
can leverage IBM Cloud's network management tools to monitor traffic, manage routes, and
maintain a high level of control over data flows. This unified approach simplifies the task of
overseeing complex, multi-region network architectures.

IBM Cloud Backbone allows for quick provisioning of new connections and expansions,
enabling businesses to respond promptly to changing requirements without extended delays.

Chapter 3. IBM Power Virtual Server in the IBM Cloud network 103
104 Power Virtual Server for AIX and Linux
 4

Chapter 4. Migration to Cloud with IBM

Power Virtual Server
This chapter explores the key factors involved in migrating IBM AIX and Linux workloads to
IBM Power Virtual Server instances. We will then detail several methods for migrating AIX
and Linux operating systems to this environment.

The following topics are discussed:

 “Example case scenario”
 “Migrating AIX to a Power Virtual Server through Cloud Object Storage”
 “Creating an OVA image”
 “Using Power Virtual Server to migrate a Linux image to the Power Virtual Server”
 “Migrating SAP workloads to IBM Cloud by using Power Virtual Server”

© Copyright IBM Corp. 2025. 105

4.1 Example case scenario
Before designing a migration plan for your on-premises IBM AIX and Linux workloads to an
off-premises location, careful consideration of architectural requirements is essential. For a
high-level overview of planning such a migration, see Appendix B, “Migration planning” on
page 189.

In this example, a customer is moving ten IBM AIX and Linux virtual machines from data
centers LPZ01 and LPZ02 in La Paz, Bolivia to IBM Power Virtual Servers on IBM Cloud in
data centers SAO01 and SAO04 in Sao Paulo, Brazil. During migration, the only change to
any of the VMs is an operating system upgrade from AIX version 7.2 to version 7.3. The ten
virtual machines are four production IBM AIX and Linux VMs, one development VM, one
archive VM, and four disaster recovery VMs that are duplicated to SAO04. This IBM Cloud
environment includes storage, backups in IBM Cloud Object Storage (COS), internal
networking including firewalls and a jump server to manage access of the virtual machines.
Additionally, this example includes a third-party vendor, replication across different zones in
IBM Cloud. See Figure 4-1.

Figure 4-1 Migrating IBM AIX and Linux VMs from La Paz (on premises) to Sao Paulo (off premises)

Note: Bolivia and Brazil are in the same continent (South America) that is why this
hypothetical case describes both countries, La Paz is 3000 kilometers from Sao Paulo. For
more information about multizone regions, see Locations for resource deployment.

4.1.1 Scope
In this example, all ten IBM AIX and Linux virtual machines (VMs) are migrated from data
center LPZ01, a customer replication source, and LPZ02, a customer replication target. The
VMs are managed by the customer in La Paz, Bolivia and will be migrated to the IBM Cloud
data centers, SAO01, the replication source, and SAO04, the replicated target, in Sao Paulo,
Brazil. Development and archive VMs in the La Paz data centers are migrated to IBM Cloud
by using IBM Cloud Object Storage backup and then restored to the target VM in Power
Virtual Server on IBM Cloud. The IBM AIX and Linux production VMs currently running at

106 Power Virtual Server for AIX and Linux

LPZ01 will be migrated by using IBM Cloud Object Storage backup and logical replication
method.

Note: Typically, you need a maintenance contract and an activation key of the logical
replication, installation, and configuration done by the third-party vendor solution.

After the migrated VMs are active, the data is restored to the target location and connectivity
from the La Paz data centers is established by using IBM Access Client Solution (ACS). After
validation of the migrated VMs, the customer’s applications are configured and started in the
environment. Each migrated VM is assessed for proper operation. IBM provides the technical
information to the customer, such as IP addresses, DNS names, and VM temporary name.
The original VMs in La Paz must remain unaffected by tests of the migrated VMs.

Important: It is the customer’s responsibility to administer their applications and user IDs.

Post-migration, IBM conducts security scans tailored to each AIX or Linux environment,
based on the customer's security policy, and provides the results for customer review. The
transition and ongoing support of the environment involve multiple teams, including those
responsible for IBM Cloud Connect for Network, Cloud Object Storage, Power Virtual Server,
and the AIX and Linux operating systems. The customer's application team and any
third-party vendors supporting logical replication are also key stakeholders in this process.

Image catalogs, created from optical device backups, must be restored onto the IBM Power
Virtual Server instance. This restoration process leverages migration strategies involving IBM
Cloud Object Storage and NFS servers.

Infrastructure considerations
The technical infrastructure architecture and design includes deploying several zones in
IBM Cloud in Sao Paulo. In addition to the Power Virtual Servers zone named “Power Colo”,
which is a contraction of Power co-location, a front-end zone is defined in which the jump
servers are deployed. Jump servers can be used to manage user access and for other
function such as a proxy for accessing the IBM Cloud Object Storage services. Those
services are hosted in an IBM Cloud Bare Metal Server. A cluster of firewalls is deployed in
the front-end zone within the SAO01 site. In the SAO04 data center, a stand-alone firewall is
deployed.

Functional requirements
The solution must satisfy functional and nonfunctional requirements in a way that best
balances competing concerns of stakeholders and must consider possible constraints.

Table 4-1 shows the functional requirements.

Table 4-1 Functional requirements

Requirement Description

Management services for IBM AIX and Linux Support for IBM AIX and Linux operating systems

Provide backup services IBM Cloud Object Storage is used as backup

services.

Provide multi-site HA solution. Multi-site infrastructure is provided in the two

sites in Sao Paulo.

Chapter 4. Migration to Cloud with IBM Power Virtual Server 107

 Requirement Description

Dual sites high availability The use of any third-party vendor solution on
logical replication to establishing disaster
recovery between SAO01 and SAO04.

Provide fault tolerant LAN infrastructure in Provide Network connectivity for application and
IBM Cloud servers.

Data replication between IBM Cloud and Use a logical replication solution for replicating
customer data center data for IBM AIX and Linux for replicating data for
the move of application

Provide traffic isolation and segmentation Use jump servers and traffic filtering on
IBM Cloud

Provide WAN connectivity Customer provides WAN circuit and the POP
network infrastructure. IBM provides the
termination endpoint in Sao Paulo.

Nonfunctional requirements
The nonfunctional requirements are:
 IBM Cloud portal access for IBM AIX and Linux virtual machines provisioning.
 Tools for alert monitoring and reporting on IBM AIX and Linux.
 Traffic bandwidth in IBM Cloud infrastructure cannot exceed 1 Gbps.
 Traffic bandwidth for replication is limited to 500 Mbps. Use Internet for preserving
production traffic.
 Local network redundancy to be provided in primary IBM Cloud site (SAO01) including
firewall cluster in High Availability and dual ports connectivity.
 Jump servers are used for managing access to the Power Virtual Server VMs.

4.1.2 Architectural decisions

Documenting architectural decisions can help to communicate the reasoning behind the
solution architecture. There is more than one conceivable solution for a given architectural
issue. Architectural decisions can include some of the following considerations:
 Components and their connections.
 Software version levels.
 Configuration of components based on infrastructure.
 Types of nodes.

These decisions have significant implications for cost, performance, and the degree to which
the system fulfills its requirements and addresses the needs of various stakeholders.
Documenting these choices establishes a formal record and ensures transparency regarding
the rationale underlying the system's design.

Documenting your architecture design process helps demonstrate and defend the reasoning
behind the design choices. It helps verify that the configuration fulfills both functional and
nonfunctional prerequisites and ensures that the stakeholders are satisfied with the
configuration. This can help avoid superfluous adjustments of the design during the design
process. In the following sections we present some examples of architectural decisions that

108 Power Virtual Server for AIX and Linux

need to be addressed when migrating IBM AIX and Linux VMs to the cloud in areas such as
infrastructure, servers, and networking.

Note: The design decisions that need to be made are unique to each client situation and
will be guided by the functional and non-ffunctional requirements in that situation.

Accessing the Power Virtual Servers

Table 4-2 discusses the decisions related to choosing the front-end accounts used to access
services. Note that the problem is stated along with assumptions and other considerations.

Table 4-2 Infrastructure - front-end accounts

Front-end accounts used for accessibility and provisioning of some services.

Provide a way to access the target Power Virtual Servers

Problem statement when VMs are moved from customer’s data centers to the
IBM Cloud data centers in Sao Paulo.

Customer provides the WAN connectivity up to the network

Assumptions
PoP Equinixa next to the data center.

Motivation Standard design for this type of solution.

Alternatives No alternatives.

Decision Deploy front-end account and services.

To access the Power Virtual Server, there is a need for a

front-end zone.
Justifications
Some provided services are firewalls, a relay environment to
access the target IBM AIX and Linux images, and a proxy for
IBM Cloud Object Storage access.

Deploy WAN access and replication method for moving the

Implications
existing data in the target environment

 Providing Firewall services for VPN access and filtering of

traffic.
 Providing IBM Cloud Object Storage services for Backup.
Derived requirements  Providing WAN network connectivity for customer’s users
and application connectivity.
 Providing Bare Metal servers to host relay applications
and Proxy.
a. For further details about Equinix refer to Equinix America Data Centers.

Note: Using Equinix you can get a direct link to IBM Cloud Classic and from IBM Cloud
Classic reach Power Virtual Server over Direct Link Connect. Alternatively, from Equinix,
you can get a cross connect to Megaport and connect to Power Virtual Server directly.

Before you begin, determine the location connection to IBM Cloud by verifying your
collocation provider's or service provider's capabilities to reach the meet-me room (MMR) and
cross-connect into IBM Cloud. For more information, see Direct Link Dedicated Hosting on
Classic. For example, on SAO01, the location type is a data center and the MMR Operator is
Ascenty.

In this use case, to migrate IBM AIX and Linux VMs from Bolivia to Brazil, it is possible to
establish the connection from Bolivia to SAO01. To do this you contract directly with a carrier

Chapter 4. Migration to Cloud with IBM Power Virtual Server 109

 that has capacity and presence in any Ascenty data center. The solution might be
LAN-to-LAN plus Cross Connection Fiber Optic plus IBM Cloud Direct Link of 1 Gbps or
10 Gbps. For the LAN-to-LAN link, IBM needs to directly contract the carriers for the private
LAN-to-LAN circuits. To view the list of Ascenty data centers, see: Ascenty Data Centers.

For more information, see ODATA.

Defining dual-site infrastructure

In this section Table 4-3 discusses the dual site infrastructure requirements and associated
considerations.

Table 4-3 Infrastructure - Dual site

Dual-site infrastructure is required for high availability purposes.

During a major outage, users are able to connect to backup

Problem statement
site. Consider use of DNS for servers translation.

Two sites are used for the solution: one in SAO01 and the
Assumptions
other one in SAO04, which is in a different zone.

Motivation Infrastructure recovery during a major outage

Alternatives No alternatives

Deploy dual site solution in an IBM Cloud Multi-Zone Region

Decision
(Sao Paulo).

In case of primary site major outage, the main goal is to

Justifications restart part of the application and services in the secondary
site.

Deploy a secondary site in addition to the Production

Implications
environment.

 Providing WAN network connectivity to secondary site for

customer’s users and application connectivity.
Derived requirements
 Duplicate part of the primary infrastructure in backup
site.

Defining a migration method

There are many considerations for migrating workloads from existing data centers to the new
Power Virtual Server instances in the IBM Cloud data center. Table 4-4 discusses the
considerations for the migration strategy.

Table 4-4 Defining a migration method

IBM Cloud Object Storage backup will be used for migrating IBM AIX and Linux VMs to
SAO01 and SAO04.

There is no automated tape library or virtual tape system

Problem statement available to perform a save or restore, which is a traditional
migration method for IBM AIX and Linux operating systems.

The use of IBM Cloud Object Storage for the migration is one
Assumptions of the available methods for moving workload to IBM Power
Virtual Server in IBM Cloud.

The use of IBM Cloud Object Storage to move IBM AIX and
Motivation
Linux workloads to SAO01 and SAO04.

110 Power Virtual Server for AIX and Linux

 IBM Cloud Object Storage backup will be used for migrating IBM AIX and Linux VMs to
SAO01 and SAO04.

 The use of IBM Cloud Object Storage for migration

 The use of master data management (MDM) device for
Alternatives the migration.
 Transferring IBM AIX and Linux image OVA file to IBM
Cloud Storage using IBM Power Virtualization Center.

Decision In this case IBM Cloud Object Storage will be used.

 MDM has been excluded as it is no longer avaiable.

Justifications  Customer does not have a virtualization by Power Virtual
Server.

Network connectivity will include VPN WAN connectivity and

Implications
proxy in a front-end account.

 Deploy proxy in front-end zones and VPN access from

client on IBM Cloud.
 Create buckets on IBM Cloud Object Storage for the data
Derived requirements
migration. Additional storage is needed for the IBM Cloud
Object Storage backup for the source IBM AIX and Linux
VMs.

Defining connectivity
This section describes the considerations for defining the connectivity as shown in Table 4-5.

Table 4-5 Networking - IBM Cloud Direct Link Dedicated on Classic

WAN direct-link connectivity to be redundant: one primary and one secondary link.

WAN access connectivity needs to be recovered during a

Problem statement
primary link outage.

Furnishing WAN is customer’s responsibility. IBM Cloud

Assumptions provides dual circuit connectivity on separate physical
devices.

Motivation Maintain connectivity with customer’s corporate network.

Doubling the WAN connectivity: a redundant connectivity in

Alternatives
SAO01 and a redundant connectivity in SAO04.

Provide redundant connectivity in SAO01 and use the IBM

Decision
Cloud backbone for Inter-site communications.

The provided service level is consistent, and there is the

Justifications
option to connect the IBM Cloud site by using VPN.

Implications Sao Paulo site to site connectivity to be deployed.

Deploy GRE and direct-link connectivity for Front-End zones

Derived requirements
communications.

IBM Cloud Direct Link Dedicated provides a dedicated connection (single-tenant) for users
with strict compliance needs. It uses a dedicated port in an IBM Cloud Point of Presence
(PoP). You connect via a fiber cross-connection through a network service provider (NSP),
who handles the “last mile” link between your network and the local IBM Cloud data center.
Like other Direct Link options, you can add global routing for private network access to all IBM

Chapter 4. Migration to Cloud with IBM Power Virtual Server 111

 Cloud locations. For more information, see IBM Cloud Direct Link provides fast, secure and
reliable performance for hybrid workloads.

IBM Cloud Direct Link is available in these offerings:

 IBM Cloud Direct Link on Classic:
– Direct Link Connect on Classic.
– Direct Link Dedicated on Classic.
– Direct Link Exchange on Classic.
– Direct Link Dedicate Hosting on Classic.
 IBM Direct Link 2.0:
– Direct Link Connect.
– Direct Link Dedicated.

To decide which Direct Link solution to order, see Getting started with IBM Cloud Direct Link
on Classic and Getting started with IBM Cloud Direct Link (2.0).

4.1.3 Architectural diagram

The architectural diagram (shown in Figure 4-2) shows a detailed overview for IBM Cloud in
Sao Paulo including the physical division of different zones. These zones are isolated from
each other by configured firewalls on separate physical switches.

The infrastructure is a dual site infrastructure:

SAO01 is where the IBM AIX and Linux production runs in two subzones. The first subzone is
named Client Front End Account and contains the jump servers and services such as IBM
Cloud firewalls and proxy. The second subzone, named Power Colo, is where the IBM Power
Virtual Server resides. The two zones communicate by the internal IBM Cloud network
backbone. SAO04 is for disaster recovery if there is an SAO01 outage.

Figure 4-2 Sample architectural diagram of IBM AIX and Linux on IBM Power Virtual Server

112 Power Virtual Server for AIX and Linux

4.2 Migrating AIX to a Power Virtual Server through Cloud
Object Storage
When you provision your Power Virtual Server instance you can use a standard image from
the ones provided by IBM Cloud, or you can provide your own customized AIX operating
system (OS) image for use within an IBM Power Virtual Server by storing an existing OS in an
OVA image file.

Note: You cannot transfer an OS license from an on-premises system to a Power Virtual
Server. The license cost is factored into the overall hourly billing rate.

To deploy an instance by using a custom image:

1. Create the custom image.
2. Store the image in your IBM Cloud Object Storage account.
3. Point the Power Virtual Server console to the image in the IBM Cloud Object Storage and
deploy the Virtual Server instance.

4.2.1 An overview of IBM Cloud Object Storage

IBM Cloud Object Storage is a cloud-based service for storing unstructured data. It's
well-suited for cloud environments due to its scalability and flexibility, handling petabytes of
data easily. Unlike block storage (data in blocks) or file storage (data in hierarchical files),
object storage manages data as individual objects.

This service offers cost-effective storage for large datasets, commonly used for archiving,
backups, web/mobile applications, and analytics. It features tiered storage classes for cost
management and integrates IBM Aspera® for high-speed data transfer. The “query-in-place”
function allows you to perform analytics directly on the stored data.

4.2.2 Creating an instance of IBM Cloud Object Storage in IBM Cloud

To create an instance of IBM Cloud Object Storage:
1. Login to the IBM cloud console, select Catalog and search for Object Storage.
2. Give the service instance a name and choose either Lite or Standard plan. In this
example, a Standard Plan is selected, and the instance name is Cloud Object Storage
Power Virtual Server as shown in Figure 4-3 on page 114.
3. Click Create, which is in the Summary panel on the right side of the window. (not shown in
Figure 4-3 on page 114).

Note: Some of the screen captures in this example might be different than the current
version because they were created with a previous version of the IBM Cloud Object
Storage interface.

Chapter 4. Migration to Cloud with IBM Power Virtual Server 113

 Figure 4-3 Creating an instance of IBM Cloud Object Storage

4. After you create the instance, the Cloud Object Storage window is displayed. Click Create
bucket to store data. See Figure 4-4.

Figure 4-4 IBM Cloud Object Storage Create bucket

Note: You can view and select instances by clicking Instances on the left side panel,
Cloud Object Storage.

114 Power Virtual Server for AIX and Linux

5. When prompted, click Create Bucket. See Figure 4-5.

Figure 4-5 Select Create bucket

You can choose to create a custom bucket or select a predefined bucket. In this example,
customize your bucket by clicking the blue arrow in the lower right of the Customize your
bucket section. See Figure 4-6.

Figure 4-6 Customize the bucket

6. In the Customer Bucket section:

a. Enter the name of the bucket. In the example, the bucket name is powervs-aix.
b. In the Location field, select a location to store the physical data.
c. Select a Storage Class of Vault. See Figure 4-7 on page 116.
d. Accept the rest of the default parameters and click Create Bucket.

Chapter 4. Migration to Cloud with IBM Power Virtual Server 115

 Figure 4-7 Creating a bucket window

e. The newly created bucket is listed in COS PowerVS instance as shown in Figure 4-8.

Figure 4-8 Listing buckets

7. After the creation of the bucket, define Service Credentials, which provide the information
to connect an application to object storage. Click Service credentials and then click New
credential as shown in Figure 4-9 on page 117.

116 Power Virtual Server for AIX and Linux

Figure 4-9 Creating New credential

8. Enter the service credential name, click Role to choose a role from the list, and enable the
Include HMAC Credential. See Figure 4-10
9. Click Add.

Figure 4-10 Creating new credentials

a. Figure 4-11 shows the new service Credential created.

Figure 4-11 New service credential

Chapter 4. Migration to Cloud with IBM Power Virtual Server 117

 b. Figure 4-12 shows the created service credential.

Figure 4-12 New service Credential

c. You can now begin uploading any OVA file by using Aspera Connect which is a built-in
feature. For instructions on creating the OVA file see 4.2.3, “Creating an OVA image”
on page 122.

Note: You can set Aspera as your default for any uploads. For more information, see Using
Aspera high-speed transfer.

10.To upload the OVA image to the IBM Cloud Object Storage, click Upload as shown in
Figure 4-13.

Figure 4-13 Uploading a file to a bucket

118 Power Virtual Server for AIX and Linux

11.Select files to upload and select a transfer type. See Figure 4-14.

Figure 4-14 Uploading file by using Aspera

12.Click Upload files to browse your notebook folder. Choose a file and start the upload. You
can monitor the file transfer from the GUI. See Figure 4-15.

Figure 4-15 Transfer file to bucket

a. You can view the transferred file in the bucket as shown in Figure 4-16.

Figure 4-16 Viewing the file in the bucket

Chapter 4. Migration to Cloud with IBM Power Virtual Server 119

 b. Before you import the image, determine or obtain the following information:
• Storage type (Tier 1 or Tier 3).
• Region.
• Image file name.
• Bucket name.
• IBM Cloud Object Storage access key. To copy the key select the Menu icon, then
select Resource list → Storage → Cloud Storage Object name → Service
credentials → View credentials, then copy the IBM Cloud Storage access key.
• IBM Cloud Object Storage secret access key. To access the secret key, select the
Menu icon then select Resource list → Storage → Cloud Storage Object
name → Service credentials → View credentials, then copy the
secret_access_key.
13.Import the OVA file to the Power Virtual Server instance by selecting Resource list →
Services → Power Virtual Server Guide. For an example of the resulting screen, see
Figure 4-17.

Figure 4-17 Selection Boot images tab

14.Click Import Image.

15.In the Import boot image page, enter the custom image name, storage type, region, image
filename, bucket name, and storage access key and secret key in their appropriate fields.
See Figure 4-18.

Figure 4-18 Importing boot Image page

120 Power Virtual Server for AIX and Linux

16.After the image is imported, use the image to deploy a new AIX virtual machine. Select
Virtual server instance and click Create instance. Enter the required name and ensure
that the image is listed. See Figure 4-19.

Figure 4-19 Creating a new AIX virtual machine

17.View the created Power Virtual Server instance as shown in Figure 4-20.

Figure 4-20 Listing Virtual Server instances

Chapter 4. Migration to Cloud with IBM Power Virtual Server 121

 18.Connect to the Power Virtual Server instance to verify that the AIX image is running. See
Figure 4-21.

Figure 4-21 AIX image OVA file restored and running

4.2.3 Creating an OVA image

There are two options which can be used to create the OVA image to upload and use in your
Power Virtual Server instances.

Using PowerVC to capture and import an OVA image

IBM PowerVC is an advanced virtualization and cloud management offering. Built on
OpenStack, it provides simplified virtualization management and cloud deployments for IBM
AIX, IBM i and Linux virtual machines running on IBM Power. If you deployed PowerVC in
your on-premises environment, you can use it to capture any supported LPAR and create an
OVA image. After you create the OVA image, upload it to your IBM Cloud Object Storage
account and import it into the Power Virtual Server environment. For more information, see
Exporting Images.

Using create_ova command on AIX to create OVA image

Starting with AIX 7.2, the create_ova command is used to create a single-volume raw disk
image and to export contents of a raw disk image to a compatible OVA package format. The
OVA package can be imported into any Power Virtual Server environment that contains a
supported storage device.

You can also import the OVA package into any cloud service that supports the Open
Virtualization Format (OVF) packaging standard. The imported OVA package can be
deployed as a virtual machine. For more information about creating an OVA image by using
AIX 7.3, see create_ova Command.

4.3 Migrating AIX to a Power Virtual Server using a mksysb file

In this section, the example demonstrates a system migration from an on-premises system to
a Power Virtual Server instance by using a file created from the mksysb command.
1. After the mksysb image is collected from an on-premises system, view the contents of the
powervs-aix bucket and click Upload. In the Uploads page, click Upload files. Choose the
mksysb image and start the upload. See Figure 4-22 on page 123.

122 Power Virtual Server for AIX and Linux

Figure 4-22 Uploading the mksysb image

2. You can monitor the file transfer as shown in Figure 4-23.

Figure 4-23 Uploading the mksysb image

After the upload is complete, you can view the file in the bucket as shown in Figure 4-24.

Figure 4-24 Listing files in the bucket

3. Create a Power Virtual Server instance to receive the mksysb image, by clicking Create
Instance and enter the instance name as shown in Figure 4-25 on page 124.

Chapter 4. Migration to Cloud with IBM Power Virtual Server 123

 Figure 4-25 Creating a new Power Virtual Server instance

4. Select the machine type, CPU, and memory configuration as shown in the example in
Figure 4-26.

Figure 4-26 Selecting CPU and Memory for a new Power Virtual Server instance

124 Power Virtual Server for AIX and Linux

5. Enable the public network to access to the internet. From the internet, you can download
and install AWS CLI tools to allow access to the external Cloud Object Storage endpoint.
Usually, the public connection is disabled after the installation of the server image is
completed. See Figure 4-27.

Figure 4-27 Enabling public network

6. Agree to the terms and conditions and click Create instance. See Figure 4-28.

Figure 4-28 Creating a Power Virtual Server instance

7. When the Power Virtual Server instance creation is completed, open the console into the
instance by selecting the VM actions pull-down menu. Click Open console. See
Figure 4-29.

Figure 4-29 Selecting Open Console

Chapter 4. Migration to Cloud with IBM Power Virtual Server 125

 8. Login as user root and set the root password as shown in Figure 4-30.

Figure 4-30 Accessing the console and changing root password

9. Connect to the public IP address of the Power Virtual Server instance using SSH. See
Figure 4-31.

Figure 4-31 Check public IP address

10.Access the Power Virtual Server instance by using its public IP address as shown in
Figure 4-32.

Figure 4-32 Access the Power Virtual Server instance from public IP address

126 Power Virtual Server for AIX and Linux

11.Add a staging volume by copying the mksysb image:
a. Click the Power Virtual Server instance in the IBM Cloud GUI and open the Attached
volumes page. Click Create volume as shown in Figure 4-33.

Figure 4-33 Creating a new volume

b. Name the volume and ensure that the volume is large enough to contain the mksysb
file. Then click Create and Attach as shown in Figure 4-34.

Figure 4-34 Creating a new volume

c. From the ssh console, run cfgmgr and the new volume is available as shown in
Figure 4-35.

Figure 4-35 Recognize the new disk

12.Create a staging volume group and a file system on the new disk, and mount it as shown
in Figure 4-36.

Figure 4-36 Creating staging volume group

Chapter 4. Migration to Cloud with IBM Power Virtual Server 127

 13.Install the AWS CLI tools to retrieve the mksysb image from IBM Cloud Object Storage:
a. Increase the size of the /opt filesystem to make space for the tools as shown in
Figure 4-37.

Figure 4-37 Increasing /opt filesystem

b. Run the cloud_setup script to install a series of open-source packages that are
dependencies for the AWS CLI. See Figure 4-38.

Figure 4-38 Running cloud_setup script

c. Install the awscli tools as shown in Figure 4-39.

Figure 4-39 Installing awscli tools

128 Power Virtual Server for AIX and Linux

 d. Use the aws configure command to setup the connection to the IBM Cloud Object
Storage. Copy the access keys from the defined Service Credentials as shown in
Figure 4-40.

Figure 4-40 Configure connecting to the IBM Cloud Object Storage

e. Use the AWS CLI to copy the mksysb image from your bucket into the stage file
system:
i. View the listed public endpoint. Figure 4-41.

Figure 4-41 Collecting public endpoint from PowerVS-aix bucket

ii. List the objects in the bucket PowerVS-aix as shown in Figure 4-42.

Figure 4-42 Listing objects in the bucket PowerVS-aix

iii. Copy the example.mksyb file from PowerVS-aix bucket to the /stage filesystem as
shown in Figure 4-43.

Figure 4-43 Copying file from the bucket to the filesystem

14.Add a new root volume to restore the mksysb:

a. Change to the /stage directory and restore the image.data file from the mksysb to view
the original disk information as shown in Figure 4-44.

Figure 4-44 Restore the image.data file

Chapter 4. Migration to Cloud with IBM Power Virtual Server 129

 b. Use the cat out or otherwise search the image.data file to find the source_disk_data
section as shown in Figure 4-45. The output shows that the original system had a
single 20 GB root volume.

Figure 4-45 Viewing the disk size from the image backup

15.From the GUI, create a new volume that is large enough to deploy the mksysb as shown in
Figure 4-46.

Figure 4-46 Creating new volume

16.After the volume is created, click Storage volumes in the left column, and then click Edit
for your new volume as shown in Figure 4-47.

Figure 4-47 Listing Storage Volumes

130 Power Virtual Server for AIX and Linux

17.Set the Bootable option for the restore volume to On as shown in Figure 4-48.

Figure 4-48 Changing storage volume to bootable

18.Return to the console and run cfgmgr to discover the new volume. You can confirm the
size with bootinfo -s as shown in Figure 4-49.

Figure 4-49 checking the size of the new disk

19.Enter the command alt_disk_mksysb to restore your mksysb onto the new disk. This step
can take 20–30 minutes. See Figure 4-50.

Figure 4-50 Running alt_disk_mksysb

Chapter 4. Migration to Cloud with IBM Power Virtual Server 131

 When the restore completes without errors, the bootlist is automatically set to point to
the restored root volume. See Figure 4-51.

Figure 4-51 Bootlist automatically set to point to the restored root volume

20.Boot from the new boot volume with the restored mksysb:
a. Return to the GUI and click Open console as shown in Figure 4-52.

Figure 4-52 Open console

b. Reboot your Power Virtual Server instance. This can take some time as devices must
be re-created in the restored environment. You notice at least one reboot during this
process. If the console closes while you are waiting, open it again. See Figure 4-53 on
page 133.

132 Power Virtual Server for AIX and Linux

Figure 4-53 Reboot Power Virtual Server instance

c. After approximately 20–30 minutes, the system start is complete. Set the terminal type
to vt100 and press Enter. See Figure 4-54.

Figure 4-54 Setting terminal type

d. In the next screen, which is not shown, choose the option for Tasks Complete – Exit to
Login.

Chapter 4. Migration to Cloud with IBM Power Virtual Server 133

 e. Then login as root. See Figure 4-55.

Figure 4-55 Logging on in the restored image

4.4 Using Power Virtual Server to migrate a Linux image to the

Power Virtual Server
You can use Power Virtual Server to deploy a customized Linux operating system (OS) image
within an IBM Power Virtual Server.

The following steps describe an overview to deploy an instance by using a custom image:
1. Create the custom image.
2. Store the image in your IBM Cloud Object Storage account.
3. Point the Power Virtual Server console to the image in the IBM Cloud Object Storage and
deploy the Virtual Server instance.

4.4.1 Using PowerVC to capture and import an OVA image

If you deployed PowerVC in your on-premises environment, you can use it to capture any
supported LPAR and create an OVA image. After you create the OVA image, upload it to your
IBM Cloud Object Storage account and import it into the Power Virtual Server environment.

4.4.2 Creating an instance of IBM Cloud Object Storage in IBM Cloud

Use the following steps to create a bucket. Then create an instance of IBM Cloud Object
Storage in IBM Cloud.

134 Power Virtual Server for AIX and Linux

1. Create a bucket to store data in the COS Power Virtual Server instance. Enter the name of
the bucket with correct permissions as shown in Figure 4-56.

Figure 4-56 Creating a bucket

After you create the bucket, the bucket is listed in the COS Power Virtual Server server
instance IBM Cloud Object Storage as shown in Figure 4-57.

Figure 4-57 Listing buckets

2. For Service Credentials, use the same credentials that were created previously as
described in “Creating an instance of IBM Cloud Object Storage in IBM Cloud”.
You can now start uploading any OVA file by using Aspera Connect which is a built-in
feature.

Chapter 4. Migration to Cloud with IBM Power Virtual Server 135

 3. To upload the OVA image to IBM Cloud Object Storage, click Upload as shown in
Figure 4-58.

Figure 4-58 Uploading a file to a bucket

After you select files to upload, you see a page as shown in Figure 4-59.
4. Click Upload files to select a file from a local folder. Select a file and start the upload.

Figure 4-59 Transfer file by way of Aspera

You can see the file transfer in the UI as shown in Figure 4-60.

Figure 4-60 Transfer file to bucket

136 Power Virtual Server for AIX and Linux

5. Verify that the file transferred successfully by viewing the contents of the bucket as shown
in Figure 4-61.

Figure 4-61 Check files in the bucket

6. Import the OVA file to your Power Virtual Server instance. Select Resource list →
Services → Power Virtual Server Server Guide → Select the Boot images tab as
shown in Figure 4-62.

Figure 4-62 Selection Boot Images tab

7. Before you import the image, you need the following information:
– Storage type (Tier 1 or Tier 3).
– Region.
– Image filename.
– Bucket name.
– IBM Cloud Object Storage access key. Select Menu icon → Resource list →
Storage → Cloud Storage Object name → Service credentials → View
credentials. Copy the access_key_id.
– IBM Cloud Object Storage secret key. Select the Menu icon → Resource list →
Storage Cloud Storage Object name → Service credentials → View credentials.
Copy the secret_access_key.
8. Click Import image.

Chapter 4. Migration to Cloud with IBM Power Virtual Server 137

 9. In the Import boot image page, enter or select the information in the fields as shown in
Figure 4-63.

Figure 4-63 Importing boot image

10.Verify that the boot image is listed after the file has been imported as shown in
Figure 4-64. After the image is imported, use the image to deploy a new Linux virtual
machine.

Figure 4-64 Listing boot images

11.Open the Virtual server instance page.

12.Click Create instance.
13.Enter the instance name and click Create instance.

138 Power Virtual Server for AIX and Linux

14.in the General page, select the Image field to verify that the image is available in the list of
images and select the image. See Figure 4-65.

Figure 4-65 Creating a new Linux virtual machine

15.Verify that the instance was created by viewing it in the Virtual server instances page as
shown in Figure 4-66.

Figure 4-66 Listing Power Virtual Server instance

Chapter 4. Migration to Cloud with IBM Power Virtual Server 139

 Figure 4-67 shows the running, restored Linux OVA image.

Figure 4-67 Restored Linux OVA image

4.5 Migrating SAP workloads to IBM Cloud by using Power

Virtual Server
The IBM Cloud for SAP offerings are designed based on more than 50 years of IBM-SAP
expertise. The on-demand flexible compute options provide enterprise-grade availability for
various SAP applications and database servers provide supported SAP infrastructure options
for various SAP components including SAP NetWeaver implementations and SAP HANA
implementations.

The IBM and SAP multi-decade alliance is why IBM was selected as one of SAP’s strategic
infrastructure providers for hybrid cloud. Support for SAP's suite of products is available
through the highly scalable, open, and security-rich IBM Cloud.

4.5.1 The unique value proposition of IBM Power Virtual Server for SAP
workloads
IBM Power Virtual Server differentiates itself with the following value propositions.

Accelerated time-to-value
IBM Power Virtual Server provides an accelerated time-to-value for your SAP workloads
through:
– Seamless transition from on-premises systems to IBM Power on IBM Cloud, ensuring a
consistent user experience throughout.
– Easy migration with a unified architecture that facilitates a smooth shift to IBM Power
on IBM Cloud.
– IBM offers comprehensive, optimized support for SAP across all layers, including
infrastructure, hypervisor, and operating system.

140 Power Virtual Server for AIX and Linux

 – Faster time-to-value with shorter migration durations compared to other hyper scalers.
– Thousands of clients trust IBM Power to effectively manage their SAP environments.
– Clear roadmap with IBM Consulting™, aligning on a strategic transformation plan.
– Clients utilizing SAP Business Suite applications can successfully operate within a
hybrid landscape.
– Leverage stable and secure PowerVM hardware-level hypervisors to enhance flexibility
and agility, allowing your business to adapt to evolving demands.
– Dynamically adjust computing resources while maintaining business operations
without planned downtime, addressing seasonal demands effectively.
– Benefit from cost-effective contracts within a robust, high-performance IaaS
environment on IBM Power, complemented by the full capabilities of IBM Cloud for
mission-critical SAP applications.

Maximum Uptime
Power Virtual Server provides enhanced availability capabilities which help provide maximum
uptime through the following:
– Achieve unparalleled server reliability, designed to meet or exceed SLAs, allowing IT
operations to focus on core business priorities. IBM Power has been ranked as the top
server for availability by ITIC for the past 15 years1, boasting an impressive 99.999%
uptime.
– Enterprise-class servers are engineered for resilience, featuring advanced recovery
and self-healing capabilities.
– IBM emphasizes continuous reliability improvements through a vertically integrated
design and System Life Cycle processes, including supercomputer simulations,
real-world system testing, and early client engagement.
– IBM Power servers utilize real-time advanced self-diagnosis to facilitate proactive
measures, further enhancing uptime.
– Comprehensive security is maintained across all layers, from firmware and hypervisor
to operating system, complemented by secure high-performance storage and
networking capabilities.
– Data is encrypted both at rest and in motion at speeds double that or faster than
industry standards, ensuring robust protection across the stack.
– On-chip accelerators expedite the compression and encryption of entire VMs,
significantly outperforming traditional software methods for GZIP file handling.
– IBM PowerVM provides the highest level of security among hypervisors underpinning
Cloud IaaS, with the lowest reported CVEs according to the US National Vulnerability
Database, safeguarding mission-critical data effectively.

Continuous Innovation
Power Virtual server helps with continuous innovation through:
– Focus resources on future business requirements rather than managing infrastructure
and SAP systems, enabling sustained growth.
– Enhance business processes with SAP S/4HANA, complemented by valuable insights
from IBM Consulting.
– Systems built on the IBM POWER processor benefit from over 30 years of enhanced
performance and reliability.
1 https://www.ibm.com/downloads/documents/us-en/107a02e959c8f503

Chapter 4. Migration to Cloud with IBM Power Virtual Server 141

 – Each new generation of IBM Power servers is designed for greater energy efficiency
and increased performance, helping clients reduce their carbon footprint.
– Continuous innovation characterizes every new generation of IBM Power servers,
ensuring they are purpose-built for data-intensive workloads like SAP S/4HANA.
– Access the IBM Solution Blueprint for SAP, co-developed by IBM Consulting, IBM
Cloud, and IBM Power teams, to accelerate your implementation.

4.5.2 Use Case: SAP Migration, Greenfield Implementation, and divestiture

As SAP sets a deadline for clients to migrate from legacy applications—such as ERP, BW,
and others running on AnyDB (IBM Db2®, Oracle, MS SQL Server, MaxDB, Sybase)—by
20272, organizations are increasingly considering the implementation of S/4HANA and
BW/4HANA. This can be approached through either Greenfield (new implementation) or
Brownfield (migration of existing data) strategies. In tandem with these migration projects,
many clients aim to evolve their businesses into what SAP refers to as “The Intelligent
Enterprise,” integrating new applications for analytics, customer experience, blockchain, and
IoT.
 Enterprise SAP Application Migrations and New Implementations:
– Greenfield Implementations: New deployments of S/4HANA and BW/4HANA, as well
as traditional SAP R/3 (or SAP ECC) on the cloud, encompassing development,
testing, demonstration, pre-production, and production environments.
– Brownfield Implementations: Migrating existing on-premises S/4HANA and BW
systems, along with traditional SAP R/3 implementations, to the cloud. This includes all
phases: development, testing, demonstration, pre-production, and production
environments.
– Public Cloud Certified Power SAP Options: Solutions include Business Warehouse
using SAP BW/4HANA and BW on HANA, as well as the Intelligent Enterprise
powered by SAP S/4HANA. Integration with IBM Technologies:
– Enhance SAP S/4HANA with IBM analytics, Watson, IoT, and blockchain to deliver
deeper insights to clients.
– Disaster Recovery/Development and Testing on IBM Cloud: Utilize IBM SAP Cloud
Data Centers as a disaster recovery (DR) site for on-premises SAP deployments.
 Business-Focused Examples
– Prepare business units for sale by migrating their SAP systems to the cloud, creating a
clean, marketable package.
– Digital Transformation Initiative: Implement SAP S/4HANA as part of a broader digital
core strategy.
– Sandbox Environment: Create a separate but secure environment on Power Systems
for users to test SAP S/4HANA as part of their digital transformation strategy.
– Performance Concerns: Address and resolve performance issues that may impact
business operations.

2
https://community.sap.com/t5/enterprise-resource-planning-blogs-by-members/the-impact-of
-2027-on-sap-customers/ba-p/13525401

142 Power Virtual Server for AIX and Linux

4.6 Configurations and Capabilities of IBM Power Systems
Virtual Server
IBM Power Systems Virtual Server offers a variety of configurations to cater to different
application needs. Clients can select server profiles that best fit their requirements, benefiting
from PowerVS's scalability ranging from 4 cores up to 165 cores. The IBM FlashSystem
all-flash storage system provides high performance with a balanced mix of Tier 1 and Tier 3
storage options.

Additionally, the platform supports a wide range of operating systems, ensuring flexibility for
various workloads as shown in Table 4-6 and Table 4-7.

Table 4-6 Power Virtual Server Configurations - IBM Power 9

Systems Power Virtual Server Configurations - IBM Power9®

Compute IBM Power E980

 4 cores to 120 cores
 Memory: 128 GB to 18 000 GB

Table 4-7 Power Virtual Server Configurations - IBM Power 10

Systems Power Virtual Server Configurations - IBM Power10

Compute IBM Power S1022

 SMT4 (4 cores to 25 cores), Memory (256 GB to 1500
GB)
 SMT8 (8 cores to 33 cores), Memory (1900 GB)
IBM Power E1080
 SMT4 (4 cores to 80 cores), Memory (256 GB to 14 400
GB)
 SMT8 (165 cores), Memory (30 500 GB)

For SAP HANA used in production, the following virtual server configurations/instances are
tested and supported:
 IBM Power10 server generation (IBM Power System S1022 and E1080):
– SUSE Linux Enterprise Server (SLES) for SAP 15 SP4 or newer Red Hat Enterprise
Linux (RHEL) 8.6 or newer
– Red Hat Enterprise Linux (RHEL) 9.2 or newer
– HANA Version 2 SPS07 or newer
 IBM Power9 Server Generation (IBM Power System E980)
– SUSE Linux Enterprise Server (SLES) for SAP 12 SP1 or newer SUSE Linux
Enterprise Server (SLES) for SAP 15 SP4 or newer Red Hat Enterprise Linux (RHEL)
8.1 or newer
– Red Hat Enterprise Linux (RHEL) 9.2 or newer
– HANA Version 2 SPS04 or newer

Chapter 4. Migration to Cloud with IBM Power Virtual Server 143

4.6.1 IBM Power Virtual Server certified profiles for SAP HANA
IBM and SAP are collaborating to run SAP HANA-based applications on IBM Power Virtual
Servers.

Power Virtual Server is a Power enterprise infrastructure as a service (IaaS) offering. Power
Virtual Servers are physically located with low-latency connectivity to the IBM Cloud
Infrastructure. This infrastructure design enables Power Virtual Servers to maintain key
enterprise software certification and support as its architecture is identical to a certified
on-premises infrastructure.

The IBM Power Virtual Server offering is ideal for many SAP HANA use case scenarios. You
can use your servers for mission-critical workloads, as your test environment, or for your
business continuity disaster recovery site. All SAP HANA-based products are supported on
Power Virtual Servers.

Understanding IBM Power Virtual Server profile names

The IBM Power Virtual Server for SAP HANA have profile names that are contextual and
sequential. There are multiple families of profiles for SAP HANA, each associated with the
required Service Level Agreements (SLAs):
cnp1 Non-production development for testing or development use only. Is
not intended for production deployments. Is not supported or certified
by SAP for production
ush1 Small for OLAP/OLTP workloads that don't require as much CPU and
storage consumption
umh Ultra Memory HANA for OLTP that uses 1:240 as the cpu:memory
ratio
mh1 High Memory for OLAP that use 1:180 as the cpu:memory ratio
bh1 Balanced for OLAP that use 1:100 as the cpu:memory ratio
ch1 Compute Intensive for OLAP that use 1:50 as the cpu:memory ratio.

For more information, see this IBM Cloud Document on SAP Profiles.

4.6.2 IBM Power Virtual Server certified profiles for SAP NetWeaver
IBM Power Virtual Servers are available with fully adjustable CPU cores and memory. You
can specify a custom size when defining the Power Virtual Server to use for SAP NetWeaver,
in accordance with existing SAP NetWeaver or SAP AnyDB for IBM Power best practices and
guidance from SAP. Therefore, no profile names are used to define running SAP NetWeaver
or SAP AnyDB that uses IBM Power Virtual Servers.

For SAP applications, the following virtual server configurations are supported. SAP
NetWeaver. Instance sizing is flexible, but it must follow the standard SAP sizing guidelines by
using SAPS benchmarks as shown in Table 4-8.

Table 4-8 SAPS benchmarks

IBM Power type SAPS per CPU core SAPS per CPU thread (using SMT-8)

E980 6,000 750

S1022 7600 950

E1080 7600 950

144 Power Virtual Server for AIX and Linux

Figure 4-68 shows the example of creating an SAP NetWeaver VSI.

Figure 4-68 SAP NetWeaver VSI

For more information refer to the following SAP note and IBM Redbooks:
 SAP HANA on IBM Power Systems Virtual Servers: Hybrid Cloud Solution

https://www.redbooks.ibm.com/abstracts/redp5693.html
 SAP Note 2947579 - SAP HANA on IBM Power Virtual Servers

https://launchpad.support.sap.com/#/notes/2947579

Chapter 4. Migration to Cloud with IBM Power Virtual Server 145

146 Power Virtual Server for AIX and Linux
 5

Chapter 5. Managing Workloads on IBM

Power Virtual Server for IBM AIX
and Linux deployments
This chapter describes working in an IBM Power Virtual Server environment on IBM Cloud for
AIX and Linux.

The content in this chapter is derived from actual experiences while deploying and managing
workloads on-premises and in the IBM Cloud with the IBM Power Virtual Server.

This chapter provides the following information:

 “IBM Power Virtual Server compatibility with IBM AIX and Linux”
 “Hints and tips for IBM AIX and Linux workloads on Power Virtual Server”
 “Monitoring and Performance management”
 “User management and security settings”

© Copyright IBM Corp. 2025. 147

5.1 IBM Power Virtual Server compatibility with IBM AIX and
Linux
IBM Power Virtual Server is a robust cloud-based solution that leverages IBM's powerful Power
Systems hardware to provide scalable, secure, and high-performance infrastructure-as-a-service
(IaaS). Hosted on IBM Cloud, Power Virtual Server is specifically designed for enterprise-grade
workloads, offering the reliability and compute power needed for demanding applications.

IBM Power Virtual Server is compatible with IBM AIX (IBM's UNIX operating system), Linux, and
IBM i. This compatibility makes it ideal for businesses already running mission-critical applications
on AIX or Linux who want to take advantage of cloud infrastructure while maintaining the stability
and performance of IBM Power Systems.

IBM Power Virtual Server supports a variety of Linux distributions, such as Red Hat Enterprise
Linux (RHEL), SUSE Linux Enterprise Server (SLES), and Ubuntu, providing enterprises with
flexibility and choice for their Linux workloads. This compatibility allows businesses to transition
seamlessly from on-premises IBM Power environments to the cloud, keeping operational
continuity intact while taking advantage of IBM Cloud's capabilities.

5.1.1 Benefits of managing AIX and Linux workloads on Power Virtual Server
Power Virtual Server offers several key advantages for managing AIX and Linux workloads. Here is
a summary of those benefits:

Flexibility
Power Virtual Server provides significant flexibility in the following areas:
 Hybrid Cloud Integration
Power Virtual Server allows organizations to deploy and manage AIX and Linux workloads in a
hybrid cloud environment. This integration enables seamless data flow between on-premises
data centers and IBM Cloud, providing the flexibility to keep certain workloads on-premises
while moving others to the cloud based on business needs.
 Choice of Operating System
Businesses can deploy either AIX or a variety of Linux distributions on the same Power Virtual
Server platform, supporting different applications and use cases. This choice allows
organizations to optimize their environment for specific workloads and maintain compatibility
with legacy applications.

Scalability
Enhanced scalability is provided by:
 On-Demand Resource Allocation
Power Virtual Server enables businesses to scale CPU, memory, and storage resources
up or down as needed. This scalability is especially beneficial for workloads with
fluctuating demands, such as seasonal processing tasks or applications with variable
workloads.
 Global Reach
As part of IBM Cloud, Power Virtual Server can support global operations, allowing
organizations to deploy instances in multiple regions. This geographic flexibility helps meet
data sovereignty requirements and improve application performance for users in different
locations.

148 Power Virtual Server for AIX and Linux

 Optimized performance
Workloads on Power Virtual Server gain performance benefits from:
 IBM Power architecture
Power Virtual Server leverages IBM's POWER architecture, known for its exceptional
performance with data-intensive and compute-heavy applications. The architecture is
specifically optimized for enterprise workloads, providing the performance boost
necessary for applications such as ERP systems, large databases, and analytics
workloads.
 Efficient processing of AIX and Linux workloads
IBM Power Virtual Server is designed to handle the unique requirements of AIX and Linux
workloads efficiently, ensuring that applications run smoothly even under high loads. The
platform is particularly beneficial for workloads that require high I/O performance, large
memory capacity, and low latency.
 Improved reliability and uptime
IBM Power Systems are renowned for their reliability, and the Power Virtual Server
extends this quality to the cloud. By running AIX and Linux workloads on Power Virtual
Server, organizations benefit from IBM's industry-leading uptime, which is critical for
mission-critical applications.

Security and compliance

Benefits in security and compliance are provided by:
 Built-In security features
IBM Power Virtual Server includes robust security features such as data encryption,
access controls, and firewalls to protect sensitive data. This security foundation helps
enterprises meet compliance requirements and maintain data integrity, even in a cloud
environment.
 Isolation and multi-tenancy
Each Power Virtual Server instance is isolated, ensuring that workloads run independently
without interference from other tenants. This is crucial for organizations handling sensitive
data or operating in regulated industries, as it minimizes the risk of data leakage or
unauthorized access.

Cost-effectiveness
Power Virtual Server provides cost effectiviness through:
 Reduced capital expenses
By moving AIX and Linux workloads to Power Virtual Server, businesses can reduce the
capital expenses associated with maintaining on-premises infrastructure. This cost
efficiency is particularly advantageous for businesses with high infrastructure costs that
can benefit from IBM's pay-as-you-go pricing models.
 Resource optimization
IBM Power Virtual Server allows organizations to allocate resources efficiently, paying only
for what they use. This resource optimization helps lower operational costs and enables
businesses to manage budgets more effectively.

Summary
IBM Power Virtual Server offers a powerful, scalable, and secure environment for managing
AIX and Linux workloads in the cloud. By providing compatibility with IBM's trusted operating
systems and leveraging the high-performance IBM Power architecture, Power Virtual Server

Chapter 5. Managing Workloads on IBM Power Virtual Server for IBM AIX and Linux deployments 149
 enables organizations to modernize their infrastructure while maintaining the reliability and
efficiency they rely on. Whether for hybrid cloud, global expansion, or cost management,
Power Virtual Server is an optimal solution for enterprises seeking to extend the benefits of
IBM Power Systems to the cloud.

5.2 Hints and tips for IBM AIX and Linux workloads on Power
Virtual Server
Managing IBM AIX and Linux workloads on IBM Power Virtual Server can be streamlined and
optimized by applying a set of best practices and expert tips. These insights cover everything
from resource allocation and performance tuning to network configuration and security.
Leveraging these hints and tips can help organizations maximize efficiency, ensure robust
security, and enhance the reliability of critical applications running on AIX and Linux. By
understanding how to optimize resource usage, configure backup and recovery solutions, and
implement effective monitoring, IT teams can create a stable, high-performing environment
that meets the demands of enterprise workloads. These tips are tailored to the unique
characteristics of AIX and Linux on IBM's Power architecture, offering targeted strategies for
getting the most out of the Power Virtual Server platform.

Efficient resource allocation is crucial for optimizing performance, managing costs, and
ensuring stability for IBM AIX and Linux workloads on IBM Power Virtual Server. The right
approach to allocating CPU, memory, and storage resources can make a significant
difference in how effectively workloads run, especially for high-performance or
resource-intensive applications. Here are some key tips and recommendations for optimizing
resource allocation for AIX and Linux workloads.

5.2.1 Tips for efficient allocation of CPU, memory, and storage

This section provides some tips for allocation CPU, memory and storage efficiently.
1. CPU allocation
IBM Power Virtual Server allows for both dedicated and shared CPU configurations. For
workloads that require consistent, high-performance CPU usage (e.g., transaction-heavy
databases), dedicated processors are recommended. For less critical workloads, shared
processors provide cost-efficiency by allocating CPU cycles as needed from a shared
pool.
IBM Power architecture supports SMT, which allows each core to handle multiple threads
simultaneously. Adjusting SMT settings (SMT-2, SMT-4, or SMT-8) based on workload
requirements can optimize CPU utilization and improve throughput, especially for
multi-threaded applications.
For virtualized environments, it is essential to configure the correct number of virtual
processors. Allocating too many virtual processors can lead to CPU overcommitment,
while too few may cause performance bottlenecks. Monitor the CPU usage patterns of
your workloads to find the optimal virtual processor allocation.
2. Memory allocation
Allocate sufficient memory to prevent swapping, which can significantly degrade
performance. Analyze memory usage trends in AIX or Linux (using tools like top, vmstat,
or nmon) to estimate peak memory requirements, especially for applications with intensive
data processing.

150 Power Virtual Server for AIX and Linux

 If running multiple similar workloads, memory deduplication can help save resources by
sharing identical memory pages across workloads. IBM Power Virtual Server supports
memory management features that can help reduce memory usage, especially in
development and testing environments.
For applications that perform large, contiguous memory operations (such as databases),
using large page sizes (e.g., 16 MB) can reduce memory fragmentation and increase
memory access efficiency. Configuring large pages in AIX and Linux requires setting
kernel parameters, so be sure to consult application requirements before enabling them.
3. Storage allocation
IBM Power Virtual Server offers SAN attached IBM FlashSystem for high performance
storage. IBM Power Virtual Server offers you the option to select an I/O operation per
second (IOPS) based storage tier according to your requirement. Flexible IOPS is a
tier-less storage offering that removes the notion of disk type and replace it with a storage
pool. Each of the storage pools supports multiple storage tiers. The storage tiers are
based on different IOPS levels.
Plan storage with some headroom to accommodate growth and avoid performance
degradation due to disk space limits. Monitor disk usage to detect trends and add more
storage if utilization consistently reaches high levels.
Both AIX and Linux support LVM, which allows for flexible disk management by enabling
you to expand or reduce storage volumes as needed. This is particularly useful for
dynamically adjusting storage based on workload changes without interrupting the
application.

5.2.2 Recommendations for managing high-performance or

resource-intensive workloads
The following recommendations are intended to help you manage high-performance
workloads in Power Virtual Server.
1. Separate high-performance and low-performance workloads
High-performance workloads, such as databases or analytics applications, should ideally
be isolated on dedicated resources to avoid competition for CPU and memory with less
critical applications. Use dedicated CPU and memory allocation for these workloads,
ensuring that they have consistent access to resources.
If multiple workloads must run on the same server, consider setting QoS policies to
prioritize critical applications. This ensures that resource-intensive applications maintain
access to the CPU and memory they require, even when other workloads experience high
demand.
2. Optimize for disk I/O
Choose the appropriate IOPS based storage tier for your workload. Implementing disk
caching on frequently accessed data can reduce latency and improve overall I/O
performance. IBM Power Virtual Server can support I/O optimization features that make
data retrieval faster, especially for applications with repetitive read/write patterns.
3. Manage network bandwidth for high-performance applications
Optimize the network interfaces, high-performance applications often require efficient
network connectivity. Configure virtual network adapters with appropriate bandwidth and
use multiple network interfaces for applications that require high throughput.
Isolating high-priority traffic with VLANs can prevent network congestion and improve
performance. For example, dedicate specific VLANs for critical applications like
databases, analytics tools, or streaming applications to ensure uninterrupted bandwidth.

Chapter 5. Managing Workloads on IBM Power Virtual Server for IBM AIX and Linux deployments 151
 4. Monitoring and adjustment
Set up monitoring for resource utilization by implementing monitoring tools such as nmon
(AIX), top, vmstat, or IBM Cloud Monitoring to track CPU, memory, disk, and network
usage over time. Monitoring helps identify performance trends, pinpoint bottlenecks, and
enables proactive adjustments to resource allocations.
Based on performance metrics, consider adjusting CPU, memory, and storage allocations.
For example, if an application consistently uses high memory, allocate additional memory
to prevent performance dips. IBM Power Virtual Server's flexibility enables resource
adjustments with minimal downtime.
5. Use partition mobility for resource optimization
For workloads on IBM Power Systems, Power Virtual Server supports live partition
mobility, allowing you to move active workloads between servers without downtime. This
can help balance resource usage, distribute workloads evenly, and prevent overloading
specific resources.
If your environment experiences workload fluctuations, consider automating resource
balancing to allocate more resources during peak times and reduce them during off-peak
hours. This can optimize resource usage, reduce costs, and improve overall performance.

Effective resource allocation and optimization for IBM AIX and Linux workloads on IBM Power
Virtual Server involve careful planning, regular monitoring, and strategic adjustments. By
optimizing CPU, memory, and storage allocation based on workload requirements and
applying best practices for high-performance applications, organizations can maximize
efficiency, reduce costs, and maintain consistent performance. These strategies ensure that
critical AIX and Linux workloads perform reliably, leveraging the full potential of IBM Power
Virtual Server's architecture.

5.3 Monitoring and Performance management

Effective monitoring and performance management are essential for maintaining high
availability, optimizing resource usage, and ensuring that workloads on IBM Power Virtual
Server meet performance expectations. For IBM AIX and Linux environments, using the right
tools and techniques can provide valuable insights into system health, workload efficiency,
and potential bottlenecks. This section explores key tools for monitoring performance, as well
as best practices for setting up alerts, logs, and dashboards to streamline workload
management.

5.3.1 Tools and techniques for monitoring workload performance

This section describes some tools and techniques that can help you monitor workload
performance in Power Virtual Server.
1. Nmon for AIX and Linux
Nmon (short for Nigel's Monitor) is a powerful, lightweight system monitoring tool available
for both AIX and Linux. It provides real-time performance statistics on CPU, memory, disk
I/O, network, and more.
Key Features:
– Nmon provides real-time data on system performance, which helps administrators
quickly detect and resolve performance issues.
– Nmon offers granular metrics on CPU usage by core, memory utilization, disk activity,
and network throughput, making it ideal for comprehensive performance analysis.

152 Power Virtual Server for AIX and Linux

 – Batch Mode: In addition to real-time monitoring, nmon can be run in batch mode to
collect data over time, generating performance logs that can be reviewed later or
analyzed using visualization tools like nmon analyzer.
For AIX environments, nmon is highly valuable as it provides a native view of AIX's unique
performance characteristics. On Linux, nmon provides similar capabilities and is
compatible with popular distributions such as RHEL and Ubuntu.
2. Top for Linux
Top is a standard command-line tool in Linux that shows a dynamic, real-time view of the
running system, including CPU usage, memory consumption, and active processes.
Key Features:
– Top displays CPU and memory utilization per process, helping administrators
understand which processes are consuming the most resources.
– Administrators can sort and prioritize processes, providing the ability to troubleshoot
high resource usage in real time.
– Top allows users to customize its display to focus on specific metrics, making it
versatile for various performance monitoring needs.
Top is widely used on Linux systems for quickly identifying processes that consume
excessive resources. It's particularly useful for single-server environments or situations
where a quick, high-level view of system activity is needed.
3. Vmstat for AIX and Linux
Vmstat (virtual memory statistics) provides information on system processes, memory,
paging, block I/O, traps, and CPU activity. It's valuable for identifying memory bottlenecks
and monitoring the overall health of the system.
Key Features:
– Vmstat shows active memory and CPU usage, including metrics related to memory
paging and swapping, which are crucial for diagnosing memory constraints.
– Vmstat provides insights into disk I/O, helping administrators identify potential
disk-related performance issues.
The vmstat tool is often used alongside other tools like nmon and top for a more in-depth
analysis of memory and I/O usage, especially helpful for troubleshooting performance
issues related to memory contention or storage delays.
4. IBM Cloud Monitoring with Sysdig
IBM Cloud Monitoring with Sysdig is a cloud-native, enterprise-grade monitoring platform
that provides a unified dashboard for viewing and analyzing the performance of cloud
workloads.
Key Features:
– Sysdig offers pre-configured dashboards for monitoring CPU, memory, network, and
storage metrics across multiple instances providing comprehensive metrics and
dashboards.
– Sysdig provides detailed application insights so that administrators can gain visibility
into application performance, Kubernetes clusters, and containerized workloads.
– Sysdig integrates seamlessly with IBM Cloud for automated alerting and incident
management, making it easier to respond to performance issues in real time.
Sysdig is ideal for managing workloads in IBM Cloud environments, providing centralized
monitoring across multiple Power Virtual Server instances and simplifying the monitoring
of hybrid and multi-cloud deployments.

Chapter 5. Managing Workloads on IBM Power Virtual Server for IBM AIX and Linux deployments 153
 5. Sar (System Activity Report) for AIX and Linux
Sar is part of the sysstat package and provides historical data on CPU, memory, disk, and
network usage. It allows administrators to collect system performance data over time for
trend analysis and capacity planning.
Key Features:
– Sar logs system activity at regular intervals, making it possible to analyze performance
trends and historical data.
– Sar provides detailed reports on CPU usage, memory paging, disk I/O, and network
traffic.
Sar is useful for long-term monitoring and capacity planning, especially for workloads
where historical data is needed to identify performance patterns over time.

5.3.2 Tips on setting up alerts, logs, and performance monitoring dashboards

It is recommended that you set up alerts for performance changes. Monitoring performance
and gathering logs are very useful in providing a successful implementation.
1. Setting up alerts
Configure alerts for critical metrics such as CPU usage, memory utilization, disk space,
and network bandwidth. Setting thresholds (e.g., CPU usage > 80%) allows for proactive
issue detection and timely response.
Use incident-based alerts and set up alerts for specific incidents, such as process failures,
service unavailability, or disk I/O bottlenecks. Incident alerts can help detect
application-level issues that impact workload performance.
Integrate Alerts with Notification Channels and use tools like IBM Cloud Monitoring with
Sysdig to integrate alerts with notification systems (such as email, Slack, or PagerDuty).
This enables rapid response when thresholds are breached, ensuring that critical issues
are addressed promptly.
2. Configuring logs
Enable system logging services such as syslog or journals to capture important system
events, errors, and warnings. For application-level monitoring, configure logs for specific
applications to gain insights into their performance.
Use log aggregation tools like ELK Stack (Elasticsearch, Logstash, Kibana) or IBM Cloud
Log Analysis to centralize logs from multiple instances. Aggregated logs make it easier to
analyze trends and troubleshoot issues across the entire environment.
Set up log rotation and retention policies and configure log rotation to manage log file
sizes and retain critical logs based on regulatory requirements or data analysis needs.
This helps prevent storage overload and ensures that relevant logs are preserved for
future analysis.
3. Building performance monitoring dashboards
Customize dashboards for key metrics In IBM Cloud Monitoring with Sysdig or other
dashboard tools, create customized views for critical metrics like CPU load, memory
usage, disk I/O, and network latency. Tailor these dashboards based on workload types
(e.g., database, web server) to quickly identify bottlenecks.
IBM Cloud Monitoring offers pre-built dashboard templates for various environments,
including AIX and Linux. These templates provide a quick overview of system health,
reducing the time spent on dashboard setup.

154 Power Virtual Server for AIX and Linux

 Combine metrics for comprehensive insights. Group related metrics on dashboards for a
holistic view of workload health. For example, combine CPU, memory, and disk I/O on one
dashboard to identify potential correlations between resource usage and performance.
For long-term planning and analysis, include historical data on dashboards. Displaying
trends over days, weeks, or months can reveal patterns and assist with capacity planning,
enabling proactive adjustments to resource allocation.
4. Advanced techniques for proactive performance management
Use anomaly detection tools to identify unusual performance patterns that could indicate
potential issues. IBM Cloud Monitoring supports anomaly detection, helping you identify
irregular usage patterns before they escalate.
Implement automated scripts or workflows to take predefined actions when alerts are
triggered. For example, a high CPU alert can automatically initiate a script to allocate
additional resources or throttle non-essential processes.
Analyze historical performance data using tools like sar and Sysdig to predict future
resource needs. This is crucial for planning and preventing performance issues related to
capacity limitations.

5.4 User management and security settings

Effective user management and security settings are essential for protecting AIX and Linux
systems on IBM Power Virtual Server. By creating user roles, setting permissions, and
implementing robust security protocols, administrators can ensure that systems remain
secure and that users have appropriate levels of access. This section explores best practices
for managing users, configuring permissions, and setting up security features such as sudo
privileges and password policies.

5.4.1 Creating user roles and setting permissions for AIX and Linux
environments
It is important to define users, create user roles and sett the appropriate permissions in the
system.
1. Defining User Roles
Role-Based Access Control (RBAC): Implement RBAC to assign specific roles and
permissions to users based on their job responsibilities. For example:
– Administrator Role: Full access to system resources and configurations.
– Developer Role: Limited access to application files and testing environments.
– Operator Role: Permissions to monitor and manage basic operations but restricted
from critical system changes.
Create groups for role management - Use groups to manage roles efficiently. In AIX, use
the mkgroup command or smitty security to create groups, and in Linux, use the
groupadd command. Assign users to these groups to inherit predefined permissions.
2. Creating Users
Adding Users
– In AIX: Use the mkuser command or smitty user to create new users. Specify the
user's home directory, shell, and primary group during creation.

Chapter 5. Managing Workloads on IBM Power Virtual Server for IBM AIX and Linux deployments 155
 – In Linux: Use the useradd or adduser command to create users. For example, useradd
-m -d /home/username -s /bin/bash username creates a user with a home directory
and default shell.
Assigning Groups
– In AIX: Use chuser groups=<group1,group2> to assign a user to multiple groups.
– In Linux: Use usermod -aG <group> username to add a user to supplementary groups.
3. Setting Permissions
File and Directory Permissions
– Use chmod, chown, and chgrp to control access to files and directories. For example:
• chmod 750 /path/to/directory grants read, write, and execute permissions to the
owner, and read and execute permissions to the group.
• chown user:group /path/to/file changes the file ownership.
Access Control Lists (ACLs)
– For more granular permission control, use ACLs. In AIX, use the aclget and aclput
commands to manage ACLs, and in Linux, use setfacl and getfacl. ACLs allow you
to grant specific users or groups permissions beyond the standard file ownership
model.
4. Setting Up sudo Privileges, Configuring Passwords, and Implementing Basic Security
Protocols
– Setting Up sudo Privileges
• Install and Configure sudo:
In Linux, ensure the sudo package is installed. Use the visudo command to edit the
/etc/sudoers file for configuring privileges securely. For AIX, use smitty or manually
edit the sudoers file if sudo is installed.
• Grant Specific Commands to Users
Limit the commands users can run with sudo to reduce risk. For example, add a rule
like username ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx to allow
the user to restart a service without granting full administrative rights.
• Group-Based sudo Access
Assign sudo privileges to groups for easier management. For example, in Linux,
create a group (sudo) and add users to it. Add a rule in /etc/sudoers like %sudo
ALL=(ALL:ALL) ALL.
– Configuring Password Policies
• Enforce Strong Passwords
Use tools like password to enforce password complexity rules. In AIX, configure
password policies in /etc/security/user. For Linux, use pam_pwquality in
/etc/security/pwquality.conf to enforce length, complexity, and reuse limits. See
Example 5-1.

Example 5-1 pwquality.conf

pwquality.conf:
minlen = 12
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1

156 Power Virtual Server for AIX and Linux

 – Disk and Storage Configuration
• Configuring storage options such as Logical Volume Manager (LVM) for AIX and
Linux.
• Mount additional storage volumes or network-attached storage for enhanced
capacity.
5. Maintaining and Updating AIX and Linux Workloads
– Ensure that you do regular system updates and patching. Set up automated updates
and patches to maintain system security and performance.
– Use tools like Ansible or Chef to automate configuration management for AIX and
Linux.
6. Security and Compliance Considerations
– Implement firewall rules, intrusion detection, and securing data in transit and at rest.
– Use role-based access controls and audit trails for compliance.
– Set up continuous monitoring to meet regulatory requirements for AIX and Linux
systems. Use IBM Power Virtual Server tools for logging and compliance reporting.
For more information on security see IBM Power Security Catalog, SG24-8568

Chapter 5. Managing Workloads on IBM Power Virtual Server for IBM AIX and Linux deployments 157
158 Power Virtual Server for AIX and Linux
 6

Chapter 6. IBM Power Virtual Server Backup

An effective backup process is a vital part of any data center operation. It insures business
continuity and allows specific data recovery for historical and auditing purposes. IBM Power
Systems Virtual Server provides different tools to fit operational needs and includes some
constrains that are related to its cloud nature. This chapter describes different backup options
that can be used for normal operations, makes suggestions for backup strategies, and
discusses the differences between methods.

This chapter provides the following sections:

 “Backup and recovery best practices”
 “Backing up system image to Cloud Object Storage”
 “FalconStor StorSafe”
 “Tips on utilizing IBM Cloud's backup solutions for data resilience and quick recovery”

© Copyright IBM Corp. 2025. 159

6.1 Backup and recovery best practices
Implementing an effective backup and recovery strategy is crucial for maintaining data
integrity, ensuring business continuity, and minimizing downtime in case of unexpected
events. For IBM AIX and Linux workloads on IBM Power Virtual Server, a well-defined backup
and recovery plan can provide data resilience and enable fast recovery in the cloud
environment. Here's a detailed look at best practices for setting up regular backups and tips
for leveraging IBM Cloud's backup solutions.

6.1.1 Recommendations for setting up regular backups

1. Define a backup schedule based on data criticality
• Regular, Automated Backups: Automate backup schedules to ensure data
consistency and reduce the chances of missed backups. For critical workloads,
daily or even hourly backups may be appropriate, whereas less critical data might
only require weekly or monthly backups.
• Incremental and Differential Backups: To save storage space and improve backup
efficiency, use incremental or differential backups. Incremental backups capture
only the changes made since the last backup, while differential backups capture
changes since the last full backup, making both options more storage-efficient than
frequent full backups.
2. Set backup retention policies
• Data Retention Requirements: Define retention policies based on regulatory,
compliance, and business needs. For instance, financial data may need to be
stored for several years, while temporary application logs may only need short-term
retention.
• Storage Optimization: Consider lifecycle management for backup data to optimize
storage use. IBM Cloud's storage options allow data tiering to more cost-effective
storage options over time, freeing up space for recent backups while keeping
historical data accessible if needed.
3. Test Backup and Recovery Processes Regularly
• Scheduled Testing: Conduct regular recovery drills to test the integrity and reliability
of backups. Testing ensures that backup files are intact and that the recovery
process works as expected, reducing the risk of failure in a real recovery scenario.
• Validate Data Consistency: After each backup, validate that the backup is complete
and consistent. This can be done by performing data integrity checks or restoring
sample files, ensuring the data can be restored accurately when needed.
4. Use Encryption for Backup Data
• Data Security During Backup and Transit: Encrypt backup data both at rest and
during transit to protect sensitive information. IBM Cloud provides encryption
options to secure data stored in backup repositories, ensuring that it complies with
security standards and regulatory requirements.
• Key Management: Ensure proper management of encryption keys used for backup
data, either by using IBM Key Protect or a trusted key management system.
Effective key management practices help prevent unauthorized access and data
loss.

160 Power Virtual Server for AIX and Linux

 5. Implement Multi-Site Backup Replication
• Geo-Redundant Backups: For high availability and resilience, replicate backups
across multiple IBM Cloud regions or zones. This protects data from localized
failures, such as regional outages, and ensures that backups are accessible even if
one site experiences downtime.
• Offsite Backup Options: In addition to local backups, consider offsite backups
stored in geographically separate locations for disaster recovery, further enhancing
resilience and continuity.
6. Use Role-Based Access Control (RBAC) for Backup Management
• Limit Access to Backup Data: Restrict backup management permissions to
authorized personnel only, reducing the risk of accidental or malicious deletion of
backup files. IBM Cloud IAM (Identity and Access Management) allows you to set
granular permissions for backup-related actions.
• Logging and Audit Trails: Enable logging for backup operations to track who
accessed or modified backup files. Audit trails are useful for identifying and
investigating issues related to backup management.

6.2 Secure automated backup with Compass for AIX and Linux
IBM Cloud Partner Cobalt Iron provides an automated backup offering for AIX and Linux
instances of IBM Power Virtual Server. The backup offering is called Secure Automated
Backup with Compass referred hereafter as “Backup Offering.” The Backup Offering is
powered by Cobalt Iron Compass and is accessible from the IBM Cloud Catalog.

The Backup Offering provides enterprise-class backup and restore features in a cloud-centric
SaaS solution. Compass capabilities and security features, along with many other security
functions provides protection and self-assessments to protect enterprise data and
applications.

Cobalt Iron Compass protects various platforms, applications, and data classes. The Backup
Offering includes the following unique features and functions:
1. AIX operating systems
– File-level backup and restore
– Image-level backup and restore
– Policy management down to the directory and file object or type levels
– Back up and archive features that include long-term retention of data
2. Linux on Power operating systems
– File-level backup and restore
– Image-level backup and restore
– Policy management down to the directory and file object or type levels
– Back up and archive features that include long-term retention of data
3. Db2 on AIX databases
– Db2-integrated backup and restore of Db2 databases
– Db2-integrated archive logging of Db2 databases
4. Oracle on AIX databases
– RMAN-integrated backup and restore of Oracle databases
– RMAN-integrated archive logging of Oracle databases
– Support for Oracle Automated Storage Management (Oracle ASM) features

Chapter 6. IBM Power Virtual Server Backup 161

 5. SAP HANA on Linux on Power databases
– HDBackInt-integrated backup and restore of SAP HANA databases
– HDBackInt-integrated backup and restore of SAP HANA redo log files
– Support for the SAP HANA Cockpit for configuration, monitoring, and scheduling of
backups

For more information, see Cobalt Iron Documentation -

https://help.cobaltiron.com/getting-started-with-powervs-and-compass-commander/

The Backup Offering provides various integrated security and operational features including:
 Alerting, notifications, and ticketing features and integration
 Automated auditing and validation of backup server landscape
 Backup server automation that includes hands-free automation of all backup server tasks
 Centralized policy management
 Complete governance
 Data reduction through compression and deduplication
 Data replication across regions in IBM Cloud
 Encryption of data in all phases from in-transit, to-storage, and at-rest
 Extensive support for encryption, data immutability, and other security access controls
 Multi-tenancy and unlimited sub-organizations
 Role-based access control management.

Note: The Backup Offering is not currently applicable to the IBM i environment in Power
Virtual Server.

You can use the Backup Offering to back up your AIX and Linux virtual server instances in
IBM Cloud Power Virtual Server. To deploy the Backup Offering, complete the following steps:
1. From the IBM Cloud catalog, provision the Backup Offering for your account for a region.
2. Attach the Power Virtual Server workspace that you want to enable for backup zones to
the IBM Cloud Transit Gateway.
3. Access the Cobalt Iron Commander graphical interface to download the software and
install the agent inside the virtual machines.
4. Define the fine granular backup policies for your virtual server instances, files, and file
systems.

6.2.1 Architecture diagram

Figure 6-1 on page 163provides insights about how the Backup Offering is deployed and the
requirements for AIX and Linux VMs on Power to access the Compass backup servers
through IBM Cloud network. Compass backup servers are pre-configured in the data center
and are also replicated across to other regions.

162 Power Virtual Server for AIX and Linux

 Figure 6-1 Backup Offering network architecture diagram

It is highly recommended that you refrain from deploying any additional resources to Backup
Offering VPC. The Backup Offering VPC is the managed backup server instance that is
deployed when the Backup Offering is provisioned.

Upon deployment of the backup server instance, an automation process creates the
following:
 A local Transit Gateway if it does not exist
 A VPC for exclusive use of the backup activity
 A VPE for each of the backup servers
 Security group with inbound rule, address prefix, and subnet.

The Backup Offering VPC and the Power Virtual Server workspaces are required be present
in the same region and connected by using the local Transit Gateway. You can connect your
on-premises workloads to the Transit Gateway through a Direct Link connection. Alternatively,
a VPN connection will work the same and is equivalent to a Direct Link connection.

6.2.2 Deploying the backup instance

To create and deploy a backup server instance from the IBM Cloud catalog, complete the
following steps:
1. Log in to IBM Cloud catalog with your credentials.
2. In the search box, type Compass Backup and click Secure Automated Backup with
Compass tile.
3. Select a deployment location for your backup instance.
4. Define these fields:
– Pricing plan
– Service name
– Resource group
– your IBM Cloud API key as per your business needs.

Chapter 6. IBM Power Virtual Server Backup 163

 5. Click Create.
6. Connect the newly created VPC and the Power Virtual Server workspace that you want to
back up by using the local Transit Gateway.
You can use you existing Transit Gateway or create a new one.
7. Click Launch Compass UI. This will redirect you to the Cobalt Iron Compass page where
you will complete the setup.

For more information:

 Ordering IBM Cloud Transit Gateway
https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-ordering-trans
it-gateway&interface=ui
 Using virtual private endpoints for VPC to privately connect to IBM Cloud Transit Gateway
https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-vpe-connection
&interface=cli

6.2.3 Pricing
When you use the Backup Offering, you are billed monthly through IBM Cloud for amount of
data backed up for the region at an hourly rate. For current pricing see Cobalt Iron Pricing.

Connectivity between Power Virtual Server instances and the backup servers is established
via a Transit Gateway connection to the backup VPC. Name resolution for the backup server
connections is also required. You can accomplish this using the agent system's /etc/hosts file,
or by adding CNAME entries to your agent system's DNS server. These elements need to be
deployed in your account. The Transit Gateway and VPC provisioning and setup happens
through automation when the Backup Offering is provisioned.

Supported data center pairs

The Backup Offering is currently available in the locations shown in Table 6-1.

Table 6-1 Data center pair availability for backup offering

Data Center 1 Data Center 2

DAL10 WDC07
DAL12 WDC06

MAD02 FRA04
MAD04 FRA05
SAO01 SAO04
OSA21 TOK04

SYD04 SYD05

Additional support
Support for the Backup Offering is provided by Cobalt Iron and you need to have login
credentials to Cobalt Iron to access the following:
 For issues related to backup and restore, reach out to Cobalt Iron by opening a service
ticket via support URL.
 If you encounter an issue that is related to Power Virtual Server or IBM Cloud, see Getting
help and support.

164 Power Virtual Server for AIX and Linux

 Additional backup strategies
IBM teams and managed services: You can engage these IBM teams and services to assist
you throughout the migration lifecycle.
 Expert Labs
 IBM Services® for Cloud Migration

6.3 Backing up system image to Cloud Object Storage

In Chapter 4.2, “Migrating AIX to a Power Virtual Server through Cloud Object Storage” on
page 1134 we discussed using Cloud Object Storage and image capture to migrate systems
to Power Virtual Server. This same concept can be used as a back up. Image capture
produces a storage FlashCopy of the logical partition (LPAR) and works on AIX, Linux, and
IBM i LPARs.

You can use image capture to store VM images within your account (locally) as a part of your
image catalog, directly to IBM Cloud Object Storage, or both.

Importing and exporting images requires a considerable amount of processing power and
network bandwidth. As a result, you can submit only one import or export request before it is
queued. Typically, users import or export system disks (AIX rootvg disks) that are smaller in
size (less than 1 TB) to facilitate the transfer to and from Cloud Object Storage. If your image
size is greater than 1 TB, your transfer might take a long time and be prone to failure. The
maximum uncompressed image size that you can import or export is 10 TB.

Cloud Object Storage

The preferred ways to connect to Cloud Object Storage from a VM in Power Virtual Server are
as follows:
1. In a PER workspace, attach the Power Virtual Server workspace to a Transit Gateway and
directly access the Cloud Object Storage direct endpoint.
For more information regarding attaching transit gateway -
https://www.ibm.com/docs/en/power-virtual-server?topic=premises-getting-started
-power-edge-router#migrate-per
2. In a non-PER workspace that are in a multi-zone region (MZR) the best way to connect to
Cloud Object Storage is as follows:
– Create a Virtual Private Cloud (VPC) with subnets in the same region as your Power
Virtual Server workspace.
– Create a Virtual Private Endpoint gateway (VPE).
– Connect the VPC to a Transit Gateway.
– Create a cloud connection to connect the non-PER Power Virtual Server workspace to
the same Transit Gateway.
The Power Virtual Server would then use the VPE's IP address to connect to Cloud Object
Storage. A Custom Resolver (CR) is needed by the Power Virtual Server to reach the
Cloud Object Storage. If the VPE has multiple IP addresses, you can set up custom DNS
and a custom hostname to connect to Cloud Object Storage.
3. Deploy a Nginx reverse proxy server in either the classic or VPC infrastructure.
Nginx is a mature, compact, and fast open source web server that excels at specialized
tasks, including the reverse proxy server role. For information on setting up a Nginx
reverse proxy server see this IBM Cloud document.

Chapter 6. IBM Power Virtual Server Backup 165

 Cloud Object Storage on AIX
IBM Power Systems that are running AIX 7.2 TL3, or later, have a script that is located in the
path /usr/samples/nim/cloud_setup. The cloud_setup command installs the command-line
environment for cloud storage services.

cloud_setup [-I | G | C] [-v]

• I: Install the necessary RPMs for universal CLI (supports Cloud Object Storage).
• G: Install the necessary RPMs for gsutil CLI (Google Cloud Storage).
• C: Install the necessary RPMs for cloud-init.
• v: Enable debug output.
1. To begin, copy the file to the system that requires AWS and give it run permission.
2. Enter the cloud_setup -I command to install the AWS CLI and all of the dependent
RPMs.
3. After the installation is complete, you must configure awscli for access to Cloud Object
Storage and provide the correct region (where your bucket Cloud Object Storage is
defined) in the aws --endpoint-url s3 command. This is shown in Example 6-1 using
region us-east.

Example 6-1 Cloud object config

# export PATH=$PATH:/opt/freeware/bin
# aws configure
AWS Access Key ID [None]: d197axxxxxxxxxxxxxxxxxxxxxxxxxxxa4
AWS Secret Access Key [None]: f52a5xxxxxxxxxxxxxxxxxxxxxxx001a33b74d8
Default region name [None]: us-east
Default output format [None]: json
# aws --endpoint-url https://s3.us-east.cloud-object-storage.appdomain.cloud s3 ls
2019-01-28 13:32:40 poweriaastest
# aws --endpoint-url https://s3.us-east.cloud-object-storage.appdomain.cloud s3 ls
s3://poweriaastest
2019-01-28 13:33:42 6832 nimstat.sh
2019-01-28 15:05:25 1380725 yum-3.4.3-5.aix6.1.noarch.rpm

6.4 FalconStor StorSafe

FalconStor StorSafe is a backup and deduplication solution featuring Virtual Tape Library
(VTL) emulation, fast backup and restore speeds. It includes data archiving to S3-compatible
clouds, global deduplication, and enterprise replication, all without requiring changes to your
existing infrastructure.

Your existing backup software can be combined with the VTL emulation provided by StorSafe
to provide an enterprise level backup and restore solution for your Power Virtual Server
instances, whether they are running AIX, Linux or even IBM i.

StorSafe also supports NFS and SMB interfaces in a NAS environment. AIX and Linux
systems can use StorSafe as an NFS server for applications such as Oracle RMAN or SAP
Hana Studio. You can also store backup files created with the Veeam Agent for IBM AIX on
backup repositories managed by Veeam Backup & Replication (VBR).

FalconStor StorSafe is available as an option in the IBM Cloud catalog. For more information,
see FalconStor StorSafe

166 Power Virtual Server for AIX and Linux

6.4.1 Tips on utilizing IBM Cloud's backup solutions for data resilience and
quick recovery
1. IBM Cloud Backup for Automated Backup Management
• IBM Cloud Backup allows you to define policies that automate the backup process,
such as specifying the backup frequency, retention, and encryption options. This
ensures that backup schedules are maintained consistently across workloads,
minimizing the risk of human error.
• IBM Cloud Backup supports full, incremental, and differential backups, giving you
flexibility in designing a strategy that balances storage efficiency with data recovery
speed.
2. Use IBM Storage Protect for enterprise-grade backup and recovery
• IBM Spectrum Protect offers advanced backup and recovery capabilities, including
deduplication, compression, and incremental backups, to reduce storage
requirements and improve backup efficiency.
• IBM Storage Protect is designed for fast, scalable recovery of data, making it ideal
for businesses that require quick restoration times. This is particularly valuable for
mission-critical AIX and Linux workloads that need minimal downtime.
3. Leverage IBM Cloud Object Storage for cost-effective, scalable backup storage
• IBM Cloud Object Storage provides a scalable and cost-effective solution for storing
large volumes of backup data. Cold or archival storage options are ideal for
long-term backups that may not require frequent access, helping reduce storage
costs.
• IBM Cloud Object Storage offers multiple storage classes, allowing businesses to
move backup data to more affordable storage tiers over time. This is particularly
useful for backups that follow a retention policy but don't need to be readily
accessible.
4. Use IBM Power Virtual Server for AIX and Linux Virtual Machine Snapshots
• IBM Power Virtual Server provides snapshot capabilities for virtual machines,
enabling quick, point-in-time backups for AIX and Linux environments. Snapshots
allow for fast recovery from issues like configuration errors or software crashes, as
they can be easily reverted to a previous state.
• With Power Virtual Server, set up automated snapshot schedules to capture regular
backups without manual intervention, ensuring that you always have recent
recovery points available.
5. Implement IBM Disaster Recovery as a Service (DRaaS)
• IBM's DRaaS includes backup and recovery capabilities that extend beyond regular
data backups. It encompasses failover capabilities and business continuity plans,
enabling businesses to quickly recover entire environments in the event of a major
disaster.
• DRaaS can automate failover to secondary sites, minimizing downtime for critical
AIX and Linux applications. This is particularly useful for industries with strict uptime
requirements, such as finance and healthcare.
6. Configure alerts and monitoring for backup failures
• Set up automated alerts to notify administrators of backup failures, storage limits, or
connectivity issues. These alerts allow for prompt intervention to address issues
before they impact data protection.

Chapter 6. IBM Power Virtual Server Backup 167

 • Use IBM Cloud Monitoring tools to monitor backup operations, ensuring that
backups are completed successfully and identifying any bottlenecks or performance
issues. Performance monitoring can also help optimize backup schedules and
resource allocation.
7. Use cross-region replication for multi-region availability
• By replicating backup data across multiple IBM Cloud regions, organizations can
protect their data from regional outages. Cross-region replication ensures that data
is available for recovery even if one region faces an extended downtime.
• Cross-region replication can support compliance with data residency requirements,
ensuring that data remains available in multiple locations in line with legal and
regulatory standards.

Establishing a solid backup and recovery plan for IBM AIX and Linux workloads on IBM Power
Virtual Server is essential to ensure data resilience, regulatory compliance, and business
continuity. By following best practices for scheduling, encryption, multi-site replication, and
retention policies, organizations can protect their data effectively. Leveraging IBM Cloud's
suite of backup solutions-such as IBM Cloud Backup, IBM Spectrum Protect, IBM Cloud
Object Storage, Power Virtual Server snapshots, and DRaaS-enables flexible and scalable
data protection strategies. These solutions provide the tools needed for efficient backup
management and quick recovery, helping organizations minimize downtime and mitigate data
loss in the face of unexpected disruptions.

168 Power Virtual Server for AIX and Linux

 A

Appendix A. Global Replication Services

solution using Power Virtual
Server
This appendix describes how to build a replication solution using Power Virtual Server
including use cases and examples that you can apply in your deployments.

This appendix contains the following sections:

 “Solution overview”.
 “Setup for Global Replication Services”.
 “Failover and failback”.
 “Disabling the replication”.

© Copyright IBM Corp. 2025. 169

A.1 Solution overview
IBM Power clients run mission-critical workloads. To ensure business continuity during
uncertain conditions, you need a secure, highly available solution, which can aid in disaster
recovery (DR). Planning such an environment is complex and might require large capital
expenditures to configure CPU needs, capacity, and advanced network and storage
requirements.

IBM Power Virtual Server cloud provides a Global Replication Services solution that provides
the replication capability to your workloads by maintaining the benchmarks for Recovery Point
Objective (RPO) and Recovery Time Objective (RTO) as shown in Figure A-1.

Figure A-1 Recovery time graphics

Global Replication Services (GRS) uses IBM Storwize® Global Mirror with Change Volumes
(GMCV) asynchronous replication. A Power Virtual Server GRS solution provides access to
IBM Cloud API and CLI to create and manage replication-enabled volumes.

Global Replication Services on Power Virtual Server include the following benefits:
– At the remote site, maintain a consistent and recoverable copy of the data, which is
created with minimal impact to applications at your local site
– Efficiently synchronize the local and remote sites with support for failover and failback
modes, helping to reduce the time that is required to switch back to the local site after a
planned or unplanned outage
– Replicate more data in less time to remote locations
– Maintain redundant data centers in distant locations for rapid recovery from disasters
– Eliminate costly dedicated networks for replication and avoid bandwidth upgrades

Figure A-2 is an example showing the use of GRS between data centers DAL12 and WDC06.

Figure A-2 Data centers diagram

170 Power Virtual Server for AIX and Linux

 You can use the GRS location APIs to determine the locations that support storage replication
and their mapped location. For more information, see all disaster recovery locations that are
supported by Power Virtual Server in API documentation.

Table A-1 shows the location pairs that support replication.1

Table A-1 Replication-enabled Power Virtual Server region pairs

Location 1 Location 2

mad02 eu-de-1 (fra04)

mad04 eu-de-2 (fra05)

us-east (wdc04) us-south (dal13)

wdc06 dal12

wdc07 dal10

osa21 tok04

syd04 syd05

sao01 sao04

mon01 tor01

lon04 lon06

A.2 Setup for Global Replication Services

The data centers for IBM Power Virtual Server are configured to have all the required
replication capabilities as shown in Figure A-3.

Figure A-3 IBM Cloud solution diagram

1
For the latest list of supported locations go to
https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-getting-started-GRS#locations-GRS

Appendix A. Global Replication Services solution using Power Virtual Server 171
 Supported tier 1 and tier 3 storage controllers are preconfigured to use replication by using
Global Mirror with Change Volumes (GMCV). GRS provides the replication at the storage
level by using GMCV asynchronous replication. When using GMCV, the initial synchronization
copies the entire data from master to auxiliary. After the initial synchronization, only the delta
changes are synchronized with the periodic interval of 500 seconds, which means the
maximum RPO will be 1000 seconds, which is approximately 16–17 minutes.

For every replicated volume that is created, 4 volumes are created across 2 sites as shown in
Figure A-4:
1. Primary volume on site1.
2. Primary change volume on site1 to store the delta changes.
3. Auxiliary volume on site2.
4. Auxiliary change volume on site2 to update the delta changes.

Figure A-4 Volume diagram, remote consistency group

GMCV uses a remote copy consistency group to ensure that the data that is spread across
multiple volumes are consistent while the data is copied to remote sites. Also, it helps to
switch the replication direction during the time of planned and unplanned outages. GRS API
and CLI can be used to create and manage replicated volumes and consistency groups.

For example when using DAL12 and WDC06 data centers enabled to use GRS APIs. If you
are using DAL12 as a primary site, then auxiliary volumes are created on WDC06. And if you
are using WDC06 as a primary site, then auxiliary volumes are created on DAL12. The site
where volumes are created or enabled for replication is the primary site.

After you have the volumes replicated at both primary and secondary, you can use “Disaster
recovery workflow” on page 173 to start the standby VM by using the replicated volumes.

A.2.1 DR location sites

Identify the replication-enabled sites, by using the Power Virtual Server drl CLI command:
ibmcloud pi drl --all-regions --json

172 Power Virtual Server for AIX and Linux

 Figure A-5 shows that dal12 and wdc06 are active replication sites.

Figure A-5 CLI ibmcloud drl list example

Create a Power Virtual Service instance on each replication enabled site. After you create the
service instances, you can list the instances to find the Cloud Resource Names (CRNs) by
using the ibmcloud pi service-list command.

A.2.2 Disaster recovery workflow

As an example, consider an AIX VM running an Oracle database application workload on the
primary site, DAL12 data center. Configure GMCV to back up the data volumes in case you
need to recover the Oracle database. Refer to Figure 6-2.

Figure 6-2 Disaster Recovery (DR) data center configuration

Appendix A. Global Replication Services solution using Power Virtual Server 173
 Figure A-6 shows the steps to enable the replication for your application workload that is
running on the primary site and make it ready to trigger failover and failback.

Figure A-6 DR recovery workflow diagram

A.2.3 Creating and enabling volume replication

The first step for replicating VM volumes is to select or create volumes to replicate. You can
either create new replication-enabled volumes, or you can select existing volumes to enable
replication. When replication is enabled on the volume, an auxiliary mirror on the remote
storage controllers is defined, and the replication relationship is defined.

Figure A-7 shows an AIX VM with volumes (vol1, vol2, and vol3), and after enabling
replication, it creates aux_vol1, aux_vol2 and aux_vol3 on the auxiliary storage. These
volumes are not visible and are managed by the service broker workspace.

Figure A-7 Replicated volume creation diagram

174 Power Virtual Server for AIX and Linux

Creating a replication enabled volume
A new option, replication-Enabled, has been added for creating a replication-enabled
volume as shown in Figure A-8:
ibmcloud pi volc volume_name --size 1 --replication-enabled –type <tier_level>

Figure A-8 Command to create a replication-enabled volume

Converting existing volumes to replication enabled volumes

You can convert existing volumes to replication enabled provided the volume pool supports
replication capability as shown in Figure A-9:
ibmcloud pi vola <volume_name> --replication-enabled=true

Figure A-9 Ibmcloud CLI list replicated volumes

Viewing replication properties of the volume

Use the command ibmcloud pi vol testVol1 --json to retrieve the volume details. If the
replicationEnabled field is true, then replication is enabled on the volume. See Figure A-10.

Figure A-10 Listing properties of a volume

Appendix A. Global Replication Services solution using Power Virtual Server 175
 The properties of the volume include the following
masterVolumeName
The name of the master volume.
auxVolumeName
Name of the auxiliary volume
auxiliary
if status is true, then the volume is an auxiliary volume. If the value is false, then the
volume is the master volume.
primaryRole
Specifies how the volume is being used.
replicationStatus
If the field is enabled, then the volume is enabled for replication and is active.
mirroringState
Specifies the state of the replication relationship. If the value is consistent_copying, then
the two sites are in sync.

A.2.4 Creating and updating the volume group

Create a volume group and add the replication-enabled volumes to the volume group. This
creates a remote replication consistency group for both the primary and the remote auxiliary
storage. This process stores the consistent copy for the volumes. When the volume group is
created, it assigns the primary role as master. See Figure A-11. When replication-enabled
volumes are created on th Primary site, the corresponding auxiliary volumes are created on
the Secondary site.

Figure A-11 Create and update a volume group

176 Power Virtual Server for AIX and Linux

Creating a volume group
Figure A-12 shows that the CLI can be used to create a volume group and add
replication-enabled volumes. You can add only replication-enabled volumes to a volume
group.

Figure A-12 Ibmcloud create volume group from CLI

The member-volume-ids parameter is a space-separated list of volume IDs to add to the

volume group. All volume IDs must belong to the same storage pool. Otherwise, the
command fails. At least one volume is mandatory to create a volume group. A volume can
only be part of a single volume group at a time.

Volume group properties

You can view the basic properties of a volume group by using the ibmcloud pi vg command
as shown in Figure A-13.

Figure A-13 List of volume group properties

The output of the ibmcloud pi vg <volume-group-id> --long --json command includes the
status of the following properties:
consistencyGroupName
The name of the replication consistency group which is created at the storage level. This
field is the same for a replication consistency group across the two sites.
volumeIDs
Lists the volume IDs in the volume group.
statusDescription
Populated if there are any failures while adding the volumes to the volume group.
status
The current state of the volume group. Status available means it is active. Possible values
are available, error, updating, and creating.

Appendix A. Global Replication Services solution using Power Virtual Server 177
 replicationStatus
The replication state of the volume group.

When a volume is part of a replication volume group. The output of the command includes the
group_id and consistencyGroupName fields in the volume group details.

Getting volume group storage details

To retrieve the properties of the volume group storage details using the vgsd parameter, use
the following command:
ibmcloud pi vgsd <volume_group_name> --json

The output of the command to retrieve volume storage details includes the current
consistency group information from the storage back end. See Figure A-14.

Figure A-14 Ibmcloud get volume storage details json formatted

cyclePeriodSeconds
Duration in seconds between the start of a remote copy
remoteCopyRelationshipNames
Remote copy relationships that belong to the consistency group
state
The current status of a consistency group, which includes the following possible states:
– consistent_copying
– inconsistent_copying
– inconsistent_stopped
– idling
– idling_disconnected
– inconsistent_disconnected

Retrieving volume group relationship details

To list more detailed information of the remote copy relationships of the volume group use the
following command:
ibmcloud pi vgrcr <volume_group_name> --json

178 Power Virtual Server for AIX and Linux

The output of the command is listed in Figure A-15.

Figure A-15 Get volume relationship details

The output of the ibmcloud pi vgrcr includes the following properties:

remoteCopyrelationships
Shows the relationship details for each replicated volume which are part of volume group.
freezeTime
Indicates the time in the format yy-mm-ddThh:mm:time_zone. when the last sync
happened. This parameter is used to monitor the RPO.
progress
The current percentage of how much of the data has been copied. A value of 100 means
the two sites are in sync.

After the volume group is created, if its current state is consistent_copying, then the volume
data is copied to the secondary site.

Switching to the secondary site (WDC06)

To move to the secondary site use the st parameter to set the service target. In this example,
the secondary site is wdc06. The following command entered on one line sets the service
target to the secondary site:
ibmcloud pi st crn:v1:bluemix:public:power-iaas:wdc06:a/
2bb3df23c0d14ebe921397bd8aa2555a:56ee5081-f4cf-4d19-8bd6-4fdaa60c9999::

Appendix A. Global Replication Services solution using Power Virtual Server 179
 Onboarding auxiliary volumes
Although auxiliary volumes are in the backend storage of the secondary site, these volumes
are not managed by the current Power Virtual Server workspace. Configure the auxiliary
volume, so it can be managed and accessed by the cloud user. The onboard operation
requires a source CRN that is used to verify if the remote user has required permissions to
access and onboard the auxiliary volumes. Permissions are based on the owner of the paired
primary volumes. If the user does not have valid permissions, then the onboard operation fails
with an authentication error. Refer to Figure A-16.

Figure A-16 Onboard auxiliary volumes

As part of the onboard auxiliary volume operation, the required volume IDs are created to
manage the existing auxiliary volumes. If the auxiliary volumes are part of the consistency
group, the onboard operation also creates the volume group IDs to manage the existing
consistency group.

Onboarding the auxiliary volumes with the CLI

The following command creates an onboarding job testOnboarding to onboard two auxiliary
volumes for source-crn (refer to Figure A-17):
ibmcloud pi voloc --source-crn crn:v1: bluemix:public:power-iaas:dal10:
2bb3df23c0d14ebe921397bd8aa2555a:56ee5081-f4cf-4d19-8bd6-4fdaa60c8888::
--description testOnboarding --auxiliary-volume
"aux_volume-testVol1-afd07003-a61a1210664 recoveryVol1" --auxiliary-volume "
aux_volume-testVol2-7a9f1ca6-acec1210664 recoveryVol2"

Figure A-17 Ibmcloud onboard volume

180 Power Virtual Server for AIX and Linux

Checking onboard progress
The onboard operation returns the onboarding UUID, which can be used to check the status
of the onboarding operation. The onboarding operation is an asynchronous operation. The
time to complete the onboarding depends upon the number of volumes. Use the command
ibmcloud pi volog <onboarding_ID> to view the status of the onboarding process. See
Figure A-18.

Figure A-18 Ibmcloud check onboard status

The status field lists whether the onboarding process completed successfully. If the
onboarding completes successfully, the results field lists the onboarded auxiliary volumes.

After completion of the onboard operation, you can view the auxiliary volumes by using the
volume list, or you can retrieve the volume details by using the volume name. Volume IDs and
group ID for the master and auxiliary volume pair are different on the primary and the
secondary sites. However, you can view other fields such as masterVolumeName,
auxVolumeName, and consistencyGroupName.

Figure A-19 and Figure A-20 on page 182 show the volume and the volume group details that
are created after the onboard operation.

Figure A-19 Ibmcloud list volume information

Appendix A. Global Replication Services solution using Power Virtual Server 181
 Figure A-20 Ibmcloud list volume information json format

Deploying the standby VM on the secondary site

After onboarding the auxiliary volumes and volume group on the secondary site, provision a
standby VM on the secondary site and attach the auxiliary volumes as shown in Figure A-21.
Keep the VM powered off and use it only if there is a disaster. The auxiliary volumes are
read/write protected. While a primary site is up, only a primary site can perform I/O on the
volumes. When the primary site is down, the consistency group is stopped by allowing read
permission, then read/write operations are allowed on only the auxiliary volumes.

Figure A-21 Deploy machine on remote site

You can use the existing commands to provision and attach volumes. For more information,
see ibmcloud pi instance-create and ibmcloud pi volume-attach.

182 Power Virtual Server for AIX and Linux

A.3 Failover and failback
During a disaster such as a primary site failure or storage failure, you lose access to the
storage volumes, and these are marked with an ERROR. See Figure A-22. The replication
relationship is disconnected, and the consistency group status is consistent-disconnected.
The volume group primary role is no longer defined.

Figure A-22 Failover and failback diagram

If a site is down, then no new replication operations are allowed. Access existing workloads
by powering on the standby VM and auxiliary replication volumes from the secondary site
after giving them read access.

A.3.1 Steps to take after a primary site failure

This section describes the three steps to take during disaster recovery:
1. Access auxiliary volumes on primary site failure
2. Failover or switch volume group role to secondary
3. Failback to primary site

Accessing auxiliary volumes after primary site failure

To allow read/write I/O on auxiliary volumes during a primary site failure, stop the volume
group with the command --allow-read-access as shown in Figure A-23

Figure A-23 Ibmcloud CLI failover and failback

Appendix A. Global Replication Services solution using Power Virtual Server 183
 After the volume group is stopped, the remote copy consistency group changes to a state of
idling, and the replication status is disabled. See Figure A-24

Figure A-24 Viewing the state of the remote copy consistency group

Power on the standby VM and run the instructions to access your application configured on
the auxiliary volumes.

Performing a failover or switching the volume group role to auxiliary

When the primary site is recovered, you can restart the consistency group to restart the
replication. You can start the volume group to switch the role to auxiliary and to change the
replication direction from secondary to primary. This allows the auxiliary volume delta
changes to be copied to the master volumes to synchronize the volumes. See Figure A-25.

Figure A-25 Failover diagram

184 Power Virtual Server for AIX and Linux

 Figure A-26 shows the command that can be used to start the volume group and Figure A-27
shows the switched role to auxiliary.

Figure A-26 Starting the volume group

Figure A-27 Switching roles

Performing a failback to the primary site

To switch back the volume group to the primary site, use the same volume group start
command without the –source option. See Figure A-26.

A.4 Disabling the replication

Disabling the replication deletes the auxiliary volume from the remote site. Before disabling
the replication, check that the replication is not associated with any group. Because there are
two sites, follow the procedure for disabling the replication.

A.4.1 Removing the volumes from the volume group on the primary site
If the volume is a part of any volume group, then remove the volume from its associated
volume group as demonstrated by the following example command:
ibmcloud pi vgu 5bbe734a-7ec6-4f0a-a34e-8bd45fc189ca --remove-member-volume-ids
afd07003-a61a-45ca-97d1-4f910272306d

See Figure A-28.

Figure A-28 Removing a volume from a volume group on the primary site

Appendix A. Global Replication Services solution using Power Virtual Server 185
A.4.2 Disabling the replication of a volume
When you disable the volume replication, this removes the replication relationship and
deletes the auxiliary volume. Use the following command as an example to disable the
volume replication:
ibmcloud pi vola afd07003-a61a-45ca-97d1-4f910272306d –replication_enabled=False

Figure A-29 Disabling the replication of a volume

Disabling replication is an asynchronous process. View the volume details to verify that
volume replication is disabled as shown in Figure A-30.

Figure A-30 Check replication disable

Removing the volumes from a volume group on a secondary site

Update the volume group of the secondary site to remove the volumes from it:
ibmcloud pi vgu 96e037e3-9effd-4d6d-90cf-d1f6cc76d6c3 --remove-member-volume-ids
ba147c20-578a-4ae1-8a94-252b6bbcd9cb

If the volume group is empty, then you can delete the volume group:
ibmcloud pi vgd 96e037e3-9efd-4d6d-90cf-d1f6cc76d6c3

Delete the auxiliary volume from secondary site

Finally delete the auxiliary volume reference from the secondary site with the following
command:
ibmcloud pi vold afd07003-a61a-45ca-97d1-4f910272306d

If the auxiliary volume is not deleted from the secondary site, then this volume moves to an
error state because these volumes no longer exist in the storage back end. The error is
triggered by an out-of-band periodic verification over an interval of 24 hours.

186 Power Virtual Server for AIX and Linux

A.5 Billing and charging
You are charged from the location where you create a replication-enabled volume. There are
no charges for the auxiliary volume from the remote site.

The cost of a volume is based on the following factors:

– The master volume is charged 2x its size based on its Tier under the existing part
numbers for Tier 1 and Tier 3.
– Replication capability cost is charged per GB under a new part number
GLOBAL_REPLICATION_STORAGE_GIGABYTE_HOURS that is independent of
volume tier.

Upon a site failure due to a catastrophe, metering is not available from the failed site. The
auxiliary volumes are charged from remote site for its 2x size based on its tier. There is no
replication capability cost for any replication-enabled volume.

A.6 Troubleshooting
This section provides some problem determinations procedures.

A.6.1 Starting a volume group in any site

You can start and stop a volume group from any site. But it is a best practice to use the
primary site for all the volume operations and perform operations on the auxiliary volume on
the secondary site only during failover.

A.6.2 Volume group replication status is not in sync across two sites
Examine the storage details of the volume group to check the actual replication status of the
volume group, not the volume group details.

The start and stop operation on the volume group updates the replication status of the volume
group on the site from where the start and the stop operations are performed, but it does not
update the replication status of the corresponding volume group on the other site.

A.6.3 Determining whether an update on the volume group fails

Updates on the volume group are asynchronous operations. List the volume group details to
verify the results. If there is any error during the update operation, then the
statusDescription(errors) field provides the error details from the last failed operation.

A.6.4 The update on a volume group is not working as its status is in error
state
You can perform a reset operation on the volume group. This action does not change the
replication status but sets its status to available so that updates can be performed on the
volume group.

This action does not clear the errors field from the volume group. The next successful update
operation resets this field.

Appendix A. Global Replication Services solution using Power Virtual Server 187
A.6.5 Determining which volume is defined as primary for a volume group
Retrieve the storage-details of a volume group and check the primaryRole field. A master
value indicates that master volumes are playing the primary role.

A.6.6 Onboarding new or existing volumes in a volume group

You can create one or more onboarding operations with the required volume list. The
onboarding operation onboards new volumes with an existing volume group.

A.6.7 Adding more volumes to a volume group after the onboarding operation
Add volumes to the volume group on the primary site and then onboard the volumes on the
secondary site.

A.6.8 Deleting a volume from one site but not from the other site
The replicated volume that is managed on its corresponding remote site moves to an error
state in an interval of 24 hours. Any operation on this replicated volume fails except a delete
operation.

Delete the volumes from the primary site. Otherwise, master volumes are charged when you
delete the auxiliary volume but fail to delete the master volume.

A.7 References
 IBM Power System Virtual Servers API Reference
https://cloud.ibm.com/apidocs/power-cloud
 IBM Power System Virtual Servers CLI Reference
https://cloud.ibm.com/docs/power-iaas-cli-plugin?topic=power-iaas-cli-plugin-power-iaas-
cli-reference

188 Power Virtual Server for AIX and Linux

 B

Appendix B. Migration planning

Planning to move your existing workloads to Power Virtual Server requires that you
understand your current environment and plan carefully to correctly size the Power Virtual
Server instances, ensure that the proper networking connections are available, ensure that
you provide the appropriate tools and connections to backup and restore your data, and
ensure that you have planned for any high availability and disaster recovery requirements.

This appendix is intended to provide a high-level guide to some of the planning tasks that
need to be addressed as you develop your migration plan. It is not intended to be
comprehensive but is a starting point.

If you would like additional assistance in planning your move to Power Virtual Server, there
are many services available from IBM and IBM business partners to help you build and
execute a plan for your migration. For further details see this IBM Cloud document.

The following topics are covered in the appendix”

 Migration Planning
 Application assessment
 Sizing

© Copyright IBM Corp. 2025. 189

B.1 Migration Planning
Before moving existing workloads to IBM Power Virtual Server, you need to understand the
current environment and determine the appropriate Power Virtual Server configuration. To
properly design your Power Virtual Server instances, you need to:
 Assess the applications running on the current infrastructure to ensure that you can
successfully move them to your Power Virtual Server instances. See B.2, “Application
assessment” on page 190.
 Determine the correct sizing for your Power Virtual Server instance. This covers the CPU,
memory and storage for each instance.
– To determine the correct CPU configuration in your Power Virtual Server see, B.3.1,
“Compute sizing” on page 191.
– To size the memory in your Power Virtual Server, determine the current memory usage
in your LPAR using tools like nMon. This may be smaller than the amount of memory
that has been allocated to the LPAR, depending on your workload.
Power Virtual Server instances must be provisioned with a minimum of 2 GB of
random-access memory (RAM). The maximum amount of memory varies based on
machine type and availability in the selected location. If greater than 64 GB RAM per
core is specified, a higher price is charged. Memory can be dynamically scaled if your
application needs change.
– To calculate your storage configuration, determine the amount of storage currently
being used by the LPAR. Storage in Power Virtual Server is provided by SAN attached
IBM FlashSystem devices. Storage volumes are assigned a Storage Tier when created
which determines the supported IOPS available to your application from that volume.
To help you size your storage see B.3.2, “Storage sizing” on page 192.
 Plan for any high availability and disaster recovery requirements. Power Virtual Server has
several options for data replication and application recovery between different data
centers.
 Understand the backup and recovery options available to you in Power Virtual Server.
 Determine any networking connectivity required for your application, including connections
to other on-premises applications that will not be migrated and any connections for your
users and other cloud resources.

B.2 Application assessment

Prior to moving workloads to IBM Power Virtual Server Private Cloud, you should do an
assessment of the application environment to ensure that you can successfully migrate those
workloads. some of the things that need to be evaluated are:
 Is the workload currently running on IBM Power?
If the workloads are currently running on IBM Power, then the process of migration is greatly
simplified. While it is possible to migrate workloads running on x86 platforms to IBM Power, it
does take additional planning.
 Is the workload running on a supported operating system?
Migrating a workload from an operating system that is older and not supported on IBM Power
Virtual Server requires that you update to a supported operating system version. In some
cases, this also means updating to newer versions of middleware products such as the
database manager.

190 Power Virtual Server for AIX and Linux

  Is the workload a standalone application or is it split between different systems that require
interconnections and data flow?
If your application requires connections to servers that are not running on IBM Power, you
need to plan for the continued connectivity to those resources after the migration.
 What are the availability and disaster recover requirements for the workload?
IBM Power Virtual Server provides many capabilities for workloads that require high
availability, such as automatic failover and data replications. You need to plan appropriately to
support these requirements.
For example, if you need disaster recovery, you may want to utilize Power Virtual Server
Private Cloud in a second data center, or consider utilizing Power Virtual Server off-premises
for recovering the workloads. The key is that these solutions require special planning to be
successful.

These are just some examples of the things you need to consider. IBM has several offerings
available to help you build a migration plan. For more information see IBM Technology Expert
Labs.

B.3 Sizing
Sizing your workload to determine the configuration of your Power Virtual Server Virtual Server
Instance consists of two distinct components: sizing the compute requirements (CPU and
memory) and sizing the storage requirements.

B.3.1 Compute sizing

Collecting data from your existing IBM Power servers will provide you with the information
required to correctly size your Power Virtual Server environment. Data can be gathered using
tools such as NMON and TOP or you can use scan reports from your existing Hardware
Management Controllers (HMCs) to get the information on the existing CPU utilization and
memory allocation. After choosing the size of your LPAR, monitor the performance and adjust
as necessary. It is possible to dynamically Scale LPAR cores and memory on the fly from
0.25x-8x.

CPU Cores
When sizing for CPU, size for typical LPAR processor utilization, not the maximum allocation.
Remember to not include any Virtual I/O Server (VIOS) LPARs in your sizing. Sizing on Power
Virtual Server often saves from 25%-50% of CPU compared to your existing on-premises
utilization as Power Virtual Server doesn't need the control plane and capacity headroom.

If you are not currently running on Power10 based servers, then you will need to convert the
CPU numbers on your existing IBM Power technology to the IBM Power10. You can use a loose
estimate. Optimize Cores by LPAR loosely based on the numbers in Table B-1.

Table B-1 Estimated core conversion factors

Existing technology Power10 technology

1 IBM Power7 core 0.3 Power10 core

1 IBM Power8® core 0.5 Power10 core

1 IBM Power9 core 0.75 Power10 core

Appendix B. Migration planning 191

 Processor type
Processors can be defined as shared uncapped, shared capped or dedicated. For most
LPARs, shared uncapped cores are the appropriate choice. Use shared capped cores for
compliance or ISV license purposes, and use dedicated cores only as required based on
usage in your private on-premises environment.

Memory sizing
Memory is charged on allocated memory at the LPAR, not on the memory utilization shown
by the operating system. In general, the memory size for your Power Virtual Server LPAR will
be the same as your current implementation. Reminder that if you allocate more than 64 GB
of memory per core, then there is an additional charge for the memory. Avoid this 1.5x
memory premium if possible.

Choosing the processor model

Consider using the Power S1022 unless you need additional cores, memory or performance
of the Power E1050 or Power E1080. IBM i on the Power S1022 only supports up to four
cores. For partitions larger than four cores, use the Power E1080.

B.3.2 Storage sizing

There are two components in sizing your storage configuration: amount of storage and the
storage performance requirement or tier.

Storage Tier Selection Guidance

Consider starting with tier 3 storage. All of the storage is IBM FlashSystem, so the difference
between the tiers is the number of IOPs supported. Tier 0 supports the most IOPS/GB,
followed by Tier 1 and then Tier 3. There is also a Fixed 5K IOPS tier if your storage volume is
smaller than 200 GB but requires more IOPS than provided by Tier 0 based on your volume
size.
– Use Tier 3 storage for non-production LPARS, application servers, web servers, and
other low IOPS workloads.
– Use Tier 1 storage for production, mission-critical servers, or databases.
– Use Tier 0 for high-performance databases.
– Fixed 5K IOPS is for databases with high-performance requirements that are <200 GB.

Storage tiers can be mixed as appropriate. The storage tier of a LUN can be dynamically
changed.

Storage sizing
Right-size storage volume sizes based on utilization. Aim for 70-75% utilization of allocated
storage on your volumes. This means that if you have a volume allocated at 20 TB with only
30% utilization, then it can be optimized to 10TB.

Cloud Object Storage

Cloud Object Storage (COS) is not a primary storage for Power Virtual Server. Instead, use
COS for:
– Archive
– Long-term storage and Backup repository
– Capturing and exporting a virtual machine (VM)
– Importing a boot image

192 Power Virtual Server for AIX and Linux

Related publications

The publications listed in this section are considered particularly suitable for a more detailed
discussion of the topics covered in this book.

IBM Redbooks
The following IBM Redbooks publications provide additional information about the topic in this
document. Note that some publications referenced in this list might be available in softcopy
only.
 IBM Power Security Catalog, SG24-8568
 SAP HANA on IBM Power Systems Virtual Servers: Hybrid Cloud Solution, REDP-5693
 Introduction to IBM Power Virtual Server Private Cloud, REDP-5745
 IBM Power Systems Virtual Server Guide for IBM i, SG24-8513

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 Power System Virtual Servers API Reference
https://cloud.ibm.com/apidocs/power-cloud
 IBM Power System Virtual Servers CLI Reference
https://cloud.ibm.com/docs/power-iaas-cli-plugin?topic=power-iaas-cli-plugin-power-iaas-
cli-reference

Help from IBM

IBM Support and downloads
ibm.com/support

IBM Global Services

ibm.com/services

© Copyright IBM Corp. 2025. 193

194 Power Virtual Server for AIX and Linux
IBM Power Virtual Server Guide SG24-8512-01
for IBM AIX and Linux ISBN
(1.5” spine)
1.5”<-> 1.998”
789 <->1051 pages
IBM Power Virtual Server Guide SG24-8512-01
for IBM AIX and Linux ISBN
(1.0” spine)
0.875”<->1.498”
460 <-> 788 pages
SG24-8512-01
Power Virtual Server for AIX and Linux ISBN
(0.5” spine)
0.475”<->0.873”
250 <-> 459 pages
Power Virtual Server for AIX and Linux
(0.2”spine)
0.17”<->0.473”
90<->249 pages
(0.1”spine)
0.1”<->0.169”
53<->89 pages
IBM Power Virtual Server SG24-8512-01
Guide ISBN
(2.5” spine)
2.5”<->nnn.n”
1315<-> nnnn pages
IBM Power Virtual Server Guide SG24-8512-01
for IBM AIX and Linux ISBN
(2.0” spine)
2.0” <-> 2.498”
1052 <-> 1314 pages
Back cover

SG24-8512-01

ISBN

Printed in U.S.A.

®
ibm.com/redbooks