If the migration plan or even a single VM, include a mix of datastores based disks they must all be migrated using copyoffload or VVDK/HTTP, the current code can't handle mixed methods on same plan\VM.

If you do mix say a single VM where one disk uses copyoffloaded while the second disk uses VVDK or HTTP, the plan remains stuck on "initializing phase". As there is no timeout during this phase what ends up happening the target namespace gets filled with populator pods and PVCs, this is a big problem was it will endup blocking either CPU/RAM or disk space, if left addressed.  
I've set bug to critical/major as it may induce a silent resource hogging situation on CPU/RAM and disk on the storage side. 

MTV 2.9.0 OCP 4.18

Always - yes  (tested once but should reproduce) 

1. Migrate a single VM, which has two VMDK disks, one on a datastore that is copyoffload supported, it's configured on the storgemap, this the second VM disk has to reside on a datastore that doesn't use copyoffload. 
2. Start the migration, notice the process is stuck on "initializing phase" you can also review target namespace for the pods/PVCs which are endlessly created.

3. I'd archived the migration plan, deleting the pods didn't help, had to delete the namespace, which killed all the pods. But to delete the PVCs under the namespace I had to use a bash loop to remove the finilizers, only then did the target namespace vanish. 

Migration failed, remains forever stuck on "initializing phase" you can also review target namespace for the pods/PVCs which are endlessly created. 

If the code doesn't support we should halt notify the user, else if we fix the code to support such cases the migration should complete 

I tested on a single "mixed" disk VM, but the same should happen if one VM has a single disk(s) on a xcopy supported datastore, while another VM on the plan has a disk(s) which isn't xcopy supported. 

I'll reproduce to add logs and stuff, we know why this is happening was expected need to code a solution.