Description of problem: As discussed in https://bugzilla.redhat.com/show_bug.cgi?id=1367839 oVirt sets the environment variable LIBGUESTFS_BACKEND=direct Starting from RHEL 7.4 this will no longer be necessary, and in fact should not be used. Removing this environment variable will ensure you're getting the additional security of SELinux sVirt against malicious guests. Version-Release number of selected component (if applicable): libvirt >= 2.1.0 libguestfs >= 1.34 Additional info: https://github.com/libguestfs/libguestfs/commit/ecbf09385033ba0acf14e914927ec81ad20a5308
Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.
Why is it on POST (where's the gerrit link?) and is it correctly targeted to 4.3?
(In reply to Yaniv Kaul from comment #2) > Why is it on POST (where's the gerrit link?) Probably automation failure. The gerrit patch is here: https://gerrit.ovirt.org/#/c/80844/ But we cannot do the leap yet because of libguestfs bug 1370055. It would break our imports from Xen. Should I abandon the patch and reset state to NEW to avoid confusion? > and is it correctly targeted to 4.3? Yes, because of the above.
(In reply to Tomáš Golembiovský from comment #3) > (In reply to Yaniv Kaul from comment #2) > > Why is it on POST (where's the gerrit link?) > > Probably automation failure. The gerrit patch is here: > https://gerrit.ovirt.org/#/c/80844/ > > But we cannot do the leap yet because of libguestfs bug 1370055. It would > break our imports from Xen. Is the above the right BZ? You mean https://bugzilla.redhat.com/show_bug.cgi?id=1435162 ? > > Should I abandon the patch and reset state to NEW to avoid confusion? > > > and is it correctly targeted to 4.3? > > Yes, because of the above.
(In reply to Yaniv Kaul from comment #4) > (In reply to Tomáš Golembiovský from comment #3) > > (In reply to Yaniv Kaul from comment #2) > > > Why is it on POST (where's the gerrit link?) > > > > Probably automation failure. The gerrit patch is here: > > https://gerrit.ovirt.org/#/c/80844/ > > > > But we cannot do the leap yet because of libguestfs bug 1370055. It would > > break our imports from Xen. > > Is the above the right BZ? You mean > https://bugzilla.redhat.com/show_bug.cgi?id=1435162 ? Yes, that is the correct bug. (Also, removed the blocking from the bug summary, since it is already a dependency, and removed references to RHEL versions.)
(In reply to Pino Toscano from comment #5) > (In reply to Yaniv Kaul from comment #4) > > Is the above the right BZ? You mean > > https://bugzilla.redhat.com/show_bug.cgi?id=1435162 ? > > Yes, that is the correct bug. > Yes, sorry.
Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both
We didn't get to this bug for more than 2 years, and it's not being considered for the upcoming 4.4. It's unlikely that it will ever be addressed so I'm suggesting to close it. If you feel this needs to be addressed and want to work on it please remove cond nack and target accordingly.
I was about to close it but it now looks we may get to doing this eventualy. Some time ago virt-v2v changed how disks are accessed through SSH which essentially fixes the problems with Xen. Rich now pushed also a patch [1] that disables the requirement that forced us to use direct backend. I tested it and it seems to work fine upstream. Once the code is released and rebased downstream we should be able to use it. Lets revisit the bug again few months. [1] https://github.com/libguestfs/virt-v2v/commit/2c91610ab35ad1e8b49596bcaa94731c67031180
Actually I spoke too quickly. Import from Xen with libvirt backend is still broken, even with recent changes to virt-v2v.
For the record what was the problem? Also it might be related to the changes that have happened in ssh (deprecation of crypto) which wouldn't necessarily be anything to do with the v2v changes.
From libvirt 6.0 it is mandatory to specify format of backing image (to avoid auto detection) and Xen backend does not provide format of input disks. The source domain XML does not specify (and does not have to) specify the format so I am not sure how can we get that information besides letting virt-v2v to do the auto probing.
Oh good point. I will have to fire up my old RHEL 5 VM to see what format(s) were actually used. It might only have ever been raw, since ISTR that Xen's qcow2 support was broken back in the day (and by "back in the day" I mean 2007 ...)
I pushed a patch that enables libvirt backend for VMwre and OVA inputs in oVirt and leaves direct backend only for Xen input. Let's see if we can fix the Xen input in virt-v2v. If not we're probably going to close the bug.
For most of the sources this has already been fixed. Unfortunately it seems there are still some issues with Xen so we cannot do the switch there. But Xen is not a top priority these days so I am going to close the bug.
This bugzilla is included in oVirt 4.4.6 release, published on May 4th 2021. Since the problem described in this bug report should be resolved in oVirt 4.4.6 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.