Bug 1488995

+++ This bug was initially created as a clone of Bug #1022961 +++

Description of problem:
when creating gluster storage domain, it should use gluster URI instead of mount type fuse.glusterfs

Version-Release number of selected component (if applicable):
3.3 is19

How reproducible:
100%

Steps to Reproduce:
1. set rhev setup with 2 hosts , create glusterFS DC
2. create glusterFS SD
3. create VM with disk
4. 

Actual results:
==========
we are mounting the glusterFS instead of using gluster URI

run ps aux |grep qemu - (as part of the process running you can see below)
-drive file=/rhev/data-center/mnt/glusterSD/10.35.161.249:_acanan01/619413a0-9979-4743-b0d1-255e8a8734d9

run mount - 
10.35.161.249:/acanan01 on /rhev/data-center/mnt/glusterSD/10.35.161.249:_acanan01 type fuse.glusterfs (rw,default_permissions,allow_other,max_read=131072)


Expected results:
shouldn't mount but use gluster URI like below - 
-drive file=gluster[+transport]://[server[:port]]/volname/image[?socket=...]


Additional info:
===========
as appears in ovirt feature page (check different table between posix and glusterfs)

--- Additional comment from Allon Mureinik on 2013-10-24 08:50:48 EDT ---

Seems as though this could be related to the One Shot Prepare patch:

-        for vol in imgVolumes:
+        leafPath = os.path.join(imgPath, leafUUID)
+        for volUUID in imgVolumes:
+            path = os.path.join(dom.domaindir, sd.DOMAIN_IMAGES, imgUUID,
+                                volUUID)
             volInfo = {'domainID': sdUUID, 'imageID': imgUUID,
-                       'volumeID': vol.volUUID, 'path': vol.getVolumePath(),
-                       'vmVolInfo': vol.getVmVolumeInfo()}
+                       'volumeID': volUUID, 'path': path,
+                       'volType': "path"}

Aharon - If you can test this with VDSM from is13(!), that would be great.
(This is the last revision without One Short Prepare)

--- Additional comment from Allon Mureinik on 2013-10-27 05:43:43 EDT ---

Edu, this functionality seems to have been broken by oneshot prepare (see comment 1).
Please take a look.

--- Additional comment from Aharon Canan on 2013-10-27 07:59:37 EDT ---

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

--- Additional comment from Dan Kenigsberg on 2013-10-27 21:36:38 EDT ---

Aharon, is there a reason to keep the informative comment 0 secret? You internal IP address is not a good-enough reason imo.

--- Additional comment from Aharon Canan on 2013-10-28 05:13:28 EDT ---

Itamar wrote in related email "lets be careful on how we phrase our replies publicly on this one." so...

--- Additional comment from Itamar Heim on 2013-10-28 05:14:22 EDT ---

(In reply to Aharon Canan from comment #5)
> Itamar wrote in related email "lets be careful on how we phrase our replies
> publicly on this one." so...

that was before it was understood its a simple regression (hopefully)

--- Additional comment from Rejy M Cyriac on 2013-10-31 12:40:57 EDT ---

Tested adding an RHS volume as glusterfs type Storage Domain to Data Center of glusterfs storage type on RHEVM 3.3 is21 Build.

Result
------
Test Failure

Versions
--------
RHEVM 3.3 is21 Build - 3.3.0-0.31.beta1.el6ev
Hypervisor - RHEL 6.5 with glusterfs-api-3.4.0.36rhs-1
RHS - 3.4.0.36rhs-1

Observations
------------
1) When the hypervisor has only the glusterfs-api and glusterfs-libs packages installed, the add operation fails with the following message in the vdsm logs.

