Bug 2027636

Summary: Pop up permission error when converting guest from OVA by v2v if selinux mode is enforcing
Product: Red Hat Enterprise Linux 9 Reporter: mxie <mxie>
Component: virt-v2vAssignee: Richard W.M. Jones <rjones>
Status: CLOSED CURRENTRELEASE QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 9.0CC: chhu, hongzliu, juzhou, kkiwi, lersek, mzhan, rjones, tyan, tzheng, vwu, xiaodwan
Target Milestone: rcKeywords: TestOnly, Triaged
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-01-12 01:08:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1984938, 2027697    
Bug Blocks:    

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".