Hi, for <https://bugzilla.redhat.com/show_bug.cgi?id=1658126>, I'll soon post four short patch sets in response to this email (I'm sending this email basically as a common cover letter for those sets, for better threading). The main difference (for libguestfs & co) between LUKS-on-LVM and LVM-on-LUKS is that in the latter, the names of the decrypted LUKS block devices don't matter. However we name the decrypted devices via inspect_do_decrypt() -> make_mapname() in "common/options/decrypt.c" is irrelevant, as LVM will scan for PVs on all block devices, regardless of their names. The resultant LVs (hosting the filesystems) are what "/etc/fstab" refers to, and we can deal with those names -- the VG and LV names -- well, because (a) there is an "lvs" command (and API) for enumeration (see "lv_canonical" in "daemon/lvm_utils.ml", and lv_canonical() in "daemon/lvm.c" -- see also commit c37c8e770d664), and (b) the VG and LV names are stored in the LVM metadata, so libguestfs doesn't have to "invent" names. This is not the case with LUKS-on-LVM. The names of the decrypted LUKS devices is relevant, as they directly host filesystems, and "/etc/fstab" likely refers to them. Furthermore, there is no enumeration / scanning inside the guest, only a file called "/etc/crypttab". Unfortunately, the root filesystem containing "/etc/crypttab" tends to exist on a LUKS device as well, so we can't consult it for determining the decrypted device names when we're about to decrypt those same devices in inspect_do_decrypt(). (This circular dependency is circumvented during normal guest boot by having a plaintext initrd containing a copy of "/etc/crypttab", and LUKS-related parameters on the a kernel command line in the bootloader config.) In fact, since at least RHEL6, when the user selects either LVM-on-LUKS or LUKS-on-LVM in Anaconda, the installer never asks for LUKS device names (while it does let the user set VG and LV names). Instead, for a given LUKS header containing UUID <UUID>, the decrypted block device will automatically be named /dev/mapper/luks-<UUID>. (Anaconda sets up "/etc/crypttab" and "/etc/fstab" like that.) The patches I'm about to post follow the same logic -- I don't attempt intricate UUID-based (re)mappings through "/etc/crypttab", in "check_fstab_entry" -> "resolve_fstab_device", in "daemon/inspect_fs_unix_fstab.ml". (Assume that "/etc/fstab" refers to "/dev/mapper/hunter2" as a plaintext block device to mount. Assume that "/etc/crypttab" associates the "hunter2" device name with a block device containing a LUKS header with UUID 28372dec-afca-412a-a089-736437fd03af. (For us to realize this, we'd need to parse "/etc/crypttab" with Augeas in the first place.) Then we'd have to recall, by UUID, that we had mapped that particular LUKS device as "/dev/mapper/crypt<WHATEVER>" in inspect_do_decrypt(). Then either close and reopen the LUKS device as "hunter2" (there is no rename operation!), which could get messy as the dependent filesystem would be in use, or replace "hunter2" with "crypt<WHATEVER>" in both "/etc/fstab" and "/etc/crypttab".) Instead, accept the "/dev/mapper/luks-<UUID>" naming scheme as the standard one. Thus, inspect_do_decrypt() will name the decrypted block device "/dev/mapper/luks-<UUID>" at once (rather than "/dev/mapper/crypt<WHATEVER>"). And that name is expected to match the references in "/etc/fstab" and "/etc/crypttab". I've tested this with RHEL-6 and RHEL-7 guests successfully (using "guestfish -i", "virt-inspector", and virt-v2v). Example "lsblk" outputs, with "lsblk" executed in the converted domains: RHEL6: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 252:0 0 20G 0 disk ├─vda1 252:1 0 500M 0 part /boot └─vda2 252:2 0 19.5G 0 part ├─vg_rhel6luks-root (dm-0) 253:0 0 14.7G 0 lvm │ └─luks-0d619854-ccd5-43b1-8883-991fec5ef713 (dm-2) 253:2 0 14.7G 0 crypt / └─vg_rhel6luks-swap (dm-1) 253:1 0 4.9G 0 lvm └─luks-4e9e7a6f-a68c-42fd-92b4-8f4f2579a389 (dm-3) 253:3 0 4.9G 0 crypt [SWAP] RHEL7: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 252:0 0 20G 0 disk ├─vda1 252:1 0 1G 0 part /boot └─vda2 252:2 0 19G 0 part ├─rhel_rhel7luks-root 253:0 0 10G 0 lvm │ └─luks-74558d73-1ef3-4327-878b-f11b266a20fc 253:3 0 10G 0 crypt / ├─rhel_rhel7luks-swap 253:1 0 3.9G 0 lvm │ └─luks-621270fd-6758-4001-8335-492cf5e32a45 253:2 0 3.9G 0 crypt [SWAP] └─rhel_rhel7luks-home 253:4 0 5.1G 0 lvm └─luks-0433f315-afd7-41a0-bd94-3f742114035c 253:5 0 5.1G 0 crypt /home Thanks, Laszlo