CSTACKEX-262: Support for Compute + Volume migration and Volume migration by sandeeplocharla · Pull Request #112 · NetApp/cloudstack

sandeeplocharla · 2026-10-05T05:54:57Z

Description

This PR...

Types of changes

Breaking change (fix or feature that would cause existing functionality to change)
New feature (non-breaking change which adds functionality)
Bug fix (non-breaking change which fixes an issue)
Enhancement (improves an existing feature and functionality)
Cleanup (Code refactoring and cleanup, that may add test cases)
Build/CI
Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

Major
Minor

Bug Severity

Use case	Suite	Tests	Result
Live VM migration with volumes	migration_live	22	Pass
Stopped VM storage migration	migration_stopped	15	Pass
Volume migration (detached or stopped-attached)	migration_volume	23	Pass
iSCSI pool lifecycle	iscsi_pool_lifecycle	8	Pass
iSCSI pool with volumes	iscsi_pool_volumes	7	Pass
iSCSI zone-scoped pool	iscsi_zone_pool	4	Pass
iSCSI volume lifecycle	iscsi_volume	5	Pass
iSCSI VM volume attach	iscsi_instance	8	Pass
NFS3 pool lifecycle	nfs3_pool_lifecycle	8	Pass
NFS3 pool with volumes	nfs3_pool_volumes	7	Pass
NFS3 zone-scoped pool	nfs3_zone_pool	4	Pass
NFS3 volume lifecycle	nfs3_volume	5	Pass
NFS3 VM volume attach	nfs3_instance	8	Pass

Live VM with volumes (`migrateVirtualMachineWithVolume`)

Test	What it covers	Status
test_01_nfs3_default_primary_to_cluster	DefaultPrimary root and data volumes to NFS3 C1a	Pass
test_02_nfs3_cluster_to_cluster	NFS3 C1a to C1b	Pass
test_03_nfs3_cluster_to_zone	NFS3 C1b to zone-wide Z1	Pass
test_04_nfs3_zone_to_zone	NFS3 Z1 to Z2	Pass
test_05_nfs3_zone_to_cluster	NFS3 Z2 back to C1a	Pass
test_06_iscsi_default_primary_to_cluster	DefaultPrimary root and data volumes to iSCSI C1a	Pass
test_07_iscsi_cluster_to_cluster	iSCSI C1a to C1b	Pass
test_08_iscsi_cluster_to_zone	iSCSI C1b to Z1	Pass
test_09_iscsi_zone_to_zone	iSCSI Z1 to Z2	Pass
test_10_iscsi_zone_to_cluster	iSCSI Z2 back to C1a	Pass
test_11_reject_nfs3_to_iscsi	Live NFS3-to-iSCSI mapping is rejected	Pass
test_12_reject_iscsi_to_nfs3	Live iSCSI-to-NFS3 mapping is rejected	Pass
test_13_reject_live_volume_only	`migrateVolume` with livemigrate on a running volume is rejected	Pass
test_14_nfs3_cluster_to_cluster	After host split, NFS3 C1a to C2	Pass
test_15_nfs3_cluster_to_zone	NFS3 C1a to Z1 onto a C2 host	Pass
test_16_nfs3_zone_to_cluster	NFS3 Z1 to C2	Pass
test_17_nfs3_zone_to_zone	NFS3 Z1 to Z2 onto a C2 host	Pass
test_18_iscsi_cluster_to_cluster	iSCSI C1a to C2 onto a C2 host	Pass
test_19_iscsi_cluster_to_zone	iSCSI C1a to Z1 onto a C2 host	Pass
test_20_iscsi_zone_to_cluster	iSCSI Z1 to C2	Pass
test_21_iscsi_zone_to_zone	iSCSI Z1 to Z2 onto a C2 host	Pass
test_22_reject_pool_not_reachable_from_destination_host	Cluster-1 pool mapped to a cluster-2 host is rejected	Pass

Stopped VM storage migration (`migrateVirtualMachineWithVolume`, no destination host)

