Bug 1354507 - virt-v2v conversions from vCenter do not consistently obey the proxy environment variables
Summary: virt-v2v conversions from vCenter do not consistently obey the proxy environm...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libguestfs
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
Jiri Herrmann
URL:
Whiteboard: V2V
: 1415935 (view as bug list)
Depends On: 1359086
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-11 12:47 UTC by Richard W.M. Jones
Modified: 2017-08-02 08:13 UTC (History)
8 users (show)

Fixed In Version: libguestfs-1.36.1-1.el7
Doc Type: Bug Fix
Doc Text:
The *virt-v2v* utility now ignores proxy environment variables consistently Prior to this update, when using the *virt-v2v* utility to convert a VMware guest virtual machine, *virt-v2v* used the proxy environment variables for some connections to VMware, but not for others. This in some cases caused conversions to fail. Now, *virt-v2v* ignores all proxy environment settings during the conversion, which prevents the described problem.
Clone Of:
Environment:
Last Closed: 2017-08-01 22:08:55 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2023 normal SHIPPED_LIVE libguestfs bug fix and enhancement update 2017-08-01 19:32:01 UTC

Description Richard W.M. Jones 2016-07-11 12:47:04 UTC
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

Comment 1 Richard W.M. Jones 2017-02-16 17:03:30 UTC
*** Bug 1415935 has been marked as a duplicate of this bug. ***

Comment 2 Richard W.M. Jones 2017-02-22 15:30:13 UTC
Patches posted:

https://www.redhat.com/archives/libguestfs/2017-February/msg00261.html

Comment 3 Richard W.M. Jones 2017-04-13 08:04:58 UTC
Upstream in 24d2150047f2414f29d0cecd0adc3c9b18d2cefe

Comment 5 mxie@redhat.com 2017-04-14 08:52:15 UTC
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

Comment 6 errata-xmlrpc 2017-08-01 22:08:55 UTC
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


Note You need to log in before you can comment on or make changes to this bug.