The MTV controller has a scheduler for the plan. This scheduler determines which plan should run next and how many VM migrations can be at one time, for this it uses MAX_VM_INFLIGHT env variable and the default is 20.

For cold local migration where we use virt-v2v, which transfers each disk in the sequence, the plan scheduler runs 20 VM migrations at once. Running in the transfers in sequence, results in 20 disks getting migrated at once, which is expected behaviour.

The problem is with the warm/remote migration, where we use the CNV CDI and transfer all disks in parallel. In this case, the scheduler calculates MAX_VM_INFLIGHT for each disk. So if we have 2 VMs with 10 disks each it uses the whole "cost" of the scheduler and we can't run more VMs. This results in faster individual VM migrations which is also expected behaviour for the warm migration where we want to have as low downtime as possible.
But the scheduler "cost" is not freed until the whole VM is migrated. So when VM has 10 disks 1 which is large and 9 small, the small disks are transferred faster but halting other migrations from starting as the scheduler is waiting for the whole VM to get transferred.

Possible solutions:

1. Ignore the number of the disks when migrating using CDI, this has disadvantage that the transfer speed won't be constant and with VMs with lot of disks can cause lot of traffic in the network which might be unexpected.
2. Do not count already finished disk transferred in the "cost", this fixes the biggest point which I made in this issue but does not completely solve the issue. There could be another problem with VMs with lot of disks would need to wait for long time to get scheduled and some of the "cost" migt be already free. For example 2 VMs with 15 disks, the scheduler will start 1 VM migration but won't even partially start and the 5 cost won't be used untill some of the disks would finish.
   This is also kinda expected as the migration time itself of that VM will be much faster. But overall migration plan will be larger.
3. This brings my last idea is the combination of the second solution with addition of the cold VM migration where we would migrate the VMs disk once any cost would free. This will use the "cost" at 100% but the VM disks are migrated at separate times. (only if we would use the CDI for cold migration)