+++ This bug was initially created as a clone of Bug #1690574 +++ Description of problem: virt-v2v fails to convert a guest if this has a file without architecture. An example would be a 3rd party kernel module like fileaccess_mod.ko ~~~ chroot: /sysroot: running 'file: /lib/modules/3.10.0-957.1.3.el7.x86_64/fileaccess/fileaccess_mod.ko' ocaml_exn: 'file_architecture' raised 'Failure' exception guestfsd: error: unknown architecture: /lib/modules/3.10.0-957.1.3.el7.x86_64/fileaccess/fileaccess_mod.ko guestfsd: => file_architecture (0x1db) took 0.01 secs libguestfs: trace: v2v: file_architecture = NULL (error) virt-v2v: error: libguestfs error: file_architecture: unknown architecture: /lib/modules/3.10.0-957.1.3.el7.x86_64/fileaccess/fileaccess_mod.ko ~~~ Version-Release number of selected component (if applicable): libguestfs-1.38.2-12.28.lp.el7ev.x86_64 How reproducible: 100% Steps to Reproduce: 1. Have a valid guest with a 3rd party module loaded 2. In this case, the Import was invoked through RHV UI which runs the virt-v2v Actual results: Import failed Expected results: Import should succeed Additional info: --- Additional comment from Pino Toscano on 2019-03-20 12:36:48 CET --- fileaccess_mod.ko seems like a McAfee kernel module: https://kc.mcafee.com/corporate/index?page=content&id=KB91044 https://kc.mcafee.com/corporate/index?page=content&id=KB89912 I'm puzzled why `file` can fail to run on this file, or maybe the output is not what we expect. Anyway, just posted a patch to workaround such situations: https://www.redhat.com/archives/libguestfs/2019-March/msg00069.html --- Additional comment from Pino Toscano on 2019-03-20 17:02:53 CET --- It seems like the issue is due to the module file being a symlink: `file` (invoked by the "file" API, invoked by the "file-architecture" API) does not dereference symlinks, and thus the architecture detection (based on the output of `file`) fails. I posted another fix/workaround for this, simpler than the previous one: https://www.redhat.com/archives/libguestfs/2019-March/msg00078.html --- Additional comment from Pino Toscano on 2019-03-20 17:58:08 CET --- Both patches approved, and sent upstream: https://github.com/libguestfs/libguestfs/commit/0a093035d485b3c2e66d56541ebe159f1b632ba6 https://github.com/libguestfs/libguestfs/commit/363b5e0b4ecebe861a9aafe8bce5a8390b54571c
Verify bug with builds: virt-v2v-1.40.2-4.module+el8+3201+fd6ac632.x86_64 libvirt-5.0.0-7.module+el8+3023+072e7fc8.x86_64 libguestfs-1.40.2-4.module+el8+3201+fd6ac632.x86_64 qemu-kvm-3.1.0-25.module+el8+3153+f1590ef7.x86_64 Steps: 1.Prepare a rhel7 guest with third party module loaded 1.1 Download the package ENSL1022_Eval.zip from https://www.mcafee.com/enterprise/en-us/downloads/trials.html 1.2 Unzip the package and install MFEma.x86_64.rpm and MFErt.i686.rpm 1.3 Check the 3rd party module info: # file -zb /lib/modules/3.10.0-957.el7.x86_64/fileaccess/fileaccess_mod.ko symbolic link to `/opt/isec/ens/esp/modules/fileaccess/3.10.0-957.el7.x86_64-fileaccess_mod.ko' # rpm -qf /lib/modules/3.10.0-957.el7.x86_64/fileaccess/fileaccess_mod.ko file /lib/modules/3.10.0-957.el7.x86_64/fileaccess/fileaccess_mod.ko is not owned by any package 2.Use virt-v2v to convert the guest to rhv; # virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.6-kdump --password-file /tmp/passwd -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data -op /tmp/rhvpasswd -oo rhv-cafile=/home/ca.pem -oo rhv-direct=true -oo rhv-cluster=nfs [ 0.8] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.6-kdump [ 2.7] Creating an overlay to protect the source from being modified [ 3.7] Opening the overlay [ 25.9] Inspecting the overlay [ 292.1] Checking for sufficient free disk space in the guest [ 292.1] Estimating space required on target for each disk [ 292.1] Converting Red Hat Enterprise Linux Server 7.6 (Maipo) to run on KVM virt-v2v: This guest has virtio drivers installed. [2101.0] Mapping filesystem data to avoid copying unused and blank areas [2101.3] Closing the overlay [2101.5] Assigning disks to buses [2101.5] Checking if the guest needs BIOS or UEFI to boot [2101.5] Initializing the target -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -os nfs_data [2103.8] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.LCzPnr/nbdkit0.sock", "file.export": "/" } (raw) (100.00/100%) [3788.2] Creating output metadata [3808.8] Finishing off 3.The conversion can be finished successfully and boot the guest in rhv. 3.1 The guest can pass all regular checkpoints. 3.2 Check the 3rd party kernel module info: # rpm -qf /lib/modules/3.10.0-957.el7.x86_64/fileaccess/fileaccess_mod.ko file /lib/modules/3.10.0-957.el7.x86_64/fileaccess/fileaccess_mod.ko is not owned by any package # file -zb /lib/modules/3.10.0-957.el7.x86_64/fileaccess/fileaccess_mod.ko symbolic link to `/opt/isec/ens/esp/modules/fileaccess/3.10.0-957.el7.x86_64-fileaccess_mod.ko' Result:Virt-v2v can convert guest which has a file without architecture,so change the bug from ON_QA 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-2019:2395