May 2016 - Users - oVirt List Archives

Network Address Change
by Paul.LKW 28 Dec '22

28 Dec '22

Hi All: I just has a case, I need to change the oVirt host and engine IP address due to data center decommission I checked in the hosted-engine host there are some files I could change ; in ovirt-hosted-engine/hosted-engine.conf ca_subject="O=simple.com, CN=1.2.3.4" gateway=1.2.3.254 and of course I need to change the ovirtmgmt interface IP too, I think just change the above line could do the tick, but where could I change the other host IP in the cluster ? I think I have to be lost all the host as once changed the hosted-engine host IP as it is in diff. sub net. Does there any command line tools could do that or someone has such experience could share? Best Regards, Paul.LKW

4 6

looking for some ISV backup software which integrates the backup API
by Nathanaël Blanchet 08 Jun '22

08 Jun '22

Hello, We are about to change our backup provider, and I find it is a great chance to choose a full supported ovirt backup solution. I currently use this python script vm-backup-scheduler (https://github.com/wefixit-AT/oVirtBackup) but it is not the workflow officially suggested by the community (https://www.ovirt.org/develop/release-management/features/storage/backup-re…) I've been looking for a long time an ISV who supports such an API, but the only one I found is this one : Acronis Backup Advanced suggested here https://access.redhat.com/ecosystem/search/#/ecosystem/Red%20Hat%20Enterpri… I ran the trial version, but it doesn't seem to do better than the vm-backup-scheduler script, and it doesn't seem to use the backup API (attach a clone as a disk to an existing vm). Can you suggest me some other ISV solutions, if they ever exist... or share me your backup experience?

5 4

Vm suddenly paused with error "vm has paused due to unknown storage error"
by Jasper Siero 18 Feb '20

18 Feb '20

Hi all, Since we upgraded our Ovirt nodes to CentOS 7 a vm (not a specific one but never more then one) will sometimes pause suddenly with the error "VM ... has paused due to unknown storage error". It happens now two times in a month. The Ovirt node uses san storage for the vm's running on it. When a specific vm is pausing with an error the other vm's keeps running without problems. The vm runs without problems after unpausing it. Versions: CentOS Linux release 7.1.1503 vdsm-4.14.17-0 libvirt-daemon-1.2.8-16 vdsm.log: VM Channels Listener::DEBUG::2015-10-25 07:43:54,382::vmChannels::95::vds::(_handle_timeouts) Timeout on fileno 78. libvirtEventLoop::INFO::2015-10-25 07:43:56,177::vm::4602::vm.Vm::(_onIOError) vmId=`77f07ae0-cc3e-4ae2-90ec-7fba7b11deeb`::abnormal vm stop device virtio-disk0 error eother libvirtEventLoop::DEBUG::2015-10-25 07:43:56,178::vm::5204::vm.Vm::(_onLibvirtLifecycleEvent) vmId=`77f07ae0-cc3e-4ae2-90ec-7fba7b11deeb`::event Suspended detail 2 opaque None libvirtEventLoop::INFO::2015-10-25 07:43:56,178::vm::4602::vm.Vm::(_onIOError) vmId=`77f07ae0-cc3e-4ae2-90ec-7fba7b11deeb`::abnormal vm stop device virtio-disk0 error eother ........... libvirtEventLoop::INFO::2015-10-25 07:43:56,180::vm::4602::vm.Vm::(_onIOError) vmId=`77f07ae0-cc3e-4ae2-90ec-7fba7b11deeb`::abnormal vm stop device virtio-disk0 error eother specific error part in libvirt vm log: block I/O error in device 'drive-virtio-disk0': Unknown error 32758 (32758) ........... block I/O error in device 'drive-virtio-disk0': Unknown error 32758 (32758) engine.log: 2015-10-25 07:44:48,945 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-40) [a43dcc8] VM diataal-prod-cas1 77f07ae0-cc3e-4ae2-90ec-7fba7b11deeb moved from Up --> Paused 2015-10-25 07:44:49,003 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-40) [a43dcc8] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: VM diataal-prod-cas1 has paused due to unknown storage error. Has anyone experienced the same problem or knows a way to solve this? Kind regards, Jasper

3 3

[Users] Problem Creating "oVirtEngine" Machine
by Richie＠HIP 15 May '19

15 May '19

--Apple-Mail=_DF4BF6D1-1F87-4F60-9CF9-070D4D836241 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I can't agree with you more. Modifying every box's or Virtual Machine's = HOSTS file with a FQDN and IP SHOULD work, but in my case it is not. = There are several reasons I've come to believe could be the problem = during my trial-and-errors testing and learning. FIRST - MACHINE IPs. THe machine's "Names" where not appearing in the Microsoft Active = Directory DHCP along with their assigned IPs; in other words, the DHCP = just showed an "Assigned IP", equal to the Linux Machine's IP, with a = <empty> ('i.e. blank, none, silch, plan old "no-letters-or-numbers") = "Name" in the "Name" (i.e. machines "network name", or FQDN-value used = by the Windows AD DNS-service) column. =20 if your IP is is appearing with an <empty> "name", there is no "host = name" to associate the IP, it makes it difficult to define a FQDN; which = isn't that useful if we're going to use the HOSTS files in all = participating machines in an oVirt Installation. I kept banging my head for three (3) long hours trying to find the = problem. In Fedora 18, I could't find where the "network name" of the machine = could be defined. =20 I tried putting the "Additional Search Domains" and/or "DHCP Client ID" = in Fedora's 18 Desktop - under "System Settings > Hardware > Network > = Options > IPv4 Setting" The DHCP went crazy; showing an "Aberrant-MAC-Address" (i.e. a really = long-sting value where the machine's MAC address should be), and we knew = the MAC address as we obtained using "ifconfig" on the machine getting = it's IP from the DHCP. So we reverted these entries from the = aforementioned, rebooted, and got an assigned IP, with proper MAC = address, but still no "Name" Kept wondering around the "Settings" and seeing which one made sense, = but what the heck, I went for it. =20 Under "System Settings > System > Details" I found the information about = GNOME and the machine's hardware. =20 There was a field for "Device Name" that originally had = "localhost.localdomain"; I changed the value to "ovirtmanager". and = under "Graphic" changed to "Forced Fallback Mode" to "ON". =20 I also installed all Kerberos libraries and client (i.e. authconfig-gtk, = authhub, authhub-client, krb5-apple-clents, krb5-auth-dialog, = krb5-workstation, pam-kcoda, pam-krb5, root-net.krb5) and rebooted VOILA=85!!! =20 I don;t know if it was the definition of "Device Name" from = "localhost.localdomain" to "ovirtengine", of the Kerberos libraries = install, or both. But finally the MS AD DHCP was showing the = Addigned-IP, the machine "Name" and the proper MAC-address. Regardless, = setting the machine's "Network Name" under "System Settings > System > = Details > Device Name", with no explanation of what "Device Name" meant = or was used for, was the last place I would have imagined this network = setting could be defined. NOTE - Somebody has to try the two steps I did together, separately. to = see which one is the real problem-solver; for me it is working, and "if = it ain't broke, don't fix it=85" Now that I have the DHCP / IP thing sorted, I have to do the DNS stuff. To this point, I've addressed the DHCP and "Network Name" of the = IP-Lease (required for the DNS to work). This still does't completely = explain why, by modifying the HOSTS file (allowing be to set and IP and = non-DNS FQDN). allows me to install the oVirtEngine "as long as I do not = use default HTTPd service parameters as suggested by the install". By = using the HOST file to "define" FQDNs, AND NOT using the default HTTPd = suggested changes, I'm able to install the oVirtEngine (given that I use = ports 8700 and 8701) to access the "oVirtEngine Welcome Screen", BUT = NONE of the "oVirt Portals" work=85 YET=85!!! More to come during the week Richie Jos=E9 E ("Richie") Piovanetti, MD, MS=20 M: 787-615-4884 | richiepiovanetti(a)healthcareinfopartners.com On Aug 2, 2013, at 3:10 AM, Joop <jvdwege(a)xs4all.nl> wrote: > Hello Ritchie, >=20 >> In a conversation via IRC, someone suggested that I activate = "dnsmask" to overcome what appears to be a DNS problem. I'll try that = other possibility once I get home later today. >>=20 >> In the mean time, what do you mean by "fixing the hostname"=85? I = opened and fixed the HOSTNAMES and changed it from = "localhost-localdomain" to "localhost.localdomain" and that made no = difference. Albeit, after changing I didm;t restart, remove ovirtEngine = ((using "engine-cleanup") and reinstalled via "engine-setup". Is that = what you mean=85? >>=20 >>=20 >>=20 >> In the mean time, the fact that even if I resolve the issue of = oVirtEngine I will not be able to connect to the oVirt Nodes unless I = have DNS resolution, apparently means I should do something with = resolving via DNS in my home LAN (i.e implement some sort of "DNS Cache" = so I can resolve my home computers via DNS inside my LAN). >>=20 >> Any suggestions are MORE THAN WELCOME=85!!! >> =20 >=20 > Having setup ovirt more than I can count right now I share your = feeling that it isn't always clear why things are going wrong, but in = this case I suspect that there is a rather small thing missing. > In short if you setup ovirt-engine, either using virtualbox or on real = hardware, and you give your host a meaningfull name AND you add that = info also in your /etc/hosts file than things SHOULD work, no need for = dnsmasq or even bind. Would make things easier once you start adding = virt hosts to you infrastructure since you will need to duplicate these = actions on each host (add engine name/ip to each host and add each host = to the others and all hosts to engine) >=20 > Just ask if you need more assistance and I will write down a small = howto that should work out of the box else I might have some time to see = if I can get things going. >=20 > Regards, >=20 > Joop >=20 --Apple-Mail=_DF4BF6D1-1F87-4F60-9CF9-070D4D836241 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I = can't agree with you more.  Modifying every box's or Virtual = Machine's HOSTS file with a FQDN and IP SHOULD work, but in my case it = is not.  There are several reasons I've come to believe could be = the problem during my trial-and-errors testing and = learning.<div><div> </div><div>FIRST - MACHINE IPs.</div><ul = class=3D"MailOutline"><li>THe machine's "Names" where not appearing in = the Microsoft Active Directory DHCP along with their assigned = IPs; in other words, the DHCP just showed an "Assigned IP", equal to the = Linux Machine's IP, with a <empty> ('i.e. blank, none, silch, plan = old "no-letters-or-numbers") "Name" in the "Name" (i.e. machines = "network name", or FQDN-value used by the Windows AD DNS-service) = column.  </li><li>if your IP is is appearing with an <empty> = "name", there is no "host name" to associate the IP, it makes it = difficult to define a FQDN; which isn't that useful if we're going to = use the HOSTS files in all participating machines in an oVirt = Installation.</li><li>I kept banging my head for three (3) long hours = trying to find the problem.</li><ul><li>In Fedora 18, I could't find = where the "network name" of the machine could be defined. =  </li><li>I tried putting the "Additional Search Domains" and/or = "DHCP Client ID" in Fedora's 18 Desktop - under "System Settings > = Hardware > Network > Options > IPv4 Setting"</li><ul><li>The = DHCP went crazy;  showing an "Aberrant-MAC-Address" (i.e. a really = long-sting value where the machine's MAC address should be), and we knew = the MAC address as we obtained using "ifconfig" on the machine getting = it's IP from the DHCP.  So we reverted these entries from the = aforementioned, rebooted, and got an assigned IP, with proper MAC = address, but still no "Name"</li></ul><li>Kept wondering around the = "Settings" and seeing which one made sense, but what the heck, I went = for it.  </li><ul><li>Under "System Settings > System > = Details" I found the information about GNOME and the machine's hardware. =  </li><li>There was a field for "Device Name" that originally had = "localhost.localdomain"; I changed the value to "ovirtmanager". and = under "Graphic" changed to "Forced Fallback Mode" to "ON". =  </li><li>I also installed all Kerberos libraries and client (i.e. = authconfig-gtk, authhub, authhub-client, krb5-apple-clents, = krb5-auth-dialog, krb5-workstation, pam-kcoda, pam-krb5, root-net.krb5) = and rebooted</li><li>VOILA=85!!!  </li></ul><li>I don;t know if it = was the definition of "Device Name" from "localhost.localdomain" to = "ovirtengine", of the Kerberos libraries install, or both.  But = finally the MS AD DHCP was showing the Addigned-IP, the machine "Name" = and the proper MAC-address.  Regardless, setting the machine's = "Network Name" under "System Settings > System > Details = > Device Name", with no explanation of what "Device Name" meant = or was used for, was the last place I would have imagined this = network setting could be defined.</li><li>NOTE - Somebody has to = try the two steps I did together, separately. to see which one is the = real problem-solver; for me it is working, and "if it ain't broke, don't = fix it=85"</li></ul></ul><div> </div><div>Now that I have the DHCP / = IP thing sorted, I have to do the DNS stuff.</div><div> </div><div>To = this point, I've addressed the DHCP and "Network Name" of the IP-Lease = (required for the DNS to work).  This still does't completely = explain why, by modifying the HOSTS file (allowing be to set and IP and = non-DNS FQDN). allows me to install the oVirtEngine "as long as I = do not use default  HTTPd service parameters as suggested by the = install".  By using the HOST file to "define" FQDNs, AND = NOT using the default HTTPd suggested changes, I'm able to install the = oVirtEngine (given that I use ports 8700 and 8701) to access the = "oVirtEngine Welcome Screen", BUT NONE of the "oVirt Portals" work=85 = YET=85!!!</div><div> </div><div>More to come during the = week</div><div> </div><div>Richie</div><div = apple-content-edited=3D"true"> Jos=E9 E ("Richie") Piovanetti, MD, = MS  M: 787-615-4884 | <a = href=3D"mailto:richiepiovanetti@healthcareinfopartners.com">richiepiovanet= ti(a)healthcareinfopartners.com</a> </div> <div><d= iv>On Aug 2, 2013, at 3:10 AM, Joop <<a = href=3D"mailto:jvdwege@xs4all.nl">jvdwege(a)xs4all.nl</a>> = wrote:</div> <blockquote = type=3D"cite">Hello Ritchie, <blockquote type=3D"cite">In a = conversation via IRC, someone suggested that I activate "dnsmask" to = overcome what appears to be a DNS problem.  I'll try that other = possibility once I get home later today. In the mean time, what = do you mean by "fixing the hostname"=85?  I opened and fixed the = HOSTNAMES and changed it from "localhost-localdomain" to = "localhost.localdomain" and that made no difference.  Albeit, after = changing I didm;t restart, remove ovirtEngine ((using "engine-cleanup") = and reinstalled via "engine-setup".  Is that what you = mean=85? In the mean time, the fact that even if I = resolve the issue of oVirtEngine I will not be able to connect to the = oVirt Nodes unless I have DNS resolution, apparently means I should do = something with resolving via DNS in my home LAN (i.e implement some sort = of "DNS Cache" so I can resolve my home computers via DNS inside my = LAN). Any suggestions are MORE THAN WELCOME=85!!! =   </blockquote> Having setup ovirt more than I can count = right now I share your feeling that it isn't always clear why things are = going wrong, but in this case I suspect that there is a rather small = thing missing. In short if you setup ovirt-engine, either using = virtualbox or on real hardware, and you give your host a meaningfull = name AND you add that info also in your /etc/hosts file than things = SHOULD work, no need for dnsmasq or even bind. Would make things easier = once you start adding virt hosts to you infrastructure since you will = need to duplicate these actions on each host (add engine name/ip to each = host and add each host to the others and all hosts to = engine) Just ask if you need more assistance and I will write = down a small howto that should work out of the box else I might have = some time to see if I can get things = going. Regards, Joop </blockquote></div> </div></b= ody></html>= --Apple-Mail=_DF4BF6D1-1F87-4F60-9CF9-070D4D836241--

2 1

Re: [ovirt-users] Question about the ovirt-engine-sdk-java
by Michael Pasternak 15 May '19

15 May '19

------=_Part_1975902_834617789.1445161505459 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi=C2=A0Salifou, Actually java sdk is=C2=A0intentionally=C2=A0hiding transport level interna= ls so developers could stay in java domain,if your headers are static, easi= est way would be using reverse proxy in a middle to intercept requests,=C2= =A0 can you tell me why do you need this? =20 On Friday, October 16, 2015 1:14 AM, Salifou Sidi M. Malick <ssidimah@= redhat.com> wrote: =20 Hi Micheal, I have a question about the ovirt-engine-sdk-java. Is there a way to add custom request headers to each RHEVM API call? Here is an example of a request that I would like to do: $ curl -v -k \ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -H "ID: user1(a)ad.xyz.com" \ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -H "PASSWORD: Pwssd" \ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -H "TARGET: kobe" \ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://vm0.smalick.com/api/hosts I would like to add ID, PASSWORD and TARGET as HTTP request header.=20 Thanks, Salifou ------=_Part_1975902_834617789.1445161505459 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><head></head><body><div style=3D"color:#000; background-color:#fff; f= ont-family:HelveticaNeue-Light, Helvetica Neue Light, Helvetica Neue, Helve= tica, Arial, Lucida Grande, sans-serif;font-size:13px"><div id=3D"yui_3_16_= 0_1_1445160422533_3555" dir=3D"ltr">Hi Salifou,</div><div id=3D"yui_3_16_0_1_144= 5160422533_3555" dir=3D"ltr"> = </div><div id=3D"yui_3_16_0_1_1445160422533_3555" dir=3D"ltr">= Actually java sdk is intentionally hidi= ng transport level internals so developers could stay in java domain,</span= ></div><div id=3D"yui_3_16_0_1_1445160422533_3555" dir=3D"ltr">if your headers are static, easiest way would= be using reverse proxy in a middle to intercept requests,  = </div><div id=3D"yui_3_16_0_1_1445160422533_3555" dir=3D"ltr"> </div><div id=3D"yui_3_16= _0_1_1445160422533_3555" dir=3D"ltr">can you tell me why do you need this?</span= > </div> <div class=3D"qtdSeparateBR"> </div><div class=3D"y= ahoo_quoted" style=3D"display: block;"> <div style=3D"font-family: Helvetic= aNeue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial, Lucida= Grande, sans-serif; font-size: 13px;"> <div style=3D"font-family: Helvetic= aNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-si= ze: 16px;"> <div dir=3D"ltr"> On Friday, O= ctober 16, 2015 1:14 AM, Salifou Sidi M. Malick <ssidimah(a)redhat.com>= wrote: </div> <div class=3D"y_msg_container">Hi Mich= eal, I have a question about the ovirt-engine-sdk-java. Is th= ere a way to add custom request headers to each RHEVM API call? Here= is an example of a request that I would like to do: $ curl -v -k \<= br>          -H "ID: <a ymailto=3D"mailto:user1@ad= .xyz.com" href=3D"mailto:user1@ad.xyz.com">user1(a)ad.xyz.com</a>" \ &nbsp= ;         -H "PASSWORD: Pwssd" \     &nbsp= ;     -H "TARGET: kobe" \           <= a href=3D"https://vm0.smalick.com/api/hosts" target=3D"_blank">https://vm0.= smalick.com/api/hosts</a> I would like to add ID, PASSWORD and T= ARGET as HTTP request header. Thanks, Salifou </d= iv> </div> </div> </div></div></body></html> ------=_Part_1975902_834617789.1445161505459--

2 1

[Users] oVirt Weekly Sync Meeting Minutes -- 2012-05-23
by Mike Burns 15 May '19

15 May '19

Minutes: http://ovirt.org/meetings/ovirt/2012/ovirt.2012-05-23-14.00.html Minutes (text): http://ovirt.org/meetings/ovirt/2012/ovirt.2012-05-23-14.00.txt Log: http://ovirt.org/meetings/ovirt/2012/ovirt.2012-05-23-14.00.log.html ========================= #ovirt: oVirt Weekly Sync ========================= Meeting started by mburns at 14:00:23 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2012/ovirt.2012-05-23-14.00.log.html . Meeting summary --------------- * agenda and roll call (mburns, 14:00:41) * Status of next release (mburns, 14:05:17) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=822145 (mburns, 14:05:29) * AGREED: freeze date and beta release delayed by 1 week to 2012-06-07 (mburns, 14:12:33) * post freeze, release notes flag needs to be used where required (mburns, 14:14:21) * https://bugzilla.redhat.com/show_bug.cgi?id=821867 is a VDSM blocker for 3.1 (oschreib, 14:17:27) * ACTION: dougsland to fix upstream vdsm right now, and open a bug on libvirt augeas (oschreib, 14:21:44) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=822158 (mburns, 14:23:39) * assignee not available, update to come tomorrow (mburns, 14:24:59) * ACTION: oschreib to make sure BZ#822158 is handled quickly (oschreib, 14:25:29) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=824397 (mburns, 14:28:55) * 824397 expected to be merged prior next week's meeting (mburns, 14:29:45) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=824420 (mburns, 14:30:15) * tracker for node based on F17 (mburns, 14:30:28) * blocked by util-linux bug currently (mburns, 14:30:40) * new build expected from util-linux maintainer in next couple days (mburns, 14:30:55) * sub-project status -- engine (mburns, 14:32:49) * nothing to report outside of blockers discussed above (mburns, 14:34:00) * sub-project status -- vdsm (mburns, 14:34:09) * nothing outside of blockers above (mburns, 14:35:36) * sub-project status -- node (mburns, 14:35:43) * working on f17 migration, but blocked by util-linux bug (mburns, 14:35:58) * should be ready for freeze deadline (mburns, 14:36:23) * Review decision on Java 7 and Fedora jboss rpms in oVirt Engine (mburns, 14:36:43) * Java7 basically working (mburns, 14:37:19) * LINK: http://gerrit.ovirt.org/#change,4416 (oschreib, 14:39:35) * engine will make ack/nack statement next week (mburns, 14:39:49) * fedora jboss rpms patch is in review, short tests passed (mburns, 14:40:04) * engine ack on fedora jboss rpms and java7 needed next week (mburns, 14:44:47) * Upcoming Workshops (mburns, 14:45:11) * NetApp workshop set for Jan 22-24 2013 (mburns, 14:47:16) * already at half capacity for Workshop at LinuxCon Japan (mburns, 14:47:37) * please continue to promote it (mburns, 14:48:19) * proposal: board meeting to be held at all major workshops (mburns, 14:48:43) * LINK: http://www.ovirt.org/wiki/OVirt_Global_Workshops (mburns, 14:49:30) * Open Discussion (mburns, 14:50:12) * oVirt/Quantum integration discussion will be held separately (mburns, 14:50:43) Meeting ended at 14:52:47 UTC. Action Items ------------ * dougsland to fix upstream vdsm right now, and open a bug on libvirt augeas * oschreib to make sure BZ#822158 is handled quickly Action Items, by person ----------------------- * dougsland * dougsland to fix upstream vdsm right now, and open a bug on libvirt augeas * oschreib * oschreib to make sure BZ#822158 is handled quickly * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * mburns (98) * oschreib (55) * doronf (12) * lh (11) * sgordon (8) * dougsland (8) * ovirtbot (6) * ofrenkel (4) * cestila (2) * RobertMdroid (2) * ydary (2) * rickyh (1) * yzaslavs (1) * cctrieloff (1) * mestery_ (1) * dustins (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

2 1

[QE][ACTION REQUIRED] oVirt 3.5.1 RC status - postponed
by Sandro Bonazzola 15 May '19

15 May '19

Hi, We have still blockers for oVirt 3.5.1 RC release so we need to postpone it until they'll be fixed. The bug tracker [1] shows 1 open blocker: Bug ID Whiteboard Status Summary 1160846 sla NEW Can't add disk to VM without specifying disk profile when the storage domain has more than one disk profile In order to stabilize the release a new branch ovirt-engine-3.5.1 will be created from the same git hash used for composing the RC. - ACTION: Gilad please provide ETA on above blocker, the new proposed RC date will be decided on the given ETA. Maintainers: - Please be sure that 3.5 snapshot allow to create VMs - Please be sure that no pending patches are going to block the release - If any patch must block the RC release please raise the issue as soon as possible. There are still 57 bugs [2] targeted to 3.5.1. Excluding node and documentation bugs we still have 37 bugs [3] targeted to 3.5.1. Maintainers / Assignee: - Please add the bugs to the tracker if you think that 3.5.1 should not be released without them fixed. - ACTION: Please update the target to 3.5.2 or later for bugs that won't be in 3.5.1: it will ease gathering the blocking bugs for next releases. - ACTION: Please fill release notes, the page has been created here [4] Community: - If you're testing oVirt 3.5 nightly snapshot, please add yourself to the test page [5] [1] http://bugzilla.redhat.com/1155170 [2] http://goo.gl/7G0PDV [3] http://goo.gl/6gUbVr [4] http://www.ovirt.org/OVirt_3.5.1_Release_Notes [5] http://www.ovirt.org/Testing/oVirt_3.5.1_Testing -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

[Users] Lifecycle / upgradepath
by Sven Kieske 11 May '19

11 May '19

Hi Community, Currently, there is no single document describing supported (which means: working ) upgrade scenarios. I think the project has matured enough, to have such an supported upgradepath, which should be considered in the development of new releases. As far as I know, currently it is supported to upgrade from x.y.z to x.y.z+1 and from x.y.z to x.y+1.z but not from x.y-1.z to x.y+1.z directly. maybe this should be put together in a wiki page at least. also it would be cool to know how long a single "release" would be supported. In this context I would define a release as a version bump from x.y.z to x.y+1.z or to x+1.y.z a bump in z would be a bugfix release. The question is, how long will we get bugfix releases for a given version? What are your thoughts? -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

2 1

[Users] Nested virtualization with Opteron 2nd generation and oVirt 3.1 possible?
by Gianluca Cecchi 11 May '19

11 May '19

Hello, I have 2 physical servers with Opteron 2nd gen cpu. There is CentOS 6.3 installed and some VM already configured on them. Their /proc/cpuinfo contains ... model name : Dual-Core AMD Opteron(tm) Processor 8222 ... kvm_amd kernel module is loaded with its default enabled nested option # systool -m kvm_amd -v Module = "kvm_amd" Attributes: initstate = "live" refcnt = "15" srcversion = "43D8067144E7D8B0D53D46E" Parameters: nested = "1" npt = "1" ... I already configured a fedora 17 VM as a oVirt 3.1 Engine I'm trying to configure another VM as oVirt 3.1 node with ovirt-node-iso-2.5.5-0.1.fc17.iso It seems I'm not able to configure so that ovirt install doesn't complain. After some attempts, I tried this in my vm.xml for the cpu: <cpu mode='custom' match='exact'> <model fallback='allow'>athlon</model> <vendor>AMD</vendor> <feature policy='require' name='pni'/> <feature policy='require' name='rdtscp'/> <feature policy='force' name='svm'/> <feature policy='require' name='clflush'/> <feature policy='require' name='syscall'/> <feature policy='require' name='lm'/> <feature policy='require' name='cr8legacy'/> <feature policy='require' name='ht'/> <feature policy='require' name='lahf_lm'/> <feature policy='require' name='fxsr_opt'/> <feature policy='require' name='cx16'/> <feature policy='require' name='extapic'/> <feature policy='require' name='mca'/> <feature policy='require' name='cmp_legacy'/> </cpu> Inside node /proc/cpuinfo becomes processor : 3 vendor_id : AuthenticAMD cpu family : 6 model : 2 model name : QEMU Virtual CPU version 0.12.1 stepping : 3 microcode : 0x1000065 cpu MHz : 3013.706 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall mmxext fxsr_opt lm nopl pni cx16 hypervisor lahf_lm cmp_legacy cr8_legacy bogomips : 6027.41 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: 2 questions: 1) Is there any combination in xml file to give to my VM so that oVirt doesn't complain about missing hardware virtualization with this processor? 2) suppose 1) is not possible in my case and I still want to test the interface and try some config operations to see for example the differences with RHEV 3.0, how can I do? At the moment this complaint about hw virtualization prevents me to activate the node. I get Installing Host f17ovn01. Step: RHEV_INSTALL. Host f17ovn01 was successfully approved. Host f17ovn01 running without virtualization hardware acceleration Detected new Host f17ovn01. Host state was set to Non Operational. Host f17ovn01 moved to Non-Operational state. Host f17ovn01 moved to Non-Operational state as host does not meet the cluster's minimum CPU level. Missing CPU features : CpuFlags Can I lower the requirements to be able to operate without hw virtualization in 3.1? Thanks in advance, Gianluca

2 1

Need VM run once api
by Chandrahasa S 09 May '19

09 May '19

This is a multipart message in MIME format. --=_alternative 00361B2065257E90_= Content-Type: text/plain; charset="US-ASCII" Hi Experts, We are integrating ovirt with our internal cloud. Here we installed cloudinit in vm and then converted vm to template. We deploy template with initial run parameter Hostname, IP Address, Gateway and DNS. but when we power ON initial, run parameter is not getting pushed to inside the vm. But its working when we power on VM using run once option on Ovirt portal. I believe we need to power ON vm using run once API, but we are not able get this API. Can some one help on this. I got reply on this query last time but unfortunately mail got deleted. Thanks & Regards Chandrahasa S =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you --=_alternative 00361B2065257E90_= Content-Type: text/html; charset="US-ASCII" Hi Experts, We are integrating ovirt with our internal cloud. Here we installed cloudinit in vm and then converted vm to template. We deploy template with initial run parameter Hostname, IP Address, Gateway and DNS. but when we power ON initial, run parameter is not getting pushed to inside the vm. But its working when we power on VM using run once option on Ovirt portal. I believe we need to power ON vm using run once API, but we are not able get this API. Can some one help on this. I got reply on this query last time but unfortunately mail got deleted. Thanks & Regards Chandrahasa S =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you --=_alternative 00361B2065257E90_=--

5 4

[Users] importing from kvm into ovirt
by Jonathan Horne 29 Apr '19

29 Apr '19