Test	What it covers	Status
test_01_nfs3_default_primary_to_cluster	DefaultPrimary to NFS3 C1a	Pass
test_02_nfs3_cluster_to_cluster_same_cluster	NFS3 between cluster pools in the same cluster	Pass
test_03_nfs3_cluster_to_cluster_across_clusters	NFS3 to a pool in the second cluster	Pass
test_04_nfs3_cluster_to_zone	NFS3 cluster pool to zone-wide	Pass
test_05_nfs3_zone_to_zone	NFS3 between two zone-wide pools	Pass
test_06_nfs3_zone_to_cluster	NFS3 zone-wide back to C1a	Pass
test_07_iscsi_default_primary_to_cluster	DefaultPrimary to iSCSI C1a	Pass
test_08_iscsi_cluster_to_cluster_same_cluster	iSCSI between cluster pools in the same cluster	Pass
test_09_iscsi_cluster_to_cluster_across_clusters	iSCSI to a pool in the second cluster	Pass
test_10_iscsi_cluster_to_zone	iSCSI cluster pool to zone-wide	Pass
test_11_iscsi_zone_to_zone	iSCSI between two zone-wide pools	Pass
test_12_iscsi_zone_to_cluster	iSCSI zone-wide back to C1a	Pass
test_13_reject_nfs3_to_iscsi	Stopped-VM NFS3-to-iSCSI is rejected	Pass
test_14_reject_iscsi_to_nfs3	Stopped-VM iSCSI-to-NFS3 is rejected	Pass
test_15_reject_running_vm	Stopped-VM API form is rejected once the VM is running	Pass

Volume migration (`migrateVolume`)

Test	What it covers	Status
test_01_nfs3_detached_default_primary_to_cluster	Detached NFS3, DefaultPrimary to C1a	Pass
test_02_nfs3_detached_cluster_to_cluster_same_cluster	Detached NFS3, C1a to C1b	Pass
test_03_nfs3_detached_cluster_to_cluster_across_clusters	Detached NFS3, C1b to C2	Pass
test_04_nfs3_detached_cluster_to_zone	Detached NFS3, C2 to Z1	Pass
test_05_nfs3_detached_zone_to_zone	Detached NFS3, Z1 to Z2	Pass
test_06_nfs3_detached_zone_to_cluster	Detached NFS3, Z2 back to C1a	Pass
test_07_iscsi_detached_default_primary_to_cluster	Detached iSCSI, DefaultPrimary to C1a	Pass
test_08_iscsi_detached_cluster_to_cluster_same_cluster	Detached iSCSI, C1a to C1b	Pass
test_09_iscsi_detached_cluster_to_cluster_across_clusters	Detached iSCSI, C1b to C2	Pass
test_10_iscsi_detached_cluster_to_zone	Detached iSCSI, C2 to Z1	Pass
test_11_iscsi_detached_zone_to_zone	Detached iSCSI, Z1 to Z2	Pass
test_12_iscsi_detached_zone_to_cluster	Detached iSCSI, Z2 back to C1a	Pass
test_13_nfs3_attached_stopped_vm_cluster_to_zone	Stopped-attached NFS3 data, C1a to Z1; root stays	Pass
test_14_iscsi_attached_stopped_vm_cluster_to_zone	Stopped-attached iSCSI data, C1a to Z1; root stays	Pass
test_15_nfs3_attached_stopped_vm_default_to_ontap	Stopped-attached non-ONTAP data to ONTAP NFS3	Pass
test_16_iscsi_attached_stopped_vm_default_to_ontap	Stopped-attached non-ONTAP data to ONTAP iSCSI	Pass
test_17_reject_detached_nfs3_to_iscsi	Detached NFS3-to-iSCSI is rejected	Pass
test_18_reject_detached_iscsi_to_nfs3	Detached iSCSI-to-NFS3 is rejected	Pass
test_19_reject_stopped_attached_nfs3_to_iscsi	Stopped-attached NFS3-to-iSCSI is rejected	Pass
test_20_reject_stopped_attached_iscsi_to_nfs3	Stopped-attached iSCSI-to-NFS3 is rejected	Pass
test_21_reject_attached_running_vm_without_livemigrate	Running-attached NFS3 without livemigrate is rejected	Pass
test_22_reject_attached_running_vm_with_livemigrate	Live volume-only migration is rejected	Pass
test_23_reject_same_pool	Migration to the volume's current pool is rejected	Pass