---------------------------------------------------------
Thread-42::DEBUG::2013-10-31 21:47:25,317::BindingXMLRPC::177::vds::(wrapper) client [10.70.34.114] flowID [67b5d57d]
Thread-42::DEBUG::2013-10-31 21:47:25,318::task::579::TaskManager.Task::(_updateState) Task=`1c20c336-0fed-4d01-bc48-4fd3917865c5`::moving from state init -> state preparing
Thread-42::INFO::2013-10-31 21:47:25,318::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=7, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'port': '', 'connection': 'fillmore.lab.eng.blr.redhat.com:phase1', 'iqn': '', 'portal': '', 'user': '', 'vfs_type': 'glusterfs', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000'}], options=None)
Thread-42::DEBUG::2013-10-31 21:47:25,321::mount::226::Storage.Misc.excCmd::(_runcmd) '/usr/bin/sudo -n /bin/mount -t glusterfs fillmore.lab.eng.blr.redhat.com:phase1 /rhev/data-center/mnt/glusterSD/fillmore.lab.eng.blr.redhat.com:phase1' (cwd None)
Thread-42::ERROR::2013-10-31 21:47:25,361::storageServer::209::StorageServer.MountConnection::(connect) Mount failed: (32, ";mount: unknown filesystem type 'glusterfs'\n")
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/storageServer.py", line 207, in connect
    self._mount.mount(self.options, self._vfsType)
  File "/usr/share/vdsm/storage/mount.py", line 222, in mount
    return self._runcmd(cmd, timeout)
  File "/usr/share/vdsm/storage/mount.py", line 238, in _runcmd
    raise MountError(rc, ";".join((out, err)))
MountError: (32, ";mount: unknown filesystem type 'glusterfs'\n")
Thread-42::ERROR::2013-10-31 21:47:25,362::hsm::2373::Storage.HSM::(connectStorageServer) Could not connect to storageServer
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/hsm.py", line 2370, in connectStorageServer
    conObj.connect()
  File "/usr/share/vdsm/storage/storageServer.py", line 215, in connect
    raise e
MountError: (32, ";mount: unknown filesystem type 'glusterfs'\n")
Thread-42::DEBUG::2013-10-31 21:47:25,363::hsm::2392::Storage.HSM::(connectStorageServer) knownSDs: {}
Thread-42::INFO::2013-10-31 21:47:25,363::logUtils::47::dispatcher::(wrapper) Run and protect: connectStorageServer, Return response: {'statuslist': [{'status': 477, 'id': '00000000-0000-0000-0000-000000000000'}]}
Thread-42::DEBUG::2013-10-31 21:47:25,363::task::1168::TaskManager.Task::(prepare) Task=`1c20c336-0fed-4d01-bc48-4fd3917865c5`::finished: {'statuslist': [{'status': 477, 'id': '00000000-0000-0000-0000-000000000000'}]}
Thread-42::DEBUG::2013-10-31 21:47:25,364::task::579::TaskManager.Task::(_updateState) Task=`1c20c336-0fed-4d01-bc48-4fd3917865c5`::moving from state preparing -> state finished
Thread-42::DEBUG::2013-10-31 21:47:25,364::resourceManager::939::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {}
Thread-42::DEBUG::2013-10-31 21:47:25,364::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {}
Thread-42::DEBUG::2013-10-31 21:47:25,364::task::974::TaskManager.Task::(_decref) Task=`1c20c336-0fed-4d01-bc48-4fd3917865c5`::ref 0 aborting False
Thread-44::DEBUG::2013-10-31 21:47:29,957::task::579::TaskManager.Task::(_updateState) Task=`5d2e9519-5830-415a-879e-a7b806b228a0`::moving from state init -> state preparing
Thread-44::INFO::2013-10-31 21:47:29,957::logUtils::44::dispatcher::(wrapper) Run and protect: repoStats(options=None)
Thread-44::INFO::2013-10-31 21:47:29,957::logUtils::47::dispatcher::(wrapper) Run and protect: repoStats, Return response: {}
Thread-44::DEBUG::2013-10-31 21:47:29,957::task::1168::TaskManager.Task::(prepare) Task=`5d2e9519-5830-415a-879e-a7b806b228a0`::finished: {}
Thread-44::DEBUG::2013-10-31 21:47:29,957::task::579::TaskManager.Task::(_updateState) Task=`5d2e9519-5830-415a-879e-a7b806b228a0`::moving from state preparing -> state finished
Thread-44::DEBUG::2013-10-31 21:47:29,957::resourceManager::939::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {}
Thread-44::DEBUG::2013-10-31 21:47:29,958::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {}
Thread-44::DEBUG::2013-10-31 21:47:29,958::task::974::TaskManager.Task::(_decref) Task=`5d2e9519-5830-415a-879e-a7b806b228a0`::ref 0 aborting False
---------------------------------------------------------

