On Mon, Oct 21, 2013 at 11:33 AM, Vijay Bellur wrote: > The following commands might help:
Thanks for your commands. In the mean time I noticed that as I changed gluster sources to allow live migration, offsetting the port to 50152+ as in http://review.gluster.org/#/c/6075/ referred in https://bugzilla.redhat.com/show_bug.cgi?id=1018178 I missed the iptables rules that contained: # Ports for gluster volume bricks (default 100 ports) -A INPUT -p tcp -m tcp --dport 24009:24108 -j ACCEPT -A INPUT -p tcp -m tcp --dport 49152:49251 -j ACCEPT So I had some gluster communication problems too. I updated it at the moment to # Ports for gluster volume bricks (default 100 ports) -A INPUT -p tcp -m tcp --dport 24009:24108 -j ACCEPT -A INPUT -p tcp -m tcp --dport 49152:49251 -j ACCEPT -A INPUT -p tcp -m tcp --dport 50152:50251 -j ACCEPT until libvirt for fedora19 get patched as upstream (a quick test on rebuilding libvirt-1.0.5.6-3.fc19.src.rpm with the patches proposed gave many failure and in the mean time I saw that also some other parts are to be patched...) I put in iptables these lines # Ports for gluster volume bricks (default 100 ports) -A INPUT -p tcp -m tcp --dport 24009:24108 -j ACCEPT -A INPUT -p tcp -m tcp --dport 49152:49251 -j ACCEPT -A INPUT -p tcp -m tcp --dport 50152:50251 -j ACCEPT I'm going to retest completely and see how it behaves. See here for my test case and begin of problem simulation: http://lists.ovirt.org/pipermail/users/2013-October/017228.html It represents a realistic maintenance scenario that forced a manual alignment on gluster that is in my opinin not feasible.... Eventually I'm going to put into a bugzilla if new test with correct iptables ports gives problems > >> I would like to have oVirt more conscious about it and have sort of >> capability to solve itself the misalignments generated on gluster >> backend during mainteneance of a node. >> At the moment it seems to me it only shows volumes are ok in the sense >> of started, but they could be very different... >> For example another tab with details about heal info; something like >> the output of the command >> >> gluster volume heal $VOLUME info >> >> and/or >> >> gluster volume heal $VOLUME info split-brain > > > Yes, we are looking to build this for monitoring replicated gluster volumes. Good! Gianluca _______________________________________________ Announce mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/announce
