I've tested conversion of rhel 4.9 pv guest on xen server using virt-v2v 1.29.14 recently,it can be converted successfully.

(In reply to tingting zheng from comment #4)
> I've tested conversion of rhel 4.9 pv guest on xen server using virt-v2v
> 1.29.14 recently,it can be converted successfully.

What I suspect is happening is that the old version of rpm in
RHEL 4 didn't support the epoch syntax ("1:..."), so commands
like this are failing:

rpm -ql 1:kernel-utils-2.4-23.el4

(For any package where epoch ≠ 0).

Additionally because it's sending the error message to stdout,
we don't see what the error is.

However I don't have a RHEL 4 machine around to test right now.

On RHEL 4.9:

# rpm -ql 1:kernel-utils-2.4-23.el4
package 1:kernel-utils-2.4-23.el4 is not installed
# rpm -ql 0:kernel-utils-2.4-23.el4 
package 0:kernel-utils-2.4-23.el4 is not installed
# rpm -ql kernel-utils-2.4-23.el4 
/etc/cpuspeed.conf
/etc/firmware/microcode.dat
/etc/firmware/microcode_old.dat
/etc/rc.d/init.d/cpuspeed
/etc/rc.d/init.d/irqbalance
/etc/rc.d/init.d/microcode_ctl
[...]

The error seems to be something to do with how we parse epoch
out of the packages database.

What's actually happening on RHEL 4, is that the packages do
have an epoch, but it's "hidden" on the RPM command line.

For example:

$ virt-builder rhel-4.9
$ virt-inspector rhel-4.9
...
      <application>
        <name>aspell</name>
        <epoch>12</epoch>
        <version>0.50.5</version>
        <release>4.EL4</release>
        <arch>x86_64</arch>
      </application>
...

Inside the guest:

# rpm -q aspell
aspell-0.50.5-4.EL4
# rpm -q aspell-0.50.5-4.EL4
aspell-0.50.5-4.EL4
# rpm -q 12:aspell-0.50.5-4.EL4
package 12:aspell-0.50.5-4.EL4 is not installed
# rpm -q aspell-12:0.50.5-4.EL4
package aspell-12:0.50.5-4.EL4 is not installed
# rpm -q --qf '%{name} %{version} %{release} %{epoch}\n' aspell
aspell 0.50.5 4.EL4 12

So this is a bug in virt-v2v, because it should not use the "epoch:" prefix
when querying the package.

I also checked RHEL 3.9, and it's basically the same situation.

Reproducer:

$ virt-builder rhel-4.9

$ virt-v2v -i disk rhel-4.9.img -o null
[   0.0] Opening the source -i disk rhel-4.9.img
[   0.0] Creating an overlay to protect the source from being modified
[   0.0] Opening the overlay
[  12.0] Initializing the target -o null
[  12.0] 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 Red Hat Enterprise Linux AS release 4 (Nahant Update 9) 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 [...]

And the same thing with rhel-3.9:

$ virt-builder rhel-3.9

$ virt-v2v -i disk rhel-3.9.img -o null
[   0.0] Opening the source -i disk rhel-3.9.img
[   0.0] Creating an overlay to protect the source from being modified
[   1.0] Opening the overlay
[  13.0] Initializing the target -o null
[  13.0] Inspecting the overlay
[  15.0] Checking for sufficient free disk space in the guest
[  15.0] Estimating space required on target for each disk
[  15.0] Converting Red Hat Enterprise Linux AS release 3 (Taroon Update 9) 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 [...]

Upstream patch:
https://github.com/libguestfs/libguestfs/commit/205a8c7ca1ed1d66bef56d75c3c244e726e3bbbf

Hi rjones, 
i try to reproduce it but failed, please help me check the log file, thanks.

Packages:
libguestfs-1.28.1-1.14.el7.x86_64
virt-v2v-1.28.1-1.14.el7.x86_64

steps:
1. Add rhel4.9 repo by hand as you said:
# cat > /etc/virt-builder/repos.d/rhel.conf <<EOF
> [rhel]
> uri=http://file.rdu.redhat.com/~rjones/builder/index.asc
> EOF

2. Install guest via virt-builder:
# virt-builder  rhel-4.9
gpg: Signature made Fri 31 Oct 2014 09:44:27 PM CST using RSA key ID E1B768A0
gpg: Good signature from "Richard W.M. Jones <rjones>"
gpg:                 aka "Richard W.M. Jones <rich>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: F777 4FB1 AD07 4A7E 8C87  67EA 9173 8F73 E1B7 68A0
[   6.0] Downloading: http://file.rdu.redhat.com/~rjones/builder/rhel-4.9.xz
[   6.0] Planning how to build this image
[   6.0] Uncompressing
[  12.0] Opening the new disk
[  16.0] Setting a random seed
[  16.0] Setting passwords
Setting random password of root to 03CNHXuZeQqaVtTi
[  17.0] Finishing off
                   Output file: rhel-4.9.img
                   Output size: 6.0G
                 Output format: raw
            Total usable space: 4.9G
                    Free space: 4.1G (83%)

3. Use virt-v2v convert guest:
# virt-v2v -i disk rhel-4.9.img -o null
[   0.0] Opening the source -i disk rhel-4.9.img
[   0.0] Creating an overlay to protect the source from being modified
[   0.0] Opening the overlay
[   3.0] Initializing the target -o null
[   3.0] Inspecting the overlay
[   5.0] Checking for sufficient free disk space in the guest
[   5.0] Estimating space required on target for each disk
[   5.0] Converting Red Hat Enterprise Linux AS release 4 (Nahant Update 9) to run on KVM
virt-v2v: warning: The display driver was updated to 'qxl', but X11 does 
not seem to be installed in the guest.  X may not function correctly.
virt-v2v: This guest has virtio drivers installed.
[   9.0] Mapping filesystem data to avoid copying unused and blank areas
[   9.0] Closing the overlay
[   9.0] Copying disk 1/1 to /var/tmp/null.DexJ5e/sda (raw)
    (100.00/100%)
[  10.0] Creating output metadata
[  10.0] Finishing off

4. I will attach debug log.

Created attachment 965763 [details]
rhel-4.9.img_debug.log

Hi rjones,
please help check Comment 10 & Comment 11, thanks.

Right, sorry about this.  There's actually a different bug in
RHEL 7 libguestfs which stops the test from failing.

If on RHEL 7.1 you run:

 $ virt-builder rhel-4.9
 $ virt-inspector -a rhel-4.9 | less

then you will see:
      ...
      <application>
        <name>kernel-utils</name>
        <version>2.4</version>
        <release>23.el4</release>
        <arch>x86_64</arch>
      </application>

There is no <epoch> field in there, but there should be because this
package has an epoch of 1.  (Compare to the same commands when run on F22)

Upstream I have added this commit:
  https://github.com/libguestfs/libguestfs/commit/e260460a8f608cb30093d7512b12f6ee11841456
which returns the RPM epoch field in inspection data.

That more accurate inspection data is the root cause of the
current bug.

So although this is a bug, and I'm confident we have fixed it,
it's probably the case that it could not be reproduced on RHEL 7.1.