<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>