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>
On Mon, 12 Jun 2017 at 17:40, Langley, Robert <Robert.Langley at ventura.org> 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.> > 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> 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/e4421b09/attachment.html>
On Mon, Jun 12, 2017 at 6:41 PM, Atin Mukherjee <amukherj at redhat.com> wrote:> > On Mon, 12 Jun 2017 at 17:40, Langley, Robert <Robert.Langley at ventura.org> > 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 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> 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/1d93efbc/attachment.html>