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-v2v | Assignee: | Richard W.M. Jones <rjones> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 9.0 | CC: | chhu, hongzliu, juzhou, kkiwi, lersek, mzhan, rjones, tyan, tzheng, vwu, xiaodwan |
Target Milestone: | rc | Keywords: | 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
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) (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. 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. 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. 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 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. (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". |