At the moment tests pass(or fail)  per successful VM migration, despite adding some good insight per execution a failed migration means xcopy/fallback failed, we still don't answer the actual test case. 

Some test cases call for xcopy, other tests call for fallback, some test cases mix, where one disk used xcopy while the other disk used fallback. The test should pass or fail depending the intended method mention on the plan plus the actual result of the migration. 
 

For example the first test case, migrate a thin disk VM using xcopy. If the VM was migrated successfully but the disk clone used fallback then this test despite migrating successfully should report test failure as it didn't use xcopy, this is a critical point. 

Fallback is a sub optimal execution of xcopy, where the storage system doesn't prcess the cloning but rather the ESXi host does it, yes its faster than VDDK but it's slower than true xcopy where the storage clones the data. 

Granted this change depends on recent work dev need to finish to expose xcopyused status on the logs. But we really have to fix this ASAP. 

As some test which call for xcopy may actually run with fallback.

Also this means we have to refactor all the tests or how we define/test passing criteria.