Hide Forgot
Description of problem: If you set https_proxy=... and do a virt-v2v conversion, you will find that virt-v2v makes several connections to the server: (1) Initial connection to port 5480 (via libvirt) does not use the proxy. (2) When copying the disks, the proxy is used. virt-v2v should be more consistent in how the proxy is handled, either ignoring https_proxy all the time or using https_proxy all the time. Version-Release number of selected component (if applicable): virt-v2v 1.33.42 (upstream) virt-v2v 1.32.5-10.el7 is also affected How reproducible: 100% Steps to Reproduce: 1. Set https_proxy environment variable to point to a proxy server. 2. Run tcpdump -w /tmp/dump & 3. Run virt-v2v -ic vpx:///.. to do a conversion from vCenter 4. Kill tcpdump. Actual results: Observe in the tcpdump log that connections are made both directly to the vCenter server and via the proxy. Expected results: One of the other, not both. Additional info: https://github.com/libguestfs/libguestfs/commit/41407664603d8fc58b2e74065cbb0ca2ba9e9aa6
*** Bug 1415935 has been marked as a duplicate of this bug. ***
Patches posted: https://www.redhat.com/archives/libguestfs/2017-February/msg00261.html
Upstream in 24d2150047f2414f29d0cecd0adc3c9b18d2cefe
I can reproduce the problem with builds: virt-v2v-1.32.7-3.el7_3.2.x86_64 libguestfs-1.32.7-3.el7_3.2.x86_64 Reproduce steps: 1.Set https_proxy environment variable to point to a proxy server on virt-v2v conversion server #export http_proxy=http://xx.redhat.com:xxxx #export https_proxy=http://xx.redhat.com:xxxx 2.Convert a guest from vmware to rhv by virt-v2v # virt-v2v -ic vpx://root@10.73.75.182/data/10.73.72.61/?no_verify=1 esx6.0-win2012-x86_64 -o rhev -os 10.73.131.93:/home/nfs_export -b ovirtmgmt -n ovirtmgmt --password-file /tmp/passwd [ 0.0] Opening the source -i libvirt -ic vpx://root@10.73.75.182/data/10.73.72.61/?no_verify=1 esx6.0-win2012-x86_64 [ 5.7] Creating an overlay to protect the source from being modified [ 6.8] Initializing the target -o rhev -os 10.73.131.93:/home/nfs_export [ 7.0] Opening the overlay [ 41.0] Inspecting the overlay [ 601.9] Checking for sufficient free disk space in the guest [ 601.9] Estimating space required on target for each disk [ 601.9] Converting Windows Server 2012 Standard to run on KVM virt-v2v: warning: there is no QXL driver for this version of Windows (6.2 x86_64). virt-v2v looks for this driver in /usr/share/virtio-win The guest will be configured to use a basic VGA display driver. virt-v2v: This guest has virtio drivers installed. [ 664.3] Mapping filesystem data to avoid copying unused and blank areas [ 665.5] Closing the overlay [ 665.5] Checking if the guest needs BIOS or UEFI to boot [ 665.5] Assigning disks to buses [ 665.5] Copying disk 1/1 to /tmp/v2v.F7HBTX/4f699f1d-7f77-4e73-a0d2-a3b73c1a0c29/images/b46a56b1-395c-449f-b109-d2019f286578/31c56c06-ae18-42d3-ab14-2263ba825d80 (raw) ^C (4.05/100%) Reproduce result: The v2v conversion only process at 4% of copying after 1 hour, the https proxy env influences the copying of virt-v2v conversion Try to verify the bug with builds: virt-v2v-1.36.3-2.el7.x86_64 libguestfs-1.36.3-2.el7.x86_64 Verified result: The conversion could be finished in 0.5h when converting guest from vmware to rhv after setting https_proxy environment variable, so the https proxy env will not influence virt-v2v conversion now, 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/RHBA-2017:2023