[Gluster-users] upgrading from gluster-3.2.6 to gluster-3.4.2

[Dmitry Kopelevich]

Vijay,

Thanks for the response. I don't think I had the /var/lib/glusterd 
directory before installing the RPMs (unless this directory would be 
created by the 3.2.x version).

I think my problem is indeed related to IPoIB. I have it set up but in 
the gluster set up I used hostnames corresponding to an ethernet 
connection, not IB. Is there a simple method to change the names for the 
server nodes in the gluster configuration?

Thanks,

Dmitry

Dmitry Kopelevich
Associate Professor
Chemical Engineering Department
University of Florida
Gainesville, FL 32611

Phone:   (352)-392-4422
Fax:     (352)-392-9513
E-mail:  dkopelevich at che.ufl.edu

On 02/24/2014 11:40 AM, Vijay Bellur wrote:
> On 02/19/2014 01:21 AM, Dmitry Kopelevich wrote:
>
>>
>> According to the installation guidelines, installation from rpms should
>> automatically copy the files from /etc/glusterd to /var/lib/glusterd.
>> This didn't happen for me -- the directory /var/lib/glusterd contained
>> only empty subdirectories. But the content of /etc/glusterd directory
>> has moved to /etc/glusterd/glusterd.
>
> Did /var/lib/glusterd per chance exist before installing the RPMs? If 
> it does, then contents of /etc/glusterd do not get copied over to 
> /var/lib/glusterd.
>
>>
>> So, I decided to manually copy files from /etc/glusterd/glusterd to
>> /var/lib/glusterd and follow step 5 of the installation guidelines
>> (which was supposed to be skipped when installing from rpms):
>>
>> glusterd --xlator-option *.upgrade=on -N
>>
>> This didn't work (error message: glusterd: No match)
>>
>> Then I triedspecifying explicitly the name of my volume:
>>
>> glusterd --xlator-option <volume>.upgrade=on -N
>>
>> This lead to the following messages in file 
>> etc-glusterfs-glusterd.vol.log:
>>
>> [2014-02-18 17:22:27.146449] I [glusterd.c:961:init] 0-management: Using
>> /var/lib/glusterd as working directory
>> [2014-02-18 17:22:27.149097] I [socket.c:3480:socket_init]
>> 0-socket.management: SSL support is NOT enabled
>> [2014-02-18 17:22:27.149126] I [socket.c:3495:socket_init]
>> 0-socket.management: using system polling thread
>> [2014-02-18 17:22:29.282665] I
>> [glusterd-store.c:1339:glusterd_restore_op_version] 0-glusterd:
>> retrieved op-version: 1
>> [2014-02-18 17:22:29.283478] E
>> [glusterd-store.c:1858:glusterd_store_retrieve_volume] 0-: Unknown key:
>> brick-0
>> [2014-02-18 17:22:29.283513] E
>> [glusterd-store.c:1858:glusterd_store_retrieve_volume] 0-: Unknown key:
>> brick-1
>> [2014-02-18 17:22:29.283534] E
>> [glusterd-store.c:1858:glusterd_store_retrieve_volume] 0-: Unknown key:
>> brick-2
>> ...
>> and so on for all other bricks.
>
> These messages related to bricks are benign and can be ignored.
>
>>
>> After that, files nfs.log, glustershd.log, and
>> etc-glusterfs-glusterd.vol.log get filled with a large number of warning
>> messages and nothing else seems to happen. The following messages appear
>> to be relevant:
>>
>> - Files nfs.log, glustershd.log:
>>
>> 2014-02-18 15:58:01.889847] W [rdma.c:1079:gf_rdma_cm_event_handler]
>> 0-data-volume-client-2: cma event RDMA_CM_EVENT_ADDR_ERROR, error -2
>> (me: peer:)
>
> Do you also have IPoIB in your setup? RDMA-CM in 3.4.x releases does 
> need IPoIB to function properly. [1]
>
> Raghavendra - can you please help here?
>
>>
>> (the name of my volume is data-volume and its transport type is RDMA)
>>
>> - File etc-glusterfs-glusterd.vol.log
>>
>> [2014-02-18 17:22:33.322565] W [socket.c:514:__socket_rwv] 0-management:
>> readv failed (No data available)
>>
>> Also, for some reason the time stamps in the log files are incorrect.
>
> Starting with 3.4, time stamps in the log files are in UTC by default.
>
> Thanks,
> Vijay
>
> [1] 
> https://github.com/gluster/glusterfs/blob/master/doc/features/rdma-cm-in-3.4.0.txt