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@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@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@databay.de</a>></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@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@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--