10:33 a.m.
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.ov...
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--