- Users - oVirt List Archives

ovirt ugrade to 4.1.1 problem with ovirt-engine-notifier.service
by Kapetanakis Giannis 04 Apr '17

04 Apr '17

Hi, Centos 7 (no self hosted). Trying to upgrade from 4.1.0 to 4.1.1 he setup fails to start ovirt-engine-notifier.service ● ovirt-engine-notifier.service - oVirt Engine Notifier Loaded: loaded (/usr/lib/systemd/system/ovirt-engine-notifier.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Tue 2017-04-04 15:21:28 EEST; 30s ago Process: 4489 ExecStart=/usr/share/ovirt-engine/services/ovirt-engine-notifier/ovirt-engine-notifier.py --redirect-output --systemd=notify $EXTRA_ARGS start (code=exited, status=1/FAILURE) Main PID: 4489 (code=exited, status=1/FAILURE) Apr 04 15:21:28 vmgr.cc.uoc.gr ovirt-engine-notifier.py[4489]: stderr: at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198) Apr 04 15:21:28 vmgr.cc.uoc.gr ovirt-engine-notifier.py[4489]: stderr: at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363) Apr 04 15:21:28 vmgr.cc.uoc.gr ovirt-engine-notifier.py[4489]: stderr: at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351) Apr 04 15:21:28 vmgr.cc.uoc.gr ovirt-engine-notifier.py[4489]: stderr: at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93) Apr 04 15:21:28 vmgr.cc.uoc.gr ovirt-engine-notifier.py[4489]: stderr: ... 7 more Apr 04 15:21:28 vmgr.cc.uoc.gr ovirt-engine-notifier.py[4489]: Validation failed returncode is 1: Apr 04 15:21:28 vmgr.cc.uoc.gr systemd[1]: ovirt-engine-notifier.service: main process exited, code=exited, status=1/FAILURE Apr 04 15:21:28 vmgr.cc.uoc.gr systemd[1]: Failed to start oVirt Engine Notifier. Apr 04 15:21:28 vmgr.cc.uoc.gr systemd[1]: Unit ovirt-engine-notifier.service entered failed state. Apr 04 15:21:28 vmgr.cc.uoc.gr systemd[1]: ovirt-engine-notifier.service failed. >From installation log: 2017-04-04 15:07:48 DEBUG otopi.context context._executeMethod:128 Stage closeup METHOD otopi.plugins.ovirt_engine_common.base.system.hostile_services.Plugin._closeup 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd systemd.exists:73 check if service ovirt-engine-notifier exists 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:813 execute: ('/bin/systemctl', 'show', '-p', 'LoadState', 'ovirt-engine-notifier.service'), executable='None', cwd='None', env=None 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:863 execute-result: ('/bin/systemctl', 'show', '-p', 'LoadState', 'ovirt-engine-notifier.service'), rc=0 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:921 execute-output: ('/bin/systemctl', 'show', '-p', 'LoadState', 'ovirt-engine-notifier.service') stdout: LoadState=loaded 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:926 execute-output: ('/bin/systemctl', 'show', '-p', 'LoadState', 'ovirt-engine-notifier.service') stderr: 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd systemd.state:130 starting service ovirt-engine-notifier 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:813 execute: ('/bin/systemctl', 'start', 'ovirt-engine-notifier.service'), executable='None', cwd='None', env=None 2017-04-04 15:07:49 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:863 execute-result: ('/bin/systemctl', 'start', 'ovirt-engine-notifier.service'), rc=1 2017-04-04 15:07:49 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:921 execute-output: ('/bin/systemctl', 'start', 'ovirt-engine-notifier.service') stdout: 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:926 execute-output: ('/bin/systemctl', 'show', '-p', 'LoadState', 'ovirt-engine-notifier.service') stderr: 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd systemd.state:130 starting service ovirt-engine-notifier 2017-04-04 15:07:48 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:813 execute: ('/bin/systemctl', 'start', 'ovirt-engine-notifier.service'), executable='None', cwd='None', env=None 2017-04-04 15:07:49 DEBUG otopi.plugins.otopi.services.systemd plugin.executeRaw:863 execute-result: ('/bin/systemctl', 'start', 'ovirt-engine-notifier.service'), rc=1 2017-04-04 15:07:49 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:921 execute-output: ('/bin/systemctl', 'start', 'ovirt-engine-notifier.service') stdout: 2017-04-04 15:07:49 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:926 execute-output: ('/bin/systemctl', 'start', 'ovirt-engine-notifier.service') stderr: Job for ovirt-engine-notifier.service failed because the control process exited with error code. See "systemctl status ovirt-engine-notifier.service" and "journalctl -xe" for details. 2017-04-04 15:07:49 DEBUG otopi.context context._executeMethod:142 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-common/base/system/hostile_services.py", line 104, in _closeup state=True File "/usr/share/otopi/plugins/otopi/services/systemd.py", line 141, in state service=name, RuntimeError: Failed to start service 'ovirt-engine-notifier' 2017-04-04 15:07:49 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Closing up': Failed to start service 'ovirt-engine-notifier' G

1 1

ovirt-guest-agent logs is this normal behavior
by rob cousins 04 Apr '17

04 Apr '17

After installing ovirt-guest-agent on ubuntu 16.04 following these instructions https://www.ovirt.org/documentation/how-to/guest-agent/install-the-guest-ag… i get the following messages in syslog is this normal behavior ? Apr 3 14:25:36 ubuntu python[1521]: #015Reading package lists... 0%#015#015Reading package lists... 100%#015#015Reading package lists... Done Apr 3 14:25:37 ubuntu python[1521]: #015Building dependency tree... 0%#015#015Building dependency tree... 0%#015#015Building dependency tree... 50%#015#015Building dependency tree... 50%#015#015Building dependency tree Apr 3 14:25:37 ubuntu python[1521]: #015Reading state information... 0%#015#015Reading state information... 0%#015#015Reading state information... Done Thanks Rob.

2 1

Re: [ovirt-users] iSCSI Discovery cannot detetect LUN
by Lukáš Kaplan 04 Apr '17

04 Apr '17

