<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">For a somewhat dissenting opinion, I have a (currently) 2 node gluster/compute system with a self hosted engine running and a 2nd cluster of 3 hosts sharing the gluster servers from the first just fine in production and a 3 node dev system. On top of ZFS even :)<div class=""><br class=""></div><div class="">That said, I’ve broken it several times and had interesting experiences fixing it. There are also 2 bugs out there that I’d consider blockers for production use of gluster server/hosts with ovirt. In particular: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1172905" class="">Bug 1172905</a> (gluster vms pause when vdsmd restarted) in combination with <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1158108" class="">1158108</a> (vddm leaks small amounts of memory) mean you have to be careful not to run out of ram on a gluster serer/host node or you pause some VMs and have to restart them to recover. I was already running this when this surfaced in 3.5, so I’m limping along, but I wouldn’t setup this config or use gluster in a new deployment right now. Side note, afaict this doesn’t freeze VMs mounted via NFS from a gluster server, so you can do that (and I’m working on migrating to it). And I currently have Fencing disabled because it can be ugly on a gluster system. The new arguments to prevent fencing if part of the cluster is down should work around this, I’m just waiting until my 3rd gluster node is online before going back to that.</div><div class=""><br class=""></div><div class="">Ovirt won’t help you understand the best way to deploy your gluster bricks either. For instance, your hosted engine should be on a brick by itself, with n-way replication across any hosted engine servers. Your VMs should probably be on a distributed-replicated or the newly available dispersed mode volume to get the benefits of multiple servers and not have to write to every brick all the time (unless your use case demands 4 copies of your data for redundancy). Allocate extra RAM for caching, too, it helps a lot. Proper setup of the server name and use of localhost mounts, cddb, or keepalived (and an understanding of why you want that) is important too.</div><div class=""><br class=""></div><div class="">Bottom line, Gluster is complex no matter how easy the Ovirt interface makes it look. If you aren’t prepared to get down and dirty with your network file system, I wouldn't recommend this. If you are, it’s good stuff, and I’m really looking forward to libgfapi integration in Ovirt beyond the dev builds. </div><div class=""><br class=""></div><div class=""> -Darrell</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 18, 2015, at 3:06 PM, Donny D <<a href="mailto:donny@cloudspin.me" class="">donny@cloudspin.me</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class=""><div class="">
<div class=""><br class=""></div><div class="">What he said</div><div class=""><br class=""></div><div class=""><br class=""></div><div id="composer_signature" class=""><div style="font-size:85%;color:#575757" class="">Happy Connecting. Sent from my Sprint Samsung Galaxy S® 5</div></div><br class=""><br class="">-------- Original message --------<br class="">From: Scott Worthington <<a href="mailto:scott.c.worthington@gmail.com" class="">scott.c.worthington@gmail.com</a>> <br class="">Date: 02/18/2015 2:03 PM (GMT-07:00) <br class="">To: Donny D <<a href="mailto:donny@cloudspin.me" class="">donny@cloudspin.me</a>> <br class="">Subject: Re: [ovirt-users] ovirt and glusterfs setup <br class=""><br class="">> I did not have a good experience putting both gluster and virt on the same<br class="">> node. I was doing hosted engine with replicate across two nodes, and one day<br class="">> it went into split brain hell... i was never able to track down why. However<br class="">> i do have a gluster with distribute and replica setup on its own with a<br class="">> couple nodes, and it has given me zero problems in the last 60 days. It<br class="">> seems to me that gluster and virt need to stay seperate for now. Both are<br class="">> great products and both work as described, just not on the same node at the<br class="">> same time.<br class="">><br class=""><br class="">The issue, as I perceive it, is newbies find Jason Brook's blog:<br class=""> <a href="http://community.redhat.com/blog/2014/11/up-and-running-with-ovirt-3-5-part-two/" class="">http://community.redhat.com/blog/2014/11/up-and-running-with-ovirt-3-5-part-two/</a><br class=""><br class="">And then newbies think this Red Hat blog is production quality. In my<br class="">opinion, the blog how-to is okay (not really, IMHO) for a lab, but not for<br class="">production.<br class=""><br class="">Since fencing is important in oVirt, having gluster on the hosts is a no-no<br class="">since a non-responsive host could be fenced at any time -- and the engine<br class="">could fence multiple hosts (and bork a locally hosted gluster file system and<br class="">then screw up the entire gluster cluster).<br class=""><br class="">--ScottW<br class=""></div>_______________________________________________<br class="">Users mailing list<br class=""><a href="mailto:Users@ovirt.org" class="">Users@ovirt.org</a><br class="">http://lists.ovirt.org/mailman/listinfo/users<br class=""></div></blockquote></div><br class=""></div></body></html>