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