Bug 1687126

Summary: Enabling libgfapisupported changes disk image ownership
Product: [oVirt] ovirt-engine Reporter: Hesham <hsahmed>
Component: BLL.GlusterAssignee: Sahina Bose <sabose>
Status: CLOSED DUPLICATE QA Contact: SATHEESARAN <sasundar>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.3.1CC: bugs, godas
Target Milestone: ovirt-4.4.0Flags: pm-rhel: ovirt-4.4+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-05-21 12:08:51 UTC 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:
Embargoed:

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.

Comment 2 Sahina Bose 2019-04-23 06:18:11 UTC
Could you check if problem persists with oVirt 4.3.2 as the bug 1666795 has been fixed there?

Comment 3 Hesham 2019-05-18 19:20:54 UTC
I can't reproduce this on 4.3.3

Comment 4 Sahina Bose 2019-05-21 12:08:51 UTC

*** This bug has been marked as a duplicate of bug 1666795 ***