Hi Nir,
On 02-05-2015 9:27, Nir Soffer wrote:
> On 29-04-2015 16:41, Nir Soffer wrote:
>> [...]
>> Your probably have storage issues, revealed by sanlock - it reads and
>> write to all storage domains every 10 seconds, so flaky storage will
>> cause failure to acquire a host id. Please attach to the bug these
>> logs: Hypervisor: /var/log/sanlock.log /var/log/messages
>> /var/log/glusterfs/<glusterhost>:_<volumename>.log Gluster server:
>> server logs showing what happened when sanlock failed access the
>> gluster volume.
Do you plan to provide the requested logs? Or maybe explain why they are
not needed?
I'm sorry. The sanlock issue was happening on a replica-2 volume,
not
replica-3 as we expected (our main volume).
Since replica-2 is not supported and time is valuable, we will resetup
and restart our tests.
On our lab we did really mad things like killing sanlock or just
rebooting the host, mixing replica-3 and replica-2 volumes, etc.
Any error in sanlock is not normal, and getting it constantly is bad
sign.
Good to know. We will be tracking this. This probably explains many of
the issues we had.
And the local storage on this host is used for gluster brick - right?
Yes. Is this supported? I read on BZ there was an issue with that.
Did you open a glusterfs bug for this?
Yes, but I will ask to
close it since replica-2 is not our focus and my
hypothesis that sanlock shouldn't be able to block the gluster FS was wrong:
https://bugzilla.redhat.com/show_bug.cgi?id=1217576
BTW, does oVirt work fine with a local replica-1 (no split-brains, no
other peers) gluster storage?