IBM Power Virtual Server (PowerVS)¶

Scope¶

IBM Power Virtual Server (PowerVS) is IBM Cloud's hosted bare-metal IBM Power LPAR service for AIX, IBM i (AS/400), and Linux on Power workloads. Power LPARs run on dedicated Power9 and Power10 hardware inside IBM Cloud data centers, isolated on a Power-specific network fabric and reachable from IBM Cloud VPC, classic infrastructure, on-premises sites, and other public clouds via Direct Link, Transit Gateway, Power Edge Router, and Megaport. This file covers region and hardware selection, LPAR sizing within the published machine-type envelopes, processor sharing modes, storage tiers, networking (Cloud Connections, Direct Link, Transit Gateway, Power Edge Router, VPN options post-VPNaaS end of life), identity and account model, migration on-ramps, backup and DR (snapshots, clones, Global Replication Service, third-party tools), and the IBM-included vs BYOL licensing models. For broader IBM Power workload-on-cloud alternatives see providers/skytap/cloud.md. For hybrid cloud patterns see patterns/hybrid-cloud.md. For modern-app integration patterns over the Azure or AWS boundary see providers/azure/networking.md and providers/aws/networking.md.

Checklist¶

Workload Fit¶

[Critical] Is the workload a genuine IBM Power workload (AIX, IBM i, or Linux on Power) for which native x86 cloud compute is not a substitute, or is it a Linux x86 workload that has been mislabeled as "Power" by virtue of running adjacent to one? (PowerVS is priced and scoped as a Power-specific service. Pure Linux x86 workloads belong on IBM Cloud VPC, AWS, Azure, or GCP, not on PowerVS.)
[Critical] Is the choice between PowerVS and Skytap (Kyndryl Cloud Uplift) made deliberately based on which hyperscaler the surrounding modern application estate lives in, and on the LPAR ceilings each platform supports? (PowerVS sits inside IBM Cloud; reaching Azure or AWS-native services means an additional cross-cloud network hop via Megaport or Direct Link. Skytap sits inside Azure data centers; reaching AWS or GCP means an additional hop. Match the platform to the existing application gravity.)

Region and Hardware Selection¶

[Critical] Is a PowerVS region selected that satisfies both data-residency and Direct Link / Cloud Connection topology requirements? (IBM operates PowerVS across roughly 22 data centers in 12 cities globally as of 2025-2026, with multiple data centers in Dallas and Washington DC and recent additions including Chennai. Not every IBM Cloud region offers PowerVS, and not every PowerVS region offers every hardware tier. Confirm the specific data-center code, not just the city.)
[Critical] Is the machine type chosen against the documented off-premises hardware tiers -- S922 (Power9, scale-out), E980 (Power9, enterprise), S1022 (Power10, scale-out), S1122 (Power10, scale-out) -- with explicit awareness that E980 is not offered in every data center and that Power10 machine types may not be present in every region? (Off-premises PowerVS does not currently offer E1080 directly to customers; the on-premises private-cloud variant of PowerVS offers different hardware (S1122, E1150, E1180). Verify the target region's catalog before sizing.)
[Critical] Is LPAR sizing planned within the per-machine-type cores and RAM envelopes -- for example S922 with up to 20 Power9 cores and 4 TB DDR4, S1022 with up to 40 Power10 cores and 4 TB, E980 enterprise-class scaling well beyond those limits -- and within IBM i's separate processor-group ceilings? (Single LPARs cannot exceed the underlying machine's physical capacity. Workloads needing larger LPARs than scale-out tiers provide must target the enterprise E-class hardware, which is more expensive per core and not available in every region.)
[Recommended] Is the processor mode chosen deliberately per LPAR -- dedicated cores (highest cost, full entitlement), shared capped (entitled capacity caps the partition, no burst), or shared uncapped (entitled capacity floor with burst into idle pool capacity)? (Hourly billing differs materially by mode. IBM i partitions are always capped, so setting entitled capacity to the actual workload requirement -- not a low value with hopes of bursting -- is mandatory. Memory above 64 GB per core is charged at a higher rate.)

Networking¶

