When a copy offload storagemap includes a missmatching "Storage product" for example Hitachi Vantara when the actual storage is Netapp ONTAP, as expected the migration does indeed fail. However it fails too late in the process, we should check report/log this and exit populator pod sooner. Ideally where we fail for example with a wrong user/password on the storage secert.   

MTV 2.10
OCP 4.19

100%

1. Create a storagemap where "Storage product" is intentionally set wrong say Hitachi Vantara, when we know the actual storage is Netapp ONTAP.
2. Create a migration plan using the above storage map, try to migrate a vm.
3. Migration starts the populator as expected eventually fails with  error pasted below, however I'd expect to test/detect the inconsistency earlier and fail/log a meaningful error.

The error:
W1029 11:21:47.582634 1 client_config.go:667] Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work.
I1029 11:21:47.585702 1 vantara.go:58] storageId: restServerIP: port: userID: password: hostGroupID: []
I1029 11:21:47.585745 1 vsphere-xcopy-volume-populator.go:155] Using vib method for ESXi cloning
I1029 11:21:47.687995 1 vsphere-xcopy-volume-populator.go:239] the volume name is not found on the claim "wrongvnedor-tshefi-linux9-disk-0-91b86c5f". Trying the prime pvc "prime-61406334-1763-41c6-97b3-41cc5f036922"
I1029 11:21:48.582773 1 remote_esxcli.go:107] Debug: UseSSHMethod field value: false
I1029 11:21:48.582792 1 remote_esxcli.go:113] Debug: Set cloneMethod to VIB
I1029 11:21:48.582797 1 remote_esxcli.go:116] Starting populate via remote esxcli vmkfstools (vib), source vmdk=[eco-iscsi-ds3] tshefi-linux9_2/tshefi-linux9.vmdk, pv={pvc-010b69d7-dce5-4de5-b711-21ad487712cb pvc-010b69d7-dce5-4de5-b711-21ad487712cb map[backendUUID:4ba678e5-0d3a-4f05-bdda-e516e3f2e157 internalName:trident_pvc_010b69d7_dce5_4de5_b711_21ad487712cb name:pvc-010b69d7-dce5-4de5-b711-21ad487712cb protocol:block storage.kubernetes.io/csiProvisionerIdentity:1760616938134-3672-csi.trident.netapp.io]}
I1029 11:21:48.583223 1 vsphere-xcopy-volume-populator.go:355] Staring metrics server
found vm VirtualMachine:vm-64084 @ /Eco-Datacenter/vm/tshefi-vms/tshefi-linux9
I1029 11:21:48.601028 1 remote_esxcli.go:125] Got ESXi host: HostSystem:host-12657
I1029 11:21:48.601054 1 vib.go:27] ensuring vib version on ESXi : 0.1.1
I1029 11:21:48.606702 1 client.go:57] about to run esxcli command [software vib get -n vmkfstools-wrapper]
I1029 11:21:51.422256 1 client.go:70] esxcli result message [], status []
I1029 11:21:51.422377 1 vib.go:115] reply from get vib [map[AcceptanceLevel:[CommunitySupported] CreationDate:[2025-10-07] Description:[Custom VIB to wrap vmkfstools as esxcli plugin] ID:[REDHAT_bootbank_vmkfstools-wrapper_0.1.1] InstallDate:[2025-10-19] LiveInstallAllowed:[True] LiveRemoveAllowed:[True] MaintenanceModeRequired:[False] Name:[vmkfstools-wrapper] Overlay:[False] Payloads:[payload1] Platforms:[host] ReferenceURLs:[website|https://redhat.com] StatelessReady:[True] Status:[] Summary:[Custom VIB to wrap vmkfstools as esxcli plugin] Type:[bootbank] Vendor:[REDHAT] Version:[0.1.1]]]
I1029 11:21:51.422412 1 vib.go:34] current vib version on ESXi : 0.1.1
I1029 11:21:51.428498 1 client.go:57] about to run esxcli command [storage core adapter list]
I1029 11:21:51.471328 1 client.go:70] esxcli result message [], status []
I1029 11:21:51.471349 1 client.go:70] esxcli result message [], status []
I1029 11:21:51.471359 1 remote_esxcli.go:173] scini is not required for the storage api
I1029 11:21:51.471368 1 remote_esxcli.go:175] Adapter [0]: map[Description:[(0000:5c:00.0) Microsemi HPE E208i-a SR Gen10] Driver:[smartpqi] HBAName:[vmhba0] LinkState:[link-n/a] UID:[sas.51402ec014734890]]
I1029 11:21:51.471385 1 remote_esxcli.go:177] Description: [(0000:5c:00.0) Microsemi HPE E208i-a SR Gen10]
I1029 11:21:51.471390 1 remote_esxcli.go:177] Driver: [smartpqi]
I1029 11:21:51.471395 1 remote_esxcli.go:177] HBAName: [vmhba0]
I1029 11:21:51.471398 1 remote_esxcli.go:177] LinkState: [link-n/a]
I1029 11:21:51.471399 1 remote_esxcli.go:177] UID: [sas.51402ec014734890]
I1029 11:21:51.471404 1 remote_esxcli.go:175] Adapter [1]: map[Capabilities:[Second Level Lun ID] Description:[iSCSI Software Adapter] Driver:[iscsi_vmk] HBAName:[vmhba64] LinkState:[online] UID:[iqn.1998-01.com.vmware:ecoesxi05.some.random.fqdn:98157922:64]]
I1029 11:21:51.471412 1 remote_esxcli.go:177] UID: [iqn.1998-01.com.vmware:ecoesxi05.some.random.fqdn:98157922:64]
I1029 11:21:51.471419 1 remote_esxcli.go:177] Capabilities: [Second Level Lun ID]
I1029 11:21:51.471421 1 remote_esxcli.go:177] Description: [iSCSI Software Adapter]
I1029 11:21:51.471431 1 remote_esxcli.go:177] Driver: [iscsi_vmk]
I1029 11:21:51.471433 1 remote_esxcli.go:177] HBAName: [vmhba64]
I1029 11:21:51.471435 1 remote_esxcli.go:177] LinkState: [online]
I1029 11:21:51.471443 1 remote_esxcli.go:205] Storage Adapter UID: iqn.1998-01.com.vmware:ecoesxi05.some.random.fqdn:98157922:64 (Driver: iscsi_vmk)
I1029 11:21:51.471454 1 remote_esxcli.go:209] HBA UIDs found: [iqn.1998-01.com.vmware:ecoesxi05.some.random.fqdn:98157922:64]
I1029 11:21:51.471462 1 vantara.go:146] HostGroupIDs used from environment variable: []
I1029 11:21:51.471487 1 vsphere-xcopy-volume-populator.go:204] channel quit invalid volume handle: pvc-010b69d7-dce5-4de5-b711-21ad487712cb
F1029 11:21:51.471496 1 vsphere-xcopy-volume-populator.go:206] invalid volume handle: pvc-010b69d7-dce5-4de5-b711-21ad487712cb

The populator starts working then fails

Assuming we can, I'd check this sooner and catch/halt the populator pod  earlier in the process. 

As it stands I'm worried we can cause loose ends thus reported as a bug, we can switch it to RFE.