docs: Update OpenEBS Docs (#538)

Signed-off-by: Bala Harish <161304963+balaharish7@users.noreply.github.com>

Author: balaharish7

docs/main/Solutioning/backup-and-restore/kubevirt-backup.md

@@ -11,9 +11,9 @@ description: In this document, you learn about KubeVirt VM Backup and Restore us
 
 ## Overview
 
-KubeVirt extends Kubernetes with virtual machine (VM) management capabilities, enabling a unified platform for both containerized and virtualized workloads. Live migration of VMs is a critical feature for achieving high availability, zero-downtime maintenance, and workload mobility. However, live migration in KubeVirt requires shared ReadWriteMany (RWX) storage that can be accessed across multiple nodes.
+As Kubernetes continues to gain traction in enterprise environments, there is a growing need to support traditional workloads like virtual machines (VMs) alongside containerized applications. KubeVirt extends Kubernetes by enabling the deployment and management of VMs within a Kubernetes-native ecosystem.
 
-OpenEBS Replicated PV Mayastor is a high-performance, container-native block storage engine that provides persistent storage for Kubernetes. While Replicated PV Mayastor does not natively support RWX volumes, it can be integrated with an NFS server pod and the NFS CSI driver to provide shared access to storage volumes. This document guides you through the setup and validation of a KubeVirt live migration environment using OpenEBS Replicated PV Mayastor and NFS.
+To protect KubeVirt-based VMs, a robust backup strategy is essential. This document outlines a step-by-step method to back up KubeVirt virtual machines using Velero, a popular backup and disaster recovery tool for Kubernetes, in combination with Replicated PV Mayastor VolumeSnapshots. This approach provides consistent, point-in-time VM backups that are fully integrated with Kubernetes storage primitives and cloud-native workflows.
 
 ## Environment
 

docs/main/Solutioning/openebs-on-kubernetes-platforms/openshift.md

@@ -69,6 +69,10 @@ Before installing Replicated PV Mayastor, make sure that you meet the following
     oc adm policy -n openebs add-scc-to-user privileged -z default
     ```
 
+:::note
+It is strongly recommended to use the `-z` (service account) flag as described above, as it helps prevent typographical errors and ensures that access is granted exclusively to the specified service account. If the service account is not in the current project, use the `-n` (namespace) option to specify the applicable project namespace.
+:::
+
 ## Install Replicated PV Mayastor on OpenShift
 
 Refer to the [OpenEBS Installation Documentation](../../quickstart-guide/installation.md#installation-via-helm) to install Replicated PV Mayastor using Helm.

docs/main/Solutioning/read-write-many/kubevirt.md

@@ -10,9 +10,9 @@ description: In this document, you learn about KubeVirt VM Live Migration with N
 
 ## Overview
 
-As Kubernetes continues to gain traction in enterprise environments, there is a growing need to support traditional workloads like virtual machines (VMs) alongside containerized applications. KubeVirt extends Kubernetes by enabling the deployment and management of VMs within a Kubernetes-native ecosystem.
+KubeVirt extends Kubernetes with virtual machine (VM) management capabilities, enabling a unified platform for both containerized and virtualized workloads. Live migration of VMs is a critical feature for achieving high availability, zero-downtime maintenance, and workload mobility. However, live migration in KubeVirt requires shared ReadWriteMany (RWX) storage that can be accessed across multiple nodes.
 
-To protect KubeVirt-based VMs, a robust backup strategy is essential. This document outlines a step-by-step method to back up KubeVirt virtual machines using Velero, a popular backup and disaster recovery tool for Kubernetes, in combination with Replicated PV Mayastor VolumeSnapshots. This approach provides consistent, point-in-time VM backups that are fully integrated with Kubernetes storage primitives and cloud-native workflows.
+OpenEBS Replicated PV Mayastor is a high-performance, container-native block storage engine that provides persistent storage for Kubernetes. While Replicated PV Mayastor does not natively support RWX volumes, it can be integrated with an NFS server pod and the NFS CSI driver to provide shared access to storage volumes. This document guides you through the setup and validation of a KubeVirt live migration environment using OpenEBS Replicated PV Mayastor and NFS.
 
 ## Environment
 

docs/main/releases.md

@@ -35,18 +35,22 @@ OpenEBS is delighted to introduce the following new features with OpenEBS 4.3.2:
 ### General
 
 - **Kubectl OpenEBS Plugin**
+
   A new unified CLI plugin has been introduced. If you have deployed your cluster using the OpenEBS umbrella chart, you can now manage all supported storages - Local PV Hostpath, Local PV LVM, Local PV ZFS, and Replicated PV Mayastor using a single plugin.
 
 - **One-Step Upgrade**
+
   OpenEBS now supports a unified, one-step upgrade process for all its storages. This umbrella upgrade mechanism simplifies and streamlines the upgrade procedure across the OpenEBS ecosystem.
 
 - **Enhanced Supportability**
+
   - Support bundle collection is now available for all stable OpenEBS storages — Replicated PV Mayastor, Local PV Hostpath, Local PV LVM and Local PV ZFS using the `kubectl openebs dump system` command.
   - This unified supportability approach enables consistent and comprehensive system state capture, significantly improving the efficiency of debugging and troubleshooting. Previously, this capability was limited to Replicated PV Mayastor via the `kubectl-mayastor` plugin.
 
 ### Replicated Storage
 
 **At-Rest Encryption**
+
   You can now configure disk pools with your own encryption key, allowing volume replicas to be encrypted at rest. This is useful if you are working in environments with compliance or security requirements.
 
 ## Enhancements
@@ -74,6 +78,7 @@ OpenEBS is delighted to introduce the following new features with OpenEBS 4.3.2:
 ### Local Storage
 
 **For Local PV ZFS**
+
 - The quota property is now correctly retained during upgrades.
 - Volume restores now maintain backward compatibility for `quotatype` values.
 - Fixed a crash in the controller caused by unhandled errors in the `CSI NodeGetInfo` call.

docs/main/user-guides/replicated-storage-user-guide/replicated-pv-mayastor/configuration/rs-rdma.md

@@ -21,12 +21,12 @@ Before enabling and using RDMA in Replicated PV Mayastor, ensure the following p
 
 1. **Interface Validation**
 
-  Ensure that the interface name specified in `io-engine.target.nvmf.iface` exists on all io-engine nodes. Misconfiguration of this parameter can lead to unexpected behavior.
+  Ensure that the interface name specified in `io_engine.target.nvmf.iface` exists on all io-engine nodes. Misconfiguration of this parameter can lead to unexpected behavior.
   If the interface name is not RDMA-capable on a node, Replicated PV Mayastor volume targets on such nodes will support only TCP connections.
 
 2. **Application Node Requirements**
 
-  Application nodes must also be RDMA-capable to connect to RDMA-enabled volume targets. This capability is independent of the Helm-provided interface name for `io-engine.target.nvmf.iface`. RDMA connections will work as long as the application node has an RDMA-capable device.
+  Application nodes must also be RDMA-capable to connect to RDMA-enabled volume targets. This capability is independent of the Helm-provided interface name for `io_engine.target.nvmf.iface`. RDMA connections will work as long as the application node has an RDMA-capable device.
 
 3. **TCP Fallback Behavior**
 
@@ -50,9 +50,9 @@ Before enabling and using RDMA in Replicated PV Mayastor, ensure the following p
 
 To enable the RDMA feature via Helm:
 
-1. Set `io-engine.target.nvmf.rdma.enabled` to `true`.
+1. Set `io_engine.target.nvmf.rdma.enabled` to `true`.
 
-2. Set `io-engine.target.nvmf.iface` to a valid network interface name that exists on an RNIC.
+2. Set `io_engine.target.nvmf.iface` to a valid network interface name that exists on an RNIC.
 
 3. Verify that all nodes are properly configured with RDMA-capable hardware and that network interfaces are correctly identified and accessible.
 

docs/versioned_docs/version-4.3.x/Solutioning/backup-and-restore/kubevirt-backup.md

@@ -11,9 +11,9 @@ description: In this document, you learn about KubeVirt VM Backup and Restore us
 
 ## Overview
 
-KubeVirt extends Kubernetes with virtual machine (VM) management capabilities, enabling a unified platform for both containerized and virtualized workloads. Live migration of VMs is a critical feature for achieving high availability, zero-downtime maintenance, and workload mobility. However, live migration in KubeVirt requires shared ReadWriteMany (RWX) storage that can be accessed across multiple nodes.
+As Kubernetes continues to gain traction in enterprise environments, there is a growing need to support traditional workloads like virtual machines (VMs) alongside containerized applications. KubeVirt extends Kubernetes by enabling the deployment and management of VMs within a Kubernetes-native ecosystem.
 
-OpenEBS Replicated PV Mayastor is a high-performance, container-native block storage engine that provides persistent storage for Kubernetes. While Replicated PV Mayastor does not natively support RWX volumes, it can be integrated with an NFS server pod and the NFS CSI driver to provide shared access to storage volumes. This document guides you through the setup and validation of a KubeVirt live migration environment using OpenEBS Replicated PV Mayastor and NFS.
+To protect KubeVirt-based VMs, a robust backup strategy is essential. This document outlines a step-by-step method to back up KubeVirt virtual machines using Velero, a popular backup and disaster recovery tool for Kubernetes, in combination with Replicated PV Mayastor VolumeSnapshots. This approach provides consistent, point-in-time VM backups that are fully integrated with Kubernetes storage primitives and cloud-native workflows.
 
 ## Environment
 

docs/versioned_docs/version-4.3.x/Solutioning/openebs-on-kubernetes-platforms/openshift.md

@@ -69,6 +69,10 @@ Before installing Replicated PV Mayastor, make sure that you meet the following
     oc adm policy -n openebs add-scc-to-user privileged -z default
     ```
 
+:::note
+It is strongly recommended to use the `-z` (service account) flag as described above, as it helps prevent typographical errors and ensures that access is granted exclusively to the specified service account. If the service account is not in the current project, use the `-n` (namespace) option to specify the applicable project namespace.
+:::
+
 ## Install Replicated PV Mayastor on OpenShift
 
 Refer to the [OpenEBS Installation Documentation](../../quickstart-guide/installation.md#installation-via-helm) to install Replicated PV Mayastor using Helm.

docs/versioned_docs/version-4.3.x/Solutioning/read-write-many/kubevirt.md

@@ -10,9 +10,9 @@ description: In this document, you learn about KubeVirt VM Live Migration with N
 
 ## Overview
 
-As Kubernetes continues to gain traction in enterprise environments, there is a growing need to support traditional workloads like virtual machines (VMs) alongside containerized applications. KubeVirt extends Kubernetes by enabling the deployment and management of VMs within a Kubernetes-native ecosystem.
+KubeVirt extends Kubernetes with virtual machine (VM) management capabilities, enabling a unified platform for both containerized and virtualized workloads. Live migration of VMs is a critical feature for achieving high availability, zero-downtime maintenance, and workload mobility. However, live migration in KubeVirt requires shared ReadWriteMany (RWX) storage that can be accessed across multiple nodes.
 
-To protect KubeVirt-based VMs, a robust backup strategy is essential. This document outlines a step-by-step method to back up KubeVirt virtual machines using Velero, a popular backup and disaster recovery tool for Kubernetes, in combination with Replicated PV Mayastor VolumeSnapshots. This approach provides consistent, point-in-time VM backups that are fully integrated with Kubernetes storage primitives and cloud-native workflows.
+OpenEBS Replicated PV Mayastor is a high-performance, container-native block storage engine that provides persistent storage for Kubernetes. While Replicated PV Mayastor does not natively support RWX volumes, it can be integrated with an NFS server pod and the NFS CSI driver to provide shared access to storage volumes. This document guides you through the setup and validation of a KubeVirt live migration environment using OpenEBS Replicated PV Mayastor and NFS.
 
 ## Environment
 

docs/versioned_docs/version-4.3.x/releases.md

@@ -35,18 +35,22 @@ OpenEBS is delighted to introduce the following new features with OpenEBS 4.3.2:
 ### General
 
 - **Kubectl OpenEBS Plugin**
+
   A new unified CLI plugin has been introduced. If you have deployed your cluster using the OpenEBS umbrella chart, you can now manage all supported storages - Local PV Hostpath, Local PV LVM, Local PV ZFS, and Replicated PV Mayastor using a single plugin.
 
 - **One-Step Upgrade**
+
   OpenEBS now supports a unified, one-step upgrade process for all its storages. This umbrella upgrade mechanism simplifies and streamlines the upgrade procedure across the OpenEBS ecosystem.
 
 - **Enhanced Supportability**
+
   - Support bundle collection is now available for all stable OpenEBS storages — Replicated PV Mayastor, Local PV Hostpath, Local PV LVM and Local PV ZFS using the `kubectl openebs dump system` command.
   - This unified supportability approach enables consistent and comprehensive system state capture, significantly improving the efficiency of debugging and troubleshooting. Previously, this capability was limited to Replicated PV Mayastor via the `kubectl-mayastor` plugin.
 
 ### Replicated Storage
 
 **At-Rest Encryption**
+
   You can now configure disk pools with your own encryption key, allowing volume replicas to be encrypted at rest. This is useful if you are working in environments with compliance or security requirements.
 
 ## Enhancements
@@ -74,6 +78,7 @@ OpenEBS is delighted to introduce the following new features with OpenEBS 4.3.2:
 ### Local Storage
 
 **For Local PV ZFS**
+
 - The quota property is now correctly retained during upgrades.
 - Volume restores now maintain backward compatibility for `quotatype` values.
 - Fixed a crash in the controller caused by unhandled errors in the `CSI NodeGetInfo` call.

docs/versioned_docs/version-4.3.x/user-guides/replicated-storage-user-guide/replicated-pv-mayastor/configuration/rs-rdma.md

@@ -21,12 +21,12 @@ Before enabling and using RDMA in Replicated PV Mayastor, ensure the following p
 
 1. **Interface Validation**
 
-  Ensure that the interface name specified in `io-engine.target.nvmf.iface` exists on all io-engine nodes. Misconfiguration of this parameter can lead to unexpected behavior.
+  Ensure that the interface name specified in `io_engine.target.nvmf.iface` exists on all io-engine nodes. Misconfiguration of this parameter can lead to unexpected behavior.
   If the interface name is not RDMA-capable on a node, Replicated PV Mayastor volume targets on such nodes will support only TCP connections.
 
 2. **Application Node Requirements**
 
-  Application nodes must also be RDMA-capable to connect to RDMA-enabled volume targets. This capability is independent of the Helm-provided interface name for `io-engine.target.nvmf.iface`. RDMA connections will work as long as the application node has an RDMA-capable device.
+  Application nodes must also be RDMA-capable to connect to RDMA-enabled volume targets. This capability is independent of the Helm-provided interface name for `io_engine.target.nvmf.iface`. RDMA connections will work as long as the application node has an RDMA-capable device.
 
 3. **TCP Fallback Behavior**
 
@@ -50,9 +50,9 @@ Before enabling and using RDMA in Replicated PV Mayastor, ensure the following p
 
 To enable the RDMA feature via Helm:
 
-1. Set `io-engine.target.nvmf.rdma.enabled` to `true`.
+1. Set `io_engine.target.nvmf.rdma.enabled` to `true`.
 
-2. Set `io-engine.target.nvmf.iface` to a valid network interface name that exists on an RNIC.
+2. Set `io_engine.target.nvmf.iface` to a valid network interface name that exists on an RNIC.
 
 3. Verify that all nodes are properly configured with RDMA-capable hardware and that network interfaces are correctly identified and accessible.