Did this exact same image really work in RHEL 7.5?

It seems as if this has a peculiar encrypted layout which is a bit
unlike normal layouts (ie. normally we support LVM on LUKS only).

In any case the problem is that we're not checking the decrypted
LUKS partition (/dev/mapper/lukssda2) for filesystems.  This is
possibly a regression in the new inspection code.

Note that Listfs.list_filesystems isn't returning the /dev/mapper/luks*
device.  Did the old list_filesystems function before we reimplemented
in 1.38 ...?

(In reply to Richard W.M. Jones from comment #3)
> Did this exact same image really work in RHEL 7.5?

According to my tests, libguestfs in RHEL 7.5 cannot inspect this image out-of-the-box, hence this is not a regression.

Test the bug with latest packages:
virt-v2v-1.38.2-12.el7_6.1.x86_64
libguestfs-1.38.2-12.el7_6.1.x86_64
libvirt-4.5.0-10.el7_6.2.x86_64
qemu-kvm-rhev-2.12.0-19.el7_6.2.x86_64


Scenario1: convert a encrypted rhel6 guest from XEN by virt-v2v, the conversion is still failed (original guest work well on Xen server)

# virt-v2v -ic xen+ssh://root.3.21 Auto-xen-6.9-encrypted -of qcow2 --echo-keys
[   0.0] Opening the source -i libvirt -ic xen+ssh://root.3.21 Auto-xen-6.9-encrypted
[   0.6] Creating an overlay to protect the source from being modified
[   1.2] Initializing the target -o libvirt -os default
[   1.2] Opening the overlay
Enter key or passphrase ("/dev/sda2"): redhat123
[   8.4] Inspecting the overlay
virt-v2v: error: inspection could not detect the source guest (or physical 
machine).

Assuming that you are running virt-v2v/virt-p2v on a source which is 
supported (and not, for example, a blank disk), then this should not 
happen.

No root device found in this operating system image.

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

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



Scenario2: convert a encrypted rhel6 guest from VMware by virt-v2v, the conversion is succeed

# virt-v2v -ic vpx://root.75.182/data/10.73.72.61?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io  vddk-thumbprint=1E:22:D9:AF:A3:00:09:E7:F5:90:0E:C2:D7:19:CD:6F:90:E5:C8:BF esx6.0-rhel6.9-i386-encrypt --keys-from-stdin --password-file /tmp/passwd
[   0.0] Opening the source -i libvirt -ic vpx://root.75.182/data/10.73.72.61?no_verify=1 esx6.0-rhel6.9-i386-encrypt -it vddk  -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1E:22:D9:AF:A3:00:09:E7:F5:90:0E:C2:D7:19:CD:6F:90:E5:C8:BF
[   1.8] Creating an overlay to protect the source from being modified
[   5.1] Initializing the target -o libvirt -os default
[   5.2] Opening the overlay
Enter key or passphrase ("/dev/sda2"): 
[  21.1] Inspecting the overlay
[  39.1] Checking for sufficient free disk space in the guest
[  39.1] Estimating space required on target for each disk
[  39.1] Converting Red Hat Enterprise Linux Server release 6.9 (Santiago) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[ 124.6] Mapping filesystem data to avoid copying unused and blank areas
virt-v2v: warning: fstrim on guest filesystem /dev/VolGroup/lv_root failed. 
 Usually you can ignore this message.  To find out more read "Trimming" in 
virt-v2v(1).

Original message: fstrim: fstrim: /sysroot/: the discard operation is not 
supported
[ 124.7] Closing the overlay
[ 124.9] Checking if the guest needs BIOS or UEFI to boot
[ 124.9] Assigning disks to buses
[ 124.9] Copying disk 1/1 to /var/lib/libvirt/images/esx6.0-rhel6.9-i386-encrypt-sda (raw)
    (100.00/100%)
[ 391.4] Creating output metadata
Pool default refreshed

Domain esx6.0-rhel6.9-i386-encrypt defined from /tmp/v2vlibvirt87fcda.xml

[ 391.6] Finishing off

Additional info:
  Above scenarios have same result on rhel8


Hi rjones,

    Encrypted ways of rhel6 guests of Xen and VMware are same, but the results of conversion are different, could you please help to check the difference between these two scenarios？

Created attachment 1506381 [details]
VMware-rhel6-encrypt.log

After debugging, found v2v can't convert rhel6 guest which has below encrypted partitions (the guest of this bug has below partitions)
# lsblk
NAME                                                 MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
xvda                                                 202:0    0  5.9G  0 disk  
├─xvda1                                              202:1    0    1G  0 part  /boot
├─xvda2                                              202:2    0  3.9G  0 part  
│ └─luks-e4128e77-ac34-404a-8381-23999daf12fe (dm-0) 253:0    0  3.9G  0 crypt /
└─xvda3                                              202:3    0  975M  0 part  [SWAP]


But v2v can convert rhel6 guest which has below encrypted partitions (the guest of bug 1451665 has below partitions)
# lsblk 
NAME                          MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                             8:0    0   10G  0 disk  
├─sda1                          8:1    0  500M  0 part  /boot
└─sda2                          8:2    0  9.5G  0 part  
  └─luks-666cae51-fbf3-453a-a32f-2c8141542012 (dm-0)
                              253:0    0  9.5G  0 crypt 
    ├─VolGroup-lv_root (dm-1) 253:1    0  8.5G  0 lvm   /
    └─VolGroup-lv_swap (dm-2) 253:2    0    1G  0 lvm   [SWAP]


So this bug is not a regression problem which is different with bug1451665

This issue will be addressed in the next major release of RHEL.