Description of problem: Currently, if virt-v2v-wrapper fails before creating its state file, CloudForms will be stuck trying to read the file. If the file collection fails, CloudForms should move on in the cancellation process.
https://github.com/ManageIQ/manageiq/pull/19908
To test it, the conversion pod has to fail early, e.g. if the pod already exist. A potential flow would be: 1. Create a CloudForms appliance with region 0, say cf1.example.com 2. Configuration the conversion host in cf1.example.com 3. Run a migration on cf1.example.com, the pod will be called conversion-1 4. Create another appliance with region 0, say cf.example.com 5. Configuration the conversion host in cf2.example.com 6. Run a migration on cf2.example.com, the pod can't be created as conversion-1 name already exist
*** Bug 1788505 has been marked as a duplicate of this bug. ***
Ivanchuk backport PR: https://github.com/ManageIQ/manageiq/pull/20068
New commit detected on ManageIQ/manageiq/jansa: https://github.com/ManageIQ/manageiq/commit/fcfcd4bb0ef8893804d2a6b6609e8312a6720b66 commit fcfcd4bb0ef8893804d2a6b6609e8312a6720b66 Author: Adam Grare <agrare> AuthorDate: Mon Mar 2 12:24:55 2020 +0000 Commit: Adam Grare <agrare> CommitDate: Mon Mar 2 12:24:55 2020 +0000 Merge pull request #19908 from fdupont-redhat/v2v_bz_1809035 [V2V] Allow job to continue if kill_virtv2v raises an execption (cherry picked from commit cf44de01dfa1dcc1dabcc44ac50170eed7c2a395) https://bugzilla.redhat.com/show_bug.cgi?id=1809035 app/models/infra_conversion_job.rb | 2 +- app/models/service_template_transformation_plan_task.rb | 4 + spec/models/infra_conversion_job_spec.rb | 16 +- spec/models/service_template_transformation_plan_task_spec.rb | 8 + 4 files changed, 23 insertions(+), 7 deletions(-)
In CFME 5.11.4, this could be tested by: 1. Start a migration and wait for the virt-v2v process to be reported 2. Connect to the conversion host, kill virt-v2v-wrapper and remove the state file in a single command: "kill -9 <virt-v2v-wrapper_PID> ; rm -f /tmp/v2v-import...state" CloudForms will not fail immediately as it supports not to be able to access the state file. Nonetheless, after 5 minutes, it should fail and trigger a cancellation. If you don't want to wait, you can cancel the migration manually.
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, 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/RHBA-2020:2020