Bug 1503958

Summary: Failed to convert the rhel5 guest with kmod-xenpv installed from xen server by virt-v2v
Product: Red Hat Enterprise Linux 7 Reporter: mxie <mxie>
Component: libguestfsAssignee: Richard W.M. Jones <rjones>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.4CC: dyuan, juzhou, kuwei, mzhan, ptoscano, tzheng, xiaodwan
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: V2V
Fixed In Version: libguestfs-1.36.10-2.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 09:20:40 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:
Attachments:
Description Flags
virt-v2v-kmod-xenpv.log none

Description mxie@redhat.com 2017-10-19 07:29:06 UTC
Created attachment 1340573 [details]
virt-v2v-kmod-xenpv.log

Description of problem:
Failed to convert the rhel5 guest with kmod-xenpv installed from xen server by virt-v2v

Version-Release number of selected component (if applicable):
virt-v2v-1.36.7-1.el7.x86_64
libguestfs-1.36.7-1.el7.x86_64
libvirt-3.8.0-1.el7.x86_64
qemu-kvm-rhev-2.10.0-2.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Install kmod-xenpv package in rhel5 guest
# rpm -q kmod-xenpv
kmod-xenpv-0.1-9.el5

2.Use v2v to convert this rhel5 guest from xen server
# virt-v2v -ic xen+ssh://root.3.21 xen-hvm-rhel5.11-x86_64 -o null
[   0.0] Opening the source -i libvirt -ic xen+ssh://root.3.21 xen-hvm-rhel5.11-x86_64
[   0.7] Creating an overlay to protect the source from being modified
[   1.4] Initializing the target -o null
[   1.4] Opening the overlay
[   6.1] Inspecting the overlay
[  24.5] Checking for sufficient free disk space in the guest
[  24.5] Estimating space required on target for each disk
[  24.5] Converting Red Hat Enterprise Linux Server release 5.11 (Tikanga) to run on KVM
virt-v2v: error: libguestfs error: command_lines:

If reporting bugs, run virt-v2v with debugging enabled and include the
complete output:

  virt-v2v -v -x [...]

Actual results:
As subject

Expected results:
Could convert the rhel5 guest with kmod-xenpv installed from xen server by virt-v2v

Additional info:
Could convert the rhel5 guest with kmod-xenpv installed from vmware by virt-v2v

Comment 2 Richard W.M. Jones 2017-10-19 10:10:08 UTC
The problem is we run the ‘rpm -qf’ command on the kmod-xenpv to see if it
is owned by an RPM package.  However this gives an error instead of returning
"not owned" (false):

libguestfs: trace: v2v: command_lines "rpm -qf --qf %{NAME}\n /lib/modules//2.6.18-398.el5/extra/xenpv"
guestfsd: main_loop: new request, len 0x80
...
commandrvf: rpm -qf --qf %{NAME}\n /lib/modules//2.6.18-398.el5/extra/xenpv
...
guestfsd: error: 
guestfsd: main_loop: proc 51 (command_lines) took 0.04 seconds
libguestfs: trace: v2v: command_lines = NULL (error)
virt-v2v: error: libguestfs error: command_lines: 

The upstream code is:

https://github.com/libguestfs/libguestfs/blob/f3330e144b1704e78c87b3dde8fd104ede84b7ba/v2v/linux.ml#L133
https://github.com/libguestfs/libguestfs/blob/f3330e144b1704e78c87b3dde8fd104ede84b7ba/v2v/convert_linux.ml#L156-L169

