From 32d9da19310b815f1d42543b37dffdc9bdd7a325 Mon Sep 17 00:00:00 2001
From: Yan Du <yadu@redhat.com>
Date: Wed, 25 Mar 2026 17:51:22 +0800
Subject: [PATCH 01/13] storage: Add STP for offline storage migration

Signed-off-by: Yan Du <yadu@redhat.com>
---
 stps/sig-storage/storage_mig_offline.md | 431 ++++++++++++++++++++++++
 1 file changed, 431 insertions(+)
 create mode 100644 stps/sig-storage/storage_mig_offline.md

diff --git a/stps/sig-storage/storage_mig_offline.md b/stps/sig-storage/storage_mig_offline.md
new file mode 100644
index 00000000..bc3935b6
--- /dev/null
+++ b/stps/sig-storage/storage_mig_offline.md
@@ -0,0 +1,431 @@
+# Openshift-virtualization-tests Test plan
+
+## **Offline Storage Migration - Quality Engineering Plan**
+
+### **Metadata & Tracking**
+
+- **Enhancement(s):** https://github.com/kubevirt/kubevirt-migration-controller/pull/32
+- **Feature Tracking:** [CNV-73509](https://redhat.atlassian.net/browse/CNV-73509)
+- **Epic Tracking:** [CNV-73500](https://redhat.atlassian.net/browse/CNV-73500)
+- **QE Owner(s):** Yan Du
+- **Owning SIG:** sig-storage
+- **Participating SIGs:** sig-storage
+
+**Document Conventions:**
+None
+
+### **Feature Overview**
+
+This feature extends the OpenShift Virtualization migration plan to support storage migration for offline (stopped) VMs in addition to existing online (running) VM support. It enables customers to migrate storage for VMs regardless of their running state, allowing mixed migration plans containing both offline and running VMs.
+
+---
+
+### **I. Motivation and Requirements Review (QE Review Guidelines)**
+
+This section documents the mandatory QE review process. The goal is to understand the feature's value,
+technology, and testability before formal test planning.
+
+#### **1. Requirement & User Story Review Checklist**
+
+<!-- **How to complete this checklist:**
+1. **Checkbox**: Mark [x] if the check is complete; if the item cannot be checked - add an explanation why in the `details` section
+2. Complete the relevant, needed details for the checklist item -->
+
+- [x] **Review Requirements**
+  <!-- Review the D/S (Downstream) requirements as defined in Jira. Understand the difference between Upstream (U/S) and D/S requirements.
+  Example: "VMs must migrate without network downtime exceeding the defined threshold during node maintenance." -->
+  - *List the key D/S requirements reviewed:* Reviewed the user cases for offline VM storage migration from CNV-82430 and CNV-73500
+
+- [x] **Understand Value and Customer Use Cases**
+  <!-- Understand why the feature matters to customers from a D/S perspective and what the real-world use cases are.
+  Example: "Customers need to migrate VMs without network downtime to maintain SLA compliance during node maintenance." -->
+  - *Describe the feature's value to customers:* Enables customers to perform storage migration for offline VMs without requiring them to be running, providing flexibility in storage management operations.
+  - *List the customer use cases identified:* Storage migration for mixed offline VMs and running VMs in one migration plan, allowing batch migration operations regardless of VM state.
+
+- [x] **Testability**
+  <!-- Confirmed requirements are **testable and unambiguous**. -->
+  - *Note any requirements that are unclear or untestable:* Requirements are testable. Downstream build with the feature code is available for testing.
+
+- [x] **Acceptance Criteria**
+  <!-- Acceptance criteria are the specific, verifiable conditions that must be met for the feature to be considered complete — they define *how we know it works*.
+  Example: "VM migrates without network downtime exceeding 500ms", "VM deletion is blocked for non-admin users." -->
+  - *List the acceptance criteria:*
+    - Storage migration completes successfully for offline VMs between ODF and HPP storage classes
+    - Storage migration completes successfully for mixed offline VMs and running VMs
+    - Storage migration completes successfully for offline VMs with hotplug disk
+    - Source volume could be retained/cleaned up for an offline VM migration completed with retentionPolicy defined
+    - Offline VM points to the origin volume when migration failed
+    - Migration succeeded when starting a stopped VM during migration
+
+  - *Note any gaps or missing criteria:* N/A
+
+- [x] **Non-Functional Requirements (NFRs)**
+  <!-- Confirmed coverage for NFRs, including Performance, Security, Usability, Downtime, Connectivity, Monitoring (alerts/metrics), Scalability, Portability (e.g., cloud support), and Docs.-->
+  - *List applicable NFRs and their targets:* Documentation updates to reflect offline VM storage migration support
+  - *Note any NFRs not covered and why:* Performance and scale testing are not included in this test plan
+
+#### **2. Known Limitations**
+
+The limitations are documented to ensure alignment between development, QA, and product teams.
+The following topics will not be tested or supported.
+
+<!-- Document any known limitations, constraints, or trade-offs in the feature implementation or testing approach.
+
+**Examples:**
+Feature related:
+- The feature is only supports YYY storage class
+- Feature does not support IPv6 (only IPv4)
+- No support for ARM64 architecture in this release
+- The feature is incompatible with ZZZ feature
+
+Tests related:
+- CPU xxx will not be tested due to lack of hardware
+- Integration with [Third-Party Service] is excluded; all external calls will be mocked using static data-->
+
+None identified at this time.
+
+#### **3. Technology and Design Review**
+
+<!-- **How to complete this checklist:**
+1. **Checkbox**: Mark [x] if done
+2. Complete the relevant, needed details for the checklist item -->
+
+- [x] **Developer Handoff/QE Kickoff**
+  <!-- A meeting where Dev/Arch walked QE through the design, architecture, and implementation details. **Critical for identifying untestable aspects early.**-->
+  - *Key takeaways and concerns:* Extend the offline VMs storage migration support
+
+- [x] **Technology Challenges**
+  <!-- Identified potential testing challenges related to the underlying technology.-->
+  - *List identified challenges:* Offline migration uses a different mechanism than online migration, requiring separate test coverage
+  - *Impact on testing approach:* Test cases must verify both offline VM migration mixed scenarios with both offline and running VMs in the same migration plan.
+
+- [x] **API Extensions**
+  <!-- Review new or modified APIs and their impact on testing. Covers both new tests for new APIs and updates to existing tests for modified APIs.
+  Example: "New VirtualMachineSnapshot API v1beta2 — 3 new endpoints, 1 modified endpoint. Existing snapshot tests need updating." -->
+  - *List new or modified APIs:* No new APIs - extends existing migration plan API to handle offline VMs
+  - *Testing impact:* No API test updates required; functional tests will verify new behavior
+
+- [x] **Test Environment Needs**
+  <!-- Identified whether special environment setups are needed beyond standard infrastructure.-->
+  - *See environment requirements in Section II.3 and testing tools in Section II.3.1*
+
+- [x] **Topology Considerations**
+  <!-- Evaluated multi-cluster, network topology, and architectural impacts.-->
+  - *Describe topology requirements:* Standard 3-master/3-worker cluster sufficient
+  - *Impact on test design:* No special topology requirements
+
+### **II. Software Test Plan (STP)**
+
+This STP serves as the **overall roadmap for testing**, detailing the scope, approach, resources, and schedule.
+
+#### **1. Scope of Testing**
+
+<!-- Briefly describe what will be tested. The scope must **cover functional and non-functional requirements**.
+Must ensure user stories are included and aligned to downstream user stories from Section I. -->
+
+**Testing Goals**
+
+<!-- Testing goals are specific, measurable objectives — they say *what* must be verified and *how* success is measured.
+
+Define specific, measurable testing objectives for this feature using **SMART criteria**
+(Specific, Measurable, Achievable, Relevant, Time-bound).
+Each goal should tie back to requirements from Section I and be independently verifiable.
+
+**How to Define Good Testing Goals:**
+- **Specific**: Clearly state what will be tested (not "test the feature" but "validate VM live migration
+  with SR-IOV networks")
+- **Measurable**: Define quantifiable success criteria (e.g., "95% of VM migrations complete within xxx seconds")
+- **Achievable**: Realistic given resources and timeline
+- **Relevant**: Directly supports feature acceptance criteria and user stories
+- **Verifiable**: Can be objectively confirmed as complete
+
+**Priority Levels:**
+- **P0**: Blocking GA - must be complete before release
+- **P1**: High priority - required for full feature coverage
+- **P2**: Nice-to-have - can be deferred if timeline constraints exist -->
+
+<!-- **Example - Functional Goals**:
+- **[P0]** Verify VM live migration completes successfully with new network binding plugin across
+  OVN-Kubernetes and secondary networks
+- **[P1]** Validate hotplug/hotunplug operations work with new storage class without VM restart
+- **[P0]** Confirm RBAC permissions model correctly restricts non-admin users from accessing
+  cluster-wide configuration API
+- **[P2]** Validate new metrics with real-time VM performance data (CPU, memory, network, disk I/O)
+
+**Example - Quality Goals**:
+- **[P0]** Verify VM live migration completes in <30 seconds for VMs with <8GB memory
+  (performance baseline from VEP-XXXX)
+- **[P1]** Confirm feature operates correctly in disconnected/air-gapped environments with local
+  image registry
+- **[P0]** Validate zero data loss during live migration under network latency up to 100ms
+
+**Example - Integration Goals**:
+- **[P0]** Verify backward compatibility: upgrade from OCP 4.19 to 4.20 preserves existing VM
+  configurations without manual intervention
+- **[P0]** Confirm interoperability with OpenShift Service Mesh when VMs use Istio sidecar injection
+- **[P1]** Test integration with OpenShift monitoring stack: metrics appear in Prometheus,
+  alerts fire correctly in Alertmanager -->
+
+- **[P0]** Verify offline VM storage migration completes between ODF and HPP storage classes, and the VM boots successfully after migration
+- **[P0]** Verify storage migration completes for a migration plan containing both offline and running VMs
+- **[P1]** Verify offline VM storage migration completes when the VM has hotplug disks attached
+- **[P0]** Verify source volumes are retained or deleted according to retentionPolicy configuration when offline VM storage migration completes
+- **[P2]** Verify offline VM continues pointing to the original volume when storage migration fails
+- **[P2]** Verify storage migration completes when a stopped VM is started during the migration process
+
+**Storage Class Coverage**
+
+The following storage class migration combinations will be tested:
+- **ODF (ocs-storagecluster-ceph-rbd-virtualization) ↔ HPP (hostpath-provisioner)
+- **ODF ↔ ODF** — Same storage class migration
+- **HPP ↔ HPP** — Same storage class migration
+
+Storage classes **not covered** in this test plan:
+- Cloud provider-specific storage classes (AWS EBS, Azure Disk, GCP PD) — Out of scope for initial release
+
+**Out of Scope (Testing Scope Exclusions)**
+
+The following items are explicitly Out of Scope for this test cycle and represent intentional exclusions.
+No verification activities will be performed for these items, and any related issues found will not be classified as defects for this release.
+
+<!-- Explicitly document what is **out of scope** for testing.
+This section define the test boundaries; for example: test coverage by other teams, edge cases, low priority, etc.
+**Critical:** All out-of-scope items require explicit stakeholder agreement to prevent "I assumed you were testing
+that" issues; each out-of-scope item must have PM/Lead sign-off.
+
+- Items without stakeholder agreement are considered **risks** and must be escalated
+- Review the items during Developer Handoff/QE Kickoff meeting
+
+**Note:** Replace examples with your actual out-of-scope items. If there are no items; delete the checklist and add `None`-->
+
+None
+
+#### **2. Test Strategy**
+
+<!-- The following test strategy considerations must be reviewed and addressed. Mark [x] if applicable,
+leave unchecked if not applicable (with justification in Details). Unchecked items without details
+indicate incomplete review.
+
+Note: Strategy defines *which types of testing* apply and the high-level approach. Goals (Section II.1) define the specific, measurable objectives.
+Example: Strategy says "Performance testing is applicable — we will measure migration stuntime." Goals say "[P0] Verify VM stuntime during live migration is below 500ms." -->
+
+**Functional**
+
+- [x] **Functional Testing** — Validates that the feature works according to specified requirements and user stories
+  <!-- Mark if this feature requires functional testing. Functional testing validates that the feature works as specified — as opposed to non-functional testing (performance, security, scale, etc.) which validates how well it works. -->
+  - *Details:* Functional testing will verify offline VM storage migration and mixed offline/online VM migration scenarios
+
+- [x] **Automation Testing** — Confirms test automation plan is in place for CI and regression coverage (all tests are expected to be automated)
+  <!-- Example: "All Tier 2 tests automated by sprint 3, integrated into nightly CI lane." -->
+  - *Details:* All test cases will be automated
+
+- [x] **Regression Testing** — Verifies that new changes do not break existing functionality
+  - *Details:* Verify that existing online VM storage migration functionality remains unaffected by the offline VM support additions
+
+**Non-Functional**
+
+- [ ] **Performance Testing** — Validates feature performance meets requirements (latency, throughput, resource usage)
+  - *Details:* Performance testing for bulk offline migrations is tracked separately in CNV-82430 and will be covered by a separate test plan
+
+- [ ] **Scale Testing** — Validates feature behavior under increased load and at production-like scale (e.g., large number of VMs, nodes, or concurrent operations)
+  - *Details:* Not applicable
+
+- [ ] **Security Testing** — Verifies security requirements, RBAC, authentication, authorization, and vulnerability scanning
+  - *Details:* Not applicable
+
+- [x] **Usability Testing** — Validates user experience and accessibility requirements
+  - Does the feature require a UI? If so, ensure the UI aligns with the requirements (UI/UX consistency, accessibility)
+  - Does the feature expose CLI commands? If so, validate usability and that needed information is available (e.g., status conditions, clear output)
+  - Does the feature trigger backend operations that should be reported to the admin? If so, validate that the user receives clear feedback about the operation and its outcome (e.g., status conditions, events, or notifications indicating success or failure)
+  - *Details:* UI testing will be covered in https://redhat.atlassian.net/browse/CNV-77503
+
+- [ ] **Monitoring** — Does the feature require metrics and/or alerts?
+  - *Details:* Not applicable
+
+**Integration & Compatibility**
+
+- [x] **Compatibility Testing** — Ensures feature works across supported platforms, versions, and configurations
+  - Does the feature maintain backward compatibility with previous API versions and configurations?
+  - *Details:* Feature maintains backward compatibility with existing migration API. Existing online VM migrations continue to work unchanged.
+
+- [ ] **Upgrade Testing** — Validates upgrade paths from previous versions, data migration, and configuration preservation
+  - *Details:* Not applicable
+
+- [ ] **Dependencies** — Blocked by deliverables from other components/products. Identify what we need from other teams before we can test.
+  <!-- Example: "Blocked on Storage team delivering CSI driver v2.0 — cannot test snapshot feature without it." -->
+  - *Details:* No blocking dependencies
+
+- [x] **Cross Integrations** — Does the feature affect other features or require testing by other teams? Identify the impact we cause.
+  <!-- Example: "Our API change affects the UI team's VM details page — they need to update their tests." -->
+  - *Details:* UI team needs to update their migration UI to support offline VM selection
+
+**Infrastructure**
+
+- [ ] **Cloud Testing** — Does the feature require multi-cloud platform testing? Consider cloud-specific features.
+  - *Details:* Not applicable
+
+#### **3. Test Environment**
+
+<!-- **Note:** "N/A" means explicitly not applicable. All items must be filled or marked N/A. -->
+
+- **Cluster Topology:** 3-master/3-worker bare-metal
+  <!-- Change if different, e.g., SNO, Compact Cluster, HCP -->
+
+- **OCP & OpenShift Virtualization Version(s):** OCP 4.22 with OpenShift Virtualization 4.22
+  <!-- Specify exact versions to allow version traceability -->
+
+- **CPU Virtualization:** VT-x (Intel) or AMD-V enabled
+  <!-- Change only if specific CPU requirements exist -->
+
+- **Compute Resources:** Minimum per worker node: 8 vCPUs, 32GB RAM
+  <!-- Adjust based on feature requirements -->
+
+- **Special Hardware:** N/A
+  <!-- Fill if needed, e.g., SR-IOV NICs, GPUs -->
+
+- **Storage:** ocs-storagecluster-ceph-rbd-virtualization, hostpath-provisioner
+  <!-- Change if specific StorageClass(es) required -->
+
+- **Network:** OVN-Kubernetes, IPv4
+  <!-- Change if needed, e.g., Secondary Networks, IPv6, dual-stack -->
+
+- **Required Operators:** N/A
+  <!-- Add if needed, e.g., NMState Operator -->
+
+- **Platform:** PSI
+  <!-- Change if needed, e.g., AWS, Azure, GCP -->
+
+- **Special Configurations:** N/A
+  <!-- Change if needed, e.g., Disconnected/air-gapped, Proxy, FIPS mode -->
+
+#### **3.1. Testing Tools & Frameworks**
+
+<!-- Document any **new or additional** testing tools, frameworks, or infrastructure required specifically
+for this feature. **Note:** Only list tools that are **new** or **different** from standard testing infrastructure. -->
+
+- **Test Framework:** Standard
+  <!-- Change if needed, e.g., new framework, custom test harness, significant changes in tests infrastructure code etc  -->
+
+- **CI/CD:** N/A
+  <!-- Change if needed, e.g., special test lane, custom pipeline config -->
+
+- **Other Tools:** N/A
+  <!-- Fill if needed, e.g., special monitoring, performance tools -->
+
+#### **4. Entry Criteria**
+
+The following conditions must be met before testing can begin:
+
+- [x] Requirements and design documents are **approved and merged**
+- [x] Test environment can be **set up and configured** (see Section II.3 - Test Environment)
+
+#### **5. Exit Criteria**
+
+- [ ] All high-priority defects are resolved and verified
+- [ ] Test coverage goals achieved
+- [ ] Test automation merged (required for GA sign-off)
+- [ ] All planned test cycles completed
+- [ ] Test summary report approved
+- [ ] Acceptance criteria met
+
+#### **6. Risks**
+
+<!-- Document specific risks for this feature. If a risk category is not applicable, mark as "N/A" with
+justification in mitigation strategy. -->
+
+**Timeline/Schedule**
+
+- **Risk:** N/A
+  - **Mitigation:** N/A
+  - *Estimated impact on schedule:* None
+
+**Test Coverage**
+
+- **Risk:** N/A
+  - **Mitigation:** All acceptance criteria are covered by planned test scenarios
+  - *Areas with reduced coverage:* None
+
+**Test Environment**
+
+- **Risk:** N/A
+  - **Mitigation:** Standard test environment is sufficient for testing this feature
+  - *Missing resources or infrastructure:* None
+
+**Untestable Aspects**
+
+- **Risk:** N/A
+  - **Mitigation:** N/A
+  - *Alternative validation approach:* N/A
+
+**Resource Constraints**
+
+- **Risk:** N/A
+  - **Mitigation:** N/A
+  - *Current capacity gaps:* None
+
+**Dependencies**
+
+- **Risk:** N/A
+  - **Mitigation:** No external dependencies
+  - *Dependent teams or components:* UI team for UI updates (non-blocking)
+
+**Other**
+
+- **Risk:** N/A
+  - **Mitigation:** No additional risks identified
+  <!-- If more context is needed for this item, add an entry with any relevant details-->
+
+---
+
+### **III. Test Scenarios & Traceability**
+
+<!-- This section links D/S requirements to test coverage, enabling reviewers to verify all requirements are tested.
+
+**What goes here:** New test scenarios specific to this feature. Each scenario should trace to a D/S Jira requirement.
+**Granularity:** If one scenario can fail while another passes, they should be separate items. For example:
+- Different conditions (VMs with feature X vs without) → separate scenarios
+- Feature Gate enable/disable → separate scenarios (different expected behavior)
+- Multiple alerts → separate if different trigger conditions, group if same flow
+**What does NOT go here:** Regression tests (covered in Test Strategy). -->
+
+<!-- **Requirement ID:**
+- Use Jira issue key (e.g., CNV-12345)
+
+**Requirement Summary:** Brief description from the Jira issue (user story format preferred) -->
+
+- **[CNV-73500]** — As a VM owner, I want to migrate storage for offline VMs between ODF and HPP
+  - *Test Scenario:* [Tier 2] Verify storage migration completes for offline VMs between ODF and HPP, and the VM boots sucessfully after migration
+  - *Priority:* P0
+
+- **[CNV-73500]** — As a VM owner, I want to migrate storage with mixed VM states (online and offline)
+  - *Test Scenario:* [Tier 2] Verify storage migration completes for a migration plan containing both offline and running VMs
+  - *Priority:* P0
+
+- **[CNV-73500]** — As a VM owner, I want to migrate storage for offline VMs with hotplug disk
+  - *Test Scenario:* [Tier 2] Verify storage migration completes successfully for offline VM with hotplug disk
+  - *Priority:* P1
+
+- **[CNV-73500]** — As a VM owner, I want to retain or delete the source volume for an offline VM
+  - *Test Scenario:* [Tier 2] Verify source volume is retained or cleaned up for an offline VM when retentionPolicy is set in the Migration Plan
+  - *Priority:* P0
+
+- **[CNV-73500]** — As a VM owner, I want an offline VM to still point to the original volume when migration fails
+  - *Test Scenario:* [Tier 2] Verify an offline VM still points to the original volume when migration fails
+  - *Priority:* P2
+
+- **[CNV-73500]** — As a VM owner, I want the migration to succeed when starting a stopped VM during migration
+  - *Test Scenario:* [Tier 2] Verify migration succeeds when starting a stopped VM during the migration process
+  - *Priority:* P2
+
+---
+
+### **IV. Sign-off and Approval**
+
+This Software Test Plan requires approval from the following stakeholders:
+
+* **Reviewers:**
+  - QE Architect (OCP-V): Ruth Netser (`@rnetser`)
+  - QE Members (OCP-V): Jenia Peimer (`@jpeimer`), Kate Shvaika (`@kshvaika`), Jose Manuel Castano (`@joscasta`)
+* **Approvers:**
+  - QE Architect (OCP-V): Ruth Netser (`@rnetser`)
+  - Principal Developer: Alexander Wels (`@awels`)

From f8797b91aed5a280cd8a84fad1badf7848b3570c Mon Sep 17 00:00:00 2001
From: Jose Manuel Castano <joscasta@redhat.com>
Date: Thu, 16 Apr 2026 09:16:14 +0200
Subject: [PATCH 02/13] Fix codeRabbit comments.

Signed-off-by: Jose Manuel Castano <joscasta@redhat.com>
---
 stps/sig-storage/storage_mig_offline.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/stps/sig-storage/storage_mig_offline.md b/stps/sig-storage/storage_mig_offline.md
index bc3935b6..08076733 100644
--- a/stps/sig-storage/storage_mig_offline.md
+++ b/stps/sig-storage/storage_mig_offline.md
@@ -7,7 +7,7 @@
 - **Enhancement(s):** https://github.com/kubevirt/kubevirt-migration-controller/pull/32
 - **Feature Tracking:** [CNV-73509](https://redhat.atlassian.net/browse/CNV-73509)
 - **Epic Tracking:** [CNV-73500](https://redhat.atlassian.net/browse/CNV-73500)
-- **QE Owner(s):** Yan Du
+- **QE Owner(s):** Jose Manuel Castano (joscasta@redhat.com)
 - **Owning SIG:** sig-storage
 - **Participating SIGs:** sig-storage
 
@@ -39,7 +39,7 @@ technology, and testability before formal test planning.
 - [x] **Understand Value and Customer Use Cases**
   <!-- Understand why the feature matters to customers from a D/S perspective and what the real-world use cases are.
   Example: "Customers need to migrate VMs without network downtime to maintain SLA compliance during node maintenance." -->
-  - *Describe the feature's value to customers:* Enables customers to perform storage migration for offline VMs without requiring them to be running, providing flexibility in storage management operations.
+  - *Describe the feature's value to customers:* Customers need to perform storage migration for offline VMs without requiring them to be running, providing flexibility in storage management operations.
   - *List the customer use cases identified:* Storage migration for mixed offline VMs and running VMs in one migration plan, allowing batch migration operations regardless of VM state.
 
 - [x] **Testability**
@@ -61,8 +61,8 @@ technology, and testability before formal test planning.
 
 - [x] **Non-Functional Requirements (NFRs)**
   <!-- Confirmed coverage for NFRs, including Performance, Security, Usability, Downtime, Connectivity, Monitoring (alerts/metrics), Scalability, Portability (e.g., cloud support), and Docs.-->
-  - *List applicable NFRs and their targets:* Documentation updates to reflect offline VM storage migration support
-  - *Note any NFRs not covered and why:* Performance and scale testing are not included in this test plan
+  - *List applicable NFRs and their targets:* Documentation updates to reflect offline VM storage migration support and UI support for offline VM migrations. 
+  - *Note any NFRs not covered and why:* Performance, Monitoring, Observability, Security and Scalability testing are not included in this test plan
 
 #### **2. Known Limitations**
 
@@ -82,7 +82,7 @@ Tests related:
 - CPU xxx will not be tested due to lack of hardware
 - Integration with [Third-Party Service] is excluded; all external calls will be mocked using static data-->
 
-None identified at this time.
+None - reviewed and confirmed with Yan Du on Apr 7,2026.
 
 #### **3. Technology and Design Review**
 
@@ -168,8 +168,8 @@ Each goal should tie back to requirements from Section I and be independently ve
 
 - **[P0]** Verify offline VM storage migration completes between ODF and HPP storage classes, and the VM boots successfully after migration
 - **[P0]** Verify storage migration completes for a migration plan containing both offline and running VMs
-- **[P1]** Verify offline VM storage migration completes when the VM has hotplug disks attached
 - **[P0]** Verify source volumes are retained or deleted according to retentionPolicy configuration when offline VM storage migration completes
+- **[P1]** Verify offline VM storage migration completes when the VM has hotplug disks attached
 - **[P2]** Verify offline VM continues pointing to the original volume when storage migration fails
 - **[P2]** Verify storage migration completes when a stopped VM is started during the migration process
 

From c5a8254d97db36c39bf960616c48ca0c5f9ab881 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Thu, 16 Apr 2026 07:16:53 +0000
Subject: [PATCH 03/13] [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci
---
 stps/sig-storage/storage_mig_offline.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/stps/sig-storage/storage_mig_offline.md b/stps/sig-storage/storage_mig_offline.md
index 08076733..132b7f66 100644
--- a/stps/sig-storage/storage_mig_offline.md
+++ b/stps/sig-storage/storage_mig_offline.md
@@ -61,7 +61,7 @@ technology, and testability before formal test planning.
 
 - [x] **Non-Functional Requirements (NFRs)**
   <!-- Confirmed coverage for NFRs, including Performance, Security, Usability, Downtime, Connectivity, Monitoring (alerts/metrics), Scalability, Portability (e.g., cloud support), and Docs.-->
-  - *List applicable NFRs and their targets:* Documentation updates to reflect offline VM storage migration support and UI support for offline VM migrations. 
+  - *List applicable NFRs and their targets:* Documentation updates to reflect offline VM storage migration support and UI support for offline VM migrations.
   - *Note any NFRs not covered and why:* Performance, Monitoring, Observability, Security and Scalability testing are not included in this test plan
 
 #### **2. Known Limitations**

From d4cbcc83db505799194fb1801a0a723f123fbcf7 Mon Sep 17 00:00:00 2001
From: Jose Manuel Castano <joscasta@redhat.com>
Date: Thu, 16 Apr 2026 09:28:43 +0200
Subject: [PATCH 04/13] Added Risks Review Sign-off to Risks sections

Signed-off-by: Jose Manuel Castano <joscasta@redhat.com>
---
 stps/sig-storage/storage_mig_offline.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/stps/sig-storage/storage_mig_offline.md b/stps/sig-storage/storage_mig_offline.md
index 132b7f66..c638b368 100644
--- a/stps/sig-storage/storage_mig_offline.md
+++ b/stps/sig-storage/storage_mig_offline.md
@@ -375,6 +375,8 @@ justification in mitigation strategy. -->
   - **Mitigation:** No additional risks identified
   <!-- If more context is needed for this item, add an entry with any relevant details-->
 
+> **Risks Review Sign-off:** All risk categories reviewed and confirmed N/A or addressed above — Yan Du, Apr 7,2026
+
 ---
 
 ### **III. Test Scenarios & Traceability**
@@ -394,7 +396,7 @@ justification in mitigation strategy. -->
 **Requirement Summary:** Brief description from the Jira issue (user story format preferred) -->
 
 - **[CNV-73500]** — As a VM owner, I want to migrate storage for offline VMs between ODF and HPP
-  - *Test Scenario:* [Tier 2] Verify storage migration completes for offline VMs between ODF and HPP, and the VM boots sucessfully after migration
+  - *Test Scenario:* [Tier 2] Verify storage migration completes for offline VMs between ODF and HPP, and the VM boots successfully after migration
   - *Priority:* P0
 
 - **[CNV-73500]** — As a VM owner, I want to migrate storage with mixed VM states (online and offline)

From dbc0d6ad707f5f22d8998891fd8e417afb6ac19e Mon Sep 17 00:00:00 2001
From: Jose Manuel Castano <joscasta@redhat.com>
Date: Thu, 16 Apr 2026 09:47:40 +0200
Subject: [PATCH 05/13] Remove comment markers and fix some codeRabbit
 suggestions

Signed-off-by: Jose Manuel Castano <joscasta@redhat.com>
---
 stps/sig-storage/storage_mig_offline.md | 138 +-----------------------
 1 file changed, 1 insertion(+), 137 deletions(-)

diff --git a/stps/sig-storage/storage_mig_offline.md b/stps/sig-storage/storage_mig_offline.md
index c638b368..254295ae 100644
--- a/stps/sig-storage/storage_mig_offline.md
+++ b/stps/sig-storage/storage_mig_offline.md
@@ -27,28 +27,17 @@ technology, and testability before formal test planning.
 
 #### **1. Requirement & User Story Review Checklist**
 
-<!-- **How to complete this checklist:**
-1. **Checkbox**: Mark [x] if the check is complete; if the item cannot be checked - add an explanation why in the `details` section
-2. Complete the relevant, needed details for the checklist item -->
-
 - [x] **Review Requirements**
-  <!-- Review the D/S (Downstream) requirements as defined in Jira. Understand the difference between Upstream (U/S) and D/S requirements.
-  Example: "VMs must migrate without network downtime exceeding the defined threshold during node maintenance." -->
   - *List the key D/S requirements reviewed:* Reviewed the user cases for offline VM storage migration from CNV-82430 and CNV-73500
 
 - [x] **Understand Value and Customer Use Cases**
-  <!-- Understand why the feature matters to customers from a D/S perspective and what the real-world use cases are.
-  Example: "Customers need to migrate VMs without network downtime to maintain SLA compliance during node maintenance." -->
   - *Describe the feature's value to customers:* Customers need to perform storage migration for offline VMs without requiring them to be running, providing flexibility in storage management operations.
   - *List the customer use cases identified:* Storage migration for mixed offline VMs and running VMs in one migration plan, allowing batch migration operations regardless of VM state.
 
 - [x] **Testability**
-  <!-- Confirmed requirements are **testable and unambiguous**. -->
   - *Note any requirements that are unclear or untestable:* Requirements are testable. Downstream build with the feature code is available for testing.
 
 - [x] **Acceptance Criteria**
-  <!-- Acceptance criteria are the specific, verifiable conditions that must be met for the feature to be considered complete — they define *how we know it works*.
-  Example: "VM migrates without network downtime exceeding 500ms", "VM deletion is blocked for non-admin users." -->
   - *List the acceptance criteria:*
     - Storage migration completes successfully for offline VMs between ODF and HPP storage classes
     - Storage migration completes successfully for mixed offline VMs and running VMs
@@ -60,7 +49,6 @@ technology, and testability before formal test planning.
   - *Note any gaps or missing criteria:* N/A
 
 - [x] **Non-Functional Requirements (NFRs)**
-  <!-- Confirmed coverage for NFRs, including Performance, Security, Usability, Downtime, Connectivity, Monitoring (alerts/metrics), Scalability, Portability (e.g., cloud support), and Docs.-->
   - *List applicable NFRs and their targets:* Documentation updates to reflect offline VM storage migration support and UI support for offline VM migrations.
   - *Note any NFRs not covered and why:* Performance, Monitoring, Observability, Security and Scalability testing are not included in this test plan
 
@@ -69,48 +57,25 @@ technology, and testability before formal test planning.
 The limitations are documented to ensure alignment between development, QA, and product teams.
 The following topics will not be tested or supported.
 
-<!-- Document any known limitations, constraints, or trade-offs in the feature implementation or testing approach.
-
-**Examples:**
-Feature related:
-- The feature is only supports YYY storage class
-- Feature does not support IPv6 (only IPv4)
-- No support for ARM64 architecture in this release
-- The feature is incompatible with ZZZ feature
-
-Tests related:
-- CPU xxx will not be tested due to lack of hardware
-- Integration with [Third-Party Service] is excluded; all external calls will be mocked using static data-->
-
 None - reviewed and confirmed with Yan Du on Apr 7,2026.
 
 #### **3. Technology and Design Review**
 
-<!-- **How to complete this checklist:**
-1. **Checkbox**: Mark [x] if done
-2. Complete the relevant, needed details for the checklist item -->
-
 - [x] **Developer Handoff/QE Kickoff**
-  <!-- A meeting where Dev/Arch walked QE through the design, architecture, and implementation details. **Critical for identifying untestable aspects early.**-->
   - *Key takeaways and concerns:* Extend the offline VMs storage migration support
 
 - [x] **Technology Challenges**
-  <!-- Identified potential testing challenges related to the underlying technology.-->
   - *List identified challenges:* Offline migration uses a different mechanism than online migration, requiring separate test coverage
   - *Impact on testing approach:* Test cases must verify both offline VM migration mixed scenarios with both offline and running VMs in the same migration plan.
 
 - [x] **API Extensions**
-  <!-- Review new or modified APIs and their impact on testing. Covers both new tests for new APIs and updates to existing tests for modified APIs.
-  Example: "New VirtualMachineSnapshot API v1beta2 — 3 new endpoints, 1 modified endpoint. Existing snapshot tests need updating." -->
   - *List new or modified APIs:* No new APIs - extends existing migration plan API to handle offline VMs
   - *Testing impact:* No API test updates required; functional tests will verify new behavior
 
 - [x] **Test Environment Needs**
-  <!-- Identified whether special environment setups are needed beyond standard infrastructure.-->
   - *See environment requirements in Section II.3 and testing tools in Section II.3.1*
 
 - [x] **Topology Considerations**
-  <!-- Evaluated multi-cluster, network topology, and architectural impacts.-->
   - *Describe topology requirements:* Standard 3-master/3-worker cluster sufficient
   - *Impact on test design:* No special topology requirements
 
@@ -120,52 +85,8 @@ This STP serves as the **overall roadmap for testing**, detailing the scope, app
 
 #### **1. Scope of Testing**
 
-<!-- Briefly describe what will be tested. The scope must **cover functional and non-functional requirements**.
-Must ensure user stories are included and aligned to downstream user stories from Section I. -->
-
 **Testing Goals**
 
-<!-- Testing goals are specific, measurable objectives — they say *what* must be verified and *how* success is measured.
-
-Define specific, measurable testing objectives for this feature using **SMART criteria**
-(Specific, Measurable, Achievable, Relevant, Time-bound).
-Each goal should tie back to requirements from Section I and be independently verifiable.
-
-**How to Define Good Testing Goals:**
-- **Specific**: Clearly state what will be tested (not "test the feature" but "validate VM live migration
-  with SR-IOV networks")
-- **Measurable**: Define quantifiable success criteria (e.g., "95% of VM migrations complete within xxx seconds")
-- **Achievable**: Realistic given resources and timeline
-- **Relevant**: Directly supports feature acceptance criteria and user stories
-- **Verifiable**: Can be objectively confirmed as complete
-
-**Priority Levels:**
-- **P0**: Blocking GA - must be complete before release
-- **P1**: High priority - required for full feature coverage
-- **P2**: Nice-to-have - can be deferred if timeline constraints exist -->
-
-<!-- **Example - Functional Goals**:
-- **[P0]** Verify VM live migration completes successfully with new network binding plugin across
-  OVN-Kubernetes and secondary networks
-- **[P1]** Validate hotplug/hotunplug operations work with new storage class without VM restart
-- **[P0]** Confirm RBAC permissions model correctly restricts non-admin users from accessing
-  cluster-wide configuration API
-- **[P2]** Validate new metrics with real-time VM performance data (CPU, memory, network, disk I/O)
-
-**Example - Quality Goals**:
-- **[P0]** Verify VM live migration completes in <30 seconds for VMs with <8GB memory
-  (performance baseline from VEP-XXXX)
-- **[P1]** Confirm feature operates correctly in disconnected/air-gapped environments with local
-  image registry
-- **[P0]** Validate zero data loss during live migration under network latency up to 100ms
-
-**Example - Integration Goals**:
-- **[P0]** Verify backward compatibility: upgrade from OCP 4.19 to 4.20 preserves existing VM
-  configurations without manual intervention
-- **[P0]** Confirm interoperability with OpenShift Service Mesh when VMs use Istio sidecar injection
-- **[P1]** Test integration with OpenShift monitoring stack: metrics appear in Prometheus,
-  alerts fire correctly in Alertmanager -->
-
 - **[P0]** Verify offline VM storage migration completes between ODF and HPP storage classes, and the VM boots successfully after migration
 - **[P0]** Verify storage migration completes for a migration plan containing both offline and running VMs
 - **[P0]** Verify source volumes are retained or deleted according to retentionPolicy configuration when offline VM storage migration completes
@@ -176,7 +97,7 @@ Each goal should tie back to requirements from Section I and be independently ve
 **Storage Class Coverage**
 
 The following storage class migration combinations will be tested:
-- **ODF (ocs-storagecluster-ceph-rbd-virtualization) ↔ HPP (hostpath-provisioner)
+- **ODF** (ocs-storagecluster-ceph-rbd-virtualization) ↔ **HPP** (hostpath-provisioner)
 - **ODF ↔ ODF** — Same storage class migration
 - **HPP ↔ HPP** — Same storage class migration
 
@@ -188,35 +109,16 @@ Storage classes **not covered** in this test plan:
 The following items are explicitly Out of Scope for this test cycle and represent intentional exclusions.
 No verification activities will be performed for these items, and any related issues found will not be classified as defects for this release.
 
-<!-- Explicitly document what is **out of scope** for testing.
-This section define the test boundaries; for example: test coverage by other teams, edge cases, low priority, etc.
-**Critical:** All out-of-scope items require explicit stakeholder agreement to prevent "I assumed you were testing
-that" issues; each out-of-scope item must have PM/Lead sign-off.
-
-- Items without stakeholder agreement are considered **risks** and must be escalated
-- Review the items during Developer Handoff/QE Kickoff meeting
-
-**Note:** Replace examples with your actual out-of-scope items. If there are no items; delete the checklist and add `None`-->
-
 None
 
 #### **2. Test Strategy**
 
-<!-- The following test strategy considerations must be reviewed and addressed. Mark [x] if applicable,
-leave unchecked if not applicable (with justification in Details). Unchecked items without details
-indicate incomplete review.
-
-Note: Strategy defines *which types of testing* apply and the high-level approach. Goals (Section II.1) define the specific, measurable objectives.
-Example: Strategy says "Performance testing is applicable — we will measure migration stuntime." Goals say "[P0] Verify VM stuntime during live migration is below 500ms." -->
-
 **Functional**
 
 - [x] **Functional Testing** — Validates that the feature works according to specified requirements and user stories
-  <!-- Mark if this feature requires functional testing. Functional testing validates that the feature works as specified — as opposed to non-functional testing (performance, security, scale, etc.) which validates how well it works. -->
   - *Details:* Functional testing will verify offline VM storage migration and mixed offline/online VM migration scenarios
 
 - [x] **Automation Testing** — Confirms test automation plan is in place for CI and regression coverage (all tests are expected to be automated)
-  <!-- Example: "All Tier 2 tests automated by sprint 3, integrated into nightly CI lane." -->
   - *Details:* All test cases will be automated
 
 - [x] **Regression Testing** — Verifies that new changes do not break existing functionality
@@ -252,11 +154,9 @@ Example: Strategy says "Performance testing is applicable — we will measure mi
   - *Details:* Not applicable
 
 - [ ] **Dependencies** — Blocked by deliverables from other components/products. Identify what we need from other teams before we can test.
-  <!-- Example: "Blocked on Storage team delivering CSI driver v2.0 — cannot test snapshot feature without it." -->
   - *Details:* No blocking dependencies
 
 - [x] **Cross Integrations** — Does the feature affect other features or require testing by other teams? Identify the impact we cause.
-  <!-- Example: "Our API change affects the UI team's VM details page — they need to update their tests." -->
   - *Details:* UI team needs to update their migration UI to support offline VM selection
 
 **Infrastructure**
@@ -266,51 +166,33 @@ Example: Strategy says "Performance testing is applicable — we will measure mi
 
 #### **3. Test Environment**
 
-<!-- **Note:** "N/A" means explicitly not applicable. All items must be filled or marked N/A. -->
-
 - **Cluster Topology:** 3-master/3-worker bare-metal
-  <!-- Change if different, e.g., SNO, Compact Cluster, HCP -->
 
 - **OCP & OpenShift Virtualization Version(s):** OCP 4.22 with OpenShift Virtualization 4.22
-  <!-- Specify exact versions to allow version traceability -->
 
 - **CPU Virtualization:** VT-x (Intel) or AMD-V enabled
-  <!-- Change only if specific CPU requirements exist -->
 
 - **Compute Resources:** Minimum per worker node: 8 vCPUs, 32GB RAM
-  <!-- Adjust based on feature requirements -->
 
 - **Special Hardware:** N/A
-  <!-- Fill if needed, e.g., SR-IOV NICs, GPUs -->
 
 - **Storage:** ocs-storagecluster-ceph-rbd-virtualization, hostpath-provisioner
-  <!-- Change if specific StorageClass(es) required -->
 
 - **Network:** OVN-Kubernetes, IPv4
-  <!-- Change if needed, e.g., Secondary Networks, IPv6, dual-stack -->
 
 - **Required Operators:** N/A
-  <!-- Add if needed, e.g., NMState Operator -->
 
 - **Platform:** PSI
-  <!-- Change if needed, e.g., AWS, Azure, GCP -->
 
 - **Special Configurations:** N/A
-  <!-- Change if needed, e.g., Disconnected/air-gapped, Proxy, FIPS mode -->
 
 #### **3.1. Testing Tools & Frameworks**
 
-<!-- Document any **new or additional** testing tools, frameworks, or infrastructure required specifically
-for this feature. **Note:** Only list tools that are **new** or **different** from standard testing infrastructure. -->
-
 - **Test Framework:** Standard
-  <!-- Change if needed, e.g., new framework, custom test harness, significant changes in tests infrastructure code etc  -->
 
 - **CI/CD:** N/A
-  <!-- Change if needed, e.g., special test lane, custom pipeline config -->
 
 - **Other Tools:** N/A
-  <!-- Fill if needed, e.g., special monitoring, performance tools -->
 
 #### **4. Entry Criteria**
 
@@ -330,9 +212,6 @@ The following conditions must be met before testing can begin:
 
 #### **6. Risks**
 
-<!-- Document specific risks for this feature. If a risk category is not applicable, mark as "N/A" with
-justification in mitigation strategy. -->
-
 **Timeline/Schedule**
 
 - **Risk:** N/A
@@ -373,7 +252,6 @@ justification in mitigation strategy. -->
 
 - **Risk:** N/A
   - **Mitigation:** No additional risks identified
-  <!-- If more context is needed for this item, add an entry with any relevant details-->
 
 > **Risks Review Sign-off:** All risk categories reviewed and confirmed N/A or addressed above — Yan Du, Apr 7,2026
 
@@ -381,20 +259,6 @@ justification in mitigation strategy. -->
 
 ### **III. Test Scenarios & Traceability**
 
-<!-- This section links D/S requirements to test coverage, enabling reviewers to verify all requirements are tested.
-
-**What goes here:** New test scenarios specific to this feature. Each scenario should trace to a D/S Jira requirement.
-**Granularity:** If one scenario can fail while another passes, they should be separate items. For example:
-- Different conditions (VMs with feature X vs without) → separate scenarios
-- Feature Gate enable/disable → separate scenarios (different expected behavior)
-- Multiple alerts → separate if different trigger conditions, group if same flow
-**What does NOT go here:** Regression tests (covered in Test Strategy). -->
-
-<!-- **Requirement ID:**
-- Use Jira issue key (e.g., CNV-12345)
-
-**Requirement Summary:** Brief description from the Jira issue (user story format preferred) -->
-
 - **[CNV-73500]** — As a VM owner, I want to migrate storage for offline VMs between ODF and HPP
   - *Test Scenario:* [Tier 2] Verify storage migration completes for offline VMs between ODF and HPP, and the VM boots successfully after migration
   - *Priority:* P0

From 8b0fac4b2caf01cb5e80aa3dc36203e3d2fefd61 Mon Sep 17 00:00:00 2001
From: Jose Manuel Castano <joscasta@redhat.com>
Date: Wed, 22 Apr 2026 11:06:13 +0200
Subject: [PATCH 06/13] Change Storage class in documentation after PR's review

Signed-off-by: Jose Manuel Castano <joscasta@redhat.com>
---
 stps/sig-storage/storage_mig_offline.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/stps/sig-storage/storage_mig_offline.md b/stps/sig-storage/storage_mig_offline.md
index 254295ae..5beec74a 100644
--- a/stps/sig-storage/storage_mig_offline.md
+++ b/stps/sig-storage/storage_mig_offline.md
@@ -97,7 +97,7 @@ This STP serves as the **overall roadmap for testing**, detailing the scope, app
 **Storage Class Coverage**
 
 The following storage class migration combinations will be tested:
-- **ODF** (ocs-storagecluster-ceph-rbd-virtualization) ↔ **HPP** (hostpath-provisioner)
+- **ODF** (ocs-storagecluster-ceph-rbd-virtualization) ↔ **HPP** (hostpath-csi-pvc-block)
 - **ODF ↔ ODF** — Same storage class migration
 - **HPP ↔ HPP** — Same storage class migration
 
@@ -176,7 +176,7 @@ None
 
 - **Special Hardware:** N/A
 
-- **Storage:** ocs-storagecluster-ceph-rbd-virtualization, hostpath-provisioner
+- **Storage:** ocs-storagecluster-ceph-rbd-virtualization, hostpath-csi-pvc-block
 
 - **Network:** OVN-Kubernetes, IPv4
 

From 6f2df3a2606d73fc8ca879bcd5c6cb70808fdb9d Mon Sep 17 00:00:00 2001
From: Jose Manuel Castano <joscasta@redhat.com>
Date: Wed, 29 Apr 2026 09:13:51 +0200
Subject: [PATCH 07/13] Address CodeRabbit review comments for offline storage
 migration STP

- Add feature maturity section (TP: v4.22, GA: v5.0)
- Convert customer use cases and acceptance criteria to user story format with measurable outcomes
- Expand review requirements with detailed D/S requirements list
- Add specific justifications for each NFR not covered
- Move storage class exclusions to Out of Scope section with PM sign-off
- Remove Exit Criteria section per updated template
- Update Risks section to PR #65 format with individual sign-offs

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Signed-off-by: Jose Manuel Castano <joscasta@redhat.com>
---
 stps/sig-storage/storage_mig_offline.md | 106 +++++++++++++++---------
 1 file changed, 67 insertions(+), 39 deletions(-)

diff --git a/stps/sig-storage/storage_mig_offline.md b/stps/sig-storage/storage_mig_offline.md
index 5beec74a..1e2a31a0 100644
--- a/stps/sig-storage/storage_mig_offline.md
+++ b/stps/sig-storage/storage_mig_offline.md
@@ -4,12 +4,15 @@
 
 ### **Metadata & Tracking**
 
-- **Enhancement(s):** https://github.com/kubevirt/kubevirt-migration-controller/pull/32
+- **Enhancement(s):** [CNV-77501](https://redhat.atlassian.net/browse/CNV-77501) - no VEP exists for this feature
 - **Feature Tracking:** [CNV-73509](https://redhat.atlassian.net/browse/CNV-73509)
 - **Epic Tracking:** [CNV-73500](https://redhat.atlassian.net/browse/CNV-73500)
 - **QE Owner(s):** Jose Manuel Castano (joscasta@redhat.com)
 - **Owning SIG:** sig-storage
 - **Participating SIGs:** sig-storage
+- **Feature Maturity:**
+  - TP: v4.22
+  - GA: v5.0
 
 **Document Conventions:**
 None
@@ -28,36 +31,66 @@ technology, and testability before formal test planning.
 #### **1. Requirement & User Story Review Checklist**
 
 - [x] **Review Requirements**
-  - *List the key D/S requirements reviewed:* Reviewed the user cases for offline VM storage migration from CNV-82430 and CNV-73500
+  - *List the key D/S requirements reviewed:*
+    - Support storage migration for offline (stopped) VMs between different storage classes
+    - Support mixed migration plans containing both offline and running VMs
+    - Support offline VM storage migration with hotplug disks attached
+    - Support retentionPolicy configuration for source volume cleanup after offline VM migration
+    - Ensure offline VMs remain pointing to original volumes when migration fails
+    - Support VM start operations during ongoing storage migration without conflicts
+    - Reviewed user cases for offline VM storage migration from CNV-82430 and CNV-73500
 
 - [x] **Understand Value and Customer Use Cases**
   - *Describe the feature's value to customers:* Customers need to perform storage migration for offline VMs without requiring them to be running, providing flexibility in storage management operations.
-  - *List the customer use cases identified:* Storage migration for mixed offline VMs and running VMs in one migration plan, allowing batch migration operations regardless of VM state.
+  - *List the customer use cases identified:*
+    - As a VM owner, I want to migrate storage for offline VMs, so that I can perform storage management operations without having to start the VMs
+    - As a VM owner, I want to migrate storage with mixed VM states (online and offline) in one migration plan, so that I can perform batch migration operations regardless of VM state
 
 - [x] **Testability**
   - *Note any requirements that are unclear or untestable:* Requirements are testable. Downstream build with the feature code is available for testing.
 
 - [x] **Acceptance Criteria**
   - *List the acceptance criteria:*
-    - Storage migration completes successfully for offline VMs between ODF and HPP storage classes
-    - Storage migration completes successfully for mixed offline VMs and running VMs
-    - Storage migration completes successfully for offline VMs with hotplug disk
-    - Source volume could be retained/cleaned up for an offline VM migration completed with retentionPolicy defined
-    - Offline VM points to the origin volume when migration failed
-    - Migration succeeded when starting a stopped VM during migration
+    - As a VM owner, I want to migrate storage for offline VMs between ODF and HPP storage classes, so that:
+      - Migration plan status reports "Succeeded"
+      - Offline VM disk references point to the new target storage class
+      - VM boots successfully after migration using the migrated storage
+    - As a VM owner, I want to migrate storage with mixed offline VMs and running VMs in one migration plan, so that:
+      - Migration plan status reports "Succeeded"
+      - All offline VMs point to target storage class
+      - All running VMs point to target storage class and remain running
+    - As a VM owner, I want to migrate storage for offline VMs with hotplug disk, so that:
+      - Migration plan status reports "Succeeded"
+      - All disks including hotplug disks are migrated to target storage class
+      - VM boots successfully with all disks accessible
+    - As a VM owner, I want to retain or delete the source volume for an offline VM, so that:
+      - When retentionPolicy=retain: source volumes exist after migration completes
+      - When retentionPolicy=delete: source volumes are deleted after migration completes
+    - As a VM owner, I want an offline VM to point to the original volume when migration fails, so that:
+      - Migration plan status reports "Failed"
+      - VM disk references remain unchanged and point to original storage
+    - As a VM owner, I want migration to succeed when starting a stopped VM during migration, so that:
+      - Migration plan status reports "Succeeded"
+      - VM starts successfully during the migration process
+      - VM points to target storage after migration completes
 
   - *Note any gaps or missing criteria:* N/A
 
 - [x] **Non-Functional Requirements (NFRs)**
   - *List applicable NFRs and their targets:* Documentation updates to reflect offline VM storage migration support and UI support for offline VM migrations.
-  - *Note any NFRs not covered and why:* Performance, Monitoring, Observability, Security and Scalability testing are not included in this test plan
+  - *Note any NFRs not covered and why:*
+    - **Performance:** Not covered - Performance testing for bulk offline migrations is tracked separately and will be addressed by a dedicated test plan
+    - **Monitoring:** Not applicable - Feature does not introduce new metrics or alerts; existing migration monitoring applies
+    - **Observability:** Not applicable - Feature reuses existing migration observability patterns without new requirements
+    - **Security:** Not applicable - Feature does not introduce new security boundaries or authentication/authorization requirements; leverages existing migration RBAC
+    - **Scalability:** Not applicable - Scalability characteristics inherit from existing migration infrastructure; no new scalability requirements introduced
 
 #### **2. Known Limitations**
 
 The limitations are documented to ensure alignment between development, QA, and product teams.
 The following topics will not be tested or supported.
 
-None - reviewed and confirmed with Yan Du on Apr 7,2026.
+None - reviewed and confirmed with Jose Manuel Castano on Apr 28,2026.
 
 #### **3. Technology and Design Review**
 
@@ -101,15 +134,14 @@ The following storage class migration combinations will be tested:
 - **ODF ↔ ODF** — Same storage class migration
 - **HPP ↔ HPP** — Same storage class migration
 
-Storage classes **not covered** in this test plan:
-- Cloud provider-specific storage classes (AWS EBS, Azure Disk, GCP PD) — Out of scope for initial release
-
 **Out of Scope (Testing Scope Exclusions)**
 
 The following items are explicitly Out of Scope for this test cycle and represent intentional exclusions.
 No verification activities will be performed for these items, and any related issues found will not be classified as defects for this release.
 
-None
+- **Storage Classes:** Cloud provider-specific storage classes (AWS EBS, Azure Disk, GCP PD) are out of scope for initial release
+
+> **PM Sign-off:** [Name], [Date]
 
 #### **2. Test Strategy**
 
@@ -201,59 +233,55 @@ The following conditions must be met before testing can begin:
 - [x] Requirements and design documents are **approved and merged**
 - [x] Test environment can be **set up and configured** (see Section II.3 - Test Environment)
 
-#### **5. Exit Criteria**
-
-- [ ] All high-priority defects are resolved and verified
-- [ ] Test coverage goals achieved
-- [ ] Test automation merged (required for GA sign-off)
-- [ ] All planned test cycles completed
-- [ ] Test summary report approved
-- [ ] Acceptance criteria met
-
-#### **6. Risks**
+#### **5. Risks**
 
 **Timeline/Schedule**
 
-- **Risk:** N/A
-  - **Mitigation:** N/A
+- **Risk:** No scheduling or deadline risks identified
+  - **Mitigation:** Standard test timeline is sufficient for planned test scenarios
   - *Estimated impact on schedule:* None
+  - *Sign-off:* Jose Manuel Castano, Apr 28, 2026
 
 **Test Coverage**
 
-- **Risk:** N/A
+- **Risk:** No gaps in test coverage identified
   - **Mitigation:** All acceptance criteria are covered by planned test scenarios
   - *Areas with reduced coverage:* None
+  - *Sign-off:* Jose Manuel Castano, Apr 28, 2026
 
 **Test Environment**
 
-- **Risk:** N/A
+- **Risk:** No hardware, software, or infrastructure constraints identified
   - **Mitigation:** Standard test environment is sufficient for testing this feature
   - *Missing resources or infrastructure:* None
+  - *Sign-off:* Jose Manuel Castano, Apr 28, 2026
 
 **Untestable Aspects**
 
-- **Risk:** N/A
-  - **Mitigation:** N/A
+- **Risk:** No untestable scenarios identified
+  - **Mitigation:** All scenarios can be reproduced in test environment
   - *Alternative validation approach:* N/A
+  - *Sign-off:* Jose Manuel Castano, Apr 28, 2026
 
 **Resource Constraints**
 
-- **Risk:** N/A
-  - **Mitigation:** N/A
+- **Risk:** No staffing, skill, or capacity limitations identified
+  - **Mitigation:** Current QE team capacity is sufficient for planned test execution
   - *Current capacity gaps:* None
+  - *Sign-off:* Jose Manuel Castano, Apr 28, 2026
 
 **Dependencies**
 
-- **Risk:** N/A
-  - **Mitigation:** No external dependencies
+- **Risk:** No blocking external dependencies identified
+  - **Mitigation:** UI team updates for offline VM selection are non-blocking; API testing can proceed independently
   - *Dependent teams or components:* UI team for UI updates (non-blocking)
+  - *Sign-off:* Jose Manuel Castano, Apr 28, 2026
 
 **Other**
 
-- **Risk:** N/A
-  - **Mitigation:** No additional risks identified
-
-> **Risks Review Sign-off:** All risk categories reviewed and confirmed N/A or addressed above — Yan Du, Apr 7,2026
+- **Risk:** No additional risks identified
+  - **Mitigation:** No additional mitigation required
+  - *Sign-off:* Jose Manuel Castano, Apr 28, 2026
 
 ---
 

From 0aa9a5f3b4e935f04bc02e7fcfaff7df9929f82c Mon Sep 17 00:00:00 2001
From: Jose Manuel Castano <joscasta@redhat.com>
Date: Wed, 29 Apr 2026 11:12:12 +0200
Subject: [PATCH 08/13] Updated Test Environment Platform into stp

Signed-off-by: Jose Manuel Castano <joscasta@redhat.com>
---
 stps/sig-storage/storage_mig_offline.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/stps/sig-storage/storage_mig_offline.md b/stps/sig-storage/storage_mig_offline.md
index 1e2a31a0..54f3e32d 100644
--- a/stps/sig-storage/storage_mig_offline.md
+++ b/stps/sig-storage/storage_mig_offline.md
@@ -198,7 +198,7 @@ No verification activities will be performed for these items, and any related is
 
 #### **3. Test Environment**
 
-- **Cluster Topology:** 3-master/3-worker bare-metal
+- **Cluster Topology:** 3-master/3-worker Bare-Metal
 
 - **OCP & OpenShift Virtualization Version(s):** OCP 4.22 with OpenShift Virtualization 4.22
 
@@ -214,7 +214,7 @@ No verification activities will be performed for these items, and any related is
 
 - **Required Operators:** N/A
 
-- **Platform:** PSI
+- **Platform:** Bare Metal
 
 - **Special Configurations:** N/A
 

From 73f75392a7735ee33ea63a58a2d407f16d10a22a Mon Sep 17 00:00:00 2001
From: Jose Manuel Castano <joscasta@redhat.com>
Date: Wed, 29 Apr 2026 11:39:13 +0200
Subject: [PATCH 09/13] Enhance Test Strategy documentation in offline storage
 migration STP

- Document Upgrade Testing evaluation: confirmed this is an additive feature requiring no upgrade testing
- Document Monitoring evaluation: no new metrics/alerts needed, reuses existing migration monitoring
- Document Scale Testing evaluation: inherits scalability from existing migration infrastructure
- Document Security Testing evaluation: no new security boundaries, leverages existing RBAC
- Document Cloud Testing evaluation: cloud storage classes explicitly out of scope
- Add DP: N/A to Feature Maturity metadata
- Align all Test Strategy details with NFRs section
- Address CodeRabbit HIGH severity review comment on mandatory documentation requirements

All N/A test types now include explicit justifications as required by AGENTS.md guidelines.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Signed-off-by: Jose Manuel Castano <joscasta@redhat.com>
---
 stps/sig-storage/storage_mig_offline.md | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/stps/sig-storage/storage_mig_offline.md b/stps/sig-storage/storage_mig_offline.md
index 54f3e32d..d217d27c 100644
--- a/stps/sig-storage/storage_mig_offline.md
+++ b/stps/sig-storage/storage_mig_offline.md
@@ -11,6 +11,7 @@
 - **Owning SIG:** sig-storage
 - **Participating SIGs:** sig-storage
 - **Feature Maturity:**
+  - DP: N/A
   - TP: v4.22
   - GA: v5.0
 
@@ -162,10 +163,10 @@ No verification activities will be performed for these items, and any related is
   - *Details:* Performance testing for bulk offline migrations is tracked separately in CNV-82430 and will be covered by a separate test plan
 
 - [ ] **Scale Testing** — Validates feature behavior under increased load and at production-like scale (e.g., large number of VMs, nodes, or concurrent operations)
-  - *Details:* Not applicable
+  - *Details:* N/A. Scalability characteristics inherit from existing migration infrastructure; no new scalability requirements introduced by adding offline VM support.
 
 - [ ] **Security Testing** — Verifies security requirements, RBAC, authentication, authorization, and vulnerability scanning
-  - *Details:* Not applicable
+  - *Details:* N/A. Feature does not introduce new security boundaries or authentication/authorization requirements; leverages existing migration RBAC model.
 
 - [x] **Usability Testing** — Validates user experience and accessibility requirements
   - Does the feature require a UI? If so, ensure the UI aligns with the requirements (UI/UX consistency, accessibility)
@@ -174,7 +175,7 @@ No verification activities will be performed for these items, and any related is
   - *Details:* UI testing will be covered in https://redhat.atlassian.net/browse/CNV-77503
 
 - [ ] **Monitoring** — Does the feature require metrics and/or alerts?
-  - *Details:* Not applicable
+  - *Details:* N/A. No new metrics or alerts are required. Feature does not introduce new metrics or alerts; existing migration monitoring applies to both online and offline VM migrations.
 
 **Integration & Compatibility**
 
@@ -183,7 +184,7 @@ No verification activities will be performed for these items, and any related is
   - *Details:* Feature maintains backward compatibility with existing migration API. Existing online VM migrations continue to work unchanged.
 
 - [ ] **Upgrade Testing** — Validates upgrade paths from previous versions, data migration, and configuration preservation
-  - *Details:* Not applicable
+  - *Details:* Upgrade path was evaluated. No dedicated upgrade testing is required because this is a new additive feature (offline VM storage migration support) that does not modify existing migration behavior or introduce configuration changes requiring migration. Existing online VM migration functionality remains unchanged and backward compatible (see Compatibility Testing). Users upgrading to v4.22+ will gain offline migration capability without requiring any configuration updates or data migration.
 
 - [ ] **Dependencies** — Blocked by deliverables from other components/products. Identify what we need from other teams before we can test.
   - *Details:* No blocking dependencies
@@ -194,7 +195,7 @@ No verification activities will be performed for these items, and any related is
 **Infrastructure**
 
 - [ ] **Cloud Testing** — Does the feature require multi-cloud platform testing? Consider cloud-specific features.
-  - *Details:* Not applicable
+  - *Details:* N/A. Cloud provider-specific storage classes (AWS EBS, Azure Disk, GCP PD) are explicitly out of scope for initial release (see Section II.1 - Out of Scope). Testing focuses on Bare Metal with ODF and HPP storage classes.
 
 #### **3. Test Environment**
 

From d387a06c09e9412602fcd5066c8355b9b63b5f79 Mon Sep 17 00:00:00 2001
From: Jose Manuel Castano <joscasta@redhat.com>
Date: Wed, 6 May 2026 10:17:35 +0200
Subject: [PATCH 10/13] Update offline storage migration STP based on PR review
 feedback

- Add support for all volume mode combinations (File-to-Block, Block-to-File,
  File-to-File, Block-to-Block) since CDI copy clone handles the transfer
- Clarify VM start behavior during migration: VM waits for migration completion
  before becoming ready as volumes are switched to target (pending) state
- Add cloud storage classes (AWS EBS, Azure Disk, GCP PD) to supported storage
- Remove cloud storage exclusion from out-of-scope section
- Add Volume Mode Coverage section with all supported combinations
- Update test environment to include cloud platforms (AWS, Azure, GCP)
- Enable Cloud Testing requirement in test strategy

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Signed-off-by: Jose Manuel Castano <joscasta@redhat.com>
---
 stps/sig-storage/storage_mig_offline.md | 49 +++++++++++++++++--------
 1 file changed, 34 insertions(+), 15 deletions(-)

diff --git a/stps/sig-storage/storage_mig_offline.md b/stps/sig-storage/storage_mig_offline.md
index d217d27c..989df567 100644
--- a/stps/sig-storage/storage_mig_offline.md
+++ b/stps/sig-storage/storage_mig_offline.md
@@ -38,7 +38,8 @@ technology, and testability before formal test planning.
     - Support offline VM storage migration with hotplug disks attached
     - Support retentionPolicy configuration for source volume cleanup after offline VM migration
     - Ensure offline VMs remain pointing to original volumes when migration fails
-    - Support VM start operations during ongoing storage migration without conflicts
+    - Support VM start operations during ongoing storage migration where the VM waits for migration completion before starting (volumes are switched to new target volumes in pending state once migration begins)
+    - Support all volume mode combinations (File-to-Block, Block-to-File, File-to-File, Block-to-Block) given that CDI copy clone performs the underlying storage transfer
     - Reviewed user cases for offline VM storage migration from CNV-82430 and CNV-73500
 
 - [x] **Understand Value and Customer Use Cases**
@@ -72,8 +73,8 @@ technology, and testability before formal test planning.
       - VM disk references remain unchanged and point to original storage
     - As a VM owner, I want migration to succeed when starting a stopped VM during migration, so that:
       - Migration plan status reports "Succeeded"
-      - VM starts successfully during the migration process
-      - VM points to target storage after migration completes
+      - VM start operation waits for migration to complete before the VM becomes ready (volumes are switched to target storage in pending state)
+      - VM points to target storage and starts successfully after migration completes
 
   - *Note any gaps or missing criteria:* N/A
 
@@ -126,21 +127,35 @@ This STP serves as the **overall roadmap for testing**, detailing the scope, app
 - **[P0]** Verify source volumes are retained or deleted according to retentionPolicy configuration when offline VM storage migration completes
 - **[P1]** Verify offline VM storage migration completes when the VM has hotplug disks attached
 - **[P2]** Verify offline VM continues pointing to the original volume when storage migration fails
-- **[P2]** Verify storage migration completes when a stopped VM is started during the migration process
+- **[P2]** Verify storage migration completes when a stopped VM is started during the migration process and the VM waits for migration completion before becoming ready
 
 **Storage Class Coverage**
 
-The following storage class migration combinations will be tested:
-- **ODF** (ocs-storagecluster-ceph-rbd-virtualization) ↔ **HPP** (hostpath-csi-pvc-block)
-- **ODF ↔ ODF** — Same storage class migration
-- **HPP ↔ HPP** — Same storage class migration
+The following storage classes are supported for migration testing:
+- **ODF** (ocs-storagecluster-ceph-rbd-virtualization)
+- **HPP** (hostpath-csi-pvc-block)
+- **AWS EBS** (gp3-csi)
+- **Azure Disk** (managed-csi)
+- **GCP PD** (pd-ssd-csi)
+
+Migration combinations will be tested including:
+- Cross-storage class migrations (e.g., ODF ↔ HPP, ODF ↔ AWS EBS)
+- Same-storage class migrations (e.g., ODF ↔ ODF, HPP ↔ HPP)
+
+**Volume Mode Coverage**
+
+All volume mode combinations are supported and will be tested:
+- **Block ↔ Block** — Block to Block migration
+- **File ↔ File** — Filesystem to Filesystem migration
+- **Block ↔ File** — Block to Filesystem migration
+- **File ↔ Block** — Filesystem to Block migration
 
 **Out of Scope (Testing Scope Exclusions)**
 
 The following items are explicitly Out of Scope for this test cycle and represent intentional exclusions.
 No verification activities will be performed for these items, and any related issues found will not be classified as defects for this release.
 
-- **Storage Classes:** Cloud provider-specific storage classes (AWS EBS, Azure Disk, GCP PD) are out of scope for initial release
+None
 
 > **PM Sign-off:** [Name], [Date]
 
@@ -194,12 +209,12 @@ No verification activities will be performed for these items, and any related is
 
 **Infrastructure**
 
-- [ ] **Cloud Testing** — Does the feature require multi-cloud platform testing? Consider cloud-specific features.
-  - *Details:* N/A. Cloud provider-specific storage classes (AWS EBS, Azure Disk, GCP PD) are explicitly out of scope for initial release (see Section II.1 - Out of Scope). Testing focuses on Bare Metal with ODF and HPP storage classes.
+- [x] **Cloud Testing** — Does the feature require multi-cloud platform testing? Consider cloud-specific features.
+  - *Details:* Multi-cloud platform testing is required to validate storage migration across cloud provider storage classes (AWS EBS, Azure Disk, GCP PD). Since CDI copy clone performs the underlying storage transfer, the feature works across all platforms.
 
 #### **3. Test Environment**
 
-- **Cluster Topology:** 3-master/3-worker Bare-Metal
+- **Cluster Topology:** 3-master/3-worker
 
 - **OCP & OpenShift Virtualization Version(s):** OCP 4.22 with OpenShift Virtualization 4.22
 
@@ -209,13 +224,17 @@ No verification activities will be performed for these items, and any related is
 
 - **Special Hardware:** N/A
 
-- **Storage:** ocs-storagecluster-ceph-rbd-virtualization, hostpath-csi-pvc-block
+- **Storage:** 
+  - Bare Metal: ocs-storagecluster-ceph-rbd-virtualization, hostpath-csi-pvc-block
+  - AWS: gp3-csi
+  - Azure: managed-csi
+  - GCP: pd-ssd-csi
 
 - **Network:** OVN-Kubernetes, IPv4
 
 - **Required Operators:** N/A
 
-- **Platform:** Bare Metal
+- **Platform:** Bare Metal, AWS, Azure, GCP
 
 - **Special Configurations:** N/A
 
@@ -309,7 +328,7 @@ The following conditions must be met before testing can begin:
   - *Priority:* P2
 
 - **[CNV-73500]** — As a VM owner, I want the migration to succeed when starting a stopped VM during migration
-  - *Test Scenario:* [Tier 2] Verify migration succeeds when starting a stopped VM during the migration process
+  - *Test Scenario:* [Tier 2] Verify migration succeeds when starting a stopped VM during the migration process and the VM waits for migration completion before becoming ready
   - *Priority:* P2
 
 ---

From f3a87ef1b090b2474f729ccf0ccaad144ba80d59 Mon Sep 17 00:00:00 2001
From: "pre-commit-ci[bot]"
 <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Date: Wed, 6 May 2026 08:18:04 +0000
Subject: [PATCH 11/13] [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci
---
 stps/sig-storage/storage_mig_offline.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/stps/sig-storage/storage_mig_offline.md b/stps/sig-storage/storage_mig_offline.md
index 989df567..cecad4fb 100644
--- a/stps/sig-storage/storage_mig_offline.md
+++ b/stps/sig-storage/storage_mig_offline.md
@@ -224,7 +224,7 @@ None
 
 - **Special Hardware:** N/A
 
-- **Storage:** 
+- **Storage:**
   - Bare Metal: ocs-storagecluster-ceph-rbd-virtualization, hostpath-csi-pvc-block
   - AWS: gp3-csi
   - Azure: managed-csi

From 6dd9f3ed574cc77947169922d89c1d69de532873 Mon Sep 17 00:00:00 2001
From: Jose Manuel Castano <joscasta@redhat.com>
Date: Wed, 6 May 2026 16:13:18 +0200
Subject: [PATCH 12/13] Remove requirement not consider as a requirement.

Signed-off-by: Jose Manuel Castano <joscasta@redhat.com>
---
 stps/sig-storage/storage_mig_offline.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/stps/sig-storage/storage_mig_offline.md b/stps/sig-storage/storage_mig_offline.md
index cecad4fb..c03d8656 100644
--- a/stps/sig-storage/storage_mig_offline.md
+++ b/stps/sig-storage/storage_mig_offline.md
@@ -38,7 +38,6 @@ technology, and testability before formal test planning.
     - Support offline VM storage migration with hotplug disks attached
     - Support retentionPolicy configuration for source volume cleanup after offline VM migration
     - Ensure offline VMs remain pointing to original volumes when migration fails
-    - Support VM start operations during ongoing storage migration where the VM waits for migration completion before starting (volumes are switched to new target volumes in pending state once migration begins)
     - Support all volume mode combinations (File-to-Block, Block-to-File, File-to-File, Block-to-Block) given that CDI copy clone performs the underlying storage transfer
     - Reviewed user cases for offline VM storage migration from CNV-82430 and CNV-73500
 

From 44d63816ddbe0100cd56f575b91768f49e0f7209 Mon Sep 17 00:00:00 2001
From: Jose Manuel Castano <joscasta@redhat.com>
Date: Wed, 6 May 2026 16:24:18 +0200
Subject: [PATCH 13/13] Rephrase test case of start a VM during migration
 process

Signed-off-by: Jose Manuel Castano <joscasta@redhat.com>
---
 stps/sig-storage/storage_mig_offline.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/stps/sig-storage/storage_mig_offline.md b/stps/sig-storage/storage_mig_offline.md
index c03d8656..864b1b89 100644
--- a/stps/sig-storage/storage_mig_offline.md
+++ b/stps/sig-storage/storage_mig_offline.md
@@ -38,6 +38,7 @@ technology, and testability before formal test planning.
     - Support offline VM storage migration with hotplug disks attached
     - Support retentionPolicy configuration for source volume cleanup after offline VM migration
     - Ensure offline VMs remain pointing to original volumes when migration fails
+    - Support VM start operations during ongoing storage migration, the VM must start after migration completion (volumes are switched to new target volumes in pending state once migration begins)
     - Support all volume mode combinations (File-to-Block, Block-to-File, File-to-File, Block-to-Block) given that CDI copy clone performs the underlying storage transfer
     - Reviewed user cases for offline VM storage migration from CNV-82430 and CNV-73500
 
@@ -327,7 +328,7 @@ The following conditions must be met before testing can begin:
   - *Priority:* P2
 
 - **[CNV-73500]** — As a VM owner, I want the migration to succeed when starting a stopped VM during migration
-  - *Test Scenario:* [Tier 2] Verify migration succeeds when starting a stopped VM during the migration process and the VM waits for migration completion before becoming ready
+  - *Test Scenario:* [Tier 2] Verify migration succeeds when starting a VM during the migration process and the VM waits for migration completion before becoming ready
   - *Priority:* P2
 
 ---