Bug 1759441
Summary: | RFE: virt-v2v should make rhv-cafile mandatory only if rhv-verifypeer is set to true | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux Advanced Virtualization | Reporter: | liuzi <zili> | ||||||
Component: | libguestfs | Assignee: | Pino Toscano <ptoscano> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | low | ||||||||
Version: | 8.1 | CC: | jsuchane, juzhou, knoel, mtessun, mxie, mzhan, ptoscano, rjones, tzheng, xiaodwan | ||||||
Target Milestone: | rc | Keywords: | FutureFeature | ||||||
Target Release: | 8.1 | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | v2v | ||||||||
Fixed In Version: | libguestfs-1.40.2-15.module+el8.1.1+4955+f0b25565 | Doc Type: | If docs needed, set a value | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2020-02-04 18:28:50 UTC | Type: | Feature Request | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 1758964 | ||||||||
Attachments: |
|
Description
liuzi
2019-10-08 07:58:15 UTC
Created attachment 1623434 [details]
Use a wrong ca.pem file and set rhv-verifypeer=true
Yup, this was changed recently with commit 0a5eaad7db3c9b9a03fa88102a9e6142c855bfd1 which is in libguestfs >= 1.41.5. Verify bug with builds: virt-v2v-1.40.2-15.module+el8.1.1+4955+f0b25565.x86_64 libguestfs-1.40.2-15.module+el8.1.1+4955+f0b25565.x86_64 libvirt-5.6.0-9.module+el8.1.1+4955+f0b25565.x86_64 RHV:4.3.7.0-0.1.el7 Scenario 1 set rhv-verifypeer=false and without the parameter "-oo rhv-cafile" # virt-v2v -ic vpx://root.73.141/data/10.73.196.89/?no_verify=1 -o rhv-upload -os nfs_data -of raw -b ovirtmgmt -n ovirtmgmt esx6.5-win7-x86_64 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA -on esx6.5-win7-x86_64jlM -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -oo rhv-cluster=Default -oo rhv-direct -ip /tmp/passwd [ 0.4] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.196.89/?no_verify=1 esx6.5-win7-x86_64 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA [ 2.3] Creating an overlay to protect the source from being modified [ 5.8] Opening the overlay [ 19.9] Inspecting the overlay [ 22.5] Checking for sufficient free disk space in the guest [ 22.5] Estimating space required on target for each disk [ 22.5] Converting Windows 7 Ultimate to run on KVM virt-v2v: warning: /usr/share/virt-tools/pnp_wait.exe is missing. Firstboot scripts may conflict with PnP. virt-v2v: This guest has virtio drivers installed. [ 26.9] Mapping filesystem data to avoid copying unused and blank areas [ 27.8] Closing the overlay [ 27.8] Assigning disks to buses [ 27.8] Checking if the guest needs BIOS or UEFI to boot [ 27.8] Initializing the target -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -os nfs_data [ 29.1] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.eD4fUS/nbdkit0.sock", "file.export": "/" } (raw) ^C (33.27/100%) Result 1 :Virt-v2v does not require a ca.pem file and can initialize the target successfully. Scenario 2 set rhv-verifypeer=true and without the parameter "-oo rhv-cafile" # virt-v2v -ic vpx://root.73.141/data/10.73.196.89/?no_verify=1 -o rhv-upload -os nfs_data -of raw -b ovirtmgmt -n ovirtmgmt esx6.5-win7-x86_64 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA -on esx6.5-win7-x86_64jlM -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -oo rhv-cluster=Default -oo rhv-direct -ip /tmp/passwd -oo rhv-verifypeer=true virt-v2v: error: -o rhv-upload: must use ‘-oo rhv-cafile’ to supply the path to the oVirt or RHV user’s ‘ca.pem’ file If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] Result 2 :Virt-v2v shows a error info to require a ca.pem file. Scenario 3 set rhv-verifypeer=true and use right ca.pem file # virt-v2v -ic vpx://root.73.141/data/10.73.196.89/?no_verify=1 -o rhv-upload -os nfs_data -of raw -b ovirtmgmt -n ovirtmgmt esx6.5-win7-x86_64 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA -on esx6.5-win7-x86_64jlM -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -oo rhv-cluster=Default -oo rhv-direct -ip /tmp/passwd -oo rhv-verifypeer=true -oo rhv-cafile=/home/ca.pem [ 0.4] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.196.89/?no_verify=1 esx6.5-win7-x86_64 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA [ 2.0] Creating an overlay to protect the source from being modified [ 5.1] Opening the overlay [ 11.5] Inspecting the overlay [ 14.0] Checking for sufficient free disk space in the guest [ 14.0] Estimating space required on target for each disk [ 14.0] Converting Windows 7 Ultimate to run on KVM virt-v2v: warning: /usr/share/virt-tools/pnp_wait.exe is missing. Firstboot scripts may conflict with PnP. virt-v2v: This guest has virtio drivers installed. [ 17.6] Mapping filesystem data to avoid copying unused and blank areas [ 18.5] Closing the overlay [ 18.5] Assigning disks to buses [ 18.5] Checking if the guest needs BIOS or UEFI to boot [ 18.5] Initializing the target -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -os nfs_data [ 19.7] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.eU3boV/nbdkit0.sock", "file.export": "/" } (raw) ^C (4.04/100%) Result 3: virt-v2v works normally. Scenario 4 set rhv-verifypeer=true but give a wrong ca.pem file # virt-v2v -ic vpx://root.73.141/data/10.73.196.89/?no_verify=1 -o rhv-upload -os nfs_data -of raw -b ovirtmgmt -n ovirtmgmt esx6.5-win7-x86_64 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA -on esx6.5-win7-x86_64jlM -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -oo rhv-cluster=Default -oo rhv-direct -ip /tmp/passwd -oo rhv-verifypeer=true -oo rhv-cafile=/tmp/ca.pem Traceback (most recent call last): File "/usr/lib64/python3.6/site-packages/ovirtsdk4/__init__.py", line 381, in authenticate self._sso_token = self._get_access_token() File "/usr/lib64/python3.6/site-packages/ovirtsdk4/__init__.py", line 617, in _get_access_token sso_response = self._get_sso_response(self._sso_url, post_data) File "/usr/lib64/python3.6/site-packages/ovirtsdk4/__init__.py", line 694, in _get_sso_response curl.perform() pycurl.error: (35, 'error:0609E09C:digital envelope routines:pkey_set_type:unsupported algorithm') During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/var/tmp/v2v.2ELeLk/rhv-upload-precheck.py", line 67, in <module> case_sensitive=True, File "/usr/lib64/python3.6/site-packages/ovirtsdk4/services.py", line 5879, in list return self._internal_get(headers, query, wait) File "/usr/lib64/python3.6/site-packages/ovirtsdk4/service.py", line 202, in _internal_get context = self._connection.send(request) File "/usr/lib64/python3.6/site-packages/ovirtsdk4/__init__.py", line 370, in send return self.__send(request) File "/usr/lib64/python3.6/site-packages/ovirtsdk4/__init__.py", line 388, in __send self.authenticate() File "/usr/lib64/python3.6/site-packages/ovirtsdk4/__init__.py", line 384, in authenticate self.__parse_error(e) File "/usr/lib64/python3.6/site-packages/ovirtsdk4/__init__.py", line 932, in __parse_error six.reraise(clazz, clazz(error_msg), sys.exc_info()[2]) File "/usr/local/lib/python3.6/site-packages/six.py", line 695, in reraise raise value.with_traceback(tb) File "/usr/lib64/python3.6/site-packages/ovirtsdk4/__init__.py", line 381, in authenticate self._sso_token = self._get_access_token() File "/usr/lib64/python3.6/site-packages/ovirtsdk4/__init__.py", line 617, in _get_access_token sso_response = self._get_sso_response(self._sso_url, post_data) File "/usr/lib64/python3.6/site-packages/ovirtsdk4/__init__.py", line 694, in _get_sso_response curl.perform() ovirtsdk4.Error: Error while sending HTTP request: (35, 'error:0609E09C:digital envelope routines:pkey_set_type:unsupported algorithm') virt-v2v: error: failed server prechecks, see earlier errors If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] Result 4:virt-v2v does a pre-check and give the error info. Hi,Pino I have tested above scenarios,and I noticed that if set rhv-verifypeer=true,virt-v2v will pre-check the connection.pls refer result4. but I think the error info is not as clear as before,pls refer to comment 1 result2. Could we give a more clear and direct error info ? (In reply to liuzi from comment #4) > I have tested above scenarios,and I noticed that if set > rhv-verifypeer=true,virt-v2v will pre-check the connection.pls refer result4. > but I think the error info is not as clear as before,pls refer to comment 1 > result2. > Could we give a more clear and direct error info ? Most probably the error message in this case can be improved, yes. However, it happened also before the fix of this bug, so please open a different bug/RFE for it. Thanks! As conmment 4 and comment 5,now change the bug from ON_QA to VERIFIED, and file a new bug 1778090 for improving error info. 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:0404 |