Introduction

This article describes the procedure for migrating a PowerVS environment connected to an x86 IaaS (VPC or Classic) with "Manually configured Direct Link 2.0" to a PER environment.

The "Automatically configured Cloud Connection" cannot be migrated to PER using this procedure.

Essentially, we can migrate to PER environment by following the docs below.
https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-migrate-ws-per

Considerations for migrating to PER-enabled workspace

As described in the docs, in workspaces migrated using this procedure, it is necessary to create a case and have support staff modify the network configurations when adding, updating, or deleting subnets. Please note that what can be done by self-service in the workspace before migration or in a newly created PER-enabled workspace will require a request by a case in a migrated workspace.
https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-migrate-ws-per#add-info-per-mig

Create a support case and request transfer to PER.

My initial configuration is shown in the figure, with Direct Link 2.0 connecting PowerVS to VPC.
Transit Gateway is not used.

Create a case as per the docs, providing details about the PowerVS workspace, subnet, and Direct Link you want to migrate. (Step 4 of the docs)

You will receive a reply in the case when the necessary action is taken on the PowerVS support side.

When you access the workspace, you will notice that Cloud connections and VPN connections have disappeared from the Networking menu on the left side of the workspace. PER enabled workspaces cannot use these functions, so this indicates that the workspace has been migrated to a PER enabled environment.

[Before]

[After]

Create PER+Transit Gateway route

We are ready to use PER from the workspace, but communication is still done via Direct Link.
The following tasks will switch to communication via PER instead of using Direct Link.

Order a Transit Gateway and create connections to PowerVS and VPC, as PER-enabled workspaces need to communicate with x86 IaaS and/or on-premises via Transit Gateway. (Step 5 of the docs)
Before the request to the case, the workspace did not appear in the Power Systems Virtual Server type on the Transit Gateway, but now that it is a PER enabled workspace, it does appear.

We can see that routing information is advertised from both PowerVS and VPC.

At this point, two routes are available for routing between PowerVS and VPC: "via Direct Link" and "via PER+Transit Gateway".

Note that Transit Gateways connected to PowerVS are priced differently than regular Transit Gateways (less expensive than regular Transit Gateways).
Local type Transit Gateways connected to PowerVS do not charge for data transfer.
https://cloud.ibm.com/docs/power-iaas?topic=power-iaas-pricing-virtual-server-on-cloud#per-pricing

Eliminate Direct Link routes

Next, we will stop using the routes via Direct Link that we have been using so far.
Specifically, set Deny all import routes in the Import route filters of Direct Link's filtering function to block routing information from PowerVS. (Step 5 of the docs)

Since the route via Direct Link is no longer available, communication will be via the route via PER.

I enabled the Deny all import routes setting on the Direct Link while continuing to ping the PowerVS LPAR from a server in the VPC.
In my environment, there was no packet loss and only a few seconds delay (line 6 below).

64 bytes from 172.16.50.157: icmp_seq=115 ttl=250 time=0.518 ms
64 bytes from 172.16.50.157: icmp_seq=116 ttl=250 time=0.528 ms
64 bytes from 172.16.50.157: icmp_seq=117 ttl=250 time=0.470 ms
64 bytes from 172.16.50.157: icmp_seq=118 ttl=250 time=0.515 ms
64 bytes from 172.16.50.157: icmp_seq=119 ttl=250 time=0.538 ms
64 bytes from 172.16.50.157: icmp_seq=120 ttl=250 time=4.92 ms
64 bytes from 172.16.50.157: icmp_seq=121 ttl=250 time=0.503 ms
64 bytes from 172.16.50.157: icmp_seq=122 ttl=250 time=0.475 ms
64 bytes from 172.16.50.157: icmp_seq=123 ttl=250 time=0.557 ms
64 bytes from 172.16.50.157: icmp_seq=124 ttl=250 time=0.564 ms

Delete the Direct Link

Once it is confirmed that communication via PER is working without problems even though the route via Direct Link is blocked, delete the Direct Link (Step 6 of docs procedure).

Please update the case to indicate that Step 6 is complete.
When Step 7 is completed on the support side, the migration is complete.