I did following steps: - delete target on all initiators (ovirt nodes) iscsiadm -m node -T iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T -p 10.53.1.201:3260 -u iscsiadm -m node -T iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T -p 10.53.1.201:3260 -o delete - stop tgtd on target - fill storage by zeroes (dd if=/dev/zero of=/dev/md125 bs=4096 status=progress) - start tgtd - tried to connect to ovirt (Discovery=ok, Login=ok, but can not see any LUN). === After that I ran this commands on one node: === [root@fudi-cn1 ~]# iscsiadm -m session -o show tcp: [1] 10.53.0.10:3260,1 iqn.2017-03.cz.dragon.ovirt:ovirtengine (non-flash) tcp: [11] 10.53.0.201:3260,1 iqn.2017-03.cz.dragon.ovirt.fudi-sn1:10T (non-flash) tcp: [12] 10.53.1.201:3260,1 iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T (non-flash) [root@fudi-cn1 ~]# iscsiadm -m discoverydb -P1 SENDTARGETS: DiscoveryAddress: 10.53.0.201,3260 Target: iqn.2017-03.cz.dragon.ovirt:ovirtengine Portal: 10.53.0.201:3260,1 Iface Name: default iSNS: No targets found. STATIC: Target: iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T Portal: 10.53.1.201:3260,1 Iface Name: default Target: iqn.2017-03.cz.dragon.ovirt:ovirtengine Portal: 10.53.0.10:3260,1 Iface Name: default Target: iqn.2017-03.cz.dragon.ovirt.fudi-sn1:10T Portal: 10.53.0.201:3260,1 Iface Name: default FIRMWARE: No targets found. === On iscsi target: === [root@fuvs-sn1 ~]# cat /proc/mdstat Personalities : [raid1] [raid6] [raid5] [raid4] md125 : active raid6 sdl1[11] sdk1[10] sdj1[9] sdi1[8] sdh1[7] sdg1[6] sdf1[5] sde1[4] sdd1[3] sdc1[2] sdb1[1] sda1[0] 9766302720 blocks super 1.2 level 6, 512k chunk, algorithm 2 [12/12] [UUUUUUUUUUUU] bitmap: 0/8 pages [0KB], 65536KB chunk ...etc... [root@fuvs-sn1 ~]# cat /etc/tgt/targets.conf default-driver iscsi <target iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T> # provided devicce as a iSCSI target backing-store /dev/md125 # iSCSI Initiator's IP address you allow to connect #initiator-address 10.53.0.0/23 </target> -- Lukas Kaplan 2017-03-25 12:36 GMT+01:00 Lukas Kaplan <lkaplan(a)dragon.cz>: > Co muze myslet tim mappingem? > > Jinak muzu zkusit ddckem celou storage prepsat nulami. > > co ty na to? > > Odesláno z iPhonu > > Začátek přeposílané zprávy: > > *Od:* Yaniv Kaul <ykaul(a)redhat.com> > *Datum:* 24. března 2017 23:25:21 SEČ > *Komu:* Lukáš Kaplan <lkaplan(a)dragon.cz> > *Kopie:* users <users(a)ovirt.org> > *Předmět:* *Re: [ovirt-users] iSCSI Discovery cannot detetect LUN* > > > > On Fri, Mar 24, 2017 at 1:34 PM, Lukáš Kaplan <lkaplan(a)dragon.cz> wrote: > >> Hello all, >> >> please do you have some experience with troubleshooting adding of iSCSI >> domain to ovirt 4.1.1? >> >> I am chalenging this issue now: >> >> 1) I have successfuly installed oVirt 4.1.1 environment with self-hosted >> engine, 3 nodes and 3 storages (iSCSI Master domain, iSCSI for hosted >> engine and NFS ISO domain). Everything is working now. >> >> 2) But, when I want to add new iSCSI domain, I can discover it, I can >> login, but I cant see any LUN on that storage. (I had same problem in oVirt >> 4.1.0, so I made upgrade to 4.1.1) >> > > Are you sure mappings are correct? > Can you ensure the LUN is empty? > Y. > > >> >> 3) Then I tryed to add this storage to another oVirt environment (oVirt >> 3.6) and there are no problem. I can see LUN on that storage and I can >> connect it to oVirt. >> >> I tryed to examine vdsm.log, but it is very detailed and unredable for me >> :-/ >> >> Thak you in advance, have a nice day, >> -- >> Lukas Kaplan >> >> >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> >> >

6 11

Python-SDK4: Listing template by ID throws exception
by nicolas＠devels.es 04 Apr '17

04 Apr '17

Hi, I'm using ovirt-engine-sdk-python 4.1.3 (ovirt ver is 4.1.0), and in a snippet I'm trying to get a template by its id. For that, I did this: conn = ovirtsdk4.Connection(...) sys_serv = conn.system_service() tpl_serv = sys_serv.templates_service() t = tpl_serv.list(search='id=fedff75f-635f-4790-9bbf-2ac389e14f93') And it throws: Error: Fault reason is "Operation Failed". Fault detail is "statementcallback; bad sql grammar [select * from (select * from vm templates view where ( vmt guid in (select distinct vm templates storage domain.vmt guid from vm templates storage domain where ( vm templates storage domain.cluster name ilike '%id=fedff75f-635f-4790-9bbf-2ac389e14f93%' or vm templates storage domain.description ilike '%id=fedff75f-635f-4790-9bbf-2ac389e14f93%' or vm templates storage domain.free text comment ilike '%id=fedff75f-635f-4790-9bbf-2ac389e14f93%' or vm templates storage domain.name ilike '%id=fedff75f-635f-4790-9bbf-2ac389e14f93%' or vm templates storage domain.quota name ilike '%id=fedff75f-635f-4790-9bbf-2ac389e14f93%' or vm templates storage domain.storage pool name ilike '%id=fedff75f-635f-4790-9bbf-2ac389e14f93%' or vm templates storage domain.template version name,template version number ilike '%id=fedff75f-635f-4790-9bbf-2ac389e14f93%' ) )) order by name asc ) as t1 offset (1 -1) limit 2147483647]; nested exception is org.postgresql.util.psqlexception: error: argument of or must be type boolean, not type character varying position: 737". HTTP response code is 400. I'm sure this template exists and it has this ID. If I search in the webadmin by this ID, the search seems to hang and never returns anything (I have to stop it by pressing the 'X' button). Am I using this call improperly? Thanks.

2 2

Re: [ovirt-users] Memory treshold
by vasily.lamykin 04 Apr '17

04 Apr '17

engine-config -s LogMaxPhysicalMemoryUsedThresholdInPercentage=%percent per threshold% Василий Ламыкин Старший инженер по эксплуатации сервисных платформ Эксплуатация сети Столичный филиал ПАО «МегаФон» +7 (926) 500-3308 -----Original Message----- From: users-bounces(a)ovirt.org [mailto:users-bounces@ovirt.org] On Behalf Of users-request(a)ovirt.org Sent: Wednesday, March 29, 2017 1:00 PM To: users(a)ovirt.org Subject: Users Digest, Vol 66, Issue 254 Send Users mailing list submissions to users(a)ovirt.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.ovirt.org/mailman/listinfo/users or, via email, send a message with subject or body 'help' to users-request(a)ovirt.org You can reach the person managing the list at users-owner(a)ovirt.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Users digest..." Today's Topics: 1. Re: VM "hot" RAM memory decrease (Martin Sivak) 2. Memory treshold (vasily.lamykin) 3. Re: iSCSI Discovery cannot detetect LUN (Eduardo Mayoral) ---------------------------------------------------------------------- Message: 1 Date: Wed, 29 Mar 2017 11:50:59 +0200 From: Martin Sivak <msivak(a)redhat.com> To: Nicol?s <nicolas(a)devels.es> Cc: users <users(a)ovirt.org> Subject: Re: [ovirt-users] VM "hot" RAM memory decrease Message-ID: <CAF0zDV5BG9PmzpaTS+73QKYELTv8ThNJcZoiGoySYsEuGV2c9Q(a)mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Hi Nicolas, you are right, the log shows exactly the right values. Those numbers are exactly what is sent to libvirt using currentMemory field in https://libvirt.org/formatdomain.html#elementsMemoryAllocation So if the VM does not have enough memory, we will have to start looking there. Best regards Martin Sivak On Wed, Mar 29, 2017 at 11:04 AM, <nicolas(a)devels.es> wrote: > Hi Martin, > > I do, I'm attaching it. I merged the full day's log into one. > Significant hours start at 11:24:57 (log time). The interesting > machine is called jbaspre01, and as per what I can deduce, the values > in log are correct (it never goes under the threshold of 1GB, which is > its minimum). However, my colleagues and I are 100% sure we saw this > machine having about 600K KiB when running top. > > This machine has: > Memory size: 8196 MB > Minimal guaranteed memory: 1024 MB > > If you need additional information don't hesitate to ask. > > Regards. > > > El 2017-03-29 09:44, Martin Sivak escribi?: >> >> Hi Nicolas, >> >> KiB Mem tells you how much memory the host has. I am actually more >> interested in the VM. Do you still have the mom.log from the time >> this happened? We keep the logs for some time (they are rotated). >> >> Best regards >> >> Martin >> >> On Wed, Mar 29, 2017 at 10:28 AM, <nicolas(a)devels.es> wrote: >>> >>> El 2017-03-28 15:33, Martin Sivak escribi?: >>>>> >>>>> >>>>> min guaranteed should be respected, adding mom maintainer Martin >>>> >>>> >>>> >>>> I can't really help without the mom.log and the virsh dumpxml >>>> output of that VM in the final state (all memory ballooned). >>>> >>>> Min guaranteed should be respected, but the question is how the >>>> physical memory was measured (which number from top was used). >>>> >>>> -- >>>> Martin Sivak >>>> SLA / oVirt >>>> >>> >>> Hi Martin, >>> >>> I tried to reproduce the issue again and I was unable to. I had a >>> host with ~90% of RAM utilization and in mom.log I could see that >>> ballooning was indeed happening, but I couldn't see a VM going under >>> its minimum guaranteed threshold (at least not significantly). >>> >>> On top, I was using the 'KiB Mem' value to compare. I know this is >>> in KiB and that oVirt has its values as MB in the webadmin, but when >>> I sent this message the difference was quite more significant >>> (1024MB of minimum guaranteed and about 640K KiB on the VM). >>> >>> It's also true that meanwhile we upgraded from 4.0.2 to 4.1.1 and >>> this time I couldn't reproduce it anymore. >>> >>> If at some point I am able to reproduce it again, I'll send detailed >>> logs of the issue. >>> >>> Thanks. >>> >>> >>>> On Tue, Mar 28, 2017 at 4:29 PM, Michal Skrivanek >>>> <michal.skrivanek(a)redhat.com> wrote: >>>>> >>>>> >>>>> >>>>>> On 27 Mar 2017, at 23:15, Nicol?s <nicolas(a)devels.es> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I don't really know if this question is suitable on this list, as >>>>>> I doubt it's an oVirt bug, neither I know if it shall be >>>>>> considered a bug. >>>>>> >>>>>> We recently run a VM on a host that was memory over-used (around >>>>>> 80% of usage). The VM booted correctly, then we run "top" and saw >>>>>> how physical RAM started decreasing every two seconds. At first >>>>>> it was 4GB, then less and less until it stabilized at around >>>>>> 600MB. >>>>>> >>>>>> Based on this (correct me if I'm wrong), we believe this is an >>>>>> effect of having this VM with ballooning enabled, as it does >>>>>> exactly this: It adds/removes RAM depending on host decision. >>>>>> Thing is that this VM had a minimal guaranteed RAM of 1GB, so >>>>>> even if this happened due to ballooning, I'm not sure if it >>>>>> should have honored the minimum guaranteed RAM. >>>>>> >>>>>> When this happened, we run a 'ps' to see with what options the >>>>>> qemu process was invoked, and parameters seemed correct (that's >>>>>> why I don't know if it should be posted here or even if it's a >>>>>> bug). >>>>> >>>>> >>>>> >>>>> It does belong here, it?s a different component doing it ?externally? >>>>> to >>>>> the qemu process- mom. >>>>> >>>>>> >>>>>> Is this the expected behavior? >>>>> >>>>> >>>>> >>>>> min guaranteed should be respected, adding mom maintainer Martin >>>>> >>>>> Thanks, >>>>> michal >>>>> >>>>>> >>>>>> Thanks. >>>>>> _______________________________________________ >>>>>> Users mailing list >>>>>> Users(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/users >>>>>> >>>>>> >>>>> > ------------------------------ Message: 2 Date: Wed, 29 Mar 2017 09:46:18 +0000 From: vasily.lamykin <vasily.lamykin(a)MegaFon.ru> To: "users(a)ovirt.org" <users(a)ovirt.org> Subject: [ovirt-users] Memory treshold Message-ID: <78c01f9d8162434bbebbfe6a92222ba0(a)vlg-ums05.Megafon.ru> Content-Type: text/plain; charset="utf-8" Hi all. Explain please, where I can disable for cluster this threshold: Used memory of host *** [98%] exceeded defined threshold [95%]. ? ??????? ??????? ??????? ??????? ?? ???????????? ????????? ???????? ???????????? ???? ????????? ?????? ??? ????????? +7 (926) 500-3308 [??????? ????+???? ??? B2C] ________________________________ ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ovirt.org/pipermail/users/attachments/20170329/5be75efd/attach…> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 2130 bytes Desc: image001.png URL: <http://lists.ovirt.org/pipermail/users/attachments/20170329/5be75efd/attach…> ------------------------------ Message: 3 Date: Wed, 29 Mar 2017 11:59:46 +0200 From: Eduardo Mayoral <emayoral(a)arsys.es> To: Luk?? Kaplan <lkaplan(a)dragon.cz>,users <users(a)ovirt.org> Subject: Re: [ovirt-users] iSCSI Discovery cannot detetect LUN Message-ID: <2e73ca85-6e54-2994-b25f-4a11a03baac4(a)arsys.es> Content-Type: text/plain; charset="utf-8"; Format="flowed" I had a similar problem, in my case this was related to multipath, it was not masking the LUNs correctly, it was seeing it multiple times (one per path), and I could not select the LUNs in the oVirt interface. Once I configured multipath correctly, everything worked like a charm. Best regards, -- Eduardo Mayoral. On 29/03/17 11:30, Luk?? Kaplan wrote: > Hello all, > > I did all steps as I described in previous email, but no change. I > can't see any LUN after discovery and login of new iSCSI storage. > (That storage is ok, if I try to connect it to another and older ovirt > domain, it is working...) > > I tryed it on 3 new iSCSI targets alredy, all have same problem... > > Can somebody help me, please? > > -- > Lukas Kaplan > > > 2017-03-27 16:22 GMT+02:00 Luk?? Kaplan <lkaplan(a)dragon.cz > <mailto:lkaplan@dragon.cz>>: > > I did following steps: > - delete target on all initiators (ovirt nodes) > iscsiadm -m node -T iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T -p > 10.53.1.201:3260 <http://10.53.1.201:3260> -u > iscsiadm -m node -T iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T -p > 10.53.1.201:3260 <http://10.53.1.201:3260> -o delete > - stop tgtd on target > - fill storage by zeroes (dd if=/dev/zero of=/dev/md125 bs=4096 > status=progress) > - start tgtd > - tried to connect to ovirt (Discovery=ok, Login=ok, but can not > see any LUN). > > === After that I ran this commands on one node: === > > [root@fudi-cn1 ~]# iscsiadm -m session -o show > tcp: [1] 10.53.0.10:3260 <http://10.53.0.10:3260>,1 > iqn.2017-03.cz.dragon.ovirt:ovirtengine (non-flash) > tcp: [11] 10.53.0.201:3260 <http://10.53.0.201:3260>,1 > iqn.2017-03.cz.dragon.ovirt.fudi-sn1:10T (non-flash) > tcp: [12] 10.53.1.201:3260 <http://10.53.1.201:3260>,1 > iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T (non-flash) > > [root@fudi-cn1 ~]# iscsiadm -m discoverydb -P1 > SENDTARGETS: > DiscoveryAddress: 10.53.0.201,3260 > Target: iqn.2017-03.cz.dragon.ovirt:ovirtengine > Portal: 10.53.0.201:3260 <http://10.53.0.201:3260>,1 > Iface Name: default > iSNS: > No targets found. > STATIC: > Target: iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T > Portal: 10.53.1.201:3260 <http://10.53.1.201:3260>,1 > Iface Name: default > Target: iqn.2017-03.cz.dragon.ovirt:ovirtengine > Portal: 10.53.0.10:3260 <http://10.53.0.10:3260>,1 > Iface Name: default > Target: iqn.2017-03.cz.dragon.ovirt.fudi-sn1:10T > Portal: 10.53.0.201:3260 <http://10.53.0.201:3260>,1 > Iface Name: default > FIRMWARE: > No targets found. > > === On iscsi target: === > [root@fuvs-sn1 ~]# cat /proc/mdstat > Personalities : [raid1] [raid6] [raid5] [raid4] > md125 : active raid6 sdl1[11] sdk1[10] sdj1[9] sdi1[8] sdh1[7] > sdg1[6] sdf1[5] sde1[4] sdd1[3] sdc1[2] sdb1[1] sda1[0] > 9766302720 blocks super 1.2 level 6, 512k chunk, algorithm 2 > [12/12] [UUUUUUUUUUUU] > bitmap: 0/8 pages [0KB], 65536KB chunk > ...etc... > > > [root@fuvs-sn1 ~]# cat /etc/tgt/targets.conf > default-driver iscsi > > <target iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T> > # provided devicce as a iSCSI target > backing-store /dev/md125 > # iSCSI Initiator's IP address you allow to connect > #initiator-address 10.53.0.0/23 <http://10.53.0.0/23> > </target> > > -- > Lukas Kaplan > > 2017-03-25 12:36 GMT+01:00 Lukas Kaplan <lkaplan(a)dragon.cz > <mailto:lkaplan@dragon.cz>>: > > Co muze myslet tim mappingem? > > Jinak muzu zkusit ddckem celou storage prepsat nulami. > > co ty na to? > > Odesl?no z iPhonu > > Za??tek p?epos?lan? zpr?vy: > >> *Od:* Yaniv Kaul <ykaul(a)redhat.com <mailto:ykaul@redhat.com>> >> *Datum:* 24. b?ezna 2017 23:25:21 SE? >> *Komu:* Luk?? Kaplan <lkaplan(a)dragon.cz >> <mailto:lkaplan@dragon.cz>> >> *Kopie:* users <users(a)ovirt.org <mailto:users@ovirt.org>> >> *P?edm?t:* *Re: [ovirt-users] iSCSI Discovery cannot detetect >> LUN* >> >> >> >> On Fri, Mar 24, 2017 at 1:34 PM, Luk?? Kaplan >> <lkaplan(a)dragon.cz <mailto:lkaplan@dragon.cz>> wrote: >> >> Hello all, >> >> please do you have some experience with troubleshooting >> adding of iSCSI domain to ovirt 4.1.1? >> >> I am chalenging this issue now: >> >> 1) I have successfuly installed oVirt 4.1.1 environment >> with self-hosted engine, 3 nodes and 3 storages (iSCSI >> Master domain, iSCSI for hosted engine and NFS ISO >> domain). Everything is working now. >> >> 2) But, when I want to add new iSCSI domain, I can >> discover it, I can login, but I cant see any LUN on that >> storage. (I had same problem in oVirt 4.1.0, so I made >> upgrade to 4.1.1) >> >> >> Are you sure mappings are correct? >> Can you ensure the LUN is empty? >> Y. >> >> >> 3) Then I tryed to add this storage to another oVirt >> environment (oVirt 3.6) and there are no problem. I can >> see LUN on that storage and I can connect it to oVirt. >> >> I tryed to examine vdsm.log, but it is very detailed and >> unredable for me :-/ >> >> Thak you in advance, have a nice day, >> -- >> Lukas Kaplan >> >> >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> >> http://lists.ovirt.org/mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users> >> >> > > > > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ovirt.org/pipermail/users/attachments/20170329/e73ab86f/attach…> ------------------------------ _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users End of Users Digest, Vol 66, Issue 254 ************************************** ________________________________ Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщение и любые возможные его копии и приложения. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50

1 0

iSCSI Multipathing
by Devin A. Bougie 04 Apr '17

04 Apr '17

We have a new 4.1.1 cluster up and running with OVS switches and an iSCSI hosted_storage and VM data domain (same target, different LUN's). Everything works fine, and I can configure iscsid and multipathd outside of the oVirt engine to ensure redundancy with our iSCSI device. However, if I try to configure iSCSI Multipathing within the engine, all of the hosts get stuck in the "Connecting" status and the Data Center and Storage Domains go down. The hosted engine, however, continues to work just fine. Before I provide excerpts from our logs and more details on what we're seeing, it would be helpful to understand better what the advantages are of configuring iSCSI Bonds within the oVirt engine. Is this mainly a feature for oVirt users that don't have experience configuring and managing iscsid and multipathd directly? Or, is it important to actually setup iSCSI Bonds within the engine instead of directly in the underlying OS? Any advice or links to documentation I've overlooked would be greatly appreciated. Many thanks, Devin

2 3

Recent Install Docs?
by Charles Tassell 03 Apr '17

03 Apr '17

Hello, Are there any more recent install docs than what's on the website? Those all seem to be back from the 3.x days and don't really deal with the modern setup of using a hosted engine. More specifically, I've noticed that when deploying a hosted engine I can't import the storage domain that the engine is on. When I try I get errors like "Can't import the storage domain, connection already exists" Because I can't import my storage domain, I can't initialize the cluster, so I can't really get anywhere with the setup. I had this same problem on 4.0 (using 4.1 now) and I "fixed" it by wiping the cluster and creating two sets of storage: a small 50G one that holds the hosted engine, and then another one that holds all my VMs. I don't want to do that with my new cluster if I can at all avoid it.

2 2

setting iSCSI iface.net_ifacename (netIfaceName)
by Devin A. Bougie 03 Apr '17

03 Apr '17

Where do I set the iSCSI iface to use when connecting to both the hosted_storate and VM Data Domain? I believe this is related to the difficulty I've had configuring iSCSI bonds within the oVirt engine as opposed to directly in the underlying OS. I've set "iscsi_default_ifaces = ovirtsan" in vdsm.conf, but vdsmd still insists on using the default iface and vdsm.log shows: 2017-04-03 11:17:21,109-0400 INFO (jsonrpc/5) [storage.ISCSI] iSCSI iface.net_ifacename not provided. Skipping. (iscsi:590) Many thanks, Devin

1 0

iscsi config for dell ps series
by Gianluca Cecchi 02 Apr '17

02 Apr '17

Hello, I'm configuring an hypervisor for iSCSI Dell PS Series It is a CentOS 7.3 + updates server. The server has been already added to oVirt as a node, but without any storage domain configured yet. It has access to one lun that will become the storage domain one. Default oVirt generated multipath.conf is like this: defaults { polling_interval 5 no_path_retry fail user_friendly_names no flush_on_last_del yes fast_io_fail_tmo 5 dev_loss_tmo 30 max_fds 4096 } devices { device { # These settings overrides built-in devices settings. It does not apply # to devices without built-in settings (these use the settings in the # "defaults" section), or to devices defined in the "devices" section. # Note: This is not available yet on Fedora 21. For more info see # https://bugzilla.redhat.com/1253799 all_devs yes no_path_retry fail } } Apparently in device-mapper-multipath there is no builtin for this combination Vendor: EQLOGIC Model: 100E-00 Rev: 8.1 So, with the oVirt provided configuration a "show config" for multipath reports something like this at the end: polling_interval 5 path_selector "service-time 0" path_grouping_policy "failover" path_checker "directio" rr_min_io_rq 1 max_fds 4096 rr_weight "uniform" failback "manual" features "0" and multipath layout this way [root@ov300 etc]# multipath -l 364817197b5dfd0e5538d959702249b1c dm-3 EQLOGIC ,100E-00 size=1.0T features='0' hwhandler='0' wp=rw |-+- policy='service-time 0' prio=0 status=active | `- 7:0:0:0 sde 8:64 active undef running `-+- policy='service-time 0' prio=0 status=enabled `- 8:0:0:0 sdf 8:80 active undef running [root@ov300 etc]# Following recommendations from Dell here: http://en.community.dell.com/techcenter/extras/m/white_papers/20442422 I should put into defaults section these directives: defaults { polling_interval 10 path_selector "round-robin 0" path_grouping_policy multibus path_checker tur rr_min_io_rq 10 max_fds 8192 rr_weight priorities failback immediate features 0 } I'm trying to mix EQL and oVirt reccomendations to have the best for my use and arrived at this config (plus a blacklist section with my internal hd and my flash wwids that is not relevant here): # VDSM REVISION 1.3 # VDSM PRIVATE defaults { polling_interval 5 no_path_retry fail user_friendly_names no flush_on_last_del yes fast_io_fail_tmo 5 dev_loss_tmo 30 # Default oVirt value overwritten # max_fds 4096 # max_fds 8192 } devices { device { # These settings overrides built-in devices settings. It does not apply # to devices without built-in settings (these use the settings in the # "defaults" section), or to devices defined in the "devices" section. # Note: This is not available yet on Fedora 21. For more info see # https://bugzilla.redhat.com/1253799 all_devs yes no_path_retry fail } device { vendor "EQLOGIC" product "100E-00" # Default EQL configuration overwritten by oVirt default # polling_interval 10 # path_selector "round-robin 0" path_grouping_policy multibus path_checker tur rr_min_io_rq 10 rr_weight priorities failback immediate features "0" } } After activating this config I have this mutipath layout [root@ov300 etc]# multipath -l 364817197b5dfd0e5538d959702249b1c dm-3 EQLOGIC ,100E-00 size=1.0T features='0' hwhandler='0' wp=rw `-+- policy='round-robin 0' prio=0 status=active |- 7:0:0:0 sde 8:64 active undef running `- 8:0:0:0 sdf 8:80 active undef running [root@ov300 etc]# NOTE: at this moment the storage is not yet configured as a storage domain. I also changed /etc/iscsi/iscsd.conf and sysctl.d parameters as from EQL doc indications >From an iSCSI initiator point of view: [root@ov300 ~]# 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) [root@ov300 ~]# [root@ov300 ~]# iscsiadm -m session -P 1 Target: iqn.2001-05.com.equallogic:4-771816-e5d0dfb59-1c9b240297958d53-ovsd3910 (non-flash) Current Portal: 10.10.100.41:3260,1 Persistent Portal: 10.10.100.9:3260,1 ********** Interface: ********** Iface Name: ip1p1 Iface Transport: tcp Iface Initiatorname: iqn.1994-05.com.redhat:f2d7fc1e2fc Iface IPaddress: 10.10.100.87 Iface HWaddress: <empty> Iface Netdev: <empty> SID: 1 iSCSI Connection State: LOGGED IN iSCSI Session State: LOGGED_IN Internal iscsid Session State: NO CHANGE Current Portal: 10.10.100.42:3260,1 Persistent Portal: 10.10.100.9:3260,1 ********** Interface: ********** Iface Name: ip1p2 Iface Transport: tcp Iface Initiatorname: iqn.1994-05.com.redhat:f2d7fc1e2fc Iface IPaddress: 10.10.100.87 Iface HWaddress: <empty> Iface Netdev: <empty> SID: 2 iSCSI Connection State: LOGGED IN iSCSI Session State: LOGGED_IN Internal iscsid Session State: NO CHANGE [root@ov300 ~]# Do you think it is ok? Thanks for any comments, Gianluca

2 1

ovirt upgrade => vms refusing to (re)boot
by Nelson Lameiras 02 Apr '17

02 Apr '17

------=_Part_1324120_374554609.1490968161320 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello,=20 We had a rather unpleseant surprise while upgrading our production datacent= ers to oVirt 4.0 =3D> 4.1 (although I think this problem is not related to = oVirt 4.1).=20 Some critical VMs simply refused to reboot without any particular error mes= sage other than "VM failed to boot"=20 After a stressfull 2h of investigation, it turns out that the problematic V= Ms shared the same "exotic" condition. They were not rebooted since the lat= est major upgrade 3.6 =3D> 4.0 (I know, this is not a good practise and we = underestimated it's priority, we will change our reboot policies)=20 Their "custom compatilibity setting" was set to 3.6 !! When changing this s= etting to "Empty", The VM booted normaly. Hard to find, easy to fix !! ;)= =20 Neverthess, there is little to none information/documentation about the use= fullness of this setting, and I have a hard time understanding the conseque= nces of changing it manually.=20 Our oVirt datacenter (which has engine 4.1.1, but some hosts on 4.0, so it'= s still on 4.0 compatibility) hosts currently +- 200 Vms,=20 - 10 with "custom compatilibity setting" set to 3.6 - which will not (reb)b= oot in current state,=20 - 30some with "custom compatilibity setting" set to 4.0 - which (re)boot no= rmally=20 - the rest with "custom compatilibity setting" set to "empty" - which (re)b= oot normally=20 So can a oVirt guru please answer the following questions :=20 - What does this setting do? which are the consequences of changing it manu= ally ?=20 - Is it "normal" that a VM not reboooted since the 3.6 update does not boot= if a new major upgrade is done on hostig host ? (maybe a exotic bug worth = correcting ?)=20 - Which are the possible consequences of manually setting this setting to "= Empty" in all my VMs (running or stopped) ?=20 - Which events will change this setting automatically ? (cluster major vers= ion upgrade, first reboot after upgrade, ...) ?=20 - Some of my VMs have custom_compatibility_version set to 4.0 (in REST API)= eventough they have been recently rebooted and "custom compatilibity setti= ng" is empty in GUI, who's this possible ?=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_1324120_374554609.1490968161320 Content-Type: multipart/related; boundary="----=_Part_1324121_120729041.1490968161320" ------=_Part_1324121_120729041.1490968161320 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,<br></div><div><br data-mce-bogus=3D"= 1"></div><div>We had a rather unpleseant surprise while upgrading our produ= ction datacenters to oVirt 4.0 =3D> 4.1 (although I think this problem i= s not related to oVirt 4.1). </div><div>Some critical VMs simply refused to= reboot without any particular error message other than "VM failed to boot"= <br data-mce-bogus=3D"1"></div><div><br data-mce-bogus=3D"1"></div><div>Aft= er a stressfull 2h of investigation, it turns out that the problematic VMs = shared the same "exotic" condition. They were not rebooted since the latest= major upgrade 3.6 =3D> 4.0 (I know, this is not a good practise and we = underestimated it's priority, we will change our reboot policies)<br data-m= ce-bogus=3D"1"></div><div>Their "custom compatilibity setting" was set to 3= .6 !! When changing this setting to "Empty", The VM booted normaly. Hard to= find, easy to fix !! ;)<br data-mce-bogus=3D"1"></div><div><br data-mce-bo= gus=3D"1"></div><div>Neverthess, there is little to none information/docume= ntation about the usefullness of this setting, and I have a hard time under= standing the consequences of changing it manually.<br data-mce-bogus=3D"1">= </div><div><br data-mce-bogus=3D"1"></div><div>Our oVirt datacenter (which = has  engine 4.1.1, but some hosts on 4.0, so it's still on 4.0 compati= bility) hosts currently +- 200 Vms, </div><div>- 10 with "custom compatilib= ity setting" set to 3.6 - which will not (reb)boot in current state, </div>= <div>- 30some with "custom compatilibity setting" set to 4.0 - which (re)bo= ot normally <br data-mce-bogus=3D"1"></div><div>- the rest with "custom com= patilibity setting" set to "empty" - which (re)boot normally <br data-= mce-bogus=3D"1"></div><div><br data-mce-bogus=3D"1"></div><div>So can a oVi= rt guru please answer the following questions :<br data-mce-bogus=3D"1"></d= iv><div><br></div><div>- What does this setting do? which are the consequen= ces of changing it manually ?<br data-mce-bogus=3D"1"></div><div>- Is it "n= ormal" that a VM not reboooted since the 3.6 update does not boot if a new = major upgrade is done on hostig host ? (maybe a exotic bug worth correcting= ?)<br data-mce-bogus=3D"1"></div><div>- Which are the possible consequence= s of manually setting this setting to "Empty" in all my VMs (running or sto= pped) ?<br data-mce-bogus=3D"1"></div><div>- Which events will change this = setting automatically ? (cluster major version upgrade, first reboot after = upgrade, ...) ?<br data-mce-bogus=3D"1"></div><div>- Some of my VMs have&nb= sp;custom_compatibility_version set to 4.0 (in REST API)  eventough th= ey have been recently rebooted and "custom compatilibity setting" is empty = in GUI, who's this possible ?<br data-mce-bogus=3D"1"></div><div><br data-m= ce-bogus=3D"1"></div><div data-marker=3D"__SIG_PRE__"><div>cordialement, re= gards,</div><div><br data-mce-bogus=3D"1"></div><table style=3D"margin: 0px= ; table-layout: fixed; border: none; width: 345pt; padding: 0px;" data-mce-= style=3D"margin: 0px; table-layout: fixed; border: none; width: 345pt; padd= ing: 0px;" width=3D"460" cellspacing=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; font-size: 11px; font-family: Arial,sans-ser= if; color: #2b3c7a; line-height: 16px; width: 86.25pt; text-align: left;" w= idth=3D"115" valign=3D"top"><a href=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: none; width: 100%; display: block; clear: bo= th;"><img src=3D"cid:1504d440a45e25d470766a589e361163b925cd4d@zimbra" alt= =3D"" data-mce-src=3D"/home/admin(a)lyra-network.com/corporate-documents/elem= ent-signature_logo_lyra_115x94.jpg" doc=3D"corporate-documents/element-sign= ature_logo_lyra_115x94.jpg" width=3D"115" height=3D"94" 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: 258.75pt= ;" data-mce-style=3D"margin: 0; font-size: 11px; font-family: Arial,sans-se= rif; color: #2b3c7a; line-height: 16px; width: 258.75pt;" width=3D"345" val= ign=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"345" cellspacing=3D"0" cellpadding=3D"0" b= order=3D"0"><tbody><tr><td style=3D"font-size: 16px; font-family: Arial,san= s-serif; color: #2b3c7a; line-height: 18px; font-weight: bold;" data-mce-st= yle=3D"font-size: 16px; font-family: 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-he= ight: 16px;" data-mce-style=3D"font-family: Arial,sans-serif; color: #2b3c7= a; font-size: 11px; line-height: 16px;">Ing=C3=A9nieur Syst=C3=A8mes et R= =C3=A9seaux<span style=3D"font-family: Arial,sans-serif; color: #337ab7; fo= nt-size: 11px;" data-mce-style=3D"font-family: Arial,sans-serif; color: #33= 7ab7; font-size: 11px;"> / Systems and Networks engineer</span></td></tr><t= r><td style=3D"line-height: 16px; font-family: 'Arial',sans-serif; color: #= 2b3c7a; font-size: 11px;" data-mce-style=3D"line-height: 16px; font-family:= 'Arial',sans-serif; color: #2b3c7a; font-size: 11px;"><span style=3D"font-= family: Arial,sans-serif; color: #2b3c7a; font-size: 11px;" data-mce-style= =3D"font-family: Arial,sans-serif; color: #2b3c7a; font-size: 11px;">Tel: += 33 5 32 09 09 70</span></td></tr><tr><td style=3D"line-height: 16px; font-f= amily: 'Arial',sans-serif; color: #2b3c7a; font-size: 11px;" data-mce-style= =3D"line-height: 16px; font-family: 'Arial',sans-serif; color: #2b3c7a; fon= t-size: 11px;"><a href=3D"mailto:nelson.lameiras@lyra-network.com" style=3D= "font-size: 11px; font-family: Arial,sans-serif; line-height: 16px; text-de= coration: none;" data-mce-href=3D"mailto:nelson.lameiras@lyra-network.com" = data-mce-style=3D"font-size: 11px; font-family: Arial,sans-serif; line-heig= ht: 16px; text-decoration: none;">nelson.lameiras(a)lyra-network.com</a><br d= ata-mce-bogus=3D"1"></td></tr><tr><td style=3D"line-height: 16px; font-fami= ly: 'Arial',sans-serif; color: #2b3c7a; font-size: 11px;" data-mce-style=3D= "line-height: 16px; font-family: 'Arial',sans-serif; color: #2b3c7a; font-s= ize: 11px;"><a href=3D"https://www.lyra-network.com/" style=3D"font-size: 1= 1px; font-family: Arial,sans-serif; line-height: 16px; border: none; text-d= ecoration: none;" data-mce-href=3D"https://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; text-decoration: none;" data-mce-href=3D"= https://payzen.eu" data-mce-style=3D"font-size: 11px; font-family: Arial,sa= ns-serif; line-height: 16px; border: none; text-decoration: none;"> | www.p= ayzen.eu</a><br data-mce-bogus=3D"1"></td></tr></tbody></table></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: n= one; width: 345pt;" width=3D"460" cellspacing=3D"0" cellpadding=3D"0"><tbod= y><tr><td style=3D"margin: 0; font-size: 11px; font-family: Arial,sans-seri= f; color: #2b3c7a; line-height: 16px; width: 24pt; text-align: left;" data-= mce-style=3D"margin: 0; font-size: 11px; font-family: Arial,sans-serif; col= or: #2b3c7a; line-height: 16px; width: 24pt; text-align: left;" width=3D"32= " valign=3D"top"><a href=3D"https://www.youtube.com/channel/UCrVl1CO_Jlu3Kb= iRH-tQ_vA" style=3D"border: none; text-decoration: none; margin: 0; float: = left; display: inline-block; width: 32px;" data-mce-href=3D"https://www.you= tube.com/channel/UCrVl1CO_Jlu3KbiRH-tQ_vA" data-mce-style=3D"border: none; = text-decoration: none; margin: 0; float: left; display: inline-block; width= : 32px;"><img src=3D"cid:089c696a3ee09447fa2f5d20d0074bf34dc05be8@zimbra" a= lt=3D"" data-mce-src=3D"/home/admin(a)lyra-network.com/corporate-documents/el= ement-signature_logo_YouTube_32x28.jpg" doc=3D"corporate-documents/element-= signature_logo_YouTube_32x28.jpg" width=3D"32" height=3D"28" border=3D"0"><= /a><br data-mce-bogus=3D"1"></td><td style=3D"margin: 0; font-size: 11px; f= ont-family: Arial,sans-serif; color: #2b3c7a; line-height: 16px; width: 30.= 75pt; text-align: left;" data-mce-style=3D"margin: 0; font-size: 11px; font= -family: Arial,sans-serif; color: #2b3c7a; line-height: 16px; width: 30.75p= t; text-align: left;" width=3D"41" valign=3D"top"><a href=3D"https://www.li= nkedin.com/company/lyra-network_2" style=3D"border: none; text-decoration: = none; margin: 0; float: left; display: inline-block; width: 41px;" data-mce= -href=3D"https://www.linkedin.com/company/lyra-network_2" data-mce-style=3D= "border: none; text-decoration: none; margin: 0; float: left; display: inli= ne-block; width: 41px;"><img src=3D"cid:11845310ca84fd4e4def524810120e980ff= 072e5@zimbra" data-mce-src=3D"/home/admin(a)lyra-network.com/corporate-docume= nts/element-signature_logo_LinkedIn_41x28.jpg" doc=3D"corporate-documents/e= lement-signature_logo_LinkedIn_41x28.jpg" width=3D"41" height=3D"28" border= =3D"0"></a><br data-mce-bogus=3D"1"></td><td style=3D"margin: 0; font-size:= 11px; font-family: Arial,sans-serif; color: #2b3c7a; line-height: 16px; wi= dth: 31.5pt; text-align: left;" data-mce-style=3D"margin: 0; font-size: 11p= x; font-family: 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/LyraNetwork" style=3D"border: none; text-decoration: none; marg= in: 0; float: left; display: inline-block; width: 42px;" data-mce-href=3D"h= ttps://twitter.com/LyraNetwork" data-mce-style=3D"border: none; text-decora= tion: none; margin: 0; float: left; display: inline-block; width: 42px;"><i= mg src=3D"cid:c2735661868f46ef1f20b767bf188c91be0f52bd@zimbra" alt=3D"" dat= a-mce-src=3D"/home/admin(a)lyra-network.com/corporate-documents/element-signa= ture_logo_Twitter_42x28.jpg" doc=3D"corporate-documents/element-signature_l= ogo_Twitter_42x28.jpg" width=3D"42" height=3D"28" border=3D"0"></a><br data= -mce-bogus=3D"1"></td><td style=3D"margin: 0; font-size: 11px; font-family:= Arial,sans-serif; color: #2b3c7a; line-height: 16px; width: 258.75pt; text= -align: left;" data-mce-style=3D"margin: 0; font-size: 11px; font-family: A= rial,sans-serif; color: #2b3c7a; line-height: 16px; width: 258.75pt; text-a= lign: left;" width=3D"345" valign=3D"top"><a href=3D"https://payzen.eu" sty= le=3D"border: none; text-decoration: none; margin: 0; float: left; display:= inline-block; width: 61px;" data-mce-href=3D"https://payzen.eu" data-mce-s= tyle=3D"border: none; text-decoration: none; margin: 0; float: left; displa= y: inline-block; width: 61px;"><img src=3D"cid:4003b71aaa9799afe7266b76ecec= 0006c92f65bb@zimbra" alt=3D"" data-mce-src=3D"/home/admin(a)lyra-network.com/= corporate-documents/element-signature_payzen_61x28.jpg" doc=3D"corporate-do= cuments/element-signature_payzen_61x28.jpg" width=3D"61" height=3D"28" bord= er=3D"0"></a><br data-mce-bogus=3D"1"></td></tr></tbody></table><table styl= e=3D"margin: 0; table-layout: fixed; border: none; width: 345pt;" data-mce-= style=3D"margin: 0; table-layout: fixed; border: none; width: 345pt;" width= =3D"460" cellspacing=3D"0" cellpadding=3D"0"><tbody><tr><td><hr style=3D"ba= ckground: #293b79 none repeat scroll 0% 0%; width: 100%; height: 4px; color= : #293b79; margin: 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; bo= rder: none; width: 345pt;" width=3D"460" cellspacing=3D"0" cellpadding=3D"0= "><tbody><tr><td style=3D"margin: 0; font-size: 11px; font-family: Arial,sa= ns-serif; color: #2b3c7a; line-height: 16px; width: 30.75pt; text-align: le= ft;" data-mce-style=3D"margin: 0; font-size: 11px; font-family: Arial,sans-= serif; color: #2b3c7a; line-height: 16px; width: 30.75pt; text-align: left;= "><div>Lyra Network, 109 rue de l'innovation, 31670 Lab=C3=A8ge, FRANCE</di= v></td></tr></tbody></table><div><br></div></div></div></body></html> ------=_Part_1324121_120729041.1490968161320 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: <1504d440a45e25d470766a589e361163b925cd4d@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_1324121_120729041.1490968161320 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: <089c696a3ee09447fa2f5d20d0074bf34dc05be8@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_1324121_120729041.1490968161320 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: <11845310ca84fd4e4def524810120e980ff072e5@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_1324121_120729041.1490968161320 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: <c2735661868f46ef1f20b767bf188c91be0f52bd@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_1324121_120729041.1490968161320 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: <4003b71aaa9799afe7266b76ecec0006c92f65bb@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_1324121_120729041.1490968161320-- ------=_Part_1324120_374554609.1490968161320--

2 1