That did it. After detaching gsaov07 as a peer; I also had to clean out the glusterd peers folder and vols folder (/var/lib/glusterd/peers and /var/lib/glusterd/vols; for anyone else's benefit). Then, the glusterd service started successfully. I then ran gluster peer probe gsaov07.stor.local from gsaov08, which succeeded.
I did find that one error I made was from previously troubleshooting, where my bond for the stor.local network was set to mode 0, rather than mode 4. After that was corrected, the server activated and is now in "Up" status in oVirt. Thank you again for your responses. ________________________________ From: Atin Mukherjee <[email protected]> Sent: Monday, June 12, 2017 8:25 AM To: Langley, Robert Cc: Sahina Bose; SATHEESARAN; Kasturi Narra; [email protected] Subject: Re: [Gluster-users] Gluster deamon fails to start On Mon, Jun 12, 2017 at 7:30 PM, Langley, Robert <[email protected]<mailto:[email protected]>> wrote: As far as the peer status (and I now remember seeing this earlier) the issue appears to be that the host name for gsaov07 is attempting to resolve over the wrong network for gluster "ent...." and not "stor.local". So, it may be as simple as removing gsaov07 as a peer, then probing over the correct network. If gsaov07 doesn't have any volumes (bricks to be precise), that's quite safe and can be done. I'll follow up with the Engine log. Sent using OWA for iPhone ________________________________ From: Sahina Bose <[email protected]<mailto:[email protected]>> Sent: Monday, June 12, 2017 6:49:29 AM To: Atin Mukherjee Cc: Langley, Robert; SATHEESARAN; Kasturi Narra; [email protected]<mailto:[email protected]> Subject: Re: [Gluster-users] Gluster deamon fails to start On Mon, Jun 12, 2017 at 6:41 PM, Atin Mukherjee <[email protected]<mailto:[email protected]>> wrote: On Mon, 12 Jun 2017 at 17:40, Langley, Robert <[email protected]<mailto:[email protected]>> wrote: Thank you for your response. There has been no change of IP addresses. And I have tried restarting the glusterd service multiple times. I am using fully qualified names with a DNS server that has forward and reverse setup. Something I had noticed is that, with oVirt, communication is being attempted over the VM network, rather than storage network. Which is not how the bricks are defined. Not sure how to correct that. +Sas, Kasturi, Sahina - is this what expected in ovirt? You can use different n/w interface for gluster management interface by peer probing the same node with multiple addresses. But you'd still need to ensure that glusterd can communicate to the IP with which brick addresses are defined. Peer probing the multiple addresses is done via oVirt providing the logical network (with gluster role) is attached to the interface in oVirt engine. Could you provide the "gluster peer status" output from GSAov08? Also the engine.log from /var/log/ovirt-engine/engine.log of the Hosted Engine VM? Sent using OWA for iPhone ________________________________ From: Atin Mukherjee <[email protected]<mailto:[email protected]>> Sent: Monday, June 12, 2017 4:57:08 AM To: Langley, Robert Cc: [email protected]<mailto:[email protected]> Subject: Re: [Gluster-users] Gluster deamon fails to start glusterd failed to resolve addresses of the bricks. This could happen either because of glusterd was trying to resolve the address of the brick before the N/W interface was up or a change in the IP? If it's the latter then a point to note is that it's recommended that cluster should be formed using hostname otherwise if the server goes through IP change we have to change the configuration from the backend. If its the former, then this is a race condition and restarting glusterd should bring back the service up. On Fri, Jun 9, 2017 at 10:01 PM, Langley, Robert <[email protected]<mailto:[email protected]>> wrote: This is in relation to bringing up a new oVirt environment. When I was bringing up oVirt (Hosted-Engine), I had the Glusterd service stopped, since the server (I have its name as GSAoV07) was initially only going to be used to host the oVirt engine as a hypervisor (it will have Gluster volumes in the near future). I have three other servers I am using for storage. One of those three is also going to be a hypervisor and the other two are dedicated storage servers (Their names are GSA-Stor1 & GSA-Stor2). When I first deployed the engine, this server (GSAoV07) I’m having an issue with was in green status. I then added in the other server (I have it as GSAoV08), who is acting as both a Gluster server and a hypervisor. It had the red, downward arrow, for a while after I added it late at night. But, in the morning when I got into work, things switched. The GSAoV07 server ended up in a Non Operational state and the GSAov08 server is now green (Up). The hosted engine is still running on GSAov07 and it seems that the Non Operational status is due to the Gluster daemon failing. Let me know if you need logs other than the glusterd.log attached. Thank you, Robert Langley _______________________________________________ Gluster-users mailing list [email protected]<mailto:[email protected]> http://lists.gluster.org/mailman/listinfo/gluster-users
_______________________________________________ Gluster-users mailing list [email protected] http://lists.gluster.org/mailman/listinfo/gluster-users
