following comment #1, 
Can't reproduce using is13 as we couldn't run VM on glusterFS using that build.

The comment was made in the ovirt weekly meeting today:

10:54 < abaron> mburns: note that problem is not libgfapi per se but
                rather lack of support in libvirt for snapshots over
                libgfapi


but I do not see a Depends or link to a RFE in libvirt for it ... does one exist?

Looks like the root cause for gluster storage domain disappearing is that the mount process is executed by vdsm with the same CGroup so the restart of vdsm cause systemd to kill also the mount process.

If you can drop the mount it will solve also bug #1201355

Dropping dependency on 1017289 which has been closed wontfix.
VDSM won't provide 3.6 support on EL6 so no reason to be blocked by an EL6 wontfix bug while the EL7 has been closed current release.

Moving 1017289 to see also, just for reference.

*** Bug 1177776 has been marked as a duplicate of this bug. ***

should this be on MODIFIED?
Is there anything left to do from the RHEV side?

(In reply to Yaniv Dary from comment #19)
> should this be on MODIFIED?
> Is there anything left to do from the RHEV side?
Yes - to write code that makes the VM use the URI, test it and merge it :-)

Is it possible to get some clarifications?

As far as I understand, will be implemented in 4.0.0
Currently, gluster URI is not able to be used by vdsm, disk always be accessed via mount point, not as network block device.
Practically, it means that FUSE overhead still affects VMs.

Why, in that case, oVirt feature page says feature is implemented?
Just gives instructions, how to avoid https://bugzilla.redhat.com/show_bug.cgi?id=1181466

oVirt page: http://www.ovirt.org/Features/GlusterFS_Storage_Domain

May be, it is possible to run VMs in recommended way, but there is some workaround how to run VM with GlusterFS URI (with only one gluster volume to avoid https://bugzilla.redhat.com/show_bug.cgi?id=1247521 )?

Is it true?
If yes, is it possible to provide instruction for that to be tried?

(In reply to Andrejs Baulins from comment #21)
> Is it possible to get some clarifications?
> 
> As far as I understand, will be implemented in 4.0.0
> Currently, gluster URI is not able to be used by vdsm, disk always be
> accessed via mount point, not as network block device.
> Practically, it means that FUSE overhead still affects VMs.
> 
> Why, in that case, oVirt feature page says feature is implemented?
> Just gives instructions, how to avoid
> https://bugzilla.redhat.com/show_bug.cgi?id=1181466
> 
> oVirt page: http://www.ovirt.org/Features/GlusterFS_Storage_Domain
> 
> May be, it is possible to run VMs in recommended way, but there is some
> workaround how to run VM with GlusterFS URI (with only one gluster volume to
> avoid https://bugzilla.redhat.com/show_bug.cgi?id=1247521 )?
> 
> Is it true?
> If yes, is it possible to provide instruction for that to be tried?

I believe the feature page is out of date.
This feature was implemented in 3.3, but reverted before its GA as it broke snapshots.

In any event, it is not available in the current oVirt release.

> 
> In any event, it is not available in the current oVirt release.

Is it planned for future ?
Using libgfapi ( QEMU native driver for GlusterFS ) has lots of performance improvements over fuse mounted gluster volume.

(In reply to SATHEESARAN from comment #23)
> > 
> > In any event, it is not available in the current oVirt release.
> 
> Is it planned for future ?
> Using libgfapi ( QEMU native driver for GlusterFS ) has lots of performance
> improvements over fuse mounted gluster volume.

This is why this ticket exists. To track this change.

I believe, these 2 issues must be linked:
https://bugzilla.redhat.com/show_bug.cgi?id=1175800
with status "depends" or "related"

Updated wiki page with current status and main open issues found.
Reader can follow dependent issues himself in order to know current status.

The storage team do not perform any work on HC and the priority of this item will be very low outside the HC use case. We support the Gluster team in their work (review patches and design reviews, for example) and looking to get more req to perform additional work on HC from our side. Currently, however (and unfortunately), nothing is planned from our side. Moving this back.

*** Bug 1175800 has been marked as a duplicate of this bug. ***

Reassigning release based on Comment 7 of Bug 1175800, and unblocking on the qemu multiple host requirement, as what we have in functionality would be similar to fuse access now.

Opened a new RFE (Bug 1322852) to add additional host support in gfapi access.

(In reply to Yaniv Dary from comment #27)
> The storage team do not perform any work on HC and the priority of this item
> will be very low outside the HC use case. We support the Gluster team in
> their work (review patches and design reviews, for example) and looking to
> get more req to perform additional work on HC from our side. Currently,
> however (and unfortunately), nothing is planned from our side. Moving this
> back.

I was not trying to do an HC setup when I ran into this issue. It also affects non-HC setups that just happen to have a GlusterFS storage domain.

Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.

oVirt 4.0 beta has been released, moving to RC milestone.

oVirt 4.0 beta has been released, moving to RC milestone.

Can anyone tell me why this still has [HC] in the title? The issue affects ovirt installations using a completely separate glusterfs cluster too.

GlusterFS requirements for use as on oVirt storage domain need to be made much clearer IMHO, eg is replica 3 really required, replica 2 with arbiter, erasure coding. and so on.

Coming into this as a newbie would be very confusing.

Can you please update the bugs with the bug url and cleanup the patch list in this bug?

Tested with vdsm-4.19.28-1.el7ev.x86_64

when the engine is configured to use 'libgfapi', the VM disks are accessed via gfapi access mechanism and it works good.