[Critical] Is the connectivity model chosen against the current IBM Cloud topology -- Power Edge Router (PER) workspaces with Transit Gateway integration (modern, higher-bandwidth, no separate Cloud Connection charges), Cloud Connections (legacy Direct Link 2.0 Connect, US-only for some variants), or both? (PER is the strategic direction; new workspaces should be PER-enabled where the region supports it. PER plus Transit Gateway reaches IBM Cloud VPC, classic, and on-prem in one fabric without per-connection Cloud Connection charges.)
[Critical] Is the cross-cloud connectivity path defined for PowerVS reaching Azure-native, AWS-native, or GCP-native services -- typically Megaport private connectivity to the hyperscaler's ExpressRoute / Direct Connect / Cloud Interconnect, or IBM Cloud Direct Link to another cloud where a region-pair supports it? (IBM publishes a reference architecture for PowerVS-to-Azure via Megaport. Public-internet routes are not acceptable for production database or LPAR-to-app traffic. Latency, throughput, and BGP routing must be designed up front -- this is the single biggest source of project surprises when PowerVS hosts the database and Azure hosts the application tier.)
[Recommended] Is the VPN strategy aligned with the Power Virtual Server VPNaaS end-of-life (14 July 2025) -- new VPN connectivity now uses IBM Cloud VPC VPN (site-to-site or client-to-site) routed through the PowerVS workspace via Transit Gateway / PER? (Architectures that still reference Power Virtual Server VPNaaS are out of date and will not provision. Confirm the in-flight design uses VPC VPN.)
[Recommended] Is Direct Link billing factored into the cost model now that metering charges apply to all Direct Link connections from 1 July 2025? (Direct Link was previously bundled or low-cost for some PowerVS configurations. Designs that assumed free Direct Link need a refresh.)

Storage, Backup, and DR¶

[Recommended] Is the storage tier selected per workload based on the published IOPS-per-GB envelopes -- Tier 0 (25 IOPS/GB), Tier 1 (10 IOPS/GB), Tier 3 (3 IOPS/GB), Tier 5k (fixed 5,000 IOPS per volume)? (Tier 5k is the right choice for small, latency-sensitive volumes (journal receivers, redo logs) where IOPS/GB scaling produces an over-sized volume. Tier 0 is for large transactional volumes. Tier 3 is for archive and bulk data. Mis-tiered storage is a frequent cause of perceived performance problems.)
[Recommended] Is the snapshot, clone, and replication strategy defined -- FlashCopy-based delta snapshots (charged at 30% of regular storage rate), volume clones (full volume cost), and Global Replication Service (GRS) for cross-region hardware-based replication? (Snapshots alone are not a DR strategy -- they live in the same data center as the source volume. GRS provides cross-region replication for tier-1 DR; otherwise an application-layer replication path (IBM i journaling / MIMIX, AIX HACMP/PowerHA equivalents) over Direct Link or Transit Gateway is required.)
[Recommended] Is the backup target outside PowerVS itself -- typically IBM Cloud Object Storage for long-retention AIX mksysb and IBM i BRMS/GoSave output, or third-party backup (IBM Storage Defender / Storage Protect, Veeam, Commvault, Catalogic) writing to object storage? (Snapshot-only retention inside the workspace means a workspace-level event is a data-loss event. Routing backups to Cloud Object Storage via VPC and a private endpoint keeps the path off the public internet and the cost predictable.)

Identity, Account, and Migration¶

[Recommended] Is the IBM Cloud IAM model documented -- account and enterprise-account hierarchy, resource groups per PowerVS workspace, service IDs for automation, access groups for human users, and the boundary between PowerVS workspace administration and in-LPAR OS administration? (PowerVS workspace operations and AIX/IBM i OS operations are separate identity domains. Plan both. Federation to enterprise IdP (Entra ID, Okta, ADFS) via IBM Cloud SAML is the typical pattern.)
[Recommended] Is the migration on-ramp defined per source platform -- AIX mksysb / NIM for AIX, IBM i save/restore (BRMS, GoSave) or virtual-tape via BRMS for IBM i, block-level replication tools (IBM PowerVC capture/restore, Coresight, third-party tools) for larger fleets, and Migrate While Active for minimum-downtime LPAR migration into PowerVS using asynchronous replication? (Migration tooling for Power is fundamentally different from x86 migration. Hyperscaler-style automated agents do not exist; expect backup-restore or block-replication processes with appropriate cutover windows.)
[Optional] For IBM i workloads, is the Virtual Serial Number (VSN) strategy understood for software license portability between source and target systems during migration and DR? (VSN simplifies moving entitled IBM software to a replacement Power system without re-licensing per move; necessary for IBM i 7.3+ environments doing routine system replacement or DR failovers.)