github-actions · 2026-10-06T15:52:50Z

🔴 Test Coverage Grade: `D` — Marginal

Metric	Value
Line coverage	24.86%
Branch coverage	18.99%

Grade Scale

Grade	Line Coverage	Meaning
🟢 A	≥ 80%	Excellent - this code sleeps well at night 😴
🟡 B	60-79%	Good - almost there, don't stop now 😉
🟠 C	40-59%	Acceptable - your code is wearing a seatbelt, but no airbags 😬
🔴 D	20-39%	Marginal - boldly shipping where no test has gone before 🖖
⛔ F	< 20%	Failing - tests? what tests? 🔥

Branch coverage is shown as a secondary signal. Grade is determined by line coverage.
View full Actions run

piyush5netapp · 2026-10-07T04:57:12Z

    public static final String VM_WORK_JOB_HANDLER = VirtualMachineManagerImpl.class.getSimpleName();

    private static final String VM_SYNC_ALERT_SUBJECT = "VM state sync alert";
+    private static final String ONTAP_SVM_NAME_DETAIL = "svmName";


why are these required in this file ? These are ONTAP specific .

For migration of a volume with VM (Live/Stopped), executeManagedStorageChecksWhenTargetStoragePoolProvided is executed and it rejects all 'managed' storages, unless the pool is of type 'PowerFlex'. Now, as we only have our own pool type for iSCSI but not for NFS, we would be needing explicit ontap relevant checks here.

But we can definitely discuss on the list of checks that we want to keep here. I've retained the same list as in the OntapDataMotionStrategy class with the intention to fail fast.

rajiv-jain-netapp · 2026-10-08T06:03:06Z

                volume.getUuid(), currentPool.getUuid(), targetPool.getUuid()));
    }

+    protected boolean isSupportedOntapLiveStorageMigration(StoragePoolVO currentPool, StoragePoolVO targetPool) {


this is about validating the inputs if it is landing on the ONTAP plugin for migration, can this validation go insode plugin code and get it checked once control is inside plugin block ?

As replied to the previous comment, we can definitely discuss on the list of checks that we want to do. But, until we get our own pool type for NFS, we would be needing some ontap specific checks here.

rajiv-jain-netapp · 2026-10-08T06:24:26Z

+                _volumeDao.update(volumeVO.getId(), volumeVO);
+            }
+            destVolumeInfo = _volumeDataFactory.getVolume(destVolumeInfo.getId(), destVolumeInfo.getDataStore());
+            hostVO = getHostToMigrateVolume(srcVolumeInfo, destVolumeInfo);


this method can return exception, and on that situation, we would be left with stale cloudstack volume created as part of createAsync() above, fix it with rollback

If any exception is thrown, 'completeVolumeMigrationCallback' in this 'copyAsync' method's finally passes it back and the VolumeServiceImpl would handle the cleanup.

