Bug 1601943
| Summary: | Improve error "No module named ovirtsdk4" in v2v rhv-upload conversion | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | mxie <mxie> |
| Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.6 | CC: | juzhou, mzhan, ptoscano, tzheng, xiaodwan |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | V2V | ||
| Fixed In Version: | libguestfs-1.38.2-9.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-10-30 07:47:00 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
mxie@redhat.com
2018-07-17 13:57:28 UTC
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! 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 |