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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20170609/e33a3144/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: glusterd.log Type: application/octet-stream Size: 2931834 bytes Desc: glusterd.log URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20170609/e33a3144/attachment-0001.obj>
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 at ventura.org> 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 at gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20170612/215d770e/attachment.html>
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. Sent using OWA for iPhone ________________________________ From: Atin Mukherjee <amukherj at redhat.com> Sent: Monday, June 12, 2017 4:57:08 AM To: Langley, Robert Cc: gluster-users at gluster.org 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 <Robert.Langley at ventura.org<mailto:Robert.Langley at ventura.org>> 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 at gluster.org<mailto:Gluster-users at gluster.org> http://lists.gluster.org/mailman/listinfo/gluster-users -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20170612/a3249019/attachment-0001.html>