self-review

Author: RichardHoch

documentation/modules/storage-support.adoc

@@ -69,7 +69,7 @@ If the {virt} storage does not support {ocp-doc}/storage/dynamic-provisioning#dy
 +
 `ReadWriteOnce` access mode does not support live virtual machine migration.
 
-// See link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/virtualization/virtual-machines#virt-customizing-storage-profile_virt-creating-data-volumes[Enabling a statically-provisioned storage class] for details on editing the storage profile.
+See link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/virtualization/virtual-machines#virt-customizing-storage-profile_virt-creating-data-volumes[Enabling a statically-provisioned storage class] for details on editing the storage profile.
 ====
 
 [NOTE]

documentation/modules/vddk-validator-containers.adoc

@@ -4,41 +4,47 @@
 
 :_content-type: REFERENCE
 [id="vddk-validator-containers_{context}"]
-= VDDK validator containers need requests and limits
+= Requests and limits for VDDK validator containers 
 
-If you have the cluster or project resource quotas set, you must ensure that you have a sufficient quota for the {project-short} pods to perform the migration. 
+When you set cluster or project resource quotas, be sure that you have a sufficient quota for the {project-short} pods to perform the migration. 
 
-// For more information, see {ocp-doc}/building_applications/index#quotas-creating-a-quota_quotas-setting-per-project
+For more information on creating, setting, and viewing quotas, see {ocp-doc}/building_applications/index#quotas[Quotas]
 
-You can see the defaults, which you can override in the ForkliftController custom resource (CR), listed as follows. If necessary, you can adjust these defaults. 
+The defaults that are related to VDDK validator containers are listed as follows. You can override these defaults in the `ForkliftController` custom resource (CR).
 
-These settings are highly dependent on your environment. If there are many migrations happening at once and the quotas are not set enough for the migrations, then the migrations can fail. This can also be correlated to the `MAX_VM_INFLIGHT` setting that determines how many VMs/disks are migrated at once.
 
-.Defaults which can be overriden in the ForkliftController CR:
+[NOTE]
+====
+These settings are highly dependent on your environment. If there are many migrations happening at once and the quotas are not set high enough for the migrations, then the migrations can fail. 
+
+Migration success or failure is also connected to the `MAX_VM_INFLIGHT` setting that determines how many VMs or disks are migrated at once.
+====
+
+[id="defaults-that-can-be-overridden-in-forklift-controller_{context}"]
+== Defaults that can be overridden in the ForkliftController CR:
 
-* This affects both cold and warm migrations:
+* These defaults affect both cold and warm migrations:
 +
-For cold migration, it is likely to be more resource intensive as it performs the disk copy. For warm migration, you could potentially reduce the requests.
+Cold migration is likely to be more resource intensive because it copies the disks. For warm migration, you could potentially reduce the requests.
 
 ** virt_v2v_container_limits_cpu: `4000m`
 ** virt_v2v_container_limits_memory: `8Gi`
 ** virt_v2v_container_requests_cpu: `1000m`
 ** virt_v2v_container_requests_memory: `1Gi`
 +
-
 [NOTE]
 ====
 Cold and warm migration using `virt-v2v` can be resource-intensive. For more details, see link:https://libguestfs.org/virt-v2v.1.html#compute-power-and-ram[Compute power and RAM].
 ====
 
+* These defaults affect all migrations with hooks:
 
-* This affects any migrations with hooks:
 ** hooks_container_limits_cpu: `1000m`
 ** hooks_container_limits_memory: `1Gi`
 ** hooks_container_requests_cpu: `100m`
 ** hooks_container_requests_memory: `150Mi`
 
-* This affects any OVA migrations:
+* TThese defaults affect all Open Virtual Appliance (OVA) file migrations: migrations:
 
 ** ova_container_limits_cpu: `1000m`
 ** ova_container_limits_memory: `1Gi`

documentation/modules/virt-migration-workflow.adoc

@@ -25,7 +25,7 @@ The workflow describes the following steps:
 +
 *For each VM disk:*
 
-. The `Containerized Data Importer (CDI) Controller` service creates a persistent volume claim (PVC) based on the parameters specified in the `DataVolume` CR.


+. The `Containerized Data Importer (CDI) Controller` service creates a persistent volume claim (PVC) based on the parameters specified in the `DataVolume` CR.
 . If the `StorageClass` has a dynamic provisioner, the persistent volume (PV) is dynamically provisioned by the `StorageClass` provisioner.
 . The `CDI Controller` service creates an `importer` pod.
 . The `importer` pod streams the VM disk to the PV.
@@ -67,7 +67,7 @@ The `virt-launcher` pod runs `QEMU-KVM` with the PVCs attached as VM disks.
 +
 *For each VM disk:*
 
-. The `Containerized Data Importer (CDI) Controller` service creates a blank persistent volume claim (PVC) based on the parameters specified in the `DataVolume` CR.


+. The `Containerized Data Importer (CDI) Controller` service creates a blank persistent volume claim (PVC) based on the parameters specified in the `DataVolume` CR.
 . If the `StorageClass` has a dynamic provisioner, the persistent volume (PV) is dynamically provisioned by the `StorageClass` provisioner.
 
 *For all VM disks:*