rajiv-jain-netapp · 2026-10-08T06:30:30Z

                } else if (ProtocolType.NFS3.name().equalsIgnoreCase(details.get(OntapStorageConstants.PROTOCOL))) {
-                    // For NFS, no access grant needed - file is accessible via mount
-                    logger.debug("grantAccess: NFS volume [{}], no igroup mapping required", volumeVO.getUuid());
+                    if (shouldConnectHostForMigration(volumeVO)) {


Can you elaborate the permutations of this method, I am suspecting some corner cases issues?

Workflow Side State at grantAccess Attached Connect host

Live VM with storage source Migrating yes yes, iSCSI only

Live VM with storage destination Migrating no yes

Stopped VM with storage source Migrating yes yes

Stopped VM with storage destination Creating no yes

Volume on a stopped VM source Migrating yes yes

Volume on a stopped VM destination Creating no yes

Detached volume source Migrating no yes

Detached volume destination Creating no yes

Volume on a running VM — never reached — —

Deploy, attach, or start volume Ready yes no

github-actions · 2026-10-08T06:31:08Z

This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch.

rajiv-jain-netapp · 2026-10-08T06:34:34Z

+            }
+            Lun.Source source = lun.getCopy() != null ? lun.getCopy().getSource() : null;
+            Lun.Progress progress = source != null ? source.getProgress() : null;
+            if (progress == null || Integer.valueOf(100).equals(progress.getPercentComplete())) {


with this condition, wait would over even if progress is not available.
you should keep it as
if( progress != null && )

sure, will take this up. Thankyou!

is this taken care?

github-actions · 2026-10-14T15:40:03Z

This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch.

suryag1201 · 2026-10-15T16:05:03Z

+            checkAvailableForMigration(srcVolumeInfo.getAttachedVM());
+            checkUnsupportedOntapCrossProtocolMigration(srcVolumeInfo, destVolumeInfo);
+
+            destVolumeInfo.getDataStore().getDriver().createAsync(destVolumeInfo.getDataStore(), destVolumeInfo, null);


here, callback on createAsycn is null which not handled on createAsycn method so it will throw NPE when callback.complete will get called

Done, thankyou!

suryag1201 · 2026-10-15T16:05:41Z

+                destVolumeInfo.processEvent(Event.MigrationCopySucceeded);
+                destVolumeInfo.processEvent(Event.MigrationRequested);
+
+                destDataStore.getDriver().createAsync(destDataStore, destVolumeInfo, null);


same here, callback on createAsync is null

suryag1201 · 2026-10-15T16:10:21Z

+            }
+            Lun.Source source = lun.getCopy() != null ? lun.getCopy().getSource() : null;
+            Lun.Progress progress = source != null ? source.getProgress() : null;
+            if (progress == null || Integer.valueOf(100).equals(progress.getPercentComplete())) {


is this taken care?

suryag1201 · 2026-10-15T16:19:09Z

+                    migrateStorage.put(migrateDiskInfo.getSerialNumber(), migrateDiskInfo);
+                }
+
+                srcVolumeInfoToDestVolumeInfo.put(srcVolumeInfo, destVolumeInfo);


If createAsync, grantAccess, or connectHostToVolume throws exception, the loop never reaches this put.

If any of those throw, handleFailedMigration still disconnects, revokes, and expunges that volume.

suryag1201 · 2026-10-15T17:02:28Z

+                migrateCommand.setNewVmCpuShares(newVmCpuShares);
+            }
+
+            MigrateAnswer migrateAnswer = (MigrateAnswer)_agentMgr.send(srcHost.getId(), migrateCommand);


StorageSystemDataMotionStrategy catches OperationTimedoutException, checks the destination host with CheckVirtualMachineCommand, and keeps the migration if the VM is PowerOn. This strategy does not. A timeout becomes a failure, and handleFailedMigration disconnects and expunges the destination disks the VM may be running on.

Yes, I've now implemented the CheckVirtualMachineCommand to verify the destination. Now, as in StorageSystemDataMotionStrategy, when the VM is in PowerOn state, migration is deemed complete, anything else, including the check itself failing would result in rollback.

suryag1201 · 2026-10-15T17:10:24Z