--_000_9BE6F493F83A594DA60C45E6A09DC5AC016BA694AUSP01DAG0201co_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I need to import a kvm virtual machine from a standalone kvm into my ovirt = cluster. Standalone is using local storage, and my ovirt cluster is using = iscsi. Can i please have some advice on whats the best way to get this sys= tem into ovirt? Right now i see it as copying the .img file to somewhere=85 but i have no i= dea where to start. I found this directory on one of my ovirt nodes: /rhev/data-center/mnt/blockSD/fe633237-14b2-4f8b-aedd-bbf753bcafaf/master/v= ms But inside is just directories that appear to have uuid-type of names, and = i can't tell what belongs to which vm. Any advice would be greatly appreciated. Thanks, jonathan ________________________________ This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind SKO= POS to any order or other contract unless pursuant to explicit written agre= ement or government initiative expressly permitting the use of e-mail for s= uch purpose. --_000_9BE6F493F83A594DA60C45E6A09DC5AC016BA694AUSP01DAG0201co_ Content-Type: text/html; charset="Windows-1252" Content-ID: <41FAB2B157C43549B6577A3495BA255C(a)collaborationhost.net> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> </head> <body style=3D"word-wrap:break-word; color:rgb(0,0,0); font-size:14px; font= -family:Calibri,sans-serif"> <div> <div> <div>I need to import a kvm virtual machine from a standalone kvm into my o= virt cluster.  Standalone is using local storage, and my ovirt cluster= is using iscsi.  Can i please have some advice on whats the best way = to get this system into ovirt?</div> </div> </div> <div> </div> <div>Right now i see it as copying the .img file to somewhere=85 but i have= no idea where to start.  I found this directory on one of my ovirt no= des:</div> <div> </div> <div>/rhev/data-center/mnt/blockSD/fe633237-14b2-4f8b-aedd-bbf753bcafaf/mas= ter/vms</div> <div> </div> <div>But inside is just directories that appear to have uuid-type of names,= and i can't tell what belongs to which vm.</div> <div> </div> <div>Any advice would be greatly appreciated.</div> <div> </div> <div>Thanks,</div> <div>jonathan</div> <hr> This is a PRIVATE message. I= f you are not the intended recipient, please delete without copying and kin= dly advise us by e-mail of the mistake in delivery. NOTE: Regardless of con= tent, this e-mail shall not operate to bind SKOPOS to any order or other contract unless pursuant to explicit wri= tten agreement or government initiative expressly permitting the use of e-m= ail for such purpose. </body> </html> --_000_9BE6F493F83A594DA60C45E6A09DC5AC016BA694AUSP01DAG0201co_--

3 2

Trying to reset password for ovirt wiki
by noc 08 Apr '19

08 Apr '19

This is a multi-part message in MIME format. --------------000005070002050708050606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hoping someone can help me out. For some reason I keep getting the following error when I try to reset my password: Reset password * Error sending mail: Failed to add recipient: jvandewege(a)nieuwland.nl [SMTP: Invalid response code received from server (code: 554, response: 5.7.1 <jvandewege(a)nieuwland.nl>: Relay access denied)] Complete this form to receive an e-mail reminder of your account details. Since I receive the ML on this address it is definitely a working address. Tried my home account too and same error but then for my home provider, Relay denied ?? A puzzled user, Joop --------------000005070002050708050606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hoping someone can help me out. For some reason I keep getting the following error when I try to reset my password: <fieldset><legend>Reset password</legend> <div class="error"> <ul> <li>Error sending mail: Failed to add recipient: <a class="moz-txt-link-abbreviated" href="mailto:jvandewege@nieuwland.nl">jvandewege(a)nieuwland.nl</a> [SMTP: Invalid response code received from server (code: 554, response: 5.7.1 <a class="moz-txt-link-rfc2396E" href="mailto:jvandewege@nieuwland.nl"><jvandewege(a)nieuwland.nl></a>: Relay access denied)]</li> </ul> </div> Complete this form to receive an e-mail reminder of your account details. </fieldset> Since I receive the ML on this address it is definitely a working address. Tried my home account too and same error but then for my home provider, Relay denied ?? A puzzled user, Joop </body> </html> --------------000005070002050708050606--

2 1

ovirt-guest-agent issue on rhel5.5
by John Michael Mercado 08 Apr '19

08 Apr '19

Hi All, I need your help. Anyone who encounter the below error and have the solution? Can you help me how to fix this? MainThread::INFO::2015-01-27 10:22:53,247::ovirt-guest-agent::57::root::Starting oVirt guest agent MainThread::ERROR::2015-01-27 10:22:53,248::ovirt-guest-agent::138::root::Unhandled exception in oVirt guest agent! Traceback (most recent call last): File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 132, in ? agent.run(daemon, pidfile) File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 63, in run self.agent = LinuxVdsAgent(config) File "/usr/share/ovirt-guest-agent/GuestAgentLinux2.py", line 371, in __init__ AgentLogicBase.__init__(self, config) File "/usr/share/ovirt-guest-agent/OVirtAgentLogic.py", line 171, in __init__ self.vio = VirtIoChannel(config.get("virtio", "device")) File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 150, in __init__ self._stream = VirtIoStream(vport_name) File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 131, in __init__ self._vport = os.open(vport_name, os.O_RDWR) OSError: [Errno 2] No such file or directory: '/dev/virtio-ports/com.redhat.rhevm.vdsm' Thanks

2 1

[Users] oVirt Workshop at LinuxCon Japan 2012
by Leslie Hawthorn 08 Apr '19

08 Apr '19

Hello everyone, As part of our efforts to raise awareness of and educate more developers about the oVirt project, we will be holding an oVirt workshop at LinuxCon Japan, taking place on June 8, 2012. You can find full details of the workshop agenda on the LinuxCon Japan site. [0] Registration for the workshop is now open and is free of charge for the first 50 participants. We will also look at adding additional participant slots to the workshop based on demand. Attendees who register for LinuxCon Japan via the workshop registration link [1] will also be eligible for a discount on their LinuxCon Japan registration. Please spread the word to folks you think would find the workshop useful. If they have already registered for LinuxCon Japan, they can simply edit their existing registration to include the workshop. [0] - https://events.linuxfoundation.org/events/linuxcon-japan/ovirt-gluster-work… [1] - http://www.regonline.com/Register/Checkin.aspx?EventID=1099949 Cheers, LH -- Leslie Hawthorn Community Action and Impact Open Source and Standards @ Red Hat identi.ca/lh twitter.com/lhawthorn

2 1

[Users] Moving iSCSI Master Data
by rni＠chef.net 07 Apr '19

07 Apr '19

--========GMXBoundary282021374122634158505 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi, it's me again.... I started my oVirt 'project' as a proof of concept,.. but it happend as always, it became production Now, I've to move the iSCSI Master data to the real iSCSI traget. Is there any way to do this, and to become rid of the old Master Data? Thank you for your help Hans-Joachim --========GMXBoundary282021374122634158505 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, it's me again.... I started my oVirt 'project' as a proof= of concept,.. but it happend as always, it became production <img alt= =3D" " title=3D" " src=3D"http://images.gmx.com/images/outsource/applicatio= n/mailclient/mailcom/resource/mailclient/icons/blue/emoticons/animated/S_02= -516742918.gif" /> Now, I've to move the iSCSI Master data to th= e real iSCSI traget. Is there any way to do this, and to become rid of= the old Master Data? Thank you fo= r your help Hans-Joachim --========GMXBoundary282021374122634158505--

3 2

[Users] Can't access RHEV-H aka ovirt-node
by Scotto Alberto 11 Mar '19

11 Mar '19

--_004_C8B8517ADA90DB40A482797D59EB83896419FE83CED01MBXS08repl_ Content-Type: multipart/alternative; boundary="_000_C8B8517ADA90DB40A482797D59EB83896419FE83CED01MBXS08repl_" --_000_C8B8517ADA90DB40A482797D59EB83896419FE83CED01MBXS08repl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I can't login to the hypervisor, neither as root nor as admin, neither from= another computer via ssh nor directly on the machine. I'm sure I remember the passwords. This is not the first time it happens: l= ast time I reinstalled the host. Everything worked ok for about 2 weeks, an= d then... What's going on? Is it a known behavior, somehow? Before rebooting the hypervisor, I would like to try something. RHEV Manage= r talks to RHEV-H without any problems. Can I login with RHEV-M's keys? how= ? Thank you all. Alberto Scotto [Blue] Via Cardinal Massaia, 83 10147 - Torino - ITALY phone: +39 011 29100 al.scotto(a)reply.it www.reply.it ________________________________ -- The information transmitted is intended for the person or entity to which i= t is addressed and may contain confidential and/or privileged material. Any= review, retransmission, dissemination or other use of, or taking of any ac= tion in reliance upon, this information by persons or entities other than t= he intended recipient is prohibited. If you received this in error, please = contact the sender and delete the material from any computer. --_000_C8B8517ADA90DB40A482797D59EB83896419FE83CED01MBXS08repl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <style>  </style> </head> <body lang=3D"IT" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Hi all, I can’t login to the hype= rvisor, neither as root nor as admin, neither from another computer via ssh= nor directly on the machine. I’m sure I remember the p= asswords. This is not the first time it happens: last time I reinstalled th= e host. Everything worked ok for about 2 weeks, and then... What’s going on? Is it a = known behavior, somehow? Before rebooting the hypervisor= , I would like to try something. RHEV Manager talks to RHEV-H without any p= roblems. Can I login with RHEV-M’s keys? how?   Thank you all. </div> <div align=3D"left"> Alberto Scotto <img border=3D"0" alt=3D"Blue" src=3D"cid:bde= 5ac62d10545908e269a6006dbd5ac" style=3D"margin:0px"> Via Cardinal Massaia, 83 10147 - Torino - ITALY phone: +39 011 29100 <a href=3D"al.scotto(a)reply.it" target=3D"" style=3D"color:blue; text-decora= tion:underline">al.scotto(a)reply.it</a> <a title=3D"" href=3D"www.reply.it" target=3D"" style=3D"color:blue; text-d= ecoration:underline">www.reply.it</a>   </div> <hr> -- The information transmitted is intended for the person or entity to which i= t is addressed and may contain confidential and/or privileged material. Any= review, retransmission, dissemination or other use of, or taking of any ac= tion in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If= you received this in error, please contact the sender and delete the mater= ial from any computer. </body> </html> --_000_C8B8517ADA90DB40A482797D59EB83896419FE83CED01MBXS08repl_-- --_004_C8B8517ADA90DB40A482797D59EB83896419FE83CED01MBXS08repl_ Content-Type: image/png; name="blue.png" Content-Description: blue.png Content-Disposition: inline; filename="blue.png"; size=2834; creation-date="Tue, 11 Sep 2012 14:14:44 GMT"; modification-date="Tue, 11 Sep 2012 14:14:44 GMT" Content-ID: <bde5ac62d10545908e269a6006dbd5ac> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAIwAAAAyCAYAAACOADM7AAAABmJLR0QA/gD+AP7rGNSCAAAACXBI WXMAAA3XAAAN1wFCKJt4AAAACXZwQWcAAACMAAAAMgCR0D3bAAAKaUlEQVR42u2ce5AUxRnAf313 3Al4eCAYFaIgyMNEUF6KlYoVIDBArDxqopWxQgViQlWsPHA0MUlZVoyKRsdSE4lGomjIaHS0UlHL wTIPpEgQFQUUjYIWdfIIScyBHi/Z6/zRM1xP3yzs7t3unOX8qra2H9M9vb3f9Pf19/WukFKSk1Mq dVkPIOejRS4wOWXR6wVGuP5I4foDsh5HjkL0VhtGuP5A4CFgNrAD+Lb0nKeyHtfHnd68wixGCQvA qcA9wvWPy3pQH3caan1D4fonAYeBDwEZjaFflAaok56zHRhsNG0B+gAHSrhHarn0nFp/3NLnxbKP B06I5kECO2UYZD2sLtRcYIBJwK+BoYBACU89cAjoAIRw/TuAJcClQGy//FJ6zvvH6ly4/qXAz4vU HQA2A4H0nIcz+OxH41eAHaU3AhdkPaA0MrFhhOuPB2YA5wBnA6ehni5dgKcBu4C5wLZS7Rfh+g8A 80u49HHgEuk5h2s+AeaYLbsO2AKMiIqWyzBYkPW40shihUF6zkbUUwSAcP0G4FHgS9pl10rPmQMs LbXfSBVNLPHyrwDfBO7JYg4MRqEempjnsh5QMXqL0Xsl8EUt3w5cXUE/w4AztfzzwGSUGrwoyuvM yfqDR5yLUssxL2U9oGJkssLoCNdfjLJXdBZIz9lQQXcTgSYt/4z0nHjy1wvX3wW8oNX3O8q4TgKm AGegjNB/As9JzzmYer1lTwKGoOyyV2UYtArLngLMQ9lh64EVRQxZ3V5pje4V9zsVGBRl22QYrDXu e0HUvwD+K8NgXbe/lKOQqcAI178MuM0ovk16zqMVdjnNyL9g5E2DrTVlTP1RRvM3gIFG9RvC9RdK z/lHoo2yQQJgeFR0hbDsT6FUns544Icp456qpV+RYaAL5RJgepR+FWXzxfcdA6zRrr0SqKrAZKaS hOt/DbjXKH5Geo7bjW71iT8AvGLUzzXyfzfGNBBlPyymq7AAjAWeFK5/slE+AvhklC4At6KEZb9x 3cJo+9x5T8s+ERinFa012uzU0vuMuu9r6W3AXd2Yu5LIRGCE618E/D6l6rpu9Hk8MEEr2iQ9p1Wr n4wShJgPgCeMbh6g02jeB9wILASe1q4ZBHzBaDeRThukHghRdskoQF+NmlH+JJ0JqB1ijCkw72np jiOfx7JPQrkdYm6QYXBMH1V3qYlKEq7fhNLvw1CTeztK55rcJlz/s8XshGPwaeBELd8sXP961Bd4 Bsqo1u2bm6Tn7NbGeCHKMI6ZLz3nsajuT6gtfjxfpxr31lXhThkG8470a9mrtPp2uq4652np94FN Rr0uMM1a+jI6fVTvAMsrmLOy6VGBEa5fB3wOpctHaK9TgVOAxmN0MRXlwPpWBbefYuTHAj8tcu39 0nNuMMq+qqXfjoUl4mSSq/HbRlv9S3/ZqBumpXcB/zPqz9fSm2UY/Nuo1wWmCUBYdiPwHa3ck2Hw YQVzVjbVWGFmkW7YmewDfga8CNwHnB6VXyZcf7X0nAfLvG8pntE3gSXSc5an1Olf+hDh+i+jVieJ UiOxwBSiMQMgLLsFOEtr+7xWB8rQjdkgw0BXK40o1RWTZrDu0dKx0X4xylMOynZZVuZcVUyPCoz0 nA7gR8L1N6FWmQIqZtRGpwoSwF7gRek5WwCE658P3A9Y0TV3C9ffUOrWOlrZdIfdXuBhlCqaqZU/ myYs0RZaNzybUV7oNFqBt7T8BJJ2iW6zDAPGFKkDGE1yBTLtF0gKTCF6/4FWtsTYVVWVqtgw0nNW lHn9LmCOcP2bgKuAvsAtqNWqFGLVF7NGes4i4fpjgNfpFNbzi7QfD/TX8vtQMa40VkvPKWh5fWfW DuhCfg5Ju8nc5k/RxpZYuTR0gWkTlj0D5YgEeJca2S4xvcXTC4D0nKvpdNWXc2hqEiqSHROrhR0k bYAzhesPTmmvG61tKAE6PXoNRRnTg6OX6VvRhfB1GQa7tbyu5v6D8qNQpH4bsDVlbLrADACu0fK/ qOXqAr1MYCLip7AcI+48I78WIIpuv6mVN5NUPWntN0nP2So9p016ThtwEKU6RpIMOyAsuw9JVWiu INO19AYZBma0fbKWXi/DoEBX9tBpu4wDLozS2+jqx6o6vVFgYt+JKKON/pTvJ6kWzKc6LTg5XEtv MeruAF5DqbZVgH6IayTJoOHf4oSw7LNICuKTeqfCsj9BUnhN+yamPXqZc3JrLfwuJpnHklKIBaa+ lIuF67eQ3KW8HtlEMabhPCmlG/3JnhX5ZHaifDeLtLqlxpmcySQfuvnCstdH6WXaZ9iPMsJ1xpOM ZaXZL6DsqfcB3UO8A7WzrDm9T2DqG7dTOHSIEgUGIc5GyhatZJ1Rv4HkmZ/xKb08o5UPRa0UkuQT vY6uQVJTFc5D7fQ6SNpUN8ow2GVcq7sB2ugq2DGHUYfLdG6SYbCPDMhcYIRlJwWjcGg/Z1/yATBE zJxXT0Pf4o0P7pWcO39W4nuVHS+JGfPq6dMXOjpgzNyt9En0MUF877fDee3x1iPlo2beTOPxnwGh qzahuhUAjwCLpOeYKkDfIT2BUl1XkxT2+2QYXJ8yen0H+JYMgz2kY9o126mh38UkITBRYGwp5e1Q usNjwL/Ql3VRX2D35mUI0UB90wyOZmc19i+wa+NB+vTrnMA9re00RO3q6iRbVtYxeOzt1NXHS3od e96dRkPT6CN9v/HUIRr738Dg0bMRDSdQVzeAjsJh+ra8SfMpf5S3XNzFoSYsewhJVbhKhoEnLDtE HV4vRGXPprQFFTdrRklk2u4opoVkyMOTYbCfjEgc0RSWPQhlQ/SruMfymCrD4IXud1N7In+ILgzT ZRj8tYfvcSLwOzoPer0DjKv1VlrHVEltqBhMafZD99mR1QfvAXT1tYfiNkhZCMvuD1yLCtbORsXg Yi7PUljAEJgoztFaYV8fN8yg4XsV95TkLJS32+QaGQZPl9tZT5O50ftRJLL1Pq8V9cjqEjHdyG8D rpdhkJmhq5MLTGX0QR2diLdnYQ/2vRq1wsRe6nUyDNq712XP0Wt/W53TO+mNoYGcXkwuMDll0eM2 TPRbnGnAvaaDSVj2bOA0GQY1j7Lm9AzVWGG+jIrwphlH3wXuzvpD51RONXZJ7aizLFcIyx4O3CXD IN527kUdJAJAWPbFqBXnVmHZV6FO3K+I6oahzgYPAX7T017UnMqoxgpTQAniONRJ/AeFZRc72+IA P47SPwEWAAjLbgL+jPJ1NAF/EZZd6o/sc6pINQSmARAyDL6OOm45mmSoX+cDVDiC6D0+azI0arcS FSkG9fcgORlTbcfdXtR5jqOdnpPGO3QK8nzU33KsoutvgXIyoBorjP7FN6OEsph3sE6rq9fS8RmQ RTIMTgP+QPJsbk5GVENgjgMQlv0QcDnwBp0nxgaQ/O+6dmCUsOxHUGdj459kbI/a3Sksew3qjE5L 1pOVUx2VtBJljxxAhf3v0v4TZRnKmI25ObruLdTZkvcAZBgcEpY9E3BRu6TrZBisznqycvJYUk6Z 5KGBnLLIBSanLHKBySmLXGByyiIXmJyy+D/P9uGVPOu6DAAAACh6VFh0U29mdHdhcmUAAHja801M LsrPTU3JTFRwyyxKLc8vyi5WsAAAYBUIJ4KDNosAAAAASUVORK5CYII= --_004_C8B8517ADA90DB40A482797D59EB83896419FE83CED01MBXS08repl_--

3 2

Unable to make Single Sign on working on Windows 7 Guest
by Felipe Herrera Martinez 11 Mar '19

11 Mar '19

On the case I'll be able to create an installer, what is the name of the Application need to be there, in order to ovirt detects that Ovirt Guest agent is installed? I have created an installer adding OvirtGuestService files and the Product Name to be shown, a part of the command line post installs.. I have tried with "ovirt-guest-agent" and "Ovirt guest agent" Names for the application installed on Windows 7 guest and even both are presented on ovirt VM Applications tab, on any case LogonVDScommand appears. There is other option to make it work now? Thanks in advance, Felipe

3 5

Re: [ovirt-users] Need VM run once api
by Chandrahasa S 11 Mar '19

11 Mar '19

This is a multipart message in MIME format. --=_alternative 00199D2865257E91_= Content-Type: text/plain; charset="US-ASCII" Can any one help on this. Thanks & Regards Chandrahasa S From: Chandrahasa S/MUM/TCS To: users(a)ovirt.org Date: 28-07-2015 15:20 Subject: Need VM run once api Hi Experts, We are integrating ovirt with our internal cloud. Here we installed cloudinit in vm and then converted vm to template. We deploy template with initial run parameter Hostname, IP Address, Gateway and DNS. but when we power ON initial, run parameter is not getting pushed to inside the vm. But its working when we power on VM using run once option on Ovirt portal. I believe we need to power ON vm using run once API, but we are not able get this API. Can some one help on this. I got reply on this query last time but unfortunately mail got deleted. Thanks & Regards Chandrahasa S =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you --=_alternative 00199D2865257E91_= Content-Type: text/html; charset="US-ASCII" Can any one help on this. Thanks & Regards Chandrahasa S From:        Chandrahasa S/MUM/TCS To:        users(a)ovirt.org Date:        28-07-2015 15:20 Subject:        Need VM run once api <hr noshade> Hi Experts, We are integrating ovirt with our internal cloud. Here we installed cloudinit in vm and then converted vm to template. We deploy template with initial run parameter Hostname, IP Address, Gateway and DNS. but when we power ON initial, run parameter is not getting pushed to inside the vm. But its working when we power on VM using run once option on Ovirt portal. I believe we need to power ON vm using run once API, but we are not able get this API. Can some one help on this. I got reply on this query last time but unfortunately mail got deleted. Thanks & Regards Chandrahasa S =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you --=_alternative 00199D2865257E91_=--

3 3

Re: [ovirt-users] Problem Windows guests start in pause
by Dafna Ron 11 Mar '19

11 Mar '19

Hi Lucas, Please send mails to the list next time. can you please do rpm -qa |grep qemu. also, can you try a different windows image? Thanks, Dafna On 07/14/2014 02:03 PM, lucas castro wrote: > On the host there I've tried to run the vm, I use a centOS 6.5 > and checked, no update for qemu, libvirt or related package. -- Dafna Ron

3 3

Feature: Hosted engine VM management
by Roy Golan 27 Feb '19

27 Feb '19

Hi all, Upcoming in 3.6 is enhancement for managing the hosted engine VM. In short, we want to: * Allow editing the Hosted engine VM, storage domain, disks, networks etc * Have a shared configuration for the hosted engine VM * Have a backup for the hosted engine VM configuration please review and comment on the wiki below: http://www.ovirt.org/Hosted_engine_VM_management Thanks, Roy

2 3

Re: [ovirt-users] Packet loss
by Doron Fediuck 26 Feb '19

26 Feb '19

----_com.android.email_640187878761650 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgS3lsZSzCoApXZSBtYXkgaGF2ZSBzZWVuIHNvbWV0aGluZyBzaW1pbGFyIGluIHRoZSBwYXN0 IGJ1dCBJIHRoaW5rIHRoZXJlIHdlcmUgdmxhbnMgaW52b2x2ZWQuwqAKSXMgaXQgdGhlIHNhbWUg Zm9yIHlvdT/CoApUb255IC8gRGFuLCBkb2VzIGl0IHJpbmcgYSBiZWxsP8Kg ----_com.android.email_640187878761650 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5IaSBLeWxlLCZuYnNwOzwv ZGl2PjxkaXY+V2UgbWF5IGhhdmUgc2VlbiBzb21ldGhpbmcgc2ltaWxhciBpbiB0aGUgcGFzdCBi dXQgSSB0aGluayB0aGVyZSB3ZXJlIHZsYW5zIGludm9sdmVkLiZuYnNwOzwvZGl2PjxkaXY+SXMg aXQgdGhlIHNhbWUgZm9yIHlvdT8mbmJzcDs8L2Rpdj48ZGl2PlRvbnkgLyBEYW4sIGRvZXMgaXQg cmluZyBhIGJlbGw/Jm5ic3A7PC9kaXY+PC9ib2R5PjwvaHRtbD4= ----_com.android.email_640187878761650--

2 1

Hosted engine Single Sign-On to VM with freeIPA not working
by Paul 21 Apr '17

21 Apr '17

