Right now we don't have any plan for supporting Disperse gluster volume from HCI. We have BZ to stop creating Storage Domain for such unsupported volume[1] We only recommend replica 3 or replica2 + arbiter with sharding for VM store use cases. 1. https://bugzilla.redhat.com/show_bug.cgi?id=1951894
On Wed, Apr 21, 2021 at 12:39 PM Sandro Bonazzola <sbona...@redhat.com> wrote: > > > Il giorno mar 20 apr 2021 alle ore 03:00 Thomas Hoberg <tho...@hoberg.net> > ha scritto: > >> 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... >> > > +Gobinda Das <go...@redhat.com> you may be interested joining this > discussion. > > >> >> If only oVirt was a product rather than only a patchwork design! >> > > You're welcome to help with oVirt project design and discuss with the > community the parts that you think should benefit from a re-design. > > > > > > > >> _______________________________________________ >> Users mailing list -- users@ovirt.org >> To unsubscribe send an email to users-le...@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/ >> > > > -- > > Sandro Bonazzola > > MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV > > Red Hat EMEA <https://www.redhat.com/> > > sbona...@redhat.com > <https://www.redhat.com/> > > *Red Hat respects your work life balance. Therefore there is no need to > answer this email out of your office hours. > <https://mojo.redhat.com/docs/DOC-1199578>* > > > -- Thanks, Gobinda
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/PZ6QLC5YQVL2T6MY4TW3DTCUKWBMKR6L/
