Sharing disks typically requires that you need to coordinate their use above the disk.

So did you consider sharing a file system instead?

Members in my team have been using NetApp for their entire career and are quite used to sharing files even for databases.

And since Gluster HCI basically builds disks out of a replicated file system, why not use that directly? All they do these days is mount some parts of oVirt's 'data' volume inside the VMs as a GlusterFS. We just create a separate directory to avoid stepping on oVirt's toes and mount that on the clients, who won't see or disturb the oVirt images.

They also run persistent Docker storage on these with Gluster mounted by the daemon, so none of the Gluster stuff needs to be baked into the Docker images. Gives you HA, zero extra copying and very fast live-migrations, which are RAM content, only.

I actually added separate Glusters (not managed by oVirt) using erasure coding dispersed volumes for things not database, because the storage efficiency is much better and a lot of that data is read-mostly. These are machines that are seen as pure compute hosts to oVirt, but offer distinct gluster volumes to all types of consumers via GlusterFS (NFS or SMB would work, too).

Too bad oVirt breaks with dispersed volumes and Gluster won't support a seamless migration from 2+1 replicas+arbiter to say 7:2 dispersed volumes as you add tiplets of hosts...

If only oVirt was a product rather than only a patchwork design!

_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-leave@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/JKRIJDB6PQSIUKA3BEZ4VUERBPSEBR3K/