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:
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?
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.
Sergei, what about Gluster? Have you considered it? We have excellent integration with Gluster.
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.
(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).
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
*** This bug has been marked as a duplicate of bug 1134318 ***