Created attachment 1345871 [details]
virt-p2v-log

Yes, this is a real bug / missing feature.

We'll probably not have time to fix this for RHEL 7.5, but we
should definitely fix it in 7.6.

I introduced upstream a new --key command line parameter in all the tools
(virt-v2v included) to help with this process:
https://github.com/libguestfs/libguestfs/commit/4b1e5b0c3f900b0f197885e85f8c917caff3c339
Maybe this needs a --machine-readable capability?

Also, should virt-p2v pre-inspect the guest to list all the LUKS/encrypted volumes/partitions, and prefill the UI with passphrase line edits?

This bug will be addressed in next major release.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

I apologise for the actions of the "stale" bug process above.  This bug
is not stale, and I am reopening it.  All bugs are important.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

My apologies, this bug was closed by a broken process that we
do not have any control over.  Reopening.

Hmmm. This sounds like a lot of trouble.

I don't think virt-p2v should try to enumerate the block devices for which keys could otentially be necessary. (See Pino's comment on pre-inspection.) That would duplicate a big bunch of libguestfs / virt-v2v logic, and that simply doesn't belong into virt-p2v. Alternatively, it would require a separate request-response interaction to the conversion server, which would again quite upset the current architecture / flow of virt-p2v.

Second, even if we just provide a list for the user to specify a bunch of keys -- transferring the keys to the conversion server is trouble. virt-v2v's "--key" option can indeed pass keys on the command line, or read them from local files -- but there's a difference between a *direct* user of virt-v2v opting in to that, and virt-p2v open-coding the keys in the virt-v2v wrapper script, or even separate plaintext data files, on the conversion server. On the conversion server, the wrappers script and its associated directory is preserved for debugging if anything goes wrong (maybe even if everything succeeds -- I'm not sure off-hand), and that might mean an indefinite leak of the keys. Big no-no.

Now, perhaps we could abuse --key to read from file descriptors, but that in turn requires more brittle file descriptor forwarding over ssh, from virt-p2v.

My final grasp at straws here would be to tell the user to manually unlock LUKS (via XTerm) on the source, refresh the disks (... although I quite suspect the plaintext device mapper blockdevs are simply not collected by p2v), and then copy the disk in plaintext. Unfortunately, that would mean *decrypting* the disk.

So, yea, no, I have nothing for this. Handling secrets is such a complicated and sensitive area that virt-p2v's architecture is just unprepared for it, at this time. Sorry.

I'm not saying we should close this as WONTFIX or CANTFIX, but the necessary investment seems disproportionate. My guess is this BZ is just going to languish in NEW state. It's really unsurprising there hasn't been much movement here in 5+ years -- I don't have anything either.

See also bug 1507901.

Meh, I meant: see also: bug 1603149.