This is a multipart message in MIME format. ------=_NextPart_000_0050_01D18069.35C995E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am having an issue with getting SSO to work when a standard user(UserRole) logs in to the UserPortal. The user has permission to use only this VM, so after login the console is automatically opened for that VM. Problem is that it doesn't login on the VM system with the provided credentials. Manual login at the console works without any issues. HBAC-rule check on IPA shows access is granted. Client has SELINUX in permissive mode and a disabled firewalld. On the client side I do see some PAM related errors in the logs (see details below). Extensive Google search on error 17 "Failure setting user credentials" didn't show helpful information :-( AFAIK this is did a pretty standard set-up, all working with RH-family products. I would expect others to encounter this issue as well. If someone knows any solution or has some directions to fix this it would be greatly appreciated. Thanks, Paul ------------------------------------------------------ System setup: I have 3 systems The connection between the Engine and IPA is working fine. (I can log in with IPA users etc.) Connection is made according to this document: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualizat ion/3.6/html-single/Administration_Guide/index.html#sect-Configuring_an_Exte rnal_LDAP_Provider Configuration of the client is done according to this document: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualizat ion/3.6/html/Virtual_Machine_Management_Guide/chap-Additional_Configuration. html#sect-Configuring_Single_Sign-On_for_Virtual_Machines --- Hosted Engine: [root@engine ~]# cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) [root@engine ~]# uname -a Linux engine.DOMAIN.COM 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [root@engine ~]# rpm -qa | grep ovirt ovirt-vmconsole-1.0.0-1.el7.centos.noarch ovirt-engine-restapi-3.6.2.6-1.el7.centos.noarch ovirt-setup-lib-1.0.1-1.el7.centos.noarch ovirt-engine-setup-plugin-ovirt-engine-common-3.6.3.4-1.el7.centos.noarch ovirt-engine-setup-3.6.3.4-1.el7.centos.noarch ovirt-image-uploader-3.6.0-1.el7.centos.noarch ovirt-engine-extension-aaa-jdbc-1.0.5-1.el7.noarch ovirt-host-deploy-1.4.1-1.el7.centos.noarch ovirt-engine-extension-aaa-ldap-setup-1.1.2-1.el7.centos.noarch ovirt-engine-wildfly-overlay-8.0.4-1.el7.noarch ovirt-engine-wildfly-8.2.1-1.el7.x86_64 ovirt-vmconsole-proxy-1.0.0-1.el7.centos.noarch ovirt-engine-tools-3.6.2.6-1.el7.centos.noarch ovirt-engine-dbscripts-3.6.2.6-1.el7.centos.noarch ovirt-engine-backend-3.6.2.6-1.el7.centos.noarch ovirt-engine-3.6.2.6-1.el7.centos.noarch ovirt-engine-extension-aaa-ldap-1.1.2-1.el7.centos.noarch ovirt-engine-setup-base-3.6.3.4-1.el7.centos.noarch ovirt-engine-setup-plugin-ovirt-engine-3.6.3.4-1.el7.centos.noarch ovirt-engine-setup-plugin-websocket-proxy-3.6.3.4-1.el7.centos.noarch ovirt-engine-vmconsole-proxy-helper-3.6.3.4-1.el7.centos.noarch ovirt-engine-cli-3.6.2.0-1.el7.centos.noarch ovirt-host-deploy-java-1.4.1-1.el7.centos.noarch ovirt-engine-userportal-3.6.2.6-1.el7.centos.noarch ovirt-engine-webadmin-portal-3.6.2.6-1.el7.centos.noarch ovirt-guest-agent-common-1.0.11-1.el7.noarch ovirt-release36-003-1.noarch ovirt-iso-uploader-3.6.0-1.el7.centos.noarch ovirt-engine-lib-3.6.3.4-1.el7.centos.noarch ovirt-engine-sdk-python-3.6.3.0-1.el7.centos.noarch ovirt-engine-setup-plugin-vmconsole-proxy-helper-3.6.3.4-1.el7.centos.noarch ovirt-engine-websocket-proxy-3.6.3.4-1.el7.centos.noarch ovirt-log-collector-3.6.1-1.el7.centos.noarch ovirt-engine-extensions-api-impl-3.6.3.4-1.el7.centos.noarch --- FreeIPA: [root@ipa01 ~]# cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) [root@ipa01 ~]# uname -a Linux ipa01.DOMAIN.COM 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [root@ipa01 ~]# rpm -qa | grep ipa ipa-python-4.2.0-15.el7_2.6.x86_64 ipa-client-4.2.0-15.el7_2.6.x86_64 python-libipa_hbac-1.13.0-40.el7_2.1.x86_64 python-iniparse-0.4-9.el7.noarch libipa_hbac-1.13.0-40.el7_2.1.x86_64 sssd-ipa-1.13.0-40.el7_2.1.x86_64 ipa-admintools-4.2.0-15.el7_2.6.x86_64 ipa-server-4.2.0-15.el7_2.6.x86_64 ipa-server-dns-4.2.0-15.el7_2.6.x86_64 --- Client: [root@test06 ~]# cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) [root@test06 ~]# uname -a Linux test06.DOMAIN.COM 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux [root@test06 ~]# rpm -qa | grep ipa python-libipa_hbac-1.13.0-40.el7_2.1.x86_64 python-iniparse-0.4-9.el7.noarch sssd-ipa-1.13.0-40.el7_2.1.x86_64 ipa-client-4.2.0-15.0.1.el7.centos.6.x86_64 libipa_hbac-1.13.0-40.el7_2.1.x86_64 ipa-python-4.2.0-15.0.1.el7.centos.6.x86_64 device-mapper-multipath-0.4.9-85.el7.x86_64 device-mapper-multipath-libs-0.4.9-85.el7.x86_64 [root@test06 ~]# rpm -qa | grep guest-agent qemu-guest-agent-2.3.0-4.el7.x86_64 ovirt-guest-agent-pam-module-1.0.11-1.el7.x86_64 ovirt-guest-agent-gdm-plugin-1.0.11-1.el7.noarch ovirt-guest-agent-common-1.0.11-1.el7.noarch --------------------------------------------------- Relevant logs: --- Engine: //var/log/ovirt-engine/engine 2016-03-17 15:22:10,516 INFO [org.ovirt.engine.core.bll.aaa.LoginUserCommand] (default task-22) [] Running command: LoginUserCommand internal: false. 2016-03-17 15:22:10,568 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-22) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: User test6@DOMAIN logged in. 2016-03-17 15:22:13,795 WARN [org.ovirt.engine.core.dal.job.ExecutionMessageDirector] (default task-6) [7400ae46] The message key 'VmLogon' is missing from 'bundles/ExecutionMessages' 2016-03-17 15:22:13,839 INFO [org.ovirt.engine.core.bll.VmLogonCommand] (default task-6) [7400ae46] Running command: VmLogonCommand internal: false. Entities affected : ID: 64a84b40-6050-4a96-a59d-d557a317c38c Type: VMAction group CONNECT_TO_VM with role type USER 2016-03-17 15:22:13,842 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.VmLogonVDSCommand] (default task-6) [7400ae46] START, VmLogonVDSCommand(HostName = host01, VmLogonVDSCommandParameters:{runAsync='true', hostId='225157c0-224b-4aa6-9210-db4de7c7fc30', vmId='64a84b40-6050-4a96-a59d-d557a317c38c', domain='DOMAIN-authz', password='***', userName='test6@DOMAIN'}), log id: 2015a1e0 2016-03-17 15:22:14,848 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.VmLogonVDSCommand] (default task-6) [7400ae46] FINISH, VmLogonVDSCommand, log id: 2015a1e0 2016-03-17 15:22:15,317 INFO [org.ovirt.engine.core.bll.SetVmTicketCommand] (default task-18) [10dad788] Running command: SetVmTicketCommand internal: true. Entities affected : ID: 64a84b40-6050-4a96-a59d-d557a317c38c Type: VMAction group CONNECT_TO_VM with role type USER 2016-03-17 15:22:15,322 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] (default task-18) [10dad788] START, SetVmTicketVDSCommand(HostName = host01, SetVmTicketVDSCommandParameters:{runAsync='true', hostId='225157c0-224b-4aa6-9210-db4de7c7fc30', vmId='64a84b40-6050-4a96-a59d-d557a317c38c', protocol='SPICE', ticket='rd8avqvdBnRl', validTime='120', userName='test6', userId='10b2da3e-6401-4a09-a330-c0780bc0faef', disconnectAction='LOCK_SCREEN'}), log id: 72efb73b 2016-03-17 15:22:16,340 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] (default task-18) [10dad788] FINISH, SetVmTicketVDSCommand, log id: 72efb73b 2016-03-17 15:22:16,377 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-18) [10dad788] Correlation ID: 10dad788, Call Stack: null, Custom Event ID: -1, Message: User test6@DOMAIN initiated console session for VM test06 2016-03-17 15:22:19,418 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-53) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: User test6@DOMAIN-authz is connected to VM test06. --- Client: /var/log/ovirt-guest-agent/ovirt-guest-agent.log MainThread::INFO::2016-03-17 15:20:58,145::ovirt-guest-agent::57::root::Starting oVirt guest agent CredServer::INFO::2016-03-17 15:20:58,214::CredServer::257::root::CredServer is running... Dummy-1::INFO::2016-03-17 15:20:58,216::OVirtAgentLogic::294::root::Received an external command: lock-screen... Dummy-1::INFO::2016-03-17 15:22:13,104::OVirtAgentLogic::294::root::Received an external command: login... Dummy-1::INFO::2016-03-17 15:22:13,104::CredServer::207::root::The following users are allowed to connect: [0] Dummy-1::INFO::2016-03-17 15:22:13,104::CredServer::273::root::Opening credentials channel... Dummy-1::INFO::2016-03-17 15:22:13,105::CredServer::132::root::Emitting user authenticated signal (651416). CredChannel::INFO::2016-03-17 15:22:13,188::CredServer::225::root::Incomming connection from user: 0 process: 2570 CredChannel::INFO::2016-03-17 15:22:13,188::CredServer::232::root::Sending user's credential (token: 651416) Dummy-1::INFO::2016-03-17 15:22:13,189::CredServer::277::root::Credentials channel was closed. /var/log/secure Mar 17 15:21:07 test06 gdm-launch-environment]: pam_unix(gdm-launch-environment:session): session opened for user gdm by (uid=0) Mar 17 15:21:10 test06 polkitd[749]: Registered Authentication Agent for unix-session:c1 (system bus name :1.34 [gnome-shell --mode=gdm], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) Mar 17 15:22:13 test06 gdm-ovirtcred]: pam_sss(gdm-ovirtcred:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=test6 Mar 17 15:22:13 test06 gdm-ovirtcred]: pam_sss(gdm-ovirtcred:auth): received for user test6: 17 (Failure setting user credentials) /var/log/sssd/krb5_child.log (debug-level 10) (Thu Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] [get_and_save_tgt] (0x0020): 1234: [-1765328360][Preauthentication failed] (Thu Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] [map_krb5_error] (0x0020): 1303: [-1765328360][Preauthentication failed] (Thu Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] [k5c_send_data] (0x0200): Received error code 1432158215 (Thu Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] [pack_response_packet] (0x2000): response packet size: [4] (Thu Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] [k5c_send_data] (0x4000): Response sent. (Thu Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] [main] (0x0400): krb5_child completed successfully /var/log/sssd/sssd_DOMAIN.COM.log (debug-level 10) (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [be_pam_handler] (0x0100): Got request with the following data (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): domain: DOMAIN.COM (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): user: test6 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): service: gdm-ovirtcred (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): tty: (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): ruser: (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): rhost: (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): authtok type: 1 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): priv: 1 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): cli_pid: 2570 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): logon name: not set (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [krb5_auth_queue_send] (0x1000): Wait queue of user [test6] is empty, running request [0x7fe30df03cc0] immediately. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [krb5_setup] (0x4000): No mapping for: test6 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7fe30df07120 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7fe30df16590 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Running timer event 0x7fe30df07120 "ltdb_callback" (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Destroying timer event 0x7fe30df16590 "ltdb_timeout" (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Ending timer event 0x7fe30df07120 "ltdb_callback" (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [get_server_status] (0x1000): Status of server 'ipa01.DOMAIN.COM' is 'working' (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [get_port_status] (0x1000): Port status of port 389 for server 'ipa01.DOMAIN.COM' is 'working' (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [get_server_status] (0x1000): Status of server 'ipa01.DOMAIN.COM' is 'working' (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [be_resolve_server_process] (0x0200): Found address for server ipa01.DOMAIN.COM: [10.0.1.21] TTL 1200 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://ipa01.DOMAIN.COM' (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sss_krb5_realm_has_proxy] (0x0040): profile_get_values failed. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [2575] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [child_handler_setup] (0x2000): Signal handler set up for pid [2575] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [write_pipe_handler] (0x0400): All data has been sent! (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [child_sig_handler] (0x1000): Waiting for child [2575]. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [child_sig_handler] (0x0100): child [2575] finished successfully. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [read_pipe_handler] (0x0400): EOF received, client finished (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [check_wait_queue] (0x1000): Wait queue for user [test6] is empty. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [krb5_auth_queue_done] (0x1000): krb5_auth_queue request [0x7fe30df03cc0] done. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_print_server] (0x2000): Searching 10.0.1.21 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(cn=ipaConfig)(objectClass=ipaGuiConfig))][cn=etc,dc=DOMAIN,dc=com]. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaMigrationEnabled] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSELinuxUserMapDefault] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSELinuxUserMapOrder] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 122 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_op_add] (0x2000): New operation 122 timeout 60 (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): Trace: sh[0x7fe30deef090], connected[1], ops[0x7fe30df094a0], ldap[0x7fe30def2920] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_parse_entry] (0x1000): OriginalDN: [cn=ipaConfig,cn=etc,dc=DOMAIN,dc=com]. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaMigrationEnabled] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaSELinuxUserMapDefault] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaSELinuxUserMapOrder] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): Trace: sh[0x7fe30deef090], connected[1], ops[0x7fe30df094a0], ldap[0x7fe30def2920] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_op_destructor] (0x2000): Operation 122 finished (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ipa_get_migration_flag_done] (0x0100): Password migration is not enabled. (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 17, <NULL>) [Success (Failure setting user credentials)] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [be_pam_handler_callback] (0x0100): Sending result [17][DOMAIN.COM] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [be_pam_handler_callback] (0x0100): Sent result [17][DOMAIN.COM] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): Trace: sh[0x7fe30deef090], connected[1], ops[(nil)], ldap[0x7fe30def2920] (Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! ------=_NextPart_000_0050_01D18069.35C995E0 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-microsoft-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"Microsoft Word 15 = (filtered medium)"><style></style></head><body lang=3DEN-US = link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1>Hi,<o:p></o:p><o:p> </o:p>I am having = an issue with getting SSO to work when a standard user(UserRole) logs in = to the UserPortal.<o:p></o:p>The user has = permission to use only this VM, so after login the console is = automatically opened for that VM.<o:p></o:p>Problem is that it doesn't login on the VM system with = the provided credentials. Manual login at the console works without any = issues. <o:p></o:p>HBAC-rule check on IPA shows = access is granted. Client has SELINUX in permissive mode and a disabled = firewalld. <o:p></o:p><o:p> </o:p>On the client side I do see some PAM related errors in = the logs (see details below). Extensive Google search on error 17 = "Failure setting user credentials" didn't show helpful = information :-(<o:p></o:p><o:p> </o:p>AFAIK this = is did a pretty standard set-up, all working with RH-family products. I = would expect others to encounter this issue as well. <o:p></o:p>If someone knows any solution or has some directions = to fix this it would be greatly appreciated.<o:p></o:p><o:p> </o:p>Thanks,<o:p></o:p><o:p> </o:p>Paul<o:p></o:p><o:p> </o:p>------------------------------------------------------<= o:p></o:p>System setup: I have 3 systems = <o:p></o:p><o:p> </o:p>The connection between the Engine and IPA is working = fine. (I can log in with IPA users etc.) Connection is made according to = this document: = https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtuali= zation/3.6/html-single/Administration_Guide/index.html#sect-Configuring_a= n_External_LDAP_Provider<o:p></o:p><o:p> </o:p>Configuration of the client is done according to this = document: = https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtuali= zation/3.6/html/Virtual_Machine_Management_Guide/chap-Additional_Configur= ation.html#sect-Configuring_Single_Sign-On_for_Virtual_Machines<o:p></o:p= ><o:p> </o:p>--- = Hosted Engine:<o:p></o:p>[root@engine ~]# cat = /etc/redhat-release<o:p></o:p>CentOS Linux = release 7.2.1511 (Core)<o:p></o:p>[root@engine = ~]# uname -a<o:p></o:p>Linux engine.DOMAIN.COM = 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 = x86_64 x86_64 GNU/Linux<o:p></o:p>[root@engine = ~]# rpm -qa | grep ovirt<o:p></o:p>ovirt-vmconsole-1.0.0-1.el7.centos.noarch<o:p></o:p></p= >ovirt-engine-restapi-3.6.2.6-1.el7.centos.noarch<o:p></= o:p>ovirt-setup-lib-1.0.1-1.el7.centos.noarch<o:p></o:p></p= >ovirt-engine-setup-plugin-ovirt-engine-common-3.6.3.4-1= .el7.centos.noarch<o:p></o:p>ovirt-engine-setup-3.6.3.4-1.el7.centos.noarch<o:p></o:= p>ovirt-image-uploader-3.6.0-1.el7.centos.noarch<o:p></o:= p>ovirt-engine-extension-aaa-jdbc-1.0.5-1.el7.noarch<o:p>= </o:p>ovirt-host-deploy-1.4.1-1.el7.centos.noarch<o:p></o:p><= /p>ovirt-engine-extension-aaa-ldap-setup-1.1.2-1.el7.cento= s.noarch<o:p></o:p>ovirt-engine-wildfly-overlay-8.0.4-1.el7.noarch<o:p></o= :p>ovirt-engine-wildfly-8.2.1-1.el7.x86_64<o:p></o:p><= p = class=3DMsoNormal>ovirt-vmconsole-proxy-1.0.0-1.el7.centos.noarch<o:p></o= :p>ovirt-engine-tools-3.6.2.6-1.el7.centos.noarch<o:p></o:= p>ovirt-engine-dbscripts-3.6.2.6-1.el7.centos.noarch<o:p>= </o:p>ovirt-engine-backend-3.6.2.6-1.el7.centos.noarch<o:p></= o:p>ovirt-engine-3.6.2.6-1.el7.centos.noarch<o:p></o:p>= ovirt-engine-extension-aaa-ldap-1.1.2-1.el7.centos.noar= ch<o:p></o:p>ovirt-engine-setup-base-3.6.3.4-1.el7.centos.noarch<o:p= ></o:p>ovirt-engine-setup-plugin-ovirt-engine-3.6.3.4-1.el7.ce= ntos.noarch<o:p></o:p>ovirt-engine-setup-plugin-websocket-proxy-3.6.3.4-1.el7= .centos.noarch<o:p></o:p>ovirt-engine-vmconsole-proxy-helper-3.6.3.4-1.el7.cento= s.noarch<o:p></o:p>ovirt-engine-cli-3.6.2.0-1.el7.centos.noarch<o:p></o:p>= ovirt-host-deploy-java-1.4.1-1.el7.centos.noarch<o:p></= o:p>ovirt-engine-userportal-3.6.2.6-1.el7.centos.noarch<o:p= ></o:p>ovirt-engine-webadmin-portal-3.6.2.6-1.el7.centos.noarc= h<o:p></o:p>ovirt-guest-agent-common-1.0.11-1.el7.noarch<o:p></o:p>= ovirt-release36-003-1.noarch<o:p></o:p>ovirt-iso-uploader-3.6.0-1.el7.centos.noarch<o:p></o:p>= ovirt-engine-lib-3.6.3.4-1.el7.centos.noarch<o:p></o:p>= ovirt-engine-sdk-python-3.6.3.0-1.el7.centos.noarch<o:p= ></o:p>ovirt-engine-setup-plugin-vmconsole-proxy-helper-3.6.3.= 4-1.el7.centos.noarch<o:p></o:p>ovirt-engine-websocket-proxy-3.6.3.4-1.el7.centos.noarc= h<o:p></o:p>ovirt-log-collector-3.6.1-1.el7.centos.noarch<o:p></o:p= >ovirt-engine-extensions-api-impl-3.6.3.4-1.el7.centos.n= oarch<o:p></o:p><o:p> </o:p>--- FreeIPA:<o:p></o:p>[root@ipa01 ~]# cat = /etc/redhat-release<o:p></o:p>CentOS Linux = release 7.2.1511 (Core) <o:p></o:p>[root@ipa01 = ~]#  uname -a<o:p></o:p>Linux = ipa01.DOMAIN.COM 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 = UTC 2016 x86_64 x86_64 x86_64 GNU/Linux<o:p></o:p>[root@ipa01 ~]# rpm -qa | grep ipa<o:p></o:p>ipa-python-4.2.0-15.el7_2.6.x86_64<o:p></o:p>ipa-client-4.2.0-15.el7_2.6.x86_64<o:p></o:p>python-libipa_hbac-1.13.0-40.el7_2.1.x86_64<o:p></o:p><= /p>python-iniparse-0.4-9.el7.noarch<o:p></o:p>libipa_hbac-1.13.0-40.el7_2.1.x86_64<o:p></o:p>sssd-ipa-1.13.0-40.el7_2.1.x86_64<o:p></o:p>ipa-admintools-4.2.0-15.el7_2.6.x86_64<o:p></o:p><p= class=3DMsoNormal>ipa-server-4.2.0-15.el7_2.6.x86_64<o:p></o:p>ipa-server-dns-4.2.0-15.el7_2.6.x86_64<o:p></o:p><p= class=3DMsoNormal><o:p> </o:p>--- = Client:<o:p></o:p>[root@test06 ~]# cat = /etc/redhat-release<o:p></o:p>CentOS Linux = release 7.2.1511 (Core) <o:p></o:p>[root@test06 = ~]# uname -a<o:p></o:p>Linux test06.DOMAIN.COM = 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 = x86_64 x86_64 GNU/Linux<o:p></o:p>[root@test06 = ~]# rpm -qa | grep ipa<o:p></o:p>python-libipa_hbac-1.13.0-40.el7_2.1.x86_64<o:p></o:p><= /p>python-iniparse-0.4-9.el7.noarch<o:p></o:p>sssd-ipa-1.13.0-40.el7_2.1.x86_64<o:p></o:p>ipa-client-4.2.0-15.0.1.el7.centos.6.x86_64<o:p></o:p><= /p>libipa_hbac-1.13.0-40.el7_2.1.x86_64<o:p></o:p>ipa-python-4.2.0-15.0.1.el7.centos.6.x86_64<o:p></o:p><= /p>device-mapper-multipath-0.4.9-85.el7.x86_64<o:p></o:p><= /p>device-mapper-multipath-libs-0.4.9-85.el7.x86_64<o:p></= o:p>[root@test06 ~]# rpm -qa | grep = guest-agent<o:p></o:p>qemu-guest-agent-2.3.0-4.el7.x86_64<o:p></o:p>ovirt-guest-agent-pam-module-1.0.11-1.el7.x86_64<o:p></= o:p>ovirt-guest-agent-gdm-plugin-1.0.11-1.el7.noarch<o:p></= o:p>ovirt-guest-agent-common-1.0.11-1.el7.noarch<o:p></o:p>= <o:p> </o:p>---------------------------------------------------<o:p= ></o:p>Relevant logs:<o:p></o:p>--- Engine:<o:p></o:p>//var/log/ovirt-engine/engine<o:p></o:p>2016-03-17 15:22:10,516 INFO  = [org.ovirt.engine.core.bll.aaa.LoginUserCommand] (default task-22) [] = Running command: LoginUserCommand internal: false.<o:p></o:p>2016-03-17 15:22:10,568 INFO  = [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] = (default task-22) [] Correlation ID: null, Call Stack: null, Custom = Event ID: -1, Message: User test6@DOMAIN logged in.<o:p></o:p>2016-03-17 15:22:13,795 WARN  = [org.ovirt.engine.core.dal.job.ExecutionMessageDirector] (default = task-6) [7400ae46] The message key 'VmLogon' is missing from = 'bundles/ExecutionMessages'<o:p></o:p>2016-03-17 15:22:13,839 INFO  = [org.ovirt.engine.core.bll.VmLogonCommand] (default task-6) [7400ae46] = Running command: VmLogonCommand internal: false. Entities affected = :  ID: 64a84b40-6050-4a96-a59d-d557a317c38c Type: VMAction group = CONNECT_TO_VM with role type USER<o:p></o:p>2016-03-17 15:22:13,842 INFO  = [org.ovirt.engine.core.vdsbroker.vdsbroker.VmLogonVDSCommand] (default = task-6) [7400ae46] START, VmLogonVDSCommand(HostName =3D host01, = VmLogonVDSCommandParameters:{runAsync=3D'true', = hostId=3D'225157c0-224b-4aa6-9210-db4de7c7fc30', = vmId=3D'64a84b40-6050-4a96-a59d-d557a317c38c', domain=3D'DOMAIN-authz', = password=3D'***', userName=3D'test6@DOMAIN'}), log id: = 2015a1e0<o:p></o:p>2016-03-17 15:22:14,848 = INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.VmLogonVDSCommand] = (default task-6) [7400ae46] FINISH, VmLogonVDSCommand, log id: = 2015a1e0<o:p></o:p>2016-03-17 15:22:15,317 = INFO  [org.ovirt.engine.core.bll.SetVmTicketCommand] (default = task-18) [10dad788] Running command: SetVmTicketCommand internal: true. = Entities affected :  ID: 64a84b40-6050-4a96-a59d-d557a317c38c Type: = VMAction group CONNECT_TO_VM with role type USER<o:p></o:p>2016-03-17 15:22:15,322 INFO  = [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] = (default task-18) [10dad788] START, SetVmTicketVDSCommand(HostName =3D = host01, SetVmTicketVDSCommandParameters:{runAsync=3D'true', = hostId=3D'225157c0-224b-4aa6-9210-db4de7c7fc30', = vmId=3D'64a84b40-6050-4a96-a59d-d557a317c38c', protocol=3D'SPICE', = ticket=3D'rd8avqvdBnRl', validTime=3D'120', userName=3D'test6', = userId=3D'10b2da3e-6401-4a09-a330-c0780bc0faef', = disconnectAction=3D'LOCK_SCREEN'}), log id: 72efb73b<o:p></o:p>2016-03-17 15:22:16,340 INFO  = [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] = (default task-18) [10dad788] FINISH, SetVmTicketVDSCommand, log id: = 72efb73b<o:p></o:p>2016-03-17 15:22:16,377 = INFO  = [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] = (default task-18) [10dad788] Correlation ID: 10dad788, Call Stack: null, = Custom Event ID: -1, Message: User test6@DOMAIN initiated console = session for VM test06<o:p></o:p>2016-03-17 = 15:22:19,418 INFO  = [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] = (DefaultQuartzScheduler_Worker-53) [] Correlation ID: null, Call Stack: = null, Custom Event ID: -1, Message: User test6@DOMAIN-authz is connected = to VM test06.<o:p></o:p><o:p> </o:p>--- Client:<o:p></o:p>/var/log/ovirt-guest-agent/ovirt-guest-agent.log<o:p></= o:p>MainThread::INFO::2016-03-17 = 15:20:58,145::ovirt-guest-agent::57::root::Starting oVirt guest = agent<o:p></o:p>CredServer::INFO::2016-03-17 = 15:20:58,214::CredServer::257::root::CredServer is = running...<o:p></o:p>Dummy-1::INFO::2016-03-17 = 15:20:58,216::OVirtAgentLogic::294::root::Received an external command: = lock-screen...<o:p></o:p>Dummy-1::INFO::2016-03-17 = 15:22:13,104::OVirtAgentLogic::294::root::Received an external command: = login...<o:p></o:p>Dummy-1::INFO::2016-03-17 = 15:22:13,104::CredServer::207::root::The following users are allowed to = connect: [0]<o:p></o:p>Dummy-1::INFO::2016-03-17 = 15:22:13,104::CredServer::273::root::Opening credentials = channel...<o:p></o:p>Dummy-1::INFO::2016-03-17 = 15:22:13,105::CredServer::132::root::Emitting user authenticated signal = (651416).<o:p></o:p>CredChannel::INFO::2016-03-17 = 15:22:13,188::CredServer::225::root::Incomming connection from user: 0 = process: 2570<o:p></o:p>CredChannel::INFO::2016-03-17 = 15:22:13,188::CredServer::232::root::Sending user's credential (token: = 651416)<o:p></o:p>Dummy-1::INFO::2016-03-17 = 15:22:13,189::CredServer::277::root::Credentials channel was = closed.<o:p></o:p><o:p> </o:p>/var/log/secure<o:p></o:p>Mar = 17 15:21:07 test06 gdm-launch-environment]: = pam_unix(gdm-launch-environment:session): session opened for user gdm by = (uid=3D0)<o:p></o:p>Mar 17 15:21:10 test06 = polkitd[749]: Registered Authentication Agent for unix-session:c1 = (system bus name :1.34 [gnome-shell --mode=3Dgdm], object path = /org/freedesktop/PolicyKit1/AuthenticationAgent, locale = en_US.UTF-8)<o:p></o:p>Mar 17 15:22:13 test06 = gdm-ovirtcred]: pam_sss(gdm-ovirtcred:auth): authentication failure; = logname=3D uid=3D0 euid=3D0 tty=3D ruser=3D rhost=3D = user=3Dtest6<o:p></o:p>Mar 17 15:22:13 test06 gdm-ovirtcred]: = pam_sss(gdm-ovirtcred:auth): received for user test6: 17 (Failure = setting user credentials)<o:p></o:p><o:p> </o:p>/var/log/sssd/krb5_child.log (debug-level = 10)<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [[sssd[krb5_child[2575]]]] [get_and_save_tgt] (0x0020): 1234: = [-1765328360][Preauthentication failed]<o:p></o:p>(Thu Mar 17 15:22:13 = 2016) [[sssd[krb5_child[2575]]]] [map_krb5_error] (0x0020): 1303: = [-1765328360][Preauthentication failed]<o:p></o:p>(Thu Mar 17 15:22:13 = 2016) [[sssd[krb5_child[2575]]]] [k5c_send_data] (0x0200): Received = error code 1432158215<o:p></o:p>(Thu = Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] [pack_response_packet] = (0x2000): response packet size: [4]<o:p></o:p>(Thu Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] = [k5c_send_data] (0x4000): Response sent.<o:p></o:p>(Thu Mar 17 15:22:13 2016) [[sssd[krb5_child[2575]]]] = [main] (0x0400): krb5_child completed successfully<o:p></o:p><o:p> </o:p>/var/log/sssd/sssd_DOMAIN.COM.log (debug-level = 10)<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [be_pam_handler] (0x0100): Got request with the = following data<o:p></o:p>(Thu Mar 17 15:22:13 = 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): command: = PAM_AUTHENTICATE<o:p></o:p>(Thu Mar 17 15:22:13 = 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): domain: = DOMAIN.COM<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): user: = test6<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): service: = gdm-ovirtcred<o:p></o:p>(Thu Mar 17 15:22:13 = 2016) [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): = tty:<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): = ruser:<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): = rhost:<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): authtok type: = 1<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): newauthtok type: = 0<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): priv: = 1<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): cli_pid: = 2570<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [pam_print_data] (0x0100): logon name: not = set<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [krb5_auth_queue_send] (0x1000): Wait queue of = user [test6] is empty, running request [0x7fe30df03cc0] = immediately.<o:p></o:p>(Thu Mar 17 15:22:13 = 2016) [sssd[be[DOMAIN.COM]]] [krb5_setup] (0x4000): No mapping for: = test6<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Added timed event = "ltdb_callback": 0x7fe30df07120<o:p></o:p><o:p> </o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Added timed event = "ltdb_timeout": 0x7fe30df16590<o:p></o:p><o:p> </o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Running timer = event 0x7fe30df07120 "ltdb_callback"<o:p></o:p><o:p> </o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Destroying timer = event 0x7fe30df16590 "ltdb_timeout"<o:p></o:p><o:p> </o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ldb] (0x4000): Ending timer event = 0x7fe30df07120 "ltdb_callback"<o:p></o:p><o:p> </o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [fo_resolve_service_send] = (0x0100): Trying to resolve service 'IPA'<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [get_server_status] (0x1000): Status of server 'ipa01.DOMAIN.COM' is = 'working'<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [get_port_status] (0x1000): Port status of port = 389 for server 'ipa01.DOMAIN.COM' is 'working'<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 = seconds<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [resolve_srv_send] (0x0200): The status of SRV = lookup is resolved<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [get_server_status] (0x1000): = Status of server 'ipa01.DOMAIN.COM' is 'working'<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [be_resolve_server_process] (0x1000): Saving the first resolved = server<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [be_resolve_server_process] (0x0200): Found = address for server ipa01.DOMAIN.COM: [10.0.1.21] TTL = 1200<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [ipa_resolve_callback] (0x0400): Constructed uri = 'ldap://ipa01.DOMAIN.COM'<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sss_krb5_realm_has_proxy] = (0x0040): profile_get_values failed.<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [child_handler_setup] (0x2000): Setting up signal handler up for pid = [2575]<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [child_handler_setup] (0x2000): Signal handler = set up for pid [2575]<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [write_pipe_handler] (0x0400): All = data has been sent!<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [child_sig_handler] (0x1000): = Waiting for child [2575].<o:p></o:p><o:p> </o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [child_sig_handler] (0x0100): = child [2575] finished successfully.<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [read_pipe_handler] (0x0400): EOF received, client = finished<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [check_wait_queue] (0x1000): Wait queue for user = [test6] is empty.<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [krb5_auth_queue_done] (0x1000): = krb5_auth_queue request [0x7fe30df03cc0] done.<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [sdap_id_op_connect_step] (0x4000): reusing cached = connection<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [sdap_print_server] (0x2000): Searching = 10.0.1.21<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [sdap_get_generic_ext_step] (0x0400): calling = ldap_search_ext with = [(&(cn=3DipaConfig)(objectClass=3DipaGuiConfig))][cn=3Detc,dc=3DDOMAI= N,dc=3Dcom].<o:p></o:p>(Thu Mar 17 15:22:13 = 2016) [sssd[be[DOMAIN.COM]]] [sdap_get_generic_ext_step] (0x1000): = Requesting attrs: [ipaMigrationEnabled]<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [sdap_get_generic_ext_step] (0x1000): Requesting attrs: = [ipaSELinuxUserMapDefault]<o:p></o:p>(Thu Mar = 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_get_generic_ext_step] = (0x1000): Requesting attrs: [ipaSELinuxUserMapOrder]<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid =3D = 122<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [sdap_op_add] (0x2000): New operation 122 timeout = 60<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): Trace: = sh[0x7fe30deef090], connected[1], ops[0x7fe30df094a0], = ldap[0x7fe30def2920]<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_message] (0x4000): = Message type: [LDAP_RES_SEARCH_ENTRY]<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [sdap_parse_entry] (0x1000): OriginalDN: = [cn=3DipaConfig,cn=3Detc,dc=3DDOMAIN,dc=3Dcom].<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [sdap_parse_range] (0x2000): No sub-attributes for = [ipaMigrationEnabled]<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_parse_range] (0x2000): No = sub-attributes for [ipaSELinuxUserMapDefault]<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [sdap_parse_range] (0x2000): No sub-attributes for = [ipaSELinuxUserMapOrder]<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): = Trace: sh[0x7fe30deef090], connected[1], ops[0x7fe30df094a0], = ldap[0x7fe30def2920]<o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [sdap_process_message] (0x4000): = Message type: [LDAP_RES_SEARCH_RESULT]<o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no = errmsg set<o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [sdap_op_destructor] (0x2000): Operation 122 = finished <o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [sdap_id_op_destroy] (0x4000): releasing = operation connection <o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [ipa_get_migration_flag_done] = (0x0100): Password migration is not enabled. <o:p></o:p>(Thu Mar 17 15:22:13 = 2016) [sssd[be[DOMAIN.COM]]] [be_pam_handler_callback] (0x0100): Backend = returned: (0, 17, <NULL>) [Success (Failure setting user = credentials)] <o:p></o:p>(Thu Mar 17 = 15:22:13 2016) [sssd[be[DOMAIN.COM]]] [be_pam_handler_callback] = (0x0100): Sending result [17][DOMAIN.COM] <o:p></o:p>(Thu Mar 17 15:22:13 2016) [sssd[be[DOMAIN.COM]]] = [be_pam_handler_callback] (0x0100): Sent result [17][DOMAIN.COM] = <o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): Trace: = sh[0x7fe30deef090], connected[1], ops[(nil)], ldap[0x7fe30def2920] = <o:p></o:p>(Thu Mar 17 15:22:13 2016) = [sssd[be[DOMAIN.COM]]] [sdap_process_result] (0x2000): Trace: = ldap_result found nothing!<o:p></o:p><o:p> </o:p> = <o:p></o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p></div></body></html> ------=_NextPart_000_0050_01D18069.35C995E0--

2 5

Changing gateway ping address
by Matteo 21 Mar '17

21 Mar '17

Hi all, I need to change the gateway ping address, the one used by hosted engine setup. Is ok to edit /etc/ovirt-hosted-engine/hosted-engine.conf on each node, update the gateway param with the new ip address and restart the agent&broker on each node? With a blind test seems ok, but need to understand if is the right procedure. Thanks, Matteo

4 7

[ovirt-shell] update hostnic/nic ???
by Bloemen, Jurriën 02 Feb '17

02 Feb '17

--_000_5697777B2050209dmcamcnetworkscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkZpcnN0IEkgY3JlYXRlZCBhIGJvbmRpbmcgaW50ZXJmYWNlOg0KDQojIGFkZCBuaWMg LS1wYXJlbnQtaG9zdC1uYW1lIHNlcnZlcjAxIC0tbmFtZSBib25kMCAtLW5ldHdvcmstbmFtZSBW TEFONjAyIC0tYm9uZGluZy1zbGF2ZXMtaG9zdF9uaWMgaG9zdF9uaWMubmFtZT1lbm8xIC0tYm9u ZGluZy1zbGF2ZXMtaG9zdF9uaWMgaG9zdF9uaWMubmFtZT1lbm8yDQoNClRoaXMgd29ya3MgZ3Jl YXQgYnV0IG5vIElQIGlzIHNldCBvbiBWTEFONjAyLg0KDQpUaGVuIEknbSB0cnlpbmcgdG8gYWRk IGFuIGlwIGFkZHJlc3MgdG8gYSBuZXR3b3JrIHdpdGggdGhlIGZvbGxvd2luZyBjb21tYW5kOg0K DQojIHVwZGF0ZSBob3N0bmljIC0tcGFyZW50LWhvc3QtbmFtZSBzZXJ2ZXIwMSAtLW5ldHdvcmst bmFtZSBWTEFONjAyIC0tYm9vdF9wcm90b2NvbCBzdGF0aWMgLS1pcC1hZGRyZXNzIDEwLjEwLjEw LjEwIC0taXAtbmV0bWFzayAyNTUuMjU1LjI1NS4wDQoNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09IEVSUk9SID09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgd3JvbmcgbnVtYmVyIG9mIGFyZ3VtZW50cywgdHJ5ICdoZWxwIHVwZGF0ZScgZm9yIGhl bHAuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KDQpMb29raW5nIGF0IHRoaXMgZG9jdW1lbnQgaHR0cHM6Ly9hY2Nlc3MucmVkaGF0LmNvbS9k b2N1bWVudGF0aW9uL2VuLVVTL1JlZF9IYXRfRW50ZXJwcmlzZV9WaXJ0dWFsaXphdGlvbi8zLjYt QmV0YS9odG1sL1JIRVZNX1NoZWxsX0d1aWRlL25pYy5odG1sIEkgbmVlZCB0byB1c2UgIm5pYyIg aW5zdGVhZCBvZiAiaG9zdG5pYyIgYnV0IHRoZW4gSSBkb24ndCBoYXZlIHRoZSBvcHRpb25zIHRv IHNheSB0aGlzIGlzIGEgLS1wYXJlbnQtaG9zdC1uYW1lLiBPbmx5IFZNIHJlbGF0ZWQgY29tbWFu ZCBvcHRpb25zLg0KDQpTbyBJIHRoaW5rIHRoZSBkb2N1bWVudGF0aW9uIGlzIGJlaGluZC4NCg0K Q2FuIHNvbWVib2R5IGhlbHAgbWUgd2l0aCB3aGF0IHRoZSBjb21tYW5kIGlzIHRvIGFkZCBhIElQ IHRvIGEgVkxBTi9OZXR3b3JrIGZvciBhIGhvc3Q/DQoNCg0KLS0NCktpbmQgcmVnYXJkcywNCg0K SnVycmnDq24gQmxvZW1lbg0KDQpUaGlzIG1lc3NhZ2UgKGluY2x1ZGluZyBhbnkgYXR0YWNobWVu dHMpIG1heSBjb250YWluIGluZm9ybWF0aW9uIHRoYXQgaXMgcHJpdmlsZWdlZCBvciBjb25maWRl bnRpYWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgZW1haWwgaW1tZWRpYXRlbHkgZnJvbSB5b3Vy IHN5c3RlbXMgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiBpdC4gWW91IG1heSBub3QsIGRpcmVj dGx5IG9yIGluZGlyZWN0bHksIHVzZSwgZGlzY2xvc2UsIGRpc3RyaWJ1dGUsIHByaW50IG9yIGNv cHkgdGhpcyBlbWFpbCBvciBhbnkgcGFydCBvZiBpdCBpZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50DQo= --_000_5697777B2050209dmcamcnetworkscom_ Content-Type: text/html; charset="utf-8" Content-ID: <DED479EC8EDE1E4F9CD5EE636812330C(a)chellomedia.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHRleHQ9IiMwMDAwMDAi IGJnY29sb3I9IiNGRkZGRkYiPg0KPHR0PkhpLDxicj4NCjxicj4NCkZpcnN0IEkgY3JlYXRlZCBh IGJvbmRpbmcgaW50ZXJmYWNlOjxicj4NCjxicj4NCiMgYWRkIG5pYyAtLXBhcmVudC1ob3N0LW5h bWUgc2VydmVyMDEgLS1uYW1lIGJvbmQwIC0tbmV0d29yay1uYW1lIFZMQU42MDIgLS1ib25kaW5n LXNsYXZlcy1ob3N0X25pYyBob3N0X25pYy5uYW1lPWVubzEgLS1ib25kaW5nLXNsYXZlcy1ob3N0 X25pYyBob3N0X25pYy5uYW1lPWVubzI8YnI+DQo8YnI+DQpUaGlzIHdvcmtzIGdyZWF0IGJ1dCBu byBJUCBpcyBzZXQgb24gVkxBTjYwMi48YnI+DQo8YnI+DQpUaGVuIEknbSB0cnlpbmcgdG8gYWRk IGFuIGlwIGFkZHJlc3MgdG8gYSBuZXR3b3JrIHdpdGggdGhlIGZvbGxvd2luZyBjb21tYW5kOjxi cj4NCjxicj4NCiMgdXBkYXRlIGhvc3RuaWMgLS1wYXJlbnQtaG9zdC1uYW1lIHNlcnZlcjAxIC0t bmV0d29yay1uYW1lIFZMQU42MDIgLS1ib290X3Byb3RvY29sIHN0YXRpYyAtLWlwLWFkZHJlc3Mg MTAuMTAuMTAuMTAgLS1pcC1uZXRtYXNrIDI1NS4yNTUuMjU1LjA8YnI+DQo8YnI+DQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSBFUlJPUiA9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg d3JvbmcgbnVtYmVyIG9mIGFyZ3VtZW50cywgdHJ5ICdoZWxwIHVwZGF0ZScgZm9yIGhlbHAuPGJy Pg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08 YnI+DQo8YnI+DQpMb29raW5nIGF0IHRoaXMgZG9jdW1lbnQgPGEgY2xhc3M9Im1vei10eHQtbGlu ay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly9hY2Nlc3MucmVkaGF0LmNvbS9kb2N1bWVudGF0aW9u L2VuLVVTL1JlZF9IYXRfRW50ZXJwcmlzZV9WaXJ0dWFsaXphdGlvbi8zLjYtQmV0YS9odG1sL1JI RVZNX1NoZWxsX0d1aWRlL25pYy5odG1sIj4NCmh0dHBzOi8vYWNjZXNzLnJlZGhhdC5jb20vZG9j dW1lbnRhdGlvbi9lbi1VUy9SZWRfSGF0X0VudGVycHJpc2VfVmlydHVhbGl6YXRpb24vMy42LUJl dGEvaHRtbC9SSEVWTV9TaGVsbF9HdWlkZS9uaWMuaHRtbDwvYT4gSSBuZWVkIHRvIHVzZSAmcXVv dDtuaWMmcXVvdDsgaW5zdGVhZCBvZiAmcXVvdDtob3N0bmljJnF1b3Q7IGJ1dCB0aGVuIEkgZG9u J3QgaGF2ZSB0aGUgb3B0aW9ucyB0byBzYXkgdGhpcyBpcyBhIC0tcGFyZW50LWhvc3QtbmFtZS4g T25seSBWTSByZWxhdGVkIGNvbW1hbmQNCiBvcHRpb25zLjxicj4NCjxicj4NClNvIEkgdGhpbmsg dGhlIGRvY3VtZW50YXRpb24gaXMgYmVoaW5kLiA8YnI+DQo8YnI+DQpDYW4gc29tZWJvZHkgaGVs cCBtZSB3aXRoIHdoYXQgdGhlIGNvbW1hbmQgaXMgdG8gYWRkIGEgSVAgdG8gYSBWTEFOL05ldHdv cmsgZm9yIGEgaG9zdD88YnI+DQo8YnI+DQo8YnI+DQo8L3R0Pg0KPGRpdiBjbGFzcz0ibW96LXNp Z25hdHVyZSI+LS0gPGJyPg0KPHRpdGxlPjwvdGl0bGU+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC1zaXplOiAxNHB4 OyBmb250LWZhbWlseToNCiAgICAgICAgICBDYWxpYnJpLCBzYW5zLXNlcmlmOyBtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7Ij4NCjxiPjxmb250IGZhY2U9IkFyaWFsLHNhbnMtc2VyaWYiIGNvbG9y PSIjMmM4Y2I2Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyI+Szwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOg0KICAgICAgICAgICAgICAgIDEzcHg7Ij5pPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwcHQ7Ij5uZCByZWdhcmRzLDwvc3Bhbj48L2ZvbnQ+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 Og0KICAgICAgICAgIENhbGlicmksIHNhbnMtc2VyaWY7IG1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFs LCBzYW5zLXNlcmlmOw0KICAgICAgICAgICAgICBjb2xvcjogcmdiKDQ0LCAxNDAsIDE4Mik7Ij4m bmJzcDs8L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJmb250LXNp emU6IDE0cHg7IGZvbnQtZmFtaWx5Og0KICAgICAgICAgIENhbGlicmksIHNhbnMtc2VyaWY7IG1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsiPg0KPGIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7DQogICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiBB cmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYig0NCwgMTQwLCAxODIpOyI+SnVycmnDq24gQmxv ZW1lbjwvc3Bhbj48L2I+PGIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsNCiAgICAgICAg ICAgICAgY29sb3I6IGdyYXk7Ij48YnI+DQo8L3NwYW4+PC9iPjxmb250IGZhY2U9IkFyaWFsLHNh bnMtc2VyaWYiIGNvbG9yPSIjODA4MDgwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyI+ PC9zcGFuPjwvZm9udD48L3A+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KVGhpcyBtZXNzYWdlIChp bmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlz IHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGVtYWls IGltbWVkaWF0ZWx5IGZyb20geW91ciBzeXN0ZW1zIGFuZCBkZXN0cm95IGFsbCBjb3BpZXMgb2Yg aXQuIFlvdSBtYXkgbm90LA0KIGRpcmVjdGx5IG9yIGluZGlyZWN0bHksIHVzZSwgZGlzY2xvc2Us IGRpc3RyaWJ1dGUsIHByaW50IG9yIGNvcHkgdGhpcyBlbWFpbCBvciBhbnkgcGFydCBvZiBpdCBp ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5697777B2050209dmcamcnetworkscom_--

3 10

ovirt-shell show vm doesn't show all vm properties
by Nathanaël Blanchet 11 Oct '16

11 Oct '16

Hi all, I'd like to find any vms with some defined properties like (console-enabled or serial_number-policy for example) with ovirt-shell -E "show vm name", but I can't find all information that I can get with edit vm popupin the UI. I belevied these kind of properties were unvailable because the flag was by default to false, but after updating the flag to true, it is still not visible. Does it exist an extended way to get those feature with ovirt-shell? Thank you. -- Nathanaël Blanchet Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet(a)abes.fr

2 5

vioscsi.sys BSOD with Win 7
by Cam Mac 29 Sep '16

29 Sep '16

Hi, I'm running oVirt 3.6.3.4-1.el7.centos and when I install a Win 7 guest VM, using VirtIO disk, networking etc, it goes through the install process ok, but blue screens upon boot with a vioscsi.sys error (attached). I have tried the official version ovirt-guest-tools-iso 3.6.0 0.2_master.fc22, as well as some earlier and later versions. I am using a PXE boot method with a Windows deployment server, which has the drivers from the oVirt tools ISO installed (indeed, it picks up the drive and networking and I can see it installing the drivers). I have tried with the generic IDE and rtl8139 config on the guest, and it also fails with the same vioscsi.sys error after rebooting upon finishing installation even though I'm using IDE as the disk driver. I have uploaded a win 7 x64 ISO and tried installing that, and it loads the VirtIO viostor driver (using the method at: https://www.ovirt.org/documentation/how-to/virtual-machines/create-a-window…) and even manages to partition the disks, but fails to install on the disk (screenshot attached). I've tried temporarily removing the vioscsi files from the install server as a last resort, but as expected it fails to install properly, though I thought it used the viostor driver instead. Thanks for any help. Regards, Cam

4 13

Hosted engine on gluster problem
by Bond, Darryl 29 Aug '16

29 Aug '16

There seems to be a pretty severe bug with using hosted engine on gluster. If the host that was used as the initial hosted-engine --deploy host goes away, the engine VM wil crash and cannot be restarted until the host comes back. This is regardless of which host the engine was currently running. The issue seems to be buried in the bowels of VDSM and is not an issue with gluster itself. The gluster filesystem is still accessable from the host that was running the engine. The issue has been submitted to bugzilla but the fix is some way off (4.1). Can my hosted engine be converted to use NFS (using the gluster NFS server on the same filesystem) without rebuilding my hosted engine (ie change domainType=glusterfs to domainType=nfs)? What effect would that have on the hosted-engine storage domain inside oVirt, ie would the same filesystem be mounted twice or would it just break. Will this actually fix the problem, does it have the same issue when the hosted engine is on NFS? Darryl ________________________________ The contents of this electronic message and any attachments are intended only for the addressee and may contain legally privileged, personal, sensitive or confidential information. If you are not the intended addressee, and have received this email, any transmission, distribution, downloading, printing or photocopying of the contents of this message or attachments is strictly prohibited. Any legal privilege or confidentiality attached to this message and attachments is not waived, lost or destroyed by reason of delivery to any person other than intended addressee. If you have received this message and are not the intended addressee you should notify the sender by return email and destroy all copies of the message and any attachments. Unless expressly attributed, the views expressed in this email do not necessarily represent the views of the company.

8 20

Dedicated NICs for gluster network
by Nicolas Ecarnot 22 Aug '16

22 Aug '16

Hello, [Here : oVirt 3.5.3, 3 x CentOS 7.0 hosts with replica-3 gluster SD on the hosts]. On the switchs, I have created a dedicated VLAN to isolate the glusterFS traffic, but I'm not using it yet. I was thinking of creating a dedicated IP for each node's gluster NIC, and a DNS record by the way ("my_nodes_name_GL"), but I fear using this hostname or this ip in oVirt GUI host network interface tab, leading oVirt think this is a different host. Not being sure this fear is clearly described, let's say : - On each node, I create a second ip+(dns record in the soa) used by gluster, plugged on the correct VLAN - in oVirt gui, in the host network setting tab, the interface will be seen, with its ip, but reverse-dns-related to a different hostname. Here, I fear oVirt might check this reverse DNS and declare this NIC belongs to another host. I would also prefer not use a reverse pointing to the name of the host management ip, as this is evil and I'm a good guy. On your side, how do you cope with a dedicated storage network in case of storage+compute mixed hosts? -- Nicolas ECARNOT

5 11

oVirt-shell command to move a disk
by Nicolas Ecarnot 16 Aug '16

16 Aug '16

Hello, I'm confused because though I'm using ovirt-shell to script many actions every day, and even after a large bunch of reading and testing, I can not find the correct syntax to move (offline/available) disks between storage domains. May you help me please? (oVirt 3.4.4) -- Nicolas Ecarnot

4 10

centos 7.1 and up & ixgbe
by Johan Kooijman 18 Jul '16

18 Jul '16

Hi all, Since we upgraded to the latest ovirt node running 7.2, we're seeing that nodes become unavailable after a while. It's running fine, with a couple of VM's on it, untill it becomes non responsive. At that moment it doesn't even respond to ICMP. It'll come back by itself after a while, but oVirt fences the machine before that time and restarts VM's elsewhere. Engine tells me this message: VDSM host09 command failed: Message timeout which can be caused by communication issues Is anyone else experiencing these issues with ixgbe drivers? I'm running on Intel X540-AT2 cards. -- Met vriendelijke groeten / With kind regards, Johan Kooijman

7 8

New oVirt-Live (3.6.6 rc1) is available for download
by Lev Veyde 23 Jun '16

23 Jun '16

Hi, The new oVirt-Live 3.6.6 rc1 is available for download. You can download it from: http://resources.ovirt.org/pub/ovirt-3.6-pre/iso/ovirt-live/ovirt-live-el7-… Thanks in advance, Lev Veyde.

1 1

VM get stuck randomly
by Christophe TREFOIS 16 Jun '16

16 Jun '16

Dear all, I have a problem since couple of weeks, where randomly 1 VM (not always the same) becomes completely unresponsive. We find this out because our Icinga server complains that host is down. Upon inspection, we find we can’t open a console to the VM, nor can we login. In oVirt engine, the VM looks like “up”. The only weird thing is that RAM usage shows 0% and CPU usage shows 100% or 75% depending on number of cores. The only way to recover is to force shutdown the VM via 2-times shutdown from the engine. Could you please help me to start debugging this? I can provide any logs, but I’m not sure which ones, because I couldn’t see anything with ERROR in the vdsm logs on the host. The host is running OS Version: RHEL - 7 - 1.1503.el7.centos.2.8 Kernel Version: 3.10.0 - 229.14.1.el7.x86_64 KVM Version: 2.1.2 - 23.el7_1.8.1 LIBVIRT Version: libvirt-1.2.8-16.el7_1.4 VDSM Version: vdsm-4.16.26-0.el7.centos SPICE Version: 0.12.4 - 9.el7_1.3 GlusterFS Version: glusterfs-3.7.5-1.el7 We use a locally exported gluster as storage domain (eg, storage is on the same machine exposed via gluster). No replica. We run around 50 VMs on that host. Thank you for your help in this, — Christophe

5 20

Problems exporting VM's
by Luciano Natale 16 Jun '16

16 Jun '16

Hi everyone. I've been having trouble when exporting VM's. I get error when moving image. I've created a whole new storage domain exclusive for this issue, and same thing happens. It's not always the same VM that fails, but once it fails on a certain storage domain, I cannot export it anymore. Please tell me which logs are relevant so i can post them and any other relevant iformation I can provide, and maybe someone can help me get through this problem. Ovirt version is 3.5.4.2-1.el6. Hosted engines is CentOS 6. Hosts are CentOS 7. VM's are all CentOS 7, except for two that are CentOS 6 and Windows 7. Please excuse my bad english! Thanks in advance! -- Luciano Natale

3 4

Neutron appliance & Cloud-init - no bootable device
by Bill Bill 14 Jun '16

14 Jun '16

--_000_SN1PR08MB1389CC3F08A78A5BCC91A4BAA6440SN1PR08MB1389namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNClRyeWluZyB0byBjb25maWd1cmUgdGhlIE5ldXRyb24gYXBwbGlhbmNlIGhvd2V2 ZXIsIHdoZW4gcnVubmluZyBjbG91ZC1pbml0IHRvIGF0dGVtcHQgdG8gc2V0IGEgcm9vdCBwYXNz d29yZCBvciBhbm90aGVyIHVzZXIgcGFzc3dvcmQsIHRoZSBWTSBzaW1wbHkgYm9vdHMgdG8gYSDi gJxubyBib290YWJsZSBkZXZpY2XigJ0gc3RhdGUuIFdpdGhvdXQgY2xvdWQtaW5pdCwgdGhlIFZN IGJvb3RzIGhvd2V2ZXIsIGhhdmUgbm8gaWRlYSB3aGF0IHRoZSBkZWZhdWx0IHJvb3QgbG9naW4g aXMuDQoNCknigJl2ZSBhbHNvIHRyaWVkIGJvb3RpbmcgaW50byBzaW5nbGUgdXNlciBtb2RlIHdo aWNoIGFsc28gZmFpbHMg4oCTIGhhcyB0aGlzIE5ldXRyb24gYXBwbGlhbmNlIGFuZCBjbG91ZC1p bml0IGJlZW4gdGVzdGVkIGZvciB2IDMuNj8NCg== --_000_SN1PR08MB1389CC3F08A78A5BCC91A4BAA6440SN1PR08MB1389namp_ Content-Type: text/html; charset="utf-8" Content-ID: <18DF5AC3DAE2C644913349334C4AE079(a)sct-15-1-485-2-msonline-outlook-1173a.templateTenant> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0iIzk1NEY3 MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVs bG8sPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UcnlpbmcgdG8gY29uZmlndXJlIHRoZSBOZXV0cm9uIGFwcGxpYW5j ZSBob3dldmVyLCB3aGVuIHJ1bm5pbmcgY2xvdWQtaW5pdCB0byBhdHRlbXB0IHRvIHNldCBhIHJv b3QgcGFzc3dvcmQgb3IgYW5vdGhlciB1c2VyIHBhc3N3b3JkLCB0aGUgVk0gc2ltcGx5IGJvb3Rz IHRvIGEg4oCcbm8gYm9vdGFibGUgZGV2aWNl4oCdIHN0YXRlLiBXaXRob3V0IGNsb3VkLWluaXQs IHRoZSBWTSBib290cyBob3dldmVyLCBoYXZlIG5vDQogaWRlYSB3aGF0IHRoZSBkZWZhdWx0IHJv b3QgbG9naW4gaXMuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZdmUgYWxzbyB0cmllZCBib290aW5nIGludG8g c2luZ2xlIHVzZXIgbW9kZSB3aGljaCBhbHNvIGZhaWxzIOKAkyBoYXMgdGhpcyBOZXV0cm9uIGFw cGxpYW5jZSBhbmQgY2xvdWQtaW5pdCBiZWVuIHRlc3RlZCBmb3IgdiAzLjY/PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN1PR08MB1389CC3F08A78A5BCC91A4BAA6440SN1PR08MB1389namp_--

3 3

Re: [ovirt-users] virt-in-virt problem: DHCP failing for a container in a oVirt VM
by Will Dennis 08 Jun '16

08 Jun '16

--_000_F3282EEAFF180F43BAF1AD0A7C34739D3DA28Cnjmailneclabscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdOKAmXMgaW4gaXB0YWJsZXMsIHJpZ2h0PyBJIGhhdmUgaXB0YWJsZXMgZGlzYWJsZWQgb24g bXkgb1ZpcnQgbm9kZXMuLi4NCg0KRnJvbTogWWFuaXYgS2F1bCBbbWFpbHRvOnlrYXVsQHJlZGhh dC5jb21dDQpTZW50OiBGcmlkYXksIE1heSAwNiwgMjAxNiAzOjUwIFBNDQpUbzogV2lsbCBEZW5u aXMNClN1YmplY3Q6IFJlOiBbb3ZpcnQtdXNlcnNdIHZpcnQtaW4tdmlydCBwcm9ibGVtOiBESENQ IGZhaWxpbmcgZm9yIGEgY29udGFpbmVyIGluIGEgb1ZpcnQgVk0NCg0KTG9uZyBzaG90IC0geW91 IG5lZWQgdG8gZGlzYWJsZSB0aGUgRW5hYmxlTUFDQW50aVNwb29maW5nRmlsdGVyUnVsZXMgLg0K WS4NCg0KT24gRnJpLCBNYXkgNiwgMjAxNiBhdCA4OjI3IFBNLCBXaWxsIERlbm5pcyA8d2Rlbm5p c0BuZWMtbGFicy5jb208bWFpbHRvOndkZW5uaXNAbmVjLWxhYnMuY29tPj4gd3JvdGU6DQpIaSBh bGwsDQoNCkhhdmUgYW4gaW50ZXJlc3RpbmcgcHJvYmxlbSDigJMgSSBhbSBydW5uaW5nIGEgVk0g aW4gb1ZpcnQgdGhhdCBpcyBydW5uaW5nIFByb3htb3ggVkUgNC4xIE9TLCB3aGljaCBJIGhhdmUg c3B1biB1cCBhIGNvbnRhaW5lciBvbi4gIFRoZSBjb250YWluZXIgaXMgc2V0IGZvciBESENQLCBh bmQgSSBoYXZlIHZlcmlmaWVkIHRoYXQgaXQgaXMgc2VuZGluZyBEaXNjb3ZlciBwYWNrZXRzIGFz IG5vcm1hbCwgYW5kIHRoYXQgdGhlc2UgcGFja2V0cyBhcmUgbWFraW5nIGl0IG91dCBvZiB0aGUg UHJveG1veCBWTSB0byB0aGUgb1ZpcnQgYnJpZGdlICh3aGljaCBpcyBhdHRhY2hlZCB0byBhIFZM QU4gc3ViLWludGVyZmFjZSBvZiBhIGJvbmQgaW50ZXJmYWNlLikgSG93ZXZlciwgdGhlc2UgcGFj a2V0cyBkbyBOT1QgbWFrZSBpdCBwYXN0IHRoZSBvVmlydCBicmlkZ2UuIFRoZSBpbnRlcmVzdGlu ZyB0aGluZyBpcyB0aGF0IHRoZSBQcm94bW94IFZNIChhcyB3ZWxsIGFzIGFueSBvdGhlciBWTSBJ IHNwaW4gdXAgb24gb1ZpcnQpIHdvcmtzIGZpbmUgd2l0aCBESENQLiAoSSBhbHNvIGhhdmUgb3Ro ZXIgb1ZpcnQgVk1zIGluc3RhbnRpYXRlZCB3aGljaCBhcmUgdXNpbmcgTFhEIHRvIHNwaW4gdXAg Y29udGFpbmVycywgYW5kIEkgaGF2ZSB0aGUgc2FtZSBwcm9ibGVtIHdpdGggdGhvc2UgYXMgd2Vs bC4pIEkgY2hlY2tlZCBhIGJ1bmNoIG9mIHN0dWZmLCBhbmQgdGhlIG9ubHkgY2x1ZSBJIGNvdWxk IGZpbmQgaXMgdGhhdCBpdCBzZWVtcyB0aGF0IHRoZSBvVmlydCBicmlkZ2UgaXMgbm90IGxlYXJu aW5nIHRoZSBNQUMgZm9yIHRoZSBjb250YWluZXIgb24gdGhlIFZNLCBldmVuIHRob3VnaCBpdCBk b2VzIGxlYXJuIHRoZSBWTeKAmXMgTUFDLCBidXQgSSBjYW4gY2FwdHVyZSBESENQIHRyYWZmaWMg Y29taW5nIGZyb20gdGhlIGNvbnRhaW5lciBvZmYgdGhlIOKAmHZuZXQw4oCZIGludGVyZmFjZSB3 aGljaCBpcyBqb2luZWQgdG8gdGhhdCBicmlkZ2UuLi4NCg0KSW5mbzoNCg0KPT09PT0gb2ZmIFBy b3htb3ggVk0gPT09PT0NCg0KQ29udGFpbmVyJ3MgTUFDIGFkZHJlc3M6IDMyOjYyOjY1OjYxOjY1 OjMzDQoNCnJvb3RAcHJveG1veC0wMjp+IyBpcCBsaW5rIHNoDQoxOiBsbzogPExPT1BCQUNLLFVQ LExPV0VSX1VQPiBtdHUgNjU1MzYgcWRpc2Mgbm9xdWV1ZSBzdGF0ZSBVTktOT1dOIG1vZGUgREVG QVVMVCBncm91cCBkZWZhdWx0DQogICAgbGluay9sb29wYmFjayAwMDowMDowMDowMDowMDowMCBi cmQgMDA6MDA6MDA6MDA6MDA6MDANCjI6IGV0aDA6IDxCUk9BRENBU1QsTVVMVElDQVNULFVQLExP V0VSX1VQPiBtdHUgMTUwMCBxZGlzYyBwZmlmb19mYXN0IG1hc3RlciB2bWJyMCBzdGF0ZSBVUCBt b2RlIERFRkFVTFQgZ3JvdXAgZGVmYXVsdCBxbGVuIDEwMDANCiAgICBsaW5rL2V0aGVyIDAwOjFh OjRhOjE2OjAxOjU3IGJyZCBmZjpmZjpmZjpmZjpmZjpmZg0KMzogdm1icjA6IDxCUk9BRENBU1Qs TVVMVElDQVNULFVQLExPV0VSX1VQPiBtdHUgMTUwMCBxZGlzYyBub3F1ZXVlIHN0YXRlIFVQIG1v ZGUgREVGQVVMVCBncm91cCBkZWZhdWx0DQogICAgbGluay9ldGhlciAwMDoxYTo0YToxNjowMTo1 NyBicmQgZmY6ZmY6ZmY6ZmY6ZmY6ZmYNCjc6IHZldGgxMDBpMEBpZjY6IDxCUk9BRENBU1QsTVVM VElDQVNULFVQLExPV0VSX1VQPiBtdHUgMTUwMCBxZGlzYyBwZmlmb19mYXN0IG1hc3RlciB2bWJy MCBzdGF0ZSBVUCBtb2RlIERFRkFVTFQgZ3JvdXAgZGVmYXVsdCBxbGVuIDEwMDANCiAgICBsaW5r L2V0aGVyIGZlOjUwOjRmOjNjOmJkOmI4IGJyZCBmZjpmZjpmZjpmZjpmZjpmZiBsaW5rLW5ldG5z aWQgMCAgIDw8PCB2ZXRoIGNvbm5lY3Rpb24gdG8gY29udGFpbmVyDQoNCnJvb3RAcHJveG1veC0w Mjp+IyBicmN0bCBzaG93bWFjcyB2bWJyMA0KcG9ydCBubyBtYWMgYWRkciAgICAgICAgICAgICAg ICBpcyBsb2NhbD8gICAgICAgYWdlaW5nIHRpbWVyDQogIDEgICAgIDAwOjEyOjNmOjI0OmE0OjU0 ICAgICAgIG5vICAgICAgICAgICAgICAgMTEyLjg4DQogIDEgICAgIDAwOjFhOjRhOjE2OjAxOjU2 ICAgICAgIG5vICAgICAgICAgICAgICAgICAwLjAyDQogIDEgICAgIDAwOjFhOjRhOjE2OjAxOjU3 ICAgICAgIHllcyAgICAgICAgICAgICAgICAwLjAwDQogIDEgICAgIDAwOjFhOjRhOjE2OjAxOjU3 ICAgICAgIHllcyAgICAgICAgICAgICAgICAwLjAwDQogIDEgICAgIDAwOjI0OjUwOmRkOmEyOjA1 ICAgICAgIG5vICAgICAgICAgICAgICAgICAxLjM3DQogIDEgICAgIDE4OjAzOjczOmUzOmJlOjVh ICAgICAgIG5vICAgICAgICAgICAgICAgIDIxLjA0DQogIDEgICAgIDE4OjAzOjczOmUzOmNhOjI0 ICAgICAgIG5vICAgICAgICAgICAgICAgICA0LjIzDQogIDEgICAgIDE4OjAzOjczOmUzOmNiOjVi ICAgICAgIG5vICAgICAgICAgICAgICAgIDQ4LjQxDQogIDEgICAgIDE4OjAzOjczOmUzOmNjOmU1 ICAgICAgIG5vICAgICAgICAgICAgICAgIDkxLjkzDQogIDEgICAgIDE4OjAzOjczOmUzOmNkOmI4 ICAgICAgIG5vICAgICAgICAgICAgICAgMTUxLjA0DQogIDEgICAgIDE4OjAzOjczOmUzOmNlOjQz ICAgICAgIG5vICAgICAgICAgICAgICAgICAwLjgwDQogIDEgICAgIDE4OjAzOjczOmUzOmQwOmE0 ICAgICAgIG5vICAgICAgICAgICAgICAgMjkwLjc0DQogIDEgICAgIDE4OjAzOjczOmUzOmQ0OjI2 ICAgICAgIG5vICAgICAgICAgICAgICAgIDM0LjA2DQogIDEgICAgIDE4OjAzOjczOmUzOmQ1OjNk ICAgICAgIG5vICAgICAgICAgICAgICAgICA2LjM2DQogIDEgICAgIDE4OjAzOjczOmU0OjIzOjA4 ICAgICAgIG5vICAgICAgICAgICAgICAgIDg4Ljc2DQogIDEgICAgIDE4OjAzOjczOmU0OjI1Ojky ICAgICAgIG5vICAgICAgICAgICAgICAgMTExLjg2DQogIDEgICAgIDE4OjAzOjczOmU0OjI2OjJm ICAgICAgIG5vICAgICAgICAgICAgICAgICA5LjU0DQogIDEgICAgIDE4OjAzOjczOmU0OjJiOjRj ICAgICAgIG5vICAgICAgICAgICAgICAgMTE0Ljg2DQogIDEgICAgIDE4OjAzOjczOmU0OjMxOjE1 ICAgICAgIG5vICAgICAgICAgICAgICAgMjYzLjkxDQogIDEgICAgIDE4OjAzOjczOmU0OjZjOjE5 ICAgICAgIG5vICAgICAgICAgICAgICAgICA2LjM2DQogIDEgICAgIDE4OjAzOjczOmU0OjdlOjBh ICAgICAgIG5vICAgICAgICAgICAgICAgMTAzLjA2DQogIDEgICAgIDE4OjAzOjczOmU4OjE2OmUw ICAgICAgIG5vICAgICAgICAgICAgICAgIDIzLjIxDQogIDIgICAgIDMyOjYyOjY1OjYxOjY1OjMz ICAgICAgIG5vICAgICAgICAgICAgICAgICA1LjA4ICAgPDw8IGNvbnRhaW5lcuKAmXMgTUFDIGxl YXJuZWQgb24gUHJveG1veCBicmlkZ2UNCiAgMSAgICAgMzQ6MTc6ZWI6OWI6ZTA6MjkgICAgICAg bm8gICAgICAgICAgICAgICAyNjUuMjINCiAgMSAgICAgMzQ6MTc6ZWI6OWI6Zjg6ZWEgICAgICAg bm8gICAgICAgICAgICAgICAxMTQuODYNCiAgMSAgICAgNDQ6ZDM6Y2E6N2U6M2M6ZmYgICAgICAg bm8gICAgICAgICAgICAgICAgIDAuMDANCiAgMSAgICAgNzg6MmI6Y2I6M2I6Y2E6YjkgICAgICAg bm8gICAgICAgICAgICAgICAyODQuNzANCiAgMSAgICAgNzg6MmI6Y2I6OTI6Y2I6Y2IgICAgICAg bm8gICAgICAgICAgICAgICAyNzkuNzANCiAgMSAgICAgNzg6MmI6Y2I6OTM6MDg6YTggICAgICAg bm8gICAgICAgICAgICAgICAyODcuMDUNCiAgMSAgICAgYjg6Y2E6M2E6N2E6NzA6NjMgICAgICAg bm8gICAgICAgICAgICAgICAgIDQuODMNCiAgMSAgICAgZjg6YmM6MTI6Njk6YmI6YTMgICAgICAg bm8gICAgICAgICAgICAgICAxMjEuODINCiAgMiAgICAgZmU6NTA6NGY6M2M6YmQ6YjggICAgICAg eWVzICAgICAgICAgICAgICAgIDAuMDANCiAgMiAgICAgZmU6NTA6NGY6M2M6YmQ6YjggICAgICAg eWVzICAgICAgICAgICAgICAgIDAuMDANCg0KPT09PT0gb2ZmIG9WaXJ0IG5vZGUgdGhhdCBoYXMg UHJveG1veCBWTSA9PT09DQoNCihyZWxldmFudCBsaW5lcyBmcm9tIOKAmGlwIGxpbmsgc2hvd+KA mSkNCjI6IGJvbmQwOiA8QlJPQURDQVNULE1VTFRJQ0FTVCxNQVNURVIsVVAsTE9XRVJfVVA+IG10 dSAxNTAwIHFkaXNjIG5vcXVldWUgc3RhdGUgVVAgbW9kZSBERUZBVUxUDQozOiBlbnA0czBmMDog PEJST0FEQ0FTVCxNVUxUSUNBU1QsU0xBVkUsVVAsTE9XRVJfVVA+IG10dSAxNTAwIHFkaXNjIHBm aWZvX2Zhc3QgbWFzdGVyIGJvbmQwIHN0YXRlIFVQIG1vZGUgREVGQVVMVCBxbGVuIDEwMDANCjQ6 IGVucDRzMGYxOiA8QlJPQURDQVNULE1VTFRJQ0FTVCxTTEFWRSxVUCxMT1dFUl9VUD4gbXR1IDE1 MDAgcWRpc2MgcGZpZm9fZmFzdCBtYXN0ZXIgYm9uZDAgc3RhdGUgVVAgbW9kZSBERUZBVUxUIHFs ZW4gMTAwMA0KODogYm9uZDAuMTY5QGJvbmQwPG1haWx0bzpib25kMC4xNjlAYm9uZDA+OiA8QlJP QURDQVNULE1VTFRJQ0FTVCxVUCxMT1dFUl9VUD4gbXR1IDE1MDAgcWRpc2Mgbm9xdWV1ZSBtYXN0 ZXIgMTY5LW5ldCBzdGF0ZSBVUCBtb2RlIERFRkFVTFQNCjEwOiBib25kMC4xODBAYm9uZDA8bWFp bHRvOmJvbmQwLjE4MEBib25kMD46IDxCUk9BRENBU1QsTVVMVElDQVNULFVQLExPV0VSX1VQPiBt dHUgMTUwMCBxZGlzYyBub3F1ZXVlIG1hc3RlciAxODAtbmV0IHN0YXRlIFVQIG1vZGUgREVGQVVM VA0KMTI6IGJvbmQwLjIwN0Bib25kMDxtYWlsdG86Ym9uZDAuMjA3QGJvbmQwPjogPEJST0FEQ0FT VCxNVUxUSUNBU1QsVVAsTE9XRVJfVVA+IG10dSAxNTAwIHFkaXNjIG5vcXVldWUgbWFzdGVyIDIw Ny1uZXQgc3RhdGUgVVAgbW9kZSBERUZBVUxUDQoxMzogMjA3LW5ldDogPEJST0FEQ0FTVCxNVUxU SUNBU1QsVVAsTE9XRVJfVVA+IG10dSAxNTAwIHFkaXNjIG5vcXVldWUgc3RhdGUgVVAgbW9kZSBE RUZBVUxUDQozMDogdm5ldDA6IDxCUk9BRENBU1QsTVVMVElDQVNULFVQLExPV0VSX1VQPiBtdHUg MTUwMCBxZGlzYyBwZmlmb19mYXN0IG1hc3RlciAyMDctbmV0IHN0YXRlIFVOS05PV04gbW9kZSBE RUZBVUxUIHFsZW4gNTAwIDw8PCB2ZXRoIGNvbm5lY3Rpb24gdG8gUHJveG1veCBWTQ0KMzE6IHZu ZXQxOiA8QlJPQURDQVNULE1VTFRJQ0FTVCxVUCxMT1dFUl9VUD4gbXR1IDE1MDAgcWRpc2MgcGZp Zm9fZmFzdCBtYXN0ZXIgMjA3LW5ldCBzdGF0ZSBVTktOT1dOIG1vZGUgREVGQVVMVCBxbGVuIDUw MA0KDQpbcm9vdEBvdmlydC1ub2RlLTAzIH5dIyBicmN0bCBzaG93DQpicmlkZ2UgbmFtZSAgICAg YnJpZGdlIGlkICAgICAgICAgICAgICAgU1RQIGVuYWJsZWQgICAgIGludGVyZmFjZXMNCjE2OS1u ZXQgICAgICAgICA4MDAwLjAwMTUxNzdiZTlkYSAgICAgICBubyAgICAgICAgICAgICAgYm9uZDAu MTY5DQoxODAtbmV0ICAgICAgICAgODAwMC4wMDE1MTc3YmU5ZGEgICAgICAgbm8gICAgICAgICAg ICAgIGJvbmQwLjE4MA0KMjA3LW5ldCAgICAgICAgIDgwMDAuMDAxNTE3N2JlOWRhICAgICAgIG5v ICAgICAgICAgICAgICBib25kMC4yMDcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdm5ldDANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdm5ldDENCjt2ZHNtZHVtbXk7ICAgICA4MDAw LjAwMDAwMDAwMDAwMCAgICAgICBubw0Kb3ZpcnRtZ210ICAgICAgIDgwMDAuMDAyMTg1MzUwODZh ICAgICAgIG5vICAgICAgICAgICAgICBlbnAxMnMwZjANCg0KDQpbcm9vdEBvdmlydC1ub2RlLTAz IH5dIyB0Y3BkdW1wIC1pIHZuZXQwIC12dnYgLXMgMTUwMCAnKHBvcnQgNjcgb3IgcG9ydCA2OCkn DQp0Y3BkdW1wOiBXQVJOSU5HOiB2bmV0MDogbm8gSVB2NCBhZGRyZXNzIGFzc2lnbmVkDQp0Y3Bk dW1wOiBsaXN0ZW5pbmcgb24gdm5ldDAsIGxpbmstdHlwZSBFTjEwTUIgKEV0aGVybmV0KSwgY2Fw dHVyZSBzaXplIDE1MDAgYnl0ZXMNCjEyOjUyOjA3LjYyODU3MSBJUCAodG9zIDB4MTAsIHR0bCAx MjgsIGlkIDAsIG9mZnNldCAwLCBmbGFncyBbbm9uZV0sIHByb3RvIFVEUCAoMTcpLCBsZW5ndGgg MzI4KQ0KICAgIDAuMC4wLjAuYm9vdHBjID4gMjU1LjI1NS4yNTUuMjU1LmJvb3RwczogW3VkcCBz dW0gb2tdIEJPT1RQL0RIQ1AsIFJlcXVlc3QgZnJvbSAzMjo2Mjo2NTo2MTo2NTozMyAob3VpIFVu a25vd24pLCBsZW5ndGggMzAwLCB4aWQgMHg5ZWZjNDg0OSwgc2VjcyA5NCwgRmxhZ3MgW25vbmVd ICgweDAwMDApDQogICAgICAgICAgQ2xpZW50LUV0aGVybmV0LUFkZHJlc3MgMzI6NjI6NjU6NjE6 NjU6MzMgKG91aSBVbmtub3duKSAgICAgXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eXl5eDQog ICAgICAgICAgVmVuZG9yLXJmYzEwNDggRXh0ZW5zaW9ucw0KICAgICAgICAgICAgTWFnaWMgQ29v a2llIDB4NjM4MjUzNjMNCiAgICAgICAgICAgIERIQ1AtTWVzc2FnZSBPcHRpb24gNTMsIGxlbmd0 aCAxOiBEaXNjb3Zlcg0KICAgICAgICAgICAgSG9zdG5hbWUgT3B0aW9uIDEyLCBsZW5ndGggNTog InRlc3QxIg0KICAgICAgICAgICAgUGFyYW1ldGVyLVJlcXVlc3QgT3B0aW9uIDU1LCBsZW5ndGgg MTM6DQogICAgICAgICAgICAgIFN1Ym5ldC1NYXNrLCBCUiwgVGltZS1ab25lLCBEZWZhdWx0LUdh dGV3YXkNCiAgICAgICAgICAgICAgRG9tYWluLU5hbWUsIERvbWFpbi1OYW1lLVNlcnZlciwgT3B0 aW9uIDExOSwgSG9zdG5hbWUNCiAgICAgICAgICAgICAgTmV0Ymlvcy1OYW1lLVNlcnZlciwgTmV0 Ymlvcy1TY29wZSwgTVRVLCBDbGFzc2xlc3MtU3RhdGljLVJvdXRlDQogICAgICAgICAgICAgIE5U UA0KICAgICAgICAgICAgRU5EIE9wdGlvbiAyNTUsIGxlbmd0aCAwDQogICAgICAgICAgICBQQUQg T3B0aW9uIDAsIGxlbmd0aCAwLCBvY2N1cnMgMzQNCg0KDQpbcm9vdEBvdmlydC1ub2RlLTAzIH5d IyBicmN0bCBzaG93bWFjcyAyMDctbmV0DQpwb3J0IG5vIG1hYyBhZGRyICAgICAgICAgICAgICAg IGlzIGxvY2FsPyAgICAgICBhZ2VpbmcgdGltZXINCiAgMSAgICAgMDA6MTU6MTc6N2I6ZTk6ZGEg ICAgICAgeWVzICAgICAgICAgICAgICAgIDAuMDANCiAgMSAgICAgMDA6MTU6MTc6N2I6ZTk6ZGEg ICAgICAgeWVzICAgICAgICAgICAgICAgIDAuMDANCiAgMyAgICAgMDA6MWE6NGE6MTY6MDE6NTYg ICAgICAgbm8gICAgICAgICAgICAgICAgIDAuMTENCiAgMiAgICAgMDA6MWE6NGE6MTY6MDE6NTcg ICAgICAgbm8gICAgICAgICAgICAgICAgIDAuMTMgIDw8IFByb3htb3ggVk0ncyBldGgwIE1BQyBs ZWFybmVkDQogIDEgICAgIDAwOjI0OjUwOmRkOmEyOjA1ICAgICAgIG5vICAgICAgICAgICAgICAg ICAxLjA1DQogIDEgICAgIDE4OjAzOjczOmUzOmJlOjVhICAgICAgIG5vICAgICAgICAgICAgICAg MTk4Ljg3DQogIDEgICAgIDE4OjAzOjczOmUzOmNhOjI0ICAgICAgIG5vICAgICAgICAgICAgICAg IDYwLjAxDQogIDEgICAgIDE4OjAzOjczOmUzOmNiOjViICAgICAgIG5vICAgICAgICAgICAgICAg IDY4LjI2DQogIDEgICAgIDE4OjAzOjczOmUzOmNkOmI4ICAgICAgIG5vICAgICAgICAgICAgICAg IDQxLjM5DQogIDEgICAgIDE4OjAzOjczOmUzOmQ0OjI2ICAgICAgIG5vICAgICAgICAgICAgICAg IDU3LjI1DQogIDEgICAgIDE4OjAzOjczOmUzOmQ1OjNkICAgICAgIG5vICAgICAgICAgICAgICAg MTMzLjUzDQogIDEgICAgIDE4OjAzOjczOmU0OjIzOjA4ICAgICAgIG5vICAgICAgICAgICAgICAg IDM0LjI4DQogIDEgICAgIDE4OjAzOjczOmU0OjI2OjJmICAgICAgIG5vICAgICAgICAgICAgICAg IDIwLjEwDQogIDEgICAgIDE4OjAzOjczOmU0OjJiOjRjICAgICAgIG5vICAgICAgICAgICAgICAg IDIyLjQ5DQogIDEgICAgIDE4OjAzOjczOmU0OjZjOjE5ICAgICAgIG5vICAgICAgICAgICAgICAg IDE0Ljg3DQogIDEgICAgIDE4OjAzOjczOmU0OjdlOjBhICAgICAgIG5vICAgICAgICAgICAgICAg IDU0LjQ2DQogIDEgICAgIDE4OjAzOjczOmU4OjE2OmUwICAgICAgIG5vICAgICAgICAgICAgICAg IDI4LjcxDQogIDEgICAgIDM0OjE3OmViOjliOmY4OmVhICAgICAgIG5vICAgICAgICAgICAgICAg IDIyLjQ5DQogIDEgICAgIDQ0OmQzOmNhOjdlOjNjOmZmICAgICAgIG5vICAgICAgICAgICAgICAg ICAwLjYwDQogIDEgICAgIDc4OjJiOmNiOjNiOmNhOmI5ICAgICAgIG5vICAgICAgICAgICAgICAg MjE3LjY2DQogIDEgICAgIDc4OjJiOmNiOjkyOmNiOmNiICAgICAgIG5vICAgICAgICAgICAgICAg MTk0LjE4DQogIDEgICAgIDc4OjJiOmNiOjkzOjA4OmE4ICAgICAgIG5vICAgICAgICAgICAgICAg MTAyLjQ5DQogIDEgICAgIGI4OmNhOjNhOjdhOjcwOjYzICAgICAgIG5vICAgICAgICAgICAgICAg ICA0LjE5DQogIDEgICAgIGY4OmJjOjEyOjY5OmJiOmEzICAgICAgIG5vICAgICAgICAgICAgICAg MTEwLjUyDQogIDMgICAgIGZlOjFhOjRhOjE2OjAxOjU2ICAgICAgIHllcyAgICAgICAgICAgICAg ICAwLjAwICA8PDwgdmV0aCBjb25uZWN0aW9uIHRvIFByb3htb3ggVk0gKHZldGgwKQ0KICAzICAg ICBmZToxYTo0YToxNjowMTo1NiAgICAgICB5ZXMgICAgICAgICAgICAgICAgMC4wMA0KICAyICAg ICBmZToxYTo0YToxNjowMTo1NyAgICAgICB5ZXMgICAgICAgICAgICAgICAgMC4wMA0KICAyICAg ICBmZToxYTo0YToxNjowMTo1NyAgICAgICB5ZXMgICAgICAgICAgICAgICAgMC4wMA0KKG5vdGlj ZSBubyBvdGhlciBlbnRyaWVzIGZvciBwb3J0IDMg4oCTIHNob3VsZCBiZSBsZWFybmluZyBNQUMg MzI6NjI6NjU6NjE6NjU6MzMgZnJvbSBpbmNvbWluZyB0cmFmZmljIG9uIHZuZXQwKQ0KDQo9PT09 PQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N ClVzZXJzIG1haWxpbmcgbGlzdA0KVXNlcnNAb3ZpcnQub3JnPG1haWx0bzpVc2Vyc0BvdmlydC5v cmc+DQpodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnMNCg0K --_000_F3282EEAFF180F43BAF1AD0A7C34739D3DA28Cnjmailneclabscom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoYXTigJlzIGluIGlwdGFibGVzLCByaWdodD8gSSBoYXZlIGlwdGFibGVzIGRpc2FibGVk IG9uIG15IG9WaXJ0IG5vZGVzLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBZYW5pdiBLYXVsIFttYWlsdG86eWthdWxAcmVkaGF0LmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiBGcmlkYXksIE1heSAwNiwgMjAxNiAzOjUwIFBNPGJyPg0KPGI+VG86PC9iPiBXaWxs IERlbm5pczxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW292aXJ0LXVzZXJzXSB2aXJ0LWluLXZp cnQgcHJvYmxlbTogREhDUCBmYWlsaW5nIGZvciBhIGNvbnRhaW5lciBpbiBhIG9WaXJ0IFZNPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TG9uZyBzaG90IC0geW91IG5lZWQg dG8gZGlzYWJsZSB0aGUmbmJzcDtFbmFibGVNQUNBbnRpU3Bvb2ZpbmdGaWx0ZXJSdWxlcyAuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBNYXkgNiwg MjAxNiBhdCA4OjI3IFBNLCBXaWxsIERlbm5pcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndkZW5uaXNA bmVjLWxhYnMuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2Rlbm5pc0BuZWMtbGFicy5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5IaSBhbGwsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IYXZlIGFuIGludGVyZXN0 aW5nIHByb2JsZW0g4oCTIEkgYW0gcnVubmluZyBhIFZNIGluIG9WaXJ0IHRoYXQgaXMgcnVubmlu ZyBQcm94bW94IFZFIDQuMSBPUywgd2hpY2ggSSBoYXZlIHNwdW4gdXAgYSBjb250YWluZXIgb24u Jm5ic3A7IFRoZSBjb250YWluZXIgaXMgc2V0IGZvciBESENQLCBhbmQgSSBoYXZlIHZlcmlmaWVk DQogdGhhdCBpdCBpcyBzZW5kaW5nIERpc2NvdmVyIHBhY2tldHMgYXMgbm9ybWFsLCBhbmQgdGhh dCB0aGVzZSBwYWNrZXRzIGFyZSBtYWtpbmcgaXQgb3V0IG9mIHRoZSBQcm94bW94IFZNIHRvIHRo ZSBvVmlydCBicmlkZ2UgKHdoaWNoIGlzIGF0dGFjaGVkIHRvIGEgVkxBTiBzdWItaW50ZXJmYWNl IG9mIGEgYm9uZCBpbnRlcmZhY2UuKSBIb3dldmVyLCB0aGVzZSBwYWNrZXRzIGRvIE5PVCBtYWtl IGl0IHBhc3QgdGhlIG9WaXJ0IGJyaWRnZS4gVGhlDQogaW50ZXJlc3RpbmcgdGhpbmcgaXMgdGhh dCB0aGUgUHJveG1veCBWTSAoYXMgd2VsbCBhcyBhbnkgb3RoZXIgVk0gSSBzcGluIHVwIG9uIG9W aXJ0KSB3b3JrcyBmaW5lIHdpdGggREhDUC4gKEkgYWxzbyBoYXZlIG90aGVyIG9WaXJ0IFZNcyBp bnN0YW50aWF0ZWQgd2hpY2ggYXJlIHVzaW5nIExYRCB0byBzcGluIHVwIGNvbnRhaW5lcnMsIGFu ZCBJIGhhdmUgdGhlIHNhbWUgcHJvYmxlbSB3aXRoIHRob3NlIGFzIHdlbGwuKSBJIGNoZWNrZWQg YSBidW5jaA0KIG9mIHN0dWZmLCBhbmQgdGhlIG9ubHkgY2x1ZSBJIGNvdWxkIGZpbmQgaXMgdGhh dCBpdCBzZWVtcyB0aGF0IHRoZSBvVmlydCBicmlkZ2UgaXMgbm90IGxlYXJuaW5nIHRoZSBNQUMg Zm9yIHRoZSBjb250YWluZXIgb24gdGhlIFZNLCBldmVuIHRob3VnaCBpdCBkb2VzIGxlYXJuIHRo ZSBWTeKAmXMgTUFDLCBidXQgSSBjYW4gY2FwdHVyZSBESENQIHRyYWZmaWMgY29taW5nIGZyb20g dGhlIGNvbnRhaW5lciBvZmYgdGhlIOKAmHZuZXQw4oCZIGludGVyZmFjZQ0KIHdoaWNoIGlzIGpv aW5lZCB0byB0aGF0IGJyaWRnZS4uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW5mbzo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPj09PT09IG9mZiBQcm94bW94IFZNID09PT09PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Db250YWluZXIncyBNQUMgYWRkcmVzczogMzI6NjI6 NjU6NjE6NjU6MzM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnJvb3RAcHJveG1veC0wMjp+ IyBpcCBsaW5rIHNoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjE6IGxv OiAmbHQ7TE9PUEJBQ0ssVVAsTE9XRVJfVVAmZ3Q7IG10dSA2NTUzNiBxZGlzYyBub3F1ZXVlIHN0 YXRlIFVOS05PV04gbW9kZSBERUZBVUxUIGdyb3VwIGRlZmF1bHQ8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxpbmsvbG9vcGJhY2sgMDA6 MDA6MDA6MDA6MDA6MDAgYnJkIDAwOjAwOjAwOjAwOjAwOjAwPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjI6IGV0aDA6ICZsdDtCUk9BRENBU1QsTVVMVElDQVNULFVQLExP V0VSX1VQJmd0OyBtdHUgMTUwMCBxZGlzYyBwZmlmb19mYXN0IG1hc3RlciB2bWJyMCBzdGF0ZSBV UCBtb2RlIERFRkFVTFQgZ3JvdXAgZGVmYXVsdCBxbGVuIDEwMDA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxpbmsvZXRoZXIgMDA6MWE6 NGE6MTY6MDE6NTcgYnJkIGZmOmZmOmZmOmZmOmZmOmZmPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjM6IHZtYnIwOiAmbHQ7QlJPQURDQVNULE1VTFRJQ0FTVCxVUCxMT1dF Ul9VUCZndDsgbXR1IDE1MDAgcWRpc2Mgbm9xdWV1ZSBzdGF0ZSBVUCBtb2RlIERFRkFVTFQgZ3Jv dXAgZGVmYXVsdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsm bmJzcDsmbmJzcDsgbGluay9ldGhlciAwMDoxYTo0YToxNjowMTo1NyBicmQgZmY6ZmY6ZmY6ZmY6 ZmY6ZmY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+NzogdmV0aDEwMGkw QGlmNjogJmx0O0JST0FEQ0FTVCxNVUxUSUNBU1QsVVAsTE9XRVJfVVAmZ3Q7IG10dSAxNTAwIHFk aXNjIHBmaWZvX2Zhc3QgbWFzdGVyIHZtYnIwIHN0YXRlIFVQIG1vZGUgREVGQVVMVCBncm91cCBk ZWZhdWx0IHFsZW4gMTAwMDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDsmbmJzcDsmbmJzcDsgbGluay9ldGhlciBmZTo1MDo0ZjozYzpiZDpiOCBicmQgZmY6ZmY6 ZmY6ZmY6ZmY6ZmYgbGluay1uZXRuc2lkIDAmbmJzcDsmbmJzcDsgJmx0OyZsdDsmbHQ7IHZldGgg Y29ubmVjdGlvbiB0byBjb250YWluZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnJvb3RA cHJveG1veC0wMjp+IyBicmN0bCBzaG93bWFjcyB2bWJyMDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5wb3J0IG5vIG1hYyBhZGRyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGlzIGxvY2FsPyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBh Z2VpbmcgdGltZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMDA6MTI6M2Y6MjQ6YTQ6NTQmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbm8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTEy Ljg4PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAxJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAwOjFhOjRhOjE2OjAxOjU2Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IG5vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDAuMDI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IDEmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMDA6MWE6NGE6MTY6MDE6NTcmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgeWVzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAu MDA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IDEmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgMDA6MWE6NGE6MTY6MDE6NTcmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgeWVzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAuMDA8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IDEmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgMDA6MjQ6NTA6ZGQ6YTI6MDUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgbm8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMS4z NzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgMSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAxODowMzo3MzplMzpiZTo1YSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBubyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyMS4wNDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgMSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAxODowMzo3MzplMzpjYToyNCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBubyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs0LjIz PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAxJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDE4OjAzOjczOmUzOmNiOjViJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IG5vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQ4LjQxPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAxJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDE4OjAzOjczOmUzOmNjOmU1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG5vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDkxLjkzPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDE4OjAzOjczOmUzOmNkOmI4Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG5vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE1MS4wNDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAxODowMzo3MzplMzpjZTo0MyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBu byZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwLjgwPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDE4OjAzOjczOmUzOmQwOmE0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG5vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDI5MC43NDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxODow Mzo3MzplMzpkNDoyNiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBubyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzNC4wNjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxODowMzo3 MzplMzpkNTozZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBubyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA2LjM2PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE4OjAz OjczOmU0OjIzOjA4Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDg4Ljc2PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE4OjAzOjcz OmU0OjI1OjkyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOzExMS44NjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxODowMzo3MzplNDoyNjoy ZiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBubyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA5LjU0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE4OjAzOjczOmU0OjJi OjRjJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDExNC44NjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxODowMzo3MzplNDozMToxNSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBubyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAyNjMuOTE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTg6MDM6NzM6ZTQ6NmM6MTkmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbm8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgNi4zNjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxODowMzo3MzplNDo3ZTowYSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBubyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAx MDMuMDY8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IDEmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMTg6MDM6NzM6ZTg6MTY6ZTAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgbm8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjMu MjE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IDImbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgMzI6NjI6NjU6NjE6NjU6MzMmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgbm8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg NS4wOCZuYnNwOyZuYnNwOyAmbHQ7Jmx0OyZsdDsgY29udGFpbmVy4oCZcyBNQUMgbGVhcm5lZCBv biBQcm94bW94IGJyaWRnZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzNDoxNzplYjo5YjplMDoyOSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBubyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAyNjUuMjI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IDEm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMzQ6MTc6ZWI6OWI6Zjg6ZWEmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgbm8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTE0Ljg2 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAxJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDQ0OmQzOmNhOjdlOjNjOmZmJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IG5vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAu MDA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IDEmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgNzg6MmI6Y2I6M2I6Y2E6YjkmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgbm8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjg0LjcwPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDc4OjJiOmNiOjkyOmNiOmNiJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG5vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDI3OS43MDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA3ODoyYjpjYjo5MzowODphOCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBu byZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyODcuMDU8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYjg6Y2E6 M2E6N2E6NzA6NjMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbm8mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgNC44MzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmODpi YzoxMjo2OTpiYjphMyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBubyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxMjEuODI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7IDImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZmU6NTA6NGY6M2M6 YmQ6YjgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeWVzJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAuMDA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7IDImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZmU6NTA6NGY6M2M6YmQ6 YjgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeWVzJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAuMDA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPj09PT09 IG9mZiBvVmlydCBub2RlIHRoYXQgaGFzIFByb3htb3ggVk0gPT09PTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+KHJlbGV2YW50IGxpbmVzIGZyb20g4oCYaXAgbGluayBzaG934oCZKTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4yOiBib25kMDogJmx0O0JST0FEQ0FT VCxNVUxUSUNBU1QsTUFTVEVSLFVQLExPV0VSX1VQJmd0OyBtdHUgMTUwMCBxZGlzYyBub3F1ZXVl IHN0YXRlIFVQIG1vZGUgREVGQVVMVDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4zOiBlbnA0czBmMDogJmx0O0JST0FEQ0FTVCxNVUxUSUNBU1QsU0xBVkUsVVAsTE9XRVJf VVAmZ3Q7IG10dSAxNTAwIHFkaXNjIHBmaWZvX2Zhc3QgbWFzdGVyIGJvbmQwIHN0YXRlIFVQIG1v ZGUgREVGQVVMVCBxbGVuIDEwMDA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+NDogZW5wNHMwZjE6ICZsdDtCUk9BRENBU1QsTVVMVElDQVNULFNMQVZFLFVQLExPV0VSX1VQ Jmd0OyBtdHUgMTUwMCBxZGlzYyBwZmlmb19mYXN0IG1hc3RlciBib25kMCBzdGF0ZSBVUCBtb2Rl IERFRkFVTFQgcWxlbiAxMDAwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pjg6DQo8YSBocmVmPSJtYWlsdG86Ym9uZDAuMTY5QGJvbmQwIj5ib25kMC4xNjlAYm9uZDA8L2E+ OiAmbHQ7QlJPQURDQVNULE1VTFRJQ0FTVCxVUCxMT1dFUl9VUCZndDsgbXR1IDE1MDAgcWRpc2Mg bm9xdWV1ZSBtYXN0ZXIgMTY5LW5ldCBzdGF0ZSBVUCBtb2RlIERFRkFVTFQ8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTA6DQo8YSBocmVmPSJtYWlsdG86Ym9uZDAuMTgw QGJvbmQwIj5ib25kMC4xODBAYm9uZDA8L2E+OiAmbHQ7QlJPQURDQVNULE1VTFRJQ0FTVCxVUCxM T1dFUl9VUCZndDsgbXR1IDE1MDAgcWRpc2Mgbm9xdWV1ZSBtYXN0ZXIgMTgwLW5ldCBzdGF0ZSBV UCBtb2RlIERFRkFVTFQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTI6 DQo8YSBocmVmPSJtYWlsdG86Ym9uZDAuMjA3QGJvbmQwIj5ib25kMC4yMDdAYm9uZDA8L2E+OiAm bHQ7QlJPQURDQVNULE1VTFRJQ0FTVCxVUCxMT1dFUl9VUCZndDsgbXR1IDE1MDAgcWRpc2Mgbm9x dWV1ZSBtYXN0ZXIgMjA3LW5ldCBzdGF0ZSBVUCBtb2RlIERFRkFVTFQ8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTM6IDIwNy1uZXQ6ICZsdDtCUk9BRENBU1QsTVVMVElD QVNULFVQLExPV0VSX1VQJmd0OyBtdHUgMTUwMCBxZGlzYyBub3F1ZXVlIHN0YXRlIFVQIG1vZGUg REVGQVVMVDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4zMDogdm5ldDA6 ICZsdDtCUk9BRENBU1QsTVVMVElDQVNULFVQLExPV0VSX1VQJmd0OyBtdHUgMTUwMCBxZGlzYyBw Zmlmb19mYXN0IG1hc3RlciAyMDctbmV0IHN0YXRlIFVOS05PV04gbW9kZSBERUZBVUxUIHFsZW4g NTAwICZsdDsmbHQ7Jmx0OyB2ZXRoIGNvbm5lY3Rpb24gdG8gUHJveG1veCBWTTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4zMTogdm5ldDE6ICZsdDtCUk9BRENBU1QsTVVM VElDQVNULFVQLExPV0VSX1VQJmd0OyBtdHUgMTUwMCBxZGlzYyBwZmlmb19mYXN0IG1hc3RlciAy MDctbmV0IHN0YXRlIFVOS05PV04gbW9kZSBERUZBVUxUIHFsZW4gNTAwPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5bcm9vdEBvdmlydC1ub2RlLTAzIH5dIyBicmN0bCBzaG93PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmJyaWRnZSBuYW1lJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGJyaWRnZSBpZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTVFAgZW5hYmxl ZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbnRlcmZhY2VzPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjE2OS1uZXQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgODAwMC4wMDE1MTc3YmU5ZGEmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgbm8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYm9uZDAuMTY5PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjE4MC1uZXQmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgODAwMC4wMDE1MTc3YmU5ZGEmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbm8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYm9uZDAu MTgwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIwNy1uZXQmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgODAwMC4wMDE1MTc3YmU5 ZGEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbm8mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgYm9uZDAuMjA3PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt2bmV0MDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgdm5ldDE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+O3Zkc21kdW1teTsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgODAwMC4wMDAwMDAw MDAwMDAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbm88bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+b3ZpcnRtZ210Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDgwMDAuMDAyMTg1MzUwODZhJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IG5vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVucDEyczBmMDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPltyb290QG92aXJ0LW5vZGUtMDMgfl0jIHRjcGR1bXAgLWkgdm5ldDAgLXZ2diAtcyAx NTAwICcocG9ydCA2NyBvciBwb3J0IDY4KSc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+dGNwZHVtcDogV0FSTklORzogdm5ldDA6IG5vIElQdjQgYWRkcmVzcyBhc3NpZ25l ZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50Y3BkdW1wOiBsaXN0ZW5p bmcgb24gdm5ldDAsIGxpbmstdHlwZSBFTjEwTUIgKEV0aGVybmV0KSwgY2FwdHVyZSBzaXplIDE1 MDAgYnl0ZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTI6NTI6MDcu NjI4NTcxIElQICh0b3MgMHgxMCwgdHRsIDEyOCwgaWQgMCwgb2Zmc2V0IDAsIGZsYWdzIFtub25l XSwgcHJvdG8gVURQICgxNyksIGxlbmd0aCAzMjgpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyAwLjAuMC4wLmJvb3RwYyAmZ3Q7IDI1NS4y NTUuMjU1LjI1NS5ib290cHM6IFt1ZHAgc3VtIG9rXSBCT09UUC9ESENQLCBSZXF1ZXN0IGZyb20g MzI6NjI6NjU6NjE6NjU6MzMgKG91aSBVbmtub3duKSwgbGVuZ3RoIDMwMCwgeGlkIDB4OWVmYzQ4 NDksIHNlY3MgOTQsIEZsYWdzIFtub25lXSAoMHgwMDAwKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgQ2xpZW50LUV0aGVybmV0LUFkZHJlc3MgMzI6NjI6NjU6NjE6NjU6MzMg KG91aSBVbmtub3duKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBeXl5eXl5eXl5eXl5eXl5eXl5e Xl5eXl5eXl5eXl48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFZlbmRvci1y ZmMxMDQ4IEV4dGVuc2lvbnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IE1hZ2ljIENvb2tpZSAweDYzODI1MzYzPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBESENQLU1lc3NhZ2UgT3B0aW9uIDUzLCBsZW5ndGgg MTogRGlzY292ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEhvc3RuYW1lIE9wdGlvbiAxMiwgbGVuZ3RoIDU6ICZxdW90O3Rlc3QxJnF1b3Q7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtQYXJhbWV0ZXItUmVx dWVzdCBPcHRpb24gNTUsIGxlbmd0aCAxMzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFN1Ym5ldC1NYXNrLCBCUiwgVGltZS1ab25l LCBEZWZhdWx0LUdhdGV3YXk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERvbWFpbi1OYW1lLCBEb21haW4tTmFtZS1TZXJ2ZXIsIE9w dGlvbiAxMTksIEhvc3RuYW1lPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOZXRiaW9zLU5hbWUtU2VydmVyLCBOZXRiaW9zLVNjb3Bl LCBNVFUsIENsYXNzbGVzcy1TdGF0aWMtUm91dGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO05UUDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRU5EIE9wdGlvbiAyNTUsIGxlbmd0aCAwPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQQUQgT3B0aW9u IDAsIGxlbmd0aCAwLCBvY2N1cnMgMzQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5bcm9vdEBvdmlydC1ub2Rl LTAzIH5dIyBicmN0bCBzaG93bWFjcyAyMDctbmV0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPnBvcnQgbm8gbWFjIGFkZHImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgaXMgbG9jYWw/Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFnZWlu ZyB0aW1lcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgMSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwMDoxNToxNzo3YjplOTpkYSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB5ZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg MC4wMDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgMSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAwMDoxNToxNzo3YjplOTpkYSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB5ZXMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMC4w MDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgMyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAwMDoxYTo0YToxNjowMTo1NiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBubyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAw LjExDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7 MiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwMDoxYTo0YToxNjowMTo1NyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBubyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAwLjEzJm5ic3A7ICZsdDsmbHQ7IFByb3htb3ggVk0ncyBldGgwIE1BQyBsZWFybmVk PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAxJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDAwOjI0OjUwOmRkOmEyOjA1Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IG5vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEu MDU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IDEmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgMTg6MDM6NzM6ZTM6YmU6NWEmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgbm8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTk4Ljg3PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDE4OjAzOjczOmUzOmNhOjI0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG5vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDYwLjAxPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDE4OjAzOjczOmUzOmNiOjViJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IG5vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDY4LjI2PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDE4OjAzOjczOmUzOmNkOmI4Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG5vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQxLjM5PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDE4OjAzOjczOmUzOmQ0OjI2Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5v Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDU3LjI1PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE4 OjAzOjczOmUzOmQ1OjNkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEzMy41MzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxODowMzo3Mzpl NDoyMzowOCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBubyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzNC4yODxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxODowMzo3MzplNDoy NjoyZiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBubyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAyMC4xMDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxODowMzo3MzplNDoyYjo0 YyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBubyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAyMi40OTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxODowMzo3MzplNDo2YzoxOSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBubyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAxNC44NzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxODowMzo3MzplNDo3ZTowYSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBubyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA1NC40NjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxODowMzo3MzplODoxNjplMCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBubyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsyOC43MTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzNDoxNzplYjo5YjpmODplYSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBubyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAyMi40OTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsg MSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA0NDpkMzpjYTo3ZTozYzpmZiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBubyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAwLjYwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDc4OjJiOmNiOjNiOmNhOmI5Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIx Ny42NjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgMSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA3ODoyYjpjYjo5MjpjYjpjYiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBubyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxOTQuMTg8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IDEmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgNzg6MmI6Y2I6OTM6MDg6YTgmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgbm8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTAyLjQ5PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGI4OmNhOjNhOjdhOjcwOjYzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IG5vJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDQuMTk8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IDEmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZjg6YmM6MTI6Njk6YmI6YTMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgbm8mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTEwLjUyPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZl OjFhOjRhOjE2OjAxOjU2Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHllcyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwLjAwJm5ic3A7ICZsdDsmbHQ7Jmx0OyB2 ZXRoIGNvbm5lY3Rpb24gdG8gUHJveG1veCBWTSAodmV0aDApPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZlOjFh OjRhOjE2OjAxOjU2Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHllcyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDswLjAwPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyAyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZlOjFhOjRh OjE2OjAxOjU3Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHllcyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwLjAwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyAyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZlOjFhOjRhOjE2 OjAxOjU3Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHllcyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwLjAwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPihub3RpY2Ugbm8gb3RoZXIgZW50cmllcyBmb3IgcG9ydCAzIOKAkyBzaG91bGQg YmUgbGVhcm5pbmcgTUFDIDMyOjYyOjY1OjYxOjY1OjMzIGZyb20gaW5jb21pbmcgdHJhZmZpYyBv biB2bmV0MCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPj09PT09PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVXNlcnMgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlVzZXJzQG92aXJ0Lm9yZyI+VXNlcnNAb3Zp cnQub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9s aXN0aW5mby91c2VycyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFp bG1hbi9saXN0aW5mby91c2VyczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_F3282EEAFF180F43BAF1AD0A7C34739D3DA28Cnjmailneclabscom_--

7 20

Sanlock add Lockspace Errors
by InterNetX - Juergen Gotteswinter 04 Jun '16

04 Jun '16

Hi, since some time we get Error Messages from Sanlock, and so far i was not able to figure out what exactly they try to tell and more important if its something which can be ignored or needs to be fixed (and how). Here are the Versions we are using currently: Engine ovirt-engine-3.5.6.2-1.el6.noarch Nodes vdsm-4.16.34-0.el7.centos.x86_64 sanlock-3.2.4-1.el7.x86_64 libvirt-lock-sanlock-1.2.17-13.el7_2.3.x86_64 libvirt-daemon-1.2.17-13.el7_2.3.x86_64 libvirt-lock-sanlock-1.2.17-13.el7_2.3.x86_64 libvirt-1.2.17-13.el7_2.3.x86_64 -- snip -- May 30 09:55:27 vm2 sanlock[1094]: 2016-05-30 09:55:27+0200 294109 [60137]: verify_leader 2 wrong space name 4643f652-8014-4951-8a1a-02af41e67d08 f757b127-a951-4fa9-bf90-81180c0702e6 /dev/f757b127-a951-4fa9-bf90-81180c0702e6/ids May 30 09:55:27 vm2 sanlock[1094]: 2016-05-30 09:55:27+0200 294109 [60137]: leader1 delta_acquire_begin error -226 lockspace f757b127-a951-4fa9-bf90-81180c0702e6 host_id 2 May 30 09:55:27 vm2 sanlock[1094]: 2016-05-30 09:55:27+0200 294109 [60137]: leader2 path /dev/f757b127-a951-4fa9-bf90-81180c0702e6/ids offset 0 May 30 09:55:27 vm2 sanlock[1094]: 2016-05-30 09:55:27+0200 294109 [60137]: leader3 m 12212010 v 30003 ss 512 nh 0 mh 1 oi 2 og 8 lv 0 May 30 09:55:27 vm2 sanlock[1094]: 2016-05-30 09:55:27+0200 294109 [60137]: leader4 sn 4643f652-8014-4951-8a1a-02af41e67d08 rn 1eed8aa9-8fb5-4d27-8d1c-03ebce2c36d4.vm2.intern ts 3786679 cs 1474f033 May 30 09:55:28 vm2 sanlock[1094]: 2016-05-30 09:55:28+0200 294110 [1099]: s9703 add_lockspace fail result -226 May 30 09:55:58 vm2 sanlock[1094]: 2016-05-30 09:55:58+0200 294140 [60331]: verify_leader 2 wrong space name 4643f652-8014-4951-8a1a-02af41e67d08 f757b127-a951-4fa9-bf90-81180c0702e6 /dev/f757b127-a951-4fa9-bf90-81180c0702e6/ids May 30 09:55:58 vm2 sanlock[1094]: 2016-05-30 09:55:58+0200 294140 [60331]: leader1 delta_acquire_begin error -226 lockspace f757b127-a951-4fa9-bf90-81180c0702e6 host_id 2 May 30 09:55:58 vm2 sanlock[1094]: 2016-05-30 09:55:58+0200 294140 [60331]: leader2 path /dev/f757b127-a951-4fa9-bf90-81180c0702e6/ids offset 0 May 30 09:55:58 vm2 sanlock[1094]: 2016-05-30 09:55:58+0200 294140 [60331]: leader3 m 12212010 v 30003 ss 512 nh 0 mh 1 oi 2 og 8 lv 0 May 30 09:55:58 vm2 sanlock[1094]: 2016-05-30 09:55:58+0200 294140 [60331]: leader4 sn 4643f652-8014-4951-8a1a-02af41e67d08 rn 1eed8aa9-8fb5-4d27-8d1c-03ebce2c36d4.vm2.intern ts 3786679 cs 1474f033 May 30 09:55:59 vm2 sanlock[1094]: 2016-05-30 09:55:59+0200 294141 [1098]: s9704 add_lockspace fail result -226 May 30 09:56:05 vm2 sanlock[1094]: 2016-05-30 09:56:05+0200 294148 [1094]: s1527 check_other_lease invalid for host 0 0 ts 7566376 name in 4643f652-8014-4951-8a1a-02af41e67d08 May 30 09:56:05 vm2 sanlock[1094]: 2016-05-30 09:56:05+0200 294148 [1094]: s1527 check_other_lease leader 12212010 owner 1 11 ts 7566376 sn f757b127-a951-4fa9-bf90-81180c0702e6 rn f888524b-27aa-4724-8bae-051f9e950a21.vm1.intern May 30 09:56:28 vm2 sanlock[1094]: 2016-05-30 09:56:28+0200 294170 [60496]: verify_leader 2 wrong space name 4643f652-8014-4951-8a1a-02af41e67d08 f757b127-a951-4fa9-bf90-81180c0702e6 /dev/f757b127-a951-4fa9-bf90-81180c0702e6/ids May 30 09:56:28 vm2 sanlock[1094]: 2016-05-30 09:56:28+0200 294170 [60496]: leader1 delta_acquire_begin error -226 lockspace f757b127-a951-4fa9-bf90-81180c0702e6 host_id 2 May 30 09:56:28 vm2 sanlock[1094]: 2016-05-30 09:56:28+0200 294170 [60496]: leader2 path /dev/f757b127-a951-4fa9-bf90-81180c0702e6/ids offset 0 May 30 09:56:28 vm2 sanlock[1094]: 2016-05-30 09:56:28+0200 294170 [60496]: leader3 m 12212010 v 30003 ss 512 nh 0 mh 1 oi 2 og 8 lv 0 May 30 09:56:28 vm2 sanlock[1094]: 2016-05-30 09:56:28+0200 294170 [60496]: leader4 sn 4643f652-8014-4951-8a1a-02af41e67d08 rn 1eed8aa9-8fb5-4d27-8d1c-03ebce2c36d4.vm2.intern ts 3786679 cs 1474f033 May 30 09:56:29 vm2 sanlock[1094]: 2016-05-30 09:56:29+0200 294171 [6415]: s9705 add_lockspace fail result -226 May 30 09:56:58 vm2 sanlock[1094]: 2016-05-30 09:56:58+0200 294200 [60645]: verify_leader 2 wrong space name 4643f652-8014-4951-8a1a-02af41e67d08 f757b127-a951-4fa9-bf90-81180c0702e6 /dev/f757b127-a951-4fa9-bf90-81180c0702e6/ids May 30 09:56:58 vm2 sanlock[1094]: 2016-05-30 09:56:58+0200 294200 [60645]: leader1 delta_acquire_begin error -226 lockspace f757b127-a951-4fa9-bf90-81180c0702e6 host_id 2 May 30 09:56:58 vm2 sanlock[1094]: 2016-05-30 09:56:58+0200 294200 [60645]: leader2 path /dev/f757b127-a951-4fa9-bf90-81180c0702e6/ids offset 0 May 30 09:56:58 vm2 sanlock[1094]: 2016-05-30 09:56:58+0200 294200 [60645]: leader3 m 12212010 v 30003 ss 512 nh 0 mh 1 oi 2 og 8 lv 0 May 30 09:56:58 vm2 sanlock[1094]: 2016-05-30 09:56:58+0200 294200 [60645]: leader4 sn 4643f652-8014-4951-8a1a-02af41e67d08 rn 1eed8aa9-8fb5-4d27-8d1c-03ebce2c36d4.vm2.intern ts 3786679 cs 1474f033 May 30 09:56:59 vm2 sanlock[1094]: 2016-05-30 09:56:59+0200 294201 [6373]: s9706 add_lockspace fail result -226 May 30 09:57:28 vm2 sanlock[1094]: 2016-05-30 09:57:28+0200 294230 [60806]: verify_leader 2 wrong space name 4643f652-8014-4951-8a1a-02af41e67d08 f757b127-a951-4fa9-bf90-81180c0702e6 /dev/f757b127-a951-4fa9-bf90-81180c0702e6/ids May 30 09:57:28 vm2 sanlock[1094]: 2016-05-30 09:57:28+0200 294230 [60806]: leader1 delta_acquire_begin error -226 lockspace f757b127-a951-4fa9-bf90-81180c0702e6 host_id 2 May 30 09:57:28 vm2 sanlock[1094]: 2016-05-30 09:57:28+0200 294230 [60806]: leader2 path /dev/f757b127-a951-4fa9-bf90-81180c0702e6/ids offset 0 May 30 09:57:28 vm2 sanlock[1094]: 2016-05-30 09:57:28+0200 294230 [60806]: leader3 m 12212010 v 30003 ss 512 nh 0 mh 1 oi 2 og 8 lv 0 May 30 09:57:28 vm2 sanlock[1094]: 2016-05-30 09:57:28+0200 294230 [60806]: leader4 sn 4643f652-8014-4951-8a1a-02af41e67d08 rn 1eed8aa9-8fb5-4d27-8d1c-03ebce2c36d4.vm2.intern ts 3786679 cs 1474f033 May 30 09:57:29 vm2 sanlock[1094]: 2016-05-30 09:57:29+0200 294231 [6399]: s9707 add_lockspace fail result -226 May 30 09:57:58 vm2 sanlock[1094]: 2016-05-30 09:57:58+0200 294260 [60946]: verify_leader 2 wrong space name 4643f652-8014-4951-8a1a-02af41e67d08 f757b127-a951-4fa9-bf90-81180c0702e6 /dev/f757b127-a951-4fa9-bf90-81180c0702e6/ids May 30 09:57:58 vm2 sanlock[1094]: 2016-05-30 09:57:58+0200 294260 [60946]: leader1 delta_acquire_begin error -226 lockspace f757b127-a951-4fa9-bf90-81180c0702e6 host_id 2 May 30 09:57:58 vm2 sanlock[1094]: 2016-05-30 09:57:58+0200 294260 [60946]: leader2 path /dev/f757b127-a951-4fa9-bf90-81180c0702e6/ids offset 0 May 30 09:57:58 vm2 sanlock[1094]: 2016-05-30 09:57:58+0200 294260 [60946]: leader3 m 12212010 v 30003 ss 512 nh 0 mh 1 oi 2 og 8 lv 0 May 30 09:57:58 vm2 sanlock[1094]: 2016-05-30 09:57:58+0200 294260 [60946]: leader4 sn 4643f652-8014-4951-8a1a-02af41e67d08 rn 1eed8aa9-8fb5-4d27-8d1c-03ebce2c36d4.vm2.intern ts 3786679 cs 1474f033 May 30 09:57:59 vm2 sanlock[1094]: 2016-05-30 09:57:59+0200 294261 [6352]: s9708 add_lockspace fail result -226 -- snip -- sanlock log_dump also shows errors -- snip -- 2016-05-30 09:53:23+0200 7526415 [1017]: s567 check_other_lease invalid for host 0 0 ts 7566376 name in 4643f652-8014-4951-8a1a-02af41e67d08 2016-05-30 09:53:23+0200 7526415 [1017]: s567 check_other_lease leader 12212010 owner 1 11 ts 7566376 sn f757b127-a951-4fa9-bf90-81180c0702e6 rn f888524b-27aa-4724-8bae-051f9e950a21.vm1.intern 2016-05-30 09:53:33+0200 7526425 [1017]: s568 check_other_lease invalid for host 0 0 ts 3786679 name in f757b127-a951-4fa9-bf90-81180c0702e6 2016-05-30 09:53:33+0200 7526425 [1017]: s568 check_other_lease leader 12212010 owner 2 8 ts 3786679 sn 4643f652-8014-4951-8a1a-02af41e67d08 rn 1eed8aa9-8fb5-4d27-8d1c-03ebce2c36d4.vm2.intern 2016-05-30 09:53:33+0200 7526425 [1017]: s568 check_other_lease invalid for host 0 0 ts 6622415 name in f757b127-a951-4fa9-bf90-81180c0702e6 2016-05-30 09:53:33+0200 7526425 [1017]: s568 check_other_lease leader 12212010 owner 3 14 ts 6622415 sn 4643f652-8014-4951-8a1a-02af41e67d08 rn 51c8f8e2-f9d8-462c-866c-e4052213ea81.vm3.intern 2016-05-30 09:53:33+0200 7526425 [1017]: s568 check_other_lease invalid for host 0 0 ts 6697413 name in f757b127-a951-4fa9-bf90-81180c0702e6 2016-05-30 09:53:33+0200 7526425 [1017]: s568 check_other_lease leader 12212010 owner 4 4 ts 6697413 sn 4643f652-8014-4951-8a1a-02af41e67d08 rn 8d4f32dc-f595-4254-bfcb-d96e5057e110.vm4.intern 2016-05-30 09:53:33+0200 7526425 [1017]: s568 check_other_lease invalid for host 0 0 ts 7563413 name in f757b127-a951-4fa9-bf90-81180c0702e6 2016-05-30 09:53:33+0200 7526425 [1017]: s568 check_other_lease leader 12212010 owner 5 8 ts 7563413 sn 4643f652-8014-4951-8a1a-02af41e67d08 rn 9fe564e6-cf40-4403-9fc0-eb118e1ee2cf.vm5.intern 2016-05-30 09:53:33+0200 7526425 [1017]: s568 check_other_lease invalid for host 0 0 ts 6129706 name in f757b127-a951-4fa9-bf90-81180c0702e6 2016-05-30 09:53:33+0200 7526425 [1017]: s568 check_other_lease leader 12212010 owner 6 169 ts 6129706 sn 4643f652-8014-4951-8a1a-02af41e67d08 rn b99ff588-f1ad-43f2-bd6c-6869f54d424d.vm1-tiny.i 2016-05-30 09:53:47+0200 7526439 [14576]: cmd_read_resource 23,58 /dev/c2212f15-35b7-4fa0-b13c-b50befda0af9/leases:1048576 -- snip -- any hint whould be highly appreciated Juergen

4 8

Moving Hosted Engine NFS storage domain
by Staniforth, Paul 03 Jun '16

03 Jun '16

--_000_146469435394125237leedsbeckettacuk_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, we would like to move our NFS storage used for the HostedEngine. Plan would be * enable global maintenance * shut-down HostedEngine VM * edit /etc/ovirt-hosted-engine/hosted-engine.conf on hosts * storage=3Dnewnfs:/newnfsvolume * copy storage domain from old to new nfs server * start HostedEngine VM * run engine-setup on HostedEngine VM * disable global maintenance Has anyone had any experience doing this? Have I missed any steps out we are currently running oVirt 3.6.2 Thanks, Paul S. To view the terms under which this email is distributed, please go to:- http://disclaimer.leedsbeckett.ac.uk/disclaimer/disclaimer.html --_000_146469435394125237leedsbeckettacuk_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none"></style> </head> <body dir=3D"ltr" style=3D"font-size:12pt;color:#000000;background-color:#F= FFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;"> Hello,          we would like to move our NFS storage = used for the HostedEngine. Plan would be <ul> <li>enable global maintenance</li><li>shut-down HostedEngine VM</li><li>edi= t  /etc/ovirt-hosted-engine/hosted-engine.conf on hosts <ul> <li>storage=3Dnewnfs:/newnfsvolume</li></ul> </li><li>copy storage domain from old to new nfs server</li><li>start Hoste= dEngine VM</li><li>run engine-setup on HostedEngine VM</li><li>disable glob= al maintenance</li></ul> Has anyone had any experience doing this?  Have I missed any steps out we are currently running oVirt 3.6.2 Thanks,               Paul S. To view the terms under which this email is distributed, please go to:- <br= > <a href=3D"http://disclaimer.leedsbeckett.ac.uk/disclaimer/disclaimer.html"= target=3D"_blank">http://disclaimer.leedsbeckett.ac.uk/disclaimer/disclaim= er.html</a> </body> </html> --_000_146469435394125237leedsbeckettacuk_--

5 13

Could not associate gluster brick with correct network warning
by Roderick Mooi 03 Jun '16

03 Jun '16

Good day I've setup a "Gluster Management" network in DC, cluster and all hosts. It is appearing as "operational" in the cluster and all host networks look correct. But I'm seeing this warning continually in the engine.log: 2016-05-27 08:56:58,988 WARN [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc] (DefaultQuartzScheduler_Worker-80) [] Could not associate brick 'glustermount.host1:/gluster/data/brick' of volume '7a25d2fb-1048-48d8-a26d-f288ff0e28cb' with correct network as no gluster network found in cluster '00000002-0002-0002-0002-0000000002b8' This is on ovirt 3.6.5. Can anyone assist? Thanks, Roderick Mooi Senior Engineer: South African National Research Network (SANReN) Meraka Institute, CSIR roderick(a)sanren.ac.za | +27 12 841 4111 | www.sanren.ac.za

2 3

Re: [ovirt-users] How to automate the ovirt host deployment?
by Karli Sjöberg 02 Jun '16

02 Jun '16

--_000_b46676c014da475aa45e7caed4236228Exch23sluse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMzAgbWFqIDIwMTYgMjI6MjIgc2tyZXYgQXJtYW4gS2hhbGF0eWFuIDxhcm0yYXJtQGdt YWlsLmNvbT46DQo+DQo+IFNvcnJ5IGZvciB0aGUgcHJldmlvdXMgZW1wdHkgZW1haWwuDQo+DQo+ IEkgd2FzIHRlc3RpbmcgZm9yZW1hbiBwbHVnaW5zIGZvciBvdmlydCBkZXBsb3kuIFRoZXkgYXJl IHNvbWUgaG93IGJyb2tlbi4gVGhlIGZvcmVtYW4taW5zdGFsbCAtLWVuYWJsZS1vdmlydC1wcm92 aXNpb25pbmctcGx1Z2luIGJyZWFrcyB0aGUgZm9yZW1hbiBpbnN0YWxsYXRpb24uIEkgbmVlZCB0 byBkaWcgZGVlcGVyOigNCg0KRG9uJ3Qga25vdyB3aGF0IGRpc3RyaWJ1dGlvbiB5b3UncmUgdXNp bmcgYnV0IHNldHRpbmcgYWxsIHVwIG1hbnVhbGx5IHNob3dlZCBtZSB0aGF0IEZvcmVtYW4gbmVl ZHMgdG8gYmUgYXQgYXQgbGVhc3QgMTEgZm9yIHRoZSBwbHVnaW4gdG8gd29yay4gT3RoZXJ3aXNl IGl0IGJlaGF2ZWQgaW4gdGhlIHNhbWUgd2F5IGZvciBtZTsgYWxsIGZpbmUgYW5kIHdlbGwgdW50 aWwgdGhlIHByb3Zpc2lvbiBwbHVnaW4gd2FzIGluc3RhbGxlZCBhbmQgdGhlbiAqc2FkZmFjZSog OikNCg0KR2V0IEZvcmVtYW4gdXAgdG8gdmVyc2lvbiAxMSBhbmQgeW91J2xsIGJlIGZpbmUsIGlz IG15IGd1ZXNzLg0KDQovSw0KPg0KPiBBbSAyOC4wNS4yMDE2IDQ6MDcgbmFjaG0uIHNjaHJpZWIg Illhbml2IEthdWwiIDx5a2F1bEByZWRoYXQuY29tPjoNCj4+DQo+PiA+DQo+DQo+ID4NCj4gPg0K PiA+IE9uIFNhdCwgTWF5IDI4LCAyMDE2IGF0IDEyOjUwIFBNLCBBcm1hbiBLaGFsYXR5YW4gPGFy bTJhcm1AZ21haWwuY29tPiB3cm90ZToNCj4+DQo+PiA+Pg0KPg0KPiA+PiBUaGFuayB5b3UgZm9y IHRoZSBoaW50LiBJIHdpbGwgdHJ5IG5leHQgd2Vlay4NCj4gPj4gRm9yZW1hbiBsb29rcyBxdWl0 ZSBjb21wbGV4OikNCj4gPg0KPiA+DQo+ID4gSSB0aGluayB0aGlzIGlzIGFuIGV4Y2VsbGVudCBz dWdnZXN0aW9uIC0gRm9yZW1hbiwgd2hpbGUgbWF5IHRha2UgYSB3aGlsZSB0byBzZXQgdXAsIHdp bGwgYWxzbyBiZSBleHRyZW1lbHkgdXNlZnVsIHRvIHByb3Zpc2lvbiBhbmQgbWFuYWdlIG5vdCBv bmx5IGhvc3RzLCBidXQgVk1zIGxhdGVyIG9uIQ0KPiA+DQo+Pg0KPj4gPj4gSSB3b3VsZCBwcmVm ZXIgc2ltcGxlIFB5dGhvbiBzY3JpcHQgd2l0aCA0IGxpbmVzOiBhZGQsIGluc3RhbGwsIHNldHVw IG5ldHdvcmtzIGFuZCBhY3RpdmF0ZS4NCj4NCj4NCj4gPg0KPiA+DQo+ID4gWW91IGNhbiBsb29r IGF0IG92aXJ0LXN5c3RlbS10ZXN0cyAsIHRoZSB0ZXN0aW5nIHN1aXRlIGZvciBvVmlydCwgb24g UHl0aG9uIGNvZGUgZm9yIHRoZSBhYm92ZS4NCj4gPiBZLg0KPiA+DQo+Pg0KPj4NCj4gPj4NCj4g Pj4gQW0gMjcuMDUuMjAxNiA2OjUxIG5hY2htLiBzY2hyaWViICJLYXJsaSBTasO2YmVyZyIgPGth cmxpLnNqb2JlcmdAc2x1LnNlPjoNCj4+DQo+PiA+Pj4NCj4NCj4gPj4+DQo+ID4+PiBEZW4gMjcg bWFqIDIwMTYgMTg6NDEgc2tyZXYgQXJtYW4gS2hhbGF0eWFuIDxhcm0yYXJtQGdtYWlsLmNvbT46 DQo+ID4+PiA+DQo+ID4+PiA+IEhpLCBJIGFtIGxvb2tpbmcgc29tZSBtZXRob2QgdG8gYXV0b21h dGUgdGhlIGhvc3QgZGVwbG95bWVudHMgaW4gYSBjbHVzdGVyIGVudmlyb25tZW50Lg0KPiA+Pj4g PiBBc3N1bWluZyB3ZSBoYXZlIDIwIG5vZGVzIHdpdGggY2VudG9zIDcgZXRoMC9ldGgxIGNvbmZp Z3VyZWQuIElzIGl0IHBvc3NpYmxlIHRvIGF1dG9tYXRlIGluc3RhbGxhdGlvbiB3aXRoIG92aXJ0 LXNkaz8NCj4gPj4+ID4gQXJlIHRoZXJlIHNvbWUgZXhhbXBsZXMgID8NCj4gPj4+DQo+ID4+PiBZ b3UgY291bGQgZG8gdGhhdCwgb3IgbG9vayBpbnRvIGZ1bGwgbGlmZSBjeWNsZSBtYW5hZ2VtZW50 IHdpdGggVGhlIEZvcmVtYW4uDQo+ID4+Pg0KPiA+Pj4gL0sNCj4gPj4+DQo+ID4+PiA+DQo+ID4+ PiA+IFRoYW5rcywNCj4gPj4+ID4gQXJtYW4uDQo+ID4+DQo+ID4+DQo+ID4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IFVzZXJzIG1haWxpbmcg bGlzdA0KPiA+PiBVc2Vyc0BvdmlydC5vcmcNCj4gPj4gaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9t YWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo+ID4+DQo+ID4NCg== --_000_b46676c014da475aa45e7caed4236228Exch23sluse_ Content-Type: text/html; charset="utf-8" Content-ID: <4E9A92F418B0C3438B9F735F24DCDD5A(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAzMCBtYWogMjAxNiAyMjoyMiBza3JldiBBcm1hbiBLaGFsYXR5YW4gJmx0O2Fy bTJhcm1AZ21haWwuY29tJmd0Ozo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBTb3JyeSBmb3IgdGhlIHBy ZXZpb3VzIGVtcHR5IGVtYWlsLjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgd2FzIHRlc3RpbmcgZm9y ZW1hbiBwbHVnaW5zIGZvciBvdmlydCBkZXBsb3kuIFRoZXkgYXJlIHNvbWUgaG93IGJyb2tlbi4g VGhlIGZvcmVtYW4taW5zdGFsbCAtLWVuYWJsZS1vdmlydC1wcm92aXNpb25pbmctcGx1Z2luIGJy ZWFrcyB0aGUgZm9yZW1hbiBpbnN0YWxsYXRpb24uIEkgbmVlZCB0byBkaWcgZGVlcGVyOig8L3A+ DQo8cCBkaXI9Imx0ciI+RG9uJ3Qga25vdyB3aGF0IGRpc3RyaWJ1dGlvbiB5b3UncmUgdXNpbmcg YnV0IHNldHRpbmcgYWxsIHVwIG1hbnVhbGx5IHNob3dlZCBtZSB0aGF0IEZvcmVtYW4gbmVlZHMg dG8gYmUgYXQgYXQgbGVhc3QgMTEgZm9yIHRoZSBwbHVnaW4gdG8gd29yay4gT3RoZXJ3aXNlIGl0 IGJlaGF2ZWQgaW4gdGhlIHNhbWUgd2F5IGZvciBtZTsgYWxsIGZpbmUgYW5kIHdlbGwgdW50aWwg dGhlIHByb3Zpc2lvbiBwbHVnaW4gd2FzIGluc3RhbGxlZA0KIGFuZCB0aGVuICpzYWRmYWNlKiA6 KTwvcD4NCjxwIGRpcj0ibHRyIj5HZXQgRm9yZW1hbiB1cCB0byB2ZXJzaW9uIDExIGFuZCB5b3Un bGwgYmUgZmluZSwgaXMgbXkgZ3Vlc3MuPC9wPg0KPHAgZGlyPSJsdHIiPi9LPGJyPg0KJmd0Ozxi cj4NCiZndDsgQW0gMjguMDUuMjAxNiA0OjA3IG5hY2htLiBzY2hyaWViICZxdW90O1lhbml2IEth dWwmcXVvdDsgJmx0O3lrYXVsQHJlZGhhdC5jb20mZ3Q7Ojxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgT24gU2F0LCBNYXkgMjgsIDIwMTYgYXQgMTI6NTAgUE0sIEFybWFuIEtoYWxhdHlh biAmbHQ7YXJtMmFybUBnbWFpbC5jb20mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgJmd0OyZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaGFuayB5b3UgZm9y IHRoZSBoaW50LiBJIHdpbGwgdHJ5IG5leHQgd2Vlay4gPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBGb3Jl bWFuIGxvb2tzIHF1aXRlIGNvbXBsZXg6KTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBJIHRoaW5rIHRoaXMgaXMgYW4gZXhjZWxsZW50IHN1Z2dlc3Rpb24gLSBG b3JlbWFuLCB3aGlsZSBtYXkgdGFrZSBhIHdoaWxlIHRvIHNldCB1cCwgd2lsbCBhbHNvIGJlIGV4 dHJlbWVseSB1c2VmdWwgdG8gcHJvdmlzaW9uIGFuZCBtYW5hZ2Ugbm90IG9ubHkgaG9zdHMsIGJ1 dCBWTXMgbGF0ZXIgb24hPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7Jmd0OyBJIHdvdWxkIHByZWZlciBzaW1wbGUgUHl0aG9uIHNjcmlwdCB3aXRoIDQgbGlu ZXM6IGFkZCwgaW5zdGFsbCwgc2V0dXAgbmV0d29ya3MgYW5kIGFjdGl2YXRlLjxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFlv dSBjYW4gbG9vayBhdCBvdmlydC1zeXN0ZW0tdGVzdHMgLCB0aGUgdGVzdGluZyBzdWl0ZSBmb3Ig b1ZpcnQsIG9uIFB5dGhvbiBjb2RlIGZvciB0aGUgYWJvdmUuPGJyPg0KJmd0OyAmZ3Q7IFkuPGJy Pg0KJmd0OyAmZ3Q7ICZuYnNwOzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBBbSAyNy4wNS4yMDE2IDY6NTEgbmFjaG0uIHNj aHJpZWIgJnF1b3Q7S2FybGkgU2rDtmJlcmcmcXVvdDsgJmx0O2thcmxpLnNqb2JlcmdAc2x1LnNl Jmd0Ozo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IERlbiAyNyBtYWog MjAxNiAxODo0MSBza3JldiBBcm1hbiBLaGFsYXR5YW4gJmx0O2FybTJhcm1AZ21haWwuY29tJmd0 Ozo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgJmd0 OyBIaSwgSSBhbSBsb29raW5nIHNvbWUgbWV0aG9kIHRvIGF1dG9tYXRlIHRoZSBob3N0IGRlcGxv eW1lbnRzIGluIGEgY2x1c3RlciBlbnZpcm9ubWVudC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyAm Z3Q7IEFzc3VtaW5nIHdlIGhhdmUgMjAgbm9kZXMgd2l0aCBjZW50b3MgNyBldGgwL2V0aDEgY29u ZmlndXJlZC4gSXMgaXQgcG9zc2libGUgdG8gYXV0b21hdGUgaW5zdGFsbGF0aW9uIHdpdGggb3Zp cnQtc2RrPzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7ICZndDsgQXJlIHRoZXJlIHNvbWUgZXhhbXBs ZXMmbmJzcDsgPzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsg WW91IGNvdWxkIGRvIHRoYXQsIG9yIGxvb2sgaW50byBmdWxsIGxpZmUgY3ljbGUgbWFuYWdlbWVu dCB3aXRoIFRoZSBGb3JlbWFuLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsgL0s8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyAmZ3Q7IFRoYW5rcywgPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsgJmd0OyBBcm1hbi48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQomZ3Q7ICZndDsmZ3Q7IFVzZXJzIG1haWxpbmcgbGlzdDxicj4NCiZn dDsgJmd0OyZndDsgVXNlcnNAb3ZpcnQub3JnPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBodHRwOi8vbGlz dHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnM8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KPC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_b46676c014da475aa45e7caed4236228Exch23sluse_--

2 2

how to come back to the list of available vms in serial console
by Nathanaël Blanchet 02 Jun '16

02 Jun '16

Hello, I can sucessfully connect to the serial console prompt, then I choose the vm to login in. When logout of this vm, I'm stuck on the login banner of this vm, and I didn't find any way to come back to the menu, or any other way rather from closing the terminal tab to exit. Is there a way to do this? Thank you. -- Nathanaël Blanchet Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet(a)abes.fr

3 3

Ovirt Engine - Wait For Launch
by Maton, Brett 01 Jun '16

01 Jun '16

I did a yum update on one of my Ovirt Hosts a few days ago. All of the VM's on that host have been shown in the web UI with a status of 'Wait For Launch'. The VM's all appear to still be up and running but I can't manage/migrate them. Is there anything I can do to clear this issue ? Regards, Brett

2 1

dwhd error: host_interface_samples_history_pkey
by Bill James 31 May '16

31 May '16

Ovirt events keeps saying "ETL service sampling has encountered an error. Please consult the service log for more details." ovirt-engine-dwhd.log says: 2016-05-27 10:55:00|UWxd1W|48u96S|MjrqV0|OVIRT_ENGINE_DWH|StatisticsSync|Default|6|Java Exception|tJDBCOutput_4|org.postgresql.util.PSQLException:ERROR: root page 3 of index "host_interface_samples_history_pkey" has level 0, expected 1|1 Exception in component tJDBCOutput_3 org.postgresql.util.PSQLException: ERROR: current transaction is aborted, commands ignored until end of transaction block at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2157) (see attached) I double checked all my VMs, they all have an interface assigned. Not sure what host_interface_samples_history_pkey is referring to. Thanks.

2 2

What recovers a VM from pause?
by Nicolas Ecarnot 31 May '16

31 May '16

Hello, We're planning a move from our old building towards a new one a few meters away. In a similar way of Martijn (https://www.mail-archive.com/users@ovirt.org/msg33182.html) I have maintenance planed on our storage side. Say an oVirt DC is using a SAN's LUN via iSCSI (Equallogic). This SAN allows me to setup block replication between two SANs, seen by oVirt as one (Dell is naming it SyncRep). Then switch all the iSCSI accesses to the replicated LUN. When doing this, the iSCSI stack of each oVirt host notices the de-connection, tries to reconnect, and succeeds. Amongst our hosts, this happens between 4 and 15 seconds. When this happens fast enough, oVirt engine and the VMs don't even notice, and they keep running happily. When this takes more than 4 seconds, there are 2 cases : 1 - The hosts and/or oVirt and/or the SPM (I actually don't know) notices that there is a storage failure, and pauses the VMs. When the iSCSI stack reconnects, the VMs are automatically recovered from pause, and this all takes less than 30 seconds. That is very acceptable for us, as this action is extremely rare. 2 - Same storage failure, VMs paused, and some VMs stay in pause mode forever. Manual "run" action is mandatory. When done, everything recovers correctly. This is also quite acceptable, but here come my questions : My questions : (!) - *WHAT* process or piece of code or what oVirt parts is responsible for deciding when to UN-pause a VM, and at what conditions? That would help me to understand why some cases are working even more smoothly than others. - Are there related timeouts I could play with in engine-config options? - [a bit off-topic] Is it safe to increase some iSCSI timeouts of buffer-sizes in the hope this kind of disconnection would get un-noticed? -- Nicolas ECARNOT

6 8

Re: [ovirt-users] How to automate the ovirt host deployment?
by Karli Sjöberg 31 May '16

31 May '16

--_000_5cb4511117cb4aa3aa76ec7ff6744b52Exch23sluse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMjcgbWFqIDIwMTYgMTg6NDEgc2tyZXYgQXJtYW4gS2hhbGF0eWFuIDxhcm0yYXJtQGdt YWlsLmNvbT46DQo+DQo+IEhpLCBJIGFtIGxvb2tpbmcgc29tZSBtZXRob2QgdG8gYXV0b21hdGUg dGhlIGhvc3QgZGVwbG95bWVudHMgaW4gYSBjbHVzdGVyIGVudmlyb25tZW50Lg0KPiBBc3N1bWlu ZyB3ZSBoYXZlIDIwIG5vZGVzIHdpdGggY2VudG9zIDcgZXRoMC9ldGgxIGNvbmZpZ3VyZWQuIElz IGl0IHBvc3NpYmxlIHRvIGF1dG9tYXRlIGluc3RhbGxhdGlvbiB3aXRoIG92aXJ0LXNkaz8NCj4g QXJlIHRoZXJlIHNvbWUgZXhhbXBsZXMgID8NCg0KWW91IGNvdWxkIGRvIHRoYXQsIG9yIGxvb2sg aW50byBmdWxsIGxpZmUgY3ljbGUgbWFuYWdlbWVudCB3aXRoIFRoZSBGb3JlbWFuLg0KDQovSw0K DQo+DQo+IFRoYW5rcywNCj4gQXJtYW4uDQo= --_000_5cb4511117cb4aa3aa76ec7ff6744b52Exch23sluse_ Content-Type: text/html; charset="utf-8" Content-ID: <9AAA3C04BA12E7489FD0F9CF918A616E(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAyNyBtYWogMjAxNiAxODo0MSBza3JldiBBcm1hbiBLaGFsYXR5YW4gJmx0O2Fy bTJhcm1AZ21haWwuY29tJmd0Ozo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSwgSSBhbSBsb29raW5n IHNvbWUgbWV0aG9kIHRvIGF1dG9tYXRlIHRoZSBob3N0IGRlcGxveW1lbnRzIGluIGEgY2x1c3Rl ciBlbnZpcm9ubWVudC48YnI+DQomZ3Q7IEFzc3VtaW5nIHdlIGhhdmUgMjAgbm9kZXMgd2l0aCBj ZW50b3MgNyBldGgwL2V0aDEgY29uZmlndXJlZC4gSXMgaXQgcG9zc2libGUgdG8gYXV0b21hdGUg aW5zdGFsbGF0aW9uIHdpdGggb3ZpcnQtc2RrPzxicj4NCiZndDsgQXJlIHRoZXJlIHNvbWUgZXhh bXBsZXMmbmJzcDsgPzwvcD4NCjxwIGRpcj0ibHRyIj5Zb3UgY291bGQgZG8gdGhhdCwgb3IgbG9v ayBpbnRvIGZ1bGwgbGlmZSBjeWNsZSBtYW5hZ2VtZW50IHdpdGggVGhlIEZvcmVtYW4uPC9wPg0K PHAgZGlyPSJsdHIiPi9LPC9wPg0KPHAgZGlyPSJsdHIiPiZndDs8YnI+DQomZ3Q7IFRoYW5rcywg PGJyPg0KJmd0OyBBcm1hbi48L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5cb4511117cb4aa3aa76ec7ff6744b52Exch23sluse_--

5 6

Can't perform search after setting up an Active Directory
by Alexis HAUSER 31 May '16

31 May '16

Hi, I added an Active Directory server to RHEV, but I can't perform any search and I don't see any namespace in the interface. I'm able to perform search using with the same search user DN / passwd and certificate : LDAPTLS_CACERT=/somewhere/myca.pem ldapsearch -H ldaps://myserver.com -x -D 'CN=Something,DC=myserver,DC=come' -w 'mypaswd' -b 'CN=users,DC=something,DC=com' in the engine.log, if I grep warn, I can see the following messages : 2016-05-25 05:54:55,840 WARN [org.ovirt.engine.core.bll.SearchQuery] (ajp-/127.0.0.1:8702-3) [] Illegal search: ADUSER@AD-authz:undefined: allnames=*: null 2016-05-25 05:54:55,843 WARN [org.ovirt.engine.core.bll.SearchQuery] (ajp-/127.0.0.1:8702-3) [] Illegal search: ADGROUP@AD-authz:undefined: name=*: null 2016-05-25 05:54:58,160 WARN [org.ovirt.engine.core.bll.SearchQuery] (ajp-/127.0.0.1:8702-9) [] Illegal search: ADUSER@AD-authz:undefined: allnames=*: null 2016-05-25 05:54:58,162 WARN [org.ovirt.engine.core.bll.SearchQuery] (ajp-/127.0.0.1:8702-9) [] Illegal search: ADGROUP@AD-authz:undefined: name=*: null I also tried adding the following configuration but it didn't solve my problem : sequence-init.init.100-my-basedn-init-vars = my-basedn-init-vars sequence.my-basedn-init-vars.010.description = set baseDN sequence.my-basedn-init-vars.010.type = var-set sequence.my-basedn-init-vars.010.var-set.variable = simple_baseDN sequence.my-basedn-init-vars.010.var-set.value = CN=Users,DC=something,DC=com Any ideas ? By the way, if I didn't rename my .profile and auth* files from my LDAP configuration, I had the LDAP namespace suggested by the web interface in my AD domain when trying to perform a search. Is that a bug ?

3 29

listing domains fails
by Fabrice Bacchella 31 May '16

31 May '16

--Apple-Mail=_943A44EE-DB36-4E2B-A9A5-F7AE7F010E4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm trying to list domains using the api, and I'm getting a strange = message : > GET /api/storagedomains;case_sensitive=3DTrue HTTP/1.1 ... > Version: 3 > Content-Type: application/xml > Accept: application/xml > Filter: False > Prefer: persistent-auth > Content-Length: 0 < HTTP/1.1 404 Not Found < <?xml version=3D"1.0" encoding=3D"UTF-8" standalone=3D"yes"?> < <fault> < <reason>Operation Failed</reason> < <detail>Entity not found: Storage server connection: = id=3D6860d96f-557e-4d82-a209-401d72bd6e16</detail> < </fault> And in engine.log, I got: Before: 2016-05-30 13:07:31,017 INFO = [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStorageServerVDSComma= nd] (default task-25) [4c2e1822] START, = DisconnectStorageServerVDSCommand(HostName =3D ng320, = StorageServerConnectionManagementVDSParameters:{runAsync=3D'true', = hostId=3D'4426ed42-0805-43b1-92d9-3e5a680eaf38', = storagePoolId=3D'00000000-0000-0000-0000-000000000000', = storageType=3D'LOCALFS', = connectionList=3D'[StorageServerConnections:{id=3D'6860d96f-557e-4d82-a209= -401d72bd6e16', connection=3D'/data/ovirt/data', iqn=3D'null', = vfsType=3D'null', mountOptions=3D'null', nfsVersion=3D'null', = nfsRetrans=3D'null', nfsTimeo=3D'null', iface=3D'null', = netIfaceName=3D'null'}]'}), log id: 63f890 ... 2016-05-30 13:07:32,312 INFO = [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStorageServerVDSComma= nd] (default task-25) [4c2e1822] FINISH, = DisconnectStorageServerVDSCommand, return: = {6860d96f-557e-4d82-a209-401d72bd6e16=3D0}, log id: 63f890 When I run the command: 2016-05-31 15:34:11,259 ERROR = [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default = task-13) [] Operation Failed: Entity not found: Storage server = connection: id=3D6860d96f-557e-4d82-a209-401d72bd6e16 What's wrong ?= --Apple-Mail=_943A44EE-DB36-4E2B-A9A5-F7AE7F010E4A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D"">I'm trying to list domains using the api, and I'm getting a = strange message :<div class=3D""> </div><div class=3D""><div= style=3D"margin: 0px;" class=3D"">> GET = /api/storagedomains;case_sensitive=3DTrue = HTTP/1.1</div></div><div class=3D"">...</div><div class=3D""><div= style=3D"margin: 0px;" class=3D"">> Version: 3</div><div = style=3D"margin: 0px;" class=3D"">> Content-Type: application/xml</div><div = style=3D"margin: 0px;" class=3D"">> Accept: application/xml</div><div = style=3D"margin: 0px;" class=3D"">> Filter: False</div><div style=3D"margin: = 0px;" class=3D"">> Prefer: persistent-auth</div><div style=3D"margin: = 0px;" class=3D"">> Content-Length: 0</div></div><div class=3D""> </div><div class=3D""><div style=3D"margin: 0px;" = class=3D""><= HTTP/1.1 404 Not Found</div></div><div class=3D""><div = style=3D"margin: 0px;" class=3D"">< <?xml version=3D"1.0" encoding=3D"UTF-8" = standalone=3D"yes"?></div><div style=3D"margin: 0px;" = class=3D""><= <fault></div><div style=3D"margin: 0px;" class=3D""><     = <reason>Operation Failed</reason></div><div = style=3D"margin: 0px;" class=3D""><     <detail>Entity not found: = Storage server connection: = id=3D6860d96f-557e-4d82-a209-401d72bd6e16</detail></div><div = style=3D"margin: 0px;" class=3D"">< </fault></div></div><div = class=3D""> </div><div class=3D"">And in engine.log, I = got:</div><div class=3D"">Before:</div><div class=3D"">2016-05-30 13:07:31,017 = INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStora= geServerVDSCommand] (default task-25) [4c2e1822] START, = DisconnectStorageServerVDSCommand(HostName =3D ng320, = StorageServerConnectionManagementVDSParameters:{runAsync=3D'true', ho= stId=3D'4426ed42-0805-43b1-92d9-3e5a680eaf38', = storagePoolId=3D'00000000-0000-0000-0000-000000000000', = storageType=3D'LOCALFS', connectionList=3D'[StorageServerConnections:= {id=3D'6860d96f-557e-4d82-a209-401d72bd6e16', = connection=3D'/data/ovirt/data', iqn=3D'null', vfsType=3D'null', = mountOptions=3D'null', nfsVersion=3D'null', nfsRetrans=3D'null', = nfsTimeo=3D'null', iface=3D'null', netIfaceName=3D'null'}]'}), = log id: 63f890 ...</div><div = class=3D""><div style=3D"margin: 0px; font-size: 11px; font-family: = Menlo;" class=3D"">2016-05-30 13:07:32,312 INFO  = [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStorageServerVDSComma= nd] (default task-25) [4c2e1822] FINISH, = DisconnectStorageServerVDSCommand, return: = {6860d96f-557e-4d82-a209-401d72bd6e16=3D0}, log id: 63f890</div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" class=3D""><br= class=3D""></div><div style=3D"margin: 0px;" class=3D"">When I run the = command:</div><div style=3D"margin: 0px;" class=3D"">2016-05-31 15:34:11,259 ERROR = [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default = task-13) [] Operation Failed: Entity not found: Storage server = connection: = id=3D6860d96f-557e-4d82-a209-401d72bd6e16</div></div><div = style=3D"margin: 0px;" class=3D""> </div><div = style=3D"margin: 0px;" class=3D"">What's wrong ?</div></body></html>= --Apple-Mail=_943A44EE-DB36-4E2B-A9A5-F7AE7F010E4A--

1 0

VMs using hugepages
by Ralf Schenk 31 May '16

31 May '16

This is a multi-part message in MIME format. --------------1F41AA982CD26EC47BC0B407 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hello, I try to get VM's to use hugepages by default. We use them on our manual VM's set up for libvirt and experience performance advantages. I installed vdsm-hook-hugepages, but according to http://www.ovirt.org/develop/developer-guide/vdsm/hook/hugepages/ I have to set hugepages=SIZE. Engine Web-Fronted doesn't show an option anywhere to specify this. I want the VMs to have: <memoryBacking> <hugepages/> </memoryBacking> Any hint ? Versions: vdsm.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-cli.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-gluster.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-hook-hugepages.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-hook-vmfex-dev.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-infra.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-jsonrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-python.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-xmlrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6 vdsm-yajsonrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6 Engine: ovirt-engine.noarch 3.6.6.2-1.el7.centos @ovirt-3.6 -- *Ralf Schenk* fon +49 (0) 24 05 / 40 83 70 fax +49 (0) 24 05 / 40 83 759 mail *rs(a)databay.de* <mailto:rs@databay.de> *Databay AG* Jens-Otto-Krag-Straße 11 D-52146 Würselen *www.databay.de* <http://www.databay.de> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202 Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns Aufsichtsratsvorsitzender: Klaus Scholzen (RA) ------------------------------------------------------------------------ --------------1F41AA982CD26EC47BC0B407 Content-Type: multipart/related; boundary="------------42116FB0C46FABA6A6982AF7" --------------42116FB0C46FABA6A6982AF7 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 try to get VM's to use hugepages by default. We use them on our manual VM's set up for libvirt and experience performance advantages. I installed vdsm-hook-hugepages, but according to <a class="moz-txt-link-freetext" href="http://www.ovirt.org/develop/developer-guide/vdsm/hook/hugepages/">http://www.ovirt.org/develop/developer-guide/vdsm/hook/hugepages/</a> I have to set hugepages=SIZE. Engine Web-Fronted doesn't show an option anywhere to specify this. I want the VMs to have: <tt> <memoryBacking> <hugepages/> </memoryBacking> </tt> Any hint ? Versions: <tt>vdsm.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt> </tt><tt>vdsm-cli.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt> </tt><tt>vdsm-gluster.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt> </tt><tt>vdsm-hook-hugepages.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt> </tt><tt>vdsm-hook-vmfex-dev.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt> </tt><tt>vdsm-infra.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt> </tt><tt>vdsm-jsonrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt> </tt><tt>vdsm-python.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt> </tt><tt>vdsm-xmlrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt> </tt><tt>vdsm-yajsonrpc.noarch 4.17.28-0.el7.centos @ovirt-3.6</tt><tt> </tt> Engine: ovirt-engine.noarch 3.6.6.2-1.el7.centos @ovirt-3.6 <div class="moz-signature">-- <table border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <td colspan="3"><img src="cid:part1.FD451D75.B4E6C315@databay.de" height="30" border="0" width="151"></td> </tr> <tr> <td valign="top"> Ralf Schenk fon +49 (0) 24 05 / 40 83 70 fax +49 (0) 24 05 / 40 83 759 mail <a href="mailto:rs@databay.de">rs(a)databay.de</a> </td> <td width="30"> </td> <td valign="top"> Databay AG Jens-Otto-Krag-Straße 11 D-52146 Würselen <a href="http://www.databay.de">www.databay.de</a> </td> </tr> <tr> <td colspan="3" valign="top"> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202 Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns Aufsichtsratsvorsitzender: Klaus Scholzen (RA) </td> </tr> </tbody> </table> <hr color="#000000" noshade="noshade" size="1" width="100%"> </div> </body> </html> --------------42116FB0C46FABA6A6982AF7 Content-Type: image/gif; name="logo_databay_email.gif" Content-Transfer-Encoding: base64 Content-ID: <part1.FD451D75.B4E6C315(a)databay.de> Content-Disposition: inline; filename="logo_databay_email.gif" R0lGODlhlwAeAMQAAObm5v9QVf/R0oKBgfDw8NfX105MTLi3t/r6+sfHx/+rrf98gC0sLP8L EhIQEKalpf/g4ZmYmHd2dmppaf8uNP/y8v8cIv+Ym//AwkE/P46NjRwbG11cXP8ABwUDA/// /yH5BAAAAAAALAAAAACXAB4AAAX/4CeOYnUJZKqubOu+cCzPNA0tVnfVfO//wGAKk+t0Ap+K QMFUYCDCqHRKJVUWDaPRUsFktZ1G4AKtms9o1gKsFVS+7I5ll67bpd647hPQawNld4KDMQJF bA07F35aFBiEkJEpfXEBjx8KjI0Vkp2DEIdaCySgFBShbEgrCQOtrq+uEQcALQewrQUjEbe8 rgkkD7y5KhMZB3drqSoVFQhdlHGXKQYe1dbX2BvHKwzY1RMiAN7j1xEjBeTmKeIeD3cYCxRf FigvChRxFJwkBBvk5A7cpZhAjgGCDwn+kfslgto4CSoSehh2BwEEBQvowDAUR0EKdArHZTg4 4oDCXBFC/3qj9SEluZEpHnjYQFIGgpo1KgSasYjNKBImrzF4NaFbNgIjCGRQeIyVKwneOLzS cLCAg38OWI4Y4GECgQcSOEwYcADnh6/FNjAwoGFYAQ0atI4AAFeEFwsLFLiJUQEfGH0kNGAD x8+oNQdIRQg+7NCaOhIgD8sVgYADNsPVGI5YWjRqzQTdHDDIYHRDLokaUhCglkFEJi0NKJhl 0RP2TsvXUg88KiLBVWsZrF6DmMKlNYMqglqTik1guN8OBgAgkGCpB+L9ugK4iSCBvwEfECw1 kILrBpa1jVCQIQBRvbP+rlEcQVAoSevWyv6uhpwE12uEkQAAZucpVw1xIsjkgf8B863mQVYt eQATCZYJZJ5WBfij2wfpHcEeHGG8Z+BMszVWDXkfKLhceJhBSAJ+1ThH32AfRFZNayNAtUFi wFSTSwEHJIYAAQU84IADwyjIEALU9MchG+vFgIF7W2GDI2T7HfjBgNcgKQKMHmwjgnCSpeCb ULRkdxhF1CDY40RjgmUAA/v1J5FAKW2gGSZscBFDMraNgJs1AYpAAGYP5jJoNQ4Y4Gh8jpFg HH9mgbmWo1l6oA4C3Ygp6UwEIFBfNRtkMIBlKMLnAXgAXLWhXXH85EIFqMhGGZgDEKArABGA ed0HI4bk5qgnprCYSt88B6dqS0FEEAMPJDCdCJYViur/B1BlwGMJqDTwnhqxJgUpo0ceOQ4D 0yEakpMm/jqCRMgWm2I1j824Y6vLvuuPjHnqOJkIgP6xzwp5sCFNsCFp88Gxh11lrjfDcNrc CEx64/CD3iAHlQcMUEQXvcA+qBkBB4Q2X1CusjBlJdKMYAKI6g28MbKN5hJsBAXknHOwutn4 oFYqkpqAzjnPbE0u1PxmwAQGXLWBbvhuIIEGEnRjlAHO4SvhbCNAkwoGzEBwgV9U0lfu2WiX OkDEGaCdKgl0nk2YkWdPOCDabvaGdkAftL1LlgwCM+7Tq11V71IO7LkM2XE0YAHMYMhqqK6U V165CpaHukLmiXFO8XSVzzakX+UH6TrmAajPNxfqByTQec41AeBPvSwIALkmAnuiexCsca3C BajgfsROuxcPA8kHQJX4DAIwjnsAvhsvfXHWKEwDAljg7sj03L9wwAQTxOWD2AE0YP75eCkw cPfs+xACADs= --------------42116FB0C46FABA6A6982AF7-- --------------1F41AA982CD26EC47BC0B407--

2 1

Clone, template, pools : how does it uses disk space ?
by Alexis HAUSER 31 May '16

31 May '16

Hi, I would like to know what happens to storage when using the different method of cloning or generating VMs using templates / pools. I'd like to know also in what case VM and virtual disks are totally independent and in what case they are not. Sadly the RHEV documentation doesn't really provide these informations and I don't find any explicit informations about it. For example, when making a VM from template, using pre-allocated disk option, for a 50GB Virtual disk, it only uses 3GB on the physical disk. Another example, when making a pool of 10 VMs, based on a VM with a 50 GB virtual disk, only 2GB more space is used on the physical disk. What is exactly done when this happens ? Here are the case I would like to have informations about (physical storage, and independence of VMs) : - using simple "clone function" - making VM from template with "clone" mode - making VM from template with "thin" mode - making VM in pools Is there modes calculating only the difference from the original VM, and other modes copying totally the informations from the virtual disk from the original VM ?

3 3

Re: [ovirt-users] oVirt 4.0 hosted-engine deploy exits without messages or logs
by Gianluca Cecchi 31 May '16

31 May '16

On Fri, May 13, 2016 at 10:43 AM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com > wrote: > On Thu, May 12, 2016 at 3:32 PM, Sandro Bonazzola wrote: > >> >> >> >> I strongly suggest to use master. In particular, I strongly suggest to us >> oVirt Node Next ISO for hosts and the engine appliance for the deployment. >> Installing Hosted Engine using Cockpit Web UI has been a nice experience >> yesterday. >> https://twitter.com/SandroBonazzola/status/730426730515673092 >> >> Be sure to install also the new dashboard package once your Hosted Engine >> is up, that's another nice thing to see in action. >> >> > It seems master from yesterday, attempting self hosted engine on nfs3 with > hypervisor on CentOS 7.2 gives: > > [ INFO ] Stage: Transaction setup > [ INFO ] Stage: Misc configuration > [ INFO ] Stage: Package installation > [ INFO ] Stage: Misc configuration > [ INFO ] Configuring libvirt > [ INFO ] Configuring VDSM > [ INFO ] Starting vdsmd > [ INFO ] Creating Storage Domain > [ INFO ] Creating Storage Pool > [ INFO ] Connecting Storage Pool > [ INFO ] Verifying sanlock lockspace initialization > [ ERROR ] Failed to execute stage 'Misc configuration': [Errno 101] > Network is unreachable > [ INFO ] Stage: Clean up > > It seems I get the same problem with 4.0 beta too... At least basic sh engine install should work in a beta, I think.... [ INFO ] Creating Storage Domain [ INFO ] Creating Storage Pool [ INFO ] Connecting Storage Pool [ INFO ] Verifying sanlock lockspace initialization [ ERROR ] Failed to execute stage 'Misc configuration': [Errno 101] Network is unreachable [ INFO ] Stage: Clean up [ INFO ] Generating answer file '/var/lib/ovirt-hosted-engine-setup/answers/answers-20160531110857.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ ERROR ] Hosted Engine deployment failed: this system is not reliable, please check the issue, fix and redeploy Inside ovirt-hosted-engine-setup initially I see an error about SSL and vdsmd May 31 11:03:58 ovirtita.localdomain.local vdsm[8571]: vdsm vds.dispatcher ERROR SSL error during reading data: unexpected eof 2016-05-31 11:04:36 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:926 execute-output: ('/bin/systemctl', 'status', 'vdsmd.service') stderr: I see it also inside messages And then 2016-05-31 11:08:51 DEBUG otopi.plugins.gr_he_setup.sanlock.lockspace storage_backends.create_volume :270 Connecting to VDSM 2016-05-31 11:08:51 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-hosted-engine-setup/scripts/../plugins/gr-he-setup/sanlock/lockspace.py", l ine 143, in _misc lockspace + '.metadata': md_size, File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/storage_backends.py", line 369, in create service_size=size) File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/storage_backends.py", line 279, in create_volume volUUID=volume_uuid File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/storage_backends.py", line 245, in _get_volume_path volUUID File "/usr/lib64/python2.7/xmlrpclib.py", line 1233, in __call__ return self.__send(self.__name, args) File "/usr/lib64/python2.7/xmlrpclib.py", line 1587, in __request verbose=self.__verbose File "/usr/lib64/python2.7/xmlrpclib.py", line 1273, in request return self.single_request(host, handler, request_body, verbose) File "/usr/lib64/python2.7/xmlrpclib.py", line 1301, in single_request self.send_content(h, request_body) File "/usr/lib64/python2.7/xmlrpclib.py", line 1448, in send_content connection.endheaders(request_body) File "/usr/lib64/python2.7/httplib.py", line 975, in endheaders self._send_output(message_body) File "/usr/lib64/python2.7/httplib.py", line 835, in _send_output self.send(msg) File "/usr/lib64/python2.7/httplib.py", line 797, in send self.connect() File "/usr/lib/python2.7/site-packages/vdsm/m2cutils.py", line 203, in connect sock = socket.create_connection((self.host, self.port), self.timeout) File "/usr/lib64/python2.7/socket.py", line 571, in create_connection raise err error: [Errno 101] Network is unreachable 2016-05-31 11:08:51 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Misc configuration': [Errno 101] Network is unreachable 2016-05-31 11:08:51 DEBUG otopi.transaction transaction.abort:119 aborting 'File transaction for '/etc/ovirt-hosted-engine/firewalld/hosted-console.xml'' 2016-05-31 11:08:51 DEBUG otopi.transaction transaction.abort:119 aborting 'File transaction for '/etc/ovirt-hosted-engine/iptables.example'' 2016-05-31 11:08:51 DEBUG otopi.transaction transaction.abort:119 aborting 'File transaction for '/etc/sysconfig/iptables'' The NFS file system is indeed mounted together with a loop device /dev/loop1 2.0G 3.1M 1.9G 1% /rhev/data-center/mnt/_var_lib_ovirt-hosted-engine-setup_tmpazuZQZ ovirtita.localdomain.local:/SHE_DOMAIN 25G 34M 25G 1% /rhev/data-center/mnt/ovirtita.localdomain.local:_SHE__DOMAIN And getting this in messages: May 31 11:03:51 ovirtita rpc.mountd[937]: authenticated mount request from 192.168.122.51:668 for /S HE_DOMAIN (/SHE_DOMAIN) May 31 11:03:51 ovirtita rpc.mountd[937]: authenticated unmount request from 192.168.122.51:927 for /SHE_DOMAIN (/SHE_DOMAIN) May 31 11:03:51 ovirtita journal: vdsm SchemaCache WARNING Provided value "1" not defined in Storage DomainType enum for StoragePool.connectStorageServer May 31 11:03:51 ovirtita journal: vdsm SchemaCache WARNING Provided parameters {u'protocol_version': 3, u'connection': u'ovirtita.localdomain.local:/SHE_DOMAIN', u'user': u'kvm', u'id': u'd8094512-9c9 e-4138-abbb-20715ea7fb96'} do not match any of union ConnectionRefParameters values May 31 11:03:51 ovirtita rpc.mountd[937]: authenticated mount request from 192.168.122.51:899 for /S HE_DOMAIN (/SHE_DOMAIN) sanlock.log contains the lines below. It seems strange the truncate of hostname from "ovirtita.localdomain.local" to "ovirtita.l" in many lines 2016-05-31 11:07:42+0200 6143 [8341]: s1 lockspace 9501187c-41a3-4e80-aa97-772bacae4c84:250:/rhev/data-center/mnt/_var_lib_ovirt-hosted-engine-setup_tmpazuZQZ/9501187c-41a3-4e80-aa97-772bacae4c84/dom_ md/ids:0 2016-05-31 11:08:03+0200 6164 [8342]: s1:r1 resource 9501187c-41a3-4e80-aa97-772bacae4c84:SDM:/rhev/data-center/mnt/_var_lib_ovirt-hosted-engine-setup_tmpazuZQZ/9501187c-41a3-4e80-aa97-772bacae4c84/do m_md/leases:1048576 for 3,11,9192 2016-05-31 11:08:03+0200 6164 [8342]: s2 lockspace cd9f23e2-1b3b-46fb-bf56-8687958c4ff8:250:/rhev/data-center/mnt/ovirtita.localdomain.local:_SHE__DOMAIN/cd9f23e2-1b3b-46fb-bf56-8687958c4ff8/dom_md/ids:0 2016-05-31 11:08:03+0200 6164 [8327]: s1 host 250 1 6143 2dd31d21-99d9-4c28-8368-2414f31eec55.ovirtita.l 2016-05-31 11:08:24+0200 6185 [8341]: s2:r2 resource cd9f23e2-1b3b-46fb-bf56-8687958c4ff8:SDM:/rhev/data-center/mnt/ovirtita.localdomain.local:_SHE__DOMAIN/cd9f23e2-1b3b-46fb-bf56-8687958c4ff8/dom_md/ leases:1048576 for 3,11,9192 2016-05-31 11:08:24+0200 6185 [8327]: s2 host 250 1 6164 2dd31d21-99d9-4c28-8368-2414f31eec55.ovirtita.l 2016-05-31 11:08:30+0200 6191 [8342]: s3 lockspace 9501187c-41a3-4e80-aa97-772bacae4c84:1:/rhev/data-center/mnt/_var_lib_ovirt-hosted-engine-setup_tmpazuZQZ/9501187c-41a3-4e80-aa97-772bacae4c84/dom_md /ids:0 2016-05-31 11:08:30+0200 6191 [8341]: s4 lockspace cd9f23e2-1b3b-46fb-bf56-8687958c4ff8:1:/rhev/data-center/mnt/ovirtita.localdomain.local:_SHE__DOMAIN/cd9f23e2-1b3b-46fb-bf56-8687958c4ff8/dom_md/ids:0 2016-05-31 11:08:51+0200 6212 [8327]: s4 host 1 1 6191 2dd31d21-99d9-4c28-8368-2414f31eec55.ovirtita.l 2016-05-31 11:08:51+0200 6212 [8327]: s4 host 250 1 0 2dd31d21-99d9-4c28-8368-2414f31eec55.ovirtita.l 2016-05-31 11:08:51+0200 6212 [8327]: s3 host 1 1 6191 2dd31d21-99d9-4c28-8368-2414f31eec55.ovirtita.l 2016-05-31 11:08:51+0200 6212 [8327]: s3 host 250 1 0 2dd31d21-99d9-4c28-8368-2414f31eec55.ovirtita.l 2016-05-31 11:08:51+0200 6212 [9662]: s3:r3 resource 9501187c-41a3-4e80-aa97-772bacae4c84:SDM:/rhev/data-center/mnt/_var_lib_ovirt-hosted-engine-setup_tmpazuZQZ/9501187c-41a3-4e80-aa97-772bacae4c84/dom_md/leases:1048576 for 3,11,9192 2016-05-31 11:11:31+0200 6372 [8342]: s5 lockspace d260b12c-3bf2-405a-9537-2949064e58b5:250:/rhev/data-center/mnt/_var_lib_ovirt-hosted-engine-setup_tmpugQ9c3/d260b12c-3bf2-405a-9537-2949064e58b5/dom_md/ids:0 Any way to understand why the "create_connect" fails and why it decodes it as "Network unreachable"? BTW: during setup I see this message [WARNING] Cannot locate gluster packages, Hyper Converged setup support will be disabled. Does it mean hyper converged setup could be supported in 4.0? Thanks, Gianluca

1 0

Re: [ovirt-users] On 3.6.6, tried doing a live VM storage migration... didn't work
by Markus Stockhausen 31 May '16

31 May '16

------=_NextPartTM-000-7fc17005-f5d8-4745-92f6-4a4dc02fab36 Content-Type: multipart/alternative; boundary="_000_c00167c8394c4c46a22eaecc541ae43cemailandroidcom_" --_000_c00167c8394c4c46a22eaecc541ae43cemailandroidcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBrbm93IG9mIGF0IGxlYXN0IG9uZSBsaXZlIERpc2sgTWlncmF0aW9uIGlzc3VlIHdpdGggTXVs dGkgRGlzayBWTXMuDQoNCmh0dHBzOi8vYnVnemlsbGEucmVkaGF0LmNvbS9zaG93X2J1Zy5jZ2k/ aWQ9MTMxOTQwMA0KDQpNaWdodCBiZSB0b3RhbGx5IGRpZmZlcmVudCBidXQgSSBtdXN0IGFkbWl0 IHRoYXQgdGhpcyBmZWF0dXJlIGhhZCBzZXZlcmFsIHVwcyBhbmQgZG93bnMgdGhlIGxhc3QgeWVh cnMuDQoNCk1hcmt1cw0KDQpBbSAyNi4wNS4yMDE2IDM6NTAgdm9ybS4gc2NocmllYiBDaHJpc3Rv cGhlciBDb3ggPGNjb3hAZW5kbGVzc25vdy5jb20+Og0KSW4gb3VyIG9sZCAzLjQgb3ZpcnQsIEkg a25vdyBJJ3ZlIG1pZ3JhdGVkIHN0b3JhZ2Ugb24gbGl2ZSBWTXMgYW5kIGV2ZXJ5dGhpbmcNCnNl ZW1lZCB0byB3b3JrLg0KDQpIb3dldmVyIG9uIDMuNi42LCBJIHRyaWVkIHRoaXMgYW5kIEkgc2F3 IHRoZSB3YXJuaW5nIGFib3V0IG1vdmluZyBzdG9yYWdlIG9uIGENCmxpdmUgVk0gKGl0IHdhc24n dCBkb2luZyBtdWNoIG9mIGFueXRoaW5nKSBhbmQgSSB3ZW50IGFoZWFkIGFuZCBtaWdyYXRlZCB0 aGUNCnN0b3JhZ2UgZnJvbSBvbmUgc3RvcmFnZSBkb21haW4gdG8gYW5vdGhlci4gICBCdXQgd2hl biBpdCB3YXMgdGhyb3VnaCwgZXZlbg0KdGhvdWdoIHRoZSBWTSB3YXMgc3RpbGwgYWxpdmUsIHdo ZW4gSSB0cmllZCB0byB3cml0ZSB0byBhIHZpcnR1YWwgZGlzayB0aGF0IHdhcw0KcGFydCBvZiB0 aGUgbW92ZSwgaXQgcGF1c2VkIHRoZSBWTSBzYXlpbmcgdGhlcmUgd2Fzbid0IGVub3VnaCBzdG9y YWdlLg0KDQpJIGNvdWxkIHVucGF1c2UgdGhlIFZNLCBidXQgaW4gYSBmZXcgc2Vjb25kcywgd2l0 aCB0aGluZ3Mgd3JpdGluZyB0byB0aGUgdmlydHVhbA0KZGlzaywgYWdhaW4gaXQgd2FzIHBhdXNl ZCB3aXRoIHRoZSBzYW1lIG91dCBvZiBzcGFjZSBtZXNzYWdlLiAgVmRzbSBsb2dzIHNob3dlZA0K dGhlIGVub3NwYyByZXR1cm4gY29kZS4uLiBzbyBpdCBtYWRlIHNlbnNlLCBpdCdzIGp1c3QgdGhh dCB0aGUgVk0gc2hvd3MgcGxlbnR5DQpvZiBzdG9yYWdlIHRoZXJlLiAgT25jZSBJIHJlYm9vdGVk IHRoZSBWTSwgZXZlcnl0aGluZyB3ZW50IGJhY2sgdG8gbm9ybWFsLg0KDQpTbyBpcyBtb3Zpbmcg c3RvcmFnZSBmb3IgYSBsaXZlIFZNIG5vdCBzdXBwb3J0ZWQ/ICBJIGd1ZXNzIHdlIGdvdCBsdWNr eSBpbiBvdXINCjMuNCBzeXN0ZW0gKD8pDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpVc2VycyBtYWlsaW5nIGxpc3QNClVzZXJzQG92aXJ0Lm9yZw0K aHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo= --_000_c00167c8394c4c46a22eaecc541ae43cemailandroidcom_ Content-Type: text/html; charset="utf-8" Content-ID: <CB7FDCFAC1461E4489DDC562BF4BDB5A(a)collogia.de> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pkkga25vdyBvZiBhdCBsZWFzdCBvbmUgbGl2ZSBEaXNrIE1pZ3JhdGlvbiBpc3N1ZSB3aXRoIE11 bHRpIERpc2sgVk1zLjwvcD4NCjxwIGRpcj0ibHRyIj5odHRwczovL2J1Z3ppbGxhLnJlZGhhdC5j b20vc2hvd19idWcuY2dpP2lkPTEzMTk0MDA8L3A+DQo8cCBkaXI9Imx0ciI+TWlnaHQgYmUgdG90 YWxseSBkaWZmZXJlbnQgYnV0IEkgbXVzdCBhZG1pdCB0aGF0IHRoaXMgZmVhdHVyZSBoYWQgc2V2 ZXJhbCB1cHMgYW5kIGRvd25zIHRoZSBsYXN0IHllYXJzLjwvcD4NCjxwIGRpcj0ibHRyIj5NYXJr dXM8L3A+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+QW0gMjYuMDUuMjAxNiAzOjUwIHZvcm0u IHNjaHJpZWIgQ2hyaXN0b3BoZXIgQ294ICZsdDtjY294QGVuZGxlc3Nub3cuY29tJmd0Ozo8YnIg dHlwZT0iYXR0cmlidXRpb24iPg0KPGJsb2NrcXVvdGUgY2xhc3M9InF1b3RlIiBzdHlsZT0ibWFy Z2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFl eCI+DQo8ZGl2Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdCI+PC9z cGFuPjwvZm9udD4NCjxkaXY+SW4gb3VyIG9sZCAzLjQgb3ZpcnQsIEkga25vdyBJJ3ZlIG1pZ3Jh dGVkIHN0b3JhZ2Ugb24gbGl2ZSBWTXMgYW5kIGV2ZXJ5dGhpbmcNCjxicj4NCnNlZW1lZCB0byB3 b3JrLjxicj4NCjxicj4NCkhvd2V2ZXIgb24gMy42LjYsIEkgdHJpZWQgdGhpcyBhbmQgSSBzYXcg dGhlIHdhcm5pbmcgYWJvdXQgbW92aW5nIHN0b3JhZ2Ugb24gYSA8YnI+DQpsaXZlIFZNIChpdCB3 YXNuJ3QgZG9pbmcgbXVjaCBvZiBhbnl0aGluZykgYW5kIEkgd2VudCBhaGVhZCBhbmQgbWlncmF0 ZWQgdGhlIDxicj4NCnN0b3JhZ2UgZnJvbSBvbmUgc3RvcmFnZSBkb21haW4gdG8gYW5vdGhlci4m bmJzcDsmbmJzcDsgQnV0IHdoZW4gaXQgd2FzIHRocm91Z2gsIGV2ZW4gPGJyPg0KdGhvdWdoIHRo ZSBWTSB3YXMgc3RpbGwgYWxpdmUsIHdoZW4gSSB0cmllZCB0byB3cml0ZSB0byBhIHZpcnR1YWwg ZGlzayB0aGF0IHdhcyA8YnI+DQpwYXJ0IG9mIHRoZSBtb3ZlLCBpdCBwYXVzZWQgdGhlIFZNIHNh eWluZyB0aGVyZSB3YXNuJ3QgZW5vdWdoIHN0b3JhZ2UuPGJyPg0KPGJyPg0KSSBjb3VsZCB1bnBh dXNlIHRoZSBWTSwgYnV0IGluIGEgZmV3IHNlY29uZHMsIHdpdGggdGhpbmdzIHdyaXRpbmcgdG8g dGhlIHZpcnR1YWwgPGJyPg0KZGlzaywgYWdhaW4gaXQgd2FzIHBhdXNlZCB3aXRoIHRoZSBzYW1l IG91dCBvZiBzcGFjZSBtZXNzYWdlLiZuYnNwOyBWZHNtIGxvZ3Mgc2hvd2VkIDxicj4NCnRoZSBl bm9zcGMgcmV0dXJuIGNvZGUuLi4gc28gaXQgbWFkZSBzZW5zZSwgaXQncyBqdXN0IHRoYXQgdGhl IFZNIHNob3dzIHBsZW50eSA8YnI+DQpvZiBzdG9yYWdlIHRoZXJlLiZuYnNwOyBPbmNlIEkgcmVi b290ZWQgdGhlIFZNLCBldmVyeXRoaW5nIHdlbnQgYmFjayB0byBub3JtYWwuPGJyPg0KPGJyPg0K U28gaXMgbW92aW5nIHN0b3JhZ2UgZm9yIGEgbGl2ZSBWTSBub3Qgc3VwcG9ydGVkPyZuYnNwOyBJ IGd1ZXNzIHdlIGdvdCBsdWNreSBpbiBvdXIgPGJyPg0KMy40IHN5c3RlbSAoPyk8YnI+DQo8YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClVz ZXJzIG1haWxpbmcgbGlzdDxicj4NClVzZXJzQG92aXJ0Lm9yZzxicj4NCjxhIGhyZWY9Imh0dHA6 Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2VycyI+aHR0cDovL2xpc3RzLm92 aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzPC9hPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_c00167c8394c4c46a22eaecc541ae43cemailandroidcom_-- ------=_NextPartTM-000-7fc17005-f5d8-4745-92f6-4a4dc02fab36 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" **************************************************************************** Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Über das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 **************************************************************************** ------=_NextPartTM-000-7fc17005-f5d8-4745-92f6-4a4dc02fab36--

2 1