7:40 a.m.
This is a multi-part message in MIME format.
--------------0D0952143881FE6C964E43BB
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Hello,
I'm using the DNS Balancing gluster hostname for years now, not only
with ovirt. No software so far had a problem. And setting the hostname
to only one Host of course breaks one advantage of a
distributed/replicated Cluster File-System like loadbalancing the
connections to the storage and/or failover if one host is missing. In
earlier ovirt it wasn't possible to specify something like
"backupvolfile-server" for a High-Available hosted-engine rollout (which
I use).
I already used live migration in such a setup. This was done with pure
libvirt setup/virsh and later using OpenNebula.
Bye
Am 25.08.2017 um 13:11 schrieb Denis Chaplygin:
Hello!
On Fri, Aug 25, 2017 at 11:05 AM, Ralf Schenk <rs(a)databay.de
<mailto:rs@databay.de>> wrote:
I replayed migration (10:38:02 local time) and recorded vdsm.log
of source and destination as attached. I can't find anything in
the gluster logs that shows an error. One information: my FQDN
glusterfs.rxmgmt.databay.de <http://glusterfs.rxmgmt.databay.de>
points to all the gluster hosts:
glusterfs.rxmgmt.databay.de <http://glusterfs.rxmgmt.databay.de>;.
84600 IN A 172.16.252.121
glusterfs.rxmgmt.databay.de <http://glusterfs.rxmgmt.databay.de>;.
84600 IN A 172.16.252.125
glusterfs.rxmgmt.databay.de <http://glusterfs.rxmgmt.databay.de>;.
84600 IN A 172.16.252.127
glusterfs.rxmgmt.databay.de <http://glusterfs.rxmgmt.databay.de>;.
84600 IN A 172.16.252.122
glusterfs.rxmgmt.databay.de <http://glusterfs.rxmgmt.databay.de>;.
84600 IN A 172.16.252.124
glusterfs.rxmgmt.databay.de <http://glusterfs.rxmgmt.databay.de>;.
84600 IN A 172.16.252.123
glusterfs.rxmgmt.databay.de <http://glusterfs.rxmgmt.databay.de>;.
84600 IN A 172.16.252.126
glusterfs.rxmgmt.databay.de <http://glusterfs.rxmgmt.databay.de>;.
84600 IN A 172.16.252.128
I double checked all gluster hosts. They all are configured the
same regarding "option rpc-auth-allow-insecure on" No iptables
rules on the host.
Do you use 'glusterfs.rxmgmt.databay.de
<http://glusterfs.rxmgmt.databay.de>" as a storage domain host name?
I'm not a gluster guru, but i'm afraid that some internal gluster
client code may go crazy, when it receives different address or
several ip addresses every time. Is it possible to try with separate
names? You can create a storage domain using 172.16.252.121 for
example and it should work bypassing your DNS. If it is possible to
make that, could you please do that and retry live migration?
--
*Ralf Schenk*
fon +49 (0) 24 05 / 40 83 70
fax +49 (0) 24 05 / 40 83 759
mail *rs(a)databay.de* <mailto:rs@databay.de>
*Databay AG*
Jens-Otto-Krag-Straße 11
D-52146 Würselen
*www.databay.de* <http://www.databay.de>
Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202
Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm.
Philipp Hermanns
Aufsichtsratsvorsitzender: Wilhelm Dohmen
------------------------------------------------------------------------
--------------0D0952143881FE6C964E43BB
Content-Type: multipart/related;
boundary="------------8175539110BE9D6A1EBCBC6A"
--------------8175539110BE9D6A1EBCBC6A
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font face="Helvetica, Arial, sans-serif">Hello,<br>
</font></p>
<p><font face="Helvetica, Arial, sans-serif">I'm using the
DNS Balancing
gluster hostname for years now, not only with ovirt. No software
so far had a problem. And setting the hostname to only one Host
of course breaks one advantage of a distributed/replicated
Cluster File-System like loadbalancing the connections to the
storage and/or failover if one host is missing. In earlier ovirt
it wasn't possible to specify something like "backupvolfile-server"
for a High-Available hosted-engine rollout (which I use).</font></p>
<p><font face="Helvetica, Arial, sans-serif">I already used
live
migration in such a setup. This was done with pure libvirt
setup/virsh and later using OpenNebula.</font></p>
<p><font face="Helvetica, Arial, sans-serif">Bye<br>
</font></p>
<p><font face="Helvetica, Arial,
sans-serif"></font><br>
</p>
<br>
<div class="moz-cite-prefix">Am 25.08.2017 um 13:11 schrieb Denis
Chaplygin:<br>
</div>
<blockquote type="cite"
cite="mid:CANVzE5=mWyKDxjX9e+B2BCGvZ8CHSVPPuuzXMvSNM=24UzBbNw@mail.gmail.com">
<div dir="ltr">Hello!
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Aug 25, 2017 at 11:05 AM,
Ralf Schenk <span dir="ltr"><<a
href="mailto:rs@databay.de" target="_blank"
moz-do-not-send="true">rs(a)databay.de</a>&gt;</span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><br>
I replayed migration (10:38:02 local time) and recorded
vdsm.log of source and destination as attached. I can't
find anything in the gluster logs that shows an error.
One information: my FQDN <a
href="http://glusterfs.rxmgmt.databay.de"
target="_blank"
moz-do-not-send="true">glusterfs.rxmgmt.databay.de</a>
points to all the gluster hosts:<br>
<br>
<a href="http://glusterfs.rxmgmt.databay.de"
target="_blank"
moz-do-not-send="true">glusterfs.rxmgmt.databay.de</a>.
84600 IN A 172.16.252.121<br>
<a href="http://glusterfs.rxmgmt.databay.de"
target="_blank"
moz-do-not-send="true">glusterfs.rxmgmt.databay.de</a>.
84600 IN A 172.16.252.125<br>
<a href="http://glusterfs.rxmgmt.databay.de"
target="_blank"
moz-do-not-send="true">glusterfs.rxmgmt.databay.de</a>.
84600 IN A 172.16.252.127<br>
<a href="http://glusterfs.rxmgmt.databay.de"
target="_blank"
moz-do-not-send="true">glusterfs.rxmgmt.databay.de</a>.
84600 IN A 172.16.252.122<br>
<a href="http://glusterfs.rxmgmt.databay.de"
target="_blank"
moz-do-not-send="true">glusterfs.rxmgmt.databay.de</a>.
84600 IN A 172.16.252.124<br>
<a href="http://glusterfs.rxmgmt.databay.de"
target="_blank"
moz-do-not-send="true">glusterfs.rxmgmt.databay.de</a>.
84600 IN A 172.16.252.123<br>
<a href="http://glusterfs.rxmgmt.databay.de"
target="_blank"
moz-do-not-send="true">glusterfs.rxmgmt.databay.de</a>.
84600 IN A 172.16.252.126<br>
<a href="http://glusterfs.rxmgmt.databay.de"
target="_blank"
moz-do-not-send="true">glusterfs.rxmgmt.databay.de</a>.
84600 IN A 172.16.252.128<br>
<br>
I double checked all gluster hosts. They all are
configured the same regarding "<tt>option
rpc-auth-allow-insecure on</tt>" No iptables rules on
the host.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Do you use '<a
href="http://glusterfs.rxmgmt.databay.de"
moz-do-not-send="true">glusterfs.rxmgmt.databay.de</a>"
as a storage domain host name? I'm not a gluster guru, but
i'm afraid that some internal gluster client code may go
crazy, when it receives different address or several ip
addresses every time. Is it possible to try with separate
names? You can create a storage domain using
172.16.252.121 for example and it should work bypassing
your DNS. If it is possible to make that, could you please
do that and retry live migration?</div>
</div>
</div>
</div>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<p>
</p>
<table cellspacing="0" cellpadding="0"
border="0">
<tbody>
<tr>
<td colspan="3"><img
src="cid:part12.39ADF8E4.CC33E9E4@databay.de"
height="30" width="151"
border="0"></td>
</tr>
<tr>
<td valign="top"> <font size="-1"
face="Verdana, Arial,
sans-serif"><br>
<b>Ralf Schenk</b><br>
fon +49 (0) 24 05 / 40 83 70<br>
fax +49 (0) 24 05 / 40 83 759<br>
mail <a href="mailto:rs@databay.de"><font
color="#FF0000"><b>rs(a)databay.de</b></font></a><br>
</font> </td>
<td width="30"> </td>
<td valign="top"> <font size="-1"
face="Verdana, Arial,
sans-serif"><br>
<b>Databay AG</b><br>
Jens-Otto-Krag-Straße 11<br>
D-52146 Würselen<br>
<a href="http://www.databay.de"><font
color="#FF0000"><b>www.databay.de</b></font></a>
</font> </td>
</tr>
<tr>
<td colspan="3" valign="top"> <font
size="1" face="Verdana,
Arial, sans-serif"><br>
Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE
210844202<br>
Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch
Yavari, Dipl.-Kfm. Philipp Hermanns<br>
Aufsichtsratsvorsitzender: Wilhelm Dohmen </font> </td>
</tr>
</tbody>
</table>
<hr noshade="noshade" size="1" color="#000000"
width="100%">
</div>
</body>
</html>
--------------8175539110BE9D6A1EBCBC6A
Content-Type: image/gif;
name="gaaiceogelpgnhae.gif"
Content-Transfer-Encoding: base64
Content-ID: <part12.39ADF8E4.CC33E9E4(a)databay.de>
Content-Disposition: inline;
filename="gaaiceogelpgnhae.gif"
R0lGODlhlwAeAMQAAObm5v9QVf/R0oKBgfDw8NfX105MTLi3t/r6+sfHx/+rrf98gC0sLP8L
EhIQEKalpf/g4ZmYmHd2dmppaf8uNP/y8v8cIv+Ym//AwkE/P46NjRwbG11cXP8ABwUDA///
/yH5BAAAAAAALAAAAACXAB4AAAX/4CeOYnUJZKqubOu+cCzPNA0tVnfVfO//wGAKk+t0Ap+K
QMFUYCDCqHRKJVUWDaPRUsFktZ1G4AKtms9o1gKsFVS+7I5ll67bpd647hPQawNld4KDMQJF
bA07F35aFBiEkJEpfXEBjx8KjI0Vkp2DEIdaCySgFBShbEgrCQOtrq+uEQcALQewrQUjEbe8
rgkkD7y5KhMZB3drqSoVFQhdlHGXKQYe1dbX2BvHKwzY1RMiAN7j1xEjBeTmKeIeD3cYCxRf
FigvChRxFJwkBBvk5A7cpZhAjgGCDwn+kfslgto4CSoSehh2BwEEBQvowDAUR0EKdArHZTg4
4oDCXBFC/3qj9SEluZEpHnjYQFIGgpo1KgSasYjNKBImrzF4NaFbNgIjCGRQeIyVKwneOLzS
cLCAg38OWI4Y4GECgQcSOEwYcADnh6/FNjAwoGFYAQ0atI4AAFeEFwsLFLiJUQEfGH0kNGAD
x8+oNQdIRQg+7NCaOhIgD8sVgYADNsPVGI5YWjRqzQTdHDDIYHRDLokaUhCglkFEJi0NKJhl
0RP2TsvXUg88KiLBVWsZrF6DmMKlNYMqglqTik1guN8OBgAgkGCpB+L9ugK4iSCBvwEfECw1
kILrBpa1jVCQIQBRvbP+rlEcQVAoSevWyv6uhpwE12uEkQAAZucpVw1xIsjkgf8B863mQVYt
eQATCZYJZJ5WBfij2wfpHcEeHGG8Z+BMszVWDXkfKLhceJhBSAJ+1ThH32AfRFZNayNAtUFi
wFSTSwEHJIYAAQU84IADwyjIEALU9MchG+vFgIF7W2GDI2T7HfjBgNcgKQKMHmwjgnCSpeCb
ULRkdxhF1CDY40RjgmUAA/v1J5FAKW2gGSZscBFDMraNgJs1AYpAAGYP5jJoNQ4Y4Gh8jpFg
HH9mgbmWo1l6oA4C3Ygp6UwEIFBfNRtkMIBlKMLnAXgAXLWhXXH85EIFqMhGGZgDEKArABGA
ed0HI4bk5qgnprCYSt88B6dqS0FEEAMPJDCdCJYViur/B1BlwGMJqDTwnhqxJgUpo0ceOQ4D
0yEakpMm/jqCRMgWm2I1j824Y6vLvuuPjHnqOJkIgP6xzwp5sCFNsCFp88Gxh11lrjfDcNrc
CEx64/CD3iAHlQcMUEQXvcA+qBkBB4Q2X1CusjBlJdKMYAKI6g28MbKN5hJsBAXknHOwutn4
oFYqkpqAzjnPbE0u1PxmwAQGXLWBbvhuIIEGEnRjlAHO4SvhbCNAkwoGzEBwgV9U0lfu2WiX
OkDEGaCdKgl0nk2YkWdPOCDabvaGdkAftL1LlgwCM+7Tq11V71IO7LkM2XE0YAHMYMhqqK6U
V165CpaHukLmiXFO8XSVzzakX+UH6TrmAajPNxfqByTQec41AeBPvSwIALkmAnuiexCsca3C
BajgfsROuxcPA8kHQJX4DAIwjnsAvhsvfXHWKEwDAljg7sj03L9wwAQTxOWD2AE0YP75eCkw
cPfs+xACADs=
--------------8175539110BE9D6A1EBCBC6A--
--------------0D0952143881FE6C964E43BB--