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

(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.

Patch posted:

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

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/

The fix is upstream in e6bc59a7d46707f5037afc8a73206d2773c3fccd.

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

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.

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