Description of problem: The discussed implementation ideas are to reuse the MTC log collection tool or come with other solutions to retain the v2v Pod or the log. Version-Release number of selected component (if applicable): MTV-2.0.0 beta
Tentatively targeting 2.0.0. This requires investigation, but if MTC solution is suitable, it could be implemented soon enough. Sam, this currently concerns VMIO and CDI, since MTV only orchestrates VMImport CRs. Do you think it would be possible?
Retargeting to 2.0.z. MTC solution is to have another state for the Plan CR: Closed. Until the Plan is closed, the resources generated during the migration are retained for investigation, including CRs, pods, etc... Since we're integrating VMIO logic in MTV, we'll add this retention mechanism directly in MTV to simplify the development.
The VMIO logic integration in MTV is targeted to MTV 2.2.0. Retargeting this BZ accordingly.
As part of the plan archival feature we're now retaining the entire virt-v2v pod. https://github.com/konveyor/forklift-controller/pull/361
Please verify with mtv-operator-bundle-2.0.0-57 / iib:126435, or later.
Verified mtv-operator-bundle-2.0.0-57 with both successful and failed pods
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (MTV 2.2.0 Images), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2021:5066