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.
Bug 2027636 - Pop up permission error when converting guest from OVA by v2v if selinux mode is enforcing
Summary: Pop up permission error when converting guest from OVA by v2v if selinux mode...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: virt-v2v
Version: 9.0
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1984938 2027697
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-11-30 10:14 UTC by mxie@redhat.com
Modified: 2022-01-12 01:08 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-01-12 01:08:31 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-104255 0 None None None 2021-11-30 10:16:22 UTC

Description mxie@redhat.com 2021-11-30 10:14:51 UTC
Description of problem:
Pop up permssion error when converting guest from OVA by v2v if selinux mode is enforcing

Version-Release number of selected component (if applicable):
virt-v2v-1.45.91-1.el9.x86_64 
libguestfs-1.46.0-5.el9.x86_64
guestfs-tools-1.46.1-5.el9.x86_64    
nbdkit-1.28.2-2.el9.x86_64
libvirt-libs-7.9.0-1.el9.x86_64
qemu-img-6.1.0-7.el9.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Convert a guest from OVA file by v2v when selinux mode is enforcing
# getenforce
Enforcing

# virt-v2v -i ova esx7.0-win2019-x86_64  -o rhv -os 10.73.194.236:/home/nfs_export -b ovirtmgmt
virt-v2v: warning: making OVA directory public readable to work around 
libvirt bug https://bugzilla.redhat.com/1045069
[   0.0] Opening the source
virt-v2v: error: libguestfs error: could not create appliance through 
libvirt.

Try running qemu directly without libvirt using this environment variable:
export LIBGUESTFS_BACKEND=direct

Original error from libvirt: internal error: process exited while 
connecting to monitor: 2021-11-30T08:40:28.530520Z qemu-kvm: -blockdev 
{"driver":"nbd","server":{"type":"unix","path":"/tmp/v2v.Xxv1zI/in0"},"node-name":"libvirt-2-storage","cache":{"direct":false,"no-flush":true},"auto-read-only":true,"discard":"unmap"}: 
Failed to connect to '/tmp/v2v.Xxv1zI/in0': Permission denied [code=1 
int1=-1]

If reporting bugs, run virt-v2v with debugging enabled and include the 
complete output:

  virt-v2v -v -x [...]


Actual results:
As above description

Expected results:
Can convert guest from OVA by v2v successfully when selinux mode is enforcing

Additional info:
If selinux mode is permissive, can convert guest from OVA by v2v successfully

# getenforce
Permissive

# virt-v2v -i ova esx7.0-win2019-x86_64  -o rhv -os 10.73.194.236:/home/nfs_export -b ovirtmgmt
virt-v2v: warning: making OVA directory public readable to work around 
libvirt bug https://bugzilla.redhat.com/1045069
[   0.0] Opening the source
[   7.4] Inspecting the source
[  13.6] Checking for sufficient free disk space in the guest
[  13.6] Converting Windows Server 2019 Standard to run on KVM
virt-v2v: This guest has virtio drivers installed.
[  38.0] Mapping filesystem data to avoid copying unused and blank areas
[  39.9] Closing the overlay
[  40.2] Assigning disks to buses
[  40.2] Checking if the guest needs BIOS or UEFI to boot
[  90.3] Copying disk 1/1
█ 100% [****************************************]
[1277.2] Creating output metadata
[1277.4] Finishing off

Comment 2 Richard W.M. Jones 2021-11-30 10:23:32 UTC
I think this needs the following fixes:

In virt-v2v:
https://github.com/libguestfs/virt-v2v/commit/52ee0500d374893a9b26bcc56b16990b5e411102
(I think this is already included in the version you have)

In qemu:
https://gitlab.com/qemu-project/qemu/-/commit/3d212b41e9ccb3f37d04f22c59a960bac099c1d4
(https://bugzilla.redhat.com/show_bug.cgi?id=1984938)

Comment 3 Klaus Heinrich Kiwi 2021-12-01 14:36:08 UTC
(In reply to Richard W.M. Jones from comment #2)
> I think this needs the following fixes:
> 
> In virt-v2v:
> https://github.com/libguestfs/virt-v2v/commit/
> 52ee0500d374893a9b26bcc56b16990b5e411102
> (I think this is already included in the version you have)
> 
> In qemu:
> https://gitlab.com/qemu-project/qemu/-/commit/
> 3d212b41e9ccb3f37d04f22c59a960bac099c1d4
> (https://bugzilla.redhat.com/show_bug.cgi?id=1984938)

Can this be considered a tracking-only bug then? Looks like no change will be needed.

Comment 4 Richard W.M. Jones 2021-12-01 14:52:23 UTC
From the development side there's nothing to be done.  But we need to keep
this bug around because it needs to be tested when qemu gets updated.

Comment 5 John Ferlan 2021-12-03 16:58:54 UTC
Added the qemu-6.2 rebase bz as blocked by since that's what we're waiting on from qemu and added the TestOnly keyword, removed the Tracking keyword. 

Also added Rich as the dev owner since he developed the v2v patch and we shouldn't have a patch w/ devel_ack or ITR set assigned to virt-maint... 

I set DTM=16 since that what's used for the blocking qemu bug... I'd say wait for QE to provide the ITM in order to get release+ 

This is one of those weird cases where "normal" movement through to ON_QA by build processes probably gets bypassed since the fix is already present in some downstream v2v although I'm not sure what version - I assume Rich can fill that in if he usually does.

Comment 6 mxie@redhat.com 2022-01-11 10:26:51 UTC
The bug has been fixed

Package version:
virt-v2v-1.45.3-3.el9.x86_64
libguestfs-1.46.1-2.el9.x86_64
guestfs-tools-1.46.1-6.el9.x86_64
libvirt-libs-8.0.0-0rc1.1.el9.x86_64
qemu-img-6.2.0-3.el9.x86_64
nbdkit-server-1.28.4-1.el9.x86_64

Steps:
1.# getenforce
Enforcing

2.# echo $LIBGUESTFS_BACKEND
nothing

3.# virt-v2v -i ova /home/esx7.0-win2019-x86_64 -o null
[   0.0] Opening the source -i ova /home/esx7.0-win2019-x86_64
virt-v2v: warning: making OVA directory public readable to work around 
libvirt bug https://bugzilla.redhat.com/1045069
[  21.8] Creating an overlay to protect the source from being modified
[  21.9] Opening the overlay
[  25.9] Inspecting the overlay
[  28.3] Checking for sufficient free disk space in the guest
[  28.3] Converting Windows Server 2019 Standard to run on KVM
virt-v2v: This guest has virtio drivers installed.
[  38.9] Mapping filesystem data to avoid copying unused and blank areas
[  39.7] Closing the overlay
[  40.0] Assigning disks to buses
[  40.0] Checking if the guest needs BIOS or UEFI to boot
[  40.0] Initializing the target -o null
[  40.0] Copying disk 1/1 to qemu URI json:{ "file.driver": "null-co", "file.size": "1E" } (raw)
    (100.00/100%)
[  92.7] Creating output metadata
[  92.7] Finishing off

Comment 7 John Ferlan 2022-01-11 19:33:23 UTC
Is it possible to set an ITM and move this along to VERIFIED?  It is TestOnly, so NEW probably is the wrong state at this point.

Comment 8 tingting zheng 2022-01-12 01:08:31 UTC
(In reply to John Ferlan from comment #7)
> Is it possible to set an ITM and move this along to VERIFIED?  It is
> TestOnly, so NEW probably is the wrong state at this point.

Set ITM as 20 and close the bug as "CLOSED CURRENTRELEASE".


Note You need to log in before you can comment on or make changes to this bug.