Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1687126

Summary: Enabling libgfapisupported changes disk image ownership
Product: [oVirt] ovirt-engine Reporter: Hesham <hsahmed>
Component: BLL.GlusterAssignee: Sahina Bose <sabose>
Status: NEW --- QA Contact: SATHEESARAN <sasundar>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.3.1CC: bugs
Target Milestone: ovirt-4.3.4Flags: pm-rhel: ovirt-4.3+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Gluster RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Hesham 2019-03-10 06:00:37 UTC
Description of problem:
Enabling LibgfApiSupported setting on oVirt engine causes the disk image file ownership to change to root:root from vdsm:kvm which in turn causes the disks owning VM to fail to start subsequently.  

Version-Release number of selected component (if applicable):
oVirt 4.3.1 

How reproducible:
Every time

Steps to Reproduce:
1. Enable LibgfApiSupported and restart ovirt-engine service 
2. Start any VM and verify it's using libgfapi
3. Shutdown the VM and try to restart it. VM will fail to start
4. Check the ownership of the disk image file, it will be root:root

Changing the ownership of disk images back to vdsm:kvm allows the VM to be started, however the permissions are lost again upon restart. 

Could be related to bug 1666795

Comment 1 Hesham 2019-03-10 06:30:32 UTC
In some cases the ownership is changed to qemu:qemu however the VM fails to start in those cases too.