Licensing and Cost¶

[Critical] Is the OS licensing model chosen -- IBM-included for AIX and IBM i (license and software maintenance bundled into hourly LPAR cost; existing on-prem licenses cannot transfer to PowerVS), IBM Full Linux Subscription for stock IBM-provided Linux images, or BYOL for customer-provided Linux images? (AIX and IBM i are not BYOL on PowerVS. Plan to retire the on-prem entitlement or maintain it separately if both environments run concurrently during migration.)
[Recommended] Is the software stack licensing (IBM Db2, IBM MQ, WebSphere, Oracle on Power, ISV apps) modeled separately with ILMT sub-capacity where IBM PVU-based products are deployed, or full-capacity where ILMT is not? (ILMT properly configured against the entitled-capacity floor on shared partitions is the difference between paying for what you use and paying for the underlying processor group. For any non-trivial Power software footprint, ILMT operations capability is mandatory.)
[Recommended] Is outbound network egress modeled (inbound is free; outbound is metered per GB) along with snapshot storage at 30% of base rate and GRS replication bandwidth and storage? (PowerVS bills are not just hourly LPAR cost. Cross-cloud database replication, Cloud Object Storage backup egress, and DR replication can each exceed the LPAR line item on a busy workload.)

Why This Matters¶

PowerVS is the only public-cloud service that runs production AIX and IBM i on dedicated IBM Power hardware at hyperscaler-style hourly billing. For an organization with an AS/400 ERP, an AIX-resident Db2 data warehouse, or a regulated banking workload that has run on Power for decades, the realistic cloud options are PowerVS, Skytap on Azure (Kyndryl Cloud Uplift), or staying on-premises. PowerVS's advantages are larger LPAR ceilings on enterprise-class hardware than Skytap supports, IBM-included licensing for AIX and IBM i, and direct integration with the rest of IBM Cloud (VPC, classic, Object Storage, Db2 on Cloud). Its constraint is that it sits inside IBM Cloud, not inside Azure or AWS -- so any modern application tier in another hyperscaler has to cross a network boundary to reach the database or LPAR-resident services. That boundary is solvable (Megaport, Direct Link, hyperscaler-side ExpressRoute/Direct Connect/Cloud Interconnect), but it has to be designed up front, not retrofitted.

The cost model is non-obvious and a frequent source of budget overruns. Hourly LPAR rates look cheap on paper, but a production deployment typically includes high-tier storage, Global Replication Service for DR, Cloud Object Storage for backup retention, Direct Link or Megaport to the surrounding cloud and on-prem estate, and outbound egress on any cross-cloud or backup path. IBM software licenses (Db2, MQ, WebSphere, plus the OS-bundled AIX/IBM i entitlement) are layered on top. ILMT sub-capacity reporting is critical for IBM PVU-based software; without it, IBM holds licensees to full-capacity on the underlying processor group, which can dwarf the entitled capacity actually consumed. Right-sizing capped IBM i partitions, picking the correct storage tier per volume, and modeling DR cost as a second running region (not a discounted replica) are mandatory disciplines.

The networking model has shifted recently and stale designs will not provision. The Power Virtual Server VPNaaS product reached end of life on 14 July 2025; new connectivity uses IBM Cloud VPC VPN routed through the workspace via Transit Gateway and Power Edge Router. Direct Link connections also became metered effective 1 July 2025. Power Edge Router-enabled workspaces are the strategic direction and provide higher bandwidth and integrated Transit Gateway routing without separate Cloud Connection charges. Designs older than 2024 that reference VPNaaS, free Direct Link, or non-PER Cloud Connections need refresh against the current IBM Cloud topology.

Migration tooling for Power is its own discipline. There is no equivalent of AWS Application Migration Service or Azure Migrate for AIX or IBM i. Expect a backup-restore or block-replication migration -- mksysb plus NIM for AIX, BRMS or GoSave for IBM i, IBM PowerVC or third-party block replication for fleet moves, and the newer "Migrate While Active" capability for minimum-downtime LPAR moves into PowerVS. Cutover windows for IBM i ERP systems are typically measured in days, not hours, and require explicit business-stakeholder sign-off. The migration plan, not the steady-state architecture, is what makes or breaks PowerVS project timelines.

Common Decisions (ADR Triggers)¶

