If you're running OpenShift on Power Virtual Server and you used the IPI installer to create it, you're in luck: migrating to Power 10 is incredibly simple. By default there are two MachineSets -- one for control plane nodes and one for workers.  Those are the two items you'll need to modify to change your cluster system type. Call this a migration or an upgrade -- since this is OpenShift, the cluster creates new machines and then safely moves all its components and your workloads to them. It also deletes the old VMs when everything has been moved and the new machine has successfully joined the cluster. 

- OpenShift 4.21+ cluster on Power Virtual Server, with the latest updates
- Cluster admin access with kubeconfig
- **Important**: Ensure you have 3 healthy control plane nodes before starting

To upgrade your control plane, you only have to edit one file. You can do this by using the oc (or kubectl) CLI. I find the simplest way to make this update is using the OpenShift Console UI. Here is an image of the only change you need to make via the cluster console: 

Change systemType to desired value

Locate the Compute section, expand to find the ControlPlaneMachineSets on the left, and edit. Change the systemType from s922 (or your current value), to s1022 (or your desired value), and click the Save button. 

You could alternatively edit using the following oc command: 

That is is it! 

The control plane MachineSet has an update strategy type of "Rolling Upgrade." The cluster will now begin to provision new Machines in PowerVS and transition them to cluster Nodes. 

Note: During my validation, it took almost an hour for each machine to complete the provision + bootstrap + join steps. 

Worker Node Upgrade

To move your worker nodes, you'll have to create a new MachineSet for the Power10 system type nodes. This MachineSet has a different Upgrade Strategy than the control planes one since worker nodes don't need to be migrated  as strictly. Due to this difference, to create Power 10 workers, you create a new MachineSet with the desired Power10 configuration. Once the new Power10 workers are ready and healthy, the original Power9 MachineSet is scaled down to zero, allowing workloads to migrate seamlessly with zero downtime.

Instead of using the UI for this I'm using the CLI. I personally find it easier to work with text files this way. 

Step 1: Get Current Worker MachineSet Configuration

First, identify your current worker machineset:

$ oc get machinesets -n openshift-machine-api

Get the full configuration:

$ oc get machineset <cluster-name>-worker -n openshift-machine-api -o yaml > original-worker-machineset.yaml

Create a new machineset file based on the original, changing:
- `metadata.name`: Add `-p10` suffix
- `spec.selector.matchLabels`: Update machineset name
- `spec.template.metadata.labels`: Update machineset name
- `spec.template.spec.providerSpec.value.systemType`: Change from `s922` to `s1022`

**Key Change:**

The yaml file should contain: 
systemType: s1022  # Changed from s922

All other settings (memory, processors, network, etc.) remain identical.

### Step 3: Apply the New MachineSet

 
$ oc apply -f worker-p10-machineset.yaml 

**Expected Warning:**

On older cluster versions, users may see this warning. 

 
Warning: providerSpec.SystemType: s1022 is not known, Currently known system types are s922, e980 and e880 

This warning is informational only - the s1022 system type is fully supported.

Step 4: Verify Power10 Nodes Join

Monitor machine creation by running the following oc commands: 
 
$ oc get machines -n openshift-machine-api | grep p10 

Wait for nodes to become Ready (typically 10-15 minutes):

$ oc get nodes | grep p10

Expected output:
 
<cluster-name>-worker-p10-xxxxx   Ready   worker   5m   v1.33.x
<cluster-name>-worker-p10-yyyyy   Ready   worker   5m   v1.33.x
<cluster-name>-worker-p10-zzzzz   Ready   worker   5m   v1.33.x 

Verify system type:

$ oc get machine <machine-name> -n openshift-machine-api -o jsonpath='{.spec.providerSpec.value.systemType}'

Note: replace <machine-name> with a name from the oc output.

Should return: s1022

Step 5: Scale Down Power9 MachineSet

Once all Power10 nodes are Ready and healthy:

 
$ oc scale machineset <cluster-name>-worker -n openshift-machine-api --replicas=0

**What Happens Automatically:**
1. Nodes are cordoned (marked unschedulable)
2. Pods are gracefully drained
3. Workloads reschedule to Power10 nodes
4. Machines are deleted from PowerVS
5. Nodes are removed from the cluster

Step 6: Monitor Migration Progress

Watch the deletion:
 
# Check machines
$ oc get machines -n openshift-machine-api

# Check nodes
$ oc get nodes

Power9 machines will show "Deleting" phase.
Power9 nodes will show "SchedulingDisabled" status during drain.

Step 7: Verify Migration Complete

Confirm all workers are on Power10:
 
$ oc get nodes
$ oc get machines -n openshift-machine-api

Step 8: Clean Up (Optional)

After confirming cluster stability, delete the old machineset:
 
$ oc delete machineset <cluster-name>-worker -n openshift-machine-api

## Rollback Procedure

If issues occur:

1. Scale Power9 machineSet back up:

   $ oc scale machineset <cluster-name>-worker -n openshift-machine-api --replicas=3=

2. Wait for Power9 nodes to become Ready

3. Scale down Power10 machineset:
    
  $ oc scale machineset <cluster-name>-worker-p10 -n openshift-machine-api --replicas=0
  

Important Notes

- **Zero Downtime**: Workloads automatically reschedule during migration
- **Validation Warning**: The "s1022 is not known" warning can be safely ignored
- **System Type**: The key field is `systemType` in the PowerVS provider spec
- **Gradual Migration**: You can scale down gradually (3→2→1→0) if preferred
- **No Manual Draining**: The machine API handles cordoning and draining automatically

Troubleshooting

Nodes Not Joining

Check machine status:
 
$ oc describe machine <machine-name> -n openshift-machine-api 

1. Verify PowerVS workspace info shows VMs are running and in WARNING state. 

2. Verify PowerVS VM console shows a booted and bootstrapping VM.

From the PowerVS UI, open the machine's Console. If the system shows a # prompt or displays other symptoms of a problematic provision such as a system in ERROR state, delete the OpenShift machine representation of the system. Do this using either the oc CLI (oc machine delete) or use the OpenShift Compute Machines console section. Be aware of the difference between a Node and a Virtual Machine. Do not delete the VM through PowerVS. By using the OpenShift tooling, the cluster will delete the VM and provision a replacement.

### Pods Not Draining
Check for PodDisruptionBudgets:
 
$ oc get pdb --all-namespaces 

If needed, manually drain:
 
$ oc adm drain <node-name> --ignore-daemonsets --delete-emptydir-data 

## Timeline

- **Machine Provisioning**: 5-10 minutes
- **Node Bootstrap**: 5-10 minutes  
- **Node Drain**: 2-5 minutes per node
- **Total Migration Time**: ~30-45 minutes for 3 workers

## Configuration Reference

### Power9 Configuration

YAML file should contain: 

systemType: s922

### Power10 Configuration

YAML file should contain: 

systemType: s1022

All other settings remain identical between Power9 and Power10 machinesets.

Also note: If you had any specific labels tied to the P9 machineSet or systems you'll need to modify accordingly.