
This is a multi-part message in MIME format. --------------3AF71384E88C3DCBA50A18ED Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hello, setting DNS glusterfs.rxmgmt.databay.de to only one IP didn't change anything. [root@microcloud22 ~]# dig glusterfs.rxmgmt.databay.de ; <<>> DiG 9.9.4-RedHat-9.9.4-50.el7_3.1 <<>> glusterfs.rxmgmt.databay.de ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35135 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 6 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;glusterfs.rxmgmt.databay.de. IN A ;; ANSWER SECTION: glusterfs.rxmgmt.databay.de. 84600 IN A 172.16.252.121 ;; AUTHORITY SECTION: rxmgmt.databay.de. 84600 IN NS ns3.databay.de. rxmgmt.databay.de. 84600 IN NS ns.databay.de. vdsm.log still shows: 2017-08-25 14:02:38,476+0200 INFO (periodic/0) [vdsm.api] FINISH repoStats return={u'7c8deaa8-be02-4aaf-b9b4-ddc8da99ad96': {'code': 0, 'actual': True, 'version': 4, 'acquired': True, 'delay': '0.000295126', 'lastCheck': '0.8', 'valid': True}, u'2b2a44fc-f2bd-47cd-b7af-00be59e30a35': {'code': 0, 'actual': True, 'version': 0, 'acquired': True, 'delay': '0.000611748', 'lastCheck': '3.6', 'valid': True}, u'5d99af76-33b5-47d8-99da-1f32413c7bb0': {'code': 0, 'actual': True, 'version': 4, 'acquired': True, 'delay': '0.000324379', 'lastCheck': '3.6', 'valid': True}, u'a7fbaaad-7043-4391-9523-3bedcdc4fb0d': {'code': 0, 'actual': True, 'version': 0, 'acquired': True, 'delay': '0.000718626', 'lastCheck': '4.1', 'valid': True}} from=internal, task_id=ec205bf0-ff00-4fac-97f0-e6a7f3f99492 (api:52) 2017-08-25 14:02:38,584+0200 ERROR (migsrc/ffb71f79) [virt.vm] (vmId='ffb71f79-54cd-4f0e-b6b5-3670236cb497') failed to initialize gluster connection (src=0x7fd82001fc30 priv=0x7fd820003ac0): Success (migration:287) 2017-08-25 14:02:38,619+0200 ERROR (migsrc/ffb71f79) [virt.vm] (vmId='ffb71f79-54cd-4f0e-b6b5-3670236cb497') Failed to migrate (migration:429) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py", line 411, in run self._startUnderlyingMigration(time.time()) File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py", line 487, in _startUnderlyingMigration self._perform_with_conv_schedule(duri, muri) File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py", line 563, in _perform_with_conv_schedule self._perform_migration(duri, muri) File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py", line 529, in _perform_migration self._vm._dom.migrateToURI3(duri, params, flags) File "/usr/lib/python2.7/site-packages/vdsm/virt/virdomain.py", line 69, in f ret = attr(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 123, in wrapper ret = f(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 944, in wrapper return func(inst, *args, **kwargs) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1939, in migrateToURI3 if ret == -1: raise libvirtError ('virDomainMigrateToURI3() failed', dom=self) libvirtError: failed to initialize gluster connection (src=0x7fd82001fc30 priv=0x7fd820003ac0): Success One thing I noticed in destination vdsm.log: 2017-08-25 10:38:03,413+0200 ERROR (jsonrpc/7) [virt.vm] (vmId='ffb71f79-54cd-4f0e-b6b5-3670236cb497') *Alias not found for device type disk during migration at destination host (vm:4587)* 2017-08-25 10:38:03,478+0200 INFO (jsonrpc/7) [root] (hooks:108) 2017-08-25 10:38:03,492+0200 INFO (jsonrpc/7) [jsonrpc.JsonRpcServer] RPC call VM.migrationCreate succeeded in 0.51 seconds (__init__:539) 2017-08-25 10:38:03,669+0200 INFO (jsonrpc/2) [vdsm.api] START destroy(gracefulAttempts=1) from=::ffff:172.16.252.122,45736 (api:46) 2017-08-25 10:38:03,669+0200 INFO (jsonrpc/2) [virt.vm] (vmId='ffb71f79-54cd-4f0e-b6b5-3670236cb497') Release VM resources (vm:4254) 2017-08-25 10:38:03,670+0200 INFO (jsonrpc/2) [virt.vm] (vmId='ffb71f79-54cd-4f0e-b6b5-3670236cb497') Stopping connection (guestagent:430) 2017-08-25 10:38:03,671+0200 INFO (jsonrpc/2) [vdsm.api] START teardownImage(sdUUID=u'5d99af76-33b5-47d8-99da-1f32413c7bb0', spUUID=u'00000001-0001-0001-0001-0000000000b9', imgUUID=u'9c007b27-0ab7-4474-9317-a294fd04c65f', volUUID=None) from=::ffff:172.16.252.122,45736, task_id=4878dd0c-54e9-4bef-9ec7-446b110c9d8b (api:46) 2017-08-25 10:38:03,671+0200 INFO (jsonrpc/2) [vdsm.api] FINISH teardownImage return=None from=::ffff:172.16.252.122,45736, task_id=4878dd0c-54e9-4bef-9ec7-446b110c9d8b (api:52) 2017-08-25 10:38:03,672+0200 INFO (jsonrpc/2) [virt.vm] (vmId='ffb71f79-54cd-4f0e-b6b5-3670236cb497') Stopping connection (guestagent:430) Am 25.08.2017 um 14:03 schrieb Denis Chaplygin:
Hello!
On Fri, Aug 25, 2017 at 1:40 PM, Ralf Schenk <rs@databay.de <mailto:rs@databay.de>> wrote:
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).
As far as i know, backup-volfile-servers is a recommended way to keep you filesystem mountable in case of server failure. While fs is mounted, gluster will automatically provide failover. And you definitely can specify backup-volfile-servers in the storage domain configuration.
I already used live migration in such a setup. This was done with pure libvirt setup/virsh and later using OpenNebula.
Yes, but it was based on a accessing gluster volume as a mount filesystem, not directly... And i would like to exclude that from list of possible causes.
-- *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 ------------------------------------------------------------------------ --------------3AF71384E88C3DCBA50A18ED Content-Type: multipart/related; boundary="------------36006B01677FB988B30A2A2E" --------------36006B01677FB988B30A2A2E 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,</font></p> <p><font face="Helvetica, Arial, sans-serif">setting DNS glusterfs.rxmgmt.databay.de to only one IP didn't change anything.</font></p> <tt>[root@microcloud22 ~]# dig glusterfs.rxmgmt.databay.de</tt><tt><br> </tt><tt><br> </tt><tt>; <<>> DiG 9.9.4-RedHat-9.9.4-50.el7_3.1 <<>> glusterfs.rxmgmt.databay.de</tt><tt><br> </tt><tt>;; global options: +cmd</tt><tt><br> </tt><tt>;; Got answer:</tt><tt><br> </tt><tt>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35135</tt><tt><br> </tt><tt>;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 6</tt><tt><br> </tt><tt><br> </tt><tt>;; OPT PSEUDOSECTION:</tt><tt><br> </tt><tt>; EDNS: version: 0, flags:; udp: 4096</tt><tt><br> </tt><tt>;; QUESTION SECTION:</tt><tt><br> </tt><tt>;glusterfs.rxmgmt.databay.de. IN A</tt><tt><br> </tt><tt><br> </tt><tt>;; ANSWER SECTION:</tt><tt><br> </tt><tt>glusterfs.rxmgmt.databay.de. 84600 IN A 172.16.252.121</tt><tt><br> </tt><tt><br> </tt><tt>;; AUTHORITY SECTION:</tt><tt><br> </tt><tt>rxmgmt.databay.de. 84600 IN NS ns3.databay.de.</tt><tt><br> </tt><tt>rxmgmt.databay.de. 84600 IN NS ns.databay.de.</tt><tt><br> </tt><br> vdsm.log still shows:<br> <tt>2017-08-25 14:02:38,476+0200 INFO (periodic/0) [vdsm.api] FINISH repoStats return={u'7c8deaa8-be02-4aaf-b9b4-ddc8da99ad96': {'code': 0, 'actual': True, 'version': 4, 'acquired': True, 'delay': '0.000295126', 'lastCheck': '0.8', 'valid': True}, u'2b2a44fc-f2bd-47cd-b7af-00be59e30a35': {'code': 0, 'actual': True, 'version': 0, 'acquired': True, 'delay': '0.000611748', 'lastCheck': '3.6', 'valid': True}, u'5d99af76-33b5-47d8-99da-1f32413c7bb0': {'code': 0, 'actual': True, 'version': 4, 'acquired': True, 'delay': '0.000324379', 'lastCheck': '3.6', 'valid': True}, u'a7fbaaad-7043-4391-9523-3bedcdc4fb0d': {'code': 0, 'actual': True, 'version': 0, 'acquired': True, 'delay': '0.000718626', 'lastCheck': '4.1', 'valid': True}} from=internal, task_id=ec205bf0-ff00-4fac-97f0-e6a7f3f99492 (api:52)</tt><tt><br> </tt><tt>2017-08-25 14:02:38,584+0200 ERROR (migsrc/ffb71f79) [virt.vm] (vmId='ffb71f79-54cd-4f0e-b6b5-3670236cb497') failed to initialize gluster connection (src=0x7fd82001fc30 priv=0x7fd820003ac0): Success (migration:287)</tt><tt><br> </tt><tt>2017-08-25 14:02:38,619+0200 ERROR (migsrc/ffb71f79) [virt.vm] (vmId='ffb71f79-54cd-4f0e-b6b5-3670236cb497') Failed to migrate (migration:429)</tt><tt><br> </tt><tt>Traceback (most recent call last):</tt><tt><br> </tt><tt> File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py", line 411, in run</tt><tt><br> </tt><tt> self._startUnderlyingMigration(time.time())</tt><tt><br> </tt><tt> File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py", line 487, in _startUnderlyingMigration</tt><tt><br> </tt><tt> self._perform_with_conv_schedule(duri, muri)</tt><tt><br> </tt><tt> File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py", line 563, in _perform_with_conv_schedule</tt><tt><br> </tt><tt> self._perform_migration(duri, muri)</tt><tt><br> </tt><tt> File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py", line 529, in _perform_migration</tt><tt><br> </tt><tt> self._vm._dom.migrateToURI3(duri, params, flags)</tt><tt><br> </tt><tt> File "/usr/lib/python2.7/site-packages/vdsm/virt/virdomain.py", line 69, in f</tt><tt><br> </tt><tt> ret = attr(*args, **kwargs)</tt><tt><br> </tt><tt> File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 123, in wrapper</tt><tt><br> </tt><tt> ret = f(*args, **kwargs)</tt><tt><br> </tt><tt> File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 944, in wrapper</tt><tt><br> </tt><tt> return func(inst, *args, **kwargs)</tt><tt><br> </tt><tt> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1939, in migrateToURI3</tt><tt><br> </tt><tt> if ret == -1: raise libvirtError ('virDomainMigrateToURI3() failed', dom=self)</tt><tt><br> </tt><tt>libvirtError: failed to initialize gluster connection (src=0x7fd82001fc30 priv=0x7fd820003ac0): Success<br> <br> </tt><br> One thing I noticed in destination vdsm.log:<br> 2017-08-25 10:38:03,413+0200 ERROR (jsonrpc/7) [virt.vm] (vmId='ffb71f79-54cd-4f0e-b6b5-3670236cb497') <b>Alias not found for device type disk during migration at destination host (vm:4587)</b><br> 2017-08-25 10:38:03,478+0200 INFO (jsonrpc/7) [root] (hooks:108)<br> 2017-08-25 10:38:03,492+0200 INFO (jsonrpc/7) [jsonrpc.JsonRpcServer] RPC call VM.migrationCreate succeeded in 0.51 seconds (__init__:539)<br> 2017-08-25 10:38:03,669+0200 INFO (jsonrpc/2) [vdsm.api] START destroy(gracefulAttempts=1) from=::ffff:172.16.252.122,45736 (api:46)<br> 2017-08-25 10:38:03,669+0200 INFO (jsonrpc/2) [virt.vm] (vmId='ffb71f79-54cd-4f0e-b6b5-3670236cb497') Release VM resources (vm:4254)<br> 2017-08-25 10:38:03,670+0200 INFO (jsonrpc/2) [virt.vm] (vmId='ffb71f79-54cd-4f0e-b6b5-3670236cb497') Stopping connection (guestagent:430)<br> 2017-08-25 10:38:03,671+0200 INFO (jsonrpc/2) [vdsm.api] START teardownImage(sdUUID=u'5d99af76-33b5-47d8-99da-1f32413c7bb0', spUUID=u'00000001-0001-0001-0001-0000000000b9', imgUUID=u'9c007b27-0ab7-4474-9317-a294fd04c65f', volUUID=None) from=::ffff:172.16.252.122,45736, task_id=4878dd0c-54e9-4bef-9ec7-446b110c9d8b (api:46)<br> 2017-08-25 10:38:03,671+0200 INFO (jsonrpc/2) [vdsm.api] FINISH teardownImage return=None from=::ffff:172.16.252.122,45736, task_id=4878dd0c-54e9-4bef-9ec7-446b110c9d8b (api:52)<br> 2017-08-25 10:38:03,672+0200 INFO (jsonrpc/2) [virt.vm] (vmId='ffb71f79-54cd-4f0e-b6b5-3670236cb497') Stopping connection (guestagent:430)<br> <br> <br> <br> <br> <div class="moz-cite-prefix">Am 25.08.2017 um 14:03 schrieb Denis Chaplygin:<br> </div> <blockquote type="cite" cite="mid:CANVzE5=EHucHyfjax9v56DZJ4+vh8VTa33aXq9p=m+71ChmUnQ@mail.gmail.com"> <div dir="ltr">Hello! <div class="gmail_extra"><br> <div class="gmail_quote">On Fri, Aug 25, 2017 at 1:40 PM, 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"> <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> </div> </blockquote> <div><br> </div> <div>As far as i know, <span style="color:rgb(0,0,0);white-space:pre-wrap">backup-volfile-servers is a recommended way to keep you filesystem mountable in case of server failure. While fs is mounted, gluster will automatically provide failover. And you definitely can specify </span><span style="color:rgb(0,0,0);white-space:pre-wrap">backup-volfile-servers in the storage domain configuration.</span></div> <div> </div> <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"> <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"><br> </font></p> </div> </blockquote> <div>Yes, but it was based on a accessing gluster volume as a mount filesystem, not directly... And i would like to exclude that from list of possible causes.</div> </div> <br> </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:part2.13442652.15678464@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> --------------36006B01677FB988B30A2A2E Content-Type: image/gif; name="dconcgdjnkmigkkd.gif" Content-Transfer-Encoding: base64 Content-ID: <part2.13442652.15678464@databay.de> Content-Disposition: inline; filename="dconcgdjnkmigkkd.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= --------------36006B01677FB988B30A2A2E-- --------------3AF71384E88C3DCBA50A18ED--