2) Installed the glusterfs package to the Hypervisor in addition to the glusterfs-api and glusterfs-libs packages already installed. Still operation fails with similar message.

---------------------------------------------------------
Thread-144::DEBUG::2013-10-31 21:51:40,874::BindingXMLRPC::177::vds::(wrapper) client [10.70.34.114] flowID [5319e10a]
Thread-144::DEBUG::2013-10-31 21:51:40,875::task::579::TaskManager.Task::(_updateState) Task=`1d7d28fe-6271-469f-8048-d8bef215df54`::moving from state init -> state preparing
Thread-144::INFO::2013-10-31 21:51:40,875::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=7, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'port': '', 'connection': 'fillmore.lab.eng.blr.redhat.com:phase1', 'iqn': '', 'portal': '', 'user': '', 'vfs_type': 'glusterfs', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000'}], options=None)
Thread-144::DEBUG::2013-10-31 21:51:40,879::mount::226::Storage.Misc.excCmd::(_runcmd) '/usr/bin/sudo -n /bin/mount -t glusterfs fillmore.lab.eng.blr.redhat.com:phase1 /rhev/data-center/mnt/glusterSD/fillmore.lab.eng.blr.redhat.com:phase1' (cwd None)
Thread-144::ERROR::2013-10-31 21:51:40,925::storageServer::209::StorageServer.MountConnection::(connect) Mount failed: (32, ";mount: unknown filesystem type 'glusterfs'\n")
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/storageServer.py", line 207, in connect
    self._mount.mount(self.options, self._vfsType)
  File "/usr/share/vdsm/storage/mount.py", line 222, in mount
    return self._runcmd(cmd, timeout)
  File "/usr/share/vdsm/storage/mount.py", line 238, in _runcmd
    raise MountError(rc, ";".join((out, err)))
MountError: (32, ";mount: unknown filesystem type 'glusterfs'\n")
Thread-144::ERROR::2013-10-31 21:51:40,927::hsm::2373::Storage.HSM::(connectStorageServer) Could not connect to storageServer
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/hsm.py", line 2370, in connectStorageServer
    conObj.connect()
  File "/usr/share/vdsm/storage/storageServer.py", line 215, in connect
    raise e
MountError: (32, ";mount: unknown filesystem type 'glusterfs'\n")
Thread-144::DEBUG::2013-10-31 21:51:40,927::hsm::2392::Storage.HSM::(connectStorageServer) knownSDs: {}
Thread-144::INFO::2013-10-31 21:51:40,927::logUtils::47::dispatcher::(wrapper) Run and protect: connectStorageServer, Return response: {'statuslist': [{'status': 477, 'id': '00000000-0000-0000-0000-000000000000'}]}
Thread-144::DEBUG::2013-10-31 21:51:40,928::task::1168::TaskManager.Task::(prepare) Task=`1d7d28fe-6271-469f-8048-d8bef215df54`::finished: {'statuslist': [{'status': 477, 'id': '00000000-0000-0000-0000-000000000000'}]}
Thread-144::DEBUG::2013-10-31 21:51:40,928::task::579::TaskManager.Task::(_updateState) Task=`1d7d28fe-6271-469f-8048-d8bef215df54`::moving from state preparing -> state finished
Thread-144::DEBUG::2013-10-31 21:51:40,928::resourceManager::939::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {}
Thread-144::DEBUG::2013-10-31 21:51:40,928::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {}
Thread-144::DEBUG::2013-10-31 21:51:40,928::task::974::TaskManager.Task::(_decref) Task=`1d7d28fe-6271-469f-8048-d8bef215df54`::ref 0 aborting False
---------------------------------------------------------

