Re: Gluster deamon fails to start

"Langley, Robert" <Robert.Langley@xxxxxxxxxxx> · Mon, 12 Jun 2017 14:06:24 +0000

attaching the engine.log file.

From: Sahina Bose <sabose@xxxxxxxxxx>

Sent: Monday, June 12, 2017 6:49 AM

To: Atin Mukherjee

Cc: Langley, Robert; SATHEESARAN; Kasturi Narra; gluster-users@xxxxxxxxxxx

Subject: Re:  Gluster deamon fails to start

On Mon, Jun 12, 2017 at 6:41 PM, Atin Mukherjee 
<amukherj@xxxxxxxxxx> wrote:

On Mon, 12 Jun 2017 at 17:40, Langley, Robert <Robert.Langley@xxxxxxxxxxx> 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 <amukherj@xxxxxxxxxx>

Sent: Monday, June 12, 2017 4:57:08 AM

To: Langley, Robert

Cc: gluster-users@xxxxxxxxxxx

Subject: Re:  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 <Robert.Langley@xxxxxxxxxxx> 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

Gluster-users@xxxxxxxxxxx

http://lists.gluster.org/mailman/listinfo/gluster-users

Attachment:
engine.log

Description: engine.log
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-users