Description of problem: When using virt-v2v against a virtual machine with LUKS encrypted devices, one has to provide the exact device/key pairs for all encrypted devices. Given the wide variety of options to encrypt devices (device, partition, logical volume...), it can lead to having a great number of encrypted devices, hence of device/key pairs to pass as --key options. It would be great to have an additional format for the --key option for wildcard: *:key:passphrase. It uses the same key for all devices that have no specific passphrase. It can be seen as a default passphrase, and should allow passing other device/key pairs for specific devices. It was also mentioned that all keys could be tested against all devices, in order to simplify user input. Version-Release number of selected component (if applicable): 1.38.4-14.module+el8.1.0+4066+0f1aadab
Preliminary patches posted: https://www.redhat.com/archives/libguestfs/2019-November/msg00036.html https://www.redhat.com/archives/libguestfs/2019-November/msg00039.html It needs documentation updates, but the way it is proposed to work is: virt-v2v ... --key :file:/tmp/key1 --key :file:/tmp/key2 [etc] which will apply the key from /tmp/key1, /tmp/key2, etc in turn on every device until one of them works (or fail if there's a device which cannot be opened by any key). Note you need to be careful about the permissions on the temporary files so they are not readable by other users on the machine.
--key is not available in the libguestfs version in RHEL, so moving to Advanced Virtualization.
In the end, we decided to allow also LUKS UUIDs as identifiers for --key, which avoids the need of wildcard options. In addition to the fix for bug 1779120, this RFE requires the following commits: https://github.com/libguestfs/libguestfs/commit/206ce8bbf1bc3332dc019e553d17d6a36f74b725 https://github.com/libguestfs/libguestfs-common/commit/530d0beef74d48617717463a5b585f21e2ed62be https://github.com/libguestfs/libguestfs-common/commit/c10c8baedb88e7c2988a01b70fc5f81fa8e4885c https://github.com/libguestfs/libguestfs-common/commit/22d796efc69de44d0ff1aad6796ac4b31b8b3dc7 (although it will be manually patched where needed, most probably) https://github.com/libguestfs/libguestfs-common/commit/c863ee5e1df5e1eca7ad6821bd2db3796277a6bd https://github.com/libguestfs/libguestfs-common/commit/bb4a2dc17a78b53437896d4215ae82df8e11b788
Verify bug with builds: virt-v2v-1.40.2-16.module+el8.1.1+5096+6326d3d5.x86_64 libguestfs-1.40.2-16.module+el8.1.1+5096+6326d3d5.x86_64 Steps to verify: 1.Prepare a rhel7 guest with two LUKS encrypted devices on ESXI6.7 # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 7G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 6G 0 part ├─rhel_bootp--73--75--198-root 253:0 0 5.4G 0 lvm / └─rhel_bootp--73--75--198-swap 253:1 0 604M 0 lvm [SWAP] sdb 8:16 0 1G 0 disk └─sdb1 8:17 0 1023M 0 part └─luks-37c6d85c-4e6b-48b1-9ae6-d86a4ad3fa33 253:2 0 1021M 0 crypt └─rhel-home 253:3 0 1016M 0 lvm /home sdc 8:32 0 1G 0 disk └─sdc1 8:33 0 1023M 0 part └─luks-e3a90385-a244-4510-b844-396dbce9209e 253:4 0 1021M 0 crypt └─rhel7-var 253:5 0 1016M 0 lvm /var sr0 11:0 1 1024M 0 rom Scenario 1:use uuid to specify device # virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.7-syscrypt-2luks -o rhv -os 10.66.144.40:/home/nfs_export --password-file /home/passwd --key 37c6d85c-4e6b-48b1-9ae6-d86a4ad3fa33:key:12345678 --key e3a90385-a244-4510-b844-396dbce9209e:file:/home/lukspasswd [ 0.0] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.7-syscrypt-2luks [ 3.9] Creating an overlay to protect the source from being modified [ 5.5] Opening the overlay [ 45.1] Inspecting the overlay [ 221.0] Checking for sufficient free disk space in the guest [ 221.0] Estimating space required on target for each disk [ 221.0] Converting Red Hat Enterprise Linux Server 7.7 (Maipo) to run on KVM ^C Result 1:virt-v2v can use uuid to specify device and find the right key for device. Scenario 2:give multiple keys for one device # # virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.7-syscrypt-2luks -o rhv -os 10.66.144.40:/home/nfs_export --password-file /home/passwd --key 37c6d85c-4e6b-48b1-9ae6-d86a4ad3fa33:key:12345678 --key e3a90385-a244-4510-b844-396dbce9209e:key:234 --key e3a90385-a244-4510-b844-396dbce9209e:file:/home/lukspasswd [ 0.0] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.7-syscrypt-2luks [ 3.9] Creating an overlay to protect the source from being modified [ 5.5] Opening the overlay [ 45.7] Inspecting the overlay [ 222.0] Checking for sufficient free disk space in the guest [ 222.0] Estimating space required on target for each disk [ 222.0] Converting Red Hat Enterprise Linux Server 7.7 (Maipo) to run on KVM virt-v2v: warning: guest tools directory ‘linux/el7’ is missing from the virtio-win directory or ISO. Guest tools are only provided in the RHV Guest Tools ISO, so this can happen if you are using the version of virtio-win which contains just the virtio drivers. In this case only virtio drivers can be installed in the guest, and installation of Guest Tools will be skipped. ^C Result 2: virt-v2v can support multi keys for one device. Scenario 3:use uuid to specify the device but only give a wrong key for the device # virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.7-syscrypt-2luks -o rhv -os 10.66.144.40:/home/nfs_export --password-file /home/passwd --key 37c6d85c-4e6b-48b1-9ae6-d86a4ad3fa33:key:12345678 --key e3a90385-a244-4510-b844-396dbce9209e:key:234 [ 0.0] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.7-syscrypt-2luks [ 3.9] Creating an overlay to protect the source from being modified [ 5.6] Opening the overlay virt-v2v: could not find key to open LUKS encrypted /dev/sdc1. Try using --key on the command line. Original error: luks_open: No key available with this passphrase. (0) Result 3: when use wrong password,virt-v2v can give a clear error info. As above testing,now virt-v2v --key option can support to use device UUIDs, and provide multiple keys for one device. 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-2020:0404