issue 8733: add doc for restorePVC

Signed-off-by: Lyndon-Li <lyonghui@vmware.com>

site/content/docs/main/csi-snapshot-data-movement.md

@@ -379,8 +379,13 @@ For the restore, this is not supported because sometimes the data movement resto
 ### BackupPVC Configuration
 
 The `BackupPVC` serves as an intermediate Persistent Volume Claim (PVC) utilized during data movement backup operations, providing efficient access to data.
-In complex storage environments, optimizing `BackupPVC` configurations can significantly enhance the performance of backup operations. [This document][16] outlines
-advanced configuration options for `BackupPVC`, allowing users to fine-tune access modes and storage class settings based on their storage provider's capabilities.
+In complex storage environments, optimizing `BackupPVC` configurations can significantly enhance the performance of backup operations. [This document][16] outlines advanced configuration options for `BackupPVC`, allowing users to fine-tune access modes and storage class settings based on their storage provider's capabilities.  
+
+### RestorePVC Configuration
+
+The `RestorePVC` serves as an intermediate Persistent Volume Claim (PVC) utilized during data movement restore operations, providing efficient access to data.  
+Sometimes, `RestorePVC` needs to be configured to increase the performance of restore operations. [This document][19] outlines advanced configuration options for `RestorePVC`, allowing users to fine-tune access modes and storage class settings based on their storage provider's capabilities.  
+
 
 [1]: https://github.com/vmware-tanzu/velero/pull/5968
 [2]: csi.md
@@ -399,4 +404,5 @@ advanced configuration options for `BackupPVC`, allowing users to fine-tune acce
 [16]: data-movement-backup-pvc-configuration.md
 [17]: backup-repository-configuration.md
 [18]: https://github.com/vmware-tanzu/velero/pull/7576
+[19]: data-movement-restore-pvc-configuration.md
 

site/content/docs/main/data-movement-restore-pvc-configuration.md

@@ -0,0 +1,30 @@
+---
+title: "RestorePVC Configuration for Data Movement Restore"
+layout: docs
+---
+
+`RestorePVC`  is an intermediate PVC to write data during the data movement restore operation.
+
+In some scenarios users may need to configure some advanced options of the `restorePVC` so that the data movement restore operation could perform better. Specifically:
+- For a volume with `WaitForFirstConsumer` mode, theoretically, the data mover pod should not be created until the restored is scheduled to a node; and the data movement should happen in that node only (because the pod may not run in every node because of topology constraints). This significantly degrades the prallelism of data movement restores; and this also prevents Velero from restoring a volume without a pod mounted. On the other hand,users must know their topology constrains if they have, or they must know in which nodes their restored workload pods can be scheduled. Therefore, in the backup/restore context, it is fine not to strictly follow the rule of `WaitForFirstConsumer` mode, instead, users should be allowed to configure to ignore the rule if they are aware that there is no topology constraints in their environments or they know how to select the nodes for restore pods to run appropriately.
+
+Velero introduces a new section in the node agent configuration ConfigMap (the name of this ConfigMap is passed using `--node-agent-configmap` velero server argument) called `restorePVC`, through which you can specify the following configurations:
+
+- `ignoreDelayBinding`: If this flag is set, the data movement restore will ignore the delay binding requirements from `WaitForFirstConsumer` mode, create the restore pod and provision the volume associated to an arbitrary node. When multiple volume restores happen in parallel, the restore pods will be spread evenly to all the nodes.
+
+
+The users can specify the ConfigMap name during velero installation by CLI:
+`velero install --node-agent-configmap=<ConfigMap-Name>`
+
+A sample of `restorePVC` config as part of the ConfigMap would look like:
+```json
+{
+    "restorePVC": {
+        "ignoreDelayBinding": true
+    }
+}
+```
+
+**Note:** 
+- If `ignoreDelayBinding` is set, the restored volume is provisioned in the storage areas associated to an arbitrary node, if the restored pod cannot be scheduled to that node, e.g., because of topology constraints, the data mover restore still completes, but the workload is not usable since the restored pod cannot mount the restored volume
+- At present, node selection is not supported for data mover restore, so the restored volume may be attached to any node in the cluster; once node selection is supported and enabled, the restored volume will be attached to one of the selected nodes only. In this way, node selection and `ignoreDelayBinding` can work together even though the environment is with topology constraints

site/data/docs/main-toc.yml

@@ -55,6 +55,8 @@ toc:
         url: /node-agent-concurrency
       - page: Data Movement Backup PVC Configuration
         url: /data-movement-backup-pvc-configuration
+      - page: Data Movement Restore PVC Configuration
+        url: /data-movement-restore-pvc-configuration        
       - page: Data Movement Pod Resource Configuration
         url: /data-movement-pod-resource-configuration        
       - page: Backup Repository Configuration