3) Installed the glusterfs-fuse package as well on the Hypervisor. Now add operation of the Storage Domain is successful with the following message. But it can be seen that a glusterfs fuse mount is being done here, just like for a POSIXcompliantFS storage domain. This is not expected to happen, as it is expected to use the gfapi method to access the RHS volume.

---------------------------------------------------------
# df -T /rhev/data-center/mnt/glusterSD/fillmore.lab.eng.blr.redhat.com:phase1
Filesystem                             Type           1K-blocks   Used Available Use% Mounted on
fillmore.lab.eng.blr.redhat.com:phase1 fuse.glusterfs  40869888 137344  40732544   1% /rhev/data-center/mnt/glusterSD/fillmore.lab.eng.blr.redhat.com:phase1

-----------------------------------

Thread-157::DEBUG::2013-10-31 21:52:13,185::task::579::TaskManager.Task::(_updateState) Task=`ced26482-8314-47d6-b63d-20cdf5692a5d`::moving from state init -> state preparing
Thread-157::INFO::2013-10-31 21:52:13,185::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=7, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'port': '', 'connection': 'fillmore.lab.eng.blr.redhat.com:phase1', 'iqn': '', 'portal': '', 'user': '', 'vfs_type': 'glusterfs', 'password': '******', 'id': '00000000-0000-0000-0000-000000000000'}], options=None)
Thread-157::DEBUG::2013-10-31 21:52:13,187::mount::226::Storage.Misc.excCmd::(_runcmd) '/usr/bin/sudo -n /bin/mount -t glusterfs fillmore.lab.eng.blr.redhat.com:phase1 /rhev/data-center/mnt/glusterSD/fillmore.lab.eng.blr.redhat.com:phase1' (cwd None)
Thread-157::DEBUG::2013-10-31 21:52:14,518::hsm::2324::Storage.HSM::(__prefetchDomains) glusterDomPath: glusterSD/*
Thread-157::DEBUG::2013-10-31 21:52:14,594::hsm::2336::Storage.HSM::(__prefetchDomains) Found SD uuids: ()
Thread-157::DEBUG::2013-10-31 21:52:14,595::hsm::2392::Storage.HSM::(connectStorageServer) knownSDs: {}
Thread-157::INFO::2013-10-31 21:52:14,595::logUtils::47::dispatcher::(wrapper) Run and protect: connectStorageServer, Return response: {'statuslist': [{'status': 0, 'id': '00000000-0000-0000-0000-000000000000'}]}
Thread-157::DEBUG::2013-10-31 21:52:14,595::task::1168::TaskManager.Task::(prepare) Task=`ced26482-8314-47d6-b63d-20cdf5692a5d`::finished: {'statuslist': [{'status': 0, 'id': '00000000-0000-0000-0000-000000000000'}]}
Thread-157::DEBUG::2013-10-31 21:52:14,596::task::579::TaskManager.Task::(_updateState) Task=`ced26482-8314-47d6-b63d-20cdf5692a5d`::moving from state preparing -> state finished
Thread-157::DEBUG::2013-10-31 21:52:14,596::resourceManager::939::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {}
Thread-157::DEBUG::2013-10-31 21:52:14,596::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {}
Thread-157::DEBUG::2013-10-31 21:52:14,596::task::974::TaskManager.Task::(_decref) Task=`ced26482-8314-47d6-b63d-20cdf5692a5d`::ref 0 aborting False
Thread-160::DEBUG::2013-10-31 21:52:14,696::BindingXMLRPC::177::vds::(wrapper) client [10.70.34.114] flowID [5785744e]
Thread-160::DEBUG::2013-10-31 21:52:14,697::task::579::TaskManager.Task::(_updateState) Task=`9566df42-c847-4c6c-9d67-00baa0dba466`::moving from state init -> state preparing
Thread-160::INFO::2013-10-31 21:52:14,697::logUtils::44::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=7, spUUID='00000000-0000-0000-0000-000000000000', conList=[{'port': '', 'connection': 'fillmore.lab.eng.blr.redhat.com:phase1', 'iqn': '', 'portal': '', 'user': '', 'vfs_type': 'glusterfs', 'password': '******', 'id': '72fa820f-1c70-4ef5-bdd2-9ee2292c2097'}], options=None)
Thread-160::DEBUG::2013-10-31 21:52:14,699::hsm::2324::Storage.HSM::(__prefetchDomains) glusterDomPath: glusterSD/*
Thread-160::DEBUG::2013-10-31 21:52:14,706::hsm::2336::Storage.HSM::(__prefetchDomains) Found SD uuids: ()
Thread-160::DEBUG::2013-10-31 21:52:14,706::hsm::2392::Storage.HSM::(connectStorageServer) knownSDs: {}
Thread-160::INFO::2013-10-31 21:52:14,706::logUtils::47::dispatcher::(wrapper) Run and protect: connectStorageServer, Return response: {'statuslist': [{'status': 0, 'id': '72fa820f-1c70-4ef5-bdd2-9ee2292c2097'}]}
Thread-160::DEBUG::2013-10-31 21:52:14,707::task::1168::TaskManager.Task::(prepare) Task=`9566df42-c847-4c6c-9d67-00baa0dba466`::finished: {'statuslist': [{'status': 0, 'id': '72fa820f-1c70-4ef5-bdd2-9ee2292c2097'}]}
Thread-160::DEBUG::2013-10-31 21:52:14,707::task::579::TaskManager.Task::(_updateState) Task=`9566df42-c847-4c6c-9d67-00baa0dba466`::moving from state preparing -> state finished
Thread-160::DEBUG::2013-10-31 21:52:14,707::resourceManager::939::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {}
Thread-160::DEBUG::2013-10-31 21:52:14,707::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {}
Thread-160::DEBUG::2013-10-31 21:52:14,707::task::974::TaskManager.Task::(_decref) Task=`9566df42-c847-4c6c-9d67-00baa0dba466`::ref 0 aborting False
Thread-162::DEBUG::2013-10-31 21:52:14,714::BindingXMLRPC::177::vds::(wrapper) client [10.70.34.114] flowID [5785744e]
---------------------------------------------------------

--- Additional comment from R P Herrold on 2013-11-13 10:59:26 EST ---

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?

--- Additional comment from Ayal Baron on 2013-11-18 07:05:47 EST ---

Sean, Itamar, note that I've targeted this for 3.1.z

--- Additional comment from Cheryn Tan on 2013-11-24 19:05:07 EST ---

Eduardo, Arthur,

This bug has been proposed for inclusion in the RHEV 3.3 release notes. To ensure accurate documentation of the issue, please do the following: 
(a) Set the Doc Type to 'Release Note' 
(b) Fill in the Doc Text field with a short description of the bug, expected behaviour, and any workarounds.

If you think that this bug does not need to be documented, please cancel the needinfo and add "--no doc text required" to the Doc Text field.

Thank you,
Cheryn

--- Additional comment from Ayal Baron on 2014-02-19 04:47:44 EST ---

1. We have multiple issues with Gluster stability at the moment (regardless of libgfapi support)
2. libgfapi support in libvirt is not merged yet and hasn't been tested and will add more instability
3. support for this needs to be added in vdsm and it's not yet clear how.
Considering the above, not sure this can make it into 3.5 so cond nacking it.

--- Additional comment from Vijay Bellur on 2014-02-19 04:50:16 EST ---

(In reply to Ayal Baron from comment #11)
> 1. We have multiple issues with Gluster stability at the moment (regardless
> of libgfapi support)

Can you please elaborate more on the issues that seem to affect Gluster stability?

--- Additional comment from Ayal Baron on 2014-02-19 07:57:55 EST ---

(In reply to Vijay Bellur from comment #12)
> (In reply to Ayal Baron from comment #11)
> > 1. We have multiple issues with Gluster stability at the moment (regardless
> > of libgfapi support)
> 
> Can you please elaborate more on the issues that seem to affect Gluster
> stability?

Federico is investigating with you afaik.
He had 3 way replication, simulated a host going down (everything went well) then when host came back up (after it was out of sync) client started to get I/O errors (instead of going on working against the 2 valid hosts) and auto heal did not take place.
Even after we resolve these issues, we need to go on testing and get more confidence before we rely on more features that can introduce more instability (namely libgfapi, since the libvirt changes there are pretty extensive as well as changing how we work with gluster with which we need to gain more confidence before relying on it).

--- Additional comment from Sean Cohen on 2014-06-11 05:04:04 EDT ---

Allon,
As we finally seem to have good progress on the blocking RFEs please assign it so we can start to look at the patches

Thanks
Sean

--- Additional comment from Sean Cohen on 2014-06-11 11:17:02 EDT ---

Pushing out to 3.6 as blocking bug 1017289 got pushed to rhel 6.7
Sean

--- Additional comment from Sandro Bonazzola on 2015-04-23 07:50:54 EDT ---

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

--- Additional comment from Sandro Bonazzola on 2015-04-24 08:09:43 EDT ---

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.

--- Additional comment from Sandro Bonazzola on 2015-04-30 02:43:57 EDT ---



--- Additional comment from Yaniv Lavi (Dary) on 2015-07-16 00:07:47 EDT ---

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

--- Additional comment from Allon Mureinik on 2015-07-16 05:03:14 EDT ---

(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 :-)

--- Additional comment from Andrejs Baulins on 2015-09-21 14:51:22 EDT ---

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?

--- Additional comment from Allon Mureinik on 2015-09-21 16:53:01 EDT ---

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

--- Additional comment from SATHEESARAN on 2015-09-21 22:50:16 EDT ---

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

--- Additional comment from Yaniv Lavi (Dary) on 2015-09-22 02:38:36 EDT ---

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

--- Additional comment from Andrejs Baulins on 2015-09-22 03:02:40 EDT ---

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

--- Additional comment from Andrejs Baulins on 2015-09-22 06:37:19 EDT ---

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

--- Additional comment from Yaniv Lavi (Dary) on 2016-03-08 05:34:35 EST ---

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.

--- Additional comment from Sahina Bose on 2016-03-31 08:44:18 EDT ---



--- Additional comment from Sahina Bose on 2016-03-31 08:56:30 EDT ---

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.

--- Additional comment from  on 2016-03-31 08:57:36 EDT ---

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

--- Additional comment from Sandro Bonazzola on 2016-05-02 05:51:04 EDT ---

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

--- Additional comment from Red Hat Bugzilla Rules Engine on 2016-05-05 08:48:11 EDT ---

Since this bug now has devel_ack+, the Devel Conditional Nak state is no longer valid and has been clear.

--- Additional comment from Yaniv Lavi (Dary) on 2016-05-23 09:14:44 EDT ---

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

--- Additional comment from Yaniv Lavi (Dary) on 2016-05-23 09:18:52 EDT ---

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

--- Additional comment from Yaniv Kaul on 2016-05-29 06:19:54 EDT ---

Moving to 4.1, as dependent bugs (on qemu-kvm and libvirt) are targeted for 7.3.

--- Additional comment from  on 2016-05-29 16:38:47 EDT ---

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.

--- Additional comment from Bronce McClain on 2016-09-21 09:46:37 EDT ---

Yaniv, do you know who can review this?

--- Additional comment from Yaniv Lavi (Dary) on 2016-09-22 03:54:58 EDT ---

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

--- Additional comment from Bronce McClain on 2017-05-24 20:44:34 EDT ---

ovirt-4.1.2 has been released, this is being re-targeted to ovirt-4.1.3

--- Additional comment from SATHEESARAN on 2017-08-21 09:45:11 EDT ---

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.