+        StoragePoolVO srcStoragePoolVO = _storagePoolDao.findById(srcVolumeInfo.getPoolId());
+        List<HostVO> hosts;
+        if (srcStoragePoolVO.getClusterId() != null) {
+            PrimaryDataStoreInfo srcStore = (PrimaryDataStoreInfo)_dataStoreMgr.getPrimaryDataStore(srcStoragePoolVO.getId());


why only from source side? why not dest side?

Usually, the source host initiates and handles the copy. So, the check is done on the src side here.

github-actions · 2026-10-16T07:35:59Z

🔴 Test Coverage Grade: `D` — Marginal

Metric	Value
Line coverage	25.90%
Branch coverage	20.19%

Grade Scale

Grade	Line Coverage	Meaning
🟢 A	≥ 80%	Excellent - this code sleeps well at night 😴
🟡 B	60-79%	Good - almost there, don't stop now 😉
🟠 C	40-59%	Acceptable - your code is wearing a seatbelt, but no airbags 😬
🔴 D	20-39%	Marginal - boldly shipping where no test has gone before 🖖
⛔ F	< 20%	Failing - tests? what tests? 🔥

Branch coverage is shown as a secondary signal. Grade is determined by line coverage.
View full Actions run

…ation # Conflicts: # plugins/storage/volume/ontap/src/main/java/org/apache/cloudstack/storage/driver/OntapPrimaryDatastoreDriver.java # plugins/storage/volume/ontap/src/main/java/org/apache/cloudstack/storage/service/UnifiedSANStrategy.java # plugins/storage/volume/ontap/src/test/java/org/apache/cloudstack/storage/driver/OntapPrimaryDatastoreDriverTest.java # plugins/storage/volume/ontap/src/test/java/org/apache/cloudstack/storage/service/UnifiedNASStrategyTest.java

…ject cross-protocol migration

… copying host

…hares

…s complete

github-actions · 2026-10-26T17:38:14Z

This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch.

piyush5netapp · 2026-10-27T11:03:27Z

        if (currentPool.getId() == targetPool.getId()) {
            return;
        }
+        if (isSupportedOntapLiveStorageMigration(currentPool, targetPool)) {


we do not need this change at all if we enable ALLOW_MIGRATE_OTHER_POOLS with ONTAP pools. That code is already there below. And for an existing pool, we can take care of those through upgrade.

We have specific set of validations to allow migration, which isn't the case for other storage vendors. If we use ALLOW_MIGRATE_OTHER_POOLS and rely on the checks in OntapDataMotionStrategy, VM migration would've been started while each volume individually reaches the strategy class and if the checks fail only for one volume out of say 2 disks, migration for that volume would fail while the other volume gets migrated. Cloudstack doesn't support moving that volume back.

Also, ALLOW_MIGRATE_OTHER_POOLS is currently used only by storage vendors whose 'managed' flag is set to 'false'.

Once our own pool types are ready, we must be able to reduce the flags here.

piyush5netapp · 2026-10-27T13:05:50Z

+
+            // OntapDataMotionStrategy also returns HIGHEST for these and a tie keeps the first strategy.
+            if (srcVolumeInfo.getState() == Volume.State.Migrating
+                    && srcVolumeInfo.getDataStore().getRole() == DataStoreRole.Primary


is not this condition of matching primary redundant if outside if already compares source and destination both as VolumeInfo ? secondary storage to primary for volume to volume itself is not there.

Yeah good catch! since we already have primary checks before this check can be removed.

piyush5netapp · 2026-10-27T13:06:42Z

+        if (copiedVolume.getLun() != null) {
+            Lun copiedLun = copiedVolume.getLun();
+            volumeDetailsDao.addDetail(destVolumeInfo.getId(), OntapStorageConstants.LUN_DOT_UUID, copiedLun.getUuid(), false);
+            volumeDetailsDao.addDetail(destVolumeInfo.getId(), OntapStorageConstants.LUN_DOT_NAME, copiedLun.getName(), false);


we need to save lun serial number of the new copies lun also here as new lun will have new serial number from previous one

Following the same as createAsync, this gets set in grantAccess

piyush5netapp · 2026-10-27T13:07:21Z

+            copyQosIopsFromSourceWhenDestinationHasNone(srcVolumeInfo, destVolumeInfo);
+            applyQosPolicyToVolume(destVolumeInfo);
+            copiedVolumeTO = (VolumeObjectTO)destVolumeInfo.getTO();
+            copiedVolumeTO.setPath(copiedPath);


why are we not setting iscsi_name for iscsi type volumes ?

grantAccess call comes after copyAsync completes, which would set that.

piyush5netapp · 2026-10-27T13:07:40Z

+            volumeDetailsDao.addDetail(destVolumeInfo.getId(), OntapStorageConstants.LUN_DOT_UUID, copiedLun.getUuid(), false);
+            volumeDetailsDao.addDetail(destVolumeInfo.getId(), OntapStorageConstants.LUN_DOT_NAME, copiedLun.getName(), false);
+            destVolumeVO.setFolder(copiedLun.getUuid());
+            destVolumeVO.set_iScsiName(null);


is null set intentionally here ?

This would have the value from source VolumeVO at this point, so setting it to null so that it could be set to proper value later in grantAccess

sandeeplocharla requested review from piyush5netapp, rajiv-jain-netapp and suryag1201 as code owners October 5, 2026 05:54

sandeeplocharla requested a review from sathvikaragi October 5, 2026 05:59

piyush5netapp reviewed Oct 5, 2026

View reviewed changes

Comment thread ...tion/src/main/java/org/apache/cloudstack/storage/motion/StorageSystemDataMotionStrategy.java

sandeeplocharla force-pushed the feature/CSTACKEX-262 branch from 15f8e29 to ddcebda Compare October 5, 2026 06:26

sandeeplocharla marked this pull request as draft October 5, 2026 14:23

sandeeplocharla marked this pull request as ready for review October 7, 2026 01:02

piyush5netapp reviewed Oct 7, 2026

View reviewed changes

rajiv-jain-netapp reviewed Oct 8, 2026

View reviewed changes

github-actions Bot added the status:has-conflicts label Oct 8, 2026

rajiv-jain-netapp reviewed Oct 8, 2026

View reviewed changes

sandeeplocharla force-pushed the feature/CSTACKEX-262 branch 2 times, most recently from e5c27c5 to 9416f32 Compare October 12, 2026 06:10

github-actions Bot removed the status:has-conflicts label Oct 12, 2026

sandeeplocharla force-pushed the feature/CSTACKEX-262 branch from 9416f32 to 7bca4ca Compare October 12, 2026 07:35

github-actions Bot added the status:has-conflicts label Oct 14, 2026

suryag1201 reviewed Oct 15, 2026

View reviewed changes

sandeeplocharla force-pushed the feature/CSTACKEX-262 branch from 575b714 to 26664a6 Compare October 16, 2026 06:45

github-actions Bot removed the status:has-conflicts label Oct 16, 2026

sandeeplocharla added 4 commits October 24, 2026 17:15

CSTACKEX-262: Keep offline CopyCommand on compatible ONTAP NFS and re…

1a1c61a

…ject cross-protocol migration

CSTACKEX-262: Use the remapped iSCSI LUN and register the pool on the…

5db110f

… copying host

Got back the lost changes for iSCSI Offline volume case

c238cce

sandeeplocharla added 4 commits October 24, 2026 17:23

Renamed a method in driver class

b5938ce

CSTACKEX-262: Move ONTAP migration into the plugin and set live CPU s…

cf3b256

…hares

Addressed PR and claude review comments

200aef3

Changes to support migration of volumes with QoS

be02af2

sandeeplocharla force-pushed the feature/CSTACKEX-262 branch from 26664a6 to be02af2 Compare October 26, 2026 13:33

Wait for ONTAP to report LUN copy progress before treating the copy a…

fe0a3c6

…s complete

github-actions Bot added the status:has-conflicts label Oct 26, 2026

piyush5netapp reviewed Oct 27, 2026

View reviewed changes

Workflow	Side	State at grantAccess	Attached	Connect host
Live VM with storage	source	Migrating	yes	yes, iSCSI only
Live VM with storage	destination	Migrating	no	yes
Stopped VM with storage	source	Migrating	yes	yes
Stopped VM with storage	destination	Creating	no	yes
Volume on a stopped VM	source	Migrating	yes	yes
Volume on a stopped VM	destination	Creating	no	yes
Detached volume	source	Migrating	no	yes
Detached volume	destination	Creating	no	yes
Volume on a running VM	—	never reached	—	—
Deploy, attach, or start	volume	Ready	yes	no

Conversation

sandeeplocharla commented Oct 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Types of changes

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

Bug Severity

Live VM with volumes (migrateVirtualMachineWithVolume)

Stopped VM storage migration (migrateVirtualMachineWithVolume, no destination host)

Volume migration (migrateVolume)

Uh oh!

Uh oh!

github-actions Bot commented Oct 6, 2026

🔴 Test Coverage Grade: D — Marginal

Grade Scale

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Oct 8, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Oct 14, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Oct 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔴 Test Coverage Grade: D — Marginal

Grade Scale

Uh oh!

github-actions Bot commented Oct 26, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sandeeplocharla commented Oct 5, 2026 •

edited

Loading

Live VM with volumes (`migrateVirtualMachineWithVolume`)

Stopped VM storage migration (`migrateVirtualMachineWithVolume`, no destination host)

Volume migration (`migrateVolume`)

🔴 Test Coverage Grade: `D` — Marginal

github-actions Bot commented Oct 16, 2026 •

edited

Loading

🔴 Test Coverage Grade: `D` — Marginal