- Users - oVirt List Archives

Create a Virtual Disk failed
by Dewey Du 28 Jun '16

28 Jun '16

I use glusterfs as storage. When I tried to create a virtual disk for a vm, I got the following error in UI logs. ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default task-48) [] Permutation name: B003B5EDCB6FC4308644D5D001F65B4C ERROR [org.ovirt.engine.ui.frontend.server.gwt.OvirtRemoteLoggingService] (default task-48) [] Uncaught exception: : com.google.gwt.core.client.JavaScriptException: (TypeError) __gwt$exception: <skipped>: a is undefined at Unknown._kj(Unknown Source) at Unknown.JUq(Unknown Source) at Unknown.Fbr(Unknown Source) at Unknown.Hno(Unknown Source) at Unknown.t0n(Unknown Source) at Unknown.w0n(Unknown Source) at Unknown.q3n(Unknown Source) at Unknown.t3n(Unknown Source) at Unknown.S2n(Unknown Source) at Unknown.V2n(Unknown Source) at Unknown.bMe(Unknown Source) at Unknown.V7(Unknown Source) at Unknown.k8(Unknown Source) at Unknown.czf/c.onreadystatechange<(Unknown Source) at Unknown.Ux(Unknown Source) at Unknown.Yx(Unknown Source) at Unknown.Xx/<(Unknown Source) at Unknown.anonymous(Unknown Source)

4 5

VDI experience to share?
by Giorgio Bersano 28 Jun '16

28 Jun '16

Hi everyone, I've been asked to deploy a VDI solution based on our oVirt infrastructure. What we have in production is a 3.6 manager (standalone, not HE) with a 3.5 cluster (CentOS 6) and a 3.6 cluster (CentOS 7), iSCSI storage, fully redundant networking. What is not clear to me is the client side, especially because we have been asked to implement a thin client solution but I've been almost unable to find suitable devices. Is there anyone in this list willing to share his/her experience on this topic? Probably my search skill is low but I've only seen references to IGEL. Other brands? There is another strong requirement: our network infrastructure makes use of 802.1x to authenticate client devices and it would be highly advisable to respect that constraint. TIA, Giorgio.

9 17

Re: [ovirt-users] 3.6 to 4.0 upgrade cert issue
by Matt Haught 28 Jun '16

28 Jun '16

So I switched back to the original self-signed certs that I had luckily saved and was able to get in without error. Is there a new process for using non-self-signed certs with ovirt 4.0? Thanks, -- Matt Haught On Fri, Jun 24, 2016 at 11:19 AM, Matt Haught <dmhaught(a)ncsu.edu> wrote: > I just attempted an upgrade from 3.6 to 4.0 hosted engine and ran into an > problem. The hosted engine vm updated without issue, but when I go to login > to the web interface to continue the process I get: > > sun.security.validator.ValidatorException: PKIX path building failed: > sun.security.provider.certpath.SunCertPathBuilderException: unable to find > valid certification path to requested target > > at every page load and I can't login. I have a feeling that the issue > comes from where I replaced the self-signed certs with trusted ca signed > certs a year ago. Is there a work around? > > CentOS 7.2 > > Thanks, > > -- > Matt Haught >

3 5

Security Groups
by Pavel Gashev 28 Jun '16

28 Jun '16

Hello, Currently oVirt supports network security groups for OpenStack network provider only. Are there plans to implement Security Groups for native networks? Technically, I can configure a vNic profile with some Security Groups UUID, and apply it in before_device_create and before_update_device VDSM hooks as filterref to some custom nwfilter. The only issue is that I have to manually edit and distribute nwfilter xml among hardware nodes. If I want isolate set of VMs, I have to manually maintain MAC addresses of VMs in that xml. It would be great if oVirt web interface had a nwfilter editor. Are there plans for it? Thanks

2 1

ovirt-engine-4.0 storage ISO Domain Unattached
by 转圈圈 28 Jun '16

28 Jun '16

This is a multi-part message in MIME format. ------=_NextPart_57722BB7_09080C70_033D1CB6 Content-Type: text/plain; charset="gb18030" Content-Transfer-Encoding: base64 UHJvYmxlbTpJbnN0YWxsIHRoZSBvdmlydC1lbmdpbmUtNC4wICxJIGNob3NlIHRoZSBJU08g RG9tYWluIHBhdGggIi92YXIvbGliL2V4cG9ydHMvaXNvIiBhbmQgaW5zdGFsbCBzdWNjZXNz ZnVsIDtidXQgYWNjZXNzIHRocm91Z2ggYnJvd3NlciwgdGhlIElTTyBEb21haW4gc3RhdGUg aXMgIlVuYXR0YWNoZWQiOw== ------=_NextPart_57722BB7_09080C70_033D1CB6 Content-Type: text/html; charset="gb18030" Content-Transfer-Encoding: base64 PGRpdj5Qcm9ibGVtOkluc3RhbGwgdGhlIG92aXJ0LWVuZ2luZS00LjAgLEkgY2hvc2UgdGhl IElTTyBEb21haW4gcGF0aCAiL3Zhci9saWIvZXhwb3J0cy9pc28iIGFuZCBpbnN0YWxsIHN1 Y2Nlc3NmdWwgO2J1dCBhY2Nlc3MgdGhyb3VnaCBicm93c2VyLCZuYnNwOzxzcGFuIHN0eWxl PSJsaW5lLWhlaWdodDogMS41OyI+dGhlIElTTyBEb21haW4gc3RhdGUgaXMgIlVuYXR0YWNo ZWQ8L3NwYW4+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAxLjU7Ij4iOzwvc3Bhbj48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxi cj48L2Rpdj4= ------=_NextPart_57722BB7_09080C70_033D1CB6--

1 0

migrating a vm from a down node
by Bill James 28 Jun '16

28 Jun '16

I am doing some fault tolerance type testing with ovirt before we put it in production. One thing I noticed is if I unplug the power from a hardware node, including iLo (fence), that the VMs that were on that host go to unknown state. I have found no way in the GUI to migrate the hosts, even they they are marked HA. The only way I've found so far is to modify the database directly. Is that the only recovery from a host failure of this type? engine=> update vm_dynamic set status = 0 where vm_guid =(select engine(> vm_guid from vm_static where vm_name = 'myvm'); ovirt-engine-3.6.4.1-1.el7.centos.noarch centos 7.2 Also is 3.6.4 a OK version to use or should I upgrade first? (looks like 3.6.6.2-1.el7.centos is current latest)

2 1

Accessing VM over WAN
by RK RK 28 Jun '16

28 Jun '16

Hi, I am planning to deploy oVirt 4.0.0 in a production environment where initially it will host 150 VDIs and will expand by 20 to 25 in subsequent years with Windows 7, 8.1 and 10. Users will be accessing these VDIs from their android tab or any tiny thin client devices which will have only very small footprint OS with HTML5 supported browser. I wish to give users to access the VDIs over WAN(from their home or on travel). Is it possible to access the VDIs via spice-html5 over the WAN. Any special configurations to be made to enable it? How should I make spice-html5 as the default protocol to access the VDIs? -- With Regards, RK, +91 9840483044

4 3

VMs halt on Storage Error
by David Gerner 27 Jun '16

27 Jun '16

Hi, I'm running into a strange issue that I've been trying to solve unsuccessfully for a few days now, and I was hoping someone could offer some insight. A few days ago I needed to reboot the the server that hosts the management engine and is also a node in the system. Following proper procedure I selected a new host to be the SPM, migrated VMs off the Host, and put it into maintenance mode. After the host came back up (and the management engine was back online) I noticed that one of my VMs had halted on a storage error, to rule out the SPM being the issue I asked oVirt to select a new SPM and it was stuck in a contending loop where each host tries to contend for SPM status but ultimately fails (every other VM also halted by this point). The error was "BlockSD master file system FSCK error", after researching the error I found a post on this list that was the same error and the author said that a simple FSCK on the offending file system fixed his issue. I had to force shutdown every VM from the halted state and put all but one host into maintenance mode. On that host I ran a FSCK on the offending volume which found a lot of short read errors which it fixed and afterwards the contending loop was broke and hosts could now successfully be an SPM. Now every VM halts on start or resume, even ones that were offline at the time of the earlier incident, with a Storage Error "abnormal vm stop device virtio-disk0 error eio". I can't even create new disks because it fails with an error. I've attached what I think is the relevant VDSM log portion of a VM trying to resume, if more is needed please just let me know. I'm worried FSCK and I mangled the file system, and have no idea how to repair it. Any insight is greatly appreciated. Thank you, Dave oVirt Engine Version: 3.6.2.6-1.el7.centos Storage Tech: iSCSI 4 Servers each with: OS: RHEL - 7 - 2.1511.el7.centos.2.10 Kernel: 3.10.0 - 327.4.5.el7.x86_64 KVM Version: 2.3.0 - 31.el7_2.7.1 libVirt Version: libvirt-1.2.17-13.el7_2.5 VDSM Version: vdsm-4.17.28-0.el7.centos

2 1

direct mounting of vm disks?
by Robert Story 27 Jun '16

27 Jun '16

--Sig_/.lLlEVeLgvPZAtF/dI+yD0s Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, I'm using oVirt 3.5.x w/nfs for vm file storage. I'm trying to restore a vm from backup, which entails: - scp backup.tar to vm - untar backup on vm this means all the data makes 3 trips over the network, each of which causes a load spike on my nfs server. That nfs load, of course, affects all other vms. what I'd like to be able to do is - scp backup.tar to nfs server - stop vm - mount vm disks on nfs server - untar backup on nfs server (using ionice to minimze load impact) - unmount vm disks - start vm I remember that I used to use kpartx to mount regular KVM disks, so I'm hoping that it can also be done here. Anyone else tried to make this work? Robert --=20 Senior Software Engineer @ Parsons --Sig_/.lLlEVeLgvPZAtF/dI+yD0s Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAldvXM8ACgkQ7/fVLLY1mni4KwCdFDpmX8f3BumEgulWCmcUiiNz m6wAnReCZ1roZh10nXVW0iIYKtl+M9gE =KDOJ -----END PGP SIGNATURE----- --Sig_/.lLlEVeLgvPZAtF/dI+yD0s--

