Bug 1507901
| Summary: | Can't input password for encrypted partition of physical machine's os during virt-p2v conversion | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | mxie <mxie> | ||||||
| Component: | virt-p2v | Assignee: | Virtualization Maintenance <virt-maint> | ||||||
| Status: | CLOSED MIGRATED | QA Contact: | tingting zheng <tzheng> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 9.2 | CC: | alexandre.chanu, jsuchane, juzhou, lersek, mzhan, ptoscano, rjones, tzheng, virt-maint, xiaodwan | ||||||
| Target Milestone: | rc | Keywords: | FutureFeature, MigratedToJIRA, Reopened, Triaged | ||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | P2V | ||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2023-06-30 18:07:17 UTC | Type: | Feature Request | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
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. |
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: