-
Bug
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
None
-
False
-
-
False
-
ToDo
-
-
-
Important
From our chit chat in [1] (forum-mig) its by design to loop through all the Vms in the namespace(s) you specified when doing a VM storage migration [2]. This is leading to extremely long migration times as mig has to loop over every one, regardless if they are being used by the specific migration plan:
{"level":"info","ts":1769107644.0891562,"logger":"directvolume","msg":"Checking migration status for VM","phase":"CleanupStaleVirtHandlerPods","vm":"sv7bc-slab003"}
{"level":"info","ts":1769107645.0940857,"logger":"directvolume","msg":"Checking migration status for VM","phase":"CleanupStaleVirtHandlerPods","vm":"sv7bc-slab003"}
{"level":"info","ts":1769107646.099285,"logger":"directvolume","msg":"Checking migration status for VM","phase":"CleanupStaleVirtHandlerPods","vm":"sv7bc-slab003"}
{"level":"info","ts":1769107647.103652,"logger":"directvolume","msg":"Checking migration status for VM","phase":"CleanupStaleVirtHandlerPods","vm":"sv7bc-slab003"}
{"level":"info","ts":1769107648.1087341,"logger":"directvolume","msg":"Checking migration status for VM","phase":"CleanupStaleVirtHandlerPods","vm":"sv7bc-slab003"}
This migration plan does finish, but it's taking hours. We understand this is being resolved with native orchestrator in future versions, but anything we can do now to speed this up or fix this iteration to limit it's scope? The customer has quiet a few vms they need to migrate to another storage provider, and this speed is not feasible.
[1] https://redhat-internal.slack.com/archives/CFN0XJEPR/p1769109050953609
