Direct image and PV migration

Author: apinnick

modules/migration-adding-cluster-to-cam.adoc

@@ -40,6 +40,10 @@ eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiw
 * *Cluster name*: May contain lower-case letters (`a-z`) and numbers (`0-9`). Must not contain spaces or international characters.
 * *Url*: URL of the cluster's API server, for example, `\https://<master1.example.com>:8443`.
 * *Service account token*: String that you obtained from the source cluster.
+* *Exposed route to image registry*: Optional. You can specify a route to the image registry of your source cluster to enable direct migration for images, for example, `docker-registry-default.apps.cluster.com`.
++
+Direct migration is much faster than migration with a replication repository.
+
 * *Azure cluster*: Optional. Select it if you are using Azure snapshots to copy your data.
 * *Azure resource group*: This field appears if *Azure cluster* is checked.
 * If you use a custom CA bundle, click *Browse* and browse to the CA bundle file.

modules/migration-creating-migration-plan-cam.adoc

@@ -27,37 +27,48 @@ The *Plan name* can contain up to 253 lower-case alphanumeric characters (`a-z,
 . Select the projects to be migrated and click *Next*.
 . Select *Copy* or *Move* for the persistent volume (PV):
 
-* *Copy* copies the data in a source cluster's PV to the replication repository and then restores it on a newly created PV, with similar characteristics, in the target cluster.
+. Select a *Source cluster*, a *Target cluster*, and a *Repository*, and click *Next*.
+. In the *Namespaces* screen, select the projects to be migrated and click *Next*.
+. In the *Persistent volumes* screen, select *Copy* or *Move* for the PVs:
+
+* *Copy* copies the data from the PV of a source cluster to the replication repository and then restores it on a newly created PV, with similar characteristics, in the target cluster.
 +
-Optional: You can verify data copied with the file system method by selecting *Verify copy*. This option generates a checksum for each source file and checks it after restoration. The operation significantly reduces performance.
+If you specified a route to an image registry when you added the source cluster to the web console, you can migrate images directly from the source cluster to the target cluster.
 
 * *Move* unmounts a remote volume, for example, NFS, from the source cluster, creates a PV resource on the target cluster pointing to the remote volume, and then mounts the remote volume on the target cluster. Applications running on the target cluster use the same remote volume that the source cluster was using. The remote volume must be accessible to the source and target clusters.
 
 . Click *Next*.
-. Select a *Copy method* for the PVs:
-* *Snapshot* backs up and restores the disk using the cloud provider's snapshot functionality. It is significantly faster than the file system copy method.
+
+. In the *Copy options* screen, select a *Copy method* for the PVs:
+
+* *Snapshot copy* backs up and restores the disk using the cloud provider's snapshot functionality. It is significantly faster than *Filesystem copy*.
 +
 [NOTE]
 ====
-The storage and clusters must be in the same region and have the same storage class.
+The storage and clusters must be in the same region and the storage classes must be compatible.
 ====
 
-* *Filesystem* copies the data files from the source disk to a newly created target disk.
+* *Filesystem copy* backs up the files on the source cluster and restores them on the target cluster.
+
+. You can select *Verify copy* to verify data migrated with *Filesystem copy*. Data is verified by generating a checksum for each source file and checking the checksum after restoration. Data verification significantly reduces performance.
 
-. Select a *Storage class* for the PVs.
+. Select a *Target storage class*.
 +
-If you selected the *Filesystem* copy method, you can change the storage class during migration, for example, from Red Hat Gluster Storage or NFS storage to Red Hat Ceph Storage.
+If you selected *Filesystem copy*, you can change the storage class during migration, for example, from Red Hat Gluster Storage or NFS storage to Red Hat Ceph Storage.
 
 . Click *Next*.
-. If you want to add a migration hook, click *Add Hook* and perform the following steps:
+
+. In the *Migration options* screen, the *Use direct image migration* and *Use direct PV migration for filesystem copies* options are selected if you specified an image registry route for the source cluster.
++
+Direct migration is much faster than migrating files and images with a replication repository.
+
+. If you want to add a migration hook, click *Add Hook* and perform the following steps for each migration:
 
 .. Specify the name of the hook.
-.. Select *Ansible playbook* to use your own playbook or *Custom container image* for a hook written in another language.
+.. Select an *Ansible playbook* or a *Custom container image* for a hook written in another language.
 .. Click *Browse* to upload the playbook.
-.. Optional: If you are not using the default Ansible runtime image, specify your custom Ansible image.
-.. Specify the cluster on which you want the hook to run.
-.. Specify the service account name.
-.. Specify the namespace.
+.. Optional: If you are not using the default Ansible runtime image, specify a custom Ansible image.
+.. Specify the cluster on which you want the hook to run, the service account name, and the namespace.
 .. Select the migration step at which you want the hook to run:
 
 * PreBackup: Before backup tasks are started on the source cluster