Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Descriptionmxie@redhat.com
2017-10-31 12:07:38 UTC
Created attachment 1345868[details]
screenshot
Description of problem:
Can't input password for encrypted partition of physical machine's os during virt-p2v conversion
Version-Release number of selected component (if applicable):
virt-p2v-1.36.10-1.el7.iso
virt-v2v-1.36.10-1.el7.x86_64
libguestfs-1.36.10-1.el7.x86_64
libvirt-3.8.0-1.el7.x86_64
qemu-kvm-rhev-2.10.0-3.el7.x86_64
How reproducible:
100%
Steps to Reproduce:
1.Install a linux OS on physical machine, need to set password for partitions during installing OS
2.Boot the machine into virt-p2v client after finishing OS installation
3.Input the conversion info at p2v client and convent host to libvirt
4.Then the conversion will stop at inputting the password for encrypted partition but p2v client has no response with inputting characters, pls refer to screenshot
Actual results:
As above description
Expected results:
Virt-p2v can convert the host whose OS has encrypted partition
Additional info:
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?
Comment 5Jaroslav Suchanek
2019-12-04 15:30:12 UTC
This bug will be addressed in next major release.
Comment 9RHEL Program Management
2021-01-08 07:24:52 UTC
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.
Comment 10Richard W.M. Jones
2021-01-08 10:55:39 UTC
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.
Comment 13RHEL Program Management
2021-07-31 07:27:15 UTC
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.
Comment 14Richard W.M. Jones
2021-07-31 07:44:50 UTC
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.
Created attachment 1345868 [details] screenshot Description of problem: Can't input password for encrypted partition of physical machine's os during virt-p2v conversion Version-Release number of selected component (if applicable): virt-p2v-1.36.10-1.el7.iso virt-v2v-1.36.10-1.el7.x86_64 libguestfs-1.36.10-1.el7.x86_64 libvirt-3.8.0-1.el7.x86_64 qemu-kvm-rhev-2.10.0-3.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.Install a linux OS on physical machine, need to set password for partitions during installing OS 2.Boot the machine into virt-p2v client after finishing OS installation 3.Input the conversion info at p2v client and convent host to libvirt 4.Then the conversion will stop at inputting the password for encrypted partition but p2v client has no response with inputting characters, pls refer to screenshot Actual results: As above description Expected results: Virt-p2v can convert the host whose OS has encrypted partition Additional info: