- Users - oVirt List Archives

test email
by Abi Askushi 19 Jul '17

19 Jul '17

several days without receiving any email from this list. please test back. Abi

2 1

[ANN] oVirt 4.1.4 Second Release Candidate is now available
by Sandro Bonazzola 19 Jul '17

19 Jul '17

The oVirt Project is pleased to announce the availability of the Second Release Candidate of oVirt 4.1.4 for testing, as of July 19th, 2017 This is pre-release software. Please take a look at our community page[1] to know how to ask questions and interact with developers and users. All issues or bugs should be reported via oVirt Bugzilla[2]. This pre-release should not to be used in production. This update is the second release candidate of the fourth in a series of stabilization updates to the 4.1 series. 4.1.4 brings more than 20 enhancements and more than 80 bugfixes, including more than 50 high or urgent severity fixes, on top of oVirt 4.1 series This release is available now for: * Fedora 24 (tech preview) * Red Hat Enterprise Linux 7.3 or later * CentOS Linux (or similar) 7.3 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.3 or later * CentOS Linux (or similar) 7.3 or later * oVirt Node 4.1 * Fedora 24 (tech preview) See the release notes draft [3] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is already available - oVirt Live is already available[4] - oVirt Node is already available[4] Additional Resources: * Read more about the oVirt 4.1.4 release highlights: http://www.ovirt.org/release/4.1.4/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] https://www.ovirt.org/community/ [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt [3] http://www.ovirt.org/release/4.1.4/ [4] resources.ovirt.org/pub/ovirt-4.1-pre/iso/ -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

"remove" option greyed out on Permissions tab
by Ian Neilsen 19 Jul '17

19 Jul '17

Hey guys Ive just noticed that I am unable to choose the "remove" option on any "Permissions" tab in Ovirt Self-hosted 4.1. Anyone have a suggestion on how to fix this. Im logged in as admin, original admin created during installation. Thanks in Advance -- Ian Neilsen Mobile: 0424 379 762 Linkedin: http://au.linkedin.com/in/ianneilsen Twitter : ineilsen

1 1

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

oVirt Metrics
by Arsène Gschwind 14 Jul '17

14 Jul '17

This is a multi-part message in MIME format. --------------9A99E910BE6E6C7F1C6C0B2C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, I'm trying to setup oVirt metrics as described at https://www.ovirt.org/develop/release-management/features/engine/metrics-st… using SSO. My oVirt installation is based on Version: 4.1.3.5-1.el7.centos. I'm missing the SSO tool called ovirt-register-sso-client as written in the doc to register new SSO client. I couldn't figure out which package contains that tool, is it included in the latest distribution ? Thanks for any help. rgds, Arsène -- *Arsène Gschwind* Fa. Sapify AG im Auftrag der Universität Basel IT Services Klingelbergstr. 70 | CH-4056 Basel | Switzerland Tel. +41 79 449 25 63 | http://its.unibas.ch <http://its.unibas.ch/> ITS-ServiceDesk: support-its(a)unibas.ch | +41 61 267 14 11 --------------9A99E910BE6E6C7F1C6C0B2C 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"> Hi all, I'm trying to setup oVirt metrics as described at <a class="moz-txt-link-freetext" href="https://www.ovirt.org/develop/release-management/features/engine/metrics-st…">https://www.ovirt.org/develop/release-management/features/engine/metrics-st…</a> using SSO. My oVirt installation is based on Version: 4.1.3.5-1.el7.centos. I'm missing the SSO tool called ovirt-register-sso-client as written in the doc to register new SSO client. I couldn't figure out which package contains that tool, is it included in the latest distribution ? Thanks for any help. rgds, Arsène <div class="moz-signature">-- Arsène Gschwind Fa. Sapify AG im Auftrag der Universität Basel IT Services Klingelbergstr. 70 | CH-4056 Basel | Switzerland Tel. +41 79 449 25 63 | <a href="http://its.unibas.ch/"> http://its.unibas.ch </a> ITS-ServiceDesk: <a class="moz-txt-link-abbreviated" href="mailto:support-its@unibas.ch">support-its(a)unibas.ch</a> | +41 61 267 14 11 </div> </body> </html> --------------9A99E910BE6E6C7F1C6C0B2C--

3 2

Fwd: Windows USB Redirection
by Abi Askushi 14 Jul '17

14 Jul '17

Hi All, I have Ovirt 4.1 with 3 nodes on top glusterfs. I Have 2 VMs: Windows 2016 64bit and Windows 10 64bit When I attach a USB flash disk to a VM (from host devices) the VM cannot see the USB drive and report driver issue at device manager (see attached). This happens with both VMs when tested. When testing with Windows 7 or Windows XP USB is attached and accessed normally. Have you encountered such issue? I have installed latest guest tools on both VMs. Many thanx

2 3

Removing iSCSI domain: host side part
by Gianluca Cecchi 14 Jul '17

14 Jul '17

Hello, I have cleanly removed an iSCSI domain from oVirt. There is another one (connecting to another storage array) that is the master domain. But I see that oVirt hosts still maintain the iscsi session to the LUN. So I want to clean from os point of view before removing the LUN itself from storage. At the moment I still see the multipath lun on both hosts [root@ov301 network-scripts]# multipath -l . . . 364817197b5dfd0e5538d959702249b1c dm-2 EQLOGIC ,100E-00 size=4.0T features='0' hwhandler='0' wp=rw `-+- policy='round-robin 0' prio=0 status=active |- 9:0:0:0 sde 8:64 active undef running `- 10:0:0:0 sdf 8:80 active undef running and [root@ov301 network-scripts]# iscsiadm -m session tcp: [1] 10.10.100.9:3260,1 iqn.2001-05.com.equallogic:4-771816-e5d0dfb59-1c9b240297958d53-ovsd3910 (non-flash) tcp: [2] 10.10.100.9:3260,1 iqn.2001-05.com.equallogic:4-771816-e5d0dfb59-1c9b240297958d53-ovsd3910 (non-flash) . . . Do I have to clean the multipath paths and multipath device and then iSCSI logout, or is it sufficient to iSCSI logout and the multipath device and its path will be cleanly removed from OS point of view? I would like not to have multipath device in stale condition. Thanks Gianluca

2 2

Failed to create template
by aduckers 13 Jul '17

13 Jul '17

I’m running 4.1 with a hosted engine, using FC SAN storage. I’ve uploaded a qcow2 image, then created a VM and attached that image. When trying to create a template from that VM, we get failures with: failed: low level image copy failed VDSM command DeleteImageGroupVDS failed: Image does not exist in domain failed to create template What should I be looking at to resolve this? Anyone recognize this issue? Thanks

3 11

Re: [ovirt-users] Detach disk from one VM, attach to another VM
by Victor José Acosta Domínguez 13 Jul '17

13 Jul '17

Hello Yes it is possible, you must remove from first VM's configuration (be careful, do not delete your virtual disk) After that you can attach ad that disk to another VM Process should be: - Detach disk from VM1 - Delete disk from VM1's configuration - Attach disk to VM2 Victor Acosta

3 2

2 hosts starting the engine at the same time?
by Gianluca Cecchi 13 Jul '17

13 Jul '17

