This is a multi-part message in MIME format. --------------B0702B281B4003762AC9D2BF Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 22/08/2016 à 08:10, Ramesh Nachimuthu a écrit :
Now, I can smoothly configure their NICs.
Doing all this, I saw that oVirt detected there already was existing gluster cluster and volume, and integrated it in oVirt.
Then, I was able to create a new storage domain in this new DC and cluster, using one of the *gluster* FQDN's host. It went nicely.
BUT, when viewing the volume tab and brick details, the displayed brick names are the host DNS name, and NOT the host GLUSTER DNS names.
I'm worrying about this, confirmed by what I read in the logs :
2016-08-19 14:46:30,484 WARN [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc] (DefaultQuartzScheduler_Worker-100) [107dc2e3] Could not associate brick 'serv-vm-al04-data.sdis.isere.fr:/gluster/data/brick04 ' of volume '35026521-e76e-4774-8ddf-0a701b9eb40c' with correct network as no gluster network found in cluster '1c8e75a0-af3f-4e97-a8fb-2f7ef3ed9f30' 2016-08-19 14:46:30,492 WARN [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc] (DefaultQuartzScheduler_Worker-100) [107dc2e3] Could not associate brick 'serv-vm-al05-data.sdis.isere.fr:/gluster/data/brick04 ' of volume '35026521-e76e-4774-8ddf-0a701b9eb40c' with correct network as no gluster network found in cluster '1c8e75a0-af3f-4e97-a8fb-2f7ef3ed9f30' 2016-08-19 14:46:30,500 WARN [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc] (DefaultQuartzScheduler_Worker-100) [107dc2e3] Could not associate brick 'serv-vm-al06-data.sdis.isere.fr:/gluster/data/brick04 ' of volume '35026521-e76e-4774-8ddf-0a701b9eb40c' with correct network as no gluster network found in cluster '1c8e75a0-af3f-4e97-a8fb-2f7ef3ed9f30'
[oVirt shell (connected)]# list clusters
id : 00000001-0001-0001-0001-000000000045 name : cluster51 description: Cluster d'alerte de test
id : 1c8e75a0-af3f-4e97-a8fb-2f7ef3ed9f30 name : cluster52 description: Cluster d'alerte de test
[oVirt shell (connected)]#
"cluster52" is the recent cluster, and I do have a dedicated gluster network, marked as gluster network, in the correct DC and cluster. The only point is that : - Each host has its name ("serv-vm-al04") and a second name for gluster ("serv-vm-al04-data"). - Using blahblahblah-data is correct on a gluster point of view - Maybe oVirt is disturb not to be able to ping the gluster FQDN (not routed) and then throwing this error?
We do have a limitation currently that if you use multiple FQDNs, oVirt cannot associate it to the gluster brick correctly. This will be a problem only when you try brick management from oVirt - i.e try to remove or replace brick from oVirt. For monitoring brick status and detecting bricks - this is not an issue, and you can ignore the error in logs.
Hi Sahina and Ramesh, what you wrote looks a lot the same at what I witnessed ("oVirt cannot associate it to the gluster brick correctly") : oVirt is trying to associate, and succeed, but using the host FQDN, and not the host gluster FQDN. That leads to a situation where oVirt is seeing the volume correctly (name, number of bricks), but : - I can not add nor manage the bricks, as you wrote it - the size is not reported - the bricks fqdn are not correct, as we just wrote it. At present, this is not very disturbing, but one major issue I witnessed twice was that : I tried to roughly reboot a host, which at this time was only used as a gluster node, and was not running any VM. I saw my complete oVirt DC crash in flames, maybe because of a STONITH storm (some host were power managed the hard way). I still have to reproduce this issue and provide you the log files, but before going further, please tell me if it's worth it on this 3.6.7 setup, or must I first upgrade to 4.xx ?
Adding Ramesh who has a patch to fix this .
Patch https://gerrit.ovirt.org/#/c/60083/ is posted to address this issue. But it will work only if the oVirt Engine can resolve FQDN *'serv-vm-al04-data.xx*'* to an IP address which is mapped to the gluster NIC (NIC with gluster network) on the host. -- Nicolas ECARNOT
--------------B0702B281B4003762AC9D2BF Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">Le 22/08/2016 à 08:10, Ramesh Nachimuthu a écrit :<br> </div> <blockquote cite="mid:9b03bd60-2542-e51a-7392-a7e76bcc6a56@redhat.com" type="cite"> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> <br> <blockquote cite="mid:CACjzOvfM4kju4oWrpw2Lxbc7Kf3-OU8J2ErkxrgBKmcYEZEh6Q@mail.gmail.com" type="cite"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div bgcolor="#FFFFFF" text="#000000"> Now, I can smoothly configure their NICs.<br> <br> Doing all this, I saw that oVirt detected there already was existing gluster cluster and volume, and integrated it in oVirt.<br> <br> Then, I was able to create a new storage domain in this new DC and cluster, using one of the *gluster* FQDN's host. It went nicely.<br> <br> BUT, when viewing the volume tab and brick details, the displayed brick names are the host DNS name, and NOT the host GLUSTER DNS names.<br> <br> I'm worrying about this, confirmed by what I read in the logs :<br> <br> 2016-08-19 14:46:30,484 WARN [org.ovirt.engine.core.<wbr>vdsbroker.gluster.<wbr>GlusterVolumesListReturnForXml<wbr>Rpc] (DefaultQuartzScheduler_<wbr>Worker-100) [107dc2e3] Could not associate brick 'serv-vm-al04-data.sdis.isere.<wbr>fr:/gluster/data/brick04<br> ' of volume '35026521-e76e-4774-8ddf-<wbr>0a701b9eb40c' with correct network as no gluster network found in cluster '1c8e75a0-af3f-4e97-a8fb-<wbr>2f7ef3ed9f30'<br> 2016-08-19 14:46:30,492 WARN [org.ovirt.engine.core.<wbr>vdsbroker.gluster.<wbr>GlusterVolumesListReturnForXml<wbr>Rpc] (DefaultQuartzScheduler_<wbr>Worker-100) [107dc2e3] Could not associate brick 'serv-vm-al05-data.sdis.isere.<wbr>fr:/gluster/data/brick04<br> ' of volume '35026521-e76e-4774-8ddf-<wbr>0a701b9eb40c' with correct network as no gluster network found in cluster '1c8e75a0-af3f-4e97-a8fb-<wbr>2f7ef3ed9f30'<br> 2016-08-19 14:46:30,500 WARN [org.ovirt.engine.core.<wbr>vdsbroker.gluster.<wbr>GlusterVolumesListReturnForXml<wbr>Rpc] (DefaultQuartzScheduler_<wbr>Worker-100) [107dc2e3] Could not associate brick 'serv-vm-al06-data.sdis.isere.<wbr>fr:/gluster/data/brick04<br> ' of volume '35026521-e76e-4774-8ddf-<wbr>0a701b9eb40c' with correct network as no gluster network found in cluster '1c8e75a0-af3f-4e97-a8fb-<wbr>2f7ef3ed9f30'<br> <br> [oVirt shell (connected)]# list clusters<br> <br> id : 00000001-0001-0001-0001-<wbr>000000000045<br> name : cluster51<br> description: Cluster d'alerte de test<br> <br> id : 1c8e75a0-af3f-4e97-a8fb-<wbr>2f7ef3ed9f30<br> name : cluster52<br> description: Cluster d'alerte de test<br> <br> [oVirt shell (connected)]# <br> <br> "cluster52" is the recent cluster, and I do have a dedicated gluster network, marked as gluster network, in the correct DC and cluster.<br> The only point is that :<br> - Each host has its name ("serv-vm-al04") and a second name for gluster ("serv-vm-al04-data").<br> - Using blahblahblah-data is correct on a gluster point of view<br> - Maybe oVirt is disturb not to be able to ping the gluster FQDN (not routed) and then throwing this error?<span class="HOEnZb"><font color="#888888"><br> <br> </font></span></div> </blockquote> <div><br> </div> <div>We do have a limitation currently that if you use multiple FQDNs, oVirt cannot associate it to the gluster brick correctly. This will be a problem only when you try brick management from oVirt - i.e try to remove or replace brick from oVirt. For monitoring brick status and detecting bricks - this is not an issue, and you can ignore the error in logs.<br> </div> </div> </div> </div> </blockquote> </blockquote> <br> Hi Sahina and Ramesh,<br> <br> what you wrote looks a lot the same at what I witnessed ("oVirt cannot associate it to the gluster brick correctly") : oVirt is trying to associate, and succeed, but using the host FQDN, and not the host gluster FQDN.<br> That leads to a situation where oVirt is seeing the volume correctly (name, number of bricks), but :<br> - I can not add nor manage the bricks, as you wrote it<br> - the size is not reported<br> - the bricks fqdn are not correct, as we just wrote it.<br> <br> At present, this is not very disturbing, but one major issue I witnessed twice was that :<br> I tried to roughly reboot a host, which at this time was only used as a gluster node, and was not running any VM.<br> I saw my complete oVirt DC crash in flames, maybe because of a STONITH storm (some host were power managed the hard way).<br> I still have to reproduce this issue and provide you the log files, but before going further, please tell me if it's worth it on this 3.6.7 setup, or must I first upgrade to 4.xx ?<br> <br> <blockquote cite="mid:9b03bd60-2542-e51a-7392-a7e76bcc6a56@redhat.com" type="cite"> <blockquote cite="mid:CACjzOvfM4kju4oWrpw2Lxbc7Kf3-OU8J2ErkxrgBKmcYEZEh6Q@mail.gmail.com" type="cite"> <div dir="ltr"> <div class="gmail_extra"> <div class="gmail_quote"> <div> <br> </div> <div>Adding Ramesh who has a patch to fix this .<br> </div> </div> </div> </div> </blockquote> <br> Patch <a moz-do-not-send="true" href="https://gerrit.ovirt.org/#/c/60083/">https://gerrit.ovirt.org/#/c/60083/</a> is posted to address this issue. But it will work only if the oVirt Engine can resolve FQDN <b>'serv-vm-al04-data.xx*'</b> to an IP address which is mapped to the gluster NIC (NIC with gluster network) on the host.<br> </blockquote> -- <br> Nicolas ECARNOT<br> </body> </html> --------------B0702B281B4003762AC9D2BF--