2 2

Unofficial projects
by James Michels 27 Jun '16

27 Jun '16

Greetings, Is there some official oVirt section where you list unofficial oVirt-related projects? If so, what is the process for a new unofficial project to get listed there? If not, I think it might be a good idea to provide a minimal support by listing them. Thank you. James

3 3

no katello 3.0 errata available anymore into ovirt
by Nathanaël Blanchet 27 Jun '16

27 Jun '16

Hi, I upgraded to the latest katello 3.0, and errata are not available anymore for hosts or vms. There is no error, it always displays 0 errata. The name of the host/vm is the same as into foreman. Though, list of provisionned hosts is still available, so I suppose the issue comes from katello API and not foreman API. 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 1

Migrations Guide in order to migrate to Enterprise Linux 7
by Ricky Schneberger 27 Jun '16

27 Jun '16

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lqvbPKPnHTdwtMCUjfMuxijuAKhJRnANe Content-Type: multipart/mixed; boundary="mVCwoxH39T20LMeN7dVTaPAj3lpWdCIge" From: Ricky Schneberger <ricky(a)schneberger.se> Reply-To: ricky(a)schneberger.se To: users <users(a)ovirt.org> Message-ID: <57711C2E.5020500(a)schneberger.se> Subject: Migrations Guide in order to migrate to Enterprise Linux 7 --mVCwoxH39T20LMeN7dVTaPAj3lpWdCIge Content-Type: multipart/alternative; boundary="------------030708040908010902070501" This is a multi-part message in MIME format. --------------030708040908010902070501 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I found out that an upgrade of oVirt 3.6 to 4.0 is not supported on Enterprise Linux 6. The information was that I should follow an Migration Guide - https://www.ovirt.org/release/4.0.0/documentation/migration-engine-3.6-to-4= .0. "Upgrade on Fedora 22 and Enterprise Linux 6 is not supported and you should follow our Migration Guide <https://www.ovirt.org/release/4.0.0/documentation/migration-engine-3.6-to-= 4.0/> in order to migrate to Enterprise Linux 7 or Fedora 23." The link only gives an 404. Regards --=20 Ricky Schneberger ------------------------------------ Use PGP to protect your own privacy! Key fingerprint =3D 59E1 2B00 C28B 6E0D C8D1 D85B 39AA 7CD5 B88C 0B63 Key-ID: 0xB88C0B63 --------------030708040908010902070501 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8= "> </head> <body text=3D"#000000" bgcolor=3D"#FFFFFF"> Hi, I found out that an upgrade of oVirt 3.6 to 4.0 is not supported on Enterprise Linux 6. The information was that I should follow an Migration Guide - <a class=3D"moz-txt-link-freetext" href=3D"https://www.ovirt.org/release/4.= 0.0/documentation/migration-engine-3.6-to-4.0">https://www.ovirt.org/releas= e/4.0.0/documentation/migration-engine-3.6-to-4.0</a>. "Upgrade on Fedora 22 and Enterprise Linux 6 is not supported and you should follow our <a href=3D"https://www.ovirt.org/release/4.0.0/documentation/migration-engine-= 3.6-to-4.0/">Migration Guide</a> in order to migrate to Enterprise Linux 7 or Fedora 23." The link only gives an 404. Regards <pre class=3D"moz-signature" cols=3D"72">--=20 Ricky Schneberger ------------------------------------ Use PGP to protect your own privacy! Key fingerprint =3D 59E1 2B00 C28B 6E0D C8D1 D85B 39AA 7CD5 B88C 0B63 Key-ID: 0xB88C0B63 </pre> </body> </html> --------------030708040908010902070501-- --mVCwoxH39T20LMeN7dVTaPAj3lpWdCIge-- --lqvbPKPnHTdwtMCUjfMuxijuAKhJRnANe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAldxHC4ACgkQOap81biMC2PXVgCgjJxrcy15uBP4XhnZmhKho2FB SYUAnRojHvqX5++WAFVwB69maUq3Loqn =ZQtv -----END PGP SIGNATURE----- --lqvbPKPnHTdwtMCUjfMuxijuAKhJRnANe-- -- IMPORTANT! This message has been scanned for viruses and phishing links. However, it is your responsibility to evaluate the links and attachments you choose to click. If you are uncertain, we always try to help. Greetings helpdesk(a)actnet.se

2 2

Network redundancy with Manual balancing per VLAN
by Fernando Frediani 27 Jun '16

27 Jun '16

