Bug 1603149

I'm looking at version 1.40 (on Fedora 29, but it should be the same on CentOS) and it does appear in the drop down menu..

I'm attaching a screenshot.

Created attachment 1549805 [details]
virt-p2v with rhv-upload screenshot

(In reply to Hetz Ben Hamo from comment #2)
> I'm looking at version 1.40 (on Fedora 29, but it should be the same on
> CentOS) and it does appear in the drop down menu..

Yes, but it is unusable.
rhv-upload requires a number of parameters that the p2v GUI does not support.

Moving to RHEL AV.  Note there is no ITR for this, it's meant to be on the backlog.

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.

I think this has actually been fixed now.  Laszlo certainly posted some patches on the list related to this:
https://listman.redhat.com/archives/libguestfs/2023-January/030539.html

In any case as we are building virt-p2v only based on RHEL 9 I'm going to move this bug to RHEL 9.

If -oo can cover all rhv-upload-specific output options, then yes, that series should add the mechanism.

However, we still need to back out the (small) change that disables rhv-upload, specifically for this BZ. So I'm taking this for further investigation.

... I mean we need to revert commit 9b009aa4a389 ("Ignore 'rhv-upload' driver (RHBZ#1590220)", 2019-09-18) for this BZ, in addition to the bug 1792141 series that Rich mentions in comment 18.

Hm, it's not so simple, unfortunately.

https://libguestfs.org/virt-v2v-output-rhv.1.html#output-to-rhv

> -op password-file
>
>     A file containing a password to be used when connecting to the
>     oVirt engine. Note the file should contain the whole password,
>     without any trailing newline, and for security the file should
>     have mode 0600 so that others cannot read it.

We don't have a way to handle this.  In fact, this is a special case of
the secrets handling problem that I outlined in
<https://bugzilla.redhat.com/show_bug.cgi?id=1507901#c16>.

We'll need to think more about this.  We might need to design a generic
way to (a) take a set of secrets on the GUI and the kernel command line,
(b) transfer them as individual, small files to the conversion server,
(c) pass them to virt-v2v with the proper cmdline options, in the
wrapper script, (d) make sure the files are removed (shredded?) in the
conversion directory, eventually, regardless of the virt-v2v exit
status; the secrets must not be leaked.

For now I'm returning this ticket to the backlog; it's not a simple
tweak.

Another note -- consider "-oo rhv-cafile=ca.pem". Even though we may soon be able to spell out just "-oo rhv-cafile=ca.pem" via the GUI, it's insufficient in itself, there's another layer of indirection. And then the question becomes even more generic than just secrets: should we support transferring arbitrary files from virt-p2v to the conversion server? I don't think so. Can we, instead, make the user responsible for preparing *all* required files on the conversion server, before booting virt-p2v on the conversion subject machine? That way, they'd have to take care of all secrets, certificates, and so on, and the virt-p2v UI (both GUI and kernel cmdline) would only have to support passing *references* to those pre-populated files. And, very importantly, virt-p2v would not be responsible for *removing* those files, once conversion ended (one way or another).

While at it, I'd propose adding, to virt-v2v's rhv-upload output module, an "-oo password-file=FILE" option, as an *alias* to the current "-op password-file" option. This would much simplify the virt-p2v UIs.