3:05 a.m.
Hello,
thank you for helping me with my problem.
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 points to all the gluster hosts:
glusterfs.rxmgmt.databay.de. 84600 IN A 172.16.252.121
glusterfs.rxmgmt.databay.de. 84600 IN A 172.16.252.125
glusterfs.rxmgmt.databay.de. 84600 IN A 172.16.252.127
glusterfs.rxmgmt.databay.de. 84600 IN A 172.16.252.122
glusterfs.rxmgmt.databay.de. 84600 IN A 172.16.252.124
glusterfs.rxmgmt.databay.de. 84600 IN A 172.16.252.123
glusterfs.rxmgmt.databay.de. 84600 IN A 172.16.252.126
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.
Bye
Am 24.08.2017 um 16:38 schrieb Yaniv Kaul:
Can you also post to the users mailing list the destination VDSM
log?
On Thu, Aug 24, 2017 at 4:55 PM, Ralf Schenk <rs(a)databay.de
<mailto:rs@databay.de>> wrote:
Hello,
nice to hear it worked for you.
Attached you find the vdsm.log (from migration source) including
the error and engine.log which looks ok.
Hostnames/IP-Adresses are correct and use the ovirtmgmt Network.
I checked (on both hosts):
[root@microcloud22 glusterfs]# gluster volume get gv0
storage.owner-uid
Option Value
------ -----
storage.owner-uid 36
[root@microcloud22 glusterfs]# gluster volume get gv0
storage.owner-gid
Option Value
------ -----
storage.owner-gid 36
[root@microcloud22 glusterfs]# gluster volume get gv0
server.allow-insecure
Option Value
------ -----
server.allow-insecure on
and /etc/glusterd
root@microcloud22 glusterfs]# cat /etc/glusterfs/glusterd.vol
volume management
type mgmt/glusterd
option working-directory /var/lib/glusterd
option transport-type socket
option transport.socket.keepalive-time 10
option transport.socket.keepalive-interval 2
option transport.socket.read-fail-log off
option ping-timeout 0
option event-threads 1
option rpc-auth-allow-insecure on
# option transport.address-family inet6
# option base-port 49152
end-volume
Bye
Am 24.08.2017 um 15:25 schrieb Denis Chaplygin:
> Hello!
>
> On Thu, Aug 24, 2017 at 3:07 PM, Ralf Schenk <rs(a)databay.de
> <mailto:rs@databay.de>> wrote:
>
> Responsiveness of VM is much better (already seen when
> Updateng OS Packages).
>
> But I'm not able to migrate the mashine live to another host
> in the cluster. Manager only states "Migration failed"
>
>
> Live migration worked for me.
>
> Cold you please provide some details? Engine/vdsm logs in +/- 10
> minutes in the vicinity of migration failure.
--
*Ralf Schenk*
fon +49 (0) 24 05 / 40 83 70 <tel:+49%202405%20408370>
fax +49 (0) 24 05 / 40 83 759 <tel:+49%202405%204083759>
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
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)ovirt.org <mailto:Users@ovirt.org>
http://lists.ovirt.org/mailman/listinfo/users
<http://lists.ovirt.org/mailman/listinfo/users>
--
*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
------------------------------------------------------------------------
5:11 a.m.
New subject: oVirt 4.1.5 Finally GlusterFS via lbgfapi
Hello!
On Fri, Aug 25, 2017 at 11:05 AM, Ralf Schenk <rs(a)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
points to all the gluster hosts:
glusterfs.rxmgmt.databay.de. 84600 IN A 172.16.252.121
glusterfs.rxmgmt.databay.de. 84600 IN A 172.16.252.125
glusterfs.rxmgmt.databay.de. 84600 IN A 172.16.252.127
glusterfs.rxmgmt.databay.de. 84600 IN A 172.16.252.122
glusterfs.rxmgmt.databay.de. 84600 IN A 172.16.252.124
glusterfs.rxmgmt.databay.de. 84600 IN A 172.16.252.123
glusterfs.rxmgmt.databay.de. 84600 IN A 172.16.252.126
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" 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?
5:40 a.m.
New subject: oVirt 4.1.5 Finally GlusterFS via lbgfapi
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--
6:03 a.m.
New subject: oVirt 4.1.5 Finally GlusterFS via lbgfapi
Hello!
On Fri, Aug 25, 2017 at 1:40 PM, Ralf Schenk <rs(a)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.
6:14 a.m.
New subject: oVirt 4.1.5 Finally GlusterFS via lbgfapi
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(a)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(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
------------------------------------------------------------------------
--------------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(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">
<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(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>
--------------36006B01677FB988B30A2A2E
Content-Type: image/gif;
name="dconcgdjnkmigkkd.gif"
Content-Transfer-Encoding: base64
Content-ID: <part2.13442652.15678464(a)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--
6:38 a.m.
New subject: oVirt 4.1.5 Finally GlusterFS via lbgfapi
Hello,
Progress: I finally tried to migrate the machine to other hosts in the
cluster. For one this was working !
See attached vdsm.log. The migration to host microcloud25 worked as
expected, migrating back to initial host microloud22 also. Other hosts
(microcloud21, microcloud23,microcloud24 where not working at all as a
migration target.
Perhaps the working ones were the two that I rebooted after upgrading
all hosts to Ovirt 4.1.5. I'll check with another host to reboot it and
try again.Perhaps any other daemon (libvirt/supervdsm or I don't know
has to be restarted)
Bye.
Am 25.08.2017 um 14:14 schrieb Ralf Schenk:
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(a)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(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
------------------------------------------------------------------------
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--
*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
------------------------------------------------------------------------
2446
days inactive
2446
days old
5 comments
2 participants
participants (2)
-
Denis Chaplygin -
Ralf Schenk