$ oc get pv
If your application uses an internal service network or an external route for communicating with services, the relevant route exists.
If your application uses cluster-level resources, you have re-created them on the target cluster.
You have excluded persistent volumes (PVs), image streams, and other resources that you do not want to migrate.
PV data has been backed up in case an application displays unexpected behavior after migration and corrupts the data.
The cluster meets the minimum hardware requirements.
You have installed the correct legacy Migration Toolkit for Containers Operator version:
operator-3.7.yml on OKD version 3.7.
operator.yml on OKD versions 3.9 to 4.5.
All nodes have an active OKD subscription.
You have performed all the run-once tasks.
You have performed all the environment health checks.
You have checked for PVs with abnormal configurations stuck in a Terminating state by running the following command:
$ oc get pv
You have checked for pods whose status is other than Running or Completed by running the following command:
$ oc get pods --all-namespaces | egrep -v 'Running | Completed'
You have checked for pods with a high restart count by running the following command:
$ oc get pods --all-namespaces --field-selector=status.phase=Running \ -o json | jq '.items|select(any( .status.containerStatuses; \ .restartCount > 3))|.metadata.name'
Even if the pods are in a Running state, a high restart count might indicate underlying problems.
You have removed old builds, deployments, and images from each namespace to be migrated by pruning.
The internal registry uses a supported storage type.
Direct image migration only: The internal registry is exposed to external traffic.
You can read and write images to the registry.
The etcd cluster is healthy.
The average API server response time on the source cluster is less than 50 ms.
The cluster certificates are valid for the duration of the migration process.
You have checked for pending certificate-signing requests by running the following command:
$ oc get csr -A | grep pending -i
The identity provider is working.
You have installed Migration Toolkit for Containers Operator version 1.5.1.
All MTC prerequisites are met.
The cluster meets the minimum hardware requirements for the specific platform and installation method, for example, on bare metal.
The cluster has storage classes defined for the storage types used by the source cluster, for example, block volume, file system, or object storage.
NFS does not require a defined storage class.
The cluster has the correct network configuration and permissions to access external services, for example, databases, source code repositories, container image registries, and CI/CD tools.
External applications and services that use services provided by the cluster have the correct network configuration and permissions to access the cluster.
Internal container image dependencies are met.
If an application uses an internal image in the
openshift namespace that is not supported by OKD 4.10, you can manually update the OKD 3 image stream tag with
The target cluster and the replication repository have sufficient storage space.
The identity provider is working.
DNS records for your application exist on the target cluster.
Set the value of the
annotation.openshift.io/host.generated parameter to
true for each OKD route to update its host name for the target cluster. Otherwise, the migrated routes retain the source cluster host name.
Certificates that your application uses exist on the target cluster.
You have configured appropriate firewall rules on the target cluster.
You have correctly configured load balancing on the target cluster.
If you migrate objects to an existing namespace on the target cluster that has the same name as the namespace being migrated from the source, the target namespace contains no objects of the same name and type as the objects being migrated.
Do not create namespaces for your application on the target cluster before migration because this might cause quotas to change.
The migration network has a minimum throughput of 10 Gbps.
The clusters have sufficient resources for migration.
Clusters require additional memory, CPUs, and storage in order to run a migration on top of normal workloads. Actual resource requirements depend on the number of Kubernetes resources being migrated in a single migration plan. You must test migrations in a non-production environment in order to estimate the resource requirements.
The memory and CPU usage of the nodes are healthy.
The etcd disk performance of the clusters has been checked with