Description of problem: Improve error "No module named ovirtsdk4" in v2v rhv-upload conversion Version-Release number of selected component (if applicable): virt-v2v-1.38.2-8.el7.x86_64 libguestfs-1.38.2-8.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.Try to convert guest to rhv4.2 using rhv-upload without installing python-ovirt-engine-sdk4 package, the conversion will be failed with error "No module named ovirtsdk4 " # virt-v2v -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.5-x86_64 -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data -op /tmp/rhvpasswd -oo rhv-cafile=/home/ca.pem -oo rhv-direct=true -of raw --password-file /tmp/passwd -on t Traceback (most recent call last): File "/var/tmp/rhvupload.hN4Zly/rhv-upload-plugin.py", line 32, in <module> import ovirtsdk4 as sdk ImportError: No module named ovirtsdk4 nbdkit: error: /var/tmp/rhvupload.hN4Zly/rhv-upload-plugin.py: error running this script virt-v2v: error: nbdkit Python plugin is not installed or not working. It is required if you want to use ‘-o rhv-upload’. See also "OUTPUT TO RHV" in the virt-v2v(1) manual. If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] Actual results: The error "No module named ovirtsdk4 " is not clear so that customers may don't know what package is needed Expected results: Improve error "No module named ovirtsdk4" in v2v rhv-upload conversion Additional info:
Simple patch posted: https://www.redhat.com/archives/libguestfs/2018-July/msg00035.html
Fixed upstream with https://github.com/libguestfs/libguestfs/commit/682d3f8b01bcf8260b4ddeb7e4bc7ea276f38f35 which is in libguestfs >= 1.39.8.
Verify the bug with builds: virt-v2v-1.38.2-9.el7.x86_64 libguestfs-1.38.2-9.el7.x86_64 nbdkit-plugin-python2-1.2.4-4.el7.x86_64 nbdkit-1.2.4-4.el7.x86_64 nbdkit-plugin-python-common-1.2.4-4.el7.x86_64 Steps: 1.Try to convert guest to rhv4.2 using rhv-upload without installing python-ovirt-engine-sdk4 package 1.1 # rpm -qa |grep ovirt-engine noting 1.2 # virt-v2v -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.5-x86_64 -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data -op /tmp/rhvpasswd -oo rhv-cafile=/home/ca.pem -oo rhv-direct=true -of raw --password-file /tmp/passwd Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: No module named ovirtsdk4 virt-v2v: error: the Python module ‘ovirtsdk4’ could not be loaded, is it installed? See previous messages for problems. If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] Hi Pino, Could make package name "python-ovirt-engine-sdk4" showing in the error message?
(In reply to mxie from comment #5) > Could make package name "python-ovirt-engine-sdk4" showing in the error > message? I could, however: - it would be a downstream-only change - mentioning the package name alone will not be helpful either, since you need anyway to add extra channels to get it - rhv-upload is mainly driven by CFME, and already dependencies will be taken care prior of calling virt-v2v - users using rhv-upload manually need already to do extra steps Because of the reasons above, IMHO the best action is to just document the manual procedure in KB (Knowledge Base), so the proper channels & package names can be be described in detail (which you cannot do in a simple error message).
(In reply to Pino Toscano from comment #6) > (In reply to mxie from comment #5) > > Could make package name "python-ovirt-engine-sdk4" showing in the error > > message? > > I could, however: > - it would be a downstream-only change > - mentioning the package name alone will not be helpful either, since you > need anyway to add extra channels to get it > - rhv-upload is mainly driven by CFME, and already dependencies will be > taken care prior of calling virt-v2v > - users using rhv-upload manually need already to do extra steps > > Because of the reasons above, IMHO the best action is to just document the > manual procedure in KB (Knowledge Base), so the proper channels & package > names can be be described in detail (which you cannot do in a simple error > message). Thanks for your reply,creating KB to record the proper channels & package is really good idea, but who will write this Knowledge Base? Do I need to track this in bug? Can I move the bug to verified firstly?
(In reply to mxie from comment #7) > Thanks for your reply,creating KB to record the proper channels & package is > really good idea, but who will write this Knowledge Base? I'm in touch already with the documentation team, this is definitely under my radar. > Can I move the bug to verified firstly? I'd say so, yes. Thanks!
Thanks Pino, according to comment5 ~ comment8, move the bug from ON_QA to VERIFIED
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/RHEA-2018:3021