MTV known issue in the CNV release notes - virt-v2v

We need to add an issue to the Known Issues

See the following conversation, which form the basis of this ticket:

 
There was a conversation in the CNV gchat channel yesterday about an MTV known issue. I want to ensure that you know about this issue in case you want to add it as a known issue in your release notes. 
 
From the CNV gchat
 
Hello guys, I believe I'm running into an issue described in this thread. Towards the end of the migration from RHV to CNV, the VM is not able to boot with an error from the Migration Toolkit saying that the conversion of the LUKS encrypted drive failed. Is there anywhere that confirms that encrypted VM disks can only be RAW format?
 
 
Allan Michel
,2:00 PM
@Hadrian Cleague
 
 
Peter Lauterbach
,3:39 PM
@Arik Hadas or @Jochen Schroder ?
 
 
Arik Hadas
,3:44 PM, Edited
@Allan Michel if this error comes from MTV then I assume virt-v2v failed to inspect the image, and that's unreated to the format of disk. in its next version, MTV won't use virt-v2v during migrations from RHV so the migration would complete but we don't import TPM data so if the keys were stored with TPM, they won't exist on the destination and the vm would still fail to boot..
 
 
Allan Michel
,3:50 PM
That's great insight @Arik Hadas
 
 
Arik Hadas
,3:59 PM
that's another benefit of skipping virt-v2v when importing from rhv (besides performance and support for guests that are not supported by virt-v2v) but yeah, full support for migrations of vms with tpm is problematic since rhv doesn't expose this data. maybe we can add a post migration hook to copy that data from rhv.. need to think about this
 
 
Allan Michel
,4:00 PM
My customer is using Clevis and Tang for the LUKS decryption. I'm assuming that may alleviate some of the issue of RHV not exposing the TPM data
 
 
Arik Hadas
,4:00 PM
yeah
 
 
Allan Michel
,4:01 PM
Where can I follow the development of virt-v2v going away on MTV?
 
 
Would like to keep tabs to test with my client when it drops
 
 
@Arik Hadas++ @Hadrian Cleague ++
 
 
Arik Hadas
,4:03 PM
it's already merged on upstream - https://github.com/kubev2v/forklift-controller/pull/440 will be included in MTV 2.4 that is planned for ~03/2023
 
 
Allan Michel
,4:03 PM
Thanks!
 
 
Matt Ford
,12 min
While that helps in a RVH to OpenShift migration, is there any plan to resolve the issue if the situation was Vmware to OpenShift?
 
 
Catherine Tomasko
,10 min
Do we need to include the MTV known issue in the CNV release notes? I don't think we have any customer scheduled to migrated from RHV to CNV right now, so if the issue is being fixed in March, we may not need to mention it.
 
 
Matt Ford
,5 min, Edited
It should at least be mentioned in MTV release notes
 
 
Matt Ford
,2 min
We really need a way to pass a luks key to MTV and the underlying architecture though. The situation that Allan is going through is because of a requirement that came down from DoD/DISA that the drive itself have encryption not just the underlying storage system. In case the drive file was copied off the system by a bad actor, they couldn't see the data that resided in it without decryption keys 
– end of conversation--

I have listed as 2.3.4 but it may affect earlier versions