Hello, In VMware it is possible to bond two network interfaces and for each Portgroup (equivalent to a VLAN) is possible to tell which of the physical interfaces underneath it you wish the traffic to flow primarily and which stays as secondary(bond mode=1 equivalent). So for certain VLANs (Management, Live Migration, etc) is possible to force traffic flow via one physical NIC of the bond and for other VLANs (Virtual Machine's traffic) outs via the other NIC with failover to each other should a cable or switch fails. This is specially good for better utilize the fewer NICs available and still have redundancy. In oVirt it is also possible to have bonds, but would it still be possible to do that same and favor the traffic per VLAN basis ? I guess it is something related to Linux Bond module but perhaps someone has done this already. Thanks Fernando

4 5

oVirt and Ceph
by Charles Gomes 27 Jun '16

27 Jun '16

--_000_307E608C4BFFA145A1496A5FD1ACC3BC1D7FDD46exchange2010dim_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello I've been reading lots of material about implementing oVirt with Ceph, howe= ver all talk about using Cinder. Is there a way to get oVirt with Ceph without having to implement entire Op= enstack ? I'm already currently using Foreman to deploy Ceph and KVM nodes, trying to= minimize the amount of moving parts. I heard something about oVirt providi= ng a managed Cinder appliance, have any seen this ? --_000_307E608C4BFFA145A1496A5FD1ACC3BC1D7FDD46exchange2010dim_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Hello<o:p></o:p> <o:p> </o:p> I’ve been reading lots of material about imple= menting oVirt with Ceph, however all talk about using Cinder. <o:p></o:p> Is there a way to get oVirt with Ceph without having= to implement entire Openstack ? <o:p></o:p> I’m already currently using Foreman to deploy = Ceph and KVM nodes, trying to minimize the amount of moving parts. I heard = something about oVirt providing a managed Cinder appliance, have any seen t= his ?<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_307E608C4BFFA145A1496A5FD1ACC3BC1D7FDD46exchange2010dim_--

9 12

latest CentOS libvirt updates safe?
by Robert Story 27 Jun '16

27 Jun '16

--Sig_/2+FpI4Cvur605E8SRHVCwXB Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I have oVirt 3.5.x on CentOS 7 hosts. These hosts have updates which include livbirt: libvirt-client x86_64 1.2.17-13.el7_2.5 updates 4= .3 M libvirt-daemon x86_64 1.2.17-13.el7_2.5 updates 5= 85 k libvirt-daemon-config-nwfilter x86_64 1.2.17-13.el7_2.5 updates 1= 22 k libvirt-daemon-driver-interface x86_64 1.2.17-13.el7_2.5 updates 1= 62 k libvirt-daemon-driver-network x86_64 1.2.17-13.el7_2.5 updates 3= 02 k libvirt-daemon-driver-nodedev x86_64 1.2.17-13.el7_2.5 updates 1= 61 k libvirt-daemon-driver-nwfilter x86_64 1.2.17-13.el7_2.5 updates 1= 85 k libvirt-daemon-driver-qemu x86_64 1.2.17-13.el7_2.5 updates 5= 71 k libvirt-daemon-driver-secret x86_64 1.2.17-13.el7_2.5 updates 1= 55 k libvirt-daemon-driver-storage x86_64 1.2.17-13.el7_2.5 updates 3= 28 k libvirt-daemon-kvm x86_64 1.2.17-13.el7_2.5 updates 1= 18 k libvirt-lock-sanlock Is it safe to let yum update these packages while the host has running VMs? in maintenance mode? or not at all? Robert --=20 Senior Software Engineer @ Parsons --Sig_/2+FpI4Cvur605E8SRHVCwXB Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAldum/EACgkQ7/fVLLY1mnj6KQCfWUsVS/OU/98ynUgin2QwEw46 ANsAnjElWFKIhCURI95jsBsCmewxDTgq =Oi3o -----END PGP SIGNATURE----- --Sig_/2+FpI4Cvur605E8SRHVCwXB--

6 7

Network Interface order changed after reboot
by ovirt＠timmi.org 27 Jun '16

27 Jun '16

Hi List, I have two nodes (running CentOS 7) and the network interface order changed for some interfaces after every reboot. The configurations are done through the oVirt GUI. So the ifcfg-ethX scripts are configured automatically by VDSM. Is there any option to get this configured to be stable? Best regards and thank you Christoph

5 11

InClusterUpgrade Scheduling Policy
by Scott 27 Jun '16

27 Jun '16

Hello list, I'm trying to upgrade a self-hosted engine RHEV environment running 3.5/el6 to 3.6/el7. I'm following the process outlined in these two documents: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualiza… https://access.redhat.com/solutions/2300331 The problem I'm having is I don't seem to be able to apply the "InClusterUpgrade" policy (procedure 5.5, step 4). I get the following error: Can not start cluster upgrade mode, see below for details: VM HostedEngine with id 5ca9cb38-82e5-4eea-8ff6-e2bc33598211 is configured to be not migratable. But the HostedEngine VM is not one I can edit due to being mid-upgrade. And even if I could, the setting its complaining about can't be managed by the engine (I tried in another RHEV instance). Is this a bug? What am I missing to be able to move on? As it seems now, the InClusterUpgrade scheduling policy is useless and can't actually be used. Thanks for any suggestions/help, Scott

3 7

vm pauses with "vm has paused due to unknown storage error
by Bill Bill 27 Jun '16

27 Jun '16

--_000_CO2PR0801MB0743180FC142ED11D7D5D3E0A62E0CO2PR0801MB0743_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkhhdmUgMyBub2RlcyBydW5uaW5nIGJvdGggb1ZpcnQgYW5kIEdsdXN0ZXIgb24g NCBTU0TigJlzIGVhY2guIEF0IHRoZSBtb21lbnQsIHRoZXJlIGFyZSB0d28gcGh5c2ljYWwgbmlj cywgb25lIGhhcyBwdWJsaWMgaW50ZXJuZXQgYWNjZXNzIGFuZCB0aGUgb3RoZXIgaXMgYSBub24t cm91dGFibGUgbmV0d29yayB1c2VkIGZvciBvdmlydG1nbXQgJiBnbHVzdGVyLg0KDQpJbiB0aGUg bG9naWNhbCBuZXR3b3JrcywgSSBoYXZlIHNlbGVjdGVkIGdsdXN0ZXIgZm9yIHRoZSBub25yb3V0 YWJsZSBuZXR3b3JrIHJ1bm5pbmcgb3ZpcnRtZ210IGFuZCBnbHVzdGVyIGhvd2V2ZXIsIHR3byBW TeKAmXMgcmFuZG9tbHkgcGF1c2UgZm9yIHdoYXQgc2VlbXMgbGlrZSBubyByZWFzb24uIFRoZXkg Y2FuIGJvdGggYmUgcmVzdW1lZCB3aXRob3V0IGlzc3VlLg0KDQpPbmUgdGVzdCBWTSBoYXMgNEdC IG9mIG1lbW9yeSBhbmQgYSBzbWFsbCBkaXNrIOKAkyBubyBwcm9ibGVtcyB3aXRoIHRoaXMgb25l LiBUd28gb3RoZXJzIGhhdmUgODAwR0IgZGlza3MgYW5kIDMyR0Igb2YgUkFNIOKAkyBib3RoIHZt 4oCZcyBleGhpYml0IHRoZSBzYW1lIGlzc3VlLg0KDQpJIGFsc28gc2VlIHRoZXNlIGluIHRoZSBv VmlydCBkYXNoYm9hcmQ6DQoNCg0KRmFpbGVkIHRvIHVwZGF0ZSBPVkYgZGlza3MgOWU2MDMyOGQt MjlhZi00NTMzLTg0ZjktNjMzZDg3ZjU0OGE3LCBPVkYgZGF0YSBpc24ndCB1cGRhdGVkIG9uIHRo b3NlIE9WRiBzdG9yZXMgKERhdGEgQ2VudGVyIHh4eHh4LCBTdG9yYWdlIERvbWFpbiBzci12b2x1 bWUwMSkuDQoNCkp1biAyMywgMjAxNiA5OjU0OjAzIFBNDQoNClZEU00gY29tbWFuZCBmYWlsZWQ6 IENvdWxkIG5vdCBhY3F1aXJlIHJlc291cmNlLiBQcm9iYWJseSByZXNvdXJjZSBmYWN0b3J5IHRo cmV3IGFuIGV4Y2VwdGlvbi46ICgpDQoNCi8vLy8vLy8vLy8vLy8vLw0KDQpWTSB4eHh4eCBoYXMg YmVlbiBwYXVzZWQgZHVlIHRvIHVua25vd24gc3RvcmFnZSBlcnJvci4NCg0KLy8vLy8vLy8vLy8v Ly8vDQoNCkluIHRoZSBlcnJvciBsb2cgb24gdGhlIGVuZ2luZSwgSSBzZWUgdGhlc2U6DQoNCkVS Uk9SIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRiYnJva2VyLmF1ZGl0bG9naGFuZGxpbmcu QXVkaXRMb2dEaXJlY3Rvcl0gKEZvcmtKb2luUG9vbC0xLXdvcmtlci03KSBbMTBjYWY5M2VdIENv cnJlbGF0aW9uIElEOiBudWxsLCBDYWxsIFN0YWNrOiBudWxsLCBDdXN0b20gRXZlbnQgSUQ6IC0x LCBNZXNzYWdlOiBWTSB4eHh4eHggaGFzIGJlZW4gcGF1c2VkIGR1ZSB0byB1bmtub3duIHN0b3Jh Z2UgZXJyb3IuDQoNCklORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRiYnJva2VyLmF1 ZGl0bG9naGFuZGxpbmcuQXVkaXRMb2dEaXJlY3Rvcl0gKEZvcmtKb2luUG9vbC0xLXdvcmtlci0x MSkgWzEwY2FmOTNlXSBDb3JyZWxhdGlvbiBJRDogbnVsbCwgQ2FsbCBTdGFjazogbnVsbCwgQ3Vz dG9tIEV2ZW50IElEOiAtMSwgTWVzc2FnZTogVk0geHh4eHh4IGhhcyByZWNvdmVyZWQgZnJvbSBw YXVzZWQgYmFjayB0byB1cC4NCg0KLy8vLy8vLy8vLy8vLy8vDQoNCkhvc3RuYW1lcyBhcmUgYWxs IGxvY2FsIHRvIC9ldGMvaG9zdHMgb24gYWxsIHNlcnZlcnMg4oCTIHRoZXkgYWxzbyByZXNvbHZl IHdpdGhvdXQgaXNzdWUgZnJvbSBlYWNoIGhvc3QuDQoNCi8vLy8vLy8vLy8vLy8vDQoNCjIwMTYt MDYtMjMgMjI6MDg6NTksNjExIFdBUk4gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2Vy LmdsdXN0ZXIuR2x1c3RlclZvbHVtZXNMaXN0UmV0dXJuRm9yWG1sUnBjXSAoRGVmYXVsdFF1YXJ0 elNjaGVkdWxlcl9Xb3JrZXItNzYpIFsxYzFjZjRmXSBDb3VsZCBub3QgYXNzb2NpYXRlIGJyaWNr ICdvdmlydDM0MzU6L21udC9kYXRhL3NyLXZvbHVtZTAxJyBvZiB2b2x1bWUgJzkzZTM2Y2RjLWFi MWItNDFlYy1hYzdmLTk2NmNmMzg1NmI1OScgd2l0aCBjb3JyZWN0IG5ldHdvcmsgYXMgbm8gZ2x1 c3RlciBuZXR3b3JrIGZvdW5kIGluIGNsdXN0ZXIgJzc1YmQ2NGRlLTA0YjItNGE5OS05Y2QwLWI2 M2U5MTliOWFjYScNCjIwMTYtMDYtMjMgMjI6MDg6NTksNjE0IFdBUk4gIFtvcmcub3ZpcnQuZW5n aW5lLmNvcmUudmRzYnJva2VyLmdsdXN0ZXIuR2x1c3RlclZvbHVtZXNMaXN0UmV0dXJuRm9yWG1s UnBjXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItNzYpIFsxYzFjZjRmXSBDb3VsZCBu b3QgYXNzb2NpYXRlIGJyaWNrICdvdmlydDM2Mzc6L21udC9kYXRhL3NyLXZvbHVtZTAxJyBvZiB2 b2x1bWUgJzkzZTM2Y2RjLWFiMWItNDFlYy1hYzdmLTk2NmNmMzg1NmI1OScgd2l0aCBjb3JyZWN0 IG5ldHdvcmsgYXMgbm8gZ2x1c3RlciBuZXR3b3JrIGZvdW5kIGluIGNsdXN0ZXIgJzc1YmQ2NGRl LTA0YjItNGE5OS05Y2QwLWI2M2U5MTliOWFjYScNCjIwMTYtMDYtMjMgMjI6MDg6NTksNjE2IFdB Uk4gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLmdsdXN0ZXIuR2x1c3RlclZvbHVt ZXNMaXN0UmV0dXJuRm9yWG1sUnBjXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItNzYp IFsxYzFjZjRmXSBDb3VsZCBub3QgYXNzb2NpYXRlIGJyaWNrICdvdmlydDM4Mzk6L21udC9kYXRh L3NyLXZvbHVtZTAxJyBvZiB2b2x1bWUgJzkzZTM2Y2RjLWFiMWItNDFlYy1hYzdmLTk2NmNmMzg1 NmI1OScgd2l0aCBjb3JyZWN0IG5ldHdvcmsgYXMgbm8gZ2x1c3RlciBuZXR3b3JrIGZvdW5kIGlu IGNsdXN0ZXIgJzc1YmQ2NGRlLTA0YjItNGE5OS05Y2QwLWI2M2U5MTliOWFjYScNCjIwMTYtMDYt MjMgMjI6MDg6NTksNjE4IFdBUk4gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLmds dXN0ZXIuR2x1c3RlclZvbHVtZXNMaXN0UmV0dXJuRm9yWG1sUnBjXSAoRGVmYXVsdFF1YXJ0elNj aGVkdWxlcl9Xb3JrZXItNzYpIFsxYzFjZjRmXSBDb3VsZCBub3QgYXNzb2NpYXRlIGJyaWNrICdv dmlydDM0MzU6L21udC9kYXRhL2Rpc3RyaWJ1dGVkJyBvZiB2b2x1bWUgJ2I4ODdiMDVlLTJlYTYt NDk2ZS05NTUyLTE1NWQ2NThlZWFhNicgd2l0aCBjb3JyZWN0IG5ldHdvcmsgYXMgbm8gZ2x1c3Rl ciBuZXR3b3JrIGZvdW5kIGluIGNsdXN0ZXIgJzc1YmQ2NGRlLTA0YjItNGE5OS05Y2QwLWI2M2U5 MTliOWFjYScNCjIwMTYtMDYtMjMgMjI6MDg6NTksNjIwIFdBUk4gIFtvcmcub3ZpcnQuZW5naW5l LmNvcmUudmRzYnJva2VyLmdsdXN0ZXIuR2x1c3RlclZvbHVtZXNMaXN0UmV0dXJuRm9yWG1sUnBj XSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItNzYpIFsxYzFjZjRmXSBDb3VsZCBub3Qg YXNzb2NpYXRlIGJyaWNrICdvdmlydDM2Mzc6L21udC9kYXRhL2Rpc3RyaWJ1dGVkJyBvZiB2b2x1 bWUgJ2I4ODdiMDVlLTJlYTYtNDk2ZS05NTUyLTE1NWQ2NThlZWFhNicgd2l0aCBjb3JyZWN0IG5l dHdvcmsgYXMgbm8gZ2x1c3RlciBuZXR3b3JrIGZvdW5kIGluIGNsdXN0ZXIgJzc1YmQ2NGRlLTA0 YjItNGE5OS05Y2QwLWI2M2U5MTliOWFjYScNCjIwMTYtMDYtMjMgMjI6MDg6NTksNjIyIFdBUk4g IFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLmdsdXN0ZXIuR2x1c3RlclZvbHVtZXNM aXN0UmV0dXJuRm9yWG1sUnBjXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItNzYpIFsx YzFjZjRmXSBDb3VsZCBub3QgYXNzb2NpYXRlIGJyaWNrICdvdmlydDM4Mzk6L21udC9kYXRhL2Rp c3RyaWJ1dGVkJyBvZiB2b2x1bWUgJ2I4ODdiMDVlLTJlYTYtNDk2ZS05NTUyLTE1NWQ2NThlZWFh Nicgd2l0aCBjb3JyZWN0IG5ldHdvcmsgYXMgbm8gZ2x1c3RlciBuZXR3b3JrIGZvdW5kIGluIGNs dXN0ZXIgJzc1YmQ2NGRlLTA0YjItNGE5OS05Y2QwLWI2M2U5MTliOWFjYScNCjIwMTYtMDYtMjMg MjI6MDg6NTksNjI0IFdBUk4gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLmdsdXN0 ZXIuR2x1c3RlclZvbHVtZXNMaXN0UmV0dXJuRm9yWG1sUnBjXSAoRGVmYXVsdFF1YXJ0elNjaGVk dWxlcl9Xb3JrZXItNzYpIFsxYzFjZjRmXSBDb3VsZCBub3QgYXNzb2NpYXRlIGJyaWNrICdvdmly dDM0MzU6L21udC9kYXRhL2lzbycgb2Ygdm9sdW1lICc4OWYzMjQ1Ny1jOGMzLTQ5MGUtYjQ5MS0x NmRkMjdkZTAwNzMnIHdpdGggY29ycmVjdCBuZXR3b3JrIGFzIG5vIGdsdXN0ZXIgbmV0d29yayBm b3VuZCBpbiBjbHVzdGVyICc3NWJkNjRkZS0wNGIyLTRhOTktOWNkMC1iNjNlOTE5YjlhY2EnDQoy MDE2LTA2LTIzIDIyOjA4OjU5LDYyNiBXQVJOICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jy b2tlci5nbHVzdGVyLkdsdXN0ZXJWb2x1bWVzTGlzdFJldHVybkZvclhtbFJwY10gKERlZmF1bHRR dWFydHpTY2hlZHVsZXJfV29ya2VyLTc2KSBbMWMxY2Y0Zl0gQ291bGQgbm90IGFzc29jaWF0ZSBi cmljayAnb3ZpcnQzNjM3Oi9tbnQvZGF0YS9pc28nIG9mIHZvbHVtZSAnODlmMzI0NTctYzhjMy00 OTBlLWI0OTEtMTZkZDI3ZGUwMDczJyB3aXRoIGNvcnJlY3QgbmV0d29yayBhcyBubyBnbHVzdGVy IG5ldHdvcmsgZm91bmQgaW4gY2x1c3RlciAnNzViZDY0ZGUtMDRiMi00YTk5LTljZDAtYjYzZTkx OWI5YWNhJw0KMjAxNi0wNi0yMyAyMjowODo1OSw2MjggV0FSTiAgW29yZy5vdmlydC5lbmdpbmUu Y29yZS52ZHNicm9rZXIuZ2x1c3Rlci5HbHVzdGVyVm9sdW1lc0xpc3RSZXR1cm5Gb3JYbWxScGNd IChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci03NikgWzFjMWNmNGZdIENvdWxkIG5vdCBh c3NvY2lhdGUgYnJpY2sgJ292aXJ0MzgzOTovbW50L2RhdGEvaXNvJyBvZiB2b2x1bWUgJzg5ZjMy NDU3LWM4YzMtNDkwZS1iNDkxLTE2ZGQyN2RlMDA3Mycgd2l0aCBjb3JyZWN0IG5ldHdvcmsgYXMg bm8gZ2x1c3RlciBuZXR3b3JrIGZvdW5kIGluIGNsdXN0ZXIgJzc1YmQ2NGRlLTA0YjItNGE5OS05 Y2QwLWI2M2U5MTliOWFjYScNCjIwMTYtMDYtMjMgMjI6MDg6NTksNjI5IElORk8gIFtvcmcub3Zp cnQuZW5naW5lLmNvcmUudmRzYnJva2VyLmdsdXN0ZXIuR2x1c3RlclZvbHVtZXNMaXN0VkRTQ29t bWFuZF0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTc2KSBbMWMxY2Y0Zl0gRklOSVNI LCBHbHVzdGVyVm9sdW1lc0xpc3RWRFNDb21tYW5kLCByZXR1cm46IHtiODg3YjA1ZS0yZWE2LTQ5 NmUtOTU1Mi0xNTVkNjU4ZWVhYTY9b3JnLm92aXJ0LmVuZ2luZS5jb3JlLmNvbW1vbi5idXNpbmVz c2VudGl0aWVzLmdsdXN0ZXIuR2x1c3RlclZvbHVtZUVudGl0eUBkOGM5MDM5YiwgOTNlMzZjZGMt YWIxYi00MWVjLWFjN2YtOTY2Y2YzODU2YjU5PW9yZy5vdmlydC5lbmdpbmUuY29yZS5jb21tb24u YnVzaW5lc3NlbnRpdGllcy5nbHVzdGVyLkdsdXN0ZXJWb2x1bWVFbnRpdHlAZmU1YWIwMTksIDg5 ZjMyNDU3LWM4YzMtNDkwZS1iNDkxLTE2ZGQyN2RlMDA3Mz1vcmcub3ZpcnQuZW5naW5lLmNvcmUu Y29tbW9uLmJ1c2luZXNzZW50aXRpZXMuZ2x1c3Rlci5HbHVzdGVyVm9sdW1lRW50aXR5QDlhNTZk NjMzfSwgbG9nIGlkOiA0ODVhMDYxMQ0KMjAxNi0wNi0yMyAyMjowOTowNCw2NDUgSU5GTyAgW29y Zy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuZ2x1c3Rlci5HbHVzdGVyVm9sdW1lc0xpc3RW RFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItODkpIFtdIFNUQVJULCBH bHVzdGVyVm9sdW1lc0xpc3RWRFNDb21tYW5kKEhvc3ROYW1lID0gb3ZpcnQzODM5LCBHbHVzdGVy Vm9sdW1lc0xpc3RWRFNQYXJhbWV0ZXJzOntydW5Bc3luYz0ndHJ1ZScsIGhvc3RJZD0nMzJjNTAw ZTUtMjY4ZC00MjZhLTlhNGEtMTA4NTM1ZTY3NzIyJ30pLCBsb2cgaWQ6IDQxYjY0NzlkDQo= --_000_CO2PR0801MB0743180FC142ED11D7D5D3E0A62E0CO2PR0801MB0743_ Content-Type: text/html; charset="utf-8" Content-ID: <D0C4FA3A5B1EE240A396E58D5F57A2E7(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 bGFzcz0iTXNvTm9ybWFsIj5IYXZlIDMgbm9kZXMgcnVubmluZyBib3RoIG9WaXJ0IGFuZCBHbHVz dGVyIG9uIDQgU1NE4oCZcyBlYWNoLiBBdCB0aGUgbW9tZW50LCB0aGVyZSBhcmUgdHdvIHBoeXNp Y2FsIG5pY3MsIG9uZSBoYXMgcHVibGljIGludGVybmV0IGFjY2VzcyBhbmQgdGhlIG90aGVyIGlz IGEgbm9uLXJvdXRhYmxlIG5ldHdvcmsgdXNlZCBmb3Igb3ZpcnRtZ210ICZhbXA7IGdsdXN0ZXIu PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JbiB0aGUgbG9naWNhbCBuZXR3b3JrcywgSSBoYXZlIHNlbGVjdGVkIGds dXN0ZXIgZm9yIHRoZSBub25yb3V0YWJsZSBuZXR3b3JrIHJ1bm5pbmcgb3ZpcnRtZ210IGFuZCBn bHVzdGVyIGhvd2V2ZXIsIHR3byBWTeKAmXMgcmFuZG9tbHkgcGF1c2UgZm9yIHdoYXQgc2VlbXMg bGlrZSBubyByZWFzb24uIFRoZXkgY2FuIGJvdGggYmUgcmVzdW1lZCB3aXRob3V0IGlzc3VlLjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T25lIHRlc3QgVk0gaGFzIDRHQiBvZiBtZW1vcnkgYW5kIGEgc21hbGwgZGlz ayDigJMgbm8gcHJvYmxlbXMgd2l0aCB0aGlzIG9uZS4gVHdvIG90aGVycyBoYXZlIDgwMEdCIGRp c2tzIGFuZCAzMkdCIG9mIFJBTSDigJMgYm90aCB2beKAmXMgZXhoaWJpdCB0aGUgc2FtZSBpc3N1 ZS48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+SSBhbHNvIHNlZSB0aGVzZSBpbiB0aGUgb1ZpcnQgZGFzaGJvYXJkOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+RmFpbGVkIHRvIHVwZGF0ZSBPVkYgZGlza3Mg OWU2MDMyOGQtMjlhZi00NTMzLTg0ZjktNjMzZDg3ZjU0OGE3LCBPVkYgZGF0YSBpc24ndCB1cGRh dGVkIG9uIHRob3NlIE9WRiBzdG9yZXMgKERhdGEgQ2VudGVyIHh4eHh4LCBTdG9yYWdlIERvbWFp biBzci12b2x1bWUwMSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkp1biAyMywgMjAxNiA5OjU0OjAz IFBNPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPlZEU00gY29tbWFuZCBmYWlsZWQ6IENvdWxkIG5vdCBh Y3F1aXJlIHJlc291cmNlLiBQcm9iYWJseSByZXNvdXJjZSBmYWN0b3J5IHRocmV3IGFuIGV4Y2Vw dGlvbi46ICgpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi8vLy8vLy8vLy8vLy8vLzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj5WTSB4eHh4eCBoYXMgYmVlbiBwYXVzZWQgZHVlIHRvIHVua25vd24gc3RvcmFn ZSBlcnJvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Ly8vLy8vLy8vLy8vLy8vPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPkluIHRoZSBlcnJvciBsb2cgb24gdGhlIGVuZ2luZSwgSSBzZWUgdGhlc2U6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPkVSUk9SIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRiYnJv a2VyLmF1ZGl0bG9naGFuZGxpbmcuQXVkaXRMb2dEaXJlY3Rvcl0gKEZvcmtKb2luUG9vbC0xLXdv cmtlci03KSBbMTBjYWY5M2VdIENvcnJlbGF0aW9uIElEOiBudWxsLCBDYWxsIFN0YWNrOiBudWxs LCBDdXN0b20gRXZlbnQgSUQ6DQogLTEsIE1lc3NhZ2U6IFZNIHh4eHh4eCBoYXMgYmVlbiBwYXVz ZWQgZHVlIHRvIHVua25vd24gc3RvcmFnZSBlcnJvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+SU5G TyZuYnNwOyBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmRhbC5kYmJyb2tlci5hdWRpdGxvZ2hhbmRs aW5nLkF1ZGl0TG9nRGlyZWN0b3JdIChGb3JrSm9pblBvb2wtMS13b3JrZXItMTEpIFsxMGNhZjkz ZV0gQ29ycmVsYXRpb24gSUQ6IG51bGwsIENhbGwgU3RhY2s6IG51bGwsIEN1c3RvbSBFdmVudCBJ RDoNCiAtMSwgTWVzc2FnZTogVk0geHh4eHh4IGhhcyByZWNvdmVyZWQgZnJvbSBwYXVzZWQgYmFj ayB0byB1cC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Ly8vLy8vLy8vLy8vLy8vPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPkhvc3RuYW1lcyBhcmUgYWxsIGxvY2FsIHRvIC9ldGMvaG9zdHMgb24gYWxsIHNl cnZlcnMg4oCTIHRoZXkgYWxzbyByZXNvbHZlIHdpdGhvdXQgaXNzdWUgZnJvbSBlYWNoIGhvc3Qu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPi8vLy8vLy8vLy8vLy8vPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi PjIwMTYtMDYtMjMgMjI6MDg6NTksNjExIFdBUk4mbmJzcDsgW29yZy5vdmlydC5lbmdpbmUuY29y ZS52ZHNicm9rZXIuZ2x1c3Rlci5HbHVzdGVyVm9sdW1lc0xpc3RSZXR1cm5Gb3JYbWxScGNdIChE ZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci03NikgWzFjMWNmNGZdIENvdWxkIG5vdCBhc3Nv Y2lhdGUNCiBicmljayAnb3ZpcnQzNDM1Oi9tbnQvZGF0YS9zci12b2x1bWUwMScgb2Ygdm9sdW1l ICc5M2UzNmNkYy1hYjFiLTQxZWMtYWM3Zi05NjZjZjM4NTZiNTknIHdpdGggY29ycmVjdCBuZXR3 b3JrIGFzIG5vIGdsdXN0ZXIgbmV0d29yayBmb3VuZCBpbiBjbHVzdGVyICc3NWJkNjRkZS0wNGIy LTRhOTktOWNkMC1iNjNlOTE5YjlhY2EnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4yMDE2LTA2LTIzIDIyOjA4OjU5LDYxNCBX QVJOJm5ic3A7IFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLmdsdXN0ZXIuR2x1c3Rl clZvbHVtZXNMaXN0UmV0dXJuRm9yWG1sUnBjXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3Jr ZXItNzYpIFsxYzFjZjRmXSBDb3VsZCBub3QgYXNzb2NpYXRlDQogYnJpY2sgJ292aXJ0MzYzNzov bW50L2RhdGEvc3Itdm9sdW1lMDEnIG9mIHZvbHVtZSAnOTNlMzZjZGMtYWIxYi00MWVjLWFjN2Yt OTY2Y2YzODU2YjU5JyB3aXRoIGNvcnJlY3QgbmV0d29yayBhcyBubyBnbHVzdGVyIG5ldHdvcmsg Zm91bmQgaW4gY2x1c3RlciAnNzViZDY0ZGUtMDRiMi00YTk5LTljZDAtYjYzZTkxOWI5YWNhJzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+MjAxNi0wNi0yMyAyMjowODo1OSw2MTYgV0FSTiZuYnNwOyBbb3JnLm92aXJ0LmVuZ2lu ZS5jb3JlLnZkc2Jyb2tlci5nbHVzdGVyLkdsdXN0ZXJWb2x1bWVzTGlzdFJldHVybkZvclhtbFJw Y10gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTc2KSBbMWMxY2Y0Zl0gQ291bGQgbm90 IGFzc29jaWF0ZQ0KIGJyaWNrICdvdmlydDM4Mzk6L21udC9kYXRhL3NyLXZvbHVtZTAxJyBvZiB2 b2x1bWUgJzkzZTM2Y2RjLWFiMWItNDFlYy1hYzdmLTk2NmNmMzg1NmI1OScgd2l0aCBjb3JyZWN0 IG5ldHdvcmsgYXMgbm8gZ2x1c3RlciBuZXR3b3JrIGZvdW5kIGluIGNsdXN0ZXIgJzc1YmQ2NGRl LTA0YjItNGE5OS05Y2QwLWI2M2U5MTliOWFjYSc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjIwMTYtMDYtMjMgMjI6MDg6NTks NjE4IFdBUk4mbmJzcDsgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuZ2x1c3Rlci5H bHVzdGVyVm9sdW1lc0xpc3RSZXR1cm5Gb3JYbWxScGNdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVy X1dvcmtlci03NikgWzFjMWNmNGZdIENvdWxkIG5vdCBhc3NvY2lhdGUNCiBicmljayAnb3ZpcnQz NDM1Oi9tbnQvZGF0YS9kaXN0cmlidXRlZCcgb2Ygdm9sdW1lICdiODg3YjA1ZS0yZWE2LTQ5NmUt OTU1Mi0xNTVkNjU4ZWVhYTYnIHdpdGggY29ycmVjdCBuZXR3b3JrIGFzIG5vIGdsdXN0ZXIgbmV0 d29yayBmb3VuZCBpbiBjbHVzdGVyICc3NWJkNjRkZS0wNGIyLTRhOTktOWNkMC1iNjNlOTE5Yjlh Y2EnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj4yMDE2LTA2LTIzIDIyOjA4OjU5LDYyMCBXQVJOJm5ic3A7IFtvcmcub3ZpcnQu ZW5naW5lLmNvcmUudmRzYnJva2VyLmdsdXN0ZXIuR2x1c3RlclZvbHVtZXNMaXN0UmV0dXJuRm9y WG1sUnBjXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItNzYpIFsxYzFjZjRmXSBDb3Vs ZCBub3QgYXNzb2NpYXRlDQogYnJpY2sgJ292aXJ0MzYzNzovbW50L2RhdGEvZGlzdHJpYnV0ZWQn IG9mIHZvbHVtZSAnYjg4N2IwNWUtMmVhNi00OTZlLTk1NTItMTU1ZDY1OGVlYWE2JyB3aXRoIGNv cnJlY3QgbmV0d29yayBhcyBubyBnbHVzdGVyIG5ldHdvcmsgZm91bmQgaW4gY2x1c3RlciAnNzVi ZDY0ZGUtMDRiMi00YTk5LTljZDAtYjYzZTkxOWI5YWNhJzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+MjAxNi0wNi0yMyAyMjow ODo1OSw2MjIgV0FSTiZuYnNwOyBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci5nbHVz dGVyLkdsdXN0ZXJWb2x1bWVzTGlzdFJldHVybkZvclhtbFJwY10gKERlZmF1bHRRdWFydHpTY2hl ZHVsZXJfV29ya2VyLTc2KSBbMWMxY2Y0Zl0gQ291bGQgbm90IGFzc29jaWF0ZQ0KIGJyaWNrICdv dmlydDM4Mzk6L21udC9kYXRhL2Rpc3RyaWJ1dGVkJyBvZiB2b2x1bWUgJ2I4ODdiMDVlLTJlYTYt NDk2ZS05NTUyLTE1NWQ2NThlZWFhNicgd2l0aCBjb3JyZWN0IG5ldHdvcmsgYXMgbm8gZ2x1c3Rl ciBuZXR3b3JrIGZvdW5kIGluIGNsdXN0ZXIgJzc1YmQ2NGRlLTA0YjItNGE5OS05Y2QwLWI2M2U5 MTliOWFjYSc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPjIwMTYtMDYtMjMgMjI6MDg6NTksNjI0IFdBUk4mbmJzcDsgW29yZy5v dmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuZ2x1c3Rlci5HbHVzdGVyVm9sdW1lc0xpc3RSZXR1 cm5Gb3JYbWxScGNdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci03NikgWzFjMWNmNGZd IENvdWxkIG5vdCBhc3NvY2lhdGUNCiBicmljayAnb3ZpcnQzNDM1Oi9tbnQvZGF0YS9pc28nIG9m IHZvbHVtZSAnODlmMzI0NTctYzhjMy00OTBlLWI0OTEtMTZkZDI3ZGUwMDczJyB3aXRoIGNvcnJl Y3QgbmV0d29yayBhcyBubyBnbHVzdGVyIG5ldHdvcmsgZm91bmQgaW4gY2x1c3RlciAnNzViZDY0 ZGUtMDRiMi00YTk5LTljZDAtYjYzZTkxOWI5YWNhJzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+MjAxNi0wNi0yMyAyMjowODo1 OSw2MjYgV0FSTiZuYnNwOyBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci5nbHVzdGVy LkdsdXN0ZXJWb2x1bWVzTGlzdFJldHVybkZvclhtbFJwY10gKERlZmF1bHRRdWFydHpTY2hlZHVs ZXJfV29ya2VyLTc2KSBbMWMxY2Y0Zl0gQ291bGQgbm90IGFzc29jaWF0ZQ0KIGJyaWNrICdvdmly dDM2Mzc6L21udC9kYXRhL2lzbycgb2Ygdm9sdW1lICc4OWYzMjQ1Ny1jOGMzLTQ5MGUtYjQ5MS0x NmRkMjdkZTAwNzMnIHdpdGggY29ycmVjdCBuZXR3b3JrIGFzIG5vIGdsdXN0ZXIgbmV0d29yayBm b3VuZCBpbiBjbHVzdGVyICc3NWJkNjRkZS0wNGIyLTRhOTktOWNkMC1iNjNlOTE5YjlhY2EnPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj4yMDE2LTA2LTIzIDIyOjA4OjU5LDYyOCBXQVJOJm5ic3A7IFtvcmcub3ZpcnQuZW5naW5l LmNvcmUudmRzYnJva2VyLmdsdXN0ZXIuR2x1c3RlclZvbHVtZXNMaXN0UmV0dXJuRm9yWG1sUnBj XSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItNzYpIFsxYzFjZjRmXSBDb3VsZCBub3Qg YXNzb2NpYXRlDQogYnJpY2sgJ292aXJ0MzgzOTovbW50L2RhdGEvaXNvJyBvZiB2b2x1bWUgJzg5 ZjMyNDU3LWM4YzMtNDkwZS1iNDkxLTE2ZGQyN2RlMDA3Mycgd2l0aCBjb3JyZWN0IG5ldHdvcmsg YXMgbm8gZ2x1c3RlciBuZXR3b3JrIGZvdW5kIGluIGNsdXN0ZXIgJzc1YmQ2NGRlLTA0YjItNGE5 OS05Y2QwLWI2M2U5MTliOWFjYSc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjIwMTYtMDYtMjMgMjI6MDg6NTksNjI5IElORk8m bmJzcDsgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuZ2x1c3Rlci5HbHVzdGVyVm9s dW1lc0xpc3RWRFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItNzYpIFsx YzFjZjRmXSBGSU5JU0gsIEdsdXN0ZXJWb2x1bWVzTGlzdFZEU0NvbW1hbmQsDQogcmV0dXJuOiB7 Yjg4N2IwNWUtMmVhNi00OTZlLTk1NTItMTU1ZDY1OGVlYWE2PW9yZy5vdmlydC5lbmdpbmUuY29y ZS5jb21tb24uYnVzaW5lc3NlbnRpdGllcy5nbHVzdGVyLkdsdXN0ZXJWb2x1bWVFbnRpdHlAZDhj OTAzOWIsIDkzZTM2Y2RjLWFiMWItNDFlYy1hYzdmLTk2NmNmMzg1NmI1OT1vcmcub3ZpcnQuZW5n aW5lLmNvcmUuY29tbW9uLmJ1c2luZXNzZW50aXRpZXMuZ2x1c3Rlci5HbHVzdGVyVm9sdW1lRW50 aXR5QGZlNWFiMDE5LCA4OWYzMjQ1Ny1jOGMzLTQ5MGUtYjQ5MS0xNmRkMjdkZTAwNzM9b3JnLm92 aXJ0LmVuZ2luZS5jb3JlLmNvbW1vbi5idXNpbmVzc2VudGl0aWVzLmdsdXN0ZXIuR2x1c3RlclZv bHVtZUVudGl0eUA5YTU2ZDYzM30sDQogbG9nIGlkOiA0ODVhMDYxMTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+MjAxNi0wNi0y MyAyMjowOTowNCw2NDUgSU5GTyZuYnNwOyBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tl ci5nbHVzdGVyLkdsdXN0ZXJWb2x1bWVzTGlzdFZEU0NvbW1hbmRdIChEZWZhdWx0UXVhcnR6U2No ZWR1bGVyX1dvcmtlci04OSkgW10gU1RBUlQsIEdsdXN0ZXJWb2x1bWVzTGlzdFZEU0NvbW1hbmQo SG9zdE5hbWUNCiA9IG92aXJ0MzgzOSwgR2x1c3RlclZvbHVtZXNMaXN0VkRTUGFyYW1ldGVyczp7 cnVuQXN5bmM9J3RydWUnLCBob3N0SWQ9JzMyYzUwMGU1LTI2OGQtNDI2YS05YTRhLTEwODUzNWU2 NzcyMid9KSwgbG9nIGlkOiA0MWI2NDc5ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_CO2PR0801MB0743180FC142ED11D7D5D3E0A62E0CO2PR0801MB0743_--

3 2

oVirt 3.6 to 4.0 Upgrade
by Brett I. Holcomb 27 Jun '16

27 Jun '16

In order to not hijack another thread I wanted to separate this from the "latest CentOS libvirt updates safe?" thread since this is different than what the OP on that thread wants to do. I've been digging through the 4.0 documentation since I'd like to upgrade in the not to distant future so I'm doing research and I'm confused. I'm running 3.6.6 in a hosted Engine environment. My engine runs in a vm on the host. The host is a physical box and the VMs are stored on a NAS accessed by an iSCSI LUN, I have no other hosts running so I can not migrate. According to this link, https://www.ovirt.org/release/4.0.0/, I'm told to simply run yum update ovirt-engine-setup and then engine-setup but I assume that's for a non hosted-engine environment. I then go to the link for Hosted_Engine_HOwto#Upgrade_Hosted_Engine guide and am told to do this. Set hosted-engine maintenance mode to global and other stuff that is written assuming I have some place to migrate my VMs to. I do not have another host. So how do I properly move to oVirt 4.0 from 3.6.6 on a single physical host running a hosted Engine VM? Thanks.

3 4

Maintenance and hosted engine issue with Ovirt 4.0
by Bertrand Caplet 26 Jun '16

26 Jun '16

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3h4m2hcgdjFHtq8mNeaCD5hu0pIJG26iX Content-Type: multipart/mixed; boundary="GFM2vDbBGUeA0wNJT7d6kjCp8ADn59Dsq" From: Bertrand Caplet <bertrand.caplet(a)chunkz.net> To: users <users(a)ovirt.org> Message-ID: <4e5a6b1b-4360-2582-190f-d9d96fac3b2c(a)chunkz.net> Subject: Maintenance and hosted engine issue with Ovirt 4.0 --GFM2vDbBGUeA0wNJT7d6kjCp8ADn59Dsq Content-Type: multipart/alternative; boundary="------------C3B1797A5CA6C32E68FD0BE3" This is a multi-part message in MIME format. --------------C3B1797A5CA6C32E68FD0BE3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi there, I have hosted engine configured in my infrastructure and I just upgraded from Ovirt 3.6 to Ovirt 4.0 yesterday. Upgrade of hosted engine and my 2 nodes did ok. But now when I put one node in maintenance, it prepares for maintenance ; unset SPM if it was then migrate all the VMs to the another node. All of this steps are ok but VM stays locked and in migration mode like this : =2E Btw for the hosted engine I did migrate it manually. So all the others VMs are stuck locked and in migration mode. I did noticed every 10 minutes or so (pretty random), the ovirt-hosted-engine HA is sending mail in this order : 1. EngineUnexpectedlyDown 2. (StartState-ReinitializeFSM sometimes) 3. EngineDown-EngineStart 4. EngineStart-EngineStarting 5. EngineStarting-EngineUnexpectedlyDown 6. Repeat The hosted engine is pingable all this long, the web UI is reacheable all this long too. Anyone having this type of issues ? Do I open a bug on BugZilla ? Thanks in advance, Regards, --=20 CHUNKZ.NET - script kiddie and computer technician Bertrand Caplet, Flers (FR) Feel free to send encrypted/signed messages Key ID: 6E494EB9 GPG FP: CB1B 664A 9165 98F8 459F 0807 CA35 B76F 6E49 4EB9 --------------C3B1797A5CA6C32E68FD0BE3 Content-Type: multipart/related; boundary="------------DF0929E39F7F44B41DB6C2AC" --------------DF0929E39F7F44B41DB6C2AC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf= -8"> </head> <body bgcolor=3D"#FFFFFF" text=3D"#000000"> Hi there, I have hosted engine configured in my infrastructure and I just upgraded from Ovirt 3.6 to Ovirt 4.0 yesterday. Upgrade of hosted engine and my 2 nodes did ok. But now when I put one node in maintenance, it prepares for maintenance ; unset SPM if it was then migrate all the VMs to the another node. All of this steps are ok but VM stays locked and in migration mode like this : <img src=3D"cid:part1.10023D7D.B57AAA47@chunkz.net" alt=3D"">. Btw = for the hosted engine I did migrate it manually. So all the others VMs are stuck locked and in migration mode. = I did noticed every 10 minutes or so (pretty random), the ovirt-hosted-engine HA is sending mail in this order : <ol> <li>EngineUnexpectedlyDown</li> <li>(StartState-ReinitializeFSM sometimes) </li> <li>EngineDown-EngineStart</li> <li>EngineStart-EngineStarting</li> <li>EngineStarting-EngineUnexpectedlyDown</li> <li>Repeat</li> </ol> The hosted engine is pingable all this long, the web UI is reacheable all this long too. Anyone having this type of issues ? Do I open a bug on BugZilla ?<= br> Thanks in advance, Regards, <pre class=3D"moz-signature" cols=3D"72">--=20 CHUNKZ.NET - script kiddie and computer technician Bertrand Caplet, Flers (FR) Feel free to send encrypted/signed messages Key ID: 6E494EB9 GPG FP: CB1B 664A 9165 98F8 459F 0807 CA35 B76F 6E49 4EB9</pre> </body> </html> --------------DF0929E39F7F44B41DB6C2AC Content-Type: image/png; name="fommfmefonkedboc.png" Content-Transfer-Encoding: base64 Content-ID: <part1.10023D7D.B57AAA47(a)chunkz.net> Content-Disposition: inline; filename="fommfmefonkedboc.png" iVBORw0KGgoAAAANSUhEUgAAABYAAAAUCAIAAAAGHlpnAAAC20lEQVQ4jbWUz08TQRTH38mb JzXeTLz4JxiTRhOKeIda4tXLHk16QDhZAnJgS0sCCmmUAgYVEgXa0FJrQ+svaLu0lN8trFBK +SFCpd0tszO73fFQKEJq1BBf3mFmvpnPe3kz74GA5DM6/C/EQjwV4GJchI/zW6ek5EY6wMVC 4djC0vpvEYvLqckoj7Aq5NSp6cT0/EpR2vwmcBH+AKvZnBqdXYnO8iUQiaQQisxjQrGMMrJM ZfreFS5I8cT6eHgDE4rzNCchkqejnokSiBCXQjKVCM1kcxlJJRh//jRpt3vbW2wD/S4xT7BC 0xkxeyAhon74MlMCEQitZw/yRKEYqyJSM1nVPRZpsfSpkmq2tA47AzlJzSEVK3Q/q7g9oRKI 8eDq4tJ2OLKKiTo85Gsyd9SbX5jaXyH5AMu0ucX2euAdJnRzW/y68mPMP30CYevptfX0mi2d 27uYm1xJpXZaLc+kfF5WqYiwolBCiCJTk7krufF9PSXE4mmvL3qMaGhoZI6s8fHj9L6SFeT+ t05zc3cn221hn0uUYklpY1++sfszIl7mdyNTG24Pd4iw9fQWLnu8vsLiyVMrJnSO3xn3J1xD wfqO3oF496O2Lsegb35pD+fpMr/n88Wc7qMXqa2tYximkI53bI5hmIe1dZgoM/GMw8Etb21V tOvAdON63Z3tXXFfUBAhc/ObTtcUv7p3iChELhalsEWE2p0LybXERbcGpGpAVecl3f2+B4Ho qqTIg66PS2u7x7+TKWXDjkByLXHBowGkA3QXUDWgqkuivmnCNOKYSibXTvQIwzA1NTUsy1qt VqvVyrJsIakroxqQ7oGoA6ESkB5QNSAdCPprI5rTbVZEMAxTRFy1awBVAdJBTg85HSAdiJWH J0h/zn/rzwiIlENQC5FyCJcDpwVOC0EtBMsgWAHBMgjdvjx68wTCYDAYjUaDwcCyrNFo/LW6 fzUvSpbzrCPnn/wniysT9kzcu9gAAAAASUVORK5CYII= --------------DF0929E39F7F44B41DB6C2AC-- --------------C3B1797A5CA6C32E68FD0BE3-- --GFM2vDbBGUeA0wNJT7d6kjCp8ADn59Dsq-- --3h4m2hcgdjFHtq8mNeaCD5hu0pIJG26iX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXb/IoAAoJEMo1t29uSU65+RAIAL8pHJrSmvNoYJfJ1LRZ3um1 frq6pP+9ChcSE+eBl+Cvb2T1wB1cJiuxrmKqrVnh1wN9CSwc8mVJe77aPhyY8exg 5pqRXmzh0t8A+hQ0KvARZso++CkcgXx24EiZysM8KLQWfILkV22Sf/0XystdMFZd eTet81/9WA7IQNcGYR4Lp/Tz8b9QiBm0Z9zoRVRQN4GTzUm9MWm7utubDkDYtiJf oIKKAP0c8ll7YJ27KhUfQ/XiNH988TPx1V4P8SzADMnq31T9wXS8/YrmNV5o3roJ p6sDOtpmtSEas2rj8JT+4dbSxMQb5puYTGL17wxKNwbGnxaS2CGI9V7c9vu+WyU= =1BC8 -----END PGP SIGNATURE----- --3h4m2hcgdjFHtq8mNeaCD5hu0pIJG26iX--

2 1

oVirt 4.0 Host install fail cause of dnf api
by Pilař Vojtěch 26 Jun '16

26 Jun '16

--_000_c9bbad56edaa4f53be9de7805b8be891EX13nconzolocal_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi all, iam trying to install host from oVirt Engine Web Admin, but with no success= so far. Everything dies on sigCheckPkg bug from dnf (https://bugzilla.redh= at.com/show_bug.cgi?id=3D1344270) 2016-06-25 19:36:22 INFO otopi.plugins.otopi.packagers.dnfpackager dnfpacka= ger.info:79 DNF Downloaded libselinux-python-2.4-4.fc23.x86_64.rpm The 'sigCheckPkg' function is not a part of DNF API and will be removed in = the upcoming DNF release. Please use only officially supported API function= s. DNF API documentation is available at https://dnf.readthedocs.org/en/lat= est/api.html. 2016-06-25 19:36:22 ERROR otopi.plugins.otopi.packagers.dnfpackager dnfpack= ager.error:84 DNF 'NoneType' object is not iterable 2016-06-25 19:36:22 DEBUG otopi.plugins.otopi.packagers.dnfpackager dnfpack= ager.verbose:75 DNF Closing transaction with rollback Is there any workaround? I see no way to deploy hosts. (Fedora 23, oVirt 4.0) Thank you for help --_000_c9bbad56edaa4f53be9de7805b8be891EX13nconzolocal_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 2"> <style type=3D"text/css" style=3D"display:none"></style> </head> <body> <div style=3D"font-size:12pt;color:#000000;background-color:#FFFFFF;font-fa= mily:Calibri,Arial,Helvetica,sans-serif;"> Hi all, iam trying to install host from oVirt Engine Web Admin, but with no success= so far. Everything dies on sigCheckPkg bug from dnf (https://bugzilla.redh= at.com/show_bug.cgi?id=3D1344270) 2016-06-25 19:36:22 INFO otopi.plugins.oto= pi.packagers.dnfpackager dnfpackager.info:79 DNF Downloaded libselinux-pyth= on-2.4-4.fc23.x86_64.rpm The 'sigCheckPkg' function is not a part o= f DNF API and will be removed in the upcoming DNF release. Please use only = officially supported API functions. DNF API documentation is available at h= ttps://dnf.readthedocs.org/en/latest/api.html. 2016-06-25 19:36:22 ERROR otopi.plugins.ot= opi.packagers.dnfpackager dnfpackager.error:84 DNF 'NoneType' object is not= iterable 2016-06-25 19:36:22 DEBUG otopi.plugins.ot= opi.packagers.dnfpackager dnfpackager.verbose:75 DNF Closing transaction wi= th rollback Is there any workaround? I see no way to deploy hosts. (Fedora 23, oVirt 4.0) Thank you for help </div> </body> </html> --_000_c9bbad56edaa4f53be9de7805b8be891EX13nconzolocal_--

2 3

oVirt/RHEV and HP Blades and HP iSCSI SAN
by Colin Coe 26 Jun '16

26 Jun '16

Hi all We run four RHEV datacenters, two PROD, one DEV and one TEST/Training. They are all working OK but I'd like a definitive answer on how I should be configuring the networking side as I'm pretty sure we're getting sub-optimal networking performance. All datacenters are housed in HP C7000 Blade enclosures. The PROD datacenters use HP 4730 iSCSI SAN clusters, each datacenter has a cluster of two 4730s. These are configured RAID5 internally with NRAID1. The DEV and TEST datacenters are using P4500 iSCSI SANs and each datacenter has a cluster of three P4500s configured with RAID10 internally and NRAID5. The HP C7000 each have two Flex10/10D interconnect modules configured in a redundant ring so that we can upgrade the interconnects without dropping network connectivity to the infrastructure. We use fat RHEL-H 7.2 hypervisors (HP BL460) and these are all configured with six network interfaces: - eno1 and eno2 are bond0 which is the rhevm interface - eno3 and eno4 are bond1 and all the VM VLANs are trunked over this bond using 802.1q - eno5 and eno6 are bond2 and dedicated to iSCSI traffic Is this the "correct" way to do this? If not, what should I be doing instead? Thanks CC

3 6

Ovirt 4.0 Engine Setup Failure
by Melissa Mesler 25 Jun '16

25 Jun '16

I am doing a clean install of Ovirt 4.0. Upon executing engine-setup with all default values, it fails. This is the error during setup: [ ERROR ] Failed to execute stage 'Misc configuration': Command '/usr/bin/ovirt-aaa-jdbc-tool' failed to execute Any ideas?

3 6

Error mounting hosted engine Volume (Glusterfs) via VDSM
by Ralf Schenk 25 Jun '16

25 Jun '16

This is a multi-part message in MIME format. --------------490BE4DF07D0809CD094F385 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I think options for mounting the hosted-engine Volume changed in latest vdsm to support mounting from backup-volfile-servers. [root@microcloud28 ~]# rpm -qi vdsm Name : vdsm Version : 4.17.28 Release : 1.el7 Architecture: noarch Install Date: Fri 10 Jun 2016 11:17:37 AM CEST Group : Applications/System Size : 3828639 License : GPLv2+ Signature : RSA/SHA1, Fri 03 Jun 2016 12:53:20 AM CEST, Key ID 7aebbe8261e8806c Source RPM : vdsm-4.17.28-1.el7.src.rpm Now my hosts have problems to mount the Volume. On hosted-engine setup I configured the (Replica 3) volume to be "glusterfs.rxmgmt.databay.de:/engine" which ist a Round-Robin DNS to my gluster hosts and _not_ the DNS-Name of any gluster-brick. Now VDSM logs: jsonrpc.Executor/3::DEBUG::2016-06-25 19:40:02,520::fileUtils::143::Storage.fileUtils::(createdir) Cre ating directory: /rhev/data-center/mnt/glusterSD/glusterfs.rxmgmt.databay.de:_engine mode: None jsonrpc.Executor/3::DEBUG::2016-06-25 19:40:02,520::storageServer::364::Storage.StorageServer.MountCon nection::(_get_backup_servers_option) Using bricks: ['microcloud21.rxmgmt.databay.de', 'microcloud24.r xmgmt.databay.de', 'microcloud27.rxmgmt.databay.de'] jsonrpc.Executor/3::WARNING::2016-06-25 19:40:02,520::storageServer::370::Storage.StorageServer.MountC onnection::(_get_backup_servers_option) gluster server u'glusterfs.rxmgmt.databay.de' is not in bricks ['microcloud21.rxmgmt.databay.de', 'microcloud24.rxmgmt.databay.de', 'microcloud27.rxmgmt.databay.de' ], possibly mounting duplicate servers jsonrpc.Executor/3::DEBUG::2016-06-25 19:40:02,520::mount::229::Storage.Misc.excCmd::(_runcmd) /usr/bi n/taskset --cpu-list 0-7 /usr/bin/sudo -n /usr/bin/systemd-run --scope --slice=3Dvdsm-glusterfs /usr/bin /mount -o backup-volfile-servers=3Dmicrocloud21.rxmgmt.databay.de:microcloud24.rxmg= mt.databay.de:microcl oud27.rxmgmt.databay.de glusterfs.rxmgmt.databay.de:/engine /rhev/data-center/mnt/glusterSD/glusterfs. rxmgmt.databay.de:_engine (cwd None) jsonrpc.Executor/3::ERROR::2016-06-25 19:40:02,540::hsm::2473::Storage.HSM::(connectStorageServer) Cou ld not connect to storageServer Traceback (most recent call last): File "/usr/share/vdsm/storage/hsm.py", line 2470, in connectStorageServ= er conObj.connect() File "/usr/share/vdsm/storage/storageServer.py", line 237, in connect six.reraise(t, v, tb) File "/usr/share/vdsm/storage/storageServer.py", line 229, in connect self._mount.mount(self.options, self._vfsType, cgroup=3Dself.CGROUP) File "/usr/share/vdsm/storage/mount.py", line 225, in mount return self._runcmd(cmd, timeout) File "/usr/share/vdsm/storage/mount.py", line 241, in _runcmd raise MountError(rc, ";".join((out, err))) MountError: (32, ';Running scope as unit run-13461.scope.\nmount.nfs: an incorrect mount option was specified\n') So the mount is tried as NFS which hasn't the option "-o backup-volfile-servers=3D...". As a consequence the host is disabled in engine. The only way to get it up is mounting the volume manually to /rhev/data-center/mnt/glusterSD/glusterfs. rxmgmt.databay.de:_engine and activate it manually in Management-GUI. Should and can I change the hosted_storage entry-point globally to i.e. "microcloud21.rxmgmt.databay.de" or wouldn't it be better globally that VDSM uses "-t glusterfs" to try to mount the gluster-Volume regardless which DNS Name for the gluster-service is used ? Ovirt is: ovirt-release36.noarch 1:3.6.6-1 Bye --=20 *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> =09 *Databay AG* Jens-Otto-Krag-Stra=C3=9Fe 11 D-52146 W=C3=BCrselen *www.databay.de* <http://www.databay.de> Sitz/Amtsgericht Aachen =E2=80=A2 HRB:8437 =E2=80=A2 USt-IdNr.: DE 210844= 202 Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns Aufsichtsratsvorsitzender: Klaus Scholzen (RA) ------------------------------------------------------------------------ --------------490BE4DF07D0809CD094F385 Content-Type: multipart/related; boundary="------------9EB1620A3DC18A1D6499F226" --------------9EB1620A3DC18A1D6499F226 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 think options for mounting the hosted-engine Volume changed in latest vdsm to support mounting from backup-volfile-servers. <tt>[root@microcloud28 ~]# rpm -qi vdsm</tt><tt> </tt><tt>Name : vdsm</tt><tt> </tt><tt>Version : 4.17.28</tt><tt> </tt><tt>Release : 1.el7</tt><tt> </tt><tt>Architecture: noarch</tt><tt> </tt><tt>Install Date: Fri 10 Jun 2016 11:17:37 AM CEST</tt><tt> </tt><tt>Group : Applications/System</tt><tt> </tt><tt>Size : 3828639</tt><tt> </tt><tt>License : GPLv2+</tt><tt> </tt><tt>Signature : RSA/SHA1, Fri 03 Jun 2016 12:53:20 AM CEST, Key ID 7aebbe8261e8806c</tt><tt> </tt><tt>Source RPM : vdsm-4.17.28-1.el7.src.rpm</tt><tt> </tt> Now my hosts have problems to mount the Volume. On hosted-engine setup I configured the (Replica 3) volume to be "glusterfs.rxmgmt.databay.de:/engine" which ist a Round-Robin DNS to my gluster hosts and _not_ the DNS-Name of any gluster-brick. Now VDSM logs: <tt>jsonrpc.Executor/3::DEBUG::2016-06-25 19:40:02,520::fileUtils::143::Storage.fileUtils::(createdir) Cre</tt><tt> </tt><tt>ating directory: /rhev/data-center/mnt/glusterSD/glusterfs.rxmgmt.databay.de:_engine mode: None</tt><tt> </tt><tt>jsonrpc.Executor/3::DEBUG::2016-06-25 19:40:02,520::storageServer::364::Storage.StorageServer.MountCon</tt><tt> </tt><tt>nection::(_get_backup_servers_option) Using bricks: ['microcloud21.rxmgmt.databay.de', 'microcloud24.r</tt><tt> </tt><tt>xmgmt.databay.de', 'microcloud27.rxmgmt.databay.de']</tt><tt> </tt><tt>jsonrpc.Executor/3::WARNING::2016-06-25 19:40:02,520::storageServer::370::Storage.StorageServer.MountC</tt><tt> </tt><tt>onnection::(_get_backup_servers_option) gluster server u'glusterfs.rxmgmt.databay.de' is not in bricks</tt><tt> </tt><tt> ['microcloud21.rxmgmt.databay.de', 'microcloud24.rxmgmt.databay.de', 'microcloud27.rxmgmt.databay.de'</tt><tt> </tt><tt>], possibly mounting duplicate servers</tt><tt> </tt><tt>jsonrpc.Executor/3::DEBUG::2016-06-25 19:40:02,520::mount::229::Storage.Misc.excCmd::(_runcmd) /usr/bi</tt><tt> </tt><tt>n/taskset --cpu-list 0-7 /usr/bin/sudo -n /usr/bin/systemd-run --scope --slice=vdsm-glusterfs /usr/bin</tt><tt> </tt><tt>/mount -o backup-volfile-servers=microcloud21.rxmgmt.databay.de:microcloud24.rxmgmt.databay.de:microcl</tt><tt> </tt><tt>oud27.rxmgmt.databay.de glusterfs.rxmgmt.databay.de:/engine /rhev/data-center/mnt/glusterSD/glusterfs.</tt><tt> </tt><tt>rxmgmt.databay.de:_engine (cwd None)</tt><tt> </tt><tt>jsonrpc.Executor/3::ERROR::2016-06-25 19:40:02,540::hsm::2473::Storage.HSM::(connectStorageServer) Cou</tt><tt> </tt><tt>ld not connect to storageServer</tt><tt> </tt><tt>Traceback (most recent call last):</tt><tt> </tt><tt> File "/usr/share/vdsm/storage/hsm.py", line 2470, in connectStorageServer</tt><tt> </tt><tt> conObj.connect()</tt><tt> </tt><tt> File "/usr/share/vdsm/storage/storageServer.py", line 237, in connect</tt><tt> </tt><tt> six.reraise(t, v, tb)</tt><tt> </tt><tt> File "/usr/share/vdsm/storage/storageServer.py", line 229, in connect</tt><tt> </tt><tt> self._mount.mount(self.options, self._vfsType, cgroup=self.CGROUP)</tt><tt> </tt><tt> File "/usr/share/vdsm/storage/mount.py", line 225, in mount</tt><tt> </tt><tt> return self._runcmd(cmd, timeout)</tt><tt> </tt><tt> File "/usr/share/vdsm/storage/mount.py", line 241, in _runcmd</tt><tt> </tt><tt> raise MountError(rc, ";".join((out, err)))</tt><tt> </tt><tt>MountError: (32, ';Running scope as unit run-13461.scope.\nmount.nfs: an incorrect mount option was specified\n')</tt><tt> </tt> So the mount is tried as NFS which hasn't the option "-o backup-volfile-servers=...". As a consequence the host is disabled in engine. The only way to get it up is mounting the volume manually to /rhev/data-center/mnt/glusterSD/glusterfs. rxmgmt.databay.de:_engine and activate it manually in Management-GUI. Should and can I change the hosted_storage entry-point globally to i.e. "microcloud21.rxmgmt.databay.de" or wouldn't it be better globally that VDSM uses "-t glusterfs" to try to mount the gluster-Volume regardless which DNS Name for the gluster-service is used ? Ovirt is: <tt>ovirt-release36.noarch 1:3.6.6-1</tt> Bye <div class="moz-signature">-- <table border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <td colspan="3"><img src="cid:part1.2FE99626.D833EF80@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> --------------9EB1620A3DC18A1D6499F226 Content-Type: image/gif; name="logo_databay_email.gif" Content-Transfer-Encoding: base64 Content-ID: <part1.2FE99626.D833EF80(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= --------------9EB1620A3DC18A1D6499F226-- --------------490BE4DF07D0809CD094F385--

1 1

Setup new enviroment
by Andy Michielsen 25 Jun '16

25 Jun '16

Hello all, I was just wondering what your opinions would be in setting up a new oVirt enviroment. I have 4 old servers, 3 with 64 Gigs of ram and 2 tera's of disk space an one with 32 Gigs of ram and 1,2 Gb. Each has 2 hexcore cpu's. Each server has at least 2 nic's. I would like to use each server in a seperate cluster with there own local storage as this would all only be used as a test enviroment but still would like to manage them from one interface. Deploy new vm's from templates etc. Can I still use the all in one installation for engine and node ? Or can I install the engine on a seperate host, physical or virtual. What would be a good way to use the network ? Any advice would be greatly appriciated. Thanks in advance.

3 5