Created attachment 977114 [details]
kvm-4.9-i386-raw-modify_debug.log

We should probably ignore any mountpoint that looks like /media/cdrom.

Does it really change /dev/hdb to /dev/hdc or was that a mistake
in the bug report?  That's pretty unexpected if it is happening.

(In reply to Richard W.M. Jones from comment #2)
> We should probably ignore any mountpoint that looks like /media/cdrom.
> 
> Does it really change /dev/hdb to /dev/hdc or was that a mistake
> in the bug report?  That's pretty unexpected if it is happening.

Hi rjones,
Yes, it really change /dev/hdb to /dev/hdc after conversion as bug described, not by mistake, thanks.

-> 7.3.  Quite a serious bug that needs more investigation.

I was unable to find RHEL4.9-i386-AS-DVD.iso.

I tried to reproduce the bug using the instructions below, but
it was not reproducible in either 1.28.1-1.55.el7, nor in upstream.

Junqin: Do you have the file RHEL4.9-i386-AS-DVD.iso or a link to it?

---------

$ virt-builder rhel-4.9
$ guestfish  -a rhel-4.9.img -i 
><fs> emacs /etc/fstab

Append the following single line to guest /etc/fstab:

/dev/hdb /media/cdrom auto pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0

Convert the guest (append -v -x options to capture more debug info):

$ virt-v2v -i disk rhel-4.9.img -o local -os /var/tmp

Examine the converted guest's /etc/fstab file:

$ virt-cat -a /var/tmp/rhel-4.9-sda /etc/fstab

I couldn't reproduce this precisely, but I'm fairly sure the problem
is fixed upstream.  I ran the virt-install command given in the
description, and installed RHEL 4.9, but the /etc/fstab did not
contain the /dev/hdb device.  However I added that manually.

I then did the conversion.  The (correct) warning was printed:

virt-v2v: warning: /files/etc/fstab/8/spec references unknown device "hdb". 
 You may have to fix this entry manually after conversion.

After examining the converted guest, I found that /etc/fstab still
contained the /dev/hdb device which I added manually.  It was not
renumbered to /dev/hdc (which would have been a bug, if it had happened).

So as far as I can tell the bug has fixed itself upstream (most likely
because of https://github.com/libguestfs/libguestfs/commit/ce83f2751bea272b96107482aeb37af2358214dc ).

Junqin/Tingting: Do you want to try to see if you can reproduce the
bug again, or shall I close it?

Junqin is on vacation，so I help to verify this bug

I can reproduce the bug with builds:
virt-v2v-1.28.1-1.55.el7.x86_64
libguestfs-1.28.1-1.55.el7.x86_64
libvirt-1.2.17-11.el7.x86_64
qemu-kvm-rhev-2.3.0-26.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Install a rhel4.9 guest with virt-install by using ISO file:

# virt-install -n kvm-4.9-x86 -r 1024 -f kvm-4.9-x86-raw.img -s 5 --graphics spice -l /root/Desktop/RHEL4.9-i386-AS-DVD.iso 

2. After installation finished, reboot guest and then login guest check file "/etc/fstab"  then shutdown guest without other operation.

# cat /etc/fstab
# This file is edited by fstab-sync - see 'man fstab-sync' for details
/dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
none                    /dev/pts                devpts  gid=5,mode=620  0 0
none                    /dev/shm                tmpfs   defaults        0 0
none                    /proc                   proc    defaults        0 0
none                    /sys                    sysfs   defaults        0 0
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0
/dev/hdb                /media/cdrom            auto     pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0

3. Use virt-v2v to convert the guest to rhev.

# virt-v2v -o rhev -os 10.66.90.115:/vol/v2v_auto/auto_export kvm-4.9-x86
[   0.0] Opening the source -i libvirt kvm-4.9-x86
[   0.0] Creating an overlay to protect the source from being modified
[   1.0] Opening the overlay
[   4.0] Initializing the target -o rhev -os 10.66.90.115:/vol/v2v_auto/auto_export
virt-v2v: warning: cannot write files to the NFS server as 36:36, even 
though we appear to be running as root. This probably means the NFS client 
or idmapd is not configured properly.

You will have to chown the files that virt-v2v creates after the run, 
otherwise RHEV-M will not be able to import the VM.
[   4.0] Inspecting the overlay
[  11.0] Checking for sufficient free disk space in the guest
[  11.0] Estimating space required on target for each disk
[  11.0] Converting Red Hat Enterprise Linux AS release 4 (Nahant Update 9) to run on KVM
virt-v2v: warning: /files/etc/fstab/8/spec references unknown device "hdb". 
 You may have to fix this entry manually after conversion.
virt-v2v: This guest has virtio drivers installed.
[  15.0] Mapping filesystem data to avoid copying unused and blank areas
[  15.0] Closing the overlay
[  15.0] Checking if the guest needs BIOS or UEFI to boot
[  15.0] Copying disk 1/1 to /tmp/v2v.Zdqi4Q/f2ab9c04-e53f-4465-b2f0-8b28fb5905cc/images/2a2f9931-ec1d-43c0-9e50-9fd61210537c/63a3451a-89be-4019-9e12-0ba71bd80bff (raw)
    (100.00/100%)
[  48.0] Creating output metadata
[  48.0] Finishing off

4. After conversion, import guest and check /etc/fstab:

/dev/hdc                /media/cdrom            auto    pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0

Actual results:
1.virt-v2v prints waringing: /files/etc/fstab/8/spec references unknown device "hdb".
You may have to fix this entry manually after conversion.
2.Gues /etc/fstab change /dev/hdb to /dev/hdc after conversion
Expected results:
No warning message and /etc/fstab will not change after conversion

I managed to reproduce it.

The two steps I was missing were:

(1) Rebooting the guest after the initial install, and going through
the guest initial setup.  After doing that, /etc/fstab does contain
/dev/hdb as described in the bug report.

(2) Importing the guest into RHEV and booting it up.  /etc/fstab is
modified *by the guest itself*, so the CDROM entry is changed to point
to wherever the CD is placed.

Immediately after conversion, /etc/fstab is correct.  It's only when
the guest is booted that the guest itself changes /etc/fstab.

Therefore: it's not a bug.  But it was definitely good to go through
this process so we understand the problem, so thanks everyone.

(The warning message printed out by virt-v2v is correct.)