Created attachment 1781756 [details] virt-v2v-windows-bitlocker.log Description of problem: Virt-v2v can't convert windows BitLocker guest on rhel8 Version-Release number of selected component (if applicable): virt-v2v-1.42.0-11.module+el8.5.0+10793+d881d728.x86_64 libguestfs-1.44.0-3.module+el8.5.0+10681+17a9b157.x86_64 libvirt-client-7.0.0-13.module+el8.4.0+10604+5608c2b4.x86_64 qemu-kvm-6.0.0-16.module+el8.5.0+10848+2dccc46d.x86_64 nbdkit-1.24.0-1.module+el8.4.0+9341+96cf2672.x86_64 How reproducible: 100% Steps to Reproduce: 1.Prepare a windows guest whose disk is encrypted by Bitblocker on VMware, then convert the guest from VMware to rhv4.4 by v2v # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk7.0 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -ip /home/passwd -o rhv-upload -of qcow2 -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -os nfs_data -b ovirtmgmt esx7.0-win2019-ntfs-3g-bitblocker [ 0.6] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win2019-ntfs-3g-bitblocker -it vddk -io vddk-libdir=/home/vddk7.0 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 [ 3.3] Creating an overlay to protect the source from being modified [ 5.2] Opening the overlay [ 10.8] 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 [...] Actual results: As above description Expected results: Virt-v2v should can convert windows BitLocker guest since bug1808977 has been fixed Additional info:
Did this really ever work on RHEL AV 8.4.0? I'm not sure that we ever tested it. (Note bug 1808977 was about adding bitlocker support to libguestfs, not testing if it works with virt-v2v.) I also think it may require using the virt-v2v --key option: virt-v2v ... --key /dev/sdb2:key:PASSWORD or: virt-v2v ... --key /dev/sdb2:file:FILENAME In future I want to allow you to use an empty device to mean "any device", eg. --key :key:PASSWORD but that does not work right now.
That command should be: virt-v2v ... --key /dev/sda2:key:PASSWORD
The result is same after adding --key /dev/sda2:key:PASSWORD # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk7.0 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -ip /home/passwd -o rhv-upload -of qcow2 -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -os nfs_data -b ovirtmgmt esx7.0-win2019-ntfs-3g-bitblocker --key /dev/sda2:key:xxxxxxxx [ 0.6] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win2019-ntfs-3g-bitblocker -it vddk -io vddk-libdir=/home/vddk7.0 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 [ 3.3] Creating an overlay to protect the source from being modified [ 4.9] Opening the overlay [ 10.0] 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 [...]
Created attachment 1781918 [details] v2v-windows-guest-bitlocker-rhel8.5.log
OK I see what's going on here. Some of the patches which fix the bug (full list: https://bugzilla.redhat.com/show_bug.cgi?id=1808977#c13) apply to the libguestfs-common git submodule. However I did not apply these patches to virt-v2v's copy of the libguestfs-common submodule, and so virt-v2v doesn't have all the fixes. So really we didn't fix this for virt-v2v in RHEL AV 8.4 (only for libguestfs). Luckily the fix is quite simple. Unfortunately I'm unable to set the ITR flag again.
Verify the bug with below builds: virt-v2v-1.42.0-12.module+el8.5.0+10976+d40a93e9.x86_64 libguestfs-1.44.0-3.module+el8.5.0+10681+17a9b157.x86_64 libvirt-client-7.0.0-13.module+el8.4.0+10604+5608c2b4.x86_64 qemu-kvm-6.0.0-16.module+el8.5.0+10848+2dccc46d.x86_64 nbdkit-1.24.0-1.module+el8.4.0+9341+96cf2672.x86_64 Steps: 1. Prepare a windows guest whose disk is encrypted by Bitblocker on VMware, then convert the guest from VMware to rhv4.4 by v2v # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk7.0 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -ip /home/passwd -o rhv-upload -of qcow2 -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -os nfs_data -b ovirtmgmt esx7.0-win2019-ntfs-3g-bitblocker --key /dev/sda2:key:XXXXXXX [ 0.6] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win2019-ntfs-3g-bitblocker -it vddk -io vddk-libdir=/home/vddk7.0 -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 [ 3.4] Creating an overlay to protect the source from being modified [ 5.2] Opening the overlay virt-v2v: could not find key to open LUKS encrypted /dev/sda2. Try using --key on the command line. Original error: cryptsetup_open: cryptsetup exited with status 1: BITLK devices with type 'encrypt-on-write' cannot be activated. (0) Result: The failure of above v2v conversion has been tracked by bug1959739, so move 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 (virt:av bug fix and enhancement update), 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-2021:4684