Comment 4 Pino Toscano 2017-10-19 10:46:53 UTC
(In reply to Richard W.M. Jones from comment #2)
> The problem is we run the ‘rpm -qf’ command on the kmod-xenpv to see if it
> is owned by an RPM package.  However this gives an error instead of returning
> "not owned" (false):
> 
> libguestfs: trace: v2v: command_lines "rpm -qf --qf %{NAME}\n
> /lib/modules//2.6.18-398.el5/extra/xenpv"
> guestfsd: main_loop: new request, len 0x80
> ...
> commandrvf: rpm -qf --qf %{NAME}\n /lib/modules//2.6.18-398.el5/extra/xenpv
> ...
> guestfsd: error: 
> guestfsd: main_loop: proc 51 (command_lines) took 0.04 seconds
> libguestfs: trace: v2v: command_lines = NULL (error)
> virt-v2v: error: libguestfs error: command_lines: 

To be precise: the comment actually prints "file <path> is not owned" to stdout, but it returns with an exit code of 1, so that is considered a failure, and the stdout discarded.  Since the command reports no error, then the logger error of command_lines is empty.

Comment 5 Richard W.M. Jones 2017-10-19 11:09:15 UTC
Patch posted:

https://www.redhat.com/archives/libguestfs/2017-October/msg00183.html

Comment 6 mxie@redhat.com 2017-10-20 04:50:34 UTC
I found this bug is not only related to kmod-xenpv package but also related to  xenpv folder which is created at /lib/modules/2.6.18-398.el5/extra/, so the bug also could be reproduced if converting the rhel5 guest which has  kmod-xenpv pkg installed and xenpv folder under /lib/modules/2.6.18-398.el5/extra/ from vmware by virt-v2v

That means:

1.The bug will happen if kmod-xenpv package is installed and xenpv folder is created under /lib/modules/2.6.18-398.el5/extra/
2.The bug will not happen if kmod-xenpv package is installed but xenpv folder is not created under /lib/modules/2.6.18-398.el5/extra/
3.The bug will not happen if kmod-xenpv package is not installed but xenpv folder is created under /lib/modules/2.6.18-398.el5/extra/

Comment 7 Richard W.M. Jones 2017-11-03 10:02:49 UTC
The fix is upstream in e6bc59a7d46707f5037afc8a73206d2773c3fccd.

I'm still working on the second part which is a test of the is_file_owned
function.

Comment 9 kuwei@redhat.com 2017-11-08 11:02:26 UTC
I can reproduce the issue with below builds:
virt-v2v-1.36.7-1.el7.x86_64
libguestfs-1.36.7-1.el7.x86_64
libvirt-3.8.0-1.el7.x86_64
qemu-kvm-rhev-2.10.0-2.el7.x86_64

Try to verify the bug with below builds:
virt-v2v-1.36.10-2.el7.x86_64
libvirt-3.9.0-1.el7.x86_64
libguestfs-1.36.10-2.el7

Steps:
1.Install kmod-xenpv package in rhel5 guest  and xenpv folder is created under /lib/modules/2.6.18-398.el5/extra/ .
2.Use v2v to convert this rhel5 guest from xen server
# virt-v2v -ic xen+ssh://root.3.21 xen-hvm-rhel5.11-x86_64 -of raw
[   0.0] Opening the source -i libvirt -ic xen+ssh://root.3.21 xen-hvm-rhel5.11-x86_64
[   0.7] Creating an overlay to protect the source from being modified
[   1.2] Initializing the target -o libvirt -os default
[   1.2] Opening the overlay
[   3.0] Inspecting the overlay
[  11.4] Checking for sufficient free disk space in the guest
[  11.4] Estimating space required on target for each disk
[  11.4] Converting Red Hat Enterprise Linux Server release 5.11 (Tikanga) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[  56.9] Mapping filesystem data to avoid copying unused and blank areas
[  57.1] Closing the overlay
[  57.2] Checking if the guest needs BIOS or UEFI to boot
[  57.2] Assigning disks to buses
[  57.2] Copying disk 1/1 to /var/lib/libvirt/images/xen-hvm-rhel5.11-x86_64-sda (raw)
    (100.00/100%)
[ 252.5] Creating output metadata
Pool default refreshed

Domain xen-hvm-rhel5.11-x86_64 defined from /tmp/v2vlibvirt5b5112.xml

[ 252.7] Finishing off

3.After conversion, all checkpoints passed.

So.move the bug to VERIFIED.

Comment 12 errata-xmlrpc 2018-04-10 09:20:40 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-2018:0677