Hello. I'm on 4.1.3 with self hosted engine and glusterfs as storage. I updated the kernel on engine so I executed these steps: - enable global maintenace from the web admin gui - wait some minutes - shutdown the engine vm from inside its OS - wait some minutes - execute on one host [root@ovirt02 ~]# hosted-engine --set-maintenance --mode=none I see that the qemu-kvm process for the engine starts on two hosts and then on one of them it gets a "kill -15" and stops Is it expected behaviour? It seems somehow dangerous to me.. - when in maintenance [root@ovirt02 ~]# hosted-engine --vm-status !! Cluster is in GLOBAL MAINTENANCE mode !! --== Host 1 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt01.localdomain.local Host ID : 1 Engine status : {"health": "good", "vm": "up", "detail": "up"} Score : 2597 stopped : False Local maintenance : False crc32 : 7931c5c3 local_conf_timestamp : 19811 Host timestamp : 19794 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=19794 (Sun Jul 9 21:31:50 2017) host-id=1 score=2597 vm_conf_refresh_time=19811 (Sun Jul 9 21:32:06 2017) conf_on_shared_storage=True maintenance=False state=GlobalMaintenance stopped=False --== Host 2 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : 192.168.150.103 Host ID : 2 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : 616ceb02 local_conf_timestamp : 2829 Host timestamp : 2812 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=2812 (Sun Jul 9 21:31:52 2017) host-id=2 score=3400 vm_conf_refresh_time=2829 (Sun Jul 9 21:32:09 2017) conf_on_shared_storage=True maintenance=False state=GlobalMaintenance stopped=False --== Host 3 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt03.localdomain.local Host ID : 3 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : 871204b2 local_conf_timestamp : 24584 Host timestamp : 24567 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=24567 (Sun Jul 9 21:31:52 2017) host-id=3 score=3400 vm_conf_refresh_time=24584 (Sun Jul 9 21:32:09 2017) conf_on_shared_storage=True maintenance=False state=GlobalMaintenance stopped=False !! Cluster is in GLOBAL MAINTENANCE mode !! [root@ovirt02 ~]# - then I exit global maintenance [root@ovirt02 ~]# hosted-engine --set-maintenance --mode=none - During monitoring of status, at some point I see "EngineStart" on both host2 and host3 [root@ovirt02 ~]# hosted-engine --vm-status --== Host 1 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt01.localdomain.local Host ID : 1 Engine status : {"reason": "bad vm status", "health": "bad", "vm": "down", "detail": "down"} Score : 3230 stopped : False Local maintenance : False crc32 : 25cadbfb local_conf_timestamp : 20055 Host timestamp : 20040 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=20040 (Sun Jul 9 21:35:55 2017) host-id=1 score=3230 vm_conf_refresh_time=20055 (Sun Jul 9 21:36:11 2017) conf_on_shared_storage=True maintenance=False state=EngineDown stopped=False --== Host 2 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : 192.168.150.103 Host ID : 2 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : e6951128 local_conf_timestamp : 3075 Host timestamp : 3058 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=3058 (Sun Jul 9 21:35:59 2017) host-id=2 score=3400 vm_conf_refresh_time=3075 (Sun Jul 9 21:36:15 2017) conf_on_shared_storage=True maintenance=False state=EngineStart stopped=False --== Host 3 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt03.localdomain.local Host ID : 3 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : 382efde5 local_conf_timestamp : 24832 Host timestamp : 24816 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=24816 (Sun Jul 9 21:36:01 2017) host-id=3 score=3400 vm_conf_refresh_time=24832 (Sun Jul 9 21:36:17 2017) conf_on_shared_storage=True maintenance=False state=EngineStart stopped=False [root@ovirt02 ~]# and then [root@ovirt02 ~]# hosted-engine --vm-status --== Host 1 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt01.localdomain.local Host ID : 1 Engine status : {"reason": "bad vm status", "health": "bad", "vm": "down", "detail": "down"} Score : 3253 stopped : False Local maintenance : False crc32 : 3fc39f31 local_conf_timestamp : 20087 Host timestamp : 20070 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=20070 (Sun Jul 9 21:36:26 2017) host-id=1 score=3253 vm_conf_refresh_time=20087 (Sun Jul 9 21:36:43 2017) conf_on_shared_storage=True maintenance=False state=EngineDown stopped=False --== Host 2 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : 192.168.150.103 Host ID : 2 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : 4a05c31e local_conf_timestamp : 3109 Host timestamp : 3079 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=3079 (Sun Jul 9 21:36:19 2017) host-id=2 score=3400 vm_conf_refresh_time=3109 (Sun Jul 9 21:36:49 2017) conf_on_shared_storage=True maintenance=False state=EngineStarting stopped=False --== Host 3 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt03.localdomain.local Host ID : 3 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : 382efde5 local_conf_timestamp : 24832 Host timestamp : 24816 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=24816 (Sun Jul 9 21:36:01 2017) host-id=3 score=3400 vm_conf_refresh_time=24832 (Sun Jul 9 21:36:17 2017) conf_on_shared_storage=True maintenance=False state=EngineStart stopped=False [root@ovirt02 ~]# and [root@ovirt02 ~]# hosted-engine --vm-status --== Host 1 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt01.localdomain.local Host ID : 1 Engine status : {"reason": "bad vm status", "health": "bad", "vm": "down", "detail": "down"} Score : 3253 stopped : False Local maintenance : False crc32 : 3fc39f31 local_conf_timestamp : 20087 Host timestamp : 20070 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=20070 (Sun Jul 9 21:36:26 2017) host-id=1 score=3253 vm_conf_refresh_time=20087 (Sun Jul 9 21:36:43 2017) conf_on_shared_storage=True maintenance=False state=EngineDown stopped=False --== Host 2 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : 192.168.150.103 Host ID : 2 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : 4a05c31e local_conf_timestamp : 3109 Host timestamp : 3079 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=3079 (Sun Jul 9 21:36:19 2017) host-id=2 score=3400 vm_conf_refresh_time=3109 (Sun Jul 9 21:36:49 2017) conf_on_shared_storage=True maintenance=False state=EngineStarting stopped=False --== Host 3 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt03.localdomain.local Host ID : 3 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : fc1e8cf9 local_conf_timestamp : 24868 Host timestamp : 24836 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=24836 (Sun Jul 9 21:36:21 2017) host-id=3 score=3400 vm_conf_refresh_time=24868 (Sun Jul 9 21:36:53 2017) conf_on_shared_storage=True maintenance=False state=EngineStarting stopped=False [root@ovirt02 ~]# and at the end Host3 goes to "ForceStop" for the engine [root@ovirt02 ~]# hosted-engine --vm-status --== Host 1 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt01.localdomain.local Host ID : 1 Engine status : {"reason": "bad vm status", "health": "bad", "vm": "down", "detail": "down"} Score : 3312 stopped : False Local maintenance : False crc32 : e9d53432 local_conf_timestamp : 20120 Host timestamp : 20102 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=20102 (Sun Jul 9 21:36:58 2017) host-id=1 score=3312 vm_conf_refresh_time=20120 (Sun Jul 9 21:37:15 2017) conf_on_shared_storage=True maintenance=False state=EngineDown stopped=False --== Host 2 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : 192.168.150.103 Host ID : 2 Engine status : {"reason": "bad vm status", "health": "bad", "vm": "up", "detail": "powering up"} Score : 3400 stopped : False Local maintenance : False crc32 : 7d2330be local_conf_timestamp : 3141 Host timestamp : 3124 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=3124 (Sun Jul 9 21:37:04 2017) host-id=2 score=3400 vm_conf_refresh_time=3141 (Sun Jul 9 21:37:21 2017) conf_on_shared_storage=True maintenance=False state=EngineStarting stopped=False --== Host 3 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt03.localdomain.local Host ID : 3 Engine status : {"reason": "Storage of VM is locked. Is another host already starting the VM?", "health": "bad", "vm": "already_locked", "detail": "down"} Score : 3400 stopped : False Local maintenance : False crc32 : 179825e8 local_conf_timestamp : 24900 Host timestamp : 24883 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=24883 (Sun Jul 9 21:37:08 2017) host-id=3 score=3400 vm_conf_refresh_time=24900 (Sun Jul 9 21:37:24 2017) conf_on_shared_storage=True maintenance=False state=EngineForceStop stopped=False [root@ovirt02 ~]# Comparing /var/log/libvirt/qemu/HostedEngine of host2 and host3 Host2: 2017-07-09 19:36:36.094+0000: starting up libvirt version: 2.0.0, package: 10.el7_3.9 (CentOS BuildSystem <http://bugs.centos.org>, 2017-05-25-20:52:28, c1bm.rdu2.centos.org) qemu version: 2.6.0 (qemu-kvm-ev-2.6.0-28.el7.10.1), hostname: ovirt02.localdomain.local ... char device redirected to /dev/pts/1 (label charconsole0) warning: host doesn't support requested feature: CPUID.07H:EBX.erms [bit 9] Host3: 2017-07-09 19:36:38.143+0000: starting up libvirt version: 2.0.0, package: 10.el7_3.9 (CentOS BuildSystem <http://bu gs.centos.org>, 2017-05-25-20:52:28, c1bm.rdu2.centos.org) qemu version: 2.6.0 (qemu-kvm-ev-2.6.0-28.el7.10.1), hos tname: ovirt03.localdomain.local ... char device redirected to /dev/pts/1 (label charconsole0) 2017-07-09 19:36:38.584+0000: shutting down 2017-07-09T19:36:38.589729Z qemu-kvm: terminating on signal 15 from pid 1835 any comment? Is it only a matter of powering on the VM in paused mode before starting the OS itself, or do I risk corruption due to 2 qemu-kvm processes trying to start the engine vm os? Thanks, Gianluca

4 16

Installation of oVirt 4.1, Gluster Storage and Hosted Engine
by Simone Marchioni 13 Jul '17

13 Jul '17

Hi to all, I have an old installation of oVirt 3.3 with the Engine on a separate server. I wanted to test the last oVirt 4.1 with Gluster Storage and Hosted Engine. Followed the following tutorial: http://www.ovirt.org/blog/2017/04/up-and-running-with-ovirt-4.1-and-gluster… I have 3 hosts as shown in the tutorial. Installed CentOS 7.3, the oVirt 4.1 repo and all required packages. Configured passwordless ssh as stated. Then I log in cockpit web interface, selected "Hosted Engine with Gluster" and hit the Start button. Configured the parameters as shown in the tutorial. In the last step (5) the Generated Gdeply configuration (note: replaced the real domain with "domain.it"): #gdeploy configuration generated by cockpit-gluster plugin [hosts] ha1.domain.it ha2.domain.it ha3.domain.it [script1] action=execute ignore_script_errors=no file=/usr/share/ansible/gdeploy/scripts/grafton-sanity-check.sh -d sdb -h ha1.domain.it,ha2.domain.it,ha3.domain.it [disktype] raid6 [diskcount] 12 [stripesize] 256 [service1] action=enable service=chronyd [service2] action=restart service=chronyd [shell2] action=execute command=vdsm-tool configure --force [script3] action=execute file=/usr/share/ansible/gdeploy/scripts/disable-multipath.sh [pv1] action=create devices=sdb ignore_pv_errors=no [vg1] action=create vgname=gluster_vg_sdb pvname=sdb ignore_vg_errors=no [lv1:{ha1.domain.it,ha2.domain.it}] action=create poolname=gluster_thinpool_sdb ignore_lv_errors=no vgname=gluster_vg_sdb lvtype=thinpool size=110GB poolmetadatasize=1GB [lv2:ha3.domain.it] action=create poolname=gluster_thinpool_sdb ignore_lv_errors=no vgname=gluster_vg_sdb lvtype=thinpool size=80GB poolmetadatasize=1GB [lv3:{ha1.domain.it,ha2.domain.it}] action=create lvname=gluster_lv_engine ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/engine lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=50GB [lv4:ha3.domain.it] action=create lvname=gluster_lv_engine ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/engine lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=20GB [lv5:{ha1.domain.it,ha2.domain.it}] action=create lvname=gluster_lv_data ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/data lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=20GB [lv6:ha3.domain.it] action=create lvname=gluster_lv_data ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/data lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=20GB [lv7:{ha1.domain.it,ha2.domain.it}] action=create lvname=gluster_lv_export ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/export lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=20GB [lv8:ha3.domain.it] action=create lvname=gluster_lv_export ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/export lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=20GB [lv9:{ha1.domain.it,ha2.domain.it}] action=create lvname=gluster_lv_iso ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/iso lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=20GB [lv10:ha3.domain.it] action=create lvname=gluster_lv_iso ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/iso lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=20GB [selinux] yes [service3] action=restart service=glusterd slice_setup=yes [firewalld] action=add ports=111/tcp,2049/tcp,54321/tcp,5900/tcp,5900-6923/tcp,5666/tcp,16514/tcp services=glusterfs [script2] action=execute file=/usr/share/ansible/gdeploy/scripts/disable-gluster-hooks.sh [shell3] action=execute command=usermod -a -G gluster qemu [volume1] action=create volname=engine transport=tcp replica=yes replica_count=3 key=group,storage.owner-uid,storage.owner-gid,network.ping-timeout,performance.strict-o-direct,network.remote-dio,cluster.granular-entry-heal value=virt,36,36,30,on,off,enable brick_dirs=ha1.domain.it:/gluster_bricks/engine/engine,ha2.domain.it:/gluster_bricks/engine/engine,ha3.domain.it:/gluster_bricks/engine/engine ignore_volume_errors=no arbiter_count=1 [volume2] action=create volname=data transport=tcp replica=yes replica_count=3 key=group,storage.owner-uid,storage.owner-gid,network.ping-timeout,performance.strict-o-direct,network.remote-dio,cluster.granular-entry-heal value=virt,36,36,30,on,off,enable brick_dirs=ha1.domain.it:/gluster_bricks/data/data,ha2.domain.it:/gluster_bricks/data/data,ha3.domain.it:/gluster_bricks/data/data ignore_volume_errors=no arbiter_count=1 [volume3] action=create volname=export transport=tcp replica=yes replica_count=3 key=group,storage.owner-uid,storage.owner-gid,network.ping-timeout,performance.strict-o-direct,network.remote-dio,cluster.granular-entry-heal value=virt,36,36,30,on,off,enable brick_dirs=ha1.domain.it:/gluster_bricks/export/export,ha2.domain.it:/gluster_bricks/export/export,ha3.domain.it:/gluster_bricks/export/export ignore_volume_errors=no arbiter_count=1 [volume4] action=create volname=iso transport=tcp replica=yes replica_count=3 key=group,storage.owner-uid,storage.owner-gid,network.ping-timeout,performance.strict-o-direct,network.remote-dio,cluster.granular-entry-heal value=virt,36,36,30,on,off,enable brick_dirs=ha1.domain.it:/gluster_bricks/iso/iso,ha2.domain.it:/gluster_bricks/iso/iso,ha3.domain.it:/gluster_bricks/iso/iso ignore_volume_errors=no arbiter_count=1 When I hit "Deploy" button the Deployment fails with the following error: PLAY [gluster_servers] ********************************************************* TASK [Run a shell script] ****************************************************** fatal: [ha1.domain.it]: FAILED! => {"failed": true, "msg": "The conditional check 'result.rc != 0' failed. The error was: error while evaluating conditional (result.rc != 0): 'dict object' has no attribute 'rc'"} fatal: [ha2.domain.it]: FAILED! => {"failed": true, "msg": "The conditional check 'result.rc != 0' failed. The error was: error while evaluating conditional (result.rc != 0): 'dict object' has no attribute 'rc'"} fatal: [ha3.domain.it]: FAILED! => {"failed": true, "msg": "The conditional check 'result.rc != 0' failed. The error was: error while evaluating conditional (result.rc != 0): 'dict object' has no attribute 'rc'"} to retry, use: --limit @/tmp/tmpcV3lam/run-script.retry PLAY RECAP ********************************************************************* ha1.domain.it : ok=0 changed=0 unreachable=0 failed=1 ha2.domain.it : ok=0 changed=0 unreachable=0 failed=1 ha3.domain.it : ok=0 changed=0 unreachable=0 failed=1 What I'm doing wrong? Maybe I need to initializa glusterfs in some way... What are the logs used to log the status of this deployment so I can check the errors? Thanks in advance! Simone

3 18

Problems with vdsm-tool and ovn-config option
by Gianluca Cecchi 13 Jul '17

13 Jul '17

Hello, on February I installed OVN controller on some hypervisors (CentOS 7.3 hosts). At that time the vdsm-tool command was part of vdsm-python-4.19.4-1.el7.centos.noarch I was able to configure my hosts with command vdsm-tool ovn-config OVN_central_server_IP local_OVN_tunneling_IP as described here: https://www.ovirt.org/blog/2016/11/ovirt-provider-ovn/ and now here https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/ht… I have 2 hosts that I added later and on which I want to configure OVN external network provider too. But now, with vdsm-python at version vdsm-python-4.19.10.1-1.el7.centos.noarch I get an usage error trying to execute the command [root@ov301 ~]# vdsm-tool ovn-config 10.4.192.43 10.4.167.41 Usage: /bin/vdsm-tool [options] <action> [arguments] Valid options: -h, --help Show this help menu. -l, --logfile <path> ... Also, the changelog of the package seems quite broken: [root@ov301 ~]# rpm -q --changelog vdsm-python * Wed Aug 03 2016 Yaniv Bronhaim <ybronhei(a)redhat.com> - 4.18.999 - Re-review of vdsm.spec to return it to fedora Bug #1361659 * Sun Oct 13 2013 Yaniv Bronhaim <ybronhei(a)redhat.com> - 4.13.0 - Removing vdsm-python-cpopen from the spec - Adding dependency on formal cpopen package * Sun Apr 07 2013 Yaniv Bronhaim <ybronhei(a)redhat.com> - 4.9.0-1 - Adding cpopen package * Wed Oct 12 2011 Federico Simoncelli <fsimonce(a)redhat.com> - 4.9.0-0 - Initial upstream release * Thu Nov 02 2006 Simon Grinberg <simong(a)qumranet.com> - 0.0-1 - Initial build [root@ov301 ~]# How can I configure OVN? Thanks in advance, Gianluca

1 1

Manually moving disks from FC to iSCSI
by Gianluca Cecchi 13 Jul '17

13 Jul '17

Hello, I have a source oVirt environment with storage domain on FC I have a destination oVirt environment with storage domain on iSCSI The two environments can communicate only via the network of their respective hypervisors. The source environment, in particular, is almost isolated and I cannot attach an export domain to it or something similar. So I'm going to plan a direct move through dd of the disks of some VMs The workflow would be On destination create a new VM with same config and same number of disks of the same size of corresponding source ones. Also I think same allocation policy (thin provision vs preallocated) Using lvs -o+lv_tags I can detect the names of my origin and destination LVs, corresponding to the disks When a VM is powered down, the LV that maps the disk will be not open, so I have to force its activation (both on source and on destination) lvchange --config 'global {use_lvmetad=0}' -ay vgname/lvname copy source disk with dd through network (I use gzip to limit network usage basically...) on src_host: dd if=/dev/src_vg/src_lv bs=1024k | gzip | ssh dest_host "gunzip | dd bs=1024k of=/dev/dest_vg/dest_lv" deactivate LVs on source and dest lvchange --config 'global {use_lvmetad=0}' -an vgname/lvname Try to power on the VM on destination Some questions: - about overall workflow - about dd flags, in particular if source disks are thin vs preallocated Thanks, Gianluca

3 5

Bizzare oVirt network problem
by FERNANDO FREDIANI 13 Jul '17

13 Jul '17

This is a multi-part message in MIME format. --------------2363491D1BDE9DA861A526B0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello. I am facing a pretty bizzare problem in two of my Nodes running oVirt. A given VM running a few hundred Mbps of traffic simply stops passing traffic and only recovers after a reboot. Checking the bridge with 'brctl showmacs BRIDGE' I see the VM's MAC address missing during this event. It seems the bridge simply unlearn the VM's mac address which only returns when the VM is rebooted. This problems happened in two different Nodes running in different hardware, in different datacenter, in different network architecture, different switch vendors and different bonding modes. The main differences these Nodes have compared to others I have and which don't show this problem are: - The CentOS 7 installed is a Minimal installation instead of oVirt-NG - The Kernel used is 4.12 (elrepo) instead of the default 3.10 - The ovirtmgmt network is used also for the Virtual Machine showing this problem. Has anyone have any idea if it may have anything to do with oVirt (any filters) or any of the components different from a oVirt-NG installation ? Thanks Fernando --------------2363491D1BDE9DA861A526B0 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 bgcolor="#FFFFFF" text="#000000"> Hello. I am facing a pretty bizzare problem in two of my Nodes running oVirt. A given VM running a few hundred Mbps of traffic simply stops passing traffic and only recovers after a reboot. Checking the bridge with 'brctl showmacs BRIDGE' I see the VM's MAC address missing during this event. It seems the bridge simply unlearn the VM's mac address which only returns when the VM is rebooted. This problems happened in two different Nodes running in different hardware, in different datacenter, in different network architecture, different switch vendors and different bonding modes. The main differences these Nodes have compared to others I have and which don't show this problem are: - The CentOS 7 installed is a Minimal installation instead of oVirt-NG - The Kernel used is 4.12 (elrepo) instead of the default 3.10 - The ovirtmgmt network is used also for the Virtual Machine showing this problem. Has anyone have any idea if it may have anything to do with oVirt (any filters) or any of the components different from a oVirt-NG installation ? Thanks Fernando </body> </html> --------------2363491D1BDE9DA861A526B0--

2 3

Deleted the default Datacenter and hosted-engine was there...
by Vinícius Ferrão 13 Jul '17

13 Jul '17

Hello, As someone may know I’m learning my way through oVirt. During the configuration of the my production oVirt pool I’ve created a new datacenter and a cluster to put my hosts and deleted the default one. But now I don’t know what to do. I can’t add one of my machines to the new datacenter since it’s still on the “old” and deleted Datacenter. The hosted engine is running on the same machine. What are the next steps? I think I’ve screwed all the installation removing the default DC. Any help is appreciated, V. PS: I still have access to the Hosted Engine, and it’s running fine.

1 0

[ovirt 4.1] how to increase HA VM retry count ?
by TranceWorldLogic . 13 Jul '17

13 Jul '17

Hi, I have created HA VM with priority as High. And then I block host network connection using firewall rule as shown below. e.g. iptables -I INPUT -j DROP; iptables -I OUTPUT -j DROP; As expected ovirt had call fencing to power off host and power on it again. At backgroud ovirt tried 10 time to start that VM but as host down it fail to start. And after 10 trial it giveup to start VM. Is there any way to increase trail count ? And also let me know how to change retry timer. Thanks, ~Rohit

3 4