PowerVS vs Skytap (Kyndryl Cloud Uplift) vs on-prem retention -- PowerVS (sits inside IBM Cloud, larger LPAR ceilings on E-class hardware, AIX/IBM i licensing included, IBM-managed, requires Megaport/Direct Link hop to Azure/AWS-native services) vs Skytap (sits inside Azure data centers, preserves L2 network semantics, Kyndryl-managed, lower LPAR ceiling, lowest latency to Azure-native services) vs on-prem retention (no migration risk, preserves existing operations, defers cloud question). The decision is driven by where the surrounding modern-application estate lives and whether L2 environment-preservation matters.
PowerVS off-premises vs PowerVS on-premises (Private Cloud) -- off-prem hosted in IBM Cloud data centers (hourly billing, IBM-managed infrastructure, fastest provisioning) vs on-prem PowerVS Private Cloud running S1122 / E1150 / E1180 in the customer's own data center (data residency, integration with on-prem SAN/network, capex or as-a-service consumption, no cross-cloud hop). On-prem PowerVS is the answer when data cannot leave the building but cloud-style consumption is required.
AIX vs Linux on Power for new workloads -- AIX (mature, IBM-supported, included licensing, deepest tooling for AIX-native apps) vs Linux on Power (open-source, broader ecosystem, BYOL or IBM Full Linux Subscription, easier hiring) vs migrate-off-Power-entirely to Linux on x86. Greenfield workloads rarely justify AIX; lift-and-shift of existing AIX workloads does.
Direct Link / PER vs VPN (post-VPNaaS EOL) -- Power Edge Router workspace with Transit Gateway (production-grade, integrated, scales with workspace) vs IBM Cloud VPC VPN routed through PER (lower cost, sufficient for dev/test or initial migration) vs Megaport private connectivity for cross-cloud (production-grade reach into Azure / AWS / GCP). VPN-only is acceptable for non-production; production should use Direct Link or PER with Megaport for cross-cloud.
IBM-included OS licensing vs BYOL -- AIX/IBM i are included on PowerVS and cannot be BYOL; existing on-prem entitlements do not transfer. Linux on Power can be IBM Full Linux Subscription (stock images, simplest operations) or BYOL (preserves existing Red Hat / SUSE entitlements). For long-running Linux workloads with existing subscriptions, BYOL is materially cheaper.
GRS cross-region DR vs application-level replication vs object-storage cold DR -- GRS hardware replication (lowest RPO, highest cost, hardware-managed, paired region required) vs application-level (IBM i journaling / MIMIX, AIX HACMP-equivalent) over Direct Link / Transit Gateway (RPO and RTO controlled by application, predictable cost) vs cold DR with backups to Cloud Object Storage and on-demand workspace rebuild (cheapest, longest RTO). Pick based on tier-1 application RTO and the cost ceiling for DR.
ILMT sub-capacity vs full-capacity IBM licensing -- deploying ILMT against PowerVS workspaces (requires ongoing ILMT operations, reports sub-capacity usage, large cost reduction on PVU-based software) vs full-capacity (no ILMT overhead, IBM bills against the whole processor group). For any non-trivial Db2/MQ/WebSphere footprint on Power, ILMT pays for itself within months -- but only if it is deployed and reporting correctly.

Reference Links¶

IBM Power Virtual Server documentation (cloud.ibm.com) -- canonical product documentation
IBM Power Virtual Server FAQ -- supported hardware (S922, E980, S1022, S1122 off-prem; S1122, E1150, E1180 on-prem), OSes, storage tiers
IBM Power Virtual Server pricing -- hourly rates per machine type, storage tier pricing, OS licensing model
IBM Power Virtual Server cloud regions -- current region and data-center list
IBM Power Virtual Server Cloud Connections -- Direct Link 2.0 Connect connectivity to IBM Cloud classic and VPC
Connecting IBM Power Virtual Server to Microsoft Azure using Megaport -- cross-cloud reference architecture
IBM Cloud Transit Gateway -- multi-VPC, multi-region, Power-to-VPC interconnect
Integrating Power Virtual Server, VPC, and classic using Transit Gateway -- PER + Transit Gateway topology
Power Virtual Server VPN connections (post-VPNaaS EOL guidance) -- migration to VPC VPN
IBM Power Systems Virtual Server Guide for IBM i (Redbook SG24-8513) -- IBM i-specific architecture and migration guidance