Bug 1453112

Summary:	[RFE] Local folder as shared storage with distributed storage systems
Product:	[oVirt] ovirt-engine	Reporter:	Sergei <getallad>
Component:	BLL.Storage	Assignee:	Allon Mureinik <amureini>
Status:	CLOSED DUPLICATE	QA Contact:	Raz Tamir <ratamir>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	future	CC:	bugs, getallad, ylavi
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---	Flags:	amureini: ovirt-future? rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack?
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-11-26 14:03:58 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Sergei 2017-05-22 07:59:27 UTC

Description of problem:

There's a class of storage products on the market - distributed storage. These products are able to create shared storage, presented as a local mount point to hypervisor. The problem is that currently ovirt supports local storage only in a non-cluster mode, where each server is on its own. But with these new products it is no longer mandatory, that if storage is a local mount point, it is not shared.

Would it be possible to reconsider storage solution, and permit having local mount point as a shared storage for cluster?

Product examples can be Maxta, Quobyte, Storpool and many others - most of them developed Linux driver, allowing to mount their distributed storage as a local folder.

P.S. I do not represent any of these storage companies, but, as a system integrator, I would like to be able to use such type of storage in our solutions. Hopefully, it will be interesting not only for us.

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


How reproducible:

When configuring local storage on server, this server is placed in separate datacenter.

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:

System would allow to create a cluster with local folder as shared storage.

Additional info:

Comment 1 Allon Mureinik 2017-05-22 10:59:45 UTC

This is a long outstanding goal for us. To make a long story short, allowing truly local storage in a shared DC means breaking the assumption that all hosts in the DC can see all the domains.

For this usecase, I'm not sure that "local storage", as it's defined in oVirt nowadays, is the right way to go.
Would you be able to mount such domains as a POSIXFS domain?

Comment 2 Sergei 2017-05-22 11:49:28 UTC

Yes, most such vendors declare POSIX-compatibility when mounting their backend storage on server.
Others (like Storpool) present local block device, which can be mounted and formatted with any fs.

Comment 3 Yaniv Kaul 2017-05-23 12:58:08 UTC

Sergei, what about Gluster? Have you considered it? We have excellent integration with Gluster.

Comment 4 Sergei 2017-05-23 13:13:47 UTC

Yaniv, thank you for your comment.
Yes, I'm aware of Gluster, although, its performance for virtual environment  (random IO) is not always good enough. That's why other storage systems need to be considered.

Comment 5 Yaniv Kaul 2017-05-23 14:28:06 UTC

(In reply to Sergei from comment #4)
> Yaniv, thank you for your comment.
> Yes, I'm aware of Gluster, although, its performance for virtual environment
> (random IO) is not always good enough. That's why other storage systems need
> to be considered.

Interesting - which version have you tested? With recent versions certain features have improved performance, from sharding to use dm-cache.
We are also working on libgfapi support, which should help as well
(BTW, I'd move the conversation to the oVirt users mailing list - you may get more information there on how to optimize Gluster for your use case).

Comment 6 Sergei 2017-05-23 14:42:34 UTC

You are right, this is not place for a conversation about how to improve Gluster :)

Although, with this RFE I just wanted to point out, that there's something to improve, and it's up to the development team whether to take this into account

Comment 7 Yaniv Lavi 2017-11-26 14:03:58 UTC


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