- Users - oVirt List Archives

Backup oVirt Node configuration
by Fernando Frediani 19 Jul '17

19 Jul '17

Folks. I had a need to reinstall a oVirt Node a few times these days. This imposed reconfigure it all in order to add it back to oVirt Engine. What is a better way to backup a oVirt Node configuration, for when you reinstall it or if it fail completelly you just reinstall it and restore the backed up files with network configuration, UUID, VDSM, etc ? Thanks Fernando

1 0

Host stuck unresponsive after Network Outage
by Anthony.Fillmore 18 Jul '17

18 Jul '17

--_000_f25a1076729a4b24a9712b1c5c7f8a9fteemlmbx11phqtargetcom_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hey Ovirt Users and Team, I have a host that I am unable to recover post a network outage. The host = is stuck in unresponsive mode, even though the host is on the network, able= to SSH and seems to be healthy. I=1B$B!G=1B(Bve tried several things to r= ecover the host in Ovirt, but have had no success so far. I=1B$B!G=1B(Bd l= ike to reach out to the community before blowing away and rebuilding the ho= st. Environment: I have an Ovengine server with about 26 Datacenters, with 2 to= 3 hosts per Datacenter. My Ovengine server is hosted centrally, with my h= osts being bare-metal and distributed throughout my environment. Ovengin= e is version 4.0.6. What I=1B$B!G=1B(Bve tried: put into maintenance mode, rebooted the host. = Confirmed host was rebooted and tried to active, goes back to unresponsive.= Attempted a reinstall, which fails. Checking from the host perspective, I can see the following problems: [boxname~]# systemctl status vdsmd =1B$B!|=1B(B vdsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled; vendor p= reset: enabled) Active: inactive (dead) Jul 14 12:34:28 boxname systemd[1]: Dependency failed for Virtual Desktop S= erver Manager. Jul 14 12:34:28 boxname systemd[1]: Job vdsmd.service/start failed with res= ult 'dependency'. Going a bit deeper, the results of journalctl -xe: [root@boxname ~]# journalctl -xe -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit libvirtd.service has begun shutting down. Jul 18 09:07:31 boxname systemd[1]: Stopped Virtualization daemon. -- Subject: Unit libvirtd.service has finished shutting down -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit libvirtd.service has finished shutting down. Jul 18 09:07:31 boxname systemd[1]: Reloading. Jul 18 09:07:31 boxname systemd[1]: Binding to IPv6 address not available s= ince kernel does not support IPv6. Jul 18 09:07:31 boxname systemd[1]: [/usr/lib/systemd/system/rpcbind.socket= :6] Failed to parse address value, ignoring: [:: Jul 18 09:07:31 boxname systemd[1]: Started Auxiliary vdsm service for runn= ing helper functions as root. -- Subject: Unit supervdsmd.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit supervdsmd.service has finished starting up. -- -- The start-up result is done. Jul 18 09:07:31 boxname systemd[1]: Starting Auxiliary vdsm service for run= ning helper functions as root... -- Subject: Unit supervdsmd.service has begun start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit supervdsmd.service has begun starting up. Jul 18 09:07:31 boxname systemd[1]: Starting Virtualization daemon... -- Subject: Unit libvirtd.service has begun start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit libvirtd.service has begun starting up. Jul 18 09:07:32 boxname systemd[1]: Started Virtualization daemon. -- Subject: Unit libvirtd.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit libvirtd.service has finished starting up. -- -- The start-up result is done. Jul 18 09:07:32 boxname systemd[1]: Starting Virtual Desktop Server Manager= network restoration... -- Subject: Unit vdsm-network.service has begun start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit vdsm-network.service has begun starting up. lines 2751-2797/2797 (END) Does the community have suggestions on what can be done next to recover thi= s host within Ovirt? I can provide additional log dumps as needed, please = inform with what you need to assist further. Thank you, Tony --_000_f25a1076729a4b24a9712b1c5c7f8a9fteemlmbx11phqtargetcom_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-2022-= jp"> <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Hey Ovirt Users and Team,<o:p></o:p> <o:p> </o:p> I have a host that I am unable to recover post a net= work outage.  The host is stuck in unresponsive mode, even though the = host is on the network, able to SSH and seems to be healthy.  I=1B$B!G= =1B(Bve tried several things to recover the host in Ovirt, but have had no success so far.  I=1B$B!G=1B(Bd like to reach out to = the community before blowing away and rebuilding the host.<o:p></o:p> <o:p> </o:p> Environment: I have an Ovengine server with a= bout 26 Datacenters, with 2 to 3 hosts per Datacenter.  My Ovengine se= rver is hosted centrally, with my hosts being bare-metal and distributed th= roughout my environment.    Ovengine is version 4.0.6.  <o:p></o:p> <o:p> </o:p> What I=1B$B!G=1B(Bve tried: put into maintena= nce mode, rebooted the host.  Confirmed host was rebooted and tried to= active, goes back to unresponsive.   Attempted a reinstall, whic= h fails.  <o:p></o:p> <o:p> </o:p> Checking from the host perspective, I can see the= following problems: <o:p></o:p> <o:p> </o:p> [boxname~]# systemctl status vdsmd<o:p></o:p> =1B$B!|=1B(B vdsmd.service - Virtual Desktop Server = Manager<o:p></o:p>    Loaded: loaded (/usr/lib/systemd/system= /vdsmd.service; enabled; vendor preset: enabled)<o:p></o:p>    Active: inactive (dead)<o:p></o:p> <o:p> </o:p> Jul 14 12:34:28 boxname systemd[1]: Dependency faile= d for Virtual Desktop Server Manager.<o:p></o:p> Jul 14 12:34:28 boxname systemd[1]: Job vdsmd.servic= e/start failed with result 'dependency'.<o:p></o:p> <o:p> </o:p> Going a bit deeper, the results of journalctl &#8= 211;xe: <o:p></o:p> <o:p> </o:p> [root@boxname ~]# journalctl -xe<o:p></o:p> -- Defined-By: systemd<o:p></o:p> -- Support: http://lists.freedesktop.org/mailman/lis= tinfo/systemd-devel<o:p></o:p> --<o:p></o:p> -- Unit libvirtd.service has begun shutting down.<o:= p></o:p> Jul 18 09:07:31 boxname systemd[1]: Stopped Virtuali= zation daemon.<o:p></o:p> -- Subject: Unit libvirtd.service has finished shutt= ing down<o:p></o:p> -- Defined-By: systemd<o:p></o:p> -- Support: http://lists.freedesktop.org/mailman/lis= tinfo/systemd-devel<o:p></o:p> --<o:p></o:p> -- Unit libvirtd.service has finished shutting down.= <o:p></o:p> Jul 18 09:07:31 boxname systemd[1]: Reloading.<o:p><= /o:p> Jul 18 09:07:31 boxname systemd[1]: Binding to IPv6 = address not available since kernel does not support IPv6.<o:p></o:p> Jul 18 09:07:31 boxname systemd[1]: [/usr/lib/system= d/system/rpcbind.socket:6] Failed to parse address value, ignoring: [::<o:p= ></o:p> Jul 18 09:07:31 boxname systemd[1]: Started Auxiliar= y vdsm service for running helper functions as root.<o:p></o:p> -- Subject: Unit supervdsmd.service has finished sta= rt-up<o:p></o:p> -- Defined-By: systemd<o:p></o:p> -- Support: http://lists.freedesktop.org/mailman/lis= tinfo/systemd-devel<o:p></o:p> --<o:p></o:p> -- Unit supervdsmd.service has finished starting up.= <o:p></o:p> --<o:p></o:p> -- The start-up result is done.<o:p></o:p> Jul 18 09:07:31 boxname systemd[1]: Starting Auxilia= ry vdsm service for running helper functions as root...<o:p></o:p> -- Subject: Unit supervdsmd.service has begun start-= up<o:p></o:p> -- Defined-By: systemd<o:p></o:p> -- Support: http://lists.freedesktop.org/mailman/lis= tinfo/systemd-devel<o:p></o:p> --<o:p></o:p> -- Unit supervdsmd.service has begun starting up.<o:= p></o:p> Jul 18 09:07:31 boxname systemd[1]: Starting Virtual= ization daemon...<o:p></o:p> -- Subject: Unit libvirtd.service has begun start-up= <o:p></o:p> -- Defined-By: systemd<o:p></o:p> -- Support: http://lists.freedesktop.org/mailman/lis= tinfo/systemd-devel<o:p></o:p> --<o:p></o:p> -- Unit libvirtd.service has begun starting up.<o:p>= </o:p> Jul 18 09:07:32 boxname systemd[1]: Started Virtuali= zation daemon.<o:p></o:p> -- Subject: Unit libvirtd.service has finished start= -up<o:p></o:p> -- Defined-By: systemd<o:p></o:p> -- Support: http://lists.freedesktop.org/mailman/lis= tinfo/systemd-devel<o:p></o:p> --<o:p></o:p> -- Unit libvirtd.service has finished starting up.<o= :p></o:p> --<o:p></o:p> -- The start-up result is done.<o:p></o:p> Jul 18 09:07:32 boxname systemd[1]: Starting Virtual= Desktop Server Manager network restoration...<o:p></o:p> -- Subject: Unit vdsm-network.service has begun star= t-up<o:p></o:p> -- Defined-By: systemd<o:p></o:p> -- Support: http://lists.freedesktop.org/mailman/lis= tinfo/systemd-devel<o:p></o:p> --<o:p></o:p> -- Unit vdsm-network.service has begun starting up.<= o:p></o:p> lines 2751-2797/2797 (END)<o:p></o:p> <o:p> </o:p> Does the community have suggestions on what can be d= one next to recover this host within Ovirt?  I can provide additional = log dumps as needed, please inform with what you need to assist further.<o:= p></o:p> <o:p> </o:p> Thank you,<o:p></o:p> Tony<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_f25a1076729a4b24a9712b1c5c7f8a9fteemlmbx11phqtargetcom_--

1 0

mirror
by Fabrice Bacchella 18 Jul '17

18 Jul '17

I'm reading https://www.ovirt.org/develop/infra/repository-mirrors/ It says: You'll find in resources.ovirt.org a user named mirror I'm looking at http://resources.ovirt.org and don't see anything about that user. Where should I look ?

2 3

ISCSI storage with multiple nics on same subnet disabled on host activation
by Nelson Lameiras 17 Jul '17

17 Jul '17

------=_Part_57353689_1234561196.1496840388734 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello,=20 In our oVirt hosts, we are using DELL equallogic SAN with each server conne= cting to SAN via 2 physical interfaces. Since both interfaces share the sam= e network (Equalogic limitation) we must patch the linux kernel to to allow= iSCSI multipath with multiple NICs in the same subnet with sysctl :=20 ---------------------------------------------------------------------------= -----------------=20 net.ipv4.conf.p2p1.arp_ignore=3D1 net.ipv4.conf.p2p1.arp_announce=3D2 net.ipv4.conf.p2p1.rp_filter=3D2 net.ipv4.conf.p2p2.arp_ignore=3D1 net.ipv4.conf.p2p2.arp_announce=3D2 net.ipv4.conf.p2p2.rp_filter=3D2=20 ---------------------------------------------------------------------------= -----------------=20 This works great in most setups, but for a strange reason, on some of our s= etups, the sysctl configuration is updated by VDSM when activating a host a= nd the second interface stops working immeadiatly :=20 ---------------------------------------------------------------------------= -----------------=20 vdsm.log=20 2017-06-07 11:51:51,063+0200 INFO (jsonrpc/5) [storage.ISCSI] Setting stri= ct mode rp_filter for device 'p2p2'. (iscsi:602) 2017-06-07 11:51:51,064+0200 ERROR (jsonrpc/5) [storage.HSM] Could not conn= ect to storageServer (hsm:2392) Traceback (most recent call last): File "/usr/share/vdsm/storage/hsm.py", line 2389, in connectStorageServer conObj.connect() File "/usr/share/vdsm/storage/storageServer.py", line 433, in connect iscsi.addIscsiNode(self._iface, self._target, self._cred) File "/usr/lib/python2.7/site-packages/vdsm/storage/iscsi.py", line 232, = in addIscsiNode iscsiadm.node_login(iface.name, target.address, target.iqn) File "/usr/lib/python2.7/site-packages/vdsm/storage/iscsiadm.py", line 33= 7, in node_login raise IscsiNodeError(rc, out, err)=20 ---------------------------------------------------------------------------= -----------------=20 "strict mode" is enforced for second interface, and it no longuer works...= =20 Which means - at least - that there is no redundancy in case of hardware fa= illure and this is not acceptable for our production needs.=20 What is really strange is that we have another "twin" site on another geogr= aphic region with simillar hardware configuration and same oVirt installati= on, and this problem does not happen.=20 What can be the root cause of this behaviour? How can I correct it?=20 our setup:=20 hostedEngine : Centor 7.3, ovirt 4.1.2=20 3 physical nodes centos 7.3, ovirt 4.1.2=20 SAN DELL Equalogic=20 cordialement, regards,=20 =09Nelson LAMEIRAS=20 Ing=C3=A9nieur Syst=C3=A8mes et R=C3=A9seaux / Systems and Networks enginee= r=20 Tel: +33 5 32 09 09 70=20 nelson.lameiras(a)lyra-network.com=20 www.lyra-network.com | www.payzen.eu=20 =09 =09 =09 Lyra Network, 109 rue de l'innovation, 31670 Lab=C3=A8ge, FRANCE=20 ------=_Part_57353689_1234561196.1496840388734 Content-Type: multipart/related; boundary="----=_Part_57353690_157338222.1496840388734" ------=_Part_57353690_157338222.1496840388734 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: arial, helvetica, sans-serif; font-s= ize: 12pt; color: #000000"><div>Hello, </div><div> </div><div>In our oVirt hosts, we are using DELL equallogic SAN with eac= h server connecting to SAN via 2 physical interfaces. Since both interfaces= share the same network (Equalogic limitation) we must patch the linux kern= el to to allow iSCSI multipath with multiple NICs in the same subnet with s= ysctl : </div><div> </div><= div>-----------------------------------------------------------------------= --------------------- </div><div><pre>net.ipv4.conf= .p2p1.arp_ignore=3D1 net.ipv4.conf.p2p1.arp_announce=3D2 net.ipv4.conf.p2p1.rp_filter=3D2 net.ipv4.conf.p2p2.arp_ignore=3D1 net.ipv4.conf.p2p2.arp_announce=3D2 net.ipv4.conf.p2p2.rp_filter=3D2 </pre>--------------------------= ------------------------------------------------------------------ <= /p>This works great in most setups, but for a strange reason, on some of= our setups, the sysctl configuration is updated by VDSM when activating a = host and the second interface stops working immeadiatly :<div>---------= ---------------------------------------------------------------------------= --------</div><div>vdsm.log </div><div><pre id=3D"p= review"><code>2017-06-07 11:51:51,063+0200 INFO (jsonrpc/5) [storage.ISCSI= ] Setting strict mode rp_filter for device 'p2p2'. (iscsi:602) 2017-06-07 11:51:51,064+0200 ERROR (jsonrpc/5) [storage.HSM] Could not conn= ect to storageServer (hsm:2392) Traceback (most recent call last): File "/usr/share/vdsm/storage/hsm.py", line 2389, in connectStorageServer conObj.connect() File "/usr/share/vdsm/storage/storageServer.py", line 433, in connect iscsi.addIscsiNode(self._iface, self._target, self._cred) File "/usr/lib/python2.7/site-packages/vdsm/storage/iscsi.py", line 232, = in addIscsiNode iscsiadm.node_login(iface.name, target.address, target.iqn) File "/usr/lib/python2.7/site-packages/vdsm/storage/iscsiadm.py", line 33= 7, in node_login raise IscsiNodeError(rc, out, err)</code></pre><pre> </pre>----------------------= ----------------------------------------------------------------------<= /div></div><div><div> </div><div>"strict mode" is e= nforced for second interface, and it no longuer works...</div><div>Which me= ans - at least - that there is no redundancy in case of hardware faillure a= nd this is not acceptable for our production needs. </div><div> </div><div>What is really strange is t= hat we have another "twin" site on another geographic region with simillar = hardware configuration and same oVirt installation, and this problem does n= ot happen.</div><div> </div><div>What can be the ro= ot cause of this behaviour? How can I correct it? <= /div><div> </div><div>our setup:</div><div>hostedEn= gine : Centor 7.3, ovirt 4.1.2 </div><div>3 physical nodes centos 7.3, o= virt 4.1.2 </div><div>SAN DELL Equalogic </div></div><div> </div><div data-mar= ker=3D"__SIG_PRE__"><div>cordialement, regards,</div><div> </div><table style=3D"margin: 0px; table-layout: fixed; border: non= e; width: 345pt; padding: 0px;" data-mce-style=3D"margin: 0px; table-layout= : fixed; border: none; width: 345pt; padding: 0px;" width=3D"460" cellspaci= ng=3D"0" cellpadding=3D"0" border=3D"0"><tbody><tr><td style=3D"margin: 0; = font-size: 11px; font-family: Arial,sans-serif; color: #2b3c7a; line-height= : 16px; width: 86.25pt; text-align: left;" data-mce-style=3D"margin: 0; fon= t-size: 11px; font-family: Arial,sans-serif; color: #2b3c7a; line-height: 1= 6px; width: 86.25pt; text-align: left;" width=3D"115" valign=3D"top"><a hre= f=3D"https://www.lyra-network.com/" style=3D"border: none; text-decoration:= none; width: 100%; display: block; clear: both;" data-mce-href=3D"https://= www.lyra-network.com/" data-mce-style=3D"border: none; text-decoration: non= e; width: 100%; display: block; clear: both;"><img src=3D"cid:6fa8666d679e1= 8cab5e566228d0ca3519aabec27@zimbra" alt=3D"" data-mce-src=3D"/home/admin@ly= ra-network.com/corporate-documents/element-signature_logo_lyra_115x94.jpg" = doc=3D"corporate-documents/element-signature_logo_lyra_115x94.jpg" height= =3D"94" width=3D"115" border=3D"0"></a> </td><td st= yle=3D"margin: 0; font-size: 11px; font-family: Arial,sans-serif; color: #2= b3c7a; line-height: 16px; width: 258.75pt;" data-mce-style=3D"margin: 0; fo= nt-size: 11px; font-family: Arial,sans-serif; color: #2b3c7a; line-height: = 16px; width: 258.75pt;" width=3D"345" valign=3D"top"><table style=3D"margin= : 0; width: 258.75pt; table-layout: fixed; border: none;" data-mce-style=3D= "margin: 0; width: 258.75pt; table-layout: fixed; border: none;" width=3D"3= 45" cellspacing=3D"0" cellpadding=3D"0" border=3D"0"><tbody><tr><td style= =3D"font-size: 16px; font-family: Arial,sans-serif; color: #2b3c7a; line-he= ight: 18px; font-weight: bold;" data-mce-style=3D"font-size: 16px; font-fam= ily: Arial,sans-serif; color: #2b3c7a; line-height: 18px; font-weight: bold= ;">Nelson LAMEIRAS</td></tr><tr><td style=3D"font-family: Arial,sans-serif;= color: #2b3c7a; font-size: 11px; line-height: 16px;" data-mce-style=3D"fon= t-family: Arial,sans-serif; color: #2b3c7a; font-size: 11px; line-height: 1= 6px;">Ing=C3=A9nieur Syst=C3=A8mes et R=C3=A9seaux / Systems a= nd Networks engineer</td></tr><tr><td style=3D"line-height: 16px; fo= nt-family: 'Arial',sans-serif; color: #2b3c7a; font-size: 11px;" data-mce-s= tyle=3D"line-height: 16px; font-family: 'Arial',sans-serif; color: #2b3c7a;= font-size: 11px;">Tel: +33 5 32 09 09 70</td></tr><tr>= <td style=3D"line-height: 16px; font-family: 'Arial',sans-serif; color: #2b= 3c7a; font-size: 11px;" data-mce-style=3D"line-height: 16px; font-family: '= Arial',sans-serif; color: #2b3c7a; font-size: 11px;"><a href=3D"mailto:nels= on.lameiras(a)lyra-network.com" style=3D"font-size: 11px; font-family: Arial,= sans-serif; line-height: 16px; text-decoration: none;" data-mce-href=3D"mai= lto:nelson.lameiras@lyra-network.com" data-mce-style=3D"font-size: 11px; fo= nt-family: Arial,sans-serif; line-height: 16px; text-decoration: none;">nel= son.lameiras(a)lyra-network.com</a> </td></tr><tr><td= style=3D"line-height: 16px; font-family: 'Arial',sans-serif; color: #2b3c7= a; font-size: 11px;" data-mce-style=3D"line-height: 16px; font-family: 'Ari= al',sans-serif; color: #2b3c7a; font-size: 11px;"><a href=3D"https://www.ly= ra-network.com/" style=3D"font-size: 11px; font-family: Arial,sans-serif; l= ine-height: 16px; border: none; text-decoration: none;" data-mce-href=3D"ht= tps://www.lyra-network.com/" data-mce-style=3D"font-size: 11px; font-family= : Arial,sans-serif; line-height: 16px; border: none; text-decoration: none;= ">www.lyra-network.com</a> <a href=3D"https://payzen.eu" style=3D"font-size= : 11px; font-family: Arial,sans-serif; line-height: 16px; border: none; tex= t-decoration: none;" data-mce-href=3D"https://payzen.eu" data-mce-style=3D"= font-size: 11px; font-family: Arial,sans-serif; line-height: 16px; border: = none; text-decoration: none;"> | www.payzen.eu</a> = </td></tr></tbody></table></td></tr></tbody></table><table style=3D"margin:= 0; table-layout: fixed; border: none; width: 345pt;" data-mce-style=3D"mar= gin: 0; table-layout: fixed; border: none; width: 345pt;" data-mce-selected= =3D"1" width=3D"460" cellspacing=3D"0" cellpadding=3D"0"><tbody><tr><td sty= le=3D"margin: 0; font-size: 11px; font-family: Arial,sans-serif; color: #2b= 3c7a; line-height: 16px; width: 24pt; text-align: left;" data-mce-style=3D"= margin: 0; font-size: 11px; font-family: Arial,sans-serif; color: #2b3c7a; = line-height: 16px; width: 24pt; text-align: left;" width=3D"32" valign=3D"t= op"><a href=3D"https://www.youtube.com/channel/UCrVl1CO_Jlu3KbiRH-tQ_vA" st= yle=3D"border: none; text-decoration: none; margin: 0; float: left; display= : inline-block; width: 32px;" data-mce-href=3D"https://www.youtube.com/chan= nel/UCrVl1CO_Jlu3KbiRH-tQ_vA" data-mce-style=3D"border: none; text-decorati= on: none; margin: 0; float: left; display: inline-block; width: 32px;"><img= src=3D"cid:2806a89cb9fbba6f879bd3fd54a93b515defd6d2@zimbra" alt=3D"" data-= mce-src=3D"/home/admin(a)lyra-network.com/corporate-documents/element-signatu= re_logo_YouTube_32x28.jpg" doc=3D"corporate-documents/element-signature_log= o_YouTube_32x28.jpg" height=3D"28" width=3D"32" border=3D"0"></a> </td><td style=3D"margin: 0; font-size: 11px; font-family: A= rial,sans-serif; color: #2b3c7a; line-height: 16px; width: 30.75pt; text-al= ign: left;" data-mce-style=3D"margin: 0; font-size: 11px; font-family: Aria= l,sans-serif; color: #2b3c7a; line-height: 16px; width: 30.75pt; text-align= : left;" width=3D"41" valign=3D"top"><a href=3D"https://www.linkedin.com/co= mpany/lyra-network_2" style=3D"border: none; text-decoration: none; margin:= 0; float: left; display: inline-block; width: 41px;" data-mce-href=3D"http= s://www.linkedin.com/company/lyra-network_2" data-mce-style=3D"border: none= ; text-decoration: none; margin: 0; float: left; display: inline-block; wid= th: 41px;"><img src=3D"cid:878634ba055bb6ae851a7ef4540f754afa3ff86c@zimbra"= data-mce-src=3D"/home/admin(a)lyra-network.com/corporate-documents/element-s= ignature_logo_LinkedIn_41x28.jpg" doc=3D"corporate-documents/element-signat= ure_logo_LinkedIn_41x28.jpg" height=3D"28" width=3D"41" border=3D"0"></a><b= r data-mce-bogus=3D"1"></td><td style=3D"margin: 0; font-size: 11px; font-f= amily: Arial,sans-serif; color: #2b3c7a; line-height: 16px; width: 31.5pt; = text-align: left;" data-mce-style=3D"margin: 0; font-size: 11px; font-famil= y: Arial,sans-serif; color: #2b3c7a; line-height: 16px; width: 31.5pt; text= -align: left;" width=3D"42" valign=3D"top"><a href=3D"https://twitter.com/L= yraNetwork" style=3D"border: none; text-decoration: none; margin: 0; float:= left; display: inline-block; width: 42px;" data-mce-href=3D"https://twitte= r.com/LyraNetwork" data-mce-style=3D"border: none; text-decoration: none; m= argin: 0; float: left; display: inline-block; width: 42px;"><img src=3D"cid= :18a767bbdad6a1133fc4152b03ea78228ce25a14@zimbra" alt=3D"" data-mce-src=3D"= /home/admin@lyra-network.com/corporate-documents/element-signature_logo_Twi= tter_42x28.jpg" doc=3D"corporate-documents/element-signature_logo_Twitter_4= 2x28.jpg" height=3D"28" width=3D"42" border=3D"0"></a> </td><td style=3D"margin: 0; font-size: 11px; font-family: Arial,sans-s= erif; color: #2b3c7a; line-height: 16px; width: 258.75pt; text-align: left;= " data-mce-style=3D"margin: 0; font-size: 11px; font-family: Arial,sans-ser= if; color: #2b3c7a; line-height: 16px; width: 258.75pt; text-align: left;" = width=3D"345" valign=3D"top"><a href=3D"https://payzen.eu" style=3D"border:= none; text-decoration: none; margin: 0; float: left; display: inline-block= ; width: 61px;" data-mce-href=3D"https://payzen.eu" data-mce-style=3D"borde= r: none; text-decoration: none; margin: 0; float: left; display: inline-blo= ck; width: 61px;"><img src=3D"cid:d3fc119a0aa72bf985c19ca559c993b5b4b54ca3@= zimbra" alt=3D"" data-mce-src=3D"/home/admin(a)lyra-network.com/corporate-doc= uments/element-signature_payzen_61x28.jpg" doc=3D"corporate-documents/eleme= nt-signature_payzen_61x28.jpg" height=3D"28" width=3D"61" border=3D"0"></a>= </td></tr></tbody></table><table style=3D"margin: = 0; table-layout: fixed; border: none; width: 345pt;" data-mce-style=3D"marg= in: 0; table-layout: fixed; border: none; width: 345pt;" width=3D"460" cell= spacing=3D"0" cellpadding=3D"0"><tbody><tr><td><hr style=3D"background: #29= 3b79 none repeat scroll 0% 0%; width: 100%; height: 4px; color: #293b79; ma= rgin: 0px;" data-mce-style=3D"background: #293b79 none repeat scroll 0% 0%;= width: 100%; height: 4px; color: #293b79; margin: 0px;"></td></tr></tbody>= </table><table style=3D"margin: 0; table-layout: fixed; border: none; width= : 345pt;" data-mce-style=3D"margin: 0; table-layout: fixed; border: none; w= idth: 345pt;" data-mce-selected=3D"1" width=3D"460" cellspacing=3D"0" cellp= adding=3D"0"><tbody><tr><td style=3D"margin: 0; font-size: 11px; font-famil= y: Arial,sans-serif; color: #2b3c7a; line-height: 16px; width: 30.75pt; tex= t-align: left;" data-mce-style=3D"margin: 0; font-size: 11px; font-family: = Arial,sans-serif; color: #2b3c7a; line-height: 16px; width: 30.75pt; text-a= lign: left;"><div>Lyra Network, 109 rue de l'innovation, 31670 Lab=C3=A8ge,= FRANCE</div></td></tr></tbody></table><div> </div></div></div></body></= html> ------=_Part_57353690_157338222.1496840388734 Content-Type: image/jpeg; name=element-signature_logo_lyra_115x94.jpg Content-Disposition: attachment; filename=element-signature_logo_lyra_115x94.jpg Content-Transfer-Encoding: base64 Content-ID: <6fa8666d679e18cab5e566228d0ca3519aabec27@zimbra> /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QOBaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjYtYzEzMiA3OS4xNTkyODQsIDIwMTYvMDQvMTktMTM6 MTM6NDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1LTgxYmQtMTYwMTFjZjk5YWVjIiB4bXBNTTpEb2N1 bWVudElEPSJ4bXAuZGlkOkU1QUU4Nzk1OEExMzExRTZBNTFCRjVENEYyNDYxNTQ1IiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOkU1QUU4Nzk0OEExMzExRTZBNTFCRjVENEYyNDYxNTQ1IiB4bXA6 Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDQyAyMDE1LjUgKFdpbmRvd3MpIj4gPHhtcE1N OkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1 LTgxYmQtMTYwMTFjZjk5YWVjIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOmRkMGY5MmM1LTc4 YWYtY2U0NS04MWJkLTE2MDExY2Y5OWFlYyIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRG PiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAYE BAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHB8fHx8f Hx8fHx8BBwcHDQwNGBAQGBoVERUaHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fH//AABEIAF4AcwMBEQACEQEDEQH/xACdAAEBAAIDAQEAAAAAAAAAAAAACAUH AgMGBAEBAQADAQEAAAAAAAAAAAAAAAACBAUBAxAAAAUDAgAHDQcCBwAAAAAAAAECAwQRBQYSByFR E7RWFzcxQSKS0nOT03RVlQgYYXEyQiMUFYEzsVJicmODOBEAAgECAwcEAgIDAAAAAAAAAAECEQNR EwQhgbESMlIzMUGhFHEVwQUiQzT/2gAMAwEAAhEDEQA/AKpAE9b/AGQZdF3FtNpsd4l29M2DHSll iS6w0bzsp5slqJCiLvERnTuENTRQg7bckntK15vmojj1WfMP0rc+Jy/JD7Fjt+EMueJ6bbnBN4bR lkWdkt+XPtDaHSfjKnSHyUpTZkg+TcLSdFGRjyv3rUo0iqP8EoQkntZ7fcOy5VdrXGYxuccGW2+S 3nCecYq3oUWnU2RmfhGXAPPSXLcJNzVVT8kNVbnKKUHRmppW1/zBOSXVtZS4lpSjNtP8nLKhfcSR alqdPXp+ERhauKKTe38nX1WfMP0qc+Jy/JHPsWO34RPLniOqz5h+lTnxOX5IfYsdvwhlzxHVZ8w/ Spz4nL8kPsWO34Qy54jqs+YfpU58Tl+SH2LHb8IZc8R1WfMP0qc+Jy/JD7Fjt+EMueJ2bCX3MH9y LxZr7eJdxKBCkoW0/JdfaJ5mUy2a0EszL/MRHTuGGshDLTiqVf8AAst81GUGMssgAAAAE5b89s+L +zwefPDV0fhlv4FW71oo0ZRaAAAAAAAAAAAAACdtj+3DLfNXDn7I1dX4Y7uBWtdbKJGUWQAAAACc t+e2fF/Z4PPnhq6Pwy38Crd60UaMotAAAAAAAAAAAAABO2x/bhlvmrhz9kaur8Md3ArWutlEjKLI AAAABOW/PbPi/s8Hnzw1dH4Zb+BVu9aKNGUWjAKzrGk5cnEjkq/nVo5RMbk3NOnkzd/uU0fgKvdH rky5eb2I86rQz48iQAAAAAAAAABO2x/bhlvmrhz9kaur8Md3ArWutlEjKLIAAAABOW/PbPi/s8Hn zw1dH4Zb+BVu9aKNGUWjSD//AKkj+xnzJQ0V/wA2/wDkr/7D3e7GX5DiOMfzlniMTEMPIRORIJfg tOeCladCk/nNJH94raa1GcuVnpck4qqOrJdz4dr2yazKOhDjkxhlUGMszop98i/TOlD/AE/CNX+0 x23p27nIJXKRqeeyjdnLMd27sGSzLdEO4Xd4uWifqkhDDiFut0qrUSzQlNa9wz7g9bemjK44puiI yuNRTOzGs53hud+gvzsYjwMVnqNfLuqUTrEck69bitZmStPc1NJIz4hy5ZtKLpKskIzk36bDHRt2 9yMsuMw9v8ejybNBc5M5s5Rp5Uy4aEZuMJSai4dPCZFStBN6a3BLne1nMyT6Uffgu8GQ5DnysXuN mbtZx461TG1ms3kyGiLWRHXToMz8Hg7nfMQvaWMYcydTsLjcqG2BSPYnbY/twy3zVw5+yNXV+GO7 gVrXWyiRlFkAAAAAnLfntnxf2eDz54auj8Mt/Aq3etFGjKLROmdZbAxL5g/5yey6/GjREJW2wSTc M3YpoKms0F3VcY1bNpzscqKs5UnU9pad4cG3Fefw1UWXFO7x3mULkpaJJnoM6JNC10WREak/aXGK 8tLO1/ns2HorilsNTYzar/kOQWTa+5tmmBjk+W9cKGqimkrJS68RcCkoV/yC7clGMXcXrJI8Yptq OBsj5oEpTiNmSRESSuKSJJFwUJlzgoKv9f1P8Hrf9Db1wh/vbVJh6tH7lhbOvi5RBpr/AEqKMXR1 PZrYaC2x3Jgbawp+IZjBkwpkWS480603rSslkRU7qTOuiqFlUlEfepw6WosO61ODK9ufLsZ27f36 RkG/8q9OwXbe3PgKciMPp0uHHS22hpxRf60o1f4VC9DlsUrWjEHWdSghllknbY/twy3zVw5+yNXV +GO7gVrXWyiRlFkAAAAAnLfntnxf2eDz54auj8Mt/Aq3etFGjKLRxU00o6qQlR8ZkRhUGMyO7W7H 7FOvUpCSZgMrfMqERqNJeCgj41qokvtMTtxcpJL3OSdFU1n8vFimPwbrnF18O55DIXybhlw8ihZm s08RLdqVOJJC5rZqqgvSJ42V7v3MpM3dTBnyWbtBQmHFnXFpLzdXOWjW9tWo2irwPpd0pWhVPBPU R0qILTVWx+y+STuYmQj7sxHH1Kctb7NuahnMflKW2akk3J/bvGlojqtpv8ZuJP8ACR8Ag9M8dtTu YdErdfEJTCZKrY/L5JSySbrbCdKmicdWRLeWlJK/bs8skq+ElSacJ8HVppr3OZiP2RuxFK4W5xi3 LK2T5D8NmY8baHHnWySSeTSa6to1K8JTumn3gtM6PbtQzDYYqnqTtsf24Zb5q4c/ZGrq/DHdwK1r rZRIyiyAAAAATlvz2z4v7PB588NXR+GW/gVbvWijRlFoADGZHjVmyO2Ltd4YOTAcUlbjJLcbJRoO qam2pCuA+GlROFxwdV6nJRT2M+q226DbLfHt8BkmIcRtLMdlNaJQgqEVTqZ/eYjKTbqwlQ5Hb4Bp Uk4zRpUpa1FoTQ1uEaVqPg7qiUZGffDmYodSbNZ0toaTBjk02hbTaCaQSUtu/wBxCSpQkr/MXfHe d4iiP12z2h5k2XYMdxlSkuKbW0hSTW2kkIUZGVKpSkiI+8RApPEURydtltdQpDsRlxCtepKm0mR8 qdXKkZfn/NxjnMxQ+kcOk7bH9uGW+auHP2Rq6vwx3cCta62USMosgAAAAE5b89s+L+zwefPDV0fh lv4FW71oo0ZRaAAAAAAAAAAAAACdtj+3DLfNXDn7I1dX4Y7uBWtdbKJGUWQAAAACb9/3mWN4cbff WTTLUWEt1xX4UpTNeNSj+wiGtolW1LfwKt7qRuTrY226RwfSkKH1rnaz3zI4jrZ226RwfSkH1rna xmRxHWztt0jg+lIPrXO1jMjiOtnbbpHB9KQfWudrGZHEdbO23SOD6Ug+tc7WMyOJ+o3W24WtKE5F CUpR0SknCqZmH1rnazjuxW2pnbTfbPeGnHbXMamNtK0OLaVqJKjKtDELlqUNklQ7C5GfS6mOu+f4 XZpy4F0vMWHMbJKlsOrJKyJRVTUvtIdjZnJVSOuaXqfF1sbbdI4PpSEvrXO1nMyOJp7YiQxJ3oyi RHcS9Hejz3GXUcKVoVOZNKi+wyOovaxUsx3cDwtdbKNGUWgAAAADX+4GzGPZveWbtcpsuO+xGTFS iObRINCFrcIz1oWdaun3xas6qVtUSR5ztKTqeZ+lrCvely8Zj1Q9f2M8EQyEPpawr3pcvGY9UH7G eCGQh9LWFe9Ll4zHqg/YzwQyEPpawr3pcvGY9UH7GeCGQh9LWFe9Ll4zHqg/YzwQyEc2flfwxl5t 1NzuJqbUSiI1MUqX/UOr+xmn6I5LTRaaxNg4XhNuxOHIiwX3n0SXCdWb5pMyMk6eDSlPEPDU6mV5 pteg0+nVpNI8zm+xeNZfkDt7nzprEl5Dbam2FNEgibTpKmttR97jErWslCNEkTlaUnUwP0tYV70u XjMeqHp+xngiOQj023+zGPYReXrtbZsuQ+/GVFUiQbRoJC1ocMy0IQdatF3x5XtVK4qNInC0oups AVT0AAAAAAAAAAAAAAAAAAAAAAAAAAAAD//Z ------=_Part_57353690_157338222.1496840388734 Content-Type: image/jpeg; name=element-signature_logo_YouTube_32x28.jpg Content-Disposition: attachment; filename=element-signature_logo_YouTube_32x28.jpg Content-Transfer-Encoding: base64 Content-ID: <2806a89cb9fbba6f879bd3fd54a93b515defd6d2@zimbra> /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QOBaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjYtYzEzMiA3OS4xNTkyODQsIDIwMTYvMDQvMTktMTM6 MTM6NDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1LTgxYmQtMTYwMTFjZjk5YWVjIiB4bXBNTTpEb2N1 bWVudElEPSJ4bXAuZGlkOjQ1REY5Njk1OEExNzExRTY5OUVDOTI1QTU3QzAwNzI0IiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOjQ1REY5Njk0OEExNzExRTY5OUVDOTI1QTU3QzAwNzI0IiB4bXA6 Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDQyAyMDE1LjUgKFdpbmRvd3MpIj4gPHhtcE1N OkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1 LTgxYmQtMTYwMTFjZjk5YWVjIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOmRkMGY5MmM1LTc4 YWYtY2U0NS04MWJkLTE2MDExY2Y5OWFlYyIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRG PiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAYE BAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHB8fHx8f Hx8fHx8BBwcHDQwNGBAQGBoVERUaHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fH//AABEIABwAIAMBEQACEQEDEQH/xAB5AAADAQEAAAAAAAAAAAAAAAAABwgF BgEAAgMBAAAAAAAAAAAAAAAAAAQCAwUBEAABBAECBAUFAAAAAAAAAAABAgMEBQARBiESEwcxUdIU CEEik1UYEQACAQMCBQUAAAAAAAAAAAAAAQIRAwQhMVFhEiITQaHBYhX/2gAMAwEAAhEDEQA/AKpw AnD5Hbg3JA35XxKqxmxUPVrJEaI862FuqkPp4IbI5lHQDNXBhFwbaW4tebqcMIvfYjURtz6eesv1 YzWz9fYh38zR7eX2+mu5lHV3VhaNOe8aTJgTHnweVXEBba1cQRkb8IeNtJbHYN9WpW+YY2T53inQ 4HfzZk6a4lmHGaiOSHl8EoT7mSOZR+gBIzUxU3Yklz+Be4+9DRl30N3dMOxjbyro9EzHW3MqupHc L7qlaoX1SsFvlHl44moPpa6XXiW113FPuu3qrT5I7dfrJLUxllMRl15hQWjqBbiuXmTqCQlQx23F rHdSqTrNFFZlDAou7vZa43xuSNaw7CPFZZhIiKbeSsqKkOuuE/aCNNHcexspW40a9Sm5bcmcH/J1 5+0rvxOenGf0o8GQ8DN7ZXxzv9vbpqrhy0huMQJCHlstocBKU+ITqANcru50ZRao9SUbLTqPvMwv DAAwAMAP/9k= ------=_Part_57353690_157338222.1496840388734 Content-Type: image/jpeg; name=element-signature_logo_LinkedIn_41x28.jpg Content-Disposition: attachment; filename=element-signature_logo_LinkedIn_41x28.jpg Content-Transfer-Encoding: base64 Content-ID: <878634ba055bb6ae851a7ef4540f754afa3ff86c@zimbra> /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QOBaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjYtYzEzMiA3OS4xNTkyODQsIDIwMTYvMDQvMTktMTM6 MTM6NDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1LTgxYmQtMTYwMTFjZjk5YWVjIiB4bXBNTTpEb2N1 bWVudElEPSJ4bXAuZGlkOjY2MEYzRTFGOEExNzExRTY5QzI5OUNGQkY1MzM2MUQ1IiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOjY2MEYzRTFFOEExNzExRTY5QzI5OUNGQkY1MzM2MUQ1IiB4bXA6 Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDQyAyMDE1LjUgKFdpbmRvd3MpIj4gPHhtcE1N OkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1 LTgxYmQtMTYwMTFjZjk5YWVjIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOmRkMGY5MmM1LTc4 YWYtY2U0NS04MWJkLTE2MDExY2Y5OWFlYyIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRG PiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAYE BAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHB8fHx8f Hx8fHx8BBwcHDQwNGBAQGBoVERUaHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fH//AABEIABwAKQMBEQACEQEDEQH/xAB2AAEBAQEAAAAAAAAAAAAAAAAABggH AQEAAwEAAAAAAAAAAAAAAAAAAwQFAhAAAQMEAgICAgMBAAAAAAAAAQIDBAARBQYhEjEHMghBE1Fh IhcRAAICAQIDCQAAAAAAAAAAAAABAgMREgQxkTIhQVGhscETMxX/2gAMAwEAAhEDEQA/ANU0Bl33 zsuzQfZcmHj8tMiMKaihDLMl1psKcQkXslSUjk8mtjZ1xdeWkVbW9RDZ/ZN8wOXkYnI7LKMuL1Lq o+RddaIWkLHVwLAPCuf4NWYVwksqPkcNtd5V+ldr2ef7MwkaZmJsqK6p/uy9JdcbUBGcULpUog8i 9Q7uuKreEjquT1GsKxC2KAUBk37B2/6y72t1tB7X8dbIvf8Aq3mtvZfVzKlvUWWw7Dr+Dfy8rCt4 d153Z8ew0FNx3kohuxmUyFtAfFPyBUOBz+arwhKWE89L9SRtLmTuns4xj7LLaxYaGNE6SYojlJZ6 rhLUf19f89eyj4qa1t7ft449ziPWairGLQoBQHFvZ/onObht0jNxclFjMPNtNpZdS4Vj9aAk36gj mtDb7yMIaWiGdTbySSfqnsKbdctAFh1Fm3Bwfx8fFT/ox8GcfAyk9dfX7OapuGNzj+SiPRoJcKmG kuBRDjS2x1uAPK71DfvYzg444nUKmnk7lWcTigFAKAUAoBQCgP/Z ------=_Part_57353690_157338222.1496840388734 Content-Type: image/jpeg; name=element-signature_logo_Twitter_42x28.jpg Content-Disposition: attachment; filename=element-signature_logo_Twitter_42x28.jpg Content-Transfer-Encoding: base64 Content-ID: <18a767bbdad6a1133fc4152b03ea78228ce25a14@zimbra> /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QOBaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjYtYzEzMiA3OS4xNTkyODQsIDIwMTYvMDQvMTktMTM6 MTM6NDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1LTgxYmQtMTYwMTFjZjk5YWVjIiB4bXBNTTpEb2N1 bWVudElEPSJ4bXAuZGlkOjdDMkI3MjMyOEExNzExRTY5MDUyRTk1NEIyREUwNjVCIiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOjdDMkI3MjMxOEExNzExRTY5MDUyRTk1NEIyREUwNjVCIiB4bXA6 Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDQyAyMDE1LjUgKFdpbmRvd3MpIj4gPHhtcE1N OkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1 LTgxYmQtMTYwMTFjZjk5YWVjIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOmRkMGY5MmM1LTc4 YWYtY2U0NS04MWJkLTE2MDExY2Y5OWFlYyIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRG PiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAYE BAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHB8fHx8f Hx8fHx8BBwcHDQwNGBAQGBoVERUaHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fH//AABEIABwAKgMBEQACEQEDEQH/xAB3AAEBAQEBAAAAAAAAAAAAAAAABwUI BgEBAAMBAQAAAAAAAAAAAAAAAAMEBQIBEAABAwIEBwEBAQAAAAAAAAABAgMEAAUREhMGITFBFBUH CIEiFhEAAgIBAgQHAAAAAAAAAAAAAAERAgMxBCHBEgVBUWGBQhMV/9oADAMBAAIRAxEAPwDC9g7u 3dH33uJiNeri2wxcJQQ01JfCUNodVwCUqwSlI/AK3sGKropS0Kd7OWZMXcPsyZDdnQ7he5UFhQQ/ LZelOMoURiEqWlRAOFdumNOGqyeTYtPzFfL1df8ASm5XCTP0ey0e5eceyZu4zZc5VhjlGOFZ/cKJ dMKNeRNhbclzrOJxQCgOSW7o5a/oKXMRFXNT5iYw/EaAUtbL61tOBKTwXglWOXrW30zgj0RUmLlb 9p3rZ/r/ANd3GxWJtm3XC8B1EO2RsEqDkng88pAP8JSnEk8ugqlt6Xy5Fa3FImyNVUI8z8nJCU7o SOSRAA/O5qbuXx9+Rxg8ToGsssCgFAc/7q+b9xXrc11u7V3iNN3CW/JbQUuhaUuuFYBIHMA9K08e +rWqUPgivbC25MofK25Qoq81DKjwKlJeUT+kE13+jXyZ59DKX6a9WXPYfmO+msTPJdtp6AWMuhq4 5swHPVFVN1uFkiFoS46dJSqqEgoBQCgFAKAUAoBQH//Z ------=_Part_57353690_157338222.1496840388734 Content-Type: image/jpeg; name=element-signature_payzen_61x28.jpg Content-Disposition: attachment; filename=element-signature_payzen_61x28.jpg Content-Transfer-Encoding: base64 Content-ID: <d3fc119a0aa72bf985c19ca559c993b5b4b54ca3@zimbra> /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAAA8AAD/4QOBaHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjYtYzEzMiA3OS4xNTkyODQsIDIwMTYvMDQvMTktMTM6 MTM6NDAgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bXBNTTpPcmlnaW5hbERvY3VtZW50SUQ9 InhtcC5kaWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1LTgxYmQtMTYwMTFjZjk5YWVjIiB4bXBNTTpEb2N1 bWVudElEPSJ4bXAuZGlkOkU1NjczQjM2OEEzNDExRTZCOEJBQ0Y4Mzg3RTEzODkyIiB4bXBNTTpJ bnN0YW5jZUlEPSJ4bXAuaWlkOkU1NjczQjM1OEEzNDExRTZCOEJBQ0Y4Mzg3RTEzODkyIiB4bXA6 Q3JlYXRvclRvb2w9IkFkb2JlIFBob3Rvc2hvcCBDQyAyMDE1LjUgKFdpbmRvd3MpIj4gPHhtcE1N OkRlcml2ZWRGcm9tIHN0UmVmOmluc3RhbmNlSUQ9InhtcC5paWQ6ZGQwZjkyYzUtNzhhZi1jZTQ1 LTgxYmQtMTYwMTFjZjk5YWVjIiBzdFJlZjpkb2N1bWVudElEPSJ4bXAuZGlkOmRkMGY5MmM1LTc4 YWYtY2U0NS04MWJkLTE2MDExY2Y5OWFlYyIvPiA8L3JkZjpEZXNjcmlwdGlvbj4gPC9yZGY6UkRG PiA8L3g6eG1wbWV0YT4gPD94cGFja2V0IGVuZD0iciI/Pv/uAA5BZG9iZQBkwAAAAAH/2wCEAAYE BAQFBAYFBQYJBgUGCQsIBgYICwwKCgsKCgwQDAwMDAwMEAwODxAPDgwTExQUExMcGxsbHB8fHx8f Hx8fHx8BBwcHDQwNGBAQGBoVERUaHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fH//AABEIABwAPQMBEQACEQEDEQH/xABvAAABBAMAAAAAAAAAAAAAAAAAAQUG BwIDBAEBAAAAAAAAAAAAAAAAAAAAABAAAQQABAQEAgsBAAAAAAAAAQIDBAUAERIGITETFEEiFQfS I1FhcYGhMlIkRMQWhhEBAAAAAAAAAAAAAAAAAAAAAP/aAAwDAQACEQMRAD8AvqZ7q7OhzZMSS9IQ Yjy2JT/avqZbW2rSvU6lBSACOeeAljLzTzSHmVhxpxIW24k5pUlQzBBHgRgM8BBJ9fKuvcGwr3La wgxIlfGeaagyVsJ1uOOBRUBmOSRgI0bnZgfQwdx7qDrroYZSVzBrcJ0hKM2xq+7AWBU7PTXTEShc 2svRx6MuWp5o5gjigj68BombFRKmPyTfXTPXWpzoszloaRqOelCQPKkeAwEP6lp6f6V6vYaP9Z6b 3fcr7ntuhno6vPnxwGyohb2ntbpr6Y17NdKt7Bp5+YHlPJLitKyltI0KGk+XPANVgzV1Eyyqbe3s IMmnhsMbVaYcebDraY+XVbQ15XXFOghQVnkMBkbjcVPTUs6M5IkPbnpWa1hKlrWG7QZBp0hROnUh xRUfHTgJDWuwtsbptVTpC1xaqhgJfkuFTji9DjoKiTmpSlq/HAcO2d11d/cuXUySJG4C0+NvbfCH CmK2hClHUop0GQ6E+dWfAeUYBi2lY2E+zgW7twhVlHDk+7AkzFO9u2lRdjORFIEZrTmAkA+GYwDl TwLJhjZFouxsF3NzN6r7Lj7imExHUOSHWi0TpyCdORIzzwHT/J/7n+vgLVAA5YBChBUlRSCpOelR HEZ88sA2WG3YVhb1lnJW4VVJcXFjAgM9VxOjqKTlmVJTnp48M8Ax2+3N3J3TJu6KVAbRKisxnWpr brh+SpasxoKf14BBD91hxE2kB+nt5Px4AEL3VGoiZSAr4qyjyOP2+fAL2nuvw/e0vDl8iT8eAbv8 Lur0vPvYXrPrfrfU6bvb59Lp6NOev83HngLBwBgDAGAMAYAwBgP/2Q== ------=_Part_57353690_157338222.1496840388734-- ------=_Part_57353689_1234561196.1496840388734--

3 5

Active Directory authentication setup
by Todd Punderson 17 Jul '17

17 Jul '17

--_000_ff591869654646c7bc8df4c4af6d898fdoongaorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've been pulling my hair out over this one. Here's the outp= ut of ovirt-engine-extension-aaa-ldap-setup. Everything works fine if I use= "plain" but I don't really want to do that. I searched the error that's sh= own below and tried several different "fixes" but none of them helped. Thes= e are Server 2016 DCs. Not too sure where to go next. [ INFO ] Stage: Initializing [ INFO ] Stage: Environment setup Configuration files: ['/etc/ovirt-engine-extension-aaa-ldap-setup= .conf.d/10-packaging.conf'] Log file: /tmp/ovirt-engine-extension-aaa-ldap-setup-201707151709= 53-wfo1pk.log Version: otopi-1.6.2 (otopi-1.6.2-1.el7.centos) [ INFO ] Stage: Environment packages setup [ INFO ] Stage: Programs detection [ INFO ] Stage: Environment customization Welcome to LDAP extension configuration program Available LDAP implementations: 1 - 389ds 2 - 389ds RFC-2307 Schema 3 - Active Directory 4 - IBM Security Directory Server 5 - IBM Security Directory Server RFC-2307 Schema 6 - IPA 7 - Novell eDirectory RFC-2307 Schema 8 - OpenLDAP RFC-2307 Schema 9 - OpenLDAP Standard Schema 10 - Oracle Unified Directory RFC-2307 Schema 11 - RFC-2307 Schema (Generic) 12 - RHDS 13 - RHDS RFC-2307 Schema 14 - iPlanet Please select: 3 Please enter Active Directory Forest name: home.doonga.org [ INFO ] Resolving Global Catalog SRV record for home.doonga.org [ INFO ] Resolving LDAP SRV record for home.doonga.org NOTE: It is highly recommended to use secure protocol to access the LDA= P server. Protocol startTLS is the standard recommended method to do so. Only in cases in which the startTLS is not supported, fallback to= non standard ldaps protocol. Use plain for test environments only. Please select protocol to use (startTLS, ldaps, plain) [startTLS]= : ldaps Please select method to obtain PEM encoded CA certificate (File, = URL, Inline, System, Insecure): System [ INFO ] Resolving SRV record 'home.doonga.org' [ INFO ] Connecting to LDAP using 'ldaps://DC1.home.doonga.org:636' [WARNING] Cannot connect using 'ldaps://DC1.home.doonga.org:636': {'info': = 'TLS error -8157:Certificate extension not found.', 'desc': "Can't contact = LDAP server"} [ INFO ] Connecting to LDAP using 'ldaps://DC2.home.doonga.org:636' [WARNING] Cannot connect using 'ldaps://DC2.home.doonga.org:636': {'info': = 'TLS error -8157:Certificate extension not found.', 'desc': "Can't contact = LDAP server"} [ INFO ] Connecting to LDAP using 'ldaps://DC3.home.doonga.org:636' [WARNING] Cannot connect using 'ldaps://DC3.home.doonga.org:636': {'info': = 'TLS error -8157:Certificate extension not found.', 'desc': "Can't contact = LDAP server"} [ ERROR ] Cannot connect using any of available options Also: 2017-07-15 18:18:06 INFO otopi.plugins.ovirt_engine_extension_aaa_ldap.ldap= .common common._connectLDAP:391 Connecting to LDAP using 'ldap://DC2.home.d= oonga.org:389' 2017-07-15 18:18:06 INFO otopi.plugins.ovirt_engine_extension_aaa_ldap.ldap= .common common._connectLDAP:442 Executing startTLS 2017-07-15 18:18:06 DEBUG otopi.plugins.ovirt_engine_extension_aaa_ldap.lda= p.common common._connectLDAP:459 Exception Traceback (most recent call last): File "/usr/share/ovirt-engine-extension-aaa-ldap/setup/bin/../plugins/ovi= rt-engine-extension-aaa-ldap/ldap/common.py", line 443, in _connectLDAP c.start_tls_s() File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 564, i= n start_tls_s return self._ldap_call(self._l.start_tls_s) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in= _ldap_call result =3D func(*args,**kwargs) CONNECT_ERROR: {'info': 'TLS error -8157:Certificate extension not found.',= 'desc': 'Connect error'} 2017-07-15 18:18:06 WARNING otopi.plugins.ovirt_engine_extension_aaa_ldap.l= dap.common common._connectLDAP:463 Cannot connect using 'ldap://DC2.home.do= onga.org:389': {'info': 'TLS error -8157:Certificate extension not found.',= 'desc': 'Connect error'} 2017-07-15 18:18:06 INFO otopi.plugins.ovirt_engine_extension_aaa_ldap.ldap= .common common._connectLDAP:391 Connecting to LDAP using 'ldap://DC3.home.d= oonga.org:389' 2017-07-15 18:18:06 INFO otopi.plugins.ovirt_engine_extension_aaa_ldap.ldap= .common common._connectLDAP:442 Executing startTLS 2017-07-15 18:18:06 DEBUG otopi.plugins.ovirt_engine_extension_aaa_ldap.lda= p.common common._connectLDAP:459 Exception Traceback (most recent call last): File "/usr/share/ovirt-engine-extension-aaa-ldap/setup/bin/../plugins/ovi= rt-engine-extension-aaa-ldap/ldap/common.py", line 443, in _connectLDAP c.start_tls_s() File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 564, i= n start_tls_s return self._ldap_call(self._l.start_tls_s) File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in= _ldap_call result =3D func(*args,**kwargs) CONNECT_ERROR: {'info': 'TLS error -8157:Certificate extension not found.',= 'desc': 'Connect error'} Any help would be appreciated! Thanks --_000_ff591869654646c7bc8df4c4af6d898fdoongaorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Hi,<o:p></o:p>         &nbs= p;      I’ve been pulling my hair out over t= his one. Here’s the output of ovirt-engine-extension-aaa-ldap-setup. = Everything works fine if I use “plain” but I don’t really= want to do that. I searched the error that’s shown below and tried several different “fixes” but none of them helped. These= are Server 2016 DCs. Not too sure where to go next.<o:p></o:p> <o:p> </o:p> [ INFO  ] Stage: Initializing<o:p></o:p> [ INFO  ] Stage: Environment setup<o:p></o:p></= p>         &nbs= p; Configuration files: ['/etc/ovirt-engine-extension-aaa-ldap-setup.conf.d= /10-packaging.conf']<o:p></o:p>         &nbs= p; Log file: /tmp/ovirt-engine-extension-aaa-ldap-setup-20170715170953-wfo1= pk.log<o:p></o:p>         &nbs= p; Version: otopi-1.6.2 (otopi-1.6.2-1.el7.centos)<o:p></o:p> [ INFO  ] Stage: Environment packages setup<o:p= ></o:p> [ INFO  ] Stage: Programs detection<o:p></o:p><= /p> [ INFO  ] Stage: Environment customization<o:p>= </o:p>         &nbs= p; Welcome to LDAP extension configuration program<o:p></o:p>         &nbs= p; Available LDAP implementations:<o:p></o:p>         &nbs= p;  1 - 389ds<o:p></o:p>         &nbs= p;  2 - 389ds RFC-2307 Schema<o:p></o:p>         &nbs= p;  3 - Active Directory<o:p></o:p>         &nbs= p;  4 - IBM Security Directory Server<o:p></o:p>         &nbs= p;  5 - IBM Security Directory Server RFC-2307 Schema<o:p></o:p>         &nbs= p;  6 - IPA<o:p></o:p>         &nbs= p;  7 - Novell eDirectory RFC-2307 Schema<o:p></o:p>         &nbs= p;  8 - OpenLDAP RFC-2307 Schema<o:p></o:p>          &nb= sp; 9 - OpenLDAP Standard Schema<o:p></o:p>         &nbs= p; 10 - Oracle Unified Directory RFC-2307 Schema<o:p></o:p>         &nbs= p; 11 - RFC-2307 Schema (Generic)<o:p></o:p>         &nbs= p; 12 - RHDS<o:p></o:p>         &nbs= p; 13 - RHDS RFC-2307 Schema<o:p></o:p>         &nbs= p; 14 - iPlanet<o:p></o:p>         &nbs= p; Please select: 3<o:p></o:p>         &nbs= p; Please enter Active Directory Forest name: home.doonga.org<o:p></o:p></p= > [ INFO  ] Resolving Global Catalog SRV record f= or home.doonga.org<o:p></o:p> [ INFO  ] Resolving LDAP SRV record for home.do= onga.org<o:p></o:p>         &nbs= p; NOTE:<o:p></o:p>         &nbs= p; It is highly recommended to use secure protocol to access the LDAP serve= r.<o:p></o:p>         &nbs= p; Protocol startTLS is the standard recommended method to do so.<o:p></o:p= >         &nbs= p; Only in cases in which the startTLS is not supported, fallback to non st= andard ldaps protocol.<o:p></o:p>         &nbs= p; Use plain for test environments only.<o:p></o:p>         &nbs= p; Please select protocol to use (startTLS, ldaps, plain) [startTLS]: ldaps= <o:p></o:p>         &nbs= p; Please select method to obtain PEM encoded CA certificate (File, URL, In= line, System, Insecure): System<o:p></o:p> [ INFO  ] Resolving SRV record 'home.doonga.org= '<o:p></o:p> [ INFO  ] Connecting to LDAP using 'ldaps://DC1= .home.doonga.org:636'<o:p></o:p> [WARNING] Cannot connect using 'ldaps://DC1.home.doo= nga.org:636': {'info': 'TLS error -8157:Certificate extension not found.', = 'desc': "Can't contact LDAP server"}<o:p></o:p> [ INFO  ] Connecting to LDAP using 'ldaps://DC2= .home.doonga.org:636'<o:p></o:p> [WARNING] Cannot connect using 'ldaps://DC2.home.doo= nga.org:636': {'info': 'TLS error -8157:Certificate extension not found.', = 'desc': "Can't contact LDAP server"}<o:p></o:p> [ INFO  ] Connecting to LDAP using 'ldaps://DC3= .home.doonga.org:636'<o:p></o:p> [WARNING] Cannot connect using 'ldaps://DC3.home.doo= nga.org:636': {'info': 'TLS error -8157:Certificate extension not found.', = 'desc': "Can't contact LDAP server"}<o:p></o:p> [ ERROR ] Cannot connect using any of available opti= ons<o:p></o:p> <o:p> </o:p> Also:<o:p></o:p> 2017-07-15 18:18:06 INFO otopi.plugins.ovirt_engine_= extension_aaa_ldap.ldap.common common._connectLDAP:391 Connecting to LDAP u= sing 'ldap://DC2.home.doonga.org:389'<o:p></o:p> 2017-07-15 18:18:06 INFO otopi.plugins.ovirt_engine_= extension_aaa_ldap.ldap.common common._connectLDAP:442 Executing startTLS<o= :p></o:p> 2017-07-15 18:18:06 DEBUG otopi.plugins.ovirt_engine= _extension_aaa_ldap.ldap.common common._connectLDAP:459 Exception<o:p></o:p= > Traceback (most recent call last):<o:p></o:p>   File "/usr/share/ovirt-engine-extension-= aaa-ldap/setup/bin/../plugins/ovirt-engine-extension-aaa-ldap/ldap/common.p= y", line 443, in _connectLDAP<o:p></o:p>     c.start_tls_s()<o:p></o:p>   File "/usr/lib64/python2.7/site-packages= /ldap/ldapobject.py", line 564, in start_tls_s<o:p></o:p>     return self._ldap_call(self._l.st= art_tls_s)<o:p></o:p>   File "/usr/lib64/python2.7/site-packages= /ldap/ldapobject.py", line 99, in _ldap_call<o:p></o:p>     result =3D func(*args,**kwargs)<o= :p></o:p> CONNECT_ERROR: {'info': 'TLS error -8157:Certificate= extension not found.', 'desc': 'Connect error'}<o:p></o:p> 2017-07-15 18:18:06 WARNING otopi.plugins.ovirt_engi= ne_extension_aaa_ldap.ldap.common common._connectLDAP:463 Cannot connect us= ing 'ldap://DC2.home.doonga.org:389': {'info': 'TLS error -8157:Certificate= extension not found.', 'desc': 'Connect error'}<o:p></o:p> 2017-07-15 18:18:06 INFO otopi.plugins.ovirt_engine_= extension_aaa_ldap.ldap.common common._connectLDAP:391 Connecting to LDAP u= sing 'ldap://DC3.home.doonga.org:389'<o:p></o:p> 2017-07-15 18:18:06 INFO otopi.plugins.ovirt_engine_= extension_aaa_ldap.ldap.common common._connectLDAP:442 Executing startTLS<o= :p></o:p> 2017-07-15 18:18:06 DEBUG otopi.plugins.ovirt_engine= _extension_aaa_ldap.ldap.common common._connectLDAP:459 Exception<o:p></o:p= > Traceback (most recent call last):<o:p></o:p>   File "/usr/share/ovirt-engine-extension-= aaa-ldap/setup/bin/../plugins/ovirt-engine-extension-aaa-ldap/ldap/common.p= y", line 443, in _connectLDAP<o:p></o:p>     c.start_tls_s()<o:p></o:p>   File "/usr/lib64/python2.7/site-packages= /ldap/ldapobject.py", line 564, in start_tls_s<o:p></o:p>     return self._ldap_call(self._l.st= art_tls_s)<o:p></o:p>   File "/usr/lib64/python2.7/site-packages= /ldap/ldapobject.py", line 99, in _ldap_call<o:p></o:p>     result =3D func(*args,**kwargs)<o= :p></o:p> CONNECT_ERROR: {'info': 'TLS error -8157:Certificate= extension not found.', 'desc': 'Connect error'}<o:p></o:p> <o:p> </o:p> Any help would be appreciated!<o:p></o:p> Thanks<o:p></o:p> </div> </body> </html> --_000_ff591869654646c7bc8df4c4af6d898fdoongaorg_--

2 3

Engine HA-Issues
by Sven Achtelik 17 Jul '17

17 Jul '17

--_000_BFAB40933B3367488CE6299BAF8592D1014E52E495ACSOCRATESasl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, after running solid for several month my ovirt-engine started rebooting on = several hosts. I've looked into the hostend-engine -vm-status and it sees t= hat the engine is up on one host but not reachable. At the same time I can = access the gui and everything is working fine. After some time the engine i= s shutting down and all hosts are trying to start the engine until one is t= he winner, at least it looks like this. Any clues where to look at and find= the issue with the liveliness check ? ---------------------------------------------------------------------------= ----------------------------- --=3D=3D Host 1 status =3D=3D-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt-node01 Host ID : 1 Engine status : {"reason": "vm not running on this hos= t", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : 3eb33843 local_conf_timestamp : 17128 Host timestamp : 17113 Extra metadata (valid at timestamp): metadata_parse_version=3D1 metadata_feature_version=3D1 timestamp=3D17113 (Fri Jul 14 11:50:23 2017) host-id=3D1 score=3D3400 vm_conf_refresh_time=3D17128 (Fri Jul 14 11:50:38 2017) conf_on_shared_storage=3DTrue maintenance=3DFalse state=3DEngineDown stopped=3DFalse --=3D=3D Host 2 status =3D=3D-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt-node02.mgmt.lan Host ID : 2 Engine status : {"reason": "failed liveliness check", = "health": "bad", "vm": "up", "detail": "up"} Score : 3400 stopped : False Local maintenance : False crc32 : 2a8c86cc local_conf_timestamp : 523182 Host timestamp : 523167 Extra metadata (valid at timestamp): metadata_parse_version=3D1 metadata_feature_version=3D1 timestamp=3D523167 (Fri Jul 14 11:50:25 2017) host-id=3D2 score=3D3400 vm_conf_refresh_time=3D523182 (Fri Jul 14 11:50:40 2017) conf_on_shared_storage=3DTrue maintenance=3DFalse state=3DEngineStarting stopped=3DFalse --=3D=3D Host 3 status =3D=3D-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt-node03.mgmt.lan Host ID : 3 Engine status : {"reason": "vm not running on this hos= t", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : f8490d79 local_conf_timestamp : 527698 Host timestamp : 527683 Extra metadata (valid at timestamp): metadata_parse_version=3D1 metadata_feature_version=3D1 timestamp=3D527683 (Fri Jul 14 11:50:33 2017) host-id=3D3 score=3D3400 vm_conf_refresh_time=3D527698 (Fri Jul 14 11:50:47 2017) conf_on_shared_storage=3DTrue maintenance=3DFalse state=3DEngineDown stopped=3DFalse ---------------------------------------------------------------------------= ------------------- Thank you, Sven --_000_BFAB40933B3367488CE6299BAF8592D1014E52E495ACSOCRATESasl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"><head><meta http-equiv=3DContent-Type content= =3D"text/html; charset=3Dus-ascii"><meta name=3DGenerator content=3D"Micros= oft Word 15 (filtered medium)"><style></style></head><body lang=3DDE link=3D"#0563C1" v= link=3D"#954F72"><div class=3DWordSection1>Hi All, <o:= p></o:p><o:p> </o:p>= after running solid for several month my ovirt-engine st= arted rebooting on several hosts. I’ve looked into the hostend-engine= –vm-status and it sees that the engine is up on one host but not rea= chable. At the same time I can access the gui and everything is working fin= e. After some time the engine is shutting down and all hosts are trying to = start the engine until one is the winner, at least it looks like this. Any = clues where to look at and find the issue with the liveliness check ? <o:p>= </o:p><o:p> </o:p><= /span>-------------------------= ---------------------------------------------------------------------------= ----<o:p></o:p><o:p>&nbs= p;</o:p>--=3D=3D Host 1 = status =3D=3D--<o:p></o:p><o:p> </o:p>conf_= on_shared_storage          &nb= sp;  : True<o:p></o:p>Status up-to-date        &= nbsp;         : True<o:p></o:p></sp= an>Hostname   &n= bsp;           &nbsp= ;           : ovirt-node0= 1<o:p></o:p>Host ID&nbsp= ;            &n= bsp;           &nbsp= ;  : 1<o:p></o:p>En= gine status          &nbs= p;           : {"rea= son": "vm not running on this host", "health": &qu= ot;bad", "vm": "down", "detail": "u= nknown"}<o:p></o:p>= Score           &nbs= p;            &= nbsp;     : 3400<o:p></o:p>stopped       &nb= sp;            =         : False<o:p></o:p>Local maintenance   &nb= sp;            =   : False<o:p></o:p>crc32           &nb= sp;            =       : 3eb33843<o:p></o:p>local_conf_timestamp    &nb= sp;          : 17128<o:p></o:p= >Host timestamp &nb= sp;            &nbsp= ;      : 17113<o:p></o:p>Extra metadata (valid at timestamp):<o:p></= o:p>   &n= bsp;    metadata_parse_version=3D1<o:p></o:p>      &nb= sp; metadata_feature_version=3D1<o:p></o:p>=         timestamp=3D1= 7113 (Fri Jul 14 11:50:23 2017)<o:p></o:p><= span lang=3DEN-US>        host-id=3D1<o:= p></o:p>  &nbs= p;     score=3D3400<o:p></o:p>        vm_con= f_refresh_time=3D17128 (Fri Jul 14 11:50:38 2017)<o:p></o:p>      &nb= sp; conf_on_shared_storage=3DTrue<o:p></o:p>        maintenance= =3DFalse<o:p></o:p>&nbsp= ;       state=3DEngineDown<o:p></o:p><= /p>     &n= bsp;  stopped=3DFalse<o:p></o:p><o:p> </o:p><o:p> </o:p>-= -=3D=3D Host 2 status =3D=3D--<o:p></o:p><s= pan lang=3DEN-US><o:p> </o:p>conf_on_shared_storage       &= nbsp;     : True<o:p></o:p>Status up-to-date     &nbsp= ;            : True<= o:p></o:p>Hostname =             &nb= sp;            = : ovirt-node02.mgmt.lan<o:p></o:p>Host ID         &nb= sp;            =       : 2<o:p></o:p>Engine status      &nbsp= ;            &n= bsp;  : {"reason": "failed liveliness check", &quo= t;health": "bad", "vm": "up", "deta= il": "up"}<o:p></o:p>Score         &nbs= p;            &= nbsp;       : 3400<o:p></o:p>stopped     &nb= sp;            =           : False<o:p></o:p></= span>Local maintenance &nb= sp;            =     : False<o:p></o:p>crc32         &nb= sp;            =         : 2a8c86cc<o:p></o:p>= local_conf_timestamp  &nb= sp;            : 523= 182<o:p></o:p>Host times= tamp           &nbsp= ;         : 523167<o:p></o:p></span= >Extra metadata (valid at times= tamp):<o:p></o:p> &= nbsp;      metadata_parse_version=3D1<o:p></o:p></= span>    &n= bsp;   metadata_feature_version=3D1<o:p></o:p>        = timestamp=3D523167 (Fri Jul 14 11:50:25 2017)<o:p></o:p>        = host-id=3D2<o:p></o:p>&n= bsp;       score=3D3400<o:p></o:p>=      &nbsp= ;  vm_conf_refresh_time=3D523182 (Fri Jul 14 11:50:40 2017)<o:p></o:p>=     =     conf_on_shared_storage=3DTrue<o:p></o:p>      &nbs= p; maintenance=3DFalse<o:p></o:p>        state=3DEngineStarting<= o:p></o:p>  &n= bsp;     stopped=3DFalse<o:p></o:p><o:p> </o:p><o:p> </o:p><= span lang=3DEN-US>--=3D=3D Host 3 status =3D=3D--<o:p></o:p><o:p> </o:p>conf_on_shared_storage    =          : True<o:p></o:p></= p>Status up-to-date  &nbs= p;            &= nbsp;  : True<o:p></o:p>Hostname          &n= bsp;           &nbsp= ;    : ovirt-node03.mgmt.lan<o:p></o:p>Host ID      =             &nb= sp;         : 3<o:p></o:p></= p>Engine status   &n= bsp;           &nbsp= ;      : {"reason": "vm not running= on this host", "health": "bad", "vm": &= quot;down", "detail": "unknown"}<o:p></o:p>= Score    &n= bsp;            &nbs= p;            := 3400<o:p></o:p>stopped&= nbsp;           &nbs= p;            &= nbsp;  : False<o:p></o:p>Local maintenance        &nbs= p;         : False<o:p></o:p></span= >crc32    &= nbsp;           &nbs= p;             = : f8490d79<o:p></o:p>loc= al_conf_timestamp         &nbs= p;     : 527698<o:p></o:p>Host timestamp      &nb= sp;            =   : 527683<o:p></o:p>Extra metadata (valid at timestamp):<o:p></o:p>        metadat= a_parse_version=3D1<o:p></o:p>        metadata_feature_version= =3D1<o:p></o:p> &nb= sp;      timestamp=3D527683 (Fri Jul 14 11:50:33 2= 017)<o:p></o:p> &nb= sp;      host-id=3D3<o:p></o:p>        = score=3D3400<o:p></o:p>&= nbsp;       vm_conf_refresh_time=3D527698 (Fr= i Jul 14 11:50:47 2017)<o:p></o:p>        conf_on_shared_storage= =3DTrue<o:p></o:p> =        maintenance=3DFalse<o:p></o:p><= /p>     &n= bsp;  state=3DEngineDown<o:p></o:p><sp= an lang=3DEN-US>        stopped=3DFalse<= o:p></o:p><o:p> </o= :p>---------------------= -------------------------------------------------------------------------<o= :p></o:p>Thank you, <o:p= ></o:p>Sven <o:p></o:p><= /span></div></body></html>= --_000_BFAB40933B3367488CE6299BAF8592D1014E52E495ACSOCRATESasl_--

2 2

Installation oVirt node and engine on the same machine
by wc hung 17 Jul '17

17 Jul '17

Hi all, Could we install oVirt node and engine on the same machine? If we can do that, is there any guide to show the step?

4 6

[Ovirt 4.0] Cluster : Scheduling policy
by TranceWorldLogic . 16 Jul '17

16 Jul '17

Hi, Can some one help me how to select PinToHost policy in ovirt 4.0 ? I am lost in GUI. http://www.ovirt.org/develop/release-management/features/sla/scheduler-poli… Thanks, ~Rohit

2 2

Re: [ovirt-users] oVIRT 4.1.3 / iSCSI / VM Multiple Disks / Snapshot deletion issue.
by Benny Zlotnik 16 Jul '17

16 Jul '17

[Adding ovirt-users] On Sun, Jul 16, 2017 at 12:58 PM, Benny Zlotnik <bzlotnik(a)redhat.com> wrote: > We can see a lot of related errors in the engine log but we are unable > to correlate to the vdsm log. Do you have more hosts? If yes, please > attach their logs as well. > And just to be sure you were attempting to perform cold merge? > > On Fri, Jul 14, 2017 at 7:32 PM, Devin Acosta <devin(a)pabstatencio.com> wrote: >> >> You can get my logs from: >> >> https://files.linuxstack.cloud/s/NjoyMF11I38rJpH >> >> They were a little to big to attach to this e-mail. Would like to know if >> this is the similar bug that Richard indicated is a possibility. >> >> -- >> >> Devin Acosta >> Red Hat Certified Architect, LinuxStack >> 602-354-1220 || devin(a)linuxguru.co >> >> On July 14, 2017 at 9:18:08 AM, Devin Acosta (devin(a)pabstatencio.com) wrote: >> >> I have attached the logs. >> >> >> >> -- >> >> Devin Acosta >> Red Hat Certified Architect, LinuxStack >> 602-354-1220 || devin(a)linuxguru.co >> >> On July 13, 2017 at 9:22:03 AM, richard anthony falzini >> (richardfalzini(a)gmail.com) wrote: >> >> Hi, >> i have the same problem with gluster. >> this is a bug that i opened >> https://bugzilla.redhat.com/show_bug.cgi?id=1461029 . >> In the bug i used single disk vm but i start to notice the problem with >> multiple disk vm. >> >> >> 2017-07-13 0:07 GMT+02:00 Devin Acosta <devin(a)pabstatencio.com>: >>> >>> We are running a fresh install of oVIRT 4.1.3, using ISCSI, the VM in >>> question has multiple Disks (4 to be exact). It snapshotted OK while on >>> iSCSI however when I went to delete the single snapshot that existed it went >>> into Locked state and never came back. The deletion has been going for well >>> over an hour, and I am not convinced since the snapshot is less than 12 >>> hours old that it’s really doing anything. >>> >>> I have seen that doing some Googling indicates there might be some known >>> issues with iSCSI/Block Storage/Multiple Disk Snapshot issues. >>> >>> In the logs on the engine it shows: >>> >>> 2017-07-12 21:59:42,473Z INFO >>> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') >>> waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' >>> type:'PrepareMerge' to complete >>> 2017-07-12 21:59:52,480Z INFO >>> [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on >>> child command id: '75c535fd-4558-459a-9992-875c48578a97' >>> type:'ColdMergeSnapshotSingleDisk' to complete >>> 2017-07-12 21:59:52,483Z INFO >>> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') >>> waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' >>> type:'PrepareMerge' to complete >>> 2017-07-12 22:00:02,490Z INFO >>> [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler6) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on >>> child command id: '75c535fd-4558-459a-9992-875c48578a97' >>> type:'ColdMergeSnapshotSingleDisk' to complete >>> 2017-07-12 22:00:02,493Z INFO >>> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler6) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') >>> waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' >>> type:'PrepareMerge' to complete >>> 2017-07-12 22:00:12,498Z INFO >>> [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler3) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on >>> child command id: '75c535fd-4558-459a-9992-875c48578a97' >>> type:'ColdMergeSnapshotSingleDisk' to complete >>> 2017-07-12 22:00:12,501Z INFO >>> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler3) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') >>> waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' >>> type:'PrepareMerge' to complete >>> 2017-07-12 22:00:22,508Z INFO >>> [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler5) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on >>> child command id: '75c535fd-4558-459a-9992-875c48578a97' >>> type:'ColdMergeSnapshotSingleDisk' to complete >>> 2017-07-12 22:00:22,511Z INFO >>> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler5) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') >>> waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' >>> type:'PrepareMerge' to complete >>> >>> This is what I seen on the SPM when I grep’d the Snapshot ID. >>> >>> 2017-07-12 14:22:18,773-0700 INFO (jsonrpc/6) [vdsm.api] START >>> createVolume(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', >>> spUUID=u'00000001-0001-0001-0001-000000000311', >>> imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', size=u'107374182400', >>> volFormat=4, preallocate=2, diskType=2, >>> volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', desc=u'', >>> srcImgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', >>> srcVolUUID=u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', initialSize=None) >>> from=::ffff:10.4.64.7,60016, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e >>> (api:46) >>> 2017-07-12 14:22:19,095-0700 WARN (tasks/6) [root] File: >>> /rhev/data-center/00000001-0001-0001-0001-000000000311/0c02a758-4295-4199-97de-b041744b3b15/images/6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 >>> already removed (utils:120) >>> 2017-07-12 14:22:19,096-0700 INFO (tasks/6) [storage.Volume] Request to >>> create snapshot >>> 6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 of >>> volume >>> 6a887015-67cd-4f7b-b709-eef97142258d/0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae >>> (blockVolume:545) >>> 2017-07-12 14:22:19,676-0700 INFO (tasks/6) [storage.LVM] Change LV tags >>> (vg=0c02a758-4295-4199-97de-b041744b3b15, >>> lv=5921ba71-0f00-46cd-b0be-3c2ac1396845, delTags=['OVIRT_VOL_INITIALIZING'], >>> addTags=['MD_10', u'PU_0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', >>> u'IU_6a887015-67cd-4f7b-b709-eef97142258d']) (lvm:1344) >>> 2017-07-12 14:22:36,010-0700 INFO (jsonrpc/5) [vdsm.api] START >>> getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', >>> spUUID=u'00000001-0001-0001-0001-000000000311', >>> imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', >>> volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', options=None) >>> from=::ffff:10.4.64.7,59664, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e >>> (api:46) >>> 2017-07-12 14:22:36,077-0700 INFO (jsonrpc/5) [storage.VolumeManifest] >>> Info request: sdUUID=0c02a758-4295-4199-97de-b041744b3b15 >>> imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = >>> 5921ba71-0f00-46cd-b0be-3c2ac1396845 (volume:238) >>> 2017-07-12 14:22:36,185-0700 INFO (jsonrpc/5) [storage.VolumeManifest] >>> 0c02a758-4295-4199-97de-b041744b3b15/6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 >>> info is {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', >>> 'voltype': 'LEAF', 'description': '', 'parent': >>> '0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'format': 'COW', 'generation': 0, >>> 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499894539', >>> 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': >>> '1073741824', 'children': [], 'pool': '', 'capacity': '107374182400', >>> 'uuid': u'5921ba71-0f00-46cd-b0be-3c2ac1396845', 'truesize': '1073741824', >>> 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}} (volume:272) >>> 2017-07-12 14:22:36,186-0700 INFO (jsonrpc/5) [vdsm.api] FINISH >>> getVolumeInfo return={'info': {'status': 'OK', 'domain': >>> '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': >>> '', 'parent': '0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'format': 'COW', >>> 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': >>> '1499894539', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', >>> 'apparentsize': '1073741824', 'children': [], 'pool': '', 'capacity': >>> '107374182400', 'uuid': u'5921ba71-0f00-46cd-b0be-3c2ac1396845', 'truesize': >>> '1073741824', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}}} >>> from=::ffff:10.4.64.7,59664, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e >>> (api:52) >>> 2017-07-12 14:24:24,854-0700 INFO (jsonrpc/1) [vdsm.api] START >>> deleteVolume(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', >>> spUUID=u'00000001-0001-0001-0001-000000000311', >>> imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', >>> volumes=[u'5921ba71-0f00-46cd-b0be-3c2ac1396845'], postZero=u'false', >>> force=u'false', discard=False) from=::ffff:10.4.64.7,60016, >>> flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e (api:46) >>> 2017-07-12 14:24:25,010-0700 INFO (tasks/7) [storage.Volume] Request to >>> delete LV 5921ba71-0f00-46cd-b0be-3c2ac1396845 of image >>> 6a887015-67cd-4f7b-b709-eef97142258d in VG >>> 0c02a758-4295-4199-97de-b041744b3b15 (blockVolume:579) >>> 2017-07-12 14:24:25,130-0700 INFO (tasks/7) [storage.VolumeManifest] >>> sdUUID=0c02a758-4295-4199-97de-b041744b3b15 >>> imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = >>> 5921ba71-0f00-46cd-b0be-3c2ac1396845 legality = ILLEGAL (volume:398) >>> 2017-07-12 14:24:38,881-0700 INFO (jsonrpc/2) [vdsm.api] START >>> getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', >>> spUUID=u'00000001-0001-0001-0001-000000000311', >>> imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', >>> volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', options=None) >>> from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e >>> (api:46) >>> 2017-07-12 14:24:49,911-0700 INFO (jsonrpc/1) [vdsm.api] START >>> getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', >>> spUUID=u'00000001-0001-0001-0001-000000000311', >>> imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', >>> volUUID=u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', options=None) >>> from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e >>> (api:46) >>> 2017-07-12 14:24:49,912-0700 INFO (jsonrpc/1) [storage.VolumeManifest] >>> Info request: sdUUID=0c02a758-4295-4199-97de-b041744b3b15 >>> imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = >>> 0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae (volume:238) >>> 2017-07-12 14:24:50,036-0700 INFO (jsonrpc/1) [storage.VolumeManifest] >>> 0c02a758-4295-4199-97de-b041744b3b15/6a887015-67cd-4f7b-b709-eef97142258d/0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae >>> info is {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', >>> 'voltype': 'LEAF', 'description': '', 'parent': >>> '00000000-0000-0000-0000-000000000000', 'format': 'COW', 'generation': 0, >>> 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499885619', >>> 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': >>> '110729625600', 'children': [], 'pool': '', 'capacity': '107374182400', >>> 'uuid': u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'truesize': '110729625600', >>> 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}} (volume:272) >>> 2017-07-12 14:24:50,037-0700 INFO (jsonrpc/1) [vdsm.api] FINISH >>> getVolumeInfo return={'info': {'status': 'OK', 'domain': >>> '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': >>> '', 'parent': '00000000-0000-0000-0000-000000000000', 'format': 'COW', >>> 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': >>> '1499885619', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', >>> 'apparentsize': '110729625600', 'children': [], 'pool': '', 'capacity': >>> '107374182400', 'uuid': u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'truesize': >>> '110729625600', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}}} >>> from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e >>> (api:52) >>> >>> HELP, Right now I am starting to think Block Storage and oVIRT = BAD! >>> >>> >>> >>> >>> -- >>> >>> Devin Acosta >>> Red Hat Certified Architect, LinuxStack >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >>

1 0

oVIRT 4.1.3 / iSCSI / VM Multiple Disks / Snapshot deletion issue.
by Devin Acosta 14 Jul '17

14 Jul '17

We are running a fresh install of oVIRT 4.1.3, using ISCSI, the VM in question has multiple Disks (4 to be exact). It snapshotted OK while on iSCSI however when I went to delete the single snapshot that existed it went into Locked state and never came back. The deletion has been going for well over an hour, and I am not convinced since the snapshot is less than 12 hours old that it’s really doing anything. I have seen that doing some Googling indicates there might be some known issues with iSCSI/Block Storage/Multiple Disk Snapshot issues. In the logs on the engine it shows: 2017-07-12 21:59:42,473Z INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' type:'PrepareMerge' to complete 2017-07-12 21:59:52,480Z INFO [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on child command id: '75c535fd-4558-459a-9992-875c48578a97' type:'ColdMergeSnapshotSingleDisk' to complete 2017-07-12 21:59:52,483Z INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' type:'PrepareMerge' to complete 2017-07-12 22:00:02,490Z INFO [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] (DefaultQuartzScheduler6) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on child command id: '75c535fd-4558-459a-9992-875c48578a97' type:'ColdMergeSnapshotSingleDisk' to complete 2017-07-12 22:00:02,493Z INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (DefaultQuartzScheduler6) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' type:'PrepareMerge' to complete 2017-07-12 22:00:12,498Z INFO [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] (DefaultQuartzScheduler3) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on child command id: '75c535fd-4558-459a-9992-875c48578a97' type:'ColdMergeSnapshotSingleDisk' to complete 2017-07-12 22:00:12,501Z INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (DefaultQuartzScheduler3) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' type:'PrepareMerge' to complete 2017-07-12 22:00:22,508Z INFO [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] (DefaultQuartzScheduler5) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on child command id: '75c535fd-4558-459a-9992-875c48578a97' type:'ColdMergeSnapshotSingleDisk' to complete 2017-07-12 22:00:22,511Z INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (DefaultQuartzScheduler5) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' type:'PrepareMerge' to complete This is what I seen on the SPM when I grep’d the Snapshot ID. 2017-07-12 14:22:18,773-0700 INFO (jsonrpc/6) [vdsm.api] START createVolume(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', spUUID=u'00000001-0001-0001-0001-000000000311', imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', size=u'107374182400', volFormat=4, preallocate=2, diskType=2, volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', desc=u'', srcImgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', srcVolUUID=u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', initialSize=None) from=::ffff:10.4.64.7,60016, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e (api:46) 2017-07-12 14:22:19,095-0700 WARN (tasks/6) [root] File: /rhev/data-center/00000001-0001-0001-0001-000000000311/0c02a758-4295-4199-97de-b041744b3b15/images/6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 already removed (utils:120) 2017-07-12 14:22:19,096-0700 INFO (tasks/6) [storage.Volume] Request to create snapshot 6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 of volume 6a887015-67cd-4f7b-b709-eef97142258d/0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae (blockVolume:545) 2017-07-12 14:22:19,676-0700 INFO (tasks/6) [storage.LVM] Change LV tags (vg=0c02a758-4295-4199-97de-b041744b3b15, lv=5921ba71-0f00-46cd-b0be-3c2ac1396845, delTags=['OVIRT_VOL_INITIALIZING'], addTags=['MD_10', u'PU_0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', u'IU_6a887015-67cd-4f7b-b709-eef97142258d']) (lvm:1344) 2017-07-12 14:22:36,010-0700 INFO (jsonrpc/5) [vdsm.api] START getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', spUUID=u'00000001-0001-0001-0001-000000000311', imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', options=None) from=::ffff:10.4.64.7,59664, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e (api:46) 2017-07-12 14:22:36,077-0700 INFO (jsonrpc/5) [storage.VolumeManifest] Info request: sdUUID=0c02a758-4295-4199-97de-b041744b3b15 imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = 5921ba71-0f00-46cd-b0be-3c2ac1396845 (volume:238) 2017-07-12 14:22:36,185-0700 INFO (jsonrpc/5) [storage.VolumeManifest] 0c02a758-4295-4199-97de-b041744b3b15/6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 info is {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': '', 'parent': '0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'format': 'COW', 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499894539', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824', 'children': [], 'pool': '', 'capacity': '107374182400', 'uuid': u'5921ba71-0f00-46cd-b0be-3c2ac1396845', 'truesize': '1073741824', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}} (volume:272) 2017-07-12 14:22:36,186-0700 INFO (jsonrpc/5) [vdsm.api] FINISH getVolumeInfo return={'info': {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': '', 'parent': '0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'format': 'COW', 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499894539', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824', 'children': [], 'pool': '', 'capacity': '107374182400', 'uuid': u'5921ba71-0f00-46cd-b0be-3c2ac1396845', 'truesize': '1073741824', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}}} from=::ffff:10.4.64.7,59664, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e (api:52) 2017-07-12 14:24:24,854-0700 INFO (jsonrpc/1) [vdsm.api] START deleteVolume(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', spUUID=u'00000001-0001-0001-0001-000000000311', imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', volumes=[u'5921ba71-0f00-46cd-b0be-3c2ac1396845'], postZero=u'false', force=u'false', discard=False) from=::ffff:10.4.64.7,60016, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e (api:46) 2017-07-12 14:24:25,010-0700 INFO (tasks/7) [storage.Volume] Request to delete LV 5921ba71-0f00-46cd-b0be-3c2ac1396845 of image 6a887015-67cd-4f7b-b709-eef97142258d in VG 0c02a758-4295-4199-97de-b041744b3b15 (blockVolume:579) 2017-07-12 14:24:25,130-0700 INFO (tasks/7) [storage.VolumeManifest] sdUUID=0c02a758-4295-4199-97de-b041744b3b15 imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = 5921ba71-0f00-46cd-b0be-3c2ac1396845 legality = ILLEGAL (volume:398) 2017-07-12 14:24:38,881-0700 INFO (jsonrpc/2) [vdsm.api] START getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', spUUID=u'00000001-0001-0001-0001-000000000311', imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', options=None) from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e (api:46) 2017-07-12 14:24:49,911-0700 INFO (jsonrpc/1) [vdsm.api] START getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', spUUID=u'00000001-0001-0001-0001-000000000311', imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', volUUID=u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', options=None) from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e (api:46) 2017-07-12 14:24:49,912-0700 INFO (jsonrpc/1) [storage.VolumeManifest] Info request: sdUUID=0c02a758-4295-4199-97de-b041744b3b15 imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = 0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae (volume:238) 2017-07-12 14:24:50,036-0700 INFO (jsonrpc/1) [storage.VolumeManifest] 0c02a758-4295-4199-97de-b041744b3b15/6a887015-67cd-4f7b-b709-eef97142258d/0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae info is {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': '', 'parent': '00000000-0000-0000-0000-000000000000', 'format': 'COW', 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499885619', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': '110729625600', 'children': [], 'pool': '', 'capacity': '107374182400', 'uuid': u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'truesize': '110729625600', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}} (volume:272) 2017-07-12 14:24:50,037-0700 INFO (jsonrpc/1) [vdsm.api] FINISH getVolumeInfo return={'info': {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': '', 'parent': '00000000-0000-0000-0000-000000000000', 'format': 'COW', 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499885619', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': '110729625600', 'children': [], 'pool': '', 'capacity': '107374182400', 'uuid': u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'truesize': '110729625600', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}}} from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e (api:52) HELP, Right now I am starting to think Block Storage and oVIRT = BAD! -- Devin Acosta Red Hat Certified Architect, LinuxStack

4 5