May 2018 - Users - Ovirt List Archives

by Paul.LKW

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

2 years, 4 months

4
6
0 / 0

looking for some ISV backup software which integrates the backup API

by Nathanaël Blanchet

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-...). 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%20Enterp... 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?

2 years, 10 months

5
4
0 / 0

OVS switch type for hosted-engine

by Devin A. Bougie

Is it possible to setup a hosted engine using the OVS switch type instead of Legacy? If it's not possible to start out as OVS, instructions for switching from Legacy to OVS after the fact would be greatly appreciated. Many thanks, Devin

2 years, 11 months

4
5
2 / 0

USB3 redirection

by Rik Theys

Hi, I'm trying to assign a USB3 controller to a CentOS 7.4 VM in oVirt 4.1 with USB redirection enabled. I've created the following file in /etc/ovirt-engine/osinfo.conf.d: 01-usb.properties with content os.other.devices.usb.controller.value = nec-xhci and have restarted ovirt-engine. If I disable USB-support in the web interface for the VM, the xhci controller is added to the VM (I can see it in the qemu-kvm commandline), but usb redirection is not available. If I enable USB-support in the UI, no xhci controller is added (only 4 uhci controllers). Is there a way to make the controllers for usb redirection xhci controllers? Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 ---------------------------------------------------------------- <<Any errors in spelling, tact or fact are transmission errors>>

3 years

3
5
0 / 0

OVN routing and firewalling in oVirt

by Gianluca Cecchi

Hello, how do we manage routing between different OVN networks in oVirt? And between OVN networks and physical ones? Based on architecture read here: http://openvswitch.org/support/dist-docs/ovn-architecture.7.html I see terms for logical routers and gateway routers respectively but how to apply to oVirt configuration? Do I have to choose between setting up a specialized VM or a physical one: is it applicable/advisable to put on oVirt host itself the gateway functionality? Is there any security policy (like security groups in Openstack) to implement? Thanks, Gianluca

3 years

4
6
1 / 0

OVN and change of mgmt network

by Gianluca Cecchi

Hello, I previously had OVN running on engine (as OVN provider with northd and northbound and southbound DBs) and hosts (with OVN controller). After changing mgmt ip of hosts (engine has retained instead the same ip), I executed again on them the command: vdsm-tool ovn-config <ip_of_engine> <nel_local_ip_of_host> Now I think I have to clean up some things, eg: 1) On engine where I get these lines below systemctl status ovn-northd.service -l . . . Sep 29 14:41:42 ovmgr1 ovsdb-server[940]: ovs|00005|reconnect|ERR|tcp: 10.4.167.40:37272: no response to inactivity probe after 5 seconds, disconnecting Oct 03 11:52:00 ovmgr1 ovsdb-server[940]: ovs|00006|reconnect|ERR|tcp: 10.4.167.41:52078: no response to inactivity probe after 5 seconds, disconnecting The two IPs are the old ones of two hosts It seems that a restart of the services has fixed... Can anyone confirm if I have to do anything else? 2) On hosts (there are 3 hosts with OVN on ip 10.4.192.32/33/34) where I currently have this output [root@ov301 ~]# ovs-vsctl show 3a38c5bb-0abf-493d-a2e6-345af8aedfe3 Bridge br-int fail_mode: secure Port "ovn-1dce5b-0" Interface "ovn-1dce5b-0" type: geneve options: {csum="true", key=flow, remote_ip="10.4.192.32"} Port "ovn-ddecf0-0" Interface "ovn-ddecf0-0" type: geneve options: {csum="true", key=flow, remote_ip="10.4.192.33"} Port "ovn-fd413b-0" Interface "ovn-fd413b-0" type: geneve options: {csum="true", key=flow, remote_ip="10.4.168.74"} Port br-int Interface br-int type: internal ovs_version: "2.7.2" [root@ov301 ~]# The IPs of kind 10.4.192.x are ok. But there is a left-over of an old host I initially used for tests, corresponding to 10.4.168.74, that now doesn't exist anymore How can I clean records for 1) and 2)? Thanks, Gianluca

4 years, 3 months

3
4
0 / 0

deprecating export domain?

by Charles Kozler

Hello, I recently read on this list from a redhat member that export domain is either being deprecated or looking at being deprecated To that end, can you share details? Can you share any notes/postings/bz's that document this? I would imagine something like this would be discussed in larger audience This seems like a somewhat significant change to make and I am curious where this is scheduled? Currently, a lot of my backups rely explicitly on an export domain for online snapshots, so I'd like to plan accordingly Thanks!

4 years, 8 months

11
21
3 / 0

Vm suddenly paused with error "vm has paused due to unknown storage error"

by Jasper Siero

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

5 years, 2 months

3
3
0 / 0

Unable to find OVF_STORE after recovery / upgrade

by Sam Cappello

This is a multi-part message in MIME format. --------------05F3D0780062C6D37C1619A7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, so i was running a 3.4 hosted engine two node setup on centos 6, had some disk issues so i tried to upgrade to centos 7 and follow the path 3.4 > 3.5 > 3.6 > 4.0. i screwed up dig time somewhere between 3.6 and 4.0, so i wiped the drives, installed a fresh 4.0.3, then created the database and restored the 3.6 engine backup before running engine-setup as per the docs. things seemed to work, but i have the the following issues / symptoms: - ovirt-ha-agent running 100% CPU on both nodes - messages in the UI that the Hosted Engine storage Domain isn't active and Failed to import the Hosted Engine Storage Domain - hosted engine is not visible in the UI and the following repeating in the agent.log: MainThread::INFO::2016-10-03 12:38:27,718::hosted_engine::461::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring) Current state EngineUp (score: 3400) MainThread::INFO::2016-10-03 12:38:27,720::hosted_engine::466::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring) Best remote host vmhost1.oracool.net (id: 1, score: 3400) MainThread::INFO::2016-10-03 12:38:37,979::states::421::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(consume) Engine vm running on localhost MainThread::INFO::2016-10-03 12:38:37,985::hosted_engine::612::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_vdsm) Initializing VDSM MainThread::INFO::2016-10-03 12:38:45,645::hosted_engine::639::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_storage_images) Connecting the storage MainThread::INFO::2016-10-03 12:38:45,647::storage_server::219::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server) Connecting storage server MainThread::INFO::2016-10-03 12:39:00,543::storage_server::226::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server) Connecting storage server MainThread::INFO::2016-10-03 12:39:00,562::storage_server::233::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server) Refreshing the storage domain MainThread::INFO::2016-10-03 12:39:01,235::hosted_engine::666::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_storage_images) Preparing images MainThread::INFO::2016-10-03 12:39:01,236::image::126::ovirt_hosted_engine_ha.lib.image.Image::(prepare_images) Preparing images MainThread::INFO::2016-10-03 12:39:09,295::hosted_engine::669::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_storage_images) Reloading vm.conf from the shared storage domain MainThread::INFO::2016-10-03 12:39:09,296::config::206::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(refresh_local_conf_file) Trying to get a fresher copy of vm configuration from the OVF_STORE MainThread::WARNING::2016-10-03 12:39:16,928::ovf_store::107::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(scan) Unable to find OVF_STORE MainThread::ERROR::2016-10-03 12:39:16,934::config::235::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(refresh_local_conf_file) Unable to get vm.conf from OVF_STORE, falling back to initial vm.conf I have searched a bit and not really found a solution, and have come to the conclusion that i have made a mess of things, and am wondering if the best solution is to export the VMs, and reinstall everything then import them back? i am using remote NFS storage. if i try and add the hosted engine storage domain it says it is already registered. i have also upgraded and am now running oVirt Engine Version: 4.0.4.4-1.el7.centos hosts were installed using ovirt-node. currently at 3.10.0-327.28.3.el7.x86_64 if a fresh install is best, any advice / pointer to doc that explains best way to do this? i have not moved my most important server over to this cluster yet so i can take some downtime to reinstall. thanks! sam --------------05F3D0780062C6D37C1619A7 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"> Hi,<br> so i was running a 3.4 hosted engine two node setup on centos 6, had some disk issues so i tried to upgrade to centos 7 and follow the path 3.4 > 3.5 > 3.6 > 4.0. i screwed up dig time somewhere between 3.6 and 4.0, so i wiped the drives, installed a fresh 4.0.3, then created the database and restored the 3.6 engine backup before running engine-setup as per the docs. things seemed to work, but i have the the following issues / symptoms:<br> - ovirt-ha-agent running 100% CPU on both nodes<br> - messages in the UI that the Hosted Engine storage Domain isn't active and Failed to import the Hosted Engine Storage Domain<br> - hosted engine is not visible in the UI<br> and the following repeating in the agent.log:<br> <br> MainThread::INFO::2016-10-03 12:38:27,718::hosted_engine::461::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring) Current state EngineUp (score: 3400)<br> MainThread::INFO::2016-10-03 12:38:27,720::hosted_engine::466::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring) Best remote host vmhost1.oracool.net (id: 1, score: 3400)<br> MainThread::INFO::2016-10-03 12:38:37,979::states::421::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(consume) Engine vm running on localhost<br> MainThread::INFO::2016-10-03 12:38:37,985::hosted_engine::612::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_vdsm) Initializing VDSM<br> MainThread::INFO::2016-10-03 12:38:45,645::hosted_engine::639::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_storage_images) Connecting the storage<br> MainThread::INFO::2016-10-03 12:38:45,647::storage_server::219::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server) Connecting storage server<br> MainThread::INFO::2016-10-03 12:39:00,543::storage_server::226::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server) Connecting storage server<br> MainThread::INFO::2016-10-03 12:39:00,562::storage_server::233::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server) Refreshing the storage domain<br> MainThread::INFO::2016-10-03 12:39:01,235::hosted_engine::666::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_storage_images) Preparing images<br> MainThread::INFO::2016-10-03 12:39:01,236::image::126::ovirt_hosted_engine_ha.lib.image.Image::(prepare_images) Preparing images<br> MainThread::INFO::2016-10-03 12:39:09,295::hosted_engine::669::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_storage_images) Reloading vm.conf from the shared storage domain<br> MainThread::INFO::2016-10-03 12:39:09,296::config::206::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(refresh_local_conf_file) Trying to get a fresher copy of vm configuration from the OVF_STORE<br> MainThread::WARNING::2016-10-03 12:39:16,928::ovf_store::107::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(scan) Unable to find OVF_STORE<br> MainThread::ERROR::2016-10-03 12:39:16,934::config::235::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(refresh_local_conf_file) Unable to get vm.conf from OVF_STORE, falling back to initial vm.conf<br> <br> I have searched a bit and not really found a solution, and have come to the conclusion that i have made a mess of things, and am wondering if the best solution is to export the VMs, and reinstall everything then import them back?<br> i am using remote NFS storage.<br> if i try and add the hosted engine storage domain it says it is already registered.<br> i have also upgraded and am now running <span class="gwt-InlineLabel">oVirt Engine Version: 4.0.4.4-1.el7.centos<br> hosts were installed using ovirt-node. currently at 3.10.0-327.28.3.el7.x86_64<br> if a fresh install is best, any advice / pointer to doc that explains best way to do this?<br> i have not moved my most important server over to this cluster yet so i can take some downtime to reinstall.<br> thanks!<br> sam<br> <br> </span><br> </body> </html> --------------05F3D0780062C6D37C1619A7--

5 years, 11 months

3
2
0 / 0

[Users] Problem Creating "oVirtEngine" Machine

by Richie＠HIP

--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><br></div><div>FIRST - MACHINE IPs.</div><ul = class=3D"MailOutline"><li>THe machine's "Names" where not appearing in = the <b>Microsoft Active Directory DHCP</b> 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><b>NOTE</b> - 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><br = class=3D"webkit-block-placeholder"></div><div>Now that I have the DHCP / = IP thing sorted, I have to do the DNS stuff.</div><div><br></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 "<b><i>as long as I = do not use default  HTTPd service parameters as suggested by the = install</i></b>".  <b>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</b>=85 = YET=85!!!</div><div><br></div><div>More to come during the = week</div><div><br></div><div>Richie</div><div = apple-content-edited=3D"true"><br>Jos=E9 E ("Richie") Piovanetti, MD, = MS <br>M: 787-615-4884 | <a = href=3D"mailto:richiepiovanetti@healthcareinfopartners.com">richiepiovanet= ti(a)healthcareinfopartners.com</a><br><br><br><br><br><br></div><br><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><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite">Hello Ritchie,<br><br><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.<br><br>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?<br><br><br><br>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).<br><br>Any suggestions are MORE THAN WELCOME=85!!!<br> =  <br></blockquote><br>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.<br>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)<br><br>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.<br><br>Regards,<br><br>Joop<br><br></blockquote></div><br></div></b= ody></html>= --Apple-Mail=_DF4BF6D1-1F87-4F60-9CF9-070D4D836241--

5 years, 11 months

2
1
0 / 0

Re: [ovirt-users] Question about the ovirt-engine-sdk-java

by Michael Pasternak

------=_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"><span id=3D"yui_3_16_0_1_1445160422533_= 4552">Hi </span><span style=3D"font-family: 'Helvetica Neue', 'Segoe U= I', Helvetica, Arial, 'Lucida Grande', sans-serif;" id=3D"yui_3_16_0_1_1445= 160422533_3568" class=3D"">Salifou,</span></div><div id=3D"yui_3_16_0_1_144= 5160422533_3555" dir=3D"ltr"><span style=3D"font-family: 'Helvetica Neue', = 'Segoe UI', Helvetica, Arial, 'Lucida Grande', sans-serif;" class=3D""><br>= </span></div><div id=3D"yui_3_16_0_1_1445160422533_3555" dir=3D"ltr"><span = style=3D"font-family: 'Helvetica Neue', 'Segoe UI', Helvetica, Arial, 'Luci= da Grande', sans-serif;" class=3D"" id=3D"yui_3_16_0_1_1445160422533_3595">= Actually java sdk is </span><span style=3D"font-family: 'Helvetica Neu= e', 'Segoe UI', Helvetica, Arial, 'Lucida Grande', sans-serif;" id=3D"yui_3= _16_0_1_1445160422533_4360" class=3D"">intentionally </span><span styl= e=3D"font-family: 'Helvetica Neue', 'Segoe UI', Helvetica, Arial, 'Lucida G= rande', sans-serif;" id=3D"yui_3_16_0_1_1445160422533_4362" class=3D"">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"><span class= =3D"" id=3D"yui_3_16_0_1_1445160422533_4435"><font face=3D"Helvetica Neue, = Segoe UI, Helvetica, Arial, Lucida Grande, sans-serif" id=3D"yui_3_16_0_1_1= 445160422533_4432" class=3D"">if your headers are static, easiest way would= be using reverse proxy in a middle to intercept requests, </font><br>= </span></div><div id=3D"yui_3_16_0_1_1445160422533_3555" dir=3D"ltr"><span = class=3D""><font face=3D"Helvetica Neue, Segoe UI, Helvetica, Arial, Lucida= Grande, sans-serif" class=3D""><br></font></span></div><div id=3D"yui_3_16= _0_1_1445160422533_3555" dir=3D"ltr"><span style=3D"font-family: 'Helvetica= Neue', 'Segoe UI', Helvetica, Arial, 'Lucida Grande', sans-serif;" id=3D"y= ui_3_16_0_1_1445160422533_4357">can you tell me why do you need this?</span= ><br></div> <br><div class=3D"qtdSeparateBR"><br><br></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"> <font size=3D"2" face=3D"Arial"> On Friday, O= ctober 16, 2015 1:14 AM, Salifou Sidi M. Malick <ssidimah(a)redhat.com>= wrote:<br> </font> </div> <br><br> <div class=3D"y_msg_container">Hi Mich= eal,<br><br>I have a question about the ovirt-engine-sdk-java.<br><br>Is th= ere a way to add custom request headers to each RHEVM API call?<br><br>Here= is an example of a request that I would like to do:<br><br>$ 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>" \<br>&nbsp= ;         -H "PASSWORD: Pwssd" \<br>    &nbsp= ;     -H "TARGET: kobe" \<br>          <= a href=3D"https://vm0.smalick.com/api/hosts" target=3D"_blank">https://vm0.= smalick.com/api/hosts</a><br><br><br>I would like to add ID, PASSWORD and T= ARGET as HTTP request header. <br><br>Thanks,<br>Salifou<br><br><br><br></d= iv> </div> </div> </div></div></body></html> ------=_Part_1975902_834617789.1445161505459--

5 years, 11 months

2
1
0 / 0

[Users] oVirt Weekly Sync Meeting Minutes -- 2012-05-23

by Mike Burns

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

5 years, 11 months

2
1
0 / 0

[QE][ACTION REQUIRED] oVirt 3.5.1 RC status - postponed

by Sandro Bonazzola

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

5 years, 11 months

2
1
0 / 0

VM has paused due to no storage space error

by Sandvik Agustin

Hi users, I have this problem that sometimes 1 to 3 VM just automatically paused with user interaction and getting this error "VM has paused due to no storage space error". any inputs from you guys are very appreciated. TIA Sandvik

5 years, 11 months

5
5
0 / 0

VM Import from remote libvirt Server on web gui with Host key verification failed or permission denied error

by Rogério Ceni Coelho

Hi Ovirt Jedi´s !!! First of all, congratulations for this amazing product. I am an Vmware and Hyper-V Engineer but i am very excited with oVirt. Now, let´s go to work ... :-) I am trying to Import vm from remote libvirt server on web gui but i was unable to solve the problem until now. [image: pasted1] Node logs : [root@hlg-rbs-ovirt-kvm01-poa ~]# tail -f /var/log/vdsm/vdsm.log | grep -i error | grep -v Host.getStats jsonrpc.Executor/0::ERROR::2016-10-06 10:24:52,432::v2v::151::root::(get_external_vms) error connection to hypervisor: 'Cannot recv data: Permission denied, please try again.\r\nPermission denied, please try again.\r\nPermission denied (publickey,gssapi-keyex,gssapi-with-mic,password).: Connection reset by peer' jsonrpc.Executor/0::INFO::2016-10-06 10:24:52,433::__init__::513::jsonrpc.JsonRpcServer::(_serveRequest) RPC call Host.getExternalVMs failed (error 65) in 10.05 seconds [root@hlg-rbs-ovirt-kvm02-poa ~]# grep error /var/log/vdsm/vdsm.log | grep get_external_vms jsonrpc.Executor/7::ERROR::2016-10-06 10:25:37,344::v2v::151::root::(get_external_vms) error connection to hypervisor: 'Cannot recv data: Host key verification failed.: Connection reset by peer' [root@hlg-rbs-ovirt-kvm02-poa ~]# Engine Logs : [root@hlg-rbs-ovirt01-poa ~]# tail -f /var/log/ovirt-engine/engine.log 2016-10-06 10:24:42,377 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-97) [] START, GetVmsFromExternalProviderVDSCommand(HostName = hlg-rbs-ovirt-kvm01-poa.rbs.com.br, GetVmsFromExternalProviderParameters:{runAsync='true', hostId='5feddfba-d7b2-423e-a946-ac2bf36906fa', url='qemu+ssh:// root(a)prd-openshift-kvm03-poa.rbs.com.br/system', username='root', originType='KVM'}), log id: eb750c7 *2016-10-06 10:24:53,435 WARN [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-97) [] Unexpected return value: StatusForXmlRpc [code=65, message=Cannot recv data: Permission denied, please try again.* *Permission denied, please try again.* *Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).: Connection reset by peer]* 2016-10-06 10:24:53,435 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-97) [] Failed in 'GetVmsFromExternalProviderVDS' method 2016-10-06 10:24:53,435 WARN [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-97) [] Unexpected return value: StatusForXmlRpc [code=65, message=Cannot recv data: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).: Connection reset by peer] 2016-10-06 10:24:53,454 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-97) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: VDSM hlg-rbs-ovirt-kvm01-poa.rbs.com.br command failed: Cannot recv data: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).: Connection reset by peer 2016-10-06 10:24:53,454 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-97) [] Command 'org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand' return value 'org.ovirt.engine.core.vdsbroker.vdsbroker.VMListReturnForXmlRpc@6c6f696c' 2016-10-06 10:24:53,454 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-97) [] HostName = hlg-rbs-ovirt-kvm01-poa.rbs.com.br 2016-10-06 10:24:53,454 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-97) [] Command 'GetVmsFromExternalProviderVDSCommand(HostName = hlg-rbs-ovirt-kvm01-poa.rbs.com.br, GetVmsFromExternalProviderParameters:{runAsync='true', hostId='5feddfba-d7b2-423e-a946-ac2bf36906fa', url='qemu+ssh:// root(a)prd-openshift-kvm03-poa.rbs.com.br/system', username='root', originType='KVM'})' execution failed: VDSGenericException: VDSErrorException: Failed to GetVmsFromExternalProviderVDS, error = Cannot recv data: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).: Connection reset by peer, code = 65 2016-10-06 10:24:53,454 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-97) [] FINISH, GetVmsFromExternalProviderVDSCommand, log id: eb750c7 2016-10-06 10:24:53,459 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-97) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: Failed to retrieve VMs information from external server qemu+ssh://root@prd-openshift-kvm03-poa.rbs.com.br/system 2016-10-06 10:24:53,459 ERROR [org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery] (default task-97) [] Query 'GetVmsFromExternalProviderQuery' failed: EngineException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to GetVmsFromExternalProviderVDS, error = Cannot recv data: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).: Connection reset by peer, code = 65 (Failed with error unexpected and code 16) 2016-10-06 10:24:53,460 ERROR [org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery] (default task-97) [] Exception: org.ovirt.engine.core.common.errors.EngineException: EngineException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to GetVmsFromExternalProviderVDS, error = Cannot recv data: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).: Connection reset by peer, code = 65 (Failed with error unexpected and code 16) at org.ovirt.engine.core.bll.VdsHandler.handleVdsResult(VdsHandler.java:114) [bll.jar:] at org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.runVdsCommand(VDSBrokerFrontendImpl.java:33) [bll.jar:] at org.ovirt.engine.core.bll.QueriesCommandBase.runVdsCommand(QueriesCommandBase.java:257) [bll.jar:] at org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery.getVmsFromExternalProvider(GetVmsFromExternalProviderQuery.java:32) [bll.jar:] at org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery.executeQueryCommand(GetVmsFromExternalProviderQuery.java:27) [bll.jar:] at org.ovirt.engine.core.bll.QueriesCommandBase.executeCommand(QueriesCommandBase.java:103) [bll.jar:] at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:33) [dal.jar:] at org.ovirt.engine.core.bll.Backend.runQueryImpl(Backend.java:558) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runQuery(Backend.java:529) [bll.jar:] at sun.reflect.GeneratedMethodAccessor181.invoke(Unknown Source) [:1.8.0_102] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_102] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_102] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70) [wildfly-weld-10.0.0.Final.jar:10.0.0.Final] at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80) [wildfly-weld-10.0.0.Final.jar:10.0.0.Final] at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-10.0.0.Final.jar:10.0.0.Final] at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.ovirt.engine.core.bll.interceptors.CorrelationIdTrackerInterceptor.aroundInvoke(CorrelationIdTrackerInterceptor.java:13) [bll.jar:] at sun.reflect.GeneratedMethodAccessor179.invoke(Unknown Source) [:1.8.0_102] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_102] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_102] at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) [weld-core-impl-2.3.2.Final.jar:2.3.2.Final] at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:374) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) at org.ovirt.engine.core.common.interfaces.BackendLocal$$$view3.runQuery(Unknown Source) [common.jar:] at org.ovirt.engine.ui.frontend.server.gwt.GenericApiGWTServiceImpl.runQuery(GenericApiGWTServiceImpl.java:53) at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source) [:1.8.0_102] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_102] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_102] at com.google.gwt.rpc.server.RPC.invokeAndStreamResponse(RPC.java:196) at com.google.gwt.rpc.server.RpcServlet.processCall(RpcServlet.java:172) at com.google.gwt.rpc.server.RpcServlet.processPost(RpcServlet.java:233) at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at org.ovirt.engine.core.utils.servlet.HeaderFilter.doFilter(HeaderFilter.java:94) [utils.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.ui.frontend.server.gwt.GwtCachingFilter.doFilter(GwtCachingFilter.java:132) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.branding.BrandingFilter.doFilter(BrandingFilter.java:73) [branding.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.utils.servlet.LocaleFilter.doFilter(LocaleFilter.java:66) [utils.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_102] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_102] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_102] 2016-10-06 10:25:27,202 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-113) [] START, GetVmsFromExternalProviderVDSCommand(HostName = hlg-rbs-ovirt-kvm02-poa.rbs.com.br, GetVmsFromExternalProviderParameters:{runAsync='true', hostId='f9c9d929-b460-4102-bb29-de1e6ad6ad72', url='qemu+ssh:// root(a)prd-openshift-kvm03-poa.rbs.com.br/system', username='root', originType='KVM'}), log id: 4f3174a6 *2016-10-06 10:25:38,338 WARN [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-113) [] Unexpected return value: StatusForXmlRpc [code=65, message=Cannot recv data: Host key verification failed.: Connection reset by peer]* 2016-10-06 10:25:38,338 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-113) [] Failed in 'GetVmsFromExternalProviderVDS' method 2016-10-06 10:25:38,338 WARN [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-113) [] Unexpected return value: StatusForXmlRpc [code=65, message=Cannot recv data: Host key verification failed.: Connection reset by peer] 2016-10-06 10:25:38,343 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-113) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: VDSM hlg-rbs-ovirt-kvm02-poa.rbs.com.br command failed: Cannot recv data: Host key verification failed.: Connection reset by peer 2016-10-06 10:25:38,343 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-113) [] Command 'org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand' return value 'org.ovirt.engine.core.vdsbroker.vdsbroker.VMListReturnForXmlRpc@42dd60af' 2016-10-06 10:25:38,343 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-113) [] HostName = hlg-rbs-ovirt-kvm02-poa.rbs.com.br 2016-10-06 10:25:38,343 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-113) [] Command 'GetVmsFromExternalProviderVDSCommand(HostName = hlg-rbs-ovirt-kvm02-poa.rbs.com.br, GetVmsFromExternalProviderParameters:{runAsync='true', hostId='f9c9d929-b460-4102-bb29-de1e6ad6ad72', url='qemu+ssh:// root(a)prd-openshift-kvm03-poa.rbs.com.br/system', username='root', originType='KVM'})' execution failed: VDSGenericException: VDSErrorException: Failed to GetVmsFromExternalProviderVDS, error = Cannot recv data: Host key verification failed.: Connection reset by peer, code = 65 2016-10-06 10:25:38,343 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-113) [] FINISH, GetVmsFromExternalProviderVDSCommand, log id: 4f3174a6 2016-10-06 10:25:38,344 ERROR [org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery] (default task-113) [] Query 'GetVmsFromExternalProviderQuery' failed: EngineException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to GetVmsFromExternalProviderVDS, error = Cannot recv data: Host key verification failed.: Connection reset by peer, code = 65 (Failed with error unexpected and code 16) 2016-10-06 10:25:38,345 ERROR [org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery] (default task-113) [] Exception: org.ovirt.engine.core.common.errors.EngineException: EngineException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to GetVmsFromExternalProviderVDS, error = Cannot recv data: Host key verification failed.: Connection reset by peer, code = 65 (Failed with error unexpected and code 16) at org.ovirt.engine.core.bll.VdsHandler.handleVdsResult(VdsHandler.java:114) [bll.jar:] at org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.runVdsCommand(VDSBrokerFrontendImpl.java:33) [bll.jar:] at org.ovirt.engine.core.bll.QueriesCommandBase.runVdsCommand(QueriesCommandBase.java:257) [bll.jar:] at org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery.getVmsFromExternalProvider(GetVmsFromExternalProviderQuery.java:32) [bll.jar:] at org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery.executeQueryCommand(GetVmsFromExternalProviderQuery.java:27) [bll.jar:] at org.ovirt.engine.core.bll.QueriesCommandBase.executeCommand(QueriesCommandBase.java:103) [bll.jar:] at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:33) [dal.jar:] at org.ovirt.engine.core.bll.Backend.runQueryImpl(Backend.java:558) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runQuery(Backend.java:529) [bll.jar:] at sun.reflect.GeneratedMethodAccessor181.invoke(Unknown Source) [:1.8.0_102] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_102] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_102] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70) [wildfly-weld-10.0.0.Final.jar:10.0.0.Final] at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80) [wildfly-weld-10.0.0.Final.jar:10.0.0.Final] at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-10.0.0.Final.jar:10.0.0.Final] at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.ovirt.engine.core.bll.interceptors.CorrelationIdTrackerInterceptor.aroundInvoke(CorrelationIdTrackerInterceptor.java:13) [bll.jar:] at sun.reflect.GeneratedMethodAccessor179.invoke(Unknown Source) [:1.8.0_102] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_102] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_102] at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) [weld-core-impl-2.3.2.Final.jar:2.3.2.Final] at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:374) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) at org.ovirt.engine.core.common.interfaces.BackendLocal$$$view3.runQuery(Unknown Source) [common.jar:] at org.ovirt.engine.ui.frontend.server.gwt.GenericApiGWTServiceImpl.runQuery(GenericApiGWTServiceImpl.java:53) at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source) [:1.8.0_102] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_102] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_102] at com.google.gwt.rpc.server.RPC.invokeAndStreamResponse(RPC.java:196) at com.google.gwt.rpc.server.RpcServlet.processCall(RpcServlet.java:172) at com.google.gwt.rpc.server.RpcServlet.processPost(RpcServlet.java:233) at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at org.ovirt.engine.core.utils.servlet.HeaderFilter.doFilter(HeaderFilter.java:94) [utils.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.ui.frontend.server.gwt.GwtCachingFilter.doFilter(GwtCachingFilter.java:132) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.branding.BrandingFilter.doFilter(BrandingFilter.java:73) [branding.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.utils.servlet.LocaleFilter.doFilter(LocaleFilter.java:66) [utils.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_102] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_102] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_102] 2016-10-06 10:25:52,527 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-118) [] START, GetVmsFromExternalProviderVDSCommand(HostName = hlg-rbs-ovirt-kvm03-poa.rbs.com.br, GetVmsFromExternalProviderParameters:{runAsync='true', hostId='02ead14e-0208-4a74-b1c2-4c19383820f9', url='qemu+ssh:// root(a)prd-openshift-kvm03-poa.rbs.com.br/system', username='root', originType='KVM'}), log id: 7c8b1e2d 2016-10-06 10:26:02,695 WARN [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-118) [] Unexpected return value: StatusForXmlRpc [code=65, message=Cannot recv data: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).: Connection reset by peer] 2016-10-06 10:26:02,695 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-118) [] Failed in 'GetVmsFromExternalProviderVDS' method 2016-10-06 10:26:02,696 WARN [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-118) [] Unexpected return value: StatusForXmlRpc [code=65, message=Cannot recv data: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).: Connection reset by peer] 2016-10-06 10:26:02,701 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-118) [] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: VDSM hlg-rbs-ovirt-kvm03-poa.rbs.com.br command failed: Cannot recv data: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).: Connection reset by peer 2016-10-06 10:26:02,701 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-118) [] Command 'org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand' return value 'org.ovirt.engine.core.vdsbroker.vdsbroker.VMListReturnForXmlRpc@5ce9f7f2' 2016-10-06 10:26:02,701 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-118) [] HostName = hlg-rbs-ovirt-kvm03-poa.rbs.com.br 2016-10-06 10:26:02,701 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-118) [] Command 'GetVmsFromExternalProviderVDSCommand(HostName = hlg-rbs-ovirt-kvm03-poa.rbs.com.br, GetVmsFromExternalProviderParameters:{runAsync='true', hostId='02ead14e-0208-4a74-b1c2-4c19383820f9', url='qemu+ssh:// root(a)prd-openshift-kvm03-poa.rbs.com.br/system', username='root', originType='KVM'})' execution failed: VDSGenericException: VDSErrorException: Failed to GetVmsFromExternalProviderVDS, error = Cannot recv data: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).: Connection reset by peer, code = 65 2016-10-06 10:26:02,701 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand] (default task-118) [] FINISH, GetVmsFromExternalProviderVDSCommand, log id: 7c8b1e2d 2016-10-06 10:26:02,701 ERROR [org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery] (default task-118) [] Query 'GetVmsFromExternalProviderQuery' failed: EngineException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to GetVmsFromExternalProviderVDS, error = Cannot recv data: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).: Connection reset by peer, code = 65 (Failed with error unexpected and code 16) 2016-10-06 10:26:02,701 ERROR [org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery] (default task-118) [] Exception: org.ovirt.engine.core.common.errors.EngineException: EngineException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to GetVmsFromExternalProviderVDS, error = Cannot recv data: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).: Connection reset by peer, code = 65 (Failed with error unexpected and code 16) at org.ovirt.engine.core.bll.VdsHandler.handleVdsResult(VdsHandler.java:114) [bll.jar:] at org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.runVdsCommand(VDSBrokerFrontendImpl.java:33) [bll.jar:] at org.ovirt.engine.core.bll.QueriesCommandBase.runVdsCommand(QueriesCommandBase.java:257) [bll.jar:] at org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery.getVmsFromExternalProvider(GetVmsFromExternalProviderQuery.java:32) [bll.jar:] at org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery.executeQueryCommand(GetVmsFromExternalProviderQuery.java:27) [bll.jar:] at org.ovirt.engine.core.bll.QueriesCommandBase.executeCommand(QueriesCommandBase.java:103) [bll.jar:] at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:33) [dal.jar:] at org.ovirt.engine.core.bll.Backend.runQueryImpl(Backend.java:558) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runQuery(Backend.java:529) [bll.jar:] at sun.reflect.GeneratedMethodAccessor181.invoke(Unknown Source) [:1.8.0_102] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_102] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_102] at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:70) [wildfly-weld-10.0.0.Final.jar:10.0.0.Final] at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:80) [wildfly-weld-10.0.0.Final.jar:10.0.0.Final] at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-10.0.0.Final.jar:10.0.0.Final] at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.ovirt.engine.core.bll.interceptors.CorrelationIdTrackerInterceptor.aroundInvoke(CorrelationIdTrackerInterceptor.java:13) [bll.jar:] at sun.reflect.GeneratedMethodAccessor179.invoke(Unknown Source) [:1.8.0_102] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_102] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_102] at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:89) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) [weld-core-impl-2.3.2.Final.jar:2.3.2.Final] at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) [wildfly-weld-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:374) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:243) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) [wildfly-ejb3-10.0.0.Final.jar:10.0.0.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) at org.ovirt.engine.core.common.interfaces.BackendLocal$$$view3.runQuery(Unknown Source) [common.jar:] at org.ovirt.engine.ui.frontend.server.gwt.GenericApiGWTServiceImpl.runQuery(GenericApiGWTServiceImpl.java:53) at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source) [:1.8.0_102] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_102] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_102] at com.google.gwt.rpc.server.RPC.invokeAndStreamResponse(RPC.java:196) at com.google.gwt.rpc.server.RpcServlet.processCall(RpcServlet.java:172) at com.google.gwt.rpc.server.RpcServlet.processPost(RpcServlet.java:233) at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at org.ovirt.engine.core.utils.servlet.HeaderFilter.doFilter(HeaderFilter.java:94) [utils.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.ui.frontend.server.gwt.GwtCachingFilter.doFilter(GwtCachingFilter.java:132) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.branding.BrandingFilter.doFilter(BrandingFilter.java:73) [branding.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at org.ovirt.engine.core.utils.servlet.LocaleFilter.doFilter(LocaleFilter.java:66) [utils.jar:] at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_102] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_102] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_102] ^C [root@hlg-rbs-ovirt01-poa ~]# When i try with virsh i have sucess. [root@hlg-rbs-ovirt-kvm01-poa ~]# virsh -c qemu+ssh:// root(a)prd-openshift-kvm03-poa.rbs.com.br/system The authenticity of host 'prd-openshift-kvm03-poa.rbs.com.br (10.1.8.32)' can't be established. ECDSA key fingerprint is af:e9:12:29:65:ad:41:ab:0a:3c:a1:f0:73:1c:62:a5. Are you sure you want to continue connecting (yes/no)? yes root(a)prd-openshift-kvm03-poa.rbs.com.br's password: Welcome to virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # list Id Name State ---------------------------------------------------- 5 prd-openshift-etcd03-poa running 6 prd-openshift-master03-poa running 8 prd-openshift-node03-poa running virsh # list --all Id Name State ---------------------------------------------------- 5 prd-openshift-etcd03-poa running 6 prd-openshift-master03-poa running 8 prd-openshift-node03-poa running - teste shut off - teste1 shut off - tpl-centos72-64 shut off virsh # quit [root@hlg-rbs-ovirt-kvm01-poa ~]# Thanks.

5 years, 11 months

3
2
0 / 0

Libvirt ERROR cannot access backing file after importing VM from OpenStack

by Vrgotic, Marko

Dear oVirt team, When trying to start imported VM, it fails with following message: ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ForkJoinPool-1-worker-2) [] EVENT_ID: VM_DOWN_ERROR(119), VM instance-00000673 is down with error. Exit message: Cannot access backing file '/var/lib/nova/instances/_base/2f4f8c5fc11bb83bcab03f4c829ddda4da8c0bce' of storage file '/rhev/data-center/mnt/glusterSD/aws-gfs-01.awesome.lan:_gv0__he/2607c265-248c-40ad-b020-f3756454839e/images/816ac00f-ba98-4827-b5c8-42a8ba496089/8ecfcd5b-db67-4c23-9869-0e20d7553aba' (as uid:107, gid:107): No such file or directory. Platform details: Ovirt SHE Version 4.2.2.6-1.el7.centos GlusterFS, unmanaged by oVirt. VM is imported & converted from OpenStack, according to log files, successfully (one WARN, related to different MAC address): 2018-05-24 12:03:31,028+02 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsNamesFromExternalProviderVDSCommand] (default task-29) [cc5931a2-1af5-4d65-b0b3-362588db9d3f] FINISH, GetVmsNamesFromExternalProviderVDSCommand, return: [VM [instance-0001f94c], VM [instance-00078f6a], VM [instance-00000814], VM [instance-0001f9ac], VM [instance-000001ff], VM [instance-0001f718], VM [instance-00000673], VM [instance-0001ecf2], VM [instance-00078d38]], log id: 7f178a5e 2018-05-24 12:48:33,722+02 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsNamesFromExternalProviderVDSCommand] (default task-8) [103d56e1-7449-4853-ae50-48ee94d43d77] FINISH, GetVmsNamesFromExternalProviderVDSCommand, return: [VM [instance-0001f94c], VM [instance-00078f6a], VM [instance-00000814], VM [instance-0001f9ac], VM [instance-000001ff], VM [instance-0001f718], VM [instance-00000673], VM [instance-0001ecf2], VM [instance-00078d38]], log id: 3aa178c5 2018-05-24 12:48:47,291+02 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFullInfoFromExternalProviderVDSCommand] (default task-17) [4bf555c7-9d64-4ecc-b059-8a60a4b27bdd] START, GetVmsFullInfoFromExternalProviderVDSCommand(HostName = aws-ovhv-01, GetVmsFromExternalProviderParameters:{hostId='cbabe1e8-9e7f-4c4b-be9c-49154953564d', url='qemu+tcp://root@172.19.0.12/system', username='null', originType='KVM', namesOfVms='[instance-00000673]'}), log id: 4c445109 2018-05-24 12:48:47,318+02 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFullInfoFromExternalProviderVDSCommand] (default task-17) [4bf555c7-9d64-4ecc-b059-8a60a4b27bdd] FINISH, GetVmsFullInfoFromExternalProviderVDSCommand, return: [VM [instance-00000673]], log id: 4c445109 2018-05-24 12:49:20,466+02 INFO [org.ovirt.engine.core.bll.exportimport.ImportVmFromExternalProviderCommand] (default task-41) [14edb003-b4a0-4355-b3de-da2b68774fe3] Lock Acquired to object 'EngineLock:{exclusiveLocks='[instance-00000673=VM_NAME, 1f0b608f-7cfc-4b27-a876-b5d8073011a1=VM]', sharedLocks=''}' 2018-05-24 12:49:20,586+02 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-653408) [14edb003-b4a0-4355-b3de-da2b68774fe3] EVENT_ID: MAC_ADDRESS_IS_EXTERNAL(925), VM instance-00000673 has MAC address(es) fa:16:3e:74:18:50, which is/are out of its MAC pool definitions. 2018-05-24 12:49:21,021+02 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-653408) [14edb003-b4a0-4355-b3de-da2b68774fe3] EVENT_ID: IMPORTEXPORT_STARTING_IMPORT_VM(1,165), Starting to import Vm instance-00000673 to Data Center AVEUNL, Cluster AWSEUOPS 2018-05-24 12:49:28,816+02 INFO [org.ovirt.engine.core.bll.exportimport.ImportVmFromExternalProviderCommand] (EE-ManagedThreadFactory-engine-Thread-653407) [] Lock freed to object 'EngineLock:{exclusiveLocks='[instance-00000673=VM_NAME, 1f0b608f-7cfc-4b27-a876-b5d8073011a1=VM]', sharedLocks=''}' 2018-05-24 12:49:28,911+02 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConvertVmVDSCommand] (EE-ManagedThreadFactory-commandCoordinator-Thread-2) [2047673e] START, ConvertVmVDSCommand(HostName = aws-ovhv-01, ConvertVmVDSParameters:{hostId='cbabe1e8-9e7f-4c4b-be9c-49154953564d', url='qemu+tcp://root@172.19.0.12/system', username='null', vmId='1f0b608f-7cfc-4b27-a876-b5d8073011a1', vmName='instance-00000673', storageDomainId='2607c265-248c-40ad-b020-f3756454839e', storagePoolId='5a5de92c-0120-0167-03cb-00000000038a', virtioIsoPath='null', compatVersion='null', Disk0='816ac00f-ba98-4827-b5c8-42a8ba496089'}), log id: 53408517 2018-05-24 12:49:29,010+02 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-commandCoordinator-Thread-2) [2047673e] EVENT_ID: IMPORTEXPORT_STARTING_CONVERT_VM(1,193), Starting to convert Vm instance-00000673 2018-05-24 12:52:57,982+02 INFO [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-16) [df1d5f72-eb17-46e4-9946-20ca9809b54c] Failed to Acquire Lock to object 'EngineLock:{exclusiveLocks='[instance-00000673=VM_NAME]', sharedLocks='[1f0b608f-7cfc-4b27-a876-b5d8073011a1=VM]'}' 2018-05-24 12:59:24,575+02 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engineScheduled-Thread-20) [2047673e] EVENT_ID: IMPORTEXPORT_IMPORT_VM(1,152), Vm instance-00000673 was imported successfully to Data Center AVEUNL, Cluster AWSEUOPS Than trying to start VM fails with following messages: 2018-05-24 13:00:32,085+02 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-653729) [] EVENT_ID: USER_STARTED_VM(153), VM instance-00000673 was started by admin@internal-authz (Host: aws-ovhv-06). 2018-05-24 13:00:33,417+02 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (ForkJoinPool-1-worker-9) [] VM '1f0b608f-7cfc-4b27-a876-b5d8073011a1'(instance-00000673) moved from 'WaitForLaunch' --> 'Down' 2018-05-24 13:00:33,436+02 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ForkJoinPool-1-worker-9) [] EVENT_ID: VM_DOWN_ERROR(119), VM instance-00000673 is down with error. Exit message: Cannot access backing file '/var/lib/nova/instances/_base/2f4f8c5fc11bb83bcab03f4c829ddda4da8c0bce' of storage file '/rhev/data-center/mnt/glusterSD/aws-gfs-01.awesome.lan:_gv0__he/2607c265-248c-40ad-b020-f3756454839e/images/816ac00f-ba98-4827-b5c8-42a8ba496089/8ecfcd5b-db67-4c23-9869-0e20d7553aba' (as uid:107, gid:107): No such file or directory. 2018-05-24 13:00:33,437+02 INFO [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] (ForkJoinPool-1-worker-9) [] add VM '1f0b608f-7cfc-4b27-a876-b5d8073011a1'(instance-00000673) to rerun treatment 2018-05-24 13:00:33,455+02 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-653732) [] EVENT_ID: USER_INITIATED_RUN_VM_FAILED(151), Failed to run VM instance-00000673 on Host aws-ovhv-06. 2018-05-24 13:00:33,460+02 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-653732) [] EVENT_ID: USER_FAILED_RUN_VM(54), Failed to run VM instance-00000673 (User: admin@internal-authz). Checking on the Gluster volume, directory and files exist, permissions are in order: [root@aws-ovhv-01 816ac00f-ba98-4827-b5c8-42a8ba496089] -rw-rw----. 1 vdsm kvm 14G May 24 12:59 8ecfcd5b-db67-4c23-9869-0e20d7553aba -rw-rw----. 1 vdsm kvm 1.0M May 24 12:49 8ecfcd5b-db67-4c23-9869-0e20d7553aba.lease -rw-r--r--. 1 vdsm kvm 310 May 24 12:49 8ecfcd5b-db67-4c23-9869-0e20d7553aba.meta Than I have checked image info, and noticed that backing file entry is pointing to non-existing location, which does and should not exist on oVirt hosts: [root@aws-ovhv-01 816ac00f-ba98-4827-b5c8-42a8ba496089]# qemu-img info 8ecfcd5b-db67-4c23-9869-0e20d7553aba image: 8ecfcd5b-db67-4c23-9869-0e20d7553aba file format: qcow2 virtual size: 160G (171798691840 bytes) disk size: 14G cluster_size: 65536 backing file: /var/lib/nova/instances/_base/2f4f8c5fc11bb83bcab03f4c829ddda4da8c0bce Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false Can somebody advise me how to fix, address this, as I am in need of importing 200+ VMs from OpenStack to oVirt? Kindly awaiting your reply. Marko Vrgotic

5 years, 11 months

7
36
0 / 0

Change host names/IPs

by Davide Ferrari

Hello Is there a clean way and possibly without downtime to change the hostname and IP addresses of all the hosts in a running oVirt cluster? -- Davide Ferrari Senior Systems Engineer

5 years, 11 months

4
7
0 / 0

[Users] Lifecycle / upgradepath

by Sven Kieske

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

5 years, 11 months

2
1
0 / 0

[Users] Nested virtualization with Opteron 2nd generation and oVirt 3.1 possible?

by Gianluca Cecchi

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

5 years, 11 months

2
1
0 / 0

Need VM run once api

by Chandrahasa S

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" <font size=2 face="sans-serif">Hi Experts,</font> <br> <br><font size=2 face="sans-serif">We are integrating ovirt with our internal cloud.</font> <br> <br><font size=2 face="sans-serif">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.</font> <br> <br><font size=2 face="sans-serif">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.</font> <br> <br><font size=2 face="sans-serif">I believe we need to power ON vm using run once API, but we are not able get this API.</font> <br> <br><font size=2 face="sans-serif">Can some one help on this.</font> <br> <br><font size=2 face="sans-serif">I got reply on this query last time but unfortunately mail got deleted.</font> <br> <br><font size=2 face="sans-serif">Thanks & Regards<br> Chandrahasa S<br> </font><p>=====-----=====-----=====<br> Notice: The information contained in this e-mail<br> message and/or attachments to it may contain <br> confidential or privileged information. If you are <br> not the intended recipient, any dissemination, use, <br> review, distribution, printing or copying of the <br> information contained in this e-mail message <br> and/or attachments to it are strictly prohibited. If <br> you have received this communication in error, <br> please notify us by reply e-mail or telephone and <br> immediately and permanently delete the message <br> and any attachments. Thank you</p> <p></p> --=_alternative 00361B2065257E90_=--

5 years, 11 months

5
4
0 / 0

[Users] importing from kvm into ovirt

by Jonathan Horne

--_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><br> </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><br> </div> <div>/rhev/data-center/mnt/blockSD/fe633237-14b2-4f8b-aedd-bbf753bcafaf/mas= ter/vms</div> <div><br> </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><br> </div> <div>Any advice would be greatly appreciated.</div> <div><br> </div> <div>Thanks,</div> <div>jonathan</div> <br> <hr> <font color=3D"Gray" face=3D"Arial" size=3D"1">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.</font> </body> </html> --_000_9BE6F493F83A594DA60C45E6A09DC5AC016BA694AUSP01DAG0201co_--

6 years

3
2
0 / 0

Trying to reset password for ovirt wiki

by noc

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.<br> For some reason I keep getting the following error when I try to reset my password:<br> <br> <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> <p>Complete this form to receive an e-mail reminder of your account details.<br> </p> </fieldset> <br> Since I receive the ML on this address it is definitely a working address.<br> Tried my home account too and same error but then for my home provider, Relay denied ??<br> <br> A puzzled user,<br> <br> Joop<br> <br> </body> </html> --------------000005070002050708050606--

6 years

2
1
0 / 0

ovirt-guest-agent issue on rhel5.5

by John Michael Mercado

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

6 years

2
1
0 / 0

[Users] oVirt Workshop at LinuxCon Japan 2012

by Leslie Hawthorn

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-wo... [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

6 years

2
1
0 / 0

[Users] Moving iSCSI Master Data

by rni＠chef.net

--========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 <span style=3D'font-family:Verdana'><span style=3D'font-size:12px'>Hi,<br /= ><br />it's me again....<br /><br />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" /><br /><br />Now, I've to move the iSCSI Master data to th= e real iSCSI traget.<br />Is there any way to do this, and to become rid of= the old Master Data?<br /><br /><span id=3D"editor_signature">Thank you fo= r your help</span><br /><br />Hans-Joachim</span></span> --========GMXBoundary282021374122634158505--

6 years

3
2
0 / 0

[Users] Can't access RHEV-H aka ovirt-node

by Scotto Alberto

--_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"> <p class=3D"MsoNormal"><span lang=3D"EN-US">Hi all,</span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">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.</span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">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...</span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">What’s going on? Is it a = known behavior, somehow?</span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">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?</span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"> </span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Thank you all.</span></p> </div> <br> <br> <div align=3D"left"> <p style=3D"font-family:Calibri,Sans-Serif; font-size:10pt"><span style=3D"= color:#000000; font-weight:bold">Alberto Scotto</span> <span style=3D"color:#808080"></span><br> <br> <span style=3D"color:#000000"><img border=3D"0" alt=3D"Blue" src=3D"cid:bde= 5ac62d10545908e269a6006dbd5ac" style=3D"margin:0px"> </span><br> <span style=3D"color:#808080">Via Cardinal Massaia, 83<br> 10147 - Torino - ITALY <br> phone: +39 011 29100 <br> <a href=3D"al.scotto(a)reply.it" target=3D"" style=3D"color:blue; text-decora= tion:underline">al.scotto(a)reply.it</a> <br> <a title=3D"" href=3D"www.reply.it" target=3D"" style=3D"color:blue; text-d= ecoration:underline">www.reply.it</a> </span><br>  </p> </div> <br> <hr> <font face=3D"Arial" color=3D"Gray" size=3D"1"><br> --<br> 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.<br> </font> </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_--

6 years, 1 month

3
2
0 / 0

Unable to make Single Sign on working on Windows 7 Guest

by Felipe Herrera Martinez

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

6 years, 1 month

3
5
0 / 0

Re: [ovirt-users] Need VM run once api

by Chandrahasa S

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" <font size=2 face="sans-serif">Can any one help on this.</font> <br> <br><font size=2 face="sans-serif">Thanks & Regards<br> Chandrahasa S<br> </font> <br> <br> <br> <br><font size=1 color=#5f5f5f face="sans-serif">From:        </font><font size=1 face="sans-serif">Chandrahasa S/MUM/TCS</font> <br><font size=1 color=#5f5f5f face="sans-serif">To:        </font><font size=1 face="sans-serif">users(a)ovirt.org</font> <br><font size=1 color=#5f5f5f face="sans-serif">Date:        </font><font size=1 face="sans-serif">28-07-2015 15:20</font> <br><font size=1 color=#5f5f5f face="sans-serif">Subject:        </font><font size=1 face="sans-serif">Need VM run once api</font> <br> <hr noshade> <br> <br><font size=2 face="sans-serif">Hi Experts,</font> <br> <br><font size=2 face="sans-serif">We are integrating ovirt with our internal cloud.</font> <br> <br><font size=2 face="sans-serif">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.</font> <br> <br><font size=2 face="sans-serif">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.</font> <br> <br><font size=2 face="sans-serif">I believe we need to power ON vm using run once API, but we are not able get this API.</font> <br> <br><font size=2 face="sans-serif">Can some one help on this.</font> <br> <br><font size=2 face="sans-serif">I got reply on this query last time but unfortunately mail got deleted.</font> <br> <br><font size=2 face="sans-serif">Thanks & Regards<br> Chandrahasa S<br> </font> <br><p>=====-----=====-----=====<br> Notice: The information contained in this e-mail<br> message and/or attachments to it may contain <br> confidential or privileged information. If you are <br> not the intended recipient, any dissemination, use, <br> review, distribution, printing or copying of the <br> information contained in this e-mail message <br> and/or attachments to it are strictly prohibited. If <br> you have received this communication in error, <br> please notify us by reply e-mail or telephone and <br> immediately and permanently delete the message <br> and any attachments. Thank you</p> <p></p> --=_alternative 00199D2865257E91_=--

6 years, 1 month

3
3
0 / 0

Re: [ovirt-users] Problem Windows guests start in pause

by Dafna Ron

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

6 years, 1 month

3
3
0 / 0

Feature: Hosted engine VM management

by Roy Golan

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

6 years, 2 months

2
3
0 / 0

Re: [ovirt-users] Large DWH Database, how to empty

by Matt .

Hi, OK thanks! I saw that after upgrading to 4.0.5 from 4.0.4 the DB already dropped with around 500MB directly and is now at 2GB smaller. Does this sounds familiar to you with other settings in 4.0.5 ? Thanks, Matt 2017-01-08 10:45 GMT+01:00 Shirly Radco <sradco(a)redhat.com>: > No. That will corrupt your database. > > Are you using the full dwh or the smaller version for the dashboards? > > Please set the delete thresholds to save less data and the data older then > the time you set will be deleted. > Add a file to /ovirt-engine-dwhd.conf.d/ > update_time_to_keep_records.conf > > Add these lines with the new configurations. The numbers represent the hours > to keep the data. > > DWH_TABLES_KEEP_SAMPLES=24 > DWH_TABLES_KEEP_HOURLY=1440 > DWH_TABLES_KEEP_DAILY=43800 > > > These are the configurations for a full dwh. > > The smaller version configurations are: > DWH_TABLES_KEEP_SAMPLES=24 > DWH_TABLES_KEEP_HOURLY=720 > DWH_TABLES_KEEP_DAILY=0 > > The delete process by default at 3am every day (DWH_DELETE_JOB_HOUR=3) > > Best regards, > > Shirly Radco > > BI Software Engineer > Red Hat Israel Ltd. > 34 Jerusalem Road > Building A, 4th floor > Ra'anana, Israel 4350109 > > > On Fri, Jan 6, 2017 at 6:35 PM, Matt . <yamakasi.014(a)gmail.com> wrote: >> >> Hi, >> >> I seem to have some large database for the DWH logging and I wonder >> how I can empty it safely. >> >> Can I just simply empty the database ? >> >> Have a good weekend! >> >> Cheers, >> >> Matt >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users > >

6 years, 2 months

1
0
0 / 0

Re: [ovirt-users] Packet loss

by Doron Fediuck

----_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--

6 years, 2 months

2
1
0 / 0

Backup & Restore

by suporte＠logicworks.pt

------=_Part_20329569_1409874801.1519819859027 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, I'm testing backup & restore on Ovirt 4.2. I follow this doc https://www.ovirt.org/documentation/admin-guide/chap-Backups_and_Migration/ Try to restore to a fresh installation but always get this error message: restore-permissions Preparing to restore: - Unpacking file 'back_file' Restoring: - Files Provisioning PostgreSQL users/databases: - user 'engine', database 'engine' Restoring: FATAL: Can't connect to database 'ovirt_engine_history'. Please see '/usr/bin/engine-backup --help'. On the live engine I run # engine-backup --scope=all --mode=backup --file=file_name --log=log_file_name And try to restore on a fresh installation: # engine-backup --mode=restore --file=file_name --log=log_file_name --provision-db --restore-permissions Any Idea? Thanks -- Jose Ferradeira http://www.logicworks.pt ------=_Part_20329569_1409874801.1519819859027 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: trebuchet ms,sans-serif; font-size: = 12pt; color: #000000"><div data-marker=3D"__QUOTED_TEXT__"><div style=3D"fo= nt-family: Times New Roman; font-size: 10pt; color: #000000;" data-mce-styl= e=3D"font-family: Times New Roman; font-size: 10pt; color: #000000;"><div>H= i,<br></div><br><div><span style=3D"font-size: 11pt; font-family: terminal,= monaco;" data-mce-style=3D"font-size: 11pt; font-family: terminal, monaco;= ">I'm testing backup & restore on Ovirt 4.2.</span><br></div><div><span= style=3D"font-size: 11pt; font-family: terminal, monaco;" data-mce-style= =3D"font-size: 11pt; font-family: terminal, monaco;">I follow this doc http= s://www.ovirt.org/documentation/admin-guide/chap-Backups_and_Migration/</sp= an><br></div><div><span style=3D"font-size: 11pt; font-family: terminal, mo= naco;" data-mce-style=3D"font-size: 11pt; font-family: terminal, monaco;">T= ry to restore to a fresh installation but always get this error message:</s= pan><br></div><br><div><span style=3D"font-size: 11pt; font-family: termina= l, monaco;" data-mce-style=3D"font-size: 11pt; font-family: terminal, monac= o;">restore-permissions</span><br><span style=3D"font-size: 11pt; font-fami= ly: terminal, monaco;" data-mce-style=3D"font-size: 11pt; font-family: term= inal, monaco;">Preparing to restore:</span><br><span style=3D"font-size: 11= pt; font-family: terminal, monaco;" data-mce-style=3D"font-size: 11pt; font= -family: terminal, monaco;">- Unpacking file 'back_file'</span><br><span st= yle=3D"font-size: 11pt; font-family: terminal, monaco;" data-mce-style=3D"f= ont-size: 11pt; font-family: terminal, monaco;">Restoring:</span><br><span = style=3D"font-size: 11pt; font-family: terminal, monaco;" data-mce-style=3D= "font-size: 11pt; font-family: terminal, monaco;">- Files</span><br><span s= tyle=3D"font-size: 11pt; font-family: terminal, monaco;" data-mce-style=3D"= font-size: 11pt; font-family: terminal, monaco;">Provisioning PostgreSQL us= ers/databases:</span><br><span style=3D"font-size: 11pt; font-family: termi= nal, monaco;" data-mce-style=3D"font-size: 11pt; font-family: terminal, mon= aco;">- user 'engine', database 'engine'</span><br><span style=3D"font-size= : 11pt; font-family: terminal, monaco;" data-mce-style=3D"font-size: 11pt; = font-family: terminal, monaco;">Restoring:</span><br><span style=3D"font-si= ze: 11pt; font-family: terminal, monaco;" data-mce-style=3D"font-size: 11pt= ; font-family: terminal, monaco;">FATAL: Can't connect to database 'ovirt_e= ngine_history'. Please see '/usr/bin/engine-backup --help'.</span><br></div= ><br><div><span style=3D"font-size: 11pt; font-family: terminal, monaco;" d= ata-mce-style=3D"font-size: 11pt; font-family: terminal, monaco;">On the li= ve engine I run # engine-backup --scope=3Dall --mode=3Dbackup --file= =3Dfile_name --log=3Dlog_file_name</span></div><div><span style=3D"font-siz= e: 11pt; font-family: terminal, monaco;" data-mce-style=3D"font-size: 11pt;= font-family: terminal, monaco;"><br data-mce-bogus=3D"1"></span></div><div= ><span style=3D"font-size: 11pt; font-family: terminal, monaco;" data-mce-s= tyle=3D"font-size: 11pt; font-family: terminal, monaco;">And try to restore= on a fresh installation:</span><br></div><div><span style=3D"font-size: 11= pt; font-family: terminal, monaco;" data-mce-style=3D"font-size: 11pt; font= -family: terminal, monaco;"># engine-backup --mode=3Drestore --file=3Dfile_= name --log=3Dlog_file_name --provision-db --restore-permissions</span></div= ><div><span style=3D"font-size: 11pt; font-family: terminal, monaco;" data-= mce-style=3D"font-size: 11pt; font-family: terminal, monaco;"><br data-mce-= bogus=3D"1"></span></div><div><span style=3D"font-size: 11pt; font-family: = terminal, monaco;" data-mce-style=3D"font-size: 11pt; font-family: terminal= , monaco;">Any Idea?<br data-mce-bogus=3D"1"></span></div><div><span style= =3D"font-size: 11pt; font-family: terminal, monaco;" data-mce-style=3D"font= -size: 11pt; font-family: terminal, monaco;"><br data-mce-bogus=3D"1"></spa= n></div><div><span style=3D"font-size: 11pt; font-family: terminal, monaco;= " data-mce-style=3D"font-size: 11pt; font-family: terminal, monaco;">Thanks= <br data-mce-bogus=3D"1"></span></div><div><span style=3D"font-size: 11pt; = font-family: terminal, monaco;" data-mce-style=3D"font-size: 11pt; font-fam= ily: terminal, monaco;"><br data-mce-bogus=3D"1"></span></div><div><span st= yle=3D"font-size: 11pt; font-family: terminal, monaco;" data-mce-style=3D"f= ont-size: 11pt; font-family: terminal, monaco;"><br data-mce-bogus=3D"1"></= span></div><br><div>-- <br></div><div><hr style=3D"width: 100%; height: 2px= ;" data-mce-style=3D"width: 100%; height: 2px;">Jose Ferradeira<br>http://w= ww.logicworks.pt</div></div><br></div></div></body></html> ------=_Part_20329569_1409874801.1519819859027--

6 years, 4 months

4
16
0 / 0

Out of sync, hosts network config differs from DC

by femi adegoke

Property: default route, host - true, DC - false I have 4 nics. bond0 = 2 x 10g eno1 = ovirtmgmt eno2 = for vm traffic. eno2 says it's out of sync, hosts network config differs from DC, default route: host - true, DC - false. I have tried "sync all networks" but the message still remains See attached. Where can I look to fix the issue?

6 years, 5 months

3
2
0 / 0

oVirt Node on CentOS 7.5 and AMD EPYC Support

by Tobias Scheinert

Hi, I am currently building a new virtualization cluster with oVirt, using AMD EPYC processors (AMD EPYC 7351P). At the moment I'm running oVirt Node Version 4.2.3 @ CentOS 7.4.1708. We have the situation that the processor type is recognized as "AMD Opteron G3". With this type of instruction set the VMs are not able to do AES in hardware, this results in poor performance in our case. I found some information that tells me that this problem should be solved with CentOS 7.5 --> <https://access.redhat.com/errata/RHEA-2018:1488> My actual questions: - Are there any further information about the AMD EPYC support? - Any information about an update of the oVirt node to CentOS 7.5? Greeting Tobias

6 years, 5 months

7
10
0 / 0

Error installing ovirt node

by Junaid Jadoon

Dear All, I have Ovirt engine 4.2 and node version is 4.2. After installing node in in ovirt engine when i try to install node it gives following error 14:25:37,410+05 ERROR [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] (EE-ManagedThreadFactory-engine-Thread-19) [52669850] Host installation failed for host 'bd8d007a-be92-4075-bba9-6cbeb890a1e5', 'node_2': Command returned failure code 1 during SSH session 'root(a)192.168.20.20' 2018-02-27 14:25:37,416+05 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (EE-ManagedThreadFactory-engine-Thread-19) [52669850] START, SetVdsStatusVDSCommand(HostName = node_2, SetVdsStatusVDSCommandParameters:{hostId='bd8d007a-be92-4075-bba9-6cbeb890a1e5', status='InstallFailed', nonOperationalReason='NONE', stopSpmFailureLogged='false', maintenanceReason='null'}), log id: 2b138e87 2018-02-27 14:25:37,423+05 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (EE-ManagedThreadFactory-engine-Thread-19) [52669850] FINISH, SetVdsStatusVDSCommand, log id: 2b138e87 2018-02-27 14:25:37,429+05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-19) [52669850] EVENT_ID: VDS_INSTALL_FAILED(505), Host node_2 installation failed. Command returned failure code 1 during SSH session 'root(a)192.168.20.20'. 2018-02-27 14:25:37,433+05 INFO [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] (EE-ManagedThreadFactory-engine-Thread-19) [52669850] Lock freed to object 'EngineLock:{exclusiveLocks='[bd8d007a-be92-4075-bba9-6cbeb890a1e5=VDS]', sharedLocks=''}' I have attached log file for your reference Please help me out.

6 years, 7 months

3
8
0 / 0

Failed to synchronize networks of Provider ovirt-provider-ovn

by Kapetanakis Giannis

Hi, After upgrading to 4.2.1 I have problems with ovn provider. I'm getting "Failed to synchronize networks of Provider ovirt-provider-ovn." I use custom SSL certificate in apache and I guess this is the reason. I've tried to update ovirt-provider-ovn.conf with [OVIRT] #ovirt-ca-file=/etc/pki/ovirt-engine/ca.pem ovirt-ca-file=/etc/pki/ovirt-engine/apache-ca.pem but still no go Any tips on this? thanks G

6 years, 7 months

4
11
1 / 0

Install oVirt node without Internet repository

by G, Maghesh Kumar (Nokia - IN/Bangalore)

--_000_HE1PR0702MB3532EC34365D995765A2B7D783A60HE1PR0702MB3532_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Description of problem: Cannot add host - install fails & Install oVirt node without Internet repos= itory Version: Ovirt-4.2 Host is installed with RHEL 7.4 Actual results: Host KVM02 installation failed. Command returned failure code 1 during SSH = session 'root(a)192.175.2.231<mailto:root@192.175.2.231>' I found that right now on my oVirt Nodes in my test environment does not NO= T connect to the internet... Basically, i need the offline repository to access from oVirt nodes without= Internet access. Please guide us how to proceed Regards, Maghesh --_000_HE1PR0702MB3532EC34365D995765A2B7D783A60HE1PR0702MB3532_ 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-IN" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Co= urier New";color:black;mso-fareast-language:EN-IN">Hi<o:p></o:p></span= ></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <pre><span style=3D"font-size:12.0pt;color:black">Description of problem:<o= :p></o:p></span></pre> <pre><span style=3D"font-size:12.0pt;color:black">Cannot add host - install= fails & Install oVirt node without Internet repository<o:p></o:p></spa= n></pre> <pre><span style=3D"font-size:12.0pt;color:black"><o:p> </o:p></span><= /pre> <pre><span style=3D"font-size:12.0pt;color:black">Version: Ovirt-4.2<o:p></= o:p></span></pre> <pre><span style=3D"font-size:12.0pt;color:black">Host is installed with RH= EL 7.4<o:p></o:p></span></pre> <pre><span style=3D"font-size:12.0pt;color:black"><o:p> </o:p></span><= /pre> <pre><span style=3D"font-size:12.0pt;color:black">Actual results:<o:p></o:p= ></span></pre> <pre><span style=3D"font-size:12.0pt;color:black">Host KVM02 installation f= ailed. Command returned failure code 1 during SSH session '<a href=3D"mailt= o:root@192.175.2.231"><span style=3D"color:#6699CC">root(a)192.175.2.231</spa= n></a>'<o:p></o:p></span></pre> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Co= urier New";color:black;mso-fareast-language:EN-IN">I found that right = now on my oVirt Nodes in my test environment <b>does not NOT connect to the internet.</b>.. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Co= urier New";color:black;mso-fareast-language:EN-IN">Basically, i need t= he offline repository to access from oVirt nodes without Internet access.<o= :p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Co= urier New";color:black;mso-fareast-language:EN-IN"><o:p> </o:p></= span></p> <p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Co= urier New";color:black;mso-fareast-language:EN-IN">Please guide us how= to proceed<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Co= urier New";color:black;mso-fareast-language:EN-IN"><o:p> </o:p></= span></p> <p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Co= urier New";color:black;mso-fareast-language:EN-IN">Regards,<o:p></o:p>= </span></p> <p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Co= urier New";color:black;mso-fareast-language:EN-IN">Maghesh<o:p></o:p><= /span></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </body> </html> --_000_HE1PR0702MB3532EC34365D995765A2B7D783A60HE1PR0702MB3532_--

6 years, 7 months

3
7
0 / 0

Re: External ceph storage

by Luca 'remix_tj' Lorenzetto

No, The only way you have is to configure cinder to manage ceph pool or in alternative you have to deploy an iscsi gateway, no other ways are available at the moment. So you can't use rbd directly. Luca Il dom 27 mag 2018, 16:54 Leo David <leoalex(a)gmail.com> ha scritto: > Thank you Luca, > At the moment i would try the cinder storage provider, since we already > have a proxmox cluster directly connecting to ceph. The problem is that I > just could not find a straight way to do this. > ie: Specify the ceph monitors and ceph pool to connect to. Can oVirt > directly connect to ceph monitors ? How the configuration should be done if > so ? > Thank you very much ! > > > On Sun, May 27, 2018, 17:20 Luca 'remix_tj' Lorenzetto < > lorenzetto.luca(a)gmail.com> wrote: > >> Hello, >> >> Yes, using cinder or through iscsi gateway. >> >> For a simpler setup i suggest the second option. >> >> Luca >> >> Il dom 27 mag 2018, 16:08 Leo David <leoalex(a)gmail.com> ha scritto: >> >>> Hello everyone, >>> I am new to ovirt and very impressed of its features. I would like to >>> levereage on our existing ceph cluster to provide rbd images for vm hdds, >>> is this possible to achieve ? >>> Thank you very much ! >>> Regards, >>> Leo >>> _______________________________________________ >>> Users mailing list -- users(a)ovirt.org >>> To unsubscribe send an email to users-leave(a)ovirt.org >>> >>

6 years, 8 months

3
3
0 / 0

Network issues with oVirt 4.2 and cloud-init

by Berger, Sandy

--_000_DM5PR05MB316161E1C7E2EB8EA09A76A0D5D40DM5PR05MB3161namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We're using cloud-init to customize VMs built from a template. We're using = static IPV4 settings so we're specifying an IP address, subnet mask, and ga= teway. There is apparently a bug in the current version of cloud-init shipp= ing as part of CentOS 7.4 (https://bugzilla.redhat.com/show_bug.cgi?id=3D14= 92726) that fails to set the gateway properly. In the description of the bu= g, it says it is fixed in RHEL 7.5 but also says one can use https://people= .redhat.com/rmccabe/cloud-init/cloud-init-0.7.9-20.el7.x86_64.rpm which is = what we're doing. When the new VM first boots, the 3 IPv4 settings are all set correctly. Reb= oots of the VM maintain the settings properly. But, if the VM is shut down = and started again via the oVirt GUI, all of the IPV4 settings on the eth0 v= irtual NIC are lost and the /etc/sysconfig/network-scripts/ifcfg-eth0 shows= that the NIC is now set up for DHCP. Are we doing something incorrectly? Sandy Berger IT - Infrastructure Engineer II Quad/Graphics Performance through Innovation Sussex, Wisconsin 414.566.2123 phone 414.566.4010/2123 pager/PIN sandy.berger(a)qg.com<mailto:sandy.berger@qg.com> www.QG.com<http://www.qg.com/> Follow Us: Facebook<http://www.qg.com/social1> | Twitter<http://www.qg.com/= social2> | LinkedIn<http://www.qg.com/social3> | YouTube<http://www.qg.com/= social4> --_000_DM5PR05MB316161E1C7E2EB8EA09A76A0D5D40DM5PR05MB3161namp_ 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"> <p class=3D"MsoNormal">We’re using cloud-init to customize VMs built = from a template. We’re using static IPV4 settings so we’re spec= ifying an IP address, subnet mask, and gateway. There is apparently a bug i= n the current version of cloud-init shipping as part of CentOS 7.4 (<a href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D14= 92726">https://bugzilla.redhat.com/show_bug.cgi?id=3D1492726</a>) that fail= s to set the gateway properly. In the description of the bug, it says it is= fixed in RHEL 7.5 but also says one can use <a href=3D"https://people.redhat.com/rmccabe/cloud-init/cloud-init-0.7= .9-20.el7.x86_64.rpm"> https://people.redhat.com/rmccabe/cloud-init/cloud-init-0.7.9-20.el7.x86_64= .rpm</a> which is what we’re doing.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">When the new VM first boots, the 3 IPv4 settings are= all set correctly. Reboots of the VM maintain the settings properly. But, = if the VM is shut down and started again via the oVirt GUI, all of the IPV4= settings on the eth0 virtual NIC are lost and the /etc/sysconfig/network-scripts/ifcfg-eth0 shows that the = NIC is now set up for DHCP.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Are we doing something incorrectly?<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot= ;Arial",sans-serif;color:#1E47A4">Sandy Berger </span></b><span style=3D"font-size:10.5pt;font-family:"Arial",sa= ns-serif;color:#444444"><o:p></o:p></span></p> <p class=3D"MsoNormal"><i><span style=3D"font-size:10.0pt;font-family:&quot= ;Arial",sans-serif;color:#434D5B">IT – Infrastructure Engineer I= I</span></i><span style=3D"font-size:10.5pt;font-family:"Arial",s= ans-serif;color:#444444"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial",sans-serif;color:#444444"> <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial",sans-serif;color:#1E47A4">Quad/Graphics</span><span style=3D"font= -size:10.5pt;font-family:"Arial",sans-serif;color:#444444"><o:p><= /o:p></span></p> <p class=3D"MsoNormal"><i><span style=3D"font-size:8.0pt;font-family:"= Arial",sans-serif;color:#434D5B">Performance</span></i><span style=3D"= font-size:8.0pt;font-family:"Arial",sans-serif;color:#434D5B">&nb= sp;through </span><i><span style=3D"font-size:8.5pt;font-family:"= Arial",sans-serif;color:#434D5B">Innovation</span></i><span style=3D"f= ont-size:10.5pt;font-family:"Arial",sans-serif;color:#444444"><o:= p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:"Ar= ial",sans-serif;color:#434D5B"> </span><span style=3D"font-size:1= 0.5pt;font-family:"Arial",sans-serif;color:#444444"><o:p></o:p></= span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial",sans-serif;color:#434D5B">Sussex, Wisconsin</span><span style=3D"= font-size:10.5pt;font-family:"Arial",sans-serif;color:#444444"><o= :p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial",sans-serif;color:#434D5B">414.566.2123 phone</span><span style=3D= "font-size:10.5pt;font-family:"Arial",sans-serif;color:#444444"><= o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial",sans-serif;color:#434D5B">414.566.4010/2123 pager/PIN</span><span= style=3D"font-size:10.5pt;font-family:"Arial",sans-serif;color:#= 444444"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;color:black"> <= /span><span style=3D"font-size:10.5pt;font-family:"Arial",sans-se= rif;color:#444444"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial",sans-serif;color:black"><a href=3D"mailto:sandy.berger@qg.com"><s= pan style=3D"color:blue">sandy.berger(a)qg.com</span></a></span><span style= =3D"font-size:10.5pt;font-family:"Arial",sans-serif;color:#444444= "><o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-family:"Arial",sans-se= rif;color:black"><a href=3D"http://www.qg.com/"><span style=3D"font-size:10= .0pt;color:blue">www.QG.com</span></a></span><span style=3D"font-size:10.5p= t;font-family:"Arial",sans-serif;color:#444444"><o:p></o:p></span= ></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> Follow Us: <a href=3D"http://www.qg.com/social1">Facebook</a> | <a href=3D"= http://www.qg.com/social2"> Twitter</a> | <a href=3D"http://www.qg.com/social3">LinkedIn</a> | <a href= =3D"http://www.qg.com/social4"> YouTube</a> </body> </html> --_000_DM5PR05MB316161E1C7E2EB8EA09A76A0D5D40DM5PR05MB3161namp_--

6 years, 8 months

4
5
0 / 0

oVirt reports using Grafana

by Karli Sjöberg

Heya! I've been whishing for reports in oVirt ever since the old 'Jasper Reports' was removed. For an Enterprise, having pretty graphs to look at is a must. Searching the subject, I've found this[*] and have managed to get it installed OK but having issues trying to follow the guide setting it up. First of all, I think the guide should have at least mentioned that 'pg_hba.conf' needs to be edited for the read only user to be able to connect to the database, I scratched my head around that for a while before I got it. When I first type in the query example, I got syntax errors: 'pq: syntax error at or near "$"'. I continued anyways since I figured it would be solved at a later point, which turned out to be true, since the next step is to use the "Templating feature" to add variables. Unfortunately this doesn't go so well, even though I followed the instructions very carefully. After hitting save on the first variable I am rewarded with the error message: 'Template variables could not be initialized: pq: column "en_us" does not exist.' Are the queries stated in the guide still correct? This is for 'user_locale': "SELECT DISTINCT language_code from enum_translator" [*]:https://www.ovirt.org/blog/2018/01/ovirt-report-using-grafana/ TIA /K

6 years, 9 months

5
8
0 / 0

Changing resolution of console on Mint guest running on Ovirt 4.2

by pascal＠butterflyit.com

I keep getting an error: Could not set configuration for CRTC 63. I checked that I have spice-agent and spice-agentd running. Also qemu-guest-agent. lspci shows that I have a QXL adapter. xrandr -q shows that I have many different config available. but none work. What am I missing? Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192 Virtual-0 connected primary 1024x768+0+0 0mm x 0mm 1024x768 59.95*+ 1920x1200 59.95 1920x1080 60.00 1600x1200 59.95 1680x1050 60.00 1400x1050 60.00 1280x1024 59.95 1440x900 59.99 1280x960 59.99 1280x854 59.95 1280x800 59.96 1280x720 59.97 1152x768 59.95 800x600 59.96 848x480 59.94 720x480 59.94 640x480 59.94 Virtual-1 disconnected V

6 years, 9 months

2
1
0 / 0

ovirt-node: freshly installed node: network interfaces not visible

by etienne.charlier＠reduspaceservices.eu

Hello, I'm deploying a test cluster to get used to the ovirt product. My ovirt ( 4.2.2) engine is deployed in a vmware virtual machine. I'm busy deploying 5 hosts using the ovirt-node iso. I have issue with the additional physical network interface ( used for vm trafic and iSCSI) In ovirt manager I can't see the physical network interfaces. It's thus not possible to assign logical network to physical interfaces and my hosts stays in "non operational" status. How should I configure the additional interfaces in the ovirt-node installer to have them recognized ? I somehow managed to configure one host and I can see a comment line in /etc/sysconfig/network-script/ifcfg-... saying vdsm has acquired the interface.... No Such line in the ifcfg-* file in non operational hosts.... Any idea ? Etienne

6 years, 9 months

3
4
0 / 0

vGPU setup guide

by Callum Smith

Dear All, IS this the most current and useful example of implenting vGPUs in oVirt? I had understood that 4.2 had NVIDIA GRID support as a flagship feature, but this appears to be 4.1.4? It seems a very reasonable and decent guide, just don't want to go down this route if there's alternatives now available in 4.2.x. https://mpolednik.github.io/2017/09/13/vgpu-in-ovirt/ Regards, Callum -- Callum Smith Research Computing Core Wellcome Trust Centre for Human Genetics University of Oxford e. callum(a)well.ox.ac.uk<mailto:callum@well.ox.ac.uk>

6 years, 10 months

3
7
0 / 0

Fwd: vGPU VM not starting

by Ales Musil

On Thu, May 17, 2018 at 12:01 AM, Callum Smith <callum(a)well.ox.ac.uk> wrote: > Dear All, > > Our vGPU installation is progressing, though the VM is failing to start. > > 2018-05-16 22:57:34,328+0100 ERROR (vm/1bc9dae8) [virt.vm] > (vmId='1bc9dae8-a0ea-44b3-9103-5805100648d0') The vm start process failed > (vm:943) > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 872, in > _startUnderlyingVm > self._run() > File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2872, in > _run > dom.createWithFlags(flags) > File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", > line 130, in wrapper > ret = f(*args, **kwargs) > File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line > 92, in wrapper > return func(inst, *args, **kwargs) > File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1099, in > createWithFlags > if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', > dom=self) > libvirtError: Cannot get interface MTU on '': No such device > > That's the specific error, some other information. It seems the GPU > 'allocation' of uuid against the nvidia-xx mdev type is proceeding > correctly, and the device is being created by the VM instantiation but the > VM does not succeed in going up with this error. Any other logs or > information relevant to help diagnose? > > Regards, > Callum > > -- > > Callum Smith > Research Computing Core > Wellcome Trust Centre for Human Genetics > University of Oxford > e. callum(a)well.ox.ac.uk > > > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > > Hi Callum, can you share your version of the setup? Also do you use OVS switch type in the cluster? Regards, Ales. -- ALES MUSIL INTERN - rhv network Red Hat EMEA <https://www.redhat.com/> amusil(a)redhat.com IM: amusil <https://red.ht/sig>

6 years, 10 months

6
14
0 / 0

Unable to backend oVirt with Cinder

by Logan Kuhn

------=_Part_51316288_608143832.1472587678781 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I've got Cinder configured and pointed at Ceph for it's back end storage. I can run ceph commands on the cinder machine and cinder is configured for noauth and I've also tried it with Keystone for auth. I can run various cinder commands and it'll return as expected. When I configure it in oVirt it'll add the external provider fine, but when I go to create a disk it doesn't populate the volume type field, it's just empty. The corresponding command for cinder: cinder type-list and cinder type-show <name> returns fine and it is public. Ovirt and Cinder are on the same host so it isn't a firewall issue. Cinder config: [DEFAULT] rpc_backend = rabbit #auth_strategy = keystone auth_strategy = noauth enabled_backends = ceph #glance_api_servers = http://10.128.7.252:9292 #glance_api_version = 2 #[keystone_authtoken] #auth_uri = http://10.128.7.252:5000/v3 #auth_url = http://10.128.7.252:35357/v3 #auth_type = password #memcached_servers = localhost:11211 #project_domain_name = default #user_domain_name = default #project_name = services #username = user #password = pass [ceph] volume_driver = cinder.volume.drivers.rbd.RBDDriver volume_backend_name = ceph rbd_pool = ovirt-images rbd_user = cinder rbd_secret_uuid = <secret> rbd_ceph_conf = /etc/ceph/ceph.conf rbd_flatten_volume_from_snapshot = true rbd_max_clone_depth = 5 rbd_store_chunk_size = 4 rados_connect_timeout = -1 #glance_api_version = 2 [database] connection = postgresql://user:pass@10.128.2.33/cinder [oslo_concurrency] lock_path = /var/lib/cinder/tmp [oslo_messaging_rabbit] rabbit_host = localhost rabbit_port = 5672 rabbit_userid = user rabbit_password = pass Regards, Logan ------=_Part_51316288_608143832.1472587678781 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: Arial; font-size: 12pt; color: #0000= 00"><div>I've got Cinder configured and pointed at Ceph for it's back end s= torage.  I can run ceph commands on the cinder machine and cinder is c= onfigured for noauth and I've also tried it with Keystone for auth.  I= can run various cinder commands and it'll return as expected. </= div><div><br data-mce-bogus=3D"1"></div><div>When I configure it in oVirt i= t'll add the external provider fine, but when I go to create a disk it does= n't populate the volume type field, it's just empty.  The correspondin= g command for cinder: cinder type-list and cinder type-show <name> re= turns fine and it is public. </div><div><br data-mce-bogus=3D"1"></div= ><div>Ovirt and Cinder are on the same host so it isn't a firewall issue.</= div><div><br data-mce-bogus=3D"1"></div><div>Cinder config:</div><div>[DEFA= ULT]<br>rpc_backend =3D rabbit<br>#auth_strategy =3D keystone<br>auth_strat= egy =3D noauth<br>enabled_backends =3D ceph<br>#glance_api_servers =3D http= ://10.128.7.252:9292<br>#glance_api_version =3D 2<br><br>#[keystone_authtok= en]<br>#auth_uri =3D http://10.128.7.252:5000/v3<br>#auth_url =3D http://10= .128.7.252:35357/v3<br>#auth_type =3D password<br>#memcached_servers =3D lo= calhost:11211<br>#project_domain_name =3D default<br>#user_domain_name =3D = default<br>#project_name =3D services<br>#username =3D user<br>#passwo= rd =3D pass<br><br>[ceph]<br>volume_driver =3D cinder.volume.drivers.rbd.RB= DDriver<br>volume_backend_name =3D ceph<br>rbd_pool =3D ovirt-images<br>rbd= _user =3D cinder<br>rbd_secret_uuid =3D <secret><br>rbd_ceph_con= f =3D /etc/ceph/ceph.conf<br>rbd_flatten_volume_from_snapshot =3D true<br>r= bd_max_clone_depth =3D 5<br>rbd_store_chunk_size =3D 4<br>rados_connect_tim= eout =3D -1<br>#glance_api_version =3D 2<br><br>[database]<br>connection = =3D postgresql://user:pass@10.128.2.33/cinder<br><br>[oslo_concurrency]<br>= lock_path =3D /var/lib/cinder/tmp<br><br>[oslo_messaging_rabbit]<br>rabbit_= host =3D localhost<br>rabbit_port =3D 5672<br>rabbit_userid =3D <span = style=3D"color: #000000; font-family: Arial; font-size: 16px; font-style: n= ormal; font-variant-ligatures: normal; font-variant-caps: normal; font-weig= ht: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-a= lign: start; text-indent: 0px; text-transform: none; white-space: normal; w= idows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inlin= e !important; float: none; background-color: #ffffff;" data-mce-style=3D"co= lor: #000000; font-family: Arial; font-size: 16px; font-style: normal; font= -variant-ligatures: normal; font-variant-caps: normal; font-weight: normal;= letter-spacing: normal; line-height: normal; orphans: 2; text-align: start= ; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; w= ord-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !importan= t; float: none; background-color: #ffffff;">user</span><br>rabbit_password = =3D <span style=3D"color: #000000; font-family: Arial; font-size: 16px= ; font-style: normal; font-variant-ligatures: normal; font-variant-caps: no= rmal; font-weight: normal; letter-spacing: normal; line-height: normal; orp= hans: 2; text-align: start; text-indent: 0px; text-transform: none; white-s= pace: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;= display: inline !important; float: none; background-color: #ffffff;" data-= mce-style=3D"color: #000000; font-family: Arial; font-size: 16px; font-styl= e: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-= weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; te= xt-align: start; text-indent: 0px; text-transform: none; white-space: norma= l; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: i= nline !important; float: none; background-color: #ffffff;">pass</span></div= ><div><br></div><div data-marker=3D"__SIG_PRE__">Regards,<br>Logan</div></d= iv></body></html> ------=_Part_51316288_608143832.1472587678781--

6 years, 10 months

4
4
0 / 0

Hardering oVirt Engine

by Punaatua PK

Hello, we are subject to PCI-DSS. I have some questions. We currently have setup oVirt in our environnement. We created 2 Datacenter. - one with a cluster with hosted engine on gluster (Hyperconverged env) which represents the "LAN" part - one with a cluster with gluster storage wich is the DMZ In PCI-DSS we have to secure communication (use HTTPs as much as possible). I did saw that ovirt-ha-agent (on hosted-engine capable host) check the status of the engine by sending GET request on the hosted-engine on port 80 (the same check that hosted-engine --vm-status did in fact). Since ovirt 4.2.2, with the introduction of gluster eventing, a new flow (HTTP post resquest) is needed from gluster nodes to the engine. (In my case, it's a flow from the DMZ to the LAN part in HTTP (non secure) Here is my question. Is it possible to "hardering" this part of the engine ? Another question out of PCI scope. Events like warning and error in the dashboard are clean each days. I tried to find which process did that (look into /etc/cron.daily, root crontab, etc) on the engine without succes. Is there any maintenance task that is run periodicaly ? Could we have the list of all the engine's task ? (regulary check the status of host, vm, storage) also the frequency ? I would appreciate the help. (Great great product ovirt !) Thank you for your jobs ! We did manage KVM hypervisor as standalone machine without all the power that libvirt provides. No need to spend lot of money into licencing product (VSphere and co)

6 years, 10 months

2
3
0 / 0

Non-responsive vm's due to crashed host and hosted vm liveliness check fails

by clam2718＠gmail.com

Dear Community: The local drive on a host running ovirt-node-ng-4.1.9 in a three node cluster failed. I have production JIRA and Postres running on it at the time, not in HA, just simple vm's. Storage is via NFS on a Synology NAS. Hosted Engine was on a different host, but JIRA and Postgres vm's showed nonresponsive. I tried different things but then stupidly thought that upgrading my Hosted Engine would reinitialize the vm's that were on the failed host. Update of HE seemed to go well (output below) but now my Hosted Engine, while up, fails the liveliness check and the web management console is unavailable. I cannot console into the HE from the host it is running on. Below are the results of my attempts to console into the Hosted Engine. Please help! I have search forums, lists and Google but have not been able to fix this. My coworkers and manager are anxious. --- When I try "hosted-engine --console" after setting the console password I get The engine VM is running on this host Connected to domain HostedEngine Escape character is ^] _ The prompt is non-responsive except for the escape character key combo. --- "virsh -r list" gives ID 3, Name: HostedEngine, State: running "virsh -r console HostedEngine" gives Connected to domain HostedEngine Escape character is ^] error: operation forbidden: read only access prevents virDomainOpenConsole "virsh -r vncdisplay HostedEngine" gives "0:0" and returns me to prompt --- I am SSHed into the host running my Hosted Engine from a CentOS7 minimal install with packages xorg-x11-server-Xorg, xorg-x11-xauth and xorg-x11-apps installed. The result of "grep -i X11Forwarding /etc/ssh/sshd_config" shows it set to "Yes". I SSH into the host using "ssh -Y root(a)xxx.xxx.xxx.xxx" I am logged into the CentOS7 minimal install as root. I know root is poor practice but was trying to minimize anything that could be causing an issue. --- Below are the results of my attempt to update Hosted Engine (slightly redacted to remove personal info): --== CONFIGURATION PREVIEW ==-- Default SAN wipe after delete : False Firewall manager : firewalld Update Firewall : True Host FQDN : ovengineint.xdomainx.tld Upgrade packages : True Engine database secured connection : False Engine database user name : engine Engine database name : engine Engine database host : localhost Engine database port : 5432 Engine database host name validation : False Engine installation : True PKI organization : xdomainx.tld Set up ovirt-provider-ovn : True Configure WebSocket Proxy : True DWH installation : True DWH database secured connection : False DWH database host : localhost DWH database user name : ovirt_engine_history DWH database name : ovirt_engine_history DWH database port : 5432 DWH database host name validation : False Configure Image I/O Proxy : True Configure VMConsole Proxy : True --== SUMMARY ==-- [ INFO ] Restarting httpd Web access is enabled at: http://ovengineint.xdomainx.tld:80/ovirt-engine https://ovengineint.xdomainx.tld:443/ovirt-engine Internal CA XX:XX:XX:XX... SSH fingerprint: SHA256:xxxxxxxxxx... --== END OF SUMMARY ==-- [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20180502165652-88pkpi.log [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20180502170149-setup.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ INFO ] Execution of setup completed successfully Again, thank you so very much for any suggestions! I have found many answers on this mailing list archive to be of great insight and help. Respectfully, Charles

6 years, 10 months

3
11
0 / 0

LDAP Authentication issues

by Callum Smith

Dear All, I'm having problems getting LDAP running, login works, but I'm getting "user is not authorised to perform login" - this is even if i specify the UserRole specifically to the LDAP group the user is in. 2018-05-25 08:56:16,212+01 INFO [org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-23) [] User callum@Biomedical Research Computing successfully logged in with scopes: ovirt-app-admin ovirt-app-api ovirt-app-portal ovirt-ext=auth:sequence-priority=~ ovirt-ext=revoke:revoke-all ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search ovirt-ext=token-info:validate ovirt-ext=token:password-access 2018-05-25 08:56:16,391+01 INFO [org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-25) [63e60fe9] Running command: CreateUserSessionCommand internal: false. 2018-05-25 08:56:16,430+01 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-25) [63e60fe9] EVENT_ID: USER_VDC_LOGIN_FAILED(114), User callum@Biomedical Research Computing connecting from '192.168.65.254' failed to log in<UNKNOWN>. 2018-05-25 08:56:16,430+01 ERROR [org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default task-25) [] The user callum@Biomedical Research Computing is not authorized to perform login on a side note: is it possible to assign permissions to all members of an LDAP tree where they dont have a common group membership? Regards, Callum -- Callum Smith Research Computing Core Wellcome Trust Centre for Human Genetics University of Oxford e. callum(a)well.ox.ac.uk<mailto:callum@well.ox.ac.uk>

6 years, 10 months

4
23
0 / 0

Hosted Engine w Gluster - increase number of hosts

by ovirt＠fateknollogee.com

Using this as reference: https://www.ovirt.org/blog/2018/02/up-and-running-with-ovirt-4-2-and-glus... Assuming you want to increase the number of hosts from 3 to 5 or 9. How do you add more hosts? What is best practice & any gotcha's?

6 years, 10 months

7
15
0 / 0

VMs hung after migration

by Kapetanakis Giannis

Hi, Please have a look at BZ https://bugzilla.redhat.com/show_bug.cgi?id=1584775 about VM hung problems I have with latest kernels. Problem appeared after upgrading to 4.2.3 but I believe it has only to do with newer kernel and not any part of ovirt/vdsm/libvirt/qemu regards, Giannis

6 years, 10 months

3
2
0 / 0

Re: Fwd: FreeBSD after 10.3 could not boot (Freeze)

by Karli Sjöberg

6 years, 10 months

2
1
0 / 0

Unable to start VM on host with OVS networking

by Jonathan Dieter

I have a production ovirt setup that's gone through multiple updates over the years. At some point when 4.0 or 4.1 came out, I switched from legacy networking to OVS, and everything worked perfectly until I upgraded to 4.2. Since I upgraded to 4.2, I've been getting messages that the networks were all out of sync, but everything continued working properly. Today I tracked down the network sync problem, fixed it on one of my three hosts, and then attempted to start a VM on the host. It refused to start with the error message: "Unable to add bridge ovirtmgmt port vnet0: Operation not supported". From what I can tell, the xml being generated is still for the old legacy network. I completely reinstalled the node, using the latest 4.2.3 node ISO image, and it still doesn't work. In the cluster, the switch type is "OVS (Experimental)" (and this option can't be changed, apparently), the compatibility version is 4.2, the firewall type is firewalld and there's no "Default Network Provider". I suspect that my upgrades have somehow left my system in half OVS/half legacy mode, but I'm not sure how to move it all the way to OVS mode and I don't want to mess with the other two hosts until I'm sure I've got it figured out. My (compressed) vdsm.log is at https://www.lesbg.com/jdieter/vdsm.log.xz and my (compressed) supervdsm.log is at https://www.lesbg.com/jdieter/supervdsm.log.xz. If anyone could point me in the right direction to get this fixed, I'd sure appreciate it. Jonathan

6 years, 10 months

5
8
0 / 0

restore Self-Hosted Engine

by thetas emmanuel

hi, I follow this doc https://www.ovirt.org/documentation/self-hosted/chap-Backing_up_and_Resto... But like others, i can't restore database I Have : pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 7397; 0 0 COMMENT EXTENSION plpgsql pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension plpgsql Command was: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language'; .. ... Any solution ? emmanuel

6 years, 10 months

2
8
0 / 0

Error attaching cd iso image from data domain

by Gianluca Cecchi

Hello, I'm with oVirt 4.2.3 (upgraded from 4.1 and compatibilities set to 4.2) I have a CentOS 7 VM. I correctly uploaded an iSO image to the disks of a data storage domain (iSCSI). Now in web admin portal I select the VM, then the 3 dots in top right, then change cd I'm proposed with the [Eject] line and into the dropdown I see the two iso images I have uploaded up to now. I select an image and then OK I get a window with title "Operation canceled" and content Error while executing action Change CD: Drive image file could not be found Do I have to edit any setting in my VM to be able to connect an ISO image this way? Or other things to check? In engine.log I have: 2018-05-30 11:58:58,772+02 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.ChangeDiskVDSCommand] (d efault task-9) [d9aae17f-2a49-4d70-a909-6395d61d3ab1] Failed in 'ChangeDiskVDS' method 2018-05-30 11:58:58,775+02 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-9) [d9aae17f-2a49-4d70-a909-6395d61d3ab1] EVENT_ID: VDS_BROKER_COMMAND_FAILURE(10,802), VDSM ov200 command ChangeDiskVDS failed: Drive image file could not be found 2018-05-30 11:58:58,775+02 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ChangeDiskVDSCommand] (default task-9) [d9aae17f-2a49-4d70-a909-6395d61d3ab1] Command 'org.ovirt.engine.core.vdsbroker.vdsbroker.ChangeDiskVDSCommand' return value 'org.ovirt.engine.core.vdsbroker.vdsbroker.OneVmReturn@5e673b59' 2018-05-30 11:58:58,775+02 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ChangeDiskVDSCommand] (default task-9) [d9aae17f-2a49-4d70-a909-6395d61d3ab1] HostName = ov200 2018-05-30 11:58:58,775+02 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.ChangeDiskVDSCommand] (default task-9) [d9aae17f-2a49-4d70-a909-6395d61d3ab1] Command 'ChangeDiskVDSCommand(HostName = ov200, ChangeDiskVDSCommandParameters:{hostId='d16e723c-b44c-4c1c-be76-c67911e47ccd', vmId='2e571c77-bae1-4c1c-bf98-effaf9fed741', iface='ide', index='2', diskPath='/rhev/data-center/mnt/blockSD/fa33df49-b09d-4f86-9719-ede649542c21/images/71a84a1c-0c53-4bb9-9474-deb92419e955/5404add1-cac4-4129-b8f5-2e7b2fc0da86'})' execution failed: VDSGenericException: VDSErrorException: Failed to ChangeDiskVDS, error = Drive image file could not be found, code = 13 2018-05-30 11:58:58,775+02 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ChangeDiskVDSCommand] (default task-9) [d9aae17f-2a49-4d70-a909-6395d61d3ab1] FINISH, ChangeDiskVDSCommand, log id: 740b3c78 2018-05-30 11:58:58,775+02 ERROR [org.ovirt.engine.core.bll.storage.disk.ChangeDiskCommand] (default task-9) [d9aae17f-2a49-4d70-a909-6395d61d3ab1] Command 'org.ovirt.engine.core.bll.storage.disk.ChangeDiskCommand' failed: EngineException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to ChangeDiskVDS, error = Drive image file could not be found, code = 13 (Failed with error imageErr and code 13) 2018-05-30 11:58:58,779+02 ERROR [org.ovirt.engine.core.bll.storage.disk.ChangeDiskCommand] (default task-9) [d9aae17f-2a49-4d70-a909-6395d61d3ab1] Transaction rolled-back for command 'org.ovirt.engine.core.bll.storage.disk.ChangeDiskCommand'. 2018-05-30 11:58:58,784+02 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-9) [d9aae17f-2a49-4d70-a909-6395d61d3ab1] EVENT_ID: USER_FAILED_CHANGE_DISK_VM(102), Failed to change disk in VM c7service (Host: ov200, User: g.cecchi@internal-authz). 2018-05-30 11:59:30,262+02 INFO [org.ovirt.engine.core.bll.tasks.AsyncTaskManager] (EE-ManagedThreadFactory-engineScheduled-Thread-33) [] Setting new tasks map. The map contains now 0 tasks 2018-05-30 11:59:30,262+02 INFO [org.ovirt.engine.core.bll.tasks.AsyncTaskManager] (EE-ManagedThreadFactory-engineScheduled-Thread-33) [] Cleared all tasks of pool 'ef17cad6-7724-4cd8-96e3-9af6e529db51'. Thanks, Gianluca

6 years, 10 months

3
6
0 / 0

Asking about snapshot concept

by Terry hey

Dear all, I have a pre-allocated virtual machine. When i created a snapshot for that virtual machine, i found that it became thin-provision. And the size of the snapshot is same as the virtual machine. i would like to ask why these two behavior happened. 1. preallocated to thin provision 2. the size of snapshot is same as the disk size of virtual machine. Regards Terry

6 years, 10 months

2
3
0 / 0

oVirt hosted-engine-setup issues with getting host facts

by Mariusz Kozakowski

Hello, We've been trying to setup oVirt environment for few days but we have issue with hosted-engine-setup (ansible script). We managed to fix few small things and have them merged upstream but unfortunately right now the installation process fails on getting host facts. It looks like it cannot proceed because it fails when connecting to ovirt-engine API of the bootstrap VM. The oVirt API / webpanel is working, I tested it via a browser and I can login without issues using the admin password chosen earlier in the process. 2018-05-18 15:26:47,800+0200 INFO otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:100 TASK [Wait for the host to be up] 2018-05-18 15:39:14,025+0200 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:94 {u'_ansible_parsed': True, u'_ansible_no_log': False, u'changed': False, u'attempts': 120, u'invocation': {u'module_args': { u'pattern': u'name=host01.redacted', u'fetch_nested': False, u'nested_attributes': []}}, u'ansible_facts': {u'ovirt_hosts': []}} 2018-05-18 15:39:14,127+0200 ERROR otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:98 fatal: [localhost]: FAILED! => {"ansible_facts": {"ovirt_hosts": []}, "attempts": 120, "changed": false} May 18 13:34:34 host01 python: ansible-ovirt_hosts_facts Invoked with pattern=name=host01.redacted fetch_nested=False nested_attributes=[] auth={'timeout': 0, 'url': 'https://ovirt-dev.redacted/ovirt-engine/api', 'insecure': True, 'kerberos': False, 'compress': True, 'headers': None, 'token': 'R--token-redacted', 'ca_file': None} Do you have idea what/where is issue and how to fix it?

6 years, 10 months

4
19
0 / 0

Failure to import a VM

by Aziz

Hi All, I'm getting an error when trying to import an OVA file to my oVirt. It seems that a JAVA command is failing with an exception : Here are the logs from the engine.log file, while importing the OVA file. 2018-05-28 16:47:09,491Z ERROR [org.ovirt.engine.core.bll.exportimport.ImportVmFromOvaCommand] (EE-ManagedThreadFactory-engine-Thread-19767) [e0306ff3-db73-4030-924b-57d86023db28] Command 'org.ovirt.engine.core.bll.exportimport.ImportVmFromOvaCommand' failed: For input string: "" 2018-05-28 16:47:09,491Z ERROR [org.ovirt.engine.core.bll.exportimport.ImportVmFromOvaCommand] (EE-ManagedThreadFactory-engine-Thread-19767) [e0306ff3-db73-4030-924b-57d86023db28] Exception: java.lang.NumberFormatException: For input string: "" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.8.0_171] at java.lang.Long.parseLong(Long.java:601) [rt.jar:1.8.0_171] at org.ovirt.engine.core.utils.MacAddressRangeUtils.macToLong(MacAddressRangeUtils.java:124) [utils.jar:] at org.ovirt.engine.core.bll.network.macpool.MacPoolUsingRanges.isMacInRange(MacPoolUsingRanges.java:193) [bll.jar:] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_171] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_171] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_171] at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_171] at org.ovirt.engine.core.utils.lock.LockedObjectFactory$LockingInvocationHandler.invoke(LockedObjectFactory.java:66) [utils.jar:] at com.sun.proxy.$Proxy187.isMacInRange(Unknown Source) at java.util.function.Predicate.lambda$negate$1(Predicate.java:80) [rt.jar:1.8.0_171] at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174) [rt.jar:1.8.0_171] at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175) [rt.jar:1.8.0_171] at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) [rt.jar:1.8.0_171] at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382) [rt.jar:1.8.0_171] at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) [rt.jar:1.8.0_171] at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) [rt.jar:1.8.0_171] at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) [rt.jar:1.8.0_171] at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) [rt.jar:1.8.0_171] at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) [rt.jar:1.8.0_171] at org.ovirt.engine.core.bll.network.vm.ExternalVmMacsFinder.findExternalMacAddresses(ExternalVmMacsFinder.java:37) [bll.jar:] at org.ovirt.engine.core.bll.exportimport.ImportVmCommandBase.reportExternalMacs(ImportVmCommandBase.java:512) [bll.jar:] at org.ovirt.engine.core.bll.exportimport.ImportVmCommandBase.addVmInterfaces(ImportVmCommandBase.java:640) [bll.jar:] at org.ovirt.engine.core.bll.exportimport.ImportVmCommandBase.lambda$addVmToDb$2(ImportVmCommandBase.java:533) [bll.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInNewTransaction(TransactionSupport.java:202) [utils.jar:] at org.ovirt.engine.core.bll.exportimport.ImportVmCommandBase.addVmToDb(ImportVmCommandBase.java:529) [bll.jar:] at org.ovirt.engine.core.bll.exportimport.ImportVmFromExternalProviderCommand.addVmToDb(ImportVmFromExternalProviderCommand.java:364) [bll.jar:] at org.ovirt.engine.core.bll.exportimport.ImportVmCommandBase.executeVmCommand(ImportVmCommandBase.java:474) [bll.jar:] at org.ovirt.engine.core.bll.VmCommand.executeCommand(VmCommand.java:161) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1133) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1285) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1934) [bll.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:164) [utils.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:103) [utils.jar:] at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1345) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:400) [bll.jar:] at org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner.executeValidatedCommand(PrevalidatingMultipleActionsRunner.java:204) [bll.jar:] at org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner.runCommands(PrevalidatingMultipleActionsRunner.java:176) [bll.jar:] at org.ovirt.engine.core.bll.PrevalidatingMultipleActionsRunner.lambda$invokeCommands$3(PrevalidatingMultipleActionsRunner.java:182) [bll.jar:] at org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil$InternalWrapperRunnable.run(ThreadPoolUtil.java:96) [utils.jar:] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_171] at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_171] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171] at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171] at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250) [javax.enterprise.concurrent-1.0.jar:] at org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread.run(ElytronManagedThreadFactory.java:78) 2018-05-28 16:47:09,515Z ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-19767) [e0306ff3-db73-4030-924b-57d86023db28] EVENT_ID: IMPORTEXPORT_IMPORT_VM_FAILED(1,153), Failed to import Vm PA-VM-8.0.0 to Data Center DC2, Cluster Cluster2 2018-05-28 16:47:09,523Z INFO [org.ovirt.engine.core.bll.exportimport.ImportVmFromOvaCommand] (EE-ManagedThreadFactory-engine-Thread-19767) [e0306ff3-db73-4030-924b-57d86023db28] Lock freed to object 'EngineLock:{exclusiveLocks='[PA-VM-8.0.0=VM_NAME, 2b384fab-2ddb-4069-b4ba-59d0fe4fc8c5=VM]', sharedLocks=''}' 2018-05-28 16:47:11,057Z ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-81) [] IrsBroker::Failed::GetStoragePoolInfoVDS Can anyone help to get this resolved ? Thanks

6 years, 10 months

3
11
0 / 0

Debugging ceph access

by Bernhard Dick

Hi, as you might already know I try to use ceph with openstack in an oVirt test environment. I'm able to create and remove volumes. But if I try to run a VM which contains a ceph volume it is in the "Wait for launch" state for a very long time. Then it gets into "down" state again. The qemu log states 2018-05-25T15:03:41.100401Z qemu-kvm: -drive file=rbd:rbd/volume-3bec499e-d0d0-45ef-86ad-2c187cdb2811:id=cinder:auth_supported=cephx\;none:mon_host=[mon0]\:6789\;[mon1]\:6789,file.password-secret=scsi0-0-0-0-secret0,format=raw,if=none,id=drive-scsi0-0-0-0,serial=3bec499e-d0d0-45ef-86ad-2c187cdb2811,cache=none,werror=stop,rerror=stop,aio=threads: error connecting: Connection timed out 2018-05-25 15:03:41.109+0000: shutting down, reason=failed On the monitor hosts I see traffic with the ceph-mon-port, but not on other ports (the osds for example). In the ceph logs however I don't really see what happens. Do you have some tips how to debug this problem? Regards Bernhard

6 years, 10 months

4
7
0 / 0

Cannot see ipaddr of new VM

by 03ce007＠gmail.com

I have got a self-hosted-engine (4.2) running on centos (7.4). I am trying to create new vanilla vm with static ip using cloud-init to test ssh connectivity. I have below playbook - - name: Add vanilla vm ovirt_vms: auth: "{{ ovirt_auth }}" name: test01 cluster: Default state: running memory: 2GiB cpu_cores: 8 operating_system: rhel_7x64 high_availability: true high_availability_priority: 50 # Available from Ansible 2.5 cloud_init: nic_boot_protocol: static nic_ip_address: 10.34.60.86 nic_netmask: 255.255.252.0 nic_gateway: 10.34.63.254 nic_name: eth1 nic_on_boot: true host_name: test01.ovirt.dw custom_script: | write_files: - content: | Hello, world! path: /tmp/greeting.txt permissions: '0644' user_name: root root_password: super_password nics: - name: vnet0 network: ovirtmgmt profile: ovirtmgmt interface: virtio # taken from actual vm-infra playbook - name: Add disks ovirt_disks: auth: "{{ ovirt_auth }}" name: "{{ item.0.name }}_{{ item.1.name }}" vm_name: test01 size: "{{ item.1.size | default(omit) }}" format: "{{ item.1.format | default(omit) }}" storage_domain: "{{ item.1.storage_domain | default(omit) }}" interface: "{{ item.1.interface | default(omit) }}" bootable: "{{ item.1.bootable | default(omit) }}" wait: true with_subelements: - "{{ vms }}" - "profile.disks" - flags: skip_missing: true the playbook runs successfully, but when I want to see the summary of vms using ovirt4.py, i do not see any devices attached, nor using curl api i see anything under reported_devices. Is there something I am missing? thank you.

6 years, 10 months

3
6
0 / 0

oVirt 4.2 and CLI options

by Simon Coter

Hi, what is the best choice for a CLI interface vs oVirt 4.2 ? I've looked for it and I saw that ovirt-shell is already deprecated. Thanks Simon

6 years, 10 months

4
4
0 / 0

Hey, guys, I have a trouble with ovirt OVN.

by Чижевский _ЕД

I just have no ping between vms on different hosts when connecting ovn network with subnet to physical network(ovirtmgmt)? I did this thing vdsm-tool ovn-config 172.20.139.27(ip of my engine) 172.20.139.81(ip of host, which storaging vm).

6 years, 10 months

2
1
0 / 0

oVirt: single host install

by ovirt＠fateknollogee.com

Use case: small sites with a minimum number of vm's. Is there such a thing as a single host install? Is it valid for production use? What kind of storage?

6 years, 11 months

5
8
0 / 0

VM status and issue with cloud_init

by 03ce007＠gmail.com

Some what new to the VM and Ovirt world here and need some help understanding terminologies and get the VM to work as per requirement. I have a self-hosted-engine (4.2) running on centos (7.4). The engine is in good health and I have deployed a test VM using below playbook successfully. It is currently in "up" state. - name: oVirt Self-Hosted-Engine - Manage VMs hosts: hypervisor_ovirt gather_facts: false vars_files: # Contains encrypted `engine_password` varibale using ansible-vault - ovirt-secrets.yml vars: engine_url: https://engine-ovirt.dw/ovirt-engine/api engine_user: admin@internal engine_cafile: /etc/pki/ovirt-engine/ca.pem mytest_vm: cluster: Default memory: 64GiB memory_guaranteed: 1GiB cores: 2 nics: - name: vnet0 network: ovirtmgmt profile: ovirtmgmt interface: virtio wait: true domain: node.dev.dw os_type: rhel_7x64 ssh_key: ssh-rsa AAA...LGx user01@mytestvm root_password: super_password disks: - size: 20GiB name: data storage_domain: hosted_storage interface: virtio bootable: true nics: - name: vnet0 network: ovirtmgmt profile: ovirtmgmt interface: virtio vms: - name: mytest_vm tag: mytest_vm profile: "{{ mytest_vm }}" cloud_init: dns_servers: - 10.90.x.1 - 10.90.x.1 nic_boot_protocol: static nic_ip_address: 10.90.x.y nic_netmask: 255.255.255.0 nic_gateway: 10.90.x.z nic_name: eth0 nic_on_boot: true host_name: mytestvm.test.dw custom_script: | write_files: - content: | Hello, world! path: /tmp/greeting.txt permissions: '0644' user_name: root root_password: super_password cloud_init_persist: true roles: - oVirt.vm-infra Above playbook runs fine, but when i see summary using ovirt4.py, i do not see ipaddr for this test vm. - I do not see the ipaddr for this VM despite specifying it using cloud_init - does the "up" status mean it has "booted" or I need to do something else to boot it with centos 7.4 minimal Thank you in advance.

6 years, 11 months

3
5
0 / 0

Gluster problems, cluster performance issues

by Jim Kusznir

Hello: I've been having some cluster and gluster performance issues lately. I also found that my cluster was out of date, and was trying to apply updates (hoping to fix some of these), and discovered the ovirt 4.1 repos were taken completely offline. So, I was forced to begin an upgrade to 4.2. According to docs I found/read, I needed only add the new repo, do a yum update, reboot, and be good on my hosts (did the yum update, the engine-setup on my hosted engine). Things seemed to work relatively well, except for a gluster sync issue that showed up. My cluster is a 3 node hyperconverged cluster. I upgraded the hosted engine first, then engine 3. When engine 3 came back up, for some reason one of my gluster volumes would not sync. Here's sample output: [root@ovirt3 ~]# gluster volume heal data-hdd info Brick 172.172.1.11:/gluster/brick3/data-hdd /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/48d7ecb8-7ac5-4725-bca5-b3519681cf2f/0d6080b0-7018-4fa3-bb82-1dd9ef07d9b9 /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/647be733-f153-4cdc-85bd-ba72544c2631/b453a300-0602-4be1-8310-8bd5abe00971 /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/6da854d1-b6be-446b-9bf0-90a0dbbea830/3c93bd1f-b7fa-4aa2-b445-6904e31839ba /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/7f647567-d18c-44f1-a58e-9b8865833acb/f9364470-9770-4bb1-a6b9-a54861849625 /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/f3c8e7aa-6ef2-42a7-93d4-e0a4df6dd2fa/2eb0b1ad-2606-44ef-9cd3-ae59610a504b /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/b1ea3f62-0f05-4ded-8c82-9c91c90e0b61/d5d6bf5a-499f-431d-9013-5453db93ed32 /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/8c8b5147-e9d6-4810-b45b-185e3ed65727/16f08231-93b0-489d-a2fd-687b6bf88eaa /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/12924435-b9c2-4aab-ba19-1c1bc31310ef/07b3db69-440e-491e-854c-bbfa18a7cff2 Status: Connected Number of entries: 8 Brick 172.172.1.12:/gluster/brick3/data-hdd /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/48d7ecb8-7ac5-4725-bca5-b3519681cf2f/0d6080b0-7018-4fa3-bb82-1dd9ef07d9b9 /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/647be733-f153-4cdc-85bd-ba72544c2631/b453a300-0602-4be1-8310-8bd5abe00971 /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/b1ea3f62-0f05-4ded-8c82-9c91c90e0b61/d5d6bf5a-499f-431d-9013-5453db93ed32 /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/6da854d1-b6be-446b-9bf0-90a0dbbea830/3c93bd1f-b7fa-4aa2-b445-6904e31839ba /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/7f647567-d18c-44f1-a58e-9b8865833acb/f9364470-9770-4bb1-a6b9-a54861849625 /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/8c8b5147-e9d6-4810-b45b-185e3ed65727/16f08231-93b0-489d-a2fd-687b6bf88eaa /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/12924435-b9c2-4aab-ba19-1c1bc31310ef/07b3db69-440e-491e-854c-bbfa18a7cff2 /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/f3c8e7aa-6ef2-42a7-93d4-e0a4df6dd2fa/2eb0b1ad-2606-44ef-9cd3-ae59610a504b Status: Connected Number of entries: 8 Brick 172.172.1.13:/gluster/brick3/data-hdd /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/b1ea3f62-0f05-4ded-8c82-9c91c90e0b61/d5d6bf5a-499f-431d-9013-5453db93ed32 /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/8c8b5147-e9d6-4810-b45b-185e3ed65727/16f08231-93b0-489d-a2fd-687b6bf88eaa /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/12924435-b9c2-4aab-ba19-1c1bc31310ef/07b3db69-440e-491e-854c-bbfa18a7cff2 /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/f3c8e7aa-6ef2-42a7-93d4-e0a4df6dd2fa/2eb0b1ad-2606-44ef-9cd3-ae59610a504b /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/647be733-f153-4cdc-85bd-ba72544c2631/b453a300-0602-4be1-8310-8bd5abe00971 /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/48d7ecb8-7ac5-4725-bca5-b3519681cf2f/0d6080b0-7018-4fa3-bb82-1dd9ef07d9b9 /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/6da854d1-b6be-446b-9bf0-90a0dbbea830/3c93bd1f-b7fa-4aa2-b445-6904e31839ba /cc65f671-3377-494a-a7d4-1d9f7c3ae46c/images/7f647567-d18c-44f1-a58e-9b8865833acb/f9364470-9770-4bb1-a6b9-a54861849625 Status: Connected Number of entries: 8 --------- Its been in this state for a couple days now, and bandwidth monitoring shows no appreciable data moving. I've tried repeatedly commanding a full heal from all three clusters in the node. Its always the same files that need healing. When running gluster volume heal data-hdd statistics, I see sometimes different information, but always some number of "heal failed" entries. It shows 0 for split brain. I'm not quite sure what to do. I suspect it may be due to nodes 1 and 2 still being on the older ovirt/gluster release, but I'm afraid to upgrade and reboot them until I have a good gluster sync (don't need to create a split brain issue). How do I proceed with this? Second issue: I've been experiencing VERY POOR performance on most of my VMs. To the tune that logging into a windows 10 vm via remote desktop can take 5 minutes, launching quickbooks inside said vm can easily take 10 minutes. On some linux VMs, I get random messages like this: Message from syslogd@unifi at May 28 20:39:23 ... kernel:[6171996.308904] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [mongod:14766] (the process and PID are often different) I'm not quite sure what to do about this either. My initial thought was upgrad everything to current and see if its still there, but I cannot move forward with that until my gluster is healed... Thanks! --Jim

6 years, 11 months

7
37
0 / 0

logical_name of virtual machine disk not seen in the ovirt engine

by Punaatua PK

Hello, i used the vm_backup script as provide here : https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/vm_bac... I understood the process to backup VM. I'm stuck at getting the logical_name of the disk when the snapshot disk is attached in a VM. I checked the flow like this: - The disk is attached on the VM - oVirt guest agent detect the new disk and the mapping seen on the LOG (i did put those log in DEBUG in /etc/ovirt-guest-agent.conf), i also reduce the report_disk_usage to 10 to speed up the process - VDSM on the host get the info from the ovirt guest agent seen by running the following command vdsm-client Host getVMFullList - On the engine the logical_name is empty seen with the following sql request select device,type,device_id, logical_name from vm_device where type='disk' and vm_id='XXX'; ovirt-engine-4.2.3.5-1.el7.centos.noarch vdsm-4.20.27.1-1.el7.centos.x86_64 ovirt-guest-agent-common-1.0.14-1.el7.noarch Do you have an idea ? Is the information request by the engine to VDSM ? VDSM does report to the engine ? What is the flow to get the logical_name populated in the engine DB, python SDK ? I can provide logs if needed. I juste don't know how to enable debug on VDSM (I will take a look for this)

6 years, 11 months

1
3
0 / 0

ovirt 4.2.3 console.vv provide IP addr, not FQHN for host= (spice connection)

by Oliver Riesener

Hi, i recently upgraded to ovirt 4.2.3-[78] and noticed that the spice client got and use host=IPAddr from received console.vv file and not host=FQHN of the virtualization host. I need the FQHN because i access ovirt-webui remote via ssh with port forwarding. I added a "127.0.0.1 FQHN" entry in /etc/hosts on client side to access remote ports. Please could everyone provide a < 4.2.3 console.vv file ? How can i change the behavior back to FQHN? How can i re enable WebSocket Proxy ? It's permanent False in engine-setup? Greetings Oliver

6 years, 11 months

3
3
0 / 0

how to use oVirt engine API to retrieve the attached VM list by a disk id.

by iterjpnic

Hi all, I use oVirt engine API v4.2 for implementing terraform oVirt provider. And I want to check if a Disk has been attached to a VM, so I need to find all vms attached by this disk. But after I checked the GET-Response data from the "/ovirt-engine/api/disks/<disk-id>" rest url, there has no disk-attachment/vm related properties or links. I could get a trade-off, by the following steps: 1. getting all vms 2. get all disk-attachments of each vm 3. check if the given disk id equals to the `disk` property of each disk-attachment` 4. If equals, append the vm to result list Is there any simpler and smarter way to get this? Thanks.

6 years, 11 months

3
6
0 / 0

Re: [ANN] oVirt 4.2.4 Second Release Candidate is now available

by Karli Sjöberg

6 years, 11 months

1
0
0 / 0

Re: [ANN] oVirt 4.2.4 Second Release Candidate is now available

by Karli Sjöberg

6 years, 11 months

2
1
0 / 0

[ANN] oVirt 4.2.4 Second Release Candidate is now available

by Lev Veyde

The oVirt Project is pleased to announce the availability of the oVirt 4.2.4 Second Release Candidate, as of May 31st, 2018 This update is a release candidate of the fourth in a series of stabilization updates to the 4.2 series. This is pre-release software. This pre-release should not to be used in production. This release is available now for: * Red Hat Enterprise Linux 7.5 or later * CentOS Linux (or similar) 7.5 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.5 or later * CentOS Linux (or similar) 7.5 or later See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is available - oVirt Node is available [2] Additional Resources: * Read more about the oVirt 4.2.4 release highlights: http://www.ovirt.org/release/4.2.4/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] http://www.ovirt.org/release/4.2.4/ [2] http://resources.ovirt.org/pub/ovirt-4.2-pre/iso/ -- Lev Veyde Software Engineer, RHCE | RHCVA | MCITP Red Hat Israel <https://www.redhat.com> lev(a)redhat.com | lveyde(a)redhat.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

6 years, 11 months

2
1
0 / 0

Setting up new VM

by 03ce007＠gmail.com

I have self-hosted-engine (4.2) running on centos (7.4), the engine is running fine so I am trying to deploy a test vm to check ssh connectivity. however, the vm-infra role runs without any issues and I can see the new VM is in "up" state but it does not have any IP assigned eventhough I have defined it in the cloud_init dict. What I have noticed is that the reported_devices array comes out empty and hence the "Wait for VMs IP" task within create_vm.yml is keep getting skipped. TASK [oVirt.vm-infra : Wait for VMs IP] ****************************************************************************************************************************************************************************************************** task path: /ansible/roles/oVirt.vm-infra/tasks/main.yml:102 skipping: [hypervisor-ovirt] => (item={'name': 'mytest01-vm', 'tag': 'httpd_vm', 'profile': {'cluster': 'Default', 'domain': 'node.dev.dw', 'template': 'rhel7', 'memory': '2GiB', 'cores': 2, 'ssh_key': 'ssh-rsa AAA...LGx user@fqdn', 'disks': [{'size': '10GiB', 'name': 'data', 'storage_domain': 'hosted_storage', 'interface': 'virtio'}]}, 'cloud_init': {'host_name': 'mytestvm', 'dns_servers': '10.90.x.y 10.90.x.z', 'nic_boot_protocol': 'static', 'nic_ip_address': '10.90.0.160', 'nic_netmask': '255.255.255.0', 'nic_gateway': '10.90.0.a', 'nic_name': 'eth0', 'nic_on_boot': True, 'custom_script': "write_files:\n - content: |\n Hello, world!\n path: /tmp/greeting.txt\n permissions: '0644'\n", 'user_name': 'root', 'root_password': 'super_pass'}, 'cloud_init_persist': True}) => { "changed": false, "item": { "cloud_init": { "custom_script": "write_files:\n - content: |\n Hello, world!\n path: /tmp/greeting.txt\n permissions: '0644'\n", "dns_servers": "10.90.x.y 10.90.x.z", "host_name": "mytestvm", "nic_boot_protocol": "static", "nic_gateway": "10.90.x.a", "nic_ip_address": "10.90.x.b", "nic_name": "eth0", "nic_netmask": "255.255.255.0", "nic_on_boot": true, "root_password": "super_pass", "user_name": "root" }, "cloud_init_persist": true, "name": "mytest01-vm", "profile": { "cluster": "Default", "cores": 2, "disks": [ { "interface": "virtio", "name": "data", "size": "10GiB", "storage_domain": "hosted_storage" } ], "domain": "node.dev.dw", "memory": "2GiB", "ssh_key": "ssh-rsa AAA...LGx user@fqdn", "template": "rhel7" }, "tag": "httpd_vm" }, "skip_reason": "Conditional result was False" } I think this is the very last stage I am once the ssh connection works, I will be able to use with install yum repo, etc. Please advise.

6 years, 11 months

1
0
0 / 0

Unable to login after upgrade

by Michael Watters

I recently upgraded one of our ovirt engines from 4.1 to the 4.2.3 release and the admin account is no longer able to login. After entering the user name and password I receive a message that states "The user admin@internal is not authorized to perform login". Is there a way to resolve this? Resetting the password did not work.

6 years, 11 months

3
5
0 / 0

CephFS

by Markus Stockhausen

Hi there, coming from Gluster (standalone, mounted on nodes via fuse) and NFS storage domains we want to give Ceph a try. If I understand it right it should be possible to mount it in 3 ways. 1. via Cinder 2. via NFS (ganesha) 3. via CephFS (Posix) We do not need highest performance and want to keep things simple on the OVirt side (like NFS). From management/integration perspective CephFS seems to be the way to go. Any thoughts I missed that could favour the other setups? Best regards. Markus

6 years, 11 months

1
0
0 / 0

Re: Simple API call to start VM

by Kirin van der Veer

Many thanks to: gsswzt, Luca, Andrej, Fred, Karli, Ondra and Bohdan for their replies. A number of people mentioned the need to specify a CA cert, but curl was able to find my organizations CA locally - so that was not an issue. Correcting my url to include ovirt-engine in the path and my username to admin@internal as suggested by Andrej as per below: curl --user "admin@internal:SECRETPASSWORD" --request POST --header "Content-Type: application/xml" --header "Accept: application/xml" --data '</action>' https://ovirt-engine.localnet:443/ovirt-engine/api/vms/69c47a91-bbv1-4eda... Got me a new error message: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <fault> <detail>For correct usage, see: https://ovirt-engine.localnet/ovirt-engine/apidoc#services/vm/methods/start </detail> <reason>Request syntactically incorrect.</reason> </fault> I followed the URL, but it just seemed to repeat the information already available at http://ovirt.github.io/ovirt-engine-api-model/4.2/#services/vm/methods/start Here is the relevant section of engine.log on ovirt-engine.localnet: 2018-05-31 10:48:15,550+10 INFO [org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-25) [] User admin@internal successfully logged in with scopes: ovirt-app-api ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search ovirt-ext=token-info:validate ovirt-ext=token:password-access 2018-05-31 10:48:15,569+10 INFO [org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-29) [8ffa0f3] Running command: CreateUserSessionCommand internal: false. 2018-05-31 10:48:15,581+10 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-29) [8ffa0f3] EVENT_ID: USER_VDC_LOGIN(30), User admin@internal-authz connecting from '192.168.1.0' using session 'JNweIEHoHhw9U+wMt7Z03Ovb5Pc1zR3WyvTcSfRTpdHjd55CHbcspfDcJgToMVshtlgXamzvUSW2rzHB9ApJHA==' logged in. 2018-05-31 10:48:15,587+10 ERROR [org.ovirt.engine.api.restapi.resource.validation.IOExceptionMapper] (default task-29) [] IO exception while processing "POST" request for path "/vms/69c47a91-bbv1-4eda-b71d-7bddf82ee8ab/start" 2018-05-31 10:48:15,587+10 ERROR [org.ovirt.engine.api.restapi.resource.validation.IOExceptionMapper] (default task-29) [] Exception: java.io.IOException: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,2] Message: The markup in the document preceding the root element must be well-formed. at org.ovirt.engine.api.restapi.xml.JAXBProvider.readFrom(JAXBProvider.java:200) [restapi-jaxrs.jar:] at org.ovirt.engine.api.restapi.xml.JAXBProvider.readFrom(JAXBProvider.java:162) [restapi-jaxrs.jar:] at org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.readFrom(AbstractReaderInterceptorContext.java:66) [resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final] at org.jboss.resteasy.core.interception.ServerReaderInterceptorContext.readFrom(ServerReaderInterceptorContext.java:61) [resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final] at org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:56) [resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final] at org.jboss.resteasy.security.doseta.DigitalVerificationInterceptor.aroundReadFrom(DigitalVerificationInterceptor.java:36) [resteasy-crypto-3.0.24.Final.jar:3.0.24.Final] <MANY MANY LINES OF ERRORS SNIPPED> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171] Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,2] Message: The markup in the document preceding the root element must be well-formed. at com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:604) [rt.jar:1.8.0_171] at com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:164) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:415) at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:386) at org.ovirt.engine.api.restapi.xml.JAXBProvider.readFrom(JAXBProvider.java:187) [restapi-jaxrs.jar:] ... 104 more 2018-05-31 10:48:15,593+10 INFO [org.ovirt.engine.core.bll.aaa.LogoutSessionCommand] (default task-29) [4531c52a] Running command: LogoutSessionCommand internal: false. 2018-05-31 10:48:15,598+10 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-29) [4531c52a] EVENT_ID: USER_VDC_LOGOUT(31), User admin@internal-authz connected from '192.168.1.0' using session 'JNweIEHoHhw9U+wMt7Z03Ovb5Pc1zR3WyvTcSfRTpdHjd55CHbcspfDcJgToMVshtlgXamzvUSW2rzHB9ApJHA==' logged out. 2018-05-31 10:48:27,542+10 INFO [org.ovirt.engine.core.sso.servlets.OAuthRevokeServlet] (default task-32) [] User admin@internal successfully logged out 2018-05-31 10:48:27,550+10 INFO [org.ovirt.engine.core.bll.aaa.TerminateSessionsForTokenCommand] (default task-35) [76676851] Running command: TerminateSessionsForTokenCommand internal: true. Later I thought that perhaps the problem was that I need to use the VM Name instead of it's UUID, since all of the examples in the official docs use something like "123" or "007". However when I changed the curl request to the below: curl --user "admin@internal:SECRETPASSWORD" --request POST --header "Content-Type: application/xml" --header "Accept: application/xml" --data '</action>' https://ovirt-engine.localnet:443/ovirt-engine/api/vms/name_of_my_vm/start I got no feedback on the commandline. So I checked engine.log, but there were only a few entries as per below: 2018-05-31 11:43:39,940+10 INFO [org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-49) [] User admin@internal successfully logged in with scopes: ovirt-app-api ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search ovirt-ext=token-info:validate ovirt-ext=token:password-access 2018-05-31 11:43:39,954+10 INFO [org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-39) [41871d82] Running command: CreateUserSessionCommand internal: false. 2018-05-31 11:43:39,962+10 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-39) [41871d82] EVENT_ID: USER_VDC_LOGIN(30), User admin@internal-authz connecting from '192.168.1.0' using session 'EfiWrbyRpCilceYzJsgOz+E/An7JBAHr2ASziyZyFykop9vO77gc1+u3CQh542eNq/BXOXpOOxKhQLQhIKarEg==' logged in. 2018-05-31 11:43:39,971+10 INFO [org.ovirt.engine.core.bll.aaa.LogoutSessionCommand] (default task-39) [6209f488] Running command: LogoutSessionCommand internal: false. 2018-05-31 11:43:39,976+10 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-39) [6209f488] EVENT_ID: USER_VDC_LOGOUT(31), User admin@internal-authz connected from '192.168.1.0' using session 'EfiWrbyRpCilceYzJsgOz+E/An7JBAHr2ASziyZyFykop9vO77gc1+u3CQh542eNq/BXOXpOOxKhQLQhIKarEg==' logged out. Note that the name I specified does not show up at all. Anyone have any ideas? On Wed, May 30, 2018 at 7:03 PM, Andrej Krejcir <akrejcir(a)redhat.com> wrote: > Hi, > > the URL path is missing 'ovirt-engine', it should be: > https://ovirtengine.localnet:443/ovirt-engine/api/vms/ > dfbba498-e8b6-4fee-a86c-c91ab68eae0d/start > > Also, the admin user name is: 'admin@internal' > > Here is the API documentation, for more info: > http://ovirt.github.io/ovirt-engine-api-model/4.2/# > services/vm/methods/start > > > Andrej > > On 30 May 2018 at 08:07, Kirin van der Veer <kirin.vanderveer@ > planetinnovation.com.au> wrote: > >> Hi oVirt users, >> I have (what I hope) is a simple problem. >> I want to make an https request to start a VM via the oVirt REST API. >> Here is the command that I think should work: >> curl --user "admin:SECRETPASSWORD" --request POST --header "Content-Type: >> application/xml" --header "Accept: application/xml" --data '</action>' >> https://ovirtengine.localnet:443/api/vms/69c47a91-bbv1-4eda- >> b71d-7bddf82ee8ab/start >> >> However I get a 404 in response (see below): >> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> >> <html><head> >> <title>404 Not Found</title> >> </head><body> >> <h1>Not Found</h1> >> <p>The requested URL /api/vms/60c47a91-bca1-4eda-b71d-7bddf82ee8ab/start >> was not found on this server.</p> >> </body></html> >> >> Where have I made a mistake here? >> >> >> >> *IMPORTANT NOTE. *If you are NOT AN AUTHORISED RECIPIENT of this e-mail, >> please contact Planet Innovation Pty Ltd by return e-mail or by telephone >> on +613 9945 7510. In this case, you should not read, print, re-transmit, >> store or act in reliance on this e-mail or any attachments, and should >> destroy all copies of them. This e-mail and any attachments are >> confidential and may contain legally privileged information and/or >> copyright material of Planet Innovation Pty Ltd or third parties. You >> should only re-transmit, distribute or commercialise the material if you >> are authorised to do so. Although we use virus scanning software, we deny >> all liability for viruses or alike in any message or attachment. This >> notice should not be removed. >> >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org >> To unsubscribe send an email to users-leave(a)ovirt.org >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> oVirt Code of Conduct: https://www.ovirt.org/communit >> y/about/community-guidelines/ >> List Archives: https://lists.ovirt.org/archiv >> es/list/users(a)ovirt.org/message/5N6N4BHF6ZFJLEARSEALCON7DJIMXRCZ/ >> >> > -- *IMPORTANT NOTE. *If you are NOT AN AUTHORISED RECIPIENT of this e-mail, please contact Planet Innovation Pty Ltd by return e-mail or by telephone on +613 9945 7510. In this case, you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. This e-mail and any attachments are confidential and may contain legally privileged information and/or copyright material of Planet Innovation Pty Ltd or third parties. You should only re-transmit, distribute or commercialise the material if you are authorised to do so. Although we use virus scanning software, we deny all liability for viruses or alike in any message or attachment. This notice should not be removed. **

6 years, 11 months

2
1
0 / 0

Attaching previously owned storage domain to 4.2 Cluster

by John Nguyen

Hi Guys, I'm working through a disaster recovery of a failed cluster. And I found the documentation for attaching the old storage domain as an import domain to a new Cluster. Both clusters are 4.2. https://ovirt.org/develop/release-management/features/storage/importstora... The documentation is referencing 3.5 and I would like to know if its still applies to the 4.2 release. When I try to do the import I see warnings below: I know that its really hard to say this operation may not be destructive. But is the general work flow outlined in the 3.5 documentation still valid? Thanks, John

6 years, 11 months

3
2
0 / 0

OVN networks

by Егор Чиж

Hello, Could you help with how to change Switch type in ovirt cluster from Linux Bridge to OVS. I mean, using this link https://ovirt.org/develop/release-management/features/network/provider-ph... I read paragraph Create a cluster with Network Type set to OVS. Now i have cluster with installing type Linux Bridge, how can i changed it to OVS? Best regards, Egor

6 years, 11 months

2
1
0 / 0

Re: Fwd: FreeBSD after 10.3 could not boot (Freeze)

by Karli Sjöberg

6 years, 11 months

2
1
0 / 0

Simple API call to start VM

by Kirin van der Veer

Hi oVirt users, I have (what I hope) is a simple problem. I want to make an https request to start a VM via the oVirt REST API. Here is the command that I think should work: curl --user "admin:SECRETPASSWORD" --request POST --header "Content-Type: application/xml" --header "Accept: application/xml" --data '</action>' https://ovirtengine.localnet:443/api/vms/69c47a91-bbv1-4eda-b71d-7bddf82e... However I get a 404 in response (see below): <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL /api/vms/60c47a91-bca1-4eda-b71d-7bddf82ee8ab/start was not found on this server.</p> </body></html> Where have I made a mistake here? -- *IMPORTANT NOTE. *If you are NOT AN AUTHORISED RECIPIENT of this e-mail, please contact Planet Innovation Pty Ltd by return e-mail or by telephone on +613 9945 7510. In this case, you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. This e-mail and any attachments are confidential and may contain legally privileged information and/or copyright material of Planet Innovation Pty Ltd or third parties. You should only re-transmit, distribute or commercialise the material if you are authorised to do so. Although we use virus scanning software, we deny all liability for viruses or alike in any message or attachment. This notice should not be removed. **

6 years, 11 months

7
7
0 / 0

Re: Fwd: FreeBSD after 10.3 could not boot (Freeze)

by Karli Sjöberg

6 years, 11 months

1
0
0 / 0

Re: ovirt-node: freshly installed node: network interfaces not visible

by Ales Musil

On Wed, May 30, 2018 at 10:14 AM, Etienne Charlier < Etienne.Charlier(a)reduspaceservices.eu> wrote: > Hello, Thanks for the support > > > log are only sent to you , not to the list !!! > > > Kind Regards, > > Etienne > > Can you also please send the engine log? Regards, Ales > > ------------------------------ > *De :* Ales Musil <amusil(a)redhat.com> > *Envoyé :* mercredi 30 mai 2018 09:02 > *À :* Etienne Charlier > *Cc :* users > *Objet :* Re: [ovirt-users] Re: ovirt-node: freshly installed node: > network interfaces not visible > > > > On Tue, May 29, 2018 at 8:40 AM, <etienne.charlier(a)reduspaceservices.eu> > wrote: > >> Hello Ales, >> >> Thanks for the answer ! >> >> I tried multiple time to refresh capabilities... without success >> >> For the record, the tab named "Host Devices" is also empty >> >> Have a nice Day >> Etienne >> > > Can you please send us the vdsm and supervdsm log from the host? > > > > >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org >> To unsubscribe send an email to users-leave(a)ovirt.org >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> oVirt Code of Conduct: https://www.ovirt.org/communit >> y/about/community-guidelines/ >> List Archives: https://lists.ovirt.org/archiv >> es/list/users(a)ovirt.org/message/ISBFSCIX7J6INUIKJXUSI6J4DWKA326Q/ >> > > > > -- > > ALES MUSIL > INTERN - rhv network > > Red Hat EMEA <https://www.redhat.com/> > > > amusil(a)redhat.com IM: amusil > <https://red.ht/sig> > -- ALES MUSIL INTERN - rhv network Red Hat EMEA <https://www.redhat.com/> amusil(a)redhat.com IM: amusil <https://red.ht/sig>

6 years, 11 months

1
0
0 / 0

Use an oVirt-VM as a VDSM server

by James Michels

Greetings. In terms of teaching our students how to create and configure an oVirt infrastructure, we're planning to provide each of them a VM that will act as a Manager server, which has no issues so far. The problem is that we don't have enough physical machines to use as virtualization servers (VDSM), therefore we have been trying to use a CentOS7 based oVirt guest to run as a VDSM server. However, when trying to add it as a host, a (logical) error message shows up saying that the VM doesn't allow virtualization. The question is simple: Is there a way to enable virtualization on an oVirt VM, so we can deploy them as VDSM servers? This is oVirt 4.2.2 FWIW. Thanks James

6 years, 11 months

4
3
0 / 0

Re: Simple API call to start VM

by Karli Sjöberg

6 years, 11 months

1
0
0 / 0

FreeBSD after 10.3 could not boot (Freeze)

by Paul.LKW

HI All: Any one have tried to boot up FreeBSD 10.4, I tried 10.3 is all working fine but no lucky in 10.4 at all even boot from DVD !!! Attached is the point freezes. BR, Paul.LKW

6 years, 11 months

3
5
0 / 0

Re: Fwd: FreeBSD after 10.3 could not boot (Freeze)

by Karli Sjöberg

6 years, 11 months

2
1
0 / 0

Re: Gluster quorum

by Sahina Bose

[+users] Can you provide the engine.log to see why the monitoring is not working here. thanks! On Wed, May 16, 2018 at 2:08 PM, Demeter Tibor <tdemeter(a)itsmart.hu> wrote: > Hi, > > Meanwhile, I did the upgrade engine, but the gluster state is same on my > first node. > I've attached some screenshot of my problem. > > Thanks > > Tibor > > > > ----- 2018. máj.. 16., 10:16, Demeter Tibor <tdemeter(a)itsmart.hu> írtaHi, > > > If 4.3.4 will release, i just have to remove the nightly repo and update > to stable? > > I'm sorry for my terrible English, I try to explain what was my problem > with update. > I'm upgraded from 4.1.8. > > I followed up the official hosted-engine update documentation, that was > not clear me, because it has referenced to a lot of old thing (i think). > https://www.ovirt.org/documentation/upgrade-guide/upgrade-guide/ > https://www.ovirt.org/documentation/how-to/hosted- > engine/#upgrade-hosted-engine > > Maybe it need to update, because I had a lot of question under upgrade and > I was not sure in all of necessary steps. For example, If I need to > installing the new, 4.2 repo on the hosts, then need to remove the old repo > from that? > Why I need to do a" yum update -y" on hosts, meanwhile there is an > "Updatehost" menu in the GUI? So, maybe it outdated. > Since upgrade hosted engine, and the first node, I have problems with > gluster. It seems to working fine if you check it from console "gluster > volume status, etc" but not on the Gui, because now it yellow, and the > brick reds in the first node. > > Previously I did a mistake with glusterfs, my gluster config was wrong. I > have corrected them, but it did not helped to me,gluster bricks are reds on > my first node yet.... > > > Now I try to upgrade to nightly, but I'm affraid, because it a living, > productive system, and I don't have downtime. I hope it will help me. > > Thanks for all, > > Regards, > Tibor Demeter > > > > ----- 2018. máj.. 16., 9:58, Sahina Bose <sabose(a)redhat.com> írta: > > > > On Wed, May 16, 2018 at 1:19 PM, Demeter Tibor <tdemeter(a)itsmart.hu> > wrote: > >> Hi, >> >> is it a different, unstable repo? I have a productive cluster, how is >> safe that? >> I don't have any experience with nightly build. How can I use this? It >> have to install to the engine VM or all of my hosts? >> Thanks in advance for help me.. >> > > Only on the engine VM. > > Regarding stability - it passes CI so relatively stable, beyond that there > are no guarantees. > > What's the specific problem you're facing with update? Can you elaborate? > > >> Regards, >> >> Tibor >> >> ----- 2018. máj.. 15., 9:58, Demeter Tibor <tdemeter(a)itsmart.hu> írta: >> >> Hi, >> >> Could you explain how can I use this patch? >> >> R, >> Tibor >> >> >> ----- 2018. máj.. 14., 11:18, Demeter Tibor <tdemeter(a)itsmart.hu> írta: >> >> Hi, >> >> Sorry for my question, but can you tell me please how can I use this >> patch? >> >> Thanks, >> Regards, >> Tibor >> ----- 2018. máj.. 14., 10:47, Sahina Bose <sabose(a)redhat.com> írta: >> >> >> >> On Sat, May 12, 2018 at 1:14 PM, Demeter Tibor <tdemeter(a)itsmart.hu> >> wrote: >> >>> Hi, >>> >>> Could someone help me please ? I can't finish my upgrade process. >>> >> >> https://gerrit.ovirt.org/91164 should fix the error you're facing. >> >> Can you elaborate why this is affecting the upgrade process? >> >> >>> Thanks >>> R >>> Tibor >>> >>> >>> >>> ----- 2018. máj.. 10., 12:51, Demeter Tibor <tdemeter(a)itsmart.hu> írta: >>> >>> Hi, >>> >>> I've attached the vdsm and supervdsm logs. But I don't have engine.log >>> here, because that is on hosted engine vm. Should I send that ? >>> >>> Thank you >>> >>> Regards, >>> >>> Tibor >>> ----- 2018. máj.. 10., 12:30, Sahina Bose <sabose(a)redhat.com> írta: >>> >>> There's a bug here. Can you log one attaching this engine.log and also >>> vdsm.log & supervdsm.log from n3.itsmart.cloud >>> >>> On Thu, May 10, 2018 at 3:35 PM, Demeter Tibor <tdemeter(a)itsmart.hu> >>> wrote: >>> >>>> Hi, >>>> >>>> I found this: >>>> >>>> >>>> 2018-05-10 03:24:19,096+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterVolumeAdvancedDetailsVDSCommand] >>>> (DefaultQuartzScheduler7) [43f4eaec] FINISH, GetGlusterVolumeAdvancedDetailsVDSCommand, >>>> return: org.ovirt.engine.core.common.businessentities.gluster. >>>> GlusterVolumeAdvancedDetails@ca97448e, log id: 347435ae >>>> 2018-05-10 03:24:19,097+02 ERROR [org.ovirt.engine.core.bll.gluster.GlusterSyncJob] >>>> (DefaultQuartzScheduler7) [43f4eaec] Error while refreshing brick statuses >>>> for volume 'volume2' of cluster 'C6220': null >>>> 2018-05-10 03:24:19,097+02 INFO [org.ovirt.engine.core.bll.lock.InMemoryLockManager] >>>> (DefaultQuartzScheduler8) [7715ceda] Failed to acquire lock and wait lock >>>> 'EngineLock:{exclusiveLocks='[59c10db3-0324-0320-0120-000000000339=GLUSTER]', >>>> sharedLocks=''}' >>>> 2018-05-10 03:24:19,104+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler7) [43f4eaec] START, GetGlusterLocalLogicalVolumeListVDSCommand(HostName >>>> = n4.itsmart.cloud, VdsIdVDSCommandParametersBase: >>>> {hostId='3ddef95f-158d-407c-a7d8-49641e012755'}), log id: 6908121d >>>> 2018-05-10 03:24:19,106+02 ERROR [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler7) [43f4eaec] Command ' >>>> GetGlusterLocalLogicalVolumeListVDSCommand(HostName = >>>> n4.itsmart.cloud, VdsIdVDSCommandParametersBase: >>>> {hostId='3ddef95f-158d-407c-a7d8-49641e012755'})' execution failed: >>>> null >>>> 2018-05-10 03:24:19,106+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler7) [43f4eaec] FINISH, GetGlusterLocalLogicalVolumeListVDSCommand, >>>> log id: 6908121d >>>> 2018-05-10 03:24:19,107+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler7) [43f4eaec] START, GetGlusterLocalLogicalVolumeListVDSCommand(HostName >>>> = n1.itsmart.cloud, VdsIdVDSCommandParametersBase: >>>> {hostId='8e737bab-e0bb-4f16-ab85-e24e91882f57'}), log id: 735c6a5f >>>> 2018-05-10 03:24:19,109+02 ERROR [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler7) [43f4eaec] Command ' >>>> GetGlusterLocalLogicalVolumeListVDSCommand(HostName = >>>> n1.itsmart.cloud, VdsIdVDSCommandParametersBase: >>>> {hostId='8e737bab-e0bb-4f16-ab85-e24e91882f57'})' execution failed: >>>> null >>>> 2018-05-10 03:24:19,109+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler7) [43f4eaec] FINISH, GetGlusterLocalLogicalVolumeListVDSCommand, >>>> log id: 735c6a5f >>>> 2018-05-10 03:24:19,110+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler7) [43f4eaec] START, GetGlusterLocalLogicalVolumeListVDSCommand(HostName >>>> = n2.itsmart.cloud, VdsIdVDSCommandParametersBase: >>>> {hostId='06e361ef-3361-4eaa-9923-27fa1a0187a4'}), log id: 6f9e9f58 >>>> 2018-05-10 03:24:19,112+02 ERROR [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler7) [43f4eaec] Command ' >>>> GetGlusterLocalLogicalVolumeListVDSCommand(HostName = >>>> n2.itsmart.cloud, VdsIdVDSCommandParametersBase: >>>> {hostId='06e361ef-3361-4eaa-9923-27fa1a0187a4'})' execution failed: >>>> null >>>> 2018-05-10 03:24:19,112+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler7) [43f4eaec] FINISH, GetGlusterLocalLogicalVolumeListVDSCommand, >>>> log id: 6f9e9f58 >>>> 2018-05-10 03:24:19,113+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler7) [43f4eaec] START, GetGlusterLocalLogicalVolumeListVDSCommand(HostName >>>> = n3.itsmart.cloud, VdsIdVDSCommandParametersBase: >>>> {hostId='fd2ee743-f5d4-403b-ba18-377e309169ec'}), log id: 2ee46967 >>>> 2018-05-10 03:24:19,115+02 ERROR [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler7) [43f4eaec] Command ' >>>> GetGlusterLocalLogicalVolumeListVDSCommand(HostName = >>>> n3.itsmart.cloud, VdsIdVDSCommandParametersBase: >>>> {hostId='fd2ee743-f5d4-403b-ba18-377e309169ec'})' execution failed: >>>> null >>>> 2018-05-10 03:24:19,116+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler7) [43f4eaec] FINISH, GetGlusterLocalLogicalVolumeListVDSCommand, >>>> log id: 2ee46967 >>>> 2018-05-10 03:24:19,117+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterVolumeAdvancedDetailsVDSCommand] >>>> (DefaultQuartzScheduler7) [43f4eaec] START, GetGlusterVolumeAdvancedDetailsVDSCommand(HostName >>>> = n1.itsmart.cloud, GlusterVolumeAdvancedDetailsVD >>>> SParameters:{hostId='8e737bab-e0bb-4f16-ab85-e24e91882f57', >>>> volumeName='volume1'}), log id: 7550e5c >>>> 2018-05-10 03:24:20,748+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterVolumeAdvancedDetailsVDSCommand] >>>> (DefaultQuartzScheduler7) [43f4eaec] FINISH, GetGlusterVolumeAdvancedDetailsVDSCommand, >>>> return: org.ovirt.engine.core.common.businessentities.gluster. >>>> GlusterVolumeAdvancedDetails@4a46066f, log id: 7550e5c >>>> 2018-05-10 03:24:20,749+02 ERROR [org.ovirt.engine.core.bll.gluster.GlusterSyncJob] >>>> (DefaultQuartzScheduler7) [43f4eaec] Error while refreshing brick statuses >>>> for volume 'volume1' of cluster 'C6220': null >>>> 2018-05-10 03:24:20,750+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GlusterServersListVDSCommand] >>>> (DefaultQuartzScheduler8) [7715ceda] START, GlusterServersListVDSCommand(HostName >>>> = n2.itsmart.cloud, VdsIdVDSCommandParametersBase: >>>> {hostId='06e361ef-3361-4eaa-9923-27fa1a0187a4'}), log id: 120cc68d >>>> 2018-05-10 03:24:20,930+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GlusterServersListVDSCommand] >>>> (DefaultQuartzScheduler8) [7715ceda] FINISH, GlusterServersListVDSCommand, >>>> return: [10.101.0.2/24:CONNECTED, n1.cloudata.local:CONNECTED, >>>> 10.104.0.3:CONNECTED, 10.104.0.4:CONNECTED], log id: 120cc68d >>>> 2018-05-10 03:24:20,949+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GlusterVolumesListVDSCommand] >>>> (DefaultQuartzScheduler8) [7715ceda] START, GlusterVolumesListVDSCommand(HostName >>>> = n2.itsmart.cloud, GlusterVolumesListVDSParameter >>>> s:{hostId='06e361ef-3361-4eaa-9923-27fa1a0187a4'}), log id: 118aa264 >>>> 2018-05-10 03:24:21,048+02 WARN [org.ovirt.engine.core. >>>> vdsbroker.gluster.GlusterVolumesListReturn] (DefaultQuartzScheduler8) >>>> [7715ceda] Could not associate brick '10.104.0.1:/gluster/brick/brick1' >>>> of volume 'e0f568fa-987c-4f5c-b853-01bce718ee27' with correct network >>>> as no gluster network found in cluster '59c10db3-0324-0320-0120- >>>> 000000000339' >>>> 2018-05-10 03:24:21,055+02 WARN [org.ovirt.engine.core. >>>> vdsbroker.gluster.GlusterVolumesListReturn] (DefaultQuartzScheduler8) >>>> [7715ceda] Could not associate brick '10.104.0.1:/gluster/brick/brick2' >>>> of volume 'e0f568fa-987c-4f5c-b853-01bce718ee27' with correct network >>>> as no gluster network found in cluster '59c10db3-0324-0320-0120- >>>> 000000000339' >>>> 2018-05-10 03:24:21,061+02 WARN [org.ovirt.engine.core. >>>> vdsbroker.gluster.GlusterVolumesListReturn] (DefaultQuartzScheduler8) >>>> [7715ceda] Could not associate brick '10.104.0.1:/gluster/brick/brick3' >>>> of volume 'e0f568fa-987c-4f5c-b853-01bce718ee27' with correct network >>>> as no gluster network found in cluster '59c10db3-0324-0320-0120- >>>> 000000000339' >>>> 2018-05-10 03:24:21,067+02 WARN [org.ovirt.engine.core. >>>> vdsbroker.gluster.GlusterVolumesListReturn] (DefaultQuartzScheduler8) >>>> [7715ceda] Could not associate brick '10.104.0.1:/gluster2/brick/brick1' >>>> of volume '68cfb061-1320-4042-abcd-9228da23c0c8' with correct network >>>> as no gluster network found in cluster '59c10db3-0324-0320-0120- >>>> 000000000339' >>>> 2018-05-10 03:24:21,074+02 WARN [org.ovirt.engine.core. >>>> vdsbroker.gluster.GlusterVolumesListReturn] (DefaultQuartzScheduler8) >>>> [7715ceda] Could not associate brick '10.104.0.1:/gluster2/brick/brick2' >>>> of volume '68cfb061-1320-4042-abcd-9228da23c0c8' with correct network >>>> as no gluster network found in cluster '59c10db3-0324-0320-0120- >>>> 000000000339' >>>> 2018-05-10 03:24:21,080+02 WARN [org.ovirt.engine.core. >>>> vdsbroker.gluster.GlusterVolumesListReturn] (DefaultQuartzScheduler8) >>>> [7715ceda] Could not associate brick '10.104.0.1:/gluster2/brick/brick3' >>>> of volume '68cfb061-1320-4042-abcd-9228da23c0c8' with correct network >>>> as no gluster network found in cluster '59c10db3-0324-0320-0120- >>>> 000000000339' >>>> 2018-05-10 03:24:21,081+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GlusterVolumesListVDSCommand] >>>> (DefaultQuartzScheduler8) [7715ceda] FINISH, GlusterVolumesListVDSCommand, >>>> return: {68cfb061-1320-4042-abcd-9228da23c0c8=org.ovirt.engine. >>>> core.common.businessentities.gluster.GlusterVolumeEntity@7a6720d, >>>> e0f568fa-987c-4f5c-b853-01bce718ee27=org.ovirt.engine. >>>> core.common.businessentities.g >>>> luster.GlusterVolumeEntity@f88c521b}, log id: 118aa264 >>>> >>>> >>>> >>>> 2018-05-10 11:59:26,047+02 ERROR [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler4) [400fa486] Command ' >>>> GetGlusterLocalLogicalVolumeListVDSCommand(HostName = >>>> n1.itsmart.cloud, VdsIdVDSCommandParametersBase: >>>> {hostId='8e737bab-e0bb-4f16-ab85-e24e91882f57'})' execution failed: >>>> null >>>> 2018-05-10 11:59:26,047+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler4) [400fa486] FINISH, GetGlusterLocalLogicalVolumeListVDSCommand, >>>> log id: 14a71ef0 >>>> 2018-05-10 11:59:26,048+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler4) [400fa486] START, GetGlusterLocalLogicalVolumeListVDSCommand(HostName >>>> = n4.itsmart.cloud, VdsIdVDSCommandParametersBase: >>>> {hostId='3ddef95f-158d-407c-a7d8-49641e012755'}), log id: 28d9e255 >>>> 2018-05-10 11:59:26,051+02 ERROR [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler4) [400fa486] Command ' >>>> GetGlusterLocalLogicalVolumeListVDSCommand(HostName = >>>> n4.itsmart.cloud, VdsIdVDSCommandParametersBase: >>>> {hostId='3ddef95f-158d-407c-a7d8-49641e012755'})' execution failed: >>>> null >>>> 2018-05-10 11:59:26,051+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler4) [400fa486] FINISH, GetGlusterLocalLogicalVolumeListVDSCommand, >>>> log id: 28d9e255 >>>> 2018-05-10 11:59:26,052+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler4) [400fa486] START, GetGlusterLocalLogicalVolumeListVDSCommand(HostName >>>> = n2.itsmart.cloud, VdsIdVDSCommandParametersBase: >>>> {hostId='06e361ef-3361-4eaa-9923-27fa1a0187a4'}), log id: 4a7b280e >>>> 2018-05-10 11:59:26,054+02 ERROR [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler4) [400fa486] Command ' >>>> GetGlusterLocalLogicalVolumeListVDSCommand(HostName = >>>> n2.itsmart.cloud, VdsIdVDSCommandParametersBase: >>>> {hostId='06e361ef-3361-4eaa-9923-27fa1a0187a4'})' execution failed: >>>> null >>>> 2018-05-10 11:59:26,054+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler4) [400fa486] FINISH, GetGlusterLocalLogicalVolumeListVDSCommand, >>>> log id: 4a7b280e >>>> 2018-05-10 11:59:26,055+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler4) [400fa486] START, GetGlusterLocalLogicalVolumeListVDSCommand(HostName >>>> = n3.itsmart.cloud, VdsIdVDSCommandParametersBase: >>>> {hostId='fd2ee743-f5d4-403b-ba18-377e309169ec'}), log id: 18adc534 >>>> 2018-05-10 11:59:26,057+02 ERROR [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler4) [400fa486] Command ' >>>> GetGlusterLocalLogicalVolumeListVDSCommand(HostName = >>>> n3.itsmart.cloud, VdsIdVDSCommandParametersBase: >>>> {hostId='fd2ee743-f5d4-403b-ba18-377e309169ec'})' execution failed: >>>> null >>>> 2018-05-10 11:59:26,057+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterLocalLogicalVolumeListVDSCommand] >>>> (DefaultQuartzScheduler4) [400fa486] FINISH, GetGlusterLocalLogicalVolumeListVDSCommand, >>>> log id: 18adc534 >>>> 2018-05-10 11:59:26,058+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterVolumeAdvancedDetailsVDSCommand] >>>> (DefaultQuartzScheduler4) [400fa486] START, GetGlusterVolumeAdvancedDetailsVDSCommand(HostName >>>> = n3.itsmart.cloud, GlusterVolumeAdvancedDetailsVD >>>> SParameters:{hostId='fd2ee743-f5d4-403b-ba18-377e309169ec', >>>> volumeName='volume1'}), log id: 3451084f >>>> 2018-05-10 11:59:28,050+02 INFO [org.ovirt.engine.core.bll.lock.InMemoryLockManager] >>>> (DefaultQuartzScheduler3) [2eb1c389] Failed to acquire lock and wait lock >>>> 'EngineLock:{exclusiveLocks='[59c10db3-0324-0320-0120-000000000339=GLUSTER]', >>>> sharedLocks=''}' >>>> 2018-05-10 11:59:28,060+02 INFO [org.ovirt.engine.core.bll.lock.InMemoryLockManager] >>>> (DefaultQuartzScheduler3) [2eb1c389] Failed to acquire lock and wait lock >>>> 'EngineLock:{exclusiveLocks='[59c10db3-0324-0320-0120-000000000339=GLUSTER]', >>>> sharedLocks=''}' >>>> 2018-05-10 11:59:28,062+02 INFO [org.ovirt.engine.core.bll.lock.InMemoryLockManager] >>>> (DefaultQuartzScheduler3) [2eb1c389] Failed to acquire lock and wait lock >>>> 'EngineLock:{exclusiveLocks='[59c10db3-0324-0320-0120-000000000339=GLUSTER]', >>>> sharedLocks=''}' >>>> 2018-05-10 11:59:31,054+02 INFO [org.ovirt.engine.core.bll.lock.InMemoryLockManager] >>>> (DefaultQuartzScheduler3) [2eb1c389] Failed to acquire lock and wait lock >>>> 'EngineLock:{exclusiveLocks='[59c10db3-0324-0320-0120-000000000339=GLUSTER]', >>>> sharedLocks=''}' >>>> 2018-05-10 11:59:31,054+02 INFO [org.ovirt.engine.core.bll.lock.InMemoryLockManager] >>>> (DefaultQuartzScheduler3) [2eb1c389] Failed to acquire lock and wait lock >>>> 'EngineLock:{exclusiveLocks='[59c10db3-0324-0320-0120-000000000339=GLUSTER]', >>>> sharedLocks=''}' >>>> 2018-05-10 11:59:31,062+02 INFO [org.ovirt.engine.core.bll.lock.InMemoryLockManager] >>>> (DefaultQuartzScheduler3) [2eb1c389] Failed to acquire lock and wait lock >>>> 'EngineLock:{exclusiveLocks='[59c10db3-0324-0320-0120-000000000339=GLUSTER]', >>>> sharedLocks=''}' >>>> 2018-05-10 11:59:31,064+02 INFO [org.ovirt.engine.core.bll.lock.InMemoryLockManager] >>>> (DefaultQuartzScheduler3) [2eb1c389] Failed to acquire lock and wait lock >>>> 'EngineLock:{exclusiveLocks='[59c10db3-0324-0320-0120-000000000339=GLUSTER]', >>>> sharedLocks=''}' >>>> 2018-05-10 11:59:31,465+02 INFO [org.ovirt.engine.core. >>>> vdsbroker.gluster.GetGlusterVolumeAdvancedDetailsVDSCommand] >>>> (DefaultQuartzScheduler4) [400fa486] FINISH, GetGlusterVolumeAdvancedDetailsVDSCommand, >>>> return: org.ovirt.engine.core.common.businessentities.gluster. >>>> GlusterVolumeAdvancedDetails@3f1b7f43, log id: 3451084f >>>> 2018-05-10 11:59:31,466+02 ERROR [org.ovirt.engine.core.bll.gluster.GlusterSyncJob] >>>> (DefaultQuartzScheduler4) [400fa486] Error while refreshing brick statuses >>>> for volume 'volume1' of cluster 'C6220': null >>>> >>>> >>>> R >>>> Tibor >>>> >>>> ----- 2018. máj.. 10., 11:43, Sahina Bose <sabose(a)redhat.com> írta: >>>> >>>> This doesn't affect the monitoring of state. >>>> Any errors in vdsm.log? >>>> Or errors in engine.log of the form "Error while refreshing brick >>>> statuses for volume" >>>> >>>> On Thu, May 10, 2018 at 2:33 PM, Demeter Tibor <tdemeter(a)itsmart.hu> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> Thank you for your fast reply :) >>>>> >>>>> >>>>> 2018-05-10 11:01:51,574+02 INFO [org.ovirt.engine.core. >>>>> vdsbroker.gluster.GlusterServersListVDSCommand] >>>>> (DefaultQuartzScheduler6) [7f01fc2d] START, GlusterServersListVDSCommand(HostName >>>>> = n2.itsmart.cloud, VdsIdVDSCommandParametersBase: >>>>> {hostId='06e361ef-3361-4eaa-9923-27fa1a0187a4'}), log id: 39adbbb8 >>>>> 2018-05-10 11:01:51,768+02 INFO [org.ovirt.engine.core. >>>>> vdsbroker.gluster.GlusterServersListVDSCommand] >>>>> (DefaultQuartzScheduler6) [7f01fc2d] FINISH, GlusterServersListVDSCommand, >>>>> return: [10.101.0.2/24:CONNECTED, n1.cloudata.local:CONNECTED, >>>>> 10.104.0.3:CONNECTED, 10.104.0.4:CONNECTED], log id: 39adbbb8 >>>>> 2018-05-10 11:01:51,788+02 INFO [org.ovirt.engine.core. >>>>> vdsbroker.gluster.GlusterVolumesListVDSCommand] >>>>> (DefaultQuartzScheduler6) [7f01fc2d] START, GlusterVolumesListVDSCommand(HostName >>>>> = n2.itsmart.cloud, GlusterVolumesListVDSParameter >>>>> s:{hostId='06e361ef-3361-4eaa-9923-27fa1a0187a4'}), log id: 738a7261 >>>>> 2018-05-10 11:01:51,892+02 WARN [org.ovirt.engine.core. >>>>> vdsbroker.gluster.GlusterVolumesListReturn] (DefaultQuartzScheduler6) >>>>> [7f01fc2d] Could not associate brick '10.104.0.1:/gluster/brick/brick1' >>>>> of volume 'e0f568fa-987c-4f5c-b853-01bce718ee27' with correct network >>>>> as no gluster network found in cluster '59c10db3-0324-0320-0120- >>>>> 000000000339' >>>>> 2018-05-10 11:01:51,898+02 WARN [org.ovirt.engine.core. >>>>> vdsbroker.gluster.GlusterVolumesListReturn] (DefaultQuartzScheduler6) >>>>> [7f01fc2d] Could not associate brick '10.104.0.1:/gluster/brick/brick2' >>>>> of volume 'e0f568fa-987c-4f5c-b853-01bce718ee27' with correct network >>>>> as no gluster network found in cluster '59c10db3-0324-0320-0120- >>>>> 000000000339' >>>>> 2018-05-10 11:01:51,905+02 WARN [org.ovirt.engine.core. >>>>> vdsbroker.gluster.GlusterVolumesListReturn] (DefaultQuartzScheduler6) >>>>> [7f01fc2d] Could not associate brick '10.104.0.1:/gluster/brick/brick3' >>>>> of volume 'e0f568fa-987c-4f5c-b853-01bce718ee27' with correct network >>>>> as no gluster network found in cluster '59c10db3-0324-0320-0120- >>>>> 000000000339' >>>>> 2018-05-10 11:01:51,911+02 WARN [org.ovirt.engine.core. >>>>> vdsbroker.gluster.GlusterVolumesListReturn] (DefaultQuartzScheduler6) >>>>> [7f01fc2d] Could not associate brick '10.104.0.1:/gluster2/brick/brick1' >>>>> of volume '68cfb061-1320-4042-abcd-9228da23c0c8' with correct network >>>>> as no gluster network found in cluster '59c10db3-0324-0320-0120- >>>>> 000000000339' >>>>> 2018-05-10 11:01:51,917+02 WARN [org.ovirt.engine.core. >>>>> vdsbroker.gluster.GlusterVolumesListReturn] (DefaultQuartzScheduler6) >>>>> [7f01fc2d] Could not associate brick '10.104.0.1:/gluster2/brick/brick2' >>>>> of volume '68cfb061-1320-4042-abcd-9228da23c0c8' with correct network >>>>> as no gluster network found in cluster '59c10db3-0324-0320-0120- >>>>> 000000000339' >>>>> 2018-05-10 11:01:51,924+02 WARN [org.ovirt.engine.core. >>>>> vdsbroker.gluster.GlusterVolumesListReturn] (DefaultQuartzScheduler6) >>>>> [7f01fc2d] Could not associate brick '10.104.0.1:/gluster2/brick/brick3' >>>>> of volume '68cfb061-1320-4042-abcd-9228da23c0c8' with correct network >>>>> as no gluster network found in cluster '59c10db3-0324-0320-0120- >>>>> 000000000339' >>>>> 2018-05-10 11:01:51,925+02 INFO [org.ovirt.engine.core. >>>>> vdsbroker.gluster.GlusterVolumesListVDSCommand] >>>>> (DefaultQuartzScheduler6) [7f01fc2d] FINISH, GlusterVolumesListVDSCommand, >>>>> return: {68cfb061-1320-4042-abcd-9228da23c0c8=org.ovirt.engine. >>>>> core.common.businessentities.gluster.GlusterVolumeEntity@7a6720d, >>>>> e0f568fa-987c-4f5c-b853-01bce718ee27=org.ovirt.engine. >>>>> core.common.businessentities.gluster.GlusterVolumeEntity@f88c521b}, >>>>> log id: 738a7261 >>>>> >>>>> >>>>> This happening continuously. >>>>> >>>>> Thanks! >>>>> Tibor >>>>> >>>>> >>>>> >>>>> ----- 2018. máj.. 10., 10:56, Sahina Bose <sabose(a)redhat.com> írta: >>>>> >>>>> Could you check the engine.log if there are errors related to getting >>>>> GlusterVolumeAdvancedDetails ? >>>>> >>>>> On Thu, May 10, 2018 at 2:02 PM, Demeter Tibor <tdemeter(a)itsmart.hu> >>>>> wrote: >>>>> >>>>>> Dear Ovirt Users, >>>>>> I've followed up the self-hosted-engine upgrade documentation, I >>>>>> upgraded my 4.1 system to 4.2.3. >>>>>> I upgaded the first node with yum upgrade, it seems working now fine. >>>>>> But since upgrade, the gluster informations seems to displayed incorrect on >>>>>> the admin panel. The volume yellow, and there are red bricks from that node. >>>>>> I've checked in console, I think my gluster is not degraded: >>>>>> >>>>>> root@n1 ~]# gluster volume list >>>>>> volume1 >>>>>> volume2 >>>>>> [root@n1 ~]# gluster volume info >>>>>> >>>>>> Volume Name: volume1 >>>>>> Type: Distributed-Replicate >>>>>> Volume ID: e0f568fa-987c-4f5c-b853-01bce718ee27 >>>>>> Status: Started >>>>>> Snapshot Count: 0 >>>>>> Number of Bricks: 3 x 3 = 9 >>>>>> Transport-type: tcp >>>>>> Bricks: >>>>>> Brick1: 10.104.0.1:/gluster/brick/brick1 >>>>>> Brick2: 10.104.0.2:/gluster/brick/brick1 >>>>>> Brick3: 10.104.0.3:/gluster/brick/brick1 >>>>>> Brick4: 10.104.0.1:/gluster/brick/brick2 >>>>>> Brick5: 10.104.0.2:/gluster/brick/brick2 >>>>>> Brick6: 10.104.0.3:/gluster/brick/brick2 >>>>>> Brick7: 10.104.0.1:/gluster/brick/brick3 >>>>>> Brick8: 10.104.0.2:/gluster/brick/brick3 >>>>>> Brick9: 10.104.0.3:/gluster/brick/brick3 >>>>>> Options Reconfigured: >>>>>> transport.address-family: inet >>>>>> performance.readdir-ahead: on >>>>>> nfs.disable: on >>>>>> storage.owner-uid: 36 >>>>>> storage.owner-gid: 36 >>>>>> performance.quick-read: off >>>>>> performance.read-ahead: off >>>>>> performance.io-cache: off >>>>>> performance.stat-prefetch: off >>>>>> performance.low-prio-threads: 32 >>>>>> network.remote-dio: enable >>>>>> cluster.eager-lock: enable >>>>>> cluster.quorum-type: auto >>>>>> cluster.server-quorum-type: server >>>>>> cluster.data-self-heal-algorithm: full >>>>>> cluster.locking-scheme: granular >>>>>> cluster.shd-max-threads: 8 >>>>>> cluster.shd-wait-qlength: 10000 >>>>>> features.shard: on >>>>>> user.cifs: off >>>>>> server.allow-insecure: on >>>>>> >>>>>> Volume Name: volume2 >>>>>> Type: Distributed-Replicate >>>>>> Volume ID: 68cfb061-1320-4042-abcd-9228da23c0c8 >>>>>> Status: Started >>>>>> Snapshot Count: 0 >>>>>> Number of Bricks: 3 x 3 = 9 >>>>>> Transport-type: tcp >>>>>> Bricks: >>>>>> Brick1: 10.104.0.1:/gluster2/brick/brick1 >>>>>> Brick2: 10.104.0.2:/gluster2/brick/brick1 >>>>>> Brick3: 10.104.0.3:/gluster2/brick/brick1 >>>>>> Brick4: 10.104.0.1:/gluster2/brick/brick2 >>>>>> Brick5: 10.104.0.2:/gluster2/brick/brick2 >>>>>> Brick6: 10.104.0.3:/gluster2/brick/brick2 >>>>>> Brick7: 10.104.0.1:/gluster2/brick/brick3 >>>>>> Brick8: 10.104.0.2:/gluster2/brick/brick3 >>>>>> Brick9: 10.104.0.3:/gluster2/brick/brick3 >>>>>> Options Reconfigured: >>>>>> nfs.disable: on >>>>>> performance.readdir-ahead: on >>>>>> transport.address-family: inet >>>>>> cluster.quorum-type: auto >>>>>> network.ping-timeout: 10 >>>>>> auth.allow: * >>>>>> performance.quick-read: off >>>>>> performance.read-ahead: off >>>>>> performance.io-cache: off >>>>>> performance.stat-prefetch: off >>>>>> performance.low-prio-threads: 32 >>>>>> network.remote-dio: enable >>>>>> cluster.eager-lock: enable >>>>>> cluster.server-quorum-type: server >>>>>> cluster.data-self-heal-algorithm: full >>>>>> cluster.locking-scheme: granular >>>>>> cluster.shd-max-threads: 8 >>>>>> cluster.shd-wait-qlength: 10000 >>>>>> features.shard: on >>>>>> user.cifs: off >>>>>> storage.owner-uid: 36 >>>>>> storage.owner-gid: 36 >>>>>> server.allow-insecure: on >>>>>> [root@n1 ~]# gluster volume status >>>>>> Status of volume: volume1 >>>>>> Gluster process TCP Port RDMA Port >>>>>> Online Pid >>>>>> ------------------------------------------------------------ >>>>>> ------------------ >>>>>> Brick 10.104.0.1:/gluster/brick/brick1 49152 0 Y >>>>>> 3464 >>>>>> Brick 10.104.0.2:/gluster/brick/brick1 49152 0 Y >>>>>> 68937 >>>>>> Brick 10.104.0.3:/gluster/brick/brick1 49161 0 Y >>>>>> 94506 >>>>>> Brick 10.104.0.1:/gluster/brick/brick2 49153 0 Y >>>>>> 3457 >>>>>> Brick 10.104.0.2:/gluster/brick/brick2 49153 0 Y >>>>>> 68943 >>>>>> Brick 10.104.0.3:/gluster/brick/brick2 49162 0 Y >>>>>> 94514 >>>>>> Brick 10.104.0.1:/gluster/brick/brick3 49154 0 Y >>>>>> 3465 >>>>>> Brick 10.104.0.2:/gluster/brick/brick3 49154 0 Y >>>>>> 68949 >>>>>> Brick 10.104.0.3:/gluster/brick/brick3 49163 0 Y >>>>>> 94520 >>>>>> Self-heal Daemon on localhost N/A N/A Y >>>>>> 54356 >>>>>> Self-heal Daemon on 10.104.0.2 N/A N/A Y >>>>>> 962 >>>>>> Self-heal Daemon on 10.104.0.3 N/A N/A Y >>>>>> 108977 >>>>>> Self-heal Daemon on 10.104.0.4 N/A N/A Y >>>>>> 61603 >>>>>> >>>>>> Task Status of Volume volume1 >>>>>> ------------------------------------------------------------ >>>>>> ------------------ >>>>>> There are no active volume tasks >>>>>> >>>>>> Status of volume: volume2 >>>>>> Gluster process TCP Port RDMA Port >>>>>> Online Pid >>>>>> ------------------------------------------------------------ >>>>>> ------------------ >>>>>> Brick 10.104.0.1:/gluster2/brick/brick1 49155 0 Y >>>>>> 3852 >>>>>> Brick 10.104.0.2:/gluster2/brick/brick1 49158 0 Y >>>>>> 68955 >>>>>> Brick 10.104.0.3:/gluster2/brick/brick1 49164 0 Y >>>>>> 94527 >>>>>> Brick 10.104.0.1:/gluster2/brick/brick2 49156 0 Y >>>>>> 3851 >>>>>> Brick 10.104.0.2:/gluster2/brick/brick2 49159 0 Y >>>>>> 68961 >>>>>> Brick 10.104.0.3:/gluster2/brick/brick2 49165 0 Y >>>>>> 94533 >>>>>> Brick 10.104.0.1:/gluster2/brick/brick3 49157 0 Y >>>>>> 3883 >>>>>> Brick 10.104.0.2:/gluster2/brick/brick3 49160 0 Y >>>>>> 68968 >>>>>> Brick 10.104.0.3:/gluster2/brick/brick3 49166 0 Y >>>>>> 94541 >>>>>> Self-heal Daemon on localhost N/A N/A Y >>>>>> 54356 >>>>>> Self-heal Daemon on 10.104.0.2 N/A N/A Y >>>>>> 962 >>>>>> Self-heal Daemon on 10.104.0.3 N/A N/A Y >>>>>> 108977 >>>>>> Self-heal Daemon on 10.104.0.4 N/A N/A Y >>>>>> 61603 >>>>>> >>>>>> Task Status of Volume volume2 >>>>>> ------------------------------------------------------------ >>>>>> ------------------ >>>>>> There are no active volume tasks >>>>>> >>>>>> I think ovirt can't read valid informations about gluster. >>>>>> I can't contiune upgrade of other hosts until this problem exist. >>>>>> >>>>>> Please help me:) >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> Regards, >>>>>> >>>>>> Tibor >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Users mailing list -- users(a)ovirt.org >>>>>> To unsubscribe send an email to users-leave(a)ovirt.org >>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> Users mailing list -- users(a)ovirt.org >>> To unsubscribe send an email to users-leave(a)ovirt.org >>> >>> >> >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org >> To unsubscribe send an email to users-leave(a)ovirt.org >> >> >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org >> To unsubscribe send an email to users-leave(a)ovirt.org >> oVirt Code of Conduct: https://www.ovirt.org/community/about/community- >> guidelines/ >> List Archives: >> >> >

6 years, 11 months

4
16
0 / 0

Does ovirt engine itself support high scalability (such as Load Balancing)?

by simiam

Hi, Does ovirt engine itself support high scalability (such as Load Balancing)? It means that i can add one or many engine servers to balance the load easily. Thanks.

6 years, 11 months

1
1
0 / 0

start vm without engine

by David David

hi. How to start VM directly in hypervisor? ovirt-engine was crashed. VM's id is known. vdsclient VM, hasn't argumets for starting vm. Thanks.

6 years, 11 months

3
2
0 / 0

Updated ovirt-engine packages were released for oVirt 4.2

by Lev Veyde

Hi, We have added an updated oVirt engine (4.2.3.8) to the oVirt 4.2 stable yum repo. It fixes BZ#1582483 [1]. [1] https://bugzilla.redhat.com/1582483 Thanks in advance, -- Lev Veyde Software Engineer, RHCE | RHCVA | MCITP Red Hat Israel <https://www.redhat.com> lev(a)redhat.com | lveyde(a)redhat.com <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

6 years, 11 months

1
0
0 / 0

Ovirt 4.2.4 - Trouble installing additional self hosted engine hosts

by Maton, Brett

Adding regular, non SHE hosts works fine, however I can't seem to add Self Hosted Engine to additional physical hosts. I think this is the problem, but I don't know what the solution is: 2018-05-29 08:00:52,502+0100 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Misc configuration': Cannot resolve ovirt_hosted_engine_ha module Deploy log attached.

6 years, 11 months

3
4
0 / 0

CVE-2018-3639 - Important - oVirt - Speculative Store Bypass

by Sandro Bonazzola

As you may have already heard, an industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of Load & Store instructions. This issue is well described by CVE-2018-3639 announce available at https://access.redhat.com/security/cve/cve-2018-3639. oVirt team has released right now an update of ovirt-engine to version 4.2.3.7 which add support for SSBD CPUs in order to mitigate the security issue. If you are running oVirt on Red Hat Enterprise Linux, please apply updates described in https://access.redhat.com/security/cve/cve-2018-3639. If you are running oVirt on CentOS Linux please apply updated described by: CESA-2018:1629 Important CentOS 7 kernel Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022843.html> CESA-2018:1632 Important CentOS 7 libvirt Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022840.html> CESA-2018:1649 Important CentOS 7 java-1.8.0-openjdk Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022839.html> CESA-2018:1648 Important CentOS 7 java-1.7.0-openjdk Security Update <https://lists.centos.org/pipermail/centos-announce/2018-May/022838.html> An update for qemu-kvm-ev has been also tagged for release and announced with CESA-2018:1655 Important: qemu-kvm-ev security update <https://lists.centos.org/pipermail/centos-virt/2018-May/005804.html> but due to some issues in CentOS release process for Virt SIG content, it is not yet available on mirrors. We are working with CentOS community to get the packages signed and published as soon as possible. In the meanwhile you can still get the update package by enabling the test repository https://buildlogs.centos.org/centos/7/virt/x86_64/kvm-common/ on your systems or manually installing the package from the repository. If you're running oVirt on a different Linux distribution, please check with your vendor for available updates. Please note that to fully mitigate this vulnerability, system administrators must apply both hardware “microcode” updates and software patches that enable new functionality. At this time, microprocessor microcode will be delivered by the individual manufacturers. The oVirt team recommends end users and systems administrator to apply any available updates as soon as practical. Thanks, -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

6 years, 11 months

6
10
0 / 0

SSH into guest VM

by 03ce007＠gmail.com

I have self-hosted-engine (4.2) deployed successfully on cento (7.4) server. The physical server has 'ovirt' as hostname and the self-hosted engineVM deployed and running on it has 'engine.ovirt' as fdqn. I can successfully create new VM using the oVirt.vm-infra example playbook. But what other config/var i need to add in them so that I can ssh into this new VM. Some example, tips, hints would be helpful. Thank you.

6 years, 11 months

3
4
0 / 0

cache and viodiskcache parameters in documentation

by stefanos＠prismatelecomtesting.com

Hi, on chapter 6.13.1 "Live Migration Prerequisites" [1] of the RHV 4.2 Virtual Machine Management Guide, there is written: ____________ At a minimum, for successful live migration of virtual machines to be possible: [...] The migrating virtual machine must not have the cache!=none custom property set. ____________ However I can't find any custom property called "cache" under Edit Virtual Machine --> Custom Properties but only "viodiskcache". As a matter of fact, Appendix A of the same guide [2] reports the following statement: "If viodiskcache is enabled, the virtual machine cannot be live migrated" that suggest viodiskcache as the correct parameter. Are the two statements contradictory? Thank you. Stefano Stagnaro [1] https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/... [2] https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/...

6 years, 11 months

2
2
0 / 0

Bad volume specification

by Bryan Sockel

Hi, I am having to rebuild my ovirt instance for a couple of reasons. I have setup a temporary ovirt portal to migrate my setup to while i rebuild my production portal. I have run int a couple of VM's that will no longer start. Everything that i am seeing is identical to this article - https://access.redhat.com/solutions/2423391 VM devel-build is down with error. Exit message: Bad volume specification {'serial': 'ec7a3258-7a99-4813-aa7d-dceb727a1975', 'index': 0, 'iface': 'virtio', 'apparentsize': '1835008', 'specParams': {}, 'cache': 'none', 'imageID': 'ec7a3258-7a99-4813-aa7d-dceb727a1975', 'truesize': '1777664', 'type': 'disk', 'domainID': '2b79768f-a329-4eab-81e0-120a81ac8906', 'reqsize': '0', 'format': 'cow', 'poolID': '9e7d643c-592d-11e8-82eb-005056b41d15', 'device': 'disk', 'path': '/rhev/data-center/9e7d643c-592d-11e8-82eb-005056b41d15/2b79768f-a329-4eab-81e0-120a81ac8906/images/ec7a3258-7a99-4813-aa7d-dceb727a1975/8f4ddee4-68b3-48e9-be27-0231557f5218', 'propagateErrors': 'off', 'name': 'vda', 'bootOrder': '1', 'volumeID': '8f4ddee4-68b3-48e9-be27-0231557f5218', 'diskType': 'file', 'alias': 'ua-ec7a3258-7a99-4813-aa7d-dceb727a1975', 'discard': False}. Currently running version 4.2.3.5-1 Is there anyway to recover the image, or even just be able to mount the drive to another vm to extract data. Thank You

6 years, 11 months

2
2
0 / 0

second deploy hosted engine, engine VM is shut dwon

by dhy336＠sina.com

HiI first deploy hosted engine is failed， then deploy hosted engine, after ansible run "name: Add host ovirt_hosts:"(bootstrap_local_vm.yml), engine VM is shut dwon, why to shutown engine VM?

6 years, 11 months

1
0
0 / 0

Reference architecture for oVirt Gluster HCI

by Karli Sjöberg

6 years, 11 months

1
0
0 / 0

ovirt guest agent epel 6 and rhevm in the name

by Gianluca Cecchi

Hello, I have updated one test environment to 4.2 (it was in 4.1.9) I have a guest in Oracle Linux 6 and epel 6 repo enabled. After powering down and start the VM, I saw the exclamation mark regarding ovirt-guest-agent latest version needed. On the VM the process was dead and I took the time of updatng it from ovirt-guest-agent-1.0.12-4.el6.noarch to ovirt-guest-agent-1.0.13-2.el6.noarch and start the agent. All seems ok; no exclamation mark now and I see the ip addresses of the guest in 4.2 web admin gui. But in log of ovirt-guest-agent I see: MainThread::ERROR::2018-05-28 14:34:55,711::ovirt-guest-agent::140::root::Unhandled exception in oVirt guest agent! Traceback (most recent call last): File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 134, in <module> agent.run(daemon, pidfile) File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 65, in run self.agent = LinuxVdsAgent(config) File "/usr/share/ovirt-guest-agent/GuestAgentLinux2.py", line 466, in __init__ AgentLogicBase.__init__(self, config) File "/usr/share/ovirt-guest-agent/OVirtAgentLogic.py", line 188, in __init__ self.vio = VirtIoChannel(config.get("virtio", "device")) File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 151, in __init__ self._stream = VirtIoStream(vport_name) File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 132, 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' MainThread::INFO::2018-05-28 14:42:45,535::ovirt-guest-agent::59::root::Starting oVirt guest agent The status of files under the indicated directory is: # ll /dev/virtio-ports/ total 0 lrwxrwxrwx 1 root root 11 May 28 14:34 com.redhat.spice.0 -> ../vport0p3 lrwxrwxrwx 1 root root 11 May 28 14:34 org.qemu.guest_agent.0 -> ../vport0p2 lrwxrwxrwx 1 root root 11 May 28 14:42 ovirt-guest-agent.0 -> ../vport0p1 # Anything to be done at my side at guest/host configuration level? Thanks, Gianluca

6 years, 11 months

1
1
0 / 0

Does ovirt engine itself support high scalability

by simiam

Does ovirt engine itself support high scalability?

6 years, 11 months

1
0
0 / 0

CentOS7 Install Failure to Shutdown

by Matthew Wimpelberg

I have ovirt 4.2.3.5-1.el7.centos installed and am unable to cleanly reboot the host machine. The only way I can reboot is to press and hold the power button which causes an unclean shutdown of the engine vm. I can upload logs if necessary I'm just not sure where to upload them to.

6 years, 11 months

2
1
0 / 0

Fwd: External ceph storage

by Leo David

---------- Forwarded message --------- From: Leo David <leoalex(a)gmail.com> Date: Sun, May 27, 2018, 20:01 Subject: Re: [ovirt-users] External ceph storage To: Luca 'remix_tj' Lorenzetto <lorenzetto.luca(a)gmail.com> Indeed, you right. Will setup the gws while waiting for a maybe future native ceph connection, which in my oppinion would bring a lot of power to oVirt. On Sun, May 27, 2018, 19:48 Luca 'remix_tj' Lorenzetto < lorenzetto.luca(a)gmail.com> wrote: > I think is the best option. Setting up a sma openstack setup only for it > is not worth the hassle. > > Luca > > Il dom 27 mag 2018, 18:44 Leo David <leoalex(a)gmail.com> ha scritto: > >> Ok, so since i dont have openstack installed (which would put cinder >> between ceph and ovirt ), the only option remains the iscsi gw... >> Thank you very much ! >> >> On Sun, May 27, 2018, 18:14 Luca 'remix_tj' Lorenzetto < >> lorenzetto.luca(a)gmail.com> wrote: >> >>> No, >>> >>> The only way you have is to configure cinder to manage ceph pool or in >>> alternative you have to deploy an iscsi gateway, no other ways are >>> available at the moment. >>> >>> So you can't use rbd directly. >>> >>> Luca >>> >>> Il dom 27 mag 2018, 16:54 Leo David <leoalex(a)gmail.com> ha scritto: >>> >>>> Thank you Luca, >>>> At the moment i would try the cinder storage provider, since we already >>>> have a proxmox cluster directly connecting to ceph. The problem is that I >>>> just could not find a straight way to do this. >>>> ie: Specify the ceph monitors and ceph pool to connect to. Can oVirt >>>> directly connect to ceph monitors ? How the configuration should be done if >>>> so ? >>>> Thank you very much ! >>>> >>>> >>>> On Sun, May 27, 2018, 17:20 Luca 'remix_tj' Lorenzetto < >>>> lorenzetto.luca(a)gmail.com> wrote: >>>> >>>>> Hello, >>>>> >>>>> Yes, using cinder or through iscsi gateway. >>>>> >>>>> For a simpler setup i suggest the second option. >>>>> >>>>> Luca >>>>> >>>>> Il dom 27 mag 2018, 16:08 Leo David <leoalex(a)gmail.com> ha scritto: >>>>> >>>>>> Hello everyone, >>>>>> I am new to ovirt and very impressed of its features. I would like to >>>>>> levereage on our existing ceph cluster to provide rbd images for vm hdds, >>>>>> is this possible to achieve ? >>>>>> Thank you very much ! >>>>>> Regards, >>>>>> Leo >>>>>> _______________________________________________ >>>>>> Users mailing list -- users(a)ovirt.org >>>>>> To unsubscribe send an email to users-leave(a)ovirt.org >>>>>> >>>>>

6 years, 11 months

1
0
0 / 0

Failed to complete VM name creation fills the log every minute

by acavasiljevic＠gmail.com

Hi, Could you please help. Every 30 seconds I get an error "Failed to complete VM name creation" The task was started but stopped after a while. I have killed all tasks : $ su - postgres $ psql -d engine -U postgres > select * from job order by start_time desc; > select DeleteJob('702e9f6a-e2a3-4113-bd7d-3757ba6bc4ef'); I run: oVirt Engine Version: 4.1.9.1-1.el7.centos Thank you very much. Best regards,

6 years, 11 months

1
0
0 / 0

Re: External ceph storage

by Luca 'remix_tj' Lorenzetto

Remember always to reply to the list, youur feedback will return back to the devs! Il dom 27 mag 2018, 19:01 Leo David <leoalex(a)gmail.com> ha scritto: > Indeed, you right. Will setup the gws while waiting for a maybe future > native ceph connection, which in my oppinion would bring a lot of power to > oVirt. > > On Sun, May 27, 2018, 19:48 Luca 'remix_tj' Lorenzetto < > lorenzetto.luca(a)gmail.com> wrote: > >> I think is the best option. Setting up a sma openstack setup only for it >> is not worth the hassle. >> >> Luca >> >> Il dom 27 mag 2018, 18:44 Leo David <leoalex(a)gmail.com> ha scritto: >> >>> Ok, so since i dont have openstack installed (which would put cinder >>> between ceph and ovirt ), the only option remains the iscsi gw... >>> Thank you very much ! >>> >>> On Sun, May 27, 2018, 18:14 Luca 'remix_tj' Lorenzetto < >>> lorenzetto.luca(a)gmail.com> wrote: >>> >>>> No, >>>> >>>> The only way you have is to configure cinder to manage ceph pool or in >>>> alternative you have to deploy an iscsi gateway, no other ways are >>>> available at the moment. >>>> >>>> So you can't use rbd directly. >>>> >>>> Luca >>>> >>>> Il dom 27 mag 2018, 16:54 Leo David <leoalex(a)gmail.com> ha scritto: >>>> >>>>> Thank you Luca, >>>>> At the moment i would try the cinder storage provider, since we >>>>> already have a proxmox cluster directly connecting to ceph. The problem is >>>>> that I just could not find a straight way to do this. >>>>> ie: Specify the ceph monitors and ceph pool to connect to. Can oVirt >>>>> directly connect to ceph monitors ? How the configuration should be done if >>>>> so ? >>>>> Thank you very much ! >>>>> >>>>> >>>>> On Sun, May 27, 2018, 17:20 Luca 'remix_tj' Lorenzetto < >>>>> lorenzetto.luca(a)gmail.com> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Yes, using cinder or through iscsi gateway. >>>>>> >>>>>> For a simpler setup i suggest the second option. >>>>>> >>>>>> Luca >>>>>> >>>>>> Il dom 27 mag 2018, 16:08 Leo David <leoalex(a)gmail.com> ha scritto: >>>>>> >>>>>>> Hello everyone, >>>>>>> I am new to ovirt and very impressed of its features. I would like >>>>>>> to levereage on our existing ceph cluster to provide rbd images for vm >>>>>>> hdds, is this possible to achieve ? >>>>>>> Thank you very much ! >>>>>>> Regards, >>>>>>> Leo >>>>>>> _______________________________________________ >>>>>>> Users mailing list -- users(a)ovirt.org >>>>>>> To unsubscribe send an email to users-leave(a)ovirt.org >>>>>>> >>>>>>

6 years, 11 months

1
0
0 / 0

Re: External ceph storage

by Luca 'remix_tj' Lorenzetto

I think is the best option. Setting up a sma openstack setup only for it is not worth the hassle. Luca Il dom 27 mag 2018, 18:44 Leo David <leoalex(a)gmail.com> ha scritto: > Ok, so since i dont have openstack installed (which would put cinder > between ceph and ovirt ), the only option remains the iscsi gw... > Thank you very much ! > > On Sun, May 27, 2018, 18:14 Luca 'remix_tj' Lorenzetto < > lorenzetto.luca(a)gmail.com> wrote: > >> No, >> >> The only way you have is to configure cinder to manage ceph pool or in >> alternative you have to deploy an iscsi gateway, no other ways are >> available at the moment. >> >> So you can't use rbd directly. >> >> Luca >> >> Il dom 27 mag 2018, 16:54 Leo David <leoalex(a)gmail.com> ha scritto: >> >>> Thank you Luca, >>> At the moment i would try the cinder storage provider, since we already >>> have a proxmox cluster directly connecting to ceph. The problem is that I >>> just could not find a straight way to do this. >>> ie: Specify the ceph monitors and ceph pool to connect to. Can oVirt >>> directly connect to ceph monitors ? How the configuration should be done if >>> so ? >>> Thank you very much ! >>> >>> >>> On Sun, May 27, 2018, 17:20 Luca 'remix_tj' Lorenzetto < >>> lorenzetto.luca(a)gmail.com> wrote: >>> >>>> Hello, >>>> >>>> Yes, using cinder or through iscsi gateway. >>>> >>>> For a simpler setup i suggest the second option. >>>> >>>> Luca >>>> >>>> Il dom 27 mag 2018, 16:08 Leo David <leoalex(a)gmail.com> ha scritto: >>>> >>>>> Hello everyone, >>>>> I am new to ovirt and very impressed of its features. I would like to >>>>> levereage on our existing ceph cluster to provide rbd images for vm hdds, >>>>> is this possible to achieve ? >>>>> Thank you very much ! >>>>> Regards, >>>>> Leo >>>>> _______________________________________________ >>>>> Users mailing list -- users(a)ovirt.org >>>>> To unsubscribe send an email to users-leave(a)ovirt.org >>>>> >>>>

6 years, 11 months

1
0
0 / 0

Re: Failing to install self hosted engine - 4.2.4

by Simone Tiraboschi

On Sun, May 27, 2018 at 11:32 AM, Maton, Brett <matonb(a)ltresources.co.uk> wrote: > Thanks Simone, > > I think the problem is that /tmp is mounted noexec by default on my > servers. > Remounting and enabling exec seems to fix the problem. > > I think that allowing users to specify a working temp space would be > better than assuming that /tmp is mounted exec and also in my case big > enough to store the hosted engine vm (which the installer doesn't check, it > just fails late in the install process). > > If you execute hosted-engine-setup from CLI it will honor TMPDIR env variable (with /var/tmp as default) but I don't think your issue is there indeed your bootstrap engine VM was running. Your issue was related to the execution of host-deploy code: host-deploy is the code used to configure the host to be used as an hypervisor, the engine copies it over ssh to the host under /tmp and executes it there so your issue with noexec on /tmp. I'm not aware of any way to customize host-deploy location. > Regards, > Brett > > On 26 May 2018 at 21:25, Simone Tiraboschi <stirabos(a)redhat.com> wrote: > >> >> >> On Sat, May 26, 2018 at 11:10 AM, Maton, Brett <matonb(a)ltresources.co.uk> >> wrote: >> >>> Hi, >>> >>> I can't see in the log what the problem is, I expect it's something >>> simple though... >>> Hoping that someone can see what the problem is. >>> >>> engine setup log attached. >>> >> >> 2018-05-26 09:56:09,676+0100 ERROR otopi.ovirt_hosted_engine_setup.ansible_utils >> ansible_utils._process_output:98 fatal: [localhost]: FAILED! => >> {"ansible_facts": {"ovirt_hosts": [{"address": "node1.example.com", >> "affinity_labels": [], "auto_numa_status": "unknown", "certificate": >> {"organization": "testlab.lan", "subject": "O=testlab.lan,CN=node1.exampl >> e.com"}, "cluster": {"href": "/ovirt-engine/api/clusters/dd >> a509fe-60c0-11e8-ac4e-00163e2285d7", "id": "dda509fe-60c0-11e8-ac4e-00163e2285d7"}, >> "comment": "", "cpu": {"speed": 0.0, "topology": {}}, "device_passthrough": >> {"enabled": false}, "devices": [], "external_network_provider_configurations": >> [], "external_status": "ok", "hardware_information": >> {"supported_rng_sources": []}, "hooks": [], "href": >> "/ovirt-engine/api/hosts/b0976daa-e4b5-4881-a59b-49f9eb51f7c5", "id": >> "b0976daa-e4b5-4881-a59b-49f9eb51f7c5", "katello_errata": [], >> "kdump_status": "unknown", "ksm": {"enabled": false}, >> "max_scheduling_memory": 0, "memory": 0, "name": "node1.example.com", >> "network_attachments": [], "nics": [], "numa_nodes": [], "numa_supported": >> false, "os": {"custom_kernel_cmdline": ""}, "permissions": [], "port": >> 54321, "power_management": {"automatic_pm_enabled": true, "enabled": false, >> "kdump_detection": true, "pm_proxies": []}, "protocol": "stomp", >> "se_linux": {}, "spm": {"priority": 5, "status": "none"}, "ssh": >> {"fingerprint": "SHA256:xh1kvHMx+qp3q2L4lxf4fwra9lCAVxlfAGiVBVa7I7M", >> "port": 22}, "statistics": [], "status": "install_failed", >> "storage_connection_extensions": [], "summary": {"total": 0}, "tags": >> [], "transparent_huge_pages": {"enabled": false}, "type": "rhel", >> "unmanaged_networks": [], "update_available": false}]}, "attempts": 120, >> "changed": false} >> >> The engine failed to deploy your host and indeed we see "status": >> "install_failed" >> but to understand why it failed you have to consult host-deploy logs. >> You can find them under /var/log/ovirt-engine/host-deploy on the engine >> VM or also on your host in a directory inside hosted-engine-setup logs dir >> if hosted-engine-setup correctly managed to fetch them from the engine VM. >> >> >> >>> >>> Regards, >>> Brett >>> >>> _______________________________________________ >>> Users mailing list -- users(a)ovirt.org >>> To unsubscribe send an email to users-leave(a)ovirt.org >>> >>> >> >

6 years, 11 months

1
0
0 / 0

External ceph storage

by Leo David

Hello everyone, I am new to ovirt and very impressed of its features. I would like to levereage on our existing ceph cluster to provide rbd images for vm hdds, is this possible to achieve ? Thank you very much ! Regards, Leo

6 years, 11 months

2
1
0 / 0

Re: hosted engine setup error

by dhy336＠sina.com

hi Yanirthis is my vdsm.log vdsm run prepareForShutdown lead to engine VM shudown? why shutdown engine VM,when deploy hosted engine? thanks 2018-05-27 18:24:16,020+0800 INFO (MainThread) [vds] Received signal 15, shutting down (vdsmd:67)2018-05-27 18:24:21,028+0800 INFO (MainThread) [jsonrpc.JsonRpcServer] Stopping JsonRPC Server (__init__:703)2018-05-27 18:24:21,030+0800 INFO (MainThread) [vds] Stopping http server (http:79)2018-05-27 18:24:21,030+0800 INFO (http) [vds] Server stopped (http:69)2018-05-27 18:24:21,031+0800 INFO (MainThread) [root] Unregistering all secrets (secret:91)2018-05-27 18:24:21,031+0800 INFO (MainThread) [vds] Stopping QEMU-GA poller (qemuguestagent:116)2018-05-27 18:24:21,032+0800 INFO (MainThread) [vdsm.api] START prepareForShutdown(options=None) from=internal, task_id=d3137135-e4f8-44ef-ac4c-d1687606fb02 (api:46)2018-05-27 18:24:21,094+0800 INFO (MainThread) [storage.Monitor] Shutting down domain monitors (monitor:222)2018-05-27 18:24:21,094+0800 INFO (MainThread) [storage.check] Stopping check service (check:104)2018-05-27 18:24:21,094+0800 INFO (check/loop) [storage.asyncevent] Stopping <EventLoop running=True closed=False at 0x43126736> (asyncevent:220) ----- Original Message ----- From: <dhy336(a)sina.com> To: "Yanir Quinn" <yquinn(a)redhat.com> Cc: users <users(a)ovirt.org> Subject: [ovirt-users] Re: hosted engine setup error Date: 2018-05-27 18:51 thanks, I find when hosted-engine -deloy run [Get ovirtmgmt route table id], my engine VM is shutdown,and /var/log/message show my engine vm is powered down by guest-shutdown,[ INFO ] TASK [Get ovirtmgmt route table id][ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 50, "changed": true, "cmd": "ip rule list | grep ovirtmgmt | sed s/\\\\[.*\\\\]\\ //g | awk '{ print $9 }'", "delta": "0:00:00.004175", "end": "2018-05-26 17:41:11.892218", "rc": 0, "start": "2018-05-26 17:41:11.888043", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}[ ERROR ] Failed to execute stage 'Closing up': Failed executing ansible-playbook[ INFO ] Stage: Clean up[ INFO ] Cleaning temporary resources[ INFO ] TASK [Gathering Facts][ INFO ] ok: [localhost][ INFO ] TASK [Remove local vm dir] /var/log/message May 26 09:32:23 engine systemd: Reloading.May 26 09:32:24 engine python: ansible-file Invoked with directory_mode=None force=False remote_src=None path=/root/heanswers.conf owner=None follow=False group=None unsafe_writes=None state=absent content=NOT_LOGGING_PARAMETER serole=None diff_peek=None setype=None selevel=None original_basename=None regexp=None validate=None src=None seuser=None recurse=False delimiter=None mode=None attributes=None backup=NoneMay 26 09:32:38 engine systemd-logind: Removed session 3.May 26 09:32:48 engine qemu-ga: info: guest-shutdown called, mode: powerdownMay 26 09:32:48 engine systemd: Started Delayed Shutdown Service.May 26 09:32:48 engine systemd: Starting Delayed Shutdown Service...May 26 09:32:48 engine systemd-shutdownd: Shutting down at Sat 2018-05-26 17:32:48 CST (poweroff)...May 26 09:32:48 engine systemd-shutdownd: Creating /run/nologin, blocking further logins...May 26 09:32:48 engine systemd: Stopping QEMU Guest Agent...May 26 09:32:48 engine systemd: Stopping Session 1 of user root.May 26 09:32:48 engine systemd: Stopped target Multi-User System.May 26 09:32:48 engine systemd: Stopping Multi-User System.May 26 09:32:48 engine systemd: Stopped Execute cloud user/final scripts.May 26 09:32:48 engine systemd: Stopping Execute cloud user/final scripts...May 26 09:32:48 engine systemd: Stopping oVirt Engine...May 26 09:32:48 engine sshd[24523]: Received signal 15; terminating.May 26 09:32:48 engine systemd: Stopping OpenSSH server daemon...May 26 09:32:48 engine systemd: Stopping The Apache HTTP Server...----- Original Message ----- From: Yanir Quinn <yquinn(a)redhat.com> To: dhy336(a)sina.com Cc: users <users(a)ovirt.org> Subject: Re: Re: [ovirt-users] hosted engine setup error Date: 2018-05-27 16:46 According to BZ : https://bugzilla.redhat.com/show_bug.cgi?id=1540451#c19you should retry with a newer kernel >= -851 if possible .If you still get the error please provide full setup and vdsm logs. On Fri, May 25, 2018 at 11:54 AM, <dhy336(a)sina.com> wrote: Hi thanks for your reponse, I try to do by your guide, but it is not work. my kernel version is 3.10.0-693.11.1.el7.x86_64.besides, I try to do hosted-engine --deploy in my Virtual machine is work. but it is not work in Physical Machine ----- Original Message ----- From: Yanir Quinn <yquinn(a)redhat.com> To: dhy336(a)sina.com Cc: users <users(a)ovirt.org> Subject: Re: [ovirt-users] hosted engine setup error Date: 2018-05-24 18:35 Hi There is a BZ with a similar issue: https://bugzilla.redhat.com/show_bug.cgi?id=1546839 To sum things up, try stopping the network manager and restarting your network if you are using a RH distribution, e,g. : systemctl stop NetworkManager systemctl restart networkAnd check what is your kernel version. On Wed, May 23, 2018 at 5:03 PM, <dhy336(a)sina.com> wrote: hiI deploy ovirt-engine-4.2.2 hosted-engine by #hosted-engine --deploy, but face some error bridge ovirtmgmt is not configure, i should how to do? thanks [ INFO ] TASK [Get ovirtmgmt route table id][ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 50, "changed": true, "cmd": "ip rule list | grep ovirtmgmt | sed s/\\\\[.*\\\\]\\ //g | awk '{ print $9 }'", "delta": "0:00:00.010899", "end": "2018-05-23 20:03:21.222559", "rc": 0, "start": "2018-05-23 20:03:21.211660", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}[ ERROR ] Failed to execute stage 'Closing up': Failed executing ansible-playbook[ INFO ] Stage: Clean up[ INFO ] Cleaning temporary resources vdsm.log 2018-05-23 19:55:15,305+0800 INFO (vm/bfc6f7cf) [virt.vm] (vmId='bfc6f7cf-3e8d-4368-97f8-78a5c74a5175') VM wrapper has started (vm:2619)2018-05-23 19:55:15,454+0800 INFO (vm/bfc6f7cf) [virt.vm] (vmId='bfc6f7cf-3e8d-4368-97f8-78a5c74a5175') Starting connection (guestagent:245)2018-05-23 19:55:15,458+0800 ERROR (vm/bfc6f7cf) [virt.vm] (vmId='bfc6f7cf-3e8d-4368-97f8-78a5c74a5175') Failed to connect to guest agent channel (vm:2403)Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2401, in _vmDependentInit self.guestAgent.start() File "/usr/lib/python2.7/site-packages/vdsm/virt/guestagent.py", line 246, in start self._prepare_socket() File "/usr/lib/python2.7/site-packages/vdsm/virt/guestagent.py", line 288, in _prepare_socket supervdsm.getProxy().prepareVmChannel(self._socketName) File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 55, in __call__ return callMethod() File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 53, in <lambda> **kwargs) File "<string>", line 2, in prepareVmChannel File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _callmethod raise convert_to_error(kind, result)OSError: [Errno 2] No such file or directory: '/var/lib/libvirt/qemu/channels/bfc6f7cf-3e8d-4368-97f8-78a5c74a5175.com.redhat.rhevm.vdsm'2018-05-23 19:55:15,480+0800 INFO (vm/bfc6f7cf) [virt.vm] (vmId='bfc6f7cf-3e8d-4368-97f8-78a5c74a5175') CPU running: domain initialization (vm:5908) [root@hosted-engine-test1 ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:6c:ee:a8 brd ff:ff:ff:ff:ff:ff inet 192.168.122.217/24 brd 192.168.122.255 scope global dynamic eth0 valid_lft 2936sec preferred_lft 2936sec inet6 fe80::834a:9cc1:df2:83f/64 scope link valid_lft forever preferred_lft forever18: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 9a:d1:bc:96:cc:c0 brd ff:ff:ff:ff:ff:ff19: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000 link/ether 52:54:00:55:06:26 brd ff:ff:ff:ff:ff:ff inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr0 valid_lft forever preferred_lft forever20: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 1000 link/ether 52:54:00:55:06:26 brd ff:ff:ff:ff:ff:ff _______________________________________________ Users mailing list -- users(a)ovirt.org To unsubscribe send an email to users-leave(a)ovirt.org _______________________________________________ Users mailing list -- users(a)ovirt.org To unsubscribe send an email to users-leave(a)ovirt.org

6 years, 11 months

1
0
0 / 0

Re: hosted engine setup error

by dhy336＠sina.com

thanks, I find when hosted-engine -deloy run [Get ovirtmgmt route table id], my engine VM is shutdown,and /var/log/message show my engine vm is powered down by guest-shutdown,[ INFO ] TASK [Get ovirtmgmt route table id][ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 50, "changed": true, "cmd": "ip rule list | grep ovirtmgmt | sed s/\\\\[.*\\\\]\\ //g | awk '{ print $9 }'", "delta": "0:00:00.004175", "end": "2018-05-26 17:41:11.892218", "rc": 0, "start": "2018-05-26 17:41:11.888043", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}[ ERROR ] Failed to execute stage 'Closing up': Failed executing ansible-playbook[ INFO ] Stage: Clean up[ INFO ] Cleaning temporary resources[ INFO ] TASK [Gathering Facts][ INFO ] ok: [localhost][ INFO ] TASK [Remove local vm dir] /var/log/message May 26 09:32:23 engine systemd: Reloading.May 26 09:32:24 engine python: ansible-file Invoked with directory_mode=None force=False remote_src=None path=/root/heanswers.conf owner=None follow=False group=None unsafe_writes=None state=absent content=NOT_LOGGING_PARAMETER serole=None diff_peek=None setype=None selevel=None original_basename=None regexp=None validate=None src=None seuser=None recurse=False delimiter=None mode=None attributes=None backup=NoneMay 26 09:32:38 engine systemd-logind: Removed session 3.May 26 09:32:48 engine qemu-ga: info: guest-shutdown called, mode: powerdownMay 26 09:32:48 engine systemd: Started Delayed Shutdown Service.May 26 09:32:48 engine systemd: Starting Delayed Shutdown Service...May 26 09:32:48 engine systemd-shutdownd: Shutting down at Sat 2018-05-26 17:32:48 CST (poweroff)...May 26 09:32:48 engine systemd-shutdownd: Creating /run/nologin, blocking further logins...May 26 09:32:48 engine systemd: Stopping QEMU Guest Agent...May 26 09:32:48 engine systemd: Stopping Session 1 of user root.May 26 09:32:48 engine systemd: Stopped target Multi-User System.May 26 09:32:48 engine systemd: Stopping Multi-User System.May 26 09:32:48 engine systemd: Stopped Execute cloud user/final scripts.May 26 09:32:48 engine systemd: Stopping Execute cloud user/final scripts...May 26 09:32:48 engine systemd: Stopping oVirt Engine...May 26 09:32:48 engine sshd[24523]: Received signal 15; terminating.May 26 09:32:48 engine systemd: Stopping OpenSSH server daemon...May 26 09:32:48 engine systemd: Stopping The Apache HTTP Server...----- Original Message ----- From: Yanir Quinn <yquinn(a)redhat.com> To: dhy336(a)sina.com Cc: users <users(a)ovirt.org> Subject: Re: Re: [ovirt-users] hosted engine setup error Date: 2018-05-27 16:46 According to BZ : https://bugzilla.redhat.com/show_bug.cgi?id=1540451#c19you should retry with a newer kernel >= -851 if possible .If you still get the error please provide full setup and vdsm logs. On Fri, May 25, 2018 at 11:54 AM, <dhy336(a)sina.com> wrote: Hi thanks for your reponse, I try to do by your guide, but it is not work. my kernel version is 3.10.0-693.11.1.el7.x86_64.besides, I try to do hosted-engine --deploy in my Virtual machine is work. but it is not work in Physical Machine ----- Original Message ----- From: Yanir Quinn <yquinn(a)redhat.com> To: dhy336(a)sina.com Cc: users <users(a)ovirt.org> Subject: Re: [ovirt-users] hosted engine setup error Date: 2018-05-24 18:35 Hi There is a BZ with a similar issue: https://bugzilla.redhat.com/show_bug.cgi?id=1546839 To sum things up, try stopping the network manager and restarting your network if you are using a RH distribution, e,g. : systemctl stop NetworkManager systemctl restart networkAnd check what is your kernel version. On Wed, May 23, 2018 at 5:03 PM, <dhy336(a)sina.com> wrote: hiI deploy ovirt-engine-4.2.2 hosted-engine by #hosted-engine --deploy, but face some error bridge ovirtmgmt is not configure, i should how to do? thanks [ INFO ] TASK [Get ovirtmgmt route table id][ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 50, "changed": true, "cmd": "ip rule list | grep ovirtmgmt | sed s/\\\\[.*\\\\]\\ //g | awk '{ print $9 }'", "delta": "0:00:00.010899", "end": "2018-05-23 20:03:21.222559", "rc": 0, "start": "2018-05-23 20:03:21.211660", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}[ ERROR ] Failed to execute stage 'Closing up': Failed executing ansible-playbook[ INFO ] Stage: Clean up[ INFO ] Cleaning temporary resources vdsm.log 2018-05-23 19:55:15,305+0800 INFO (vm/bfc6f7cf) [virt.vm] (vmId='bfc6f7cf-3e8d-4368-97f8-78a5c74a5175') VM wrapper has started (vm:2619)2018-05-23 19:55:15,454+0800 INFO (vm/bfc6f7cf) [virt.vm] (vmId='bfc6f7cf-3e8d-4368-97f8-78a5c74a5175') Starting connection (guestagent:245)2018-05-23 19:55:15,458+0800 ERROR (vm/bfc6f7cf) [virt.vm] (vmId='bfc6f7cf-3e8d-4368-97f8-78a5c74a5175') Failed to connect to guest agent channel (vm:2403)Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2401, in _vmDependentInit self.guestAgent.start() File "/usr/lib/python2.7/site-packages/vdsm/virt/guestagent.py", line 246, in start self._prepare_socket() File "/usr/lib/python2.7/site-packages/vdsm/virt/guestagent.py", line 288, in _prepare_socket supervdsm.getProxy().prepareVmChannel(self._socketName) File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 55, in __call__ return callMethod() File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 53, in <lambda> **kwargs) File "<string>", line 2, in prepareVmChannel File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _callmethod raise convert_to_error(kind, result)OSError: [Errno 2] No such file or directory: '/var/lib/libvirt/qemu/channels/bfc6f7cf-3e8d-4368-97f8-78a5c74a5175.com.redhat.rhevm.vdsm'2018-05-23 19:55:15,480+0800 INFO (vm/bfc6f7cf) [virt.vm] (vmId='bfc6f7cf-3e8d-4368-97f8-78a5c74a5175') CPU running: domain initialization (vm:5908) [root@hosted-engine-test1 ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:6c:ee:a8 brd ff:ff:ff:ff:ff:ff inet 192.168.122.217/24 brd 192.168.122.255 scope global dynamic eth0 valid_lft 2936sec preferred_lft 2936sec inet6 fe80::834a:9cc1:df2:83f/64 scope link valid_lft forever preferred_lft forever18: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 9a:d1:bc:96:cc:c0 brd ff:ff:ff:ff:ff:ff19: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000 link/ether 52:54:00:55:06:26 brd ff:ff:ff:ff:ff:ff inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr0 valid_lft forever preferred_lft forever20: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 1000 link/ether 52:54:00:55:06:26 brd ff:ff:ff:ff:ff:ff _______________________________________________ Users mailing list -- users(a)ovirt.org To unsubscribe send an email to users-leave(a)ovirt.org

6 years, 11 months

1
0
0 / 0

Re: Need advice using pacemaker on VMs for application HA

by wodel youchi

Hi, Thank you both for your responses, In a conclusion : - Don't mix up several solution that provide HA : - either choose oVirt HA. - or use software HA inside a VM. And since I need to monitor a service inside the VM for HA purpose, the implementation will be : - Create two VMs (nodes) without oVirt HA enabled. - Create the shared storage. - Configure pacemaker with stonith using fence rhev. - Test the configuration and my be try to test a hypervisor crash to see the behavior of the solution. Regards. 2018-05-24 17:12 GMT+01:00 Gianluca Cecchi <gianluca.cecchi(a)gmail.com>: > On Thu, May 24, 2018 at 6:05 PM, Gianluca Cecchi < > gianluca.cecchi(a)gmail.com> wrote: > >> >> >> >>> >>>> - What about the shared storage, we will use a shared disk on oVirt >>>> which does not support snapshot >>>> >>> >>> What is the question? >>> >> >> >> In the past I had to configure a virtual CentOS 6 cluster because I >> needed to replicate a problem I had in a physical production cluster and to >> verify if some actions/updates would have solved the problem. >> I had no more spare hw to configure an so using the poor-man method (dd + >> reconfigure) I had the cluster up and running with two twin nodes identical >> to the physical ones. >> I also opened this bugzilla to backport the el7 package to el6: >> https://bugzilla.redhat.com/show_bug.cgi?id=1446474 >> >> The intracluster network has been put on OVN btw >> >> But honestly I doubt I will use a virtual-cluster software stack to >> provide high availability to production services inside a VM. Too many >> inter-relations >> >> > I didn't complete the answer about storage. > Indeed if the cluster services need also a storage (eg a filesystem), you > should create dedicated virtual disks that you mark as shared and assign to > all the nodes of the virtual-cluster. > This compromise the snapshot functionality (of only the shared disks, you > can snapshot the boot disk and the not shared disks). > > HIH, > Gianluca > >

6 years, 11 months

1
0
0 / 0

Ovirt 4.2.4 upgrade

by Maton, Brett

The 4.2.4 upgrade appears to have a database issue, i'm seeing these errors in the postgresql logs: 2018-05-24 16:27:08.292 UTC ERROR: relation "provider_binding_host_id" does not exist at character 15 2018-05-24 16:27:08.292 UTC QUERY: SELECT 1 FROM provider_binding_host_id WHERE vds_id = v_vds_id FOR UPDATE 2018-05-24 16:27:08.292 UTC CONTEXT: PL/pgSQL function updatehostproviderbinding(uuid,character varying[],character varying[]) line 3 at PERFORM Any suggestions ?

6 years, 11 months

4
6
0 / 0

Re: hosted engine setup error

by dhy336＠sina.com

Hi thanks for your reponse, I try to do by your guide, but it is not work. my kernel version is 3.10.0-693.11.1.el7.x86_64.besides, I try to do hosted-engine --deploy in my Virtual machine is work. but it is not work in Physical Machine ----- Original Message ----- From: Yanir Quinn <yquinn(a)redhat.com> To: dhy336(a)sina.com Cc: users <users(a)ovirt.org> Subject: Re: [ovirt-users] hosted engine setup error Date: 2018-05-24 18:35 Hi There is a BZ with a similar issue: https://bugzilla.redhat.com/show_bug.cgi?id=1546839 To sum things up, try stopping the network manager and restarting your network if you are using a RH distribution, e,g. : systemctl stop NetworkManager systemctl restart networkAnd check what is your kernel version. On Wed, May 23, 2018 at 5:03 PM, <dhy336(a)sina.com> wrote: hiI deploy ovirt-engine-4.2.2 hosted-engine by #hosted-engine --deploy, but face some error bridge ovirtmgmt is not configure, i should how to do? thanks [ INFO ] TASK [Get ovirtmgmt route table id][ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 50, "changed": true, "cmd": "ip rule list | grep ovirtmgmt | sed s/\\\\[.*\\\\]\\ //g | awk '{ print $9 }'", "delta": "0:00:00.010899", "end": "2018-05-23 20:03:21.222559", "rc": 0, "start": "2018-05-23 20:03:21.211660", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}[ ERROR ] Failed to execute stage 'Closing up': Failed executing ansible-playbook[ INFO ] Stage: Clean up[ INFO ] Cleaning temporary resources vdsm.log 2018-05-23 19:55:15,305+0800 INFO (vm/bfc6f7cf) [virt.vm] (vmId='bfc6f7cf-3e8d-4368-97f8-78a5c74a5175') VM wrapper has started (vm:2619)2018-05-23 19:55:15,454+0800 INFO (vm/bfc6f7cf) [virt.vm] (vmId='bfc6f7cf-3e8d-4368-97f8-78a5c74a5175') Starting connection (guestagent:245)2018-05-23 19:55:15,458+0800 ERROR (vm/bfc6f7cf) [virt.vm] (vmId='bfc6f7cf-3e8d-4368-97f8-78a5c74a5175') Failed to connect to guest agent channel (vm:2403)Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2401, in _vmDependentInit self.guestAgent.start() File "/usr/lib/python2.7/site-packages/vdsm/virt/guestagent.py", line 246, in start self._prepare_socket() File "/usr/lib/python2.7/site-packages/vdsm/virt/guestagent.py", line 288, in _prepare_socket supervdsm.getProxy().prepareVmChannel(self._socketName) File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 55, in __call__ return callMethod() File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 53, in <lambda> **kwargs) File "<string>", line 2, in prepareVmChannel File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _callmethod raise convert_to_error(kind, result)OSError: [Errno 2] No such file or directory: '/var/lib/libvirt/qemu/channels/bfc6f7cf-3e8d-4368-97f8-78a5c74a5175.com.redhat.rhevm.vdsm'2018-05-23 19:55:15,480+0800 INFO (vm/bfc6f7cf) [virt.vm] (vmId='bfc6f7cf-3e8d-4368-97f8-78a5c74a5175') CPU running: domain initialization (vm:5908) [root@hosted-engine-test1 ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:6c:ee:a8 brd ff:ff:ff:ff:ff:ff inet 192.168.122.217/24 brd 192.168.122.255 scope global dynamic eth0 valid_lft 2936sec preferred_lft 2936sec inet6 fe80::834a:9cc1:df2:83f/64 scope link valid_lft forever preferred_lft forever18: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 9a:d1:bc:96:cc:c0 brd ff:ff:ff:ff:ff:ff19: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000 link/ether 52:54:00:55:06:26 brd ff:ff:ff:ff:ff:ff inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr0 valid_lft forever preferred_lft forever20: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 1000 link/ether 52:54:00:55:06:26 brd ff:ff:ff:ff:ff:ff _______________________________________________ Users mailing list -- users(a)ovirt.org To unsubscribe send an email to users-leave(a)ovirt.org

6 years, 11 months

2
1
0 / 0

Upload Image Error

by Peter Harman

Ovirt Users, I am running into a strange problem with uploading images through the webUI. When I test the connection on an upload I get “Connection to ovirt-imageio-proxy service has failed. Make sure the service is installed, configured, and ovirt-engine certificate is registered as a valid CA in the browser.” I have conducted this operation on several computers using both chrome and firefox and ensuring the certs were loaded into the browsers. I went to this page: https://ovirt.org/develop/release-management/features/infra/pki/ to find cert info and checked both the engine and hosts for the certificates and the identity of the certificates - everything seemed to match up. Next thing I looked at was the ovirt-imageio-proxy service. I checked it and restarted it below is a status output from one of the failed operations: [root@hpm-engine ~]# systemctl status ovirt-imageio-proxy ● ovirt-imageio-proxy.service - oVirt ImageIO Proxy Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio-proxy.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2018-05-24 13:25:38 CDT; 1h 13min ago Main PID: 21239 (ovirt-imageio-p) Tasks: 2 CGroup: /system.slice/ovirt-imageio-proxy.service └─21239 /usr/bin/python /usr/bin/ovirt-imageio-proxy May 24 13:25:38 hpm-engine.server.local systemd[1]: Starting oVirt ImageIO Proxy... May 24 13:25:38 hpm-engine.server.local systemd[1]: Started oVirt ImageIO Proxy. May 24 14:38:02 hpm-engine.server.local ovirt-imageio-proxy[21239]: 127.0.0.1 - - [24/May/2018 14:38:02] "PUT /tickets/ HTTP/1.1" 200 0 ovirt-imageio-proxy service seems to check out. So, next step was checking out VDSM process output is below (NOTE: I redacted a bunch of unrelated warnings): [root@mothership ~]# systemctl status vdsmd -l ● vdsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2018-05-24 08:12:40 CDT; 6h ago Main PID: 3359 (vdsmd) Tasks: 58 CGroup: /system.slice/vdsmd.service ├─3359 /usr/bin/python2 /usr/share/vdsm/vdsmd └─6731 /usr/libexec/ioprocess --read-pipe-fd 68 --write-pipe-fd 67 --max-threads 10 --max-queued-requests 10 So VDSM doesn’t seem to be the issue. I changed a few settings here and there but mostly forget what I did (I changed it all back to defult) Some background information - I am using /etc/hosts for all the FQDN components - which seems to be working well. I checked the times to be sure the time matched up (I know this important for some security related issues.) In a somewhat funny note I disabled SSL on VDSM in one attempt at the issue and now know why you should not do that when engine is using SSL. Any help is appreciated. I am learning a lot and really thank everyone who develops Ovirt - it’s awesome. Peter Harman - Systems and Safety Cordinator | Homeyer Precision Manufacturing [Description: C:\Users\gruether\AppData\Local\Temp\Temp1_Homeyer Logo (2).zip\Homeyer Logo\Homeyer Logo.jpg] 16051 State Hwy 47, Marthasville, MO 63357| E pharman(a)homeyertool.com |<mailto:pharman@homeyertool.com%20%7C> P 636.433.2244 | F 636.433.5257

6 years, 11 months

3
3
0 / 0

Failing to install self hosted engine - 4.2.4

by Maton, Brett

Hi, I can't see in the log what the problem is, I expect it's something simple though... Hoping that someone can see what the problem is. engine setup log attached. Regards, Brett

6 years, 11 months

2
1
0 / 0

Re: Fwd: FreeBSD after 10.3 could not boot (Freeze)

by Karli Sjöberg

6 years, 11 months

1
0
0 / 0

hosted engine deploy failed , engine vm is shudown

by dhy336＠sina.com

Hi I deploy hosted engine face some errors.[ INFO ] TASK [Get ovirtmgmt route table id][ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 50, "changed": true, "cmd": "ip rule list | grep ovirtmgmt | sed s/\\\\[.*\\\\]\\ //g | awk '{ print $9 }'", "delta": "0:00:00.004175", "end": "2018-05-26 17:41:11.892218", "rc": 0, "start": "2018-05-26 17:41:11.888043", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}[ ERROR ] Failed to execute stage 'Closing up': Failed executing ansible-playbook[ INFO ] Stage: Clean up[ INFO ] Cleaning temporary resources[ INFO ] TASK [Gathering Facts][ INFO ] ok: [localhost][ INFO ] TASK [Remove local vm dir] I find when hosted-engine -deloy run [Get ovirtmgmt route table id], my enginen VM is shutdown,and /var/log/message show my engine vm is powered down by guest-shutdown, May 26 09:32:23 engine systemd: Reloading.May 26 09:32:24 engine python: ansible-file Invoked with directory_mode=None force=False remote_src=None path=/root/heanswers.conf owner=None follow=False group=None unsafe_writes=None state=absent content=NOT_LOGGING_PARAMETER serole=None diff_peek=None setype=None selevel=None original_basename=None regexp=None validate=None src=None seuser=None recurse=False delimiter=None mode=None attributes=None backup=NoneMay 26 09:32:38 engine systemd-logind: Removed session 3.May 26 09:32:48 engine qemu-ga: info: guest-shutdown called, mode: powerdownMay 26 09:32:48 engine systemd: Started Delayed Shutdown Service.May 26 09:32:48 engine systemd: Starting Delayed Shutdown Service...May 26 09:32:48 engine systemd-shutdownd: Shutting down at Sat 2018-05-26 17:32:48 CST (poweroff)...May 26 09:32:48 engine systemd-shutdownd: Creating /run/nologin, blocking further logins...May 26 09:32:48 engine systemd: Stopping QEMU Guest Agent...May 26 09:32:48 engine systemd: Stopping Session 1 of user root.May 26 09:32:48 engine systemd: Stopped target Multi-User System.May 26 09:32:48 engine systemd: Stopping Multi-User System.May 26 09:32:48 engine systemd: Stopped Execute cloud user/final scripts.May 26 09:32:48 engine systemd: Stopping Execute cloud user/final scripts...May 26 09:32:48 engine systemd: Stopping oVirt Engine...May 26 09:32:48 engine sshd[24523]: Received signal 15; terminating.May 26 09:32:48 engine systemd: Stopping OpenSSH server daemon...May 26 09:32:48 engine systemd: Stopping The Apache HTTP Server...

6 years, 11 months

1
0
0 / 0

Problems with configuring ovirt and neotron network integration

by Pym

Hi: Environmental information： 4.2.0 ovirt version, according to "https://www.ovirt.org/documentation/how-to/networking/overlay-networks-wi..." document of it services. Both services are accessible from the browser. After the above environment is configured according to the document, I need to execute the following command "engine-config --set keyauthstoneurl =http://< host-fqdn >:35357/v2.0" on the ovirt-engine side. The following information appears: "Error setting KeystoneAuthUrl's value. No such entry." When I execute "engine-config-a | grep-i 'KeystoneAuthUrl'", there is no return value, and there is no such configuration item in the current version of ovirt. Now how do I proceed next? Thanks！

6 years, 11 months

1
0
0 / 0

hosted-engine 4.2.3.7-1 "engine-setup"

by femi adegoke

This is oVirt 4.2.3 + Gluster. I ran yum -y update on the hosted engine. It installed 1 package & upgraded 16. Is it necessary to run "engine-setup" again after the yum update?

6 years, 11 months

2
1
0 / 0

Hosted Engine failed

by shamilkpm＠gmail.com

I am hosting ovirt node as VM under VMware. when try to run engine setup, it getting fails and error [ INFO ] TASK [Create cloud init user-data and meta-data files] [ INFO ] TASK [Create ISO disk] [ INFO ] changed: [localhost] [ INFO ] TASK [Create local VM] [ INFO ] changed: [localhost] [ INFO ] TASK [Get local VM IP] [ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 50, "changed": true, "cmd": "virsh -r net-dhcp-leases default | grep -i 00:16:3E:6A:7A:F9 | awk '{ print $5 }' | cut -f1 -d'/'", "delta": "0:00:00.095336", "end": "2018-05-25 00:52:21.390980", "rc": 0, "start": "2018-05-25 00:52:21.295644", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []} [ INFO ] TASK [include_tasks] [ INFO ] ok: [localhost] [ INFO ] TASK [Remove local vm dir] [ INFO ] changed: [localhost] [ INFO ] TASK [Notify the user about a failure] [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "The system may not be provisioned according to the playbook results: please check the logs for the issue, fix accordingly or re-deploy from scratch.\n"} ANYONE CAN HELP ME ?? -SHAMZ

6 years, 11 months

2
1
0 / 0

oVirt 4.2 host actions dropdown truncated

by Gianluca Cecchi

example of full list in oVirt 4.2.3.5 with only one host https://drive.google.com/file/d/12fj3uorno9UjBL_aNQOG0mUSqEFn-Ol4/view?us... example of truncated list in oVirt 4.2.3.7 with 3 hosts https://drive.google.com/file/d/1Es3YSAhcB_L-feaHdkAvwZz8BTB3sYiS/view?us... if I select with the mouse into the column and then scroll with mouse, I can see also the items below in the list: STOP, SSH MANAGEMENT, ecc. but all in all it seems counter-intuitive to me... I think the .5 vs the .7 in version is not the culprit. Anyone can reproduce? BTW: I reproduced the same strange behavior also in an RHV environment with latest 4.2 (updated yesterday), with two hosts. Any comments? Gianluca

6 years, 11 months

2
1
0 / 0

[ANN] oVirt 4.2.4 First Release Candidate is now available

by Sandro Bonazzola

The oVirt Project is pleased to announce the availability of the oVirt 4.2.4 First Release Candidate, as of May 24th, 2018 This update is a release candidate of the fourth in a series of stabilization updates to the 4.2 series. This is pre-release software. This pre-release should not to be used in production. This release is available now for: * Red Hat Enterprise Linux 7.5 or later * CentOS Linux (or similar) 7.5 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.5 or later * CentOS Linux (or similar) 7.5 or later Due to an issue with CentOS mirrors oVirt Node has not been built. We'll build and release oVirt Node as soon as the updated qemu-kvm-ev will be available on CentOS mirrors. See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance is available - oVirt Node is not yet available, will be provided soon[2] Additional Resources: * Read more about the oVirt 4.2.4 release highlights: http://www.ovirt.org/release/4.2.4/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] http://www.ovirt.org/release/4.2.4/ [2] http://resources.ovirt.org/pub/ovirt-4.2-pre/iso/ -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

6 years, 11 months

2
3
0 / 0

Support for openstack keystone v3 API?

by Bernhard Dick

Hi, I wanted to try ceph with oVirt and so I've installed an openstack queens (current stable) environment containing cinder and keystone. But when I tried to add the storage provider I ended up with 404 errors in the engine log files. They are because oVirt tries using the v2.0 API, and http://HOST:5000/v2.0/tokens does not exist. If I understand the release notes of openstack correctly the section https://blueprints.launchpad.net/keystone/+spec/removed-as-of-queens includes all v2.0 API being removed from keystone. So I'm asking whether there is support for the v3 API in sight? Regards Bernhard

6 years, 11 months

2
3
0 / 0

Error setting cluster level to 4.2

by Gianluca Cecchi

Hello, after upgrading engine (external) and the 3 hosts composing the cluster, I try to set its level to 4.2 but I receive this kind of message " Error while executing action: Update of cluster compatibility version failed because there are VMs/Templates [ov42, ovlive3, ovlive4, ovlive1, ovlive2] with incorrect configuration. To fix the issue, please go to each of them, edit, change the Custom Compatibility Version of the VM/Template to the cluster level you want to update the cluster to and press OK. If the save does not pass, fix the dialog validation. After successful cluster update, you can revert your Custom Compatibility Version change. " The ovliveN VMs are diskless where I boto from the oVirt live iso for testing and ov42 a nested single VM where I tested the oVirt 4.2 environment before upgrade of the real cluster. I suspect that the problem could be related with macspoof custom property set to true. Is this? In case how can I manage this sort of problem? Can't I have macspoof in 4.2? Thanks, Gianluca

6 years, 11 months

3
3
0 / 0

Need advice using pacemaker on VMs for application HA

by wodel youchi

Hi, Excuse the English :) Need some advice regarding the use of high availability software on VMs on oVirt. We are migrating a physical high available application to oVirt. The HA platform uses pacemaker, it contains two nodes and a shared storage, fence (stonith) is configured to use ILO. I know that oVirt offers HA for VM, but this HA is not application aware, if a service crashes on the VM, it will not be detected. Fencing could be achieved by fence agent rhev. My questions are about the best way to migrate this platform to oVirt. - Is it a good idea to make both VMs (formally nodes) Highly-Available VMs? or may be pin each one of them to a particular hypervisor and/or use VM-Affinity? - I am thinking about the situation where the hypervisor containing one of the VMs crashes, what will be the behavior of the the fence agent on the application? - if the crashed VM is not HA, it will not start on another hypervisor, so the fence agent will try to fence a VM that does not exist anymore, and it will stuck. - if the crashed VM is HA, it will be started on another hypervisor, but what will happen with the fence agent? I think that one VM will fence the other one, and the application will still be unreachable for a longer period. - What about the shared storage, we will use a shared disk on oVirt which does not support snapshot - What are the things to avoid? Any suggestions will be appreciated. Regards.

6 years, 11 months

3
2
0 / 0

Re: Ovirt 4.2.3 missing features?

by Simone Tiraboschi

On Thu, May 24, 2018 at 5:30 PM, Guilhem Berna <gberna(a)phosphore.eu> wrote: > Unfortunately the menu is the same when clicking on name. > Try clicking with the left button: it will open a new page where you will find the snapshot tab. Check the attached screenshot. Now the URLs are also predictable so you can easily directly edit it or bookmark for a direct access. > > Best regards, > > Guilhem Berna > Administrateur Système PHOSPHORE.si - https://www.phosphore.si > +33 4 66 51 87 73 > > ------------------------------ > *De: *"Simone Tiraboschi" <stirabos(a)redhat.com> > *À: *"Guilhem Berna" <gberna(a)phosphore.eu> > *Cc: *"users" <users(a)ovirt.org> > *Envoyé: *Jeudi 24 Mai 2018 17:05:08 > *Objet: *Re: [ovirt-users] Ovirt 4.2.3 missing features? > > > > On Thu, May 24, 2018 at 4:07 PM, Guilhem Berna <gberna(a)phosphore.eu> > wrote: > >> Hi, >> >> New user of ovirt here, i'm trying ovirt 4.2.3.5-1 on centos 7.5. >> On the web administration interface i'm missing a lot of features >> compared to the guides I can find online or even compared to the official >> docs. >> >> For example I can't find how to restore a snapshot, I don't have the >> snapshot tab as mentionned here : https://www.ovirt.org/ >> documentation/user-guide/user-guide/#using-a-snapshot-to- >> restore-a-virtual-machine >> I can't find how to convert a machine to a template either : >> >> >> >> Is there something i'm missing? Am I running the wrong version or do I >> need to configure something ? >> > > Did you tried clicking on the VM name? > > The UI pattern is slightly different from how it used to be in previous > versions. > > >> >> Best regards, >> >> 4.2.3 >> <https://www.ovirt.org/documentation/user-guide/user-guide/#using-a-snapsh...> >> >> Guilhem Berna >> Sysadmin PHOSPHORE.si - https://www.phosphore.si >> >> >> >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org >> To unsubscribe send an email to users-leave(a)ovirt.org >> >> >

6 years, 11 months

1
0
0 / 0

error message: how to troubleshoot

by femi adegoke

Migration failed (VM: HostedEngine, Source: ovirt-node1.livemigrate.com, Destination: ovirt-node2.livemigrate.com). Hi All, Trying to get my feet wet & learn more. What are the steps to troubleshooting an error message like this. Where do I go? What should I be looking for?

6 years, 11 months

2
4
0 / 0

Ovirt 4.2.3 missing features?

by Guilhem Berna

Hi, New user of ovirt here, i'm trying ovirt 4.2.3.5-1 on centos 7.5. On the web administration interface i'm missing a lot of features compared to the guides I can find online or even compared to the official docs. For example I can't find how to restore a snapshot, I don't have the snapshot tab as mentionned here : [ https://www.ovirt.org/documentation/user-guide/user-guide/#using-a-snapsh... | https://www.ovirt.org/documentation/user-guide/user-guide/#using-a-snapsh... ] I can't find how to convert a machine to a template either : Is there something i'm missing? Am I running the wrong version or do I need to configure something ? Best regards, [ https://www.ovirt.org/documentation/user-guide/user-guide/#using-a-snapsh... | 4.2.3 ] Guilhem Berna Sysadmin PHOSPHORE.si - [ https://www.phosphore.si/ | https://www.phosphore.si ]

6 years, 11 months

2
1
0 / 0

Discard is not supported by underlying storage

by Julio Cesar Bustamante

Hi there, I have tried o add a ID LUN from IBM Storage DS3524 by fiber channel, but it appeared this message " Discard is not supported by underlying storage". What am I doing wrong ? Should I do anything else previously?. The version Ovirt manager is 4.2.0.2-1. -- Julio Cesar Bustamante.

6 years, 11 months

4
3
0 / 0

oVirt Privacy policy change

by Sandro Bonazzola

*As part of an oVirt project review, we're publishing an updated privacy policy.You should read the statement fully, but the key updates include:* Clearer descriptions of how oVirt uses your personal data to provide services;* Additional detail on how your personal data may be shared to serve the public interest and that of the open source community; and* More focus on how you can review, modify, and update your personal data.You can find the new statement on the oVirt website at this location: https://ovirt.org/site/privacy-policy/ <https://ovirt.org/site/privacy-policy/>oVirt website pages have been updated to include links to the privacy policy. The new privacy statement takes effect on Friday, May 25, 2018.* -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

6 years, 11 months

1
0
0 / 0

oVirt Privacy policy change

by Sandro Bonazzola

*As part of an oVirt project review, we're publishing an updated privacy policy.You should read the statement fully, but the key updates include:* Clearer descriptions of how oVirt uses your personal data to provide services;* Additional detail on how your personal data may be shared to serve the public interest and that of the open source community; and* More focus on how you can review, modify, and update your personal data.You can find the new statement on the oVirt website at this location: https://ovirt.org/site/privacy-policy/ <https://ovirt.org/site/privacy-policy/>oVirt website pages have been updated to include links to the privacy policy. The new privacy statement takes effect on Friday, May 25, 2018. * -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig> <https://redhat.com/summit>

6 years, 11 months

1
0
0 / 0

hosted engine setup error

by dhy336＠sina.com

hiI deploy ovirt-engine-4.2.2 hosted-engine by #hosted-engine --deploy, but face some error bridge ovirtmgmt is not configure, i should how to do? thanks [ INFO ] TASK [Get ovirtmgmt route table id][ ERROR ] fatal: [localhost]: FAILED! => {"attempts": 50, "changed": true, "cmd": "ip rule list | grep ovirtmgmt | sed s/\\\\[.*\\\\]\\ //g | awk '{ print $9 }'", "delta": "0:00:00.010899", "end": "2018-05-23 20:03:21.222559", "rc": 0, "start": "2018-05-23 20:03:21.211660", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}[ ERROR ] Failed to execute stage 'Closing up': Failed executing ansible-playbook[ INFO ] Stage: Clean up[ INFO ] Cleaning temporary resources vdsm.log 2018-05-23 19:55:15,305+0800 INFO (vm/bfc6f7cf) [virt.vm] (vmId='bfc6f7cf-3e8d-4368-97f8-78a5c74a5175') VM wrapper has started (vm:2619)2018-05-23 19:55:15,454+0800 INFO (vm/bfc6f7cf) [virt.vm] (vmId='bfc6f7cf-3e8d-4368-97f8-78a5c74a5175') Starting connection (guestagent:245)2018-05-23 19:55:15,458+0800 ERROR (vm/bfc6f7cf) [virt.vm] (vmId='bfc6f7cf-3e8d-4368-97f8-78a5c74a5175') Failed to connect to guest agent channel (vm:2403)Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2401, in _vmDependentInit self.guestAgent.start() File "/usr/lib/python2.7/site-packages/vdsm/virt/guestagent.py", line 246, in start self._prepare_socket() File "/usr/lib/python2.7/site-packages/vdsm/virt/guestagent.py", line 288, in _prepare_socket supervdsm.getProxy().prepareVmChannel(self._socketName) File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 55, in __call__ return callMethod() File "/usr/lib/python2.7/site-packages/vdsm/common/supervdsm.py", line 53, in <lambda> **kwargs) File "<string>", line 2, in prepareVmChannel File "/usr/lib64/python2.7/multiprocessing/managers.py", line 773, in _callmethod raise convert_to_error(kind, result)OSError: [Errno 2] No such file or directory: '/var/lib/libvirt/qemu/channels/bfc6f7cf-3e8d-4368-97f8-78a5c74a5175.com.redhat.rhevm.vdsm'2018-05-23 19:55:15,480+0800 INFO (vm/bfc6f7cf) [virt.vm] (vmId='bfc6f7cf-3e8d-4368-97f8-78a5c74a5175') CPU running: domain initialization (vm:5908) [root@hosted-engine-test1 ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 52:54:00:6c:ee:a8 brd ff:ff:ff:ff:ff:ff inet 192.168.122.217/24 brd 192.168.122.255 scope global dynamic eth0 valid_lft 2936sec preferred_lft 2936sec inet6 fe80::834a:9cc1:df2:83f/64 scope link valid_lft forever preferred_lft forever18: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 9a:d1:bc:96:cc:c0 brd ff:ff:ff:ff:ff:ff19: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000 link/ether 52:54:00:55:06:26 brd ff:ff:ff:ff:ff:ff inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr0 valid_lft forever preferred_lft forever20: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 1000 link/ether 52:54:00:55:06:26 brd ff:ff:ff:ff:ff:ff

6 years, 11 months

2
1
0 / 0

Fwd: Shameless networking question

by Ales Musil

On Wed, May 23, 2018 at 2:43 PM, Peter Harman <pharman(a)homeyertool.com> wrote: > Ovirt Community, > > > > First off: thank you – these emails have helped me to get Ovirt running. I > barely know what I am doing but learning quickly. > > > > I am trying to do a network separation and confusing myself. I have two > physical networks (10.10.x.x/16 and 192.168.1.x/24) my ovirt management is > bridged on 10.10.x.x. My (currently single) Hosts have at least one > physical NIC connecting to each network. I am trying to get to the point > there the VMs are on the 192.168.1.x network and the 10.10.x.x network. The > goal is to join the VMs to a AD domain on 192.168.1.x but keep access as > limited as possible to the 10.10.x.x network. > > > > I’ve been on a googlethon over the past few days and still don’t > understand the best practice – or even a working practice – to accomplish > this goal. > > > > *Peter Harman – Systems and Safety Cordinator | Homeyer Precision > Manufacturing* > > > > [image: Description: C:\Users\gruether\AppData\Local\Temp\Temp1_Homeyer > Logo (2).zip\Homeyer Logo\Homeyer Logo.jpg] > > > > 16051 State Hwy 47, Marthasville, MO 63357| *E *pharman(a)homeyertool.com | > *P* 636.433.2244 | *F* 636.433.5257 > > > > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > > Hi Peter, if I understand this correctly you can achieve that by marking the 192.168.1.x network as VM network via UI: Networks -> Desired network -> Edit -> Check VM network and save. Then in any VM that you want to be on this network set NICs VNIC profile that is connected to 192.168.1.x via UI: Virtual Machines -> Desired VM -> Network Interfaces -> nicX -> Edit -> Profile -> Select profile that is connected to 192.168.1.x -> Save. If the VM is up and running you need to first unplug the interface save it and then change profile and plug it in again. Hopefully this helps. Regards, Ales -- ALES MUSIL INTERN - rhv network Red Hat EMEA <https://www.redhat.com/> amusil(a)redhat.com IM: amusil <https://red.ht/sig>

6 years, 11 months

1
0
0 / 0

Obtain dynamic inventory onto local machine using ovirt4.py for self-hosted engine

by 03ce007＠gmail.com

I have successfully deployed self-hosted-engine (4.2) on centos (7.4) server. the server address is ovirt where the self-hosted engine running on it has fdqn as engine.ovirt. I have ovirt,ini configured on server acan run the ovirt4.py from the server to obtain the vms in groups. But I want to control the vms using ansible from my macbook and run ansible playbooks locally. so I have downloaded the ovirt.ini and ovirt4.py from server and tried running it, but had no success. Is there something special needs setting up for 'self-hosted-ovirt-engine' as oppose to vanilla ovirt-engine which will allow me to control vms from my macbook? thanks.

6 years, 11 months

5
4
0 / 0

oVirt upgrade node from 4.1.9 to 4.2.3

by rcasebier＠adicio.com

My engine is upgraded and running 4.2.3. I am testing out upgrading my first local storage node. I installed the 4.2 release repo and ran a yum update. I had to manually install the following packages form CentOS (yum install udisks2 lshw iotop libvirt-daemon-config-network virt-install python-prettytable) for some reason these dependencies did not exist in the oVirt repo's. I was able to run yum update after fixing this issue and my host was installed with 4.2.3. After a reboot, it failed to boot, the host failed to start the login service and the authorization manager. Has anyone run into this issue?

6 years, 11 months

1
0
0 / 0

Using remote viewer outside lan

by Aziz

Hi all, I am able to access my VMs from LAN using remote Viewer, however this is not working from outside LAN, my setup is as follow: 1. Controller in a separate HW machine 2. Host in a server When checking the console.vv file, I see that it includes the local IP address of the host + port 5900. Is there a way to force ovirt to generate a console.vv file with public IP port when the user tries to connect from Internet and another file with lan IP when the user tries to connect from LAN. Any hint on how to set this feature up ? Best regards

6 years, 11 months

4
3
0 / 0

Second host deployment fails on self-hosted-engine

by 03ce007＠gmail.com

I have self-hosted-engine (4.2) deployed successfully on cento (7.4) server. The physical server has 'ovirt' as hostname and the self-hosted engineVM deployed and running on it has 'engine.ovirt' as fdqn. I want to deploy another host on engineVM and I am using pre-baked oVirt.Infra role example playbook that has two host defined. But when I run it against the engineVM it fails with 'Connecting to host via SSH has failed' error. Below is the snippet from engine.log Failed to establish session with host 'host2': SSH connection timed out connecting to 'root(a)1.2.3.6' Validation of action 'AddVds' failed for user admin@internal-authz. Reasons: VAR__ACTION__ADD,VAR__TYPE__HOST,$server 1.2.3.6,VDS_CANNOT_CONNECT_TO_SERVER I thought, the example playbook should run and deploy two hosts on already deployed engineVM. Do i need to update the example playbook?

6 years, 11 months

2
1
0 / 0

Re: ovirt and gluster disk config

by Karli Sjöberg

6 years, 11 months

1
0
0 / 0

Hosted Engine Setup Erro

by Sakhi Hadebe

Hi, I am new to ansible and tring to deploy an ovrt cluster with gluster. I am following this documentation https://www.ovirt.org/blog/2018/02/up-and-running-with-ovirt-4-2-and-glus..., although the screenshots are not exactly the same. Gluster successfully deployed. Below is what is insatlled on my OvirtNodes: 1. ansible --version ansible 2.5.3 config file = /etc/ansible/ansible.cfg 2. glusterfs 3.12.9 3. oVirtNode 4.2.3 4. CentOS Linux release 7.4.1708 (Core) During the hosted engine setup it throws the ERROR below: [ INFO ] TASK [Prepare CIDR for "virbr0"] [ ERROR ] fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'ipv4'\n\nThe error appears to have been in '/usr/share/ovirt-hosted-engine-setup/ansible/bootstrap_local_vm.yml': line 50, column 7, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n tags: [ 'skip_ansible_lint' ]\n - name: Prepare CIDR for \"{{ virbr_default }}\"\n ^ here\nWe could be wrong, but this one looks like it might be an issue with\nmissing quotes. Always quote template expression brackets when they\nstart a value. For instance:\n\n with_items:\n - {{ foo }}\n\nShould be written as:\n\n with_items:\n - \"{{ foo }}\"\n"} [ ERROR ] Failed to execute stage 'Closing up': Failed executing ansible-playbook I have tried to use quotes on line 50 in the bootstrap_local_vm.yml file, it didn't work. Please help, I have been stuck on this almost the whole day. -- Regards, Sakhi Hadebe Engineer: South African National Research Network (SANReN)Competency Area, Meraka, CSIR Tel: +27 12 841 2308 <+27128414213> Fax: +27 12 841 4223 <+27128414223> Cell: +27 71 331 9622 <+27823034657> Email: sakhi(a)sanren.ac.za <shadebe(a)csir.co.za>

6 years, 11 months

3
2
0 / 0

ovirt and gluster disk config

by william.dossett＠gmail.com

Hey, been a few years since I looked at ovirt. 3 years probably and at the time I was looking for compute and storage all in one -and was advised not to basically. So Hyperconvergence is now a thing and want to try it out. I was looking at the blog - up and running with ovirt 4.1, but it seems that is mostly for a lab setup. I've got some real hardware I am going to try this out on as a PoC, 5 Dell R720s with 12 TB raw storage in each. Just wondered if there was a guide to the hardware setup of my storage that I am missing? Should I configure the storage as hardware RAID before I start installing the Nodes? I did setup glusterfs cluster 3 years ago as well but memory fails me on how I had the RAID controller setup if at all. Thanks

6 years, 11 months

4
3
0 / 0

attempting to upgrade ovirt host which fails.

by Edward Clay

Hello, Today I began upgrading my ovirt 4.1 to 4.2 by updating the engine following the steps in the 4.2 readme. This went well and the upgrade completed. What I've run into is I have attempted to install the ovirt release 4.2 on the host and then ran a yum upgrade on it while in maintenance mode. I rebooted the system and can put the host into active mode but in the ovirt compute host screen is showing that updates are available. No mater what I do to tell it to check for updates it still shows available updates. If I install updates they fail. I see events like the following in the graphical interface. Check for available updates on host host1 was completed successfully with message 'found updates for packages ovirt-host'. Host host1 was switched to Maintenance mode Host host1 upgrade was started Failed to upgrade Host host1 How can I resolve this issue? Edward Clay Systems Administrator The Hut Group<http://www.thehutgroup.com/> Tel: Email: edward.clay(a)uk2group.com<mailto:edward.clay@uk2group.com> For the purposes of this email, the "company" means The Hut Group Limited, a company registered in England and Wales (company number 6539496) whose registered office is at Fifth Floor, Voyager House, Chicago Avenue, Manchester Airport, M90 3DQ and/or any of its respective subsidiaries. Confidentiality Notice This e-mail is confidential and intended for the use of the named recipient only. If you are not the intended recipient please notify us by telephone immediately on +44(0)1606 811888 or return it to us by e-mail. Please then delete it from your system and note that any use, dissemination, forwarding, printing or copying is strictly prohibited. Any views or opinions are solely those of the author and do not necessarily represent those of the company. Encryptions and Viruses Please note that this e-mail and any attachments have not been encrypted. They may therefore be liable to be compromised. Please also note that it is your responsibility to scan this e-mail and any attachments for viruses. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or confidentiality in relation to transmissions sent by e-mail. Monitoring Activity and use of the company's systems is monitored to secure its effective use and operation and for other lawful business purposes. Communications using these systems will also be monitored and may be recorded to secure effective use and operation and for other lawful business purposes. hgvyjuv

6 years, 11 months

2
2
0 / 0

Shameless networking question

by Peter Harman

Ovirt Community, First off: thank you - these emails have helped me to get Ovirt running. I barely know what I am doing but learning quickly. I am trying to do a network separation and confusing myself. I have two physical networks (10.10.x.x/16 and 192.168.1.x/24) my ovirt management is bridged on 10.10.x.x. My (currently single) Hosts have at least one physical NIC connecting to each network. I am trying to get to the point there the VMs are on the 192.168.1.x network and the 10.10.x.x network. The goal is to join the VMs to a AD domain on 192.168.1.x but keep access as limited as possible to the 10.10.x.x network. I've been on a googlethon over the past few days and still don't understand the best practice - or even a working practice - to accomplish this goal. Peter Harman - Systems and Safety Cordinator | Homeyer Precision Manufacturing [Description: C:\Users\gruether\AppData\Local\Temp\Temp1_Homeyer Logo (2).zip\Homeyer Logo\Homeyer Logo.jpg] 16051 State Hwy 47, Marthasville, MO 63357| E pharman(a)homeyertool.com |<mailto:pharman@homeyertool.com%20%7C> P 636.433.2244 | F 636.433.5257

6 years, 11 months

1
0
0 / 0

How to delete leftover of a failed live storage migration disk

by Gianluca Cecchi

Hello, I had an error during live storage migration of a disk. The destination image was created but the process was not completed, because of a bug in the original version of sw. Then I updated sw but if I try to run again the move of the same disk to the same destination storage domain I get VDSM command HSMGetAllTasksStatusesVDS failed: Cannot create Logical Volume: ('679c0725-75fb-4af7-bff1-7c447c5d789c', 'd2a89b5e-7d62-4695-96d8-b762ce52b379') On destination storage domain, that is empty, from web admin gui I see only the 2 OVF_STORE disks. From OS point of view using lvs I see the leftover LV that oVirt complains not able to create (I suppose because already existent due to the former error) # lvs 679c0725-75fb-4af7-bff1-7c447c5d789c/d2a89b5e-7d62-4695-96d8-b762ce52b379 LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert d2a89b5e-7d62-4695-96d8-b762ce52b379 679c0725-75fb-4af7-bff1-7c447c5d789c -wi------- 55.00g I know that I should use the "vdsClient -s 0 deleteVolume " command from the SPM host. the syntax should be # vdsClient -s 0 deleteVolume --help Error using command: list index out of range deleteVolume <sdUUID> <spUUID> <imgUUID> <volUUID>,...,<volUUID> <postZero> [<force>] Deletes an volume if its a leaf. Else returns error I have difficulties to do the exact mapping of the various elements. Is it right what below? sdUUID --> VG name spUUID I can retrieve using: # vdsClient -s 0 getStorageDomainInfo 679c0725-75fb-4af7-bff1-7c447c5d789c uuid = 679c0725-75fb-4af7-bff1-7c447c5d789c type = ISCSI vguuid = nkoZA2-nQOu-oeXX-Phpa-moqh-FWuR-AFAh4B metadataDevice = 36589cfc0000006dd999f5618bf759d3f state = OK version = 4 role = Master vgMetadataDevice = 36589cfc0000006dd999f5618bf759d3f class = Data pool = ['5af30d59-004c-02f2-01c9-0000000000b8'] name = ISCSI_400G so spUUID is the pool --> 5af30d59-004c-02f2-01c9-0000000000b8 in my case ? for imgUUID I don't know a command to retrieve. in my case the target storage domain (ISCSI_400G) in this moment is the master one and I can see it under /rhev/data-center/mnt/blockSD/ and so I find # ll /rhev/data-center/mnt/blockSD/679c0725-75fb-4af7-bff1-7c447c5d789c/images/ total 4 drwxr-xr-x. 2 vdsm kvm 4096 May 10 15:39 530b3e7f-4ce4-4051-9cac-1112f5f9e8b5 So it seems to me in my case imgUUID is 530b3e7f-4ce4-4051-9cac-1112f5f9e8b5 But even if it is right in my particular case, how can I get in general? volUUID ? Is it the LV name corresponding, so in my case d2a89b5e-7d62-4695-96d8-b762ce52b379 ? The result of the vdsCLient command should be the removal of LV also? Thanks in advance for any insight or link to details... Gianluca

6 years, 11 months

4
5
0 / 0

info about reinstall dead node

by Gianluca Cecchi

Hello, I have an host dead in a 4.1.9 environment (broken raid controller compromised both internal disks, don't ask me how it could happen...). I have replaced controller/disks and reinstalled ng-node on the same hw with the same parameters and same version (but ovirtmgmt bridge not present yet, only a bond0 that has to become backed up by the ovirtmgmt bridge when installed). In web admin gui it had been set as not responsive when failed. Now I cannot reinstall it as new. If I try to put it into maintenance it is correctly rebooted but then it remains non responsive. I think I have to "force remove" in some way the previous instance of this node, but the option is greyed out... How can I clean the node and then try to install as new again? Thanks, Gianluca

6 years, 11 months

2
2
0 / 0

First host within Self-Hosted engine stays in non-responsive state

by 03ce007＠gmail.com

I am trying to setup self-hosted-engine (4.2) on a single machine running centos 7.4. I ran hosted-engine deploy script and it ran all the way through but failed on last task (at "Wait for the local bootstrap VM to be down at engine eyes") while creating the local engine VM. However, the --vm-status shows the engine status as up and is in good health, but I cannot interact with host installed on engine VM. The host within engine VM shows it is in non-responsive state, not clear why and what caused it. I can ssh into the local engine VM and the engine.log has below entries - 2018-05-17 11:03:57,739+01 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.VmDevicesMonitoring] (EE-ManagedThreadFactory-engineScheduled-Thread-78) [6768004b] Exception:: org.springframework.dao.DataIntegrityViolationException: CallableStatementCallback; SQL [{call insertvmdevice(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)}]; ERROR: insert or update on table "vm_device" violates foreign key constraint "fk_vm_device_vm_static" Detail: Key (vm_id)=(114581bb-7fef-4b08-8e3c-85dd5a9e680b) is not present in table "vm_static". ... ... ... 2018-05-17 11:03:59,957+01 ERROR [org.ovirt.engine.core.bll.pm.FenceProxyLocator] (EE-ManagedThreadFactory-engineScheduled-Thread-44) [2bf8b18f] Can not run fence action on host 'ovirt', no suitable proxy host was found. ... ... ... 2018-05-17 11:20:00,093+01 ERROR [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (EE-ManagedThreadFactory-engine-Thread-2) [1a833057] Exception during connection ... ... ... 2018-05-17 11:20:00,386+01 ERROR [org.ovirt.engine.core.vdsbroker.HostDevListByCapsVDSCommand] (EE-ManagedThreadFactory-engine-Thread-2) [1a833057] Command 'HostDevListByCapsVDSCommand(HostName = ovirt, VdsIdAndVdsVDSCommandParametersBase:{hostId='1a6a47e6-934e-43f7-ad5b-ba8f8ff8df99', vds='Host[ovirt,1a6a47e6-934e-43f7-ad5b-ba8f8ff8df99]'})' execution failed: java.net.UnknownHostException: ovirt: Name or service not known ... ... ... 2018-05-17 11:20:03,287+01 ERROR [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (EE-ManagedThreadFactory-engineScheduled-Thread-14) [] Exception during connection 2018-05-17 11:20:03,292+01 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] (EE-ManagedThreadFactory-engineScheduled-Thread-14) [] Unable to RefreshCapabilities: UnknownHostException: ovirt 2018-05-17 11:20:03,294+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-14) [] Command 'org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand' return value 'org.ovirt.engine.core.vdsbroker.vdsbroker.VDSInfoReturn@46e3da89' 2018-05-17 11:20:03,294+01 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-14) [] HostName = ovirt 2018-05-17 11:20:03,297+01 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesAsyncVDSCommand] (EE-ManagedThreadFactory-engineScheduled-Thread-14) [] Command 'GetCapabilitiesAsyncVDSCommand(HostName = ovirt, VdsIdAndVdsVDSCommandParametersBase:{hostId='1a6a47e6-934e-43f7-ad5b-ba8f8ff8df99', vds='Host[ovirt,1a6a47e6-934e-43f7-ad5b-ba8f8ff8df99]'})' execution failed: java.net.UnknownHostException: ovirt 2018-05-17 11:20:03,316+01 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engineScheduled-Thread-15) [] EVENT_ID: VDS_BROKER_COMMAND_FAILURE(10,802), VDSM ovirt command GetCapabilitiesAsyncVDS failed: Connection issue ovirt 2018-05-17 11:20:03,317+01 ERROR [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] (EE-ManagedThreadFactory-engineScheduled-Thread-15) [] Unable to RefreshCapabilities: VDSNetworkException: VDSGenericException: VDSNetworkException: Connection issue ovirt ... ... ... and then above 5 ERROR messages are keep getting repeated. Why the connection fails when I can still ssh into the engine? where is the issue here?

6 years, 11 months

4
9
0 / 0

update from 4.1.9 to 4.2.3 and OVN doubt

by Gianluca Cecchi

Hello, at beginning of 2017 I configured OVN in my oVirt 4.1.0 setup, with the previosulsy described notes, I think the ones here: http://www.ovirt.org/blog/2016/11/ovirt-provider-ovn/ At that time OVN was not directly integrated in oVirt setup. Then I applied the updates in minor releases and coming at 4.1.9 level in late January this year. Now I plan to update to 4.2.3. I have doubts related to OVN setup. Will the new 4.2.3 OVN setup conflict with my current 4.1.x setup? WHat do I have to answer in setup related questions and prompt? In fact now, after enabling 4.2 repo and updating the setup itself, during the procedure (that I Canceled right now) I receive these questions: # engine-setup . . . [ INFO ] Stage: Environment packages setup [ INFO ] Stage: Programs detection [ INFO ] Stage: Environment setup [ INFO ] Stage: Environment customization --== PRODUCT OPTIONS ==-- Configure ovirt-provider-ovn (Yes, No) [Yes]: . . . --== OVIRT ENGINE CONFIGURATION ==-- Perform full vacuum on the engine database engine@localhost? This operation may take a while depending on this setup health and the configuration of the db vacuum process. See https://www.postgresql.org/docs/9.0/static/sql-vacuum.html (Yes, No) [No]: Yes oVirt OVN provider user[admin@internal]: what_to_put_here oVirt OVN provider password: . . . --== CONFIGURATION PREVIEW ==-- Default SAN wipe after delete : False Firewall manager : firewalld Update Firewall : True . . . Set up ovirt-provider-ovn : True . . . Configure VMConsole Proxy : True Please confirm installation settings (OK, Cancel) [OK]: Cancel Thanks for any hint. Gianluca

6 years, 11 months

3
9
0 / 0

oVirt: engine backup

by femi adegoke

Reading this: https://www.ovirt.org/documentation/self-hosted/chap-Backing_up_and_Resto... It says the node must be in maintenance mode. I was having a discussion on IRC & they were using this (see link) to backup, it makes no mention of maint mode https://scottlinux.com/2015/08/20/create-daily-rhevm-backups/ https://access.redhat.com/solutions/797463 Question: must the node be in maint mode before engine is backed up?

6 years, 11 months

2
1
0 / 0

Planned restart of production services

by Evgheni Dereveanchin

Hi everyone, I will be restarting several production systems within the following hour to apply security updates. The following services may be unreachable for some period of time: - www.ovirt.org - project website - resources.ovirt.org - package repositories - gerrit.ovirt.org - code review - jenkins.ovirt.org - CI master It will not be possible to submit/review patches, clone repositories or run CI jobs during this period. Package repositories and the website will also be unreachable for a short period of time. I will announce you once the maintenance is complete. -- Regards, Evgheni Dereveanchin

6 years, 11 months

2
2
0 / 0

Re: hosted-engine ovirt-engine server not run

by dhy336＠sina.com

Hi SimoneI debug my hosted engine, i find my engine block in class InitBackendServicesOnStartupBean -> serviceLoader.load(HostDeviceManager.class); I should how to dubug it? thanks----- Original Message ----- From: <dhy336(a)sina.com> To: "Simone Tiraboschi" <stirabos(a)redhat.com> Cc: users <users(a)ovirt.org> Subject: [ovirt-users] Re: hosted-engine ovirt-engine server not run Date: 2018-05-22 15:07 hi, I try to run my engine, if engine is good run, it has more log info in engine.log than bad run.my bad run engine log miss some info, I should how to dubug this issue? 2018-05-21 17:35:43,446+08 INFO [org.ovirt.engine.core.bll.hostdev.RefreshHostDevicesCommand] (EE-ManagedThreadFactory-engine-Thread-1) [6ced2adb] Running command: RefreshHostDevicesCommand internal: true. Entities affected : ID: 34fa518e-e453-4de2-bd18-4942885c8aa5 Type: VDSAction group MANIPULATE_HOST with role type ADMIN2018-05-21 17:35:43,447+08 INFO [org.ovirt.engine.core.bll.ServiceLoader] (ServerService Thread Pool -- 64) [6ced2adb] Start org.ovirt.engine.core.bll.hostdev.HostDeviceManager@20ad9625 2018-05-21 17:35:43,449+08 INFO [org.ovirt.engine.core.bll.dwh.DwhHeartBeat] (ServerService Thread Pool -- 64) [6ced2adb] Initializing DWH Heart Beat2018-05-21 17:35:43,464+08 INFO [org.ovirt.engine.core.bll.dwh.DwhHeartBeat] (ServerService Thread Pool -- 64) [6ced2adb] DWH Heart Beat initialized2018-05-21 17:35:43,465+08 INFO [org.ovirt.engine.core.bll.ServiceLoader] (ServerService Thread Pool -- 64) [6ced2adb] Start org.ovirt.engine.core.bll.dwh.DwhHeartBeat@75f99d39 2018-05-21 17:35:43,539+08 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ServerService Thread Pool -- 64) [6ced2adb] EVENT_ID: AFFINITY_RULES_ENFORCEMENT_MANAGER_START(10,780), Affinity Rules Enforcement Manager started.2018-05-21 17:35:43,542+08 INFO [org.ovirt.engine.core.bll.ServiceLoader] (ServerService Thread Pool -- 64) [6ced2adb] Start org.ovirt.engine.core.bll.scheduling.AffinityRulesEnforcementManager@703aa6cd 2018-05-21 17:35:43,547+08 INFO [org.ovirt.engine.core.bll.ServiceLoader] (ServerService Thread Pool -- 64) [6ced2adb] Start org.ovirt.engine.core.bll.CertificationValidityChecker@47df0bd8 2018-05-21 17:35:43,554+08 INFO [org.ovirt.engine.core.bll.ServiceLoader] (ServerService Thread Pool -- 64) [6ced2adb] Start org.ovirt.engine.core.bll.hostdeploy.HostUpdatesCheckerService@4dc8896 2018-05-21 17:35:43,556+08 INFO [org.ovirt.engine.core.bll.IPTablesDeprecationNotifier] (ServerService Thread Pool -- 64) [6ced2adb] Start initializing IPTablesDeprecationNotifier2018-05-21 17:35:43,560+08 INFO [org.ovirt.engine.core.bll.IPTablesDeprecationNotifier] (ServerService Thread Pool -- 64) [6ced2adb] Finished initializing IPTablesDeprecationNotifier2018-05-21 17:35:43,560+08 INFO [org.ovirt.engine.core.bll.ServiceLoader] (ServerService Thread Pool -- 64) [6ced2adb] Start org.ovirt.engine.core.bll.IPTablesDeprecationNotifier@46fc7dd7 ----- Original Message ----- From: Simone Tiraboschi <stirabos(a)redhat.com> To: dhy336(a)sina.com Cc: users <users(a)ovirt.org> Subject: Re: [ovirt-users] hosted-engine ovirt-engine server not run Date: 2018-05-21 21:05 On Mon, May 21, 2018 at 12:21 PM, <dhy336(a)sina.com> wrote: Hi I deploy hosted-engine with two nodes, when I power off the node that engine is runing, other node can run VM after about 3 minutes.but ovirt-engine server could not normally run. but systemctrl resetart ovirt-engine. ovirt-engine server can run. this is VM engine logs. Nothing seams bad from that logs.Can you please try reproducing it? _______________________________________________ Users mailing list -- users(a)ovirt.org To unsubscribe send an email to users-leave(a)ovirt.org _______________________________________________ Users mailing list -- users(a)ovirt.org To unsubscribe send an email to users-leave(a)ovirt.org

6 years, 11 months

1
0
0 / 0

Nginx proxy for Ovirt

by Aziz

Hi All, I'm trying to setup nginx as a reverse proxy in order to access ovirt remotely without having to add the fqdn in SSO_ALTERNATE_ENGINE_FQDNS , the idea is that nginx will handle the fqdn translation from my external FQDN (external.fqdn.net ) to ovirt's fqdn (lab.vdi.net). Is there a way to achieve scenario ? Thank you in advance ? Aziz

6 years, 11 months

1
0
0 / 0

Serial pass-through on oVirt VMs

by Joshua Blake

Hello, We have an old Windows XP VM, that requires access to a physical serial port for our telephone system. We have this working in VMWare, however, I'm not entirely sure how we would set this up in oVirt? Can someone help please? Kind Regards, Joshua Blake

6 years, 11 months

3
4
0 / 0

Re: Serial pass-through on oVirt VMs

by Tomáš Golembiovský

adding back the list On Tue, 22 May 2018 16:38:31 +0200 Francesco Romani <fromani(a)redhat.com> wrote: > On 05/22/2018 04:08 PM, Tomáš Golembiovský wrote: > > Hi, > > > > you can try to use VDSM hook to add a dummy serial device to the VM > > domain XML. Or if you really need a physical device then you can use the > > hook to add the <hostdev> element to the domain XML. Don't forget to pin > > the VM to a specific host though. > > Yes, pinning is most likely needed. As per libvirt configuration, there > should be direct libvirt support, maybe predating hostdev: > > https://libvirt.org/formatdomain.html#elementsCharHost > > Bests, > > -- > Francesco Romani > Senior SW Eng., Virtualization R&D > Red Hat > IRC: fromani github: @fromanirh > -- Tomáš Golembiovský <tgolembi(a)redhat.com>

6 years, 11 months

1
0
0 / 0

Use local ansible to talk to engineVM and other vm

by 03ce007＠gmail.com

I have a self-hosted-engine (4.2) running on a centos 7.4 server. I have downloaded ovirt ansible roles from ansible-galaxy and can run them from the server where the engineVM is running and able to deploy new vms, clusters, dc, etc. I have seen the use of ovirt4.py file to target and group hosts which you can target for specific plays. However, the box where self-hosted-engine is running is a physical server but I am looking to run ansible from my local machine instead to manage vms running on engineVM. Is there a way to achieve this? Thank you in advance.

6 years, 11 months

4
4
0 / 0

4.2.3 upgrade with a few errors

by ovirt＠fateknollogee.com

I have attached the logs in case you can find anything The upgrade to all 3 nodes generated a few errors. 1) Had to put node in & out of maintenance a few times before I could get the node to activate. 2) Node 1 upgrade failed. After activating the node, it became unresponsive. I had to login via ipmi to reboot the node. 3) /data-bricks: had 1 unsynced error & one 5 min self-heal Had to put node in & out of maintenance a few times before I could get the node to activate. Thx Femi

6 years, 11 months

2
2
0 / 0

problem to delete snapshot

by Marcelo Leandro

Hello, I had problem when try delete an snapshot. in the gui show this erro: Error while executing action: vm-name: - General command validation failure. when I acess the snapshot tab this vm, the snapshot not show ID disk, not cotain disks in this snapshot. follow the engine and spm logs.

6 years, 11 months

2
3
0 / 0

ovirt 4.1 gluster 3.8 repo no longer exist.

by Edward Clay

While checking for some patches on one of my ovirt systems I found that the ovirt-4.1-dependencies.repo no longer has a 3.8 version available. I see newer versions but not sure if I just need to change the following to point to it or upgrade to 4.2. baseurl=http://mirror.centos.org/centos/7/storage/$basearch/gluster-3.8/ to baseurl=http://mirror.centos.org/centos/7/storage/$basearch/gluster-3.10/ or baseurl=http://mirror.centos.org/centos/7/storage/$basearch/gluster-3.12/ Does anyone have the correct procedure I should follow? Edward Clay Systems Administrator The Hut Group<http://www.thehutgroup.com/> Tel: Email: edward.clay(a)uk2group.com<mailto:edward.clay@uk2group.com> For the purposes of this email, the "company" means The Hut Group Limited, a company registered in England and Wales (company number 6539496) whose registered office is at Fifth Floor, Voyager House, Chicago Avenue, Manchester Airport, M90 3DQ and/or any of its respective subsidiaries. Confidentiality Notice This e-mail is confidential and intended for the use of the named recipient only. If you are not the intended recipient please notify us by telephone immediately on +44(0)1606 811888 or return it to us by e-mail. Please then delete it from your system and note that any use, dissemination, forwarding, printing or copying is strictly prohibited. Any views or opinions are solely those of the author and do not necessarily represent those of the company. Encryptions and Viruses Please note that this e-mail and any attachments have not been encrypted. They may therefore be liable to be compromised. Please also note that it is your responsibility to scan this e-mail and any attachments for viruses. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or confidentiality in relation to transmissions sent by e-mail. Monitoring Activity and use of the company's systems is monitored to secure its effective use and operation and for other lawful business purposes. Communications using these systems will also be monitored and may be recorded to secure effective use and operation and for other lawful business purposes. hgvyjuv

6 years, 11 months

2
1
0 / 0

Re: hosted-engine ovirt-engine server not run

by dhy336＠sina.com

hi, I try to run my engine, if engine is good run, it has more log info in engine.log than bad run.my bad run engine log miss some info, I should how to dubug this issue? 2018-05-21 17:35:43,446+08 INFO [org.ovirt.engine.core.bll.hostdev.RefreshHostDevicesCommand] (EE-ManagedThreadFactory-engine-Thread-1) [6ced2adb] Running command: RefreshHostDevicesCommand internal: true. Entities affected : ID: 34fa518e-e453-4de2-bd18-4942885c8aa5 Type: VDSAction group MANIPULATE_HOST with role type ADMIN2018-05-21 17:35:43,447+08 INFO [org.ovirt.engine.core.bll.ServiceLoader] (ServerService Thread Pool -- 64) [6ced2adb] Start org.ovirt.engine.core.bll.hostdev.HostDeviceManager@20ad9625 2018-05-21 17:35:43,449+08 INFO [org.ovirt.engine.core.bll.dwh.DwhHeartBeat] (ServerService Thread Pool -- 64) [6ced2adb] Initializing DWH Heart Beat2018-05-21 17:35:43,464+08 INFO [org.ovirt.engine.core.bll.dwh.DwhHeartBeat] (ServerService Thread Pool -- 64) [6ced2adb] DWH Heart Beat initialized2018-05-21 17:35:43,465+08 INFO [org.ovirt.engine.core.bll.ServiceLoader] (ServerService Thread Pool -- 64) [6ced2adb] Start org.ovirt.engine.core.bll.dwh.DwhHeartBeat@75f99d39 2018-05-21 17:35:43,539+08 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ServerService Thread Pool -- 64) [6ced2adb] EVENT_ID: AFFINITY_RULES_ENFORCEMENT_MANAGER_START(10,780), Affinity Rules Enforcement Manager started.2018-05-21 17:35:43,542+08 INFO [org.ovirt.engine.core.bll.ServiceLoader] (ServerService Thread Pool -- 64) [6ced2adb] Start org.ovirt.engine.core.bll.scheduling.AffinityRulesEnforcementManager@703aa6cd 2018-05-21 17:35:43,547+08 INFO [org.ovirt.engine.core.bll.ServiceLoader] (ServerService Thread Pool -- 64) [6ced2adb] Start org.ovirt.engine.core.bll.CertificationValidityChecker@47df0bd8 2018-05-21 17:35:43,554+08 INFO [org.ovirt.engine.core.bll.ServiceLoader] (ServerService Thread Pool -- 64) [6ced2adb] Start org.ovirt.engine.core.bll.hostdeploy.HostUpdatesCheckerService@4dc8896 2018-05-21 17:35:43,556+08 INFO [org.ovirt.engine.core.bll.IPTablesDeprecationNotifier] (ServerService Thread Pool -- 64) [6ced2adb] Start initializing IPTablesDeprecationNotifier2018-05-21 17:35:43,560+08 INFO [org.ovirt.engine.core.bll.IPTablesDeprecationNotifier] (ServerService Thread Pool -- 64) [6ced2adb] Finished initializing IPTablesDeprecationNotifier2018-05-21 17:35:43,560+08 INFO [org.ovirt.engine.core.bll.ServiceLoader] (ServerService Thread Pool -- 64) [6ced2adb] Start org.ovirt.engine.core.bll.IPTablesDeprecationNotifier@46fc7dd7 ----- Original Message ----- From: Simone Tiraboschi <stirabos(a)redhat.com> To: dhy336(a)sina.com Cc: users <users(a)ovirt.org> Subject: Re: [ovirt-users] hosted-engine ovirt-engine server not run Date: 2018-05-21 21:05 On Mon, May 21, 2018 at 12:21 PM, <dhy336(a)sina.com> wrote: Hi I deploy hosted-engine with two nodes, when I power off the node that engine is runing, other node can run VM after about 3 minutes.but ovirt-engine server could not normally run. but systemctrl resetart ovirt-engine. ovirt-engine server can run. this is VM engine logs. Nothing seams bad from that logs.Can you please try reproducing it? _______________________________________________ Users mailing list -- users(a)ovirt.org To unsubscribe send an email to users-leave(a)ovirt.org

6 years, 11 months

1
0
0 / 0

ovirt with multiple engines

by Michael Watters

Is it possible to have multiple engines with different versions of ovirt running in the same cluster? I am working on a plan to upgrade our ovirt cluster to the 4.2 release however we would like to have a rollback plan in case there are issues with the new engine.

6 years, 11 months

4
5
0 / 0

gnome keyring and ssh passphrase?

by Gianluca Cecchi

Hello, I'm starting here in F28 to use gnome session again, after some Fedora versions... I was in Mate up to some days ago and the ssh passphrase was in need to be inserted only once in mater-terminal, because I had this in my .bashrc (I think) export SSH_ASKPASS="/usr/bin/ksshaskpass" Now I see that my gnome-terminal continues to ask my passhprase without giving chance to save it into its keyring. I read this https://wiki.gnome.org/Projects/GnomeKeyring/Ssh but I haven't completely understood it (if it is current) It seems gnome-keyring-daemon is running [g.cecchi@ope46 ~]$ ps -ef|grep keyr g.cecchi 1972 1 0 08:44 ? 00:00:13 /usr/bin/gnome-keyring-daemon --daemonize --login g.cecchi 16480 14954 0 15:11 pts/8 00:00:00 grep --color=auto keyr [g.cecchi@ope46 ~]$ but is there any other setting to do not to insert every time my passhrase? Thanks, Gianluca

6 years, 11 months

1
1
0 / 0

hosted-engine ovirt-engine server not run

by dhy336＠sina.com

Hi I deploy hosted-engine with two nodes, when I power off the node that engine is runing, other node can run VM after about 3 minutes.but ovirt-engine server could not normally run. but systemctrl resetart ovirt-engine. ovirt-engine server can run. this is VM engine logs.

6 years, 11 months

2
1
0 / 0

vGPU VM not starting

by Callum Smith

Dear All, Our vGPU installation is progressing, though the VM is failing to start. 2018-05-16 22:57:34,328+0100 ERROR (vm/1bc9dae8) [virt.vm] (vmId='1bc9dae8-a0ea-44b3-9103-5805100648d0') The vm start process failed (vm:943) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 872, in _startUnderlyingVm self._run() File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2872, in _run dom.createWithFlags(flags) File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", line 130, in wrapper ret = f(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 92, in wrapper return func(inst, *args, **kwargs) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1099, in createWithFlags if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', dom=self) libvirtError: Cannot get interface MTU on '': No such device That's the specific error, some other information. It seems the GPU 'allocation' of uuid against the nvidia-xx mdev type is proceeding correctly, and the device is being created by the VM instantiation but the VM does not succeed in going up with this error. Any other logs or information relevant to help diagnose? Regards, Callum -- Callum Smith Research Computing Core Wellcome Trust Centre for Human Genetics University of Oxford e. callum(a)well.ox.ac.uk<mailto:callum@well.ox.ac.uk>

6 years, 11 months

3
4
0 / 0

User & Roles

by Simon Coter

Hi, I'm looking how-to create roles/users and give them access to specific datacenter/host(s). I looked on the documentation but I hadn't been able to find the proper section; anyone that can give me an help ? Thanks Simon

6 years, 11 months

3
3
0 / 0

Preventing users to see other VMs

by Aziz

Hi list, I'm trying to remove the default "everyone" user from Ovirt, so that each user can have access to its own interface to manage a unique VM. I wonder if this is possible, because so far I'm unable to remove everyone user. Thank you

6 years, 11 months

4
11
0 / 0

offsite data replication

by ovirt＠fateknollogee.com

I read somewhere that RHEL 7.5 makes "offsite data replication" easy to do. Is this feature available in oVirt?

6 years, 11 months

2
2
0 / 0

Hosted Engine Setup error (oVirt v4.2.3)

by ovirt＠fateknollogee.com

Engine network config error Following this blog post: https://www.ovirt.org/blog/2018/02/up-and-running-with-ovirt-4-2-and-glus... I get an error saying the hosted engine setup is "trying" to use vibr0 (192.168.xxx.x) even though I have the bridge interface set to "eno1" Regardless of whether the Edit Hosts File is checked or unchecked, it overwrites my engine IP entry from 10.50.235.x to 192.168.xxx.x The same thing happens whether I set the engine IP to Static or DHCP (I don't have DNS, I'm using static entries in /etc/hosts). Any ideas it "insists" on using "vibr0" instead of "eno1"? **also posted this on IRC

6 years, 11 months

5
33
0 / 0

oVirt Gluster storage hardware

by ovirt＠fateknollogee.com

For those folks using SSD with Gluster, are you doing RAID or HBA? Which is recommended for performance. (I've asked this question before, not sure I got a good answer)

6 years, 11 months

1
0
0 / 0

Unable to start VM after 4.2 upgrade

by Ernest Beinrohr

Hi, I updated my engine and 1 host to 4.2 from 4.1 and now I cannot start a VM and get this error: "UnsupportedType: Unsupported {} for ioTune". My other 6 4.1 hosts are able to start VM normally with the new 4.2 engine. My VM has this inside: <iotune read_bytes_sec="0" read_iops_sec="100" total_bytes_sec="0" total_iops_sec="0" write_bytes_sec="0" write_iops_sec="100"/> error: 1. 2018-05-17 14:30:38,006+0200 ERROR (vm/0d53dd5d) [virt.vm] (vmId='0d53dd5d-ef16-4763-bbdc-2dc173087bf5') The vm start process failed (vm:943) 2. Traceback (most recent call last): 3. File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 872, in _startUnderlyingVm 4. self._run() 5. File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2882, in _run 6. self._domDependentInit() 7. File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2458, in _domDependentInit 8. self._vmDependentInit() 9. File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2495, in _vmDependentInit 10. self._sync_metadata() 11. File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 5158, in _sync_metadata 12. self._md_desc.dump(self._dom) 13. File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py", line 509, in dump 14. md_xml = self._build_xml() 15. File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py", line 721, in _build_xml 16. md_elem = self._build_tree(namespace, namespace_uri) 17. File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py", line 711, in _build_tree 18. dev_elem = _dump_device(metadata_obj, data) 19. File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py", line 800, in _dump_device 20. elems.append(_dump_device_spec_params(md_obj, value)) 21. File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py", line 866, in _dump_device_spec_params 22. spec_params_elem = md_obj.dump(_SPEC_PARAMS, **value) 23. File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py", line 229, in dump 24. _keyvalue_to_elem(self._add_ns(key), value, elem) 25. File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py", line 916, in _keyvalue_to_elem 26. raise UnsupportedType(key, value) 27. UnsupportedType: Unsupported {} for ioTune 28. 2018-05-17 14:30:38,006+0200 INFO (vm/0d53dd5d) [virt.vm] (vmId='0d53dd5d-ef16-4763-bbdc-2dc173087bf5') Changed state to Down: Unsupported {} for ioTune (code=1) (vm:1683) 29. 2018-05-17 14:30:38,007+0200 ERROR (vm/0d53dd5d) [root] FINISH thread <Thread(vm/0d53dd5d, stopped daemon 140237644748544)> failed (concurrent:201) 30. Traceback (most recent call last): 31. File "/usr/lib/python2.7/site-packages/vdsm/common/concurrent.py", line 194, in run 32. ret = func(*args, **kwargs) 33. File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 944, in _startUnderlyingVm 34. self.setDownStatus(ERROR, vmexitreason.GENERIC_ERROR, str(e)) 35. File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 1685, in setDownStatus 36. self._update_metadata() 37. File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 5145, in _update_metadata 38. self._sync_metadata() 39. File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 5158, in _sync_metadata 40. self._md_desc.dump(self._dom) 41. File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py", line 509, in dump 42. md_xml = self._build_xml() 43. File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py", line 721, in _build_xml 44. md_elem = self._build_tree(namespace, namespace_uri) 45. File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py", line 711, in _build_tree 46. dev_elem = _dump_device(metadata_obj, data) 47. File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py", line 800, in _dump_device 48. elems.append(_dump_device_spec_params(md_obj, value)) 49. File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py", line 866, in _dump_device_spec_params 50. spec_params_elem = md_obj.dump(_SPEC_PARAMS, **value) 51. File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py", line 229, in dump 52. _keyvalue_to_elem(self._add_ns(key), value, elem) 53. File "/usr/lib/python2.7/site-packages/vdsm/virt/metadata.py", line 916, in _keyvalue_to_elem 54. raise UnsupportedType(key, value) 55. UnsupportedType: Unsupported {} for ioTune

6 years, 11 months

2
3
0 / 0

Upgrade from 4.1.9 to 4.2.3 fails to upgrade postgresql

by Ian Fraser

Hi, Could someone please provide advice on a production oVirt instance that fails to upgrade to 4.2.3? Engine and hosts are all running CentOS 7 As per the upgrade instructions in the release notes I run: # yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release42.rpm # yum update "ovirt-*-setup*" # engine-setup Then I answer the questions and it fails with: ... [ INFO ] Upgrading PostgreSQL [ ERROR ] Failed to execute stage 'Misc configuration': Command '/opt/rh/rh-postgresql95/root/usr/bin/postgresql-setup' failed to execute [ INFO ] Yum Performing yum transaction rollback [ INFO ] Rolling back to the previous PostgreSQL instance (postgresql). [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20180516231622-3giicb.log [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20180516231735-setup.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ ERROR ] Execution of setup failed When I check /var/lib/pgsql/upgrade_rh-postgresql95-postgresql.log: Performing Consistency Checks ----------------------------- Checking cluster versions ok Checking database user is the install user ok Checking database connection settings ok Checking for prepared transactions ok Checking for reg* system OID user data types ok Checking for contrib/isn with bigint-passing mismatch ok Checking for invalid "line" user columns ok Creating dump of global objects ok Creating dump of database schemas engine ovirt_engine_history postgres template1 ok lc_collate values for database "postgres" do not match: old "en_GB.UTF-8", new "en_US.UTF-8" Failure, exiting I have tried running the script here: https://gist.github.com/turboladen/6790847 and rerunning engine-setup but it fails with the same error. Can anyone offer any other suggestions? Best regards Ian Fraser Systems Administrator | Agency Sector Management (UK) Limited | www.asm.org.uk [t] +44 (0)1784 242200 | [f] +44 (0)1784 242012 | [e] Ian.Fraser(a)asm.org.uk Registered in England No. 2053849 | Registered address: Ashford House 41-45 Church Road Ashford Middx TW15 2TQ Follow us on twitter @asmukltd<https://twitter.com/asmukltd>

6 years, 11 months

4
5
0 / 0

Re: Fwd: Re: Re: hosted engine with openvswitch

by Sverker Abrahamsson

Apparently the logs were too big for the mailing list, but should have been received by Petr and Dominik. Let me know if not. What it boils down to, I think, is that the xml sent to libvirt does not have the correct data for openvswitch in interface element, see snippet below. The question is, where should that be set? What I actually want to reach is to have ovirtmgmt network on OVN according to this description "https://gist.github.com/phoracek/ebbd9a6bcfcb14d88f6b463c8dccb27b" so it might be an unnecessary step to get it to work with OVS switch but the content of interface element in xml sent to libvirt is similar so I think an understanding of where it comes from is necessary to troubleshoot that (if needed). /Sverker Den 2018-05-13 kl. 00:23, skrev Sverker Abrahamsson: > Sure, they are attached. The attempt to start the hosted engine vm > occurs at 14:29:42 > > Best regards > Sverker > > Den 2018-05-11 kl. 13:39, skrev Petr Horacek: >> Hi, >> >> would you mind sharing the whole vdsm.log and supervdsm.log? >> >> Thanks, >> Petr >> >> 2018-05-10 22:48 GMT+02:00 Sverker Abrahamsson >> <sverker(a)abrahamsson.com <mailto:sverker@abrahamsson.com>>: >> >> Hi Dominik >> >> Den 2018-05-10 kl. 22:08, skrev Dominik Holler: >> >> On Thu, 10 May 2018 19:15:07 +0200 >> Sverker Abrahamsson <sverker(a)abrahamsson.com >> <mailto:sverker@abrahamsson.com>> wrote: >> >> Hi >> I have a problem with running hosted engine with >> openvswitch. I have >> >> Which version of oVirt? >> >> Ovirt version is 4.2.3.5, vdsm version 4.20.27 >> >> How do you configured hosted engine to use openvswitch? >> Did you follow the steps in >> https://lists.ovirt.org/pipermail/users/2017-March/080748.html >> <https://lists.ovirt.org/pipermail/users/2017-March/080748.html> >> ? >> >> I've followed the same steps as outlined in that mail just that I >> found it when I started to troubleshoot. >> >> one cluster where the ovirt engine runs on the host, >> there it works >> >> What is the switch type of this cluster? >> >> OVS >> >> and when starting a vm the interface definition looks >> like this: >> >> <interface type="bridge"> >> <address bus="0x00" domain="0x0000" >> function="0x0" >> slot="0x03" type="pci" /> >> <mac address="00:1a:4a:16:01:51" /> >> <model type="virtio" /> >> <source bridge="vdsmbr_2XMhqdgD" /> >> <virtualport type="openvswitch" /> >> <filterref filter="vdsm-no-mac-spoofing" /> >> </interface> >> >> Where do you pick up this xml? >> >> From vdsm.log when the vm is created >> >> The xml for that vm as fetched from vdsm does not contain >> virtualport >> >> Where do you pick up this xml, maybe from a logfile or virsh? >> >> vdsm-client VM getInfo vmID=3efc0421-5ad5-4a04-9a0e-30bd8822b299 >> >> tag nor does it use the correct bridge, it looks like this: >> >> <interface type="bridge"> >> <model type="virtio"/> >> <link state="up"/> >> <source bridge="ovirtmgmt"/> >> <address bus="0x00" domain="0x0000" function="0x0" >> slot="0x03" >> type="pci"/> >> <mac address="00:1a:4a:16:01:51"/> >> <filterref filter="vdsm-no-mac-spoofing"/> >> <bandwidth/> >> </interface> >> >> I.e. somewhere the definition is modified to contain the >> correct data >> to work with openvswitch >> >> On the other cluster where I try to run hosted engine I >> don't get the >> >> What is the switch type of this cluster? >> >> In the engine it's set to OVS, but at this point it hasn't >> started yet. Does the host have that setting somewhere? >> >> above behaviour. When the engine vm starts the interface >> settings are >> not modified to use the bridge in openvswitch, with the >> result that >> the vm fails to start: >> >> Can you share the error message from engine.log and vdsm.log, >> and maybe >> supervdsm.log? >> >> These are the error messages when vm fails to start, but it's >> caused by the interface element does not contain virtualport nor >> the correct bridge. >> >> vdsm.log: >> 2018-05-10 22:45:30,562+0200 ERROR (vm/f222c92f) [virt.vm] >> (vmId='f222c92f-91af-4d1c-860d-c2b406211496') The vm start >> process failed (vm:943) >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line >> 872, in _startUnderlyingVm >> self._run() >> File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line >> 2872, in _run >> dom.createWithFlags(flags) >> File >> "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", >> line 130, in wrapper >> ret = f(*args, **kwargs) >> File >> "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line >> 92, in wrapper >> return func(inst, *args, **kwargs) >> File "/usr/lib64/python2.7/site-packages/libvirt.py", line >> 1099, in createWithFlags >> if ret == -1: raise libvirtError ('virDomainCreateWithFlags() >> failed', dom=self) >> libvirtError: Unable to add bridge ovirtmgmt port vnet0: >> Operation not supported >> 2018-05-10 22:45:30,562+0200 INFO (vm/f222c92f) [virt.vm] >> (vmId='f222c92f-91af-4d1c-860d-c2b406211496') Changed state to >> Down: Unable to add bridge ovirtmgmt port vnet0: Operation not >> supported (code=1) >> (vm:1683) >> 2018-05-10 22:45:30,604+0200 INFO (vm/f222c92f) [virt.vm] >> (vmId='f222c92f-91af-4d1c-860d-c2b406211496') Stopping connection >> (guestagent:438) >> >> It's the hosted engine vm that fails to start, hence I don't have >> any engine.log and supervdsm.log doesn't contain anything about this >> >> <interface type="bridge"> >> <model type="virtio"/> >> <link state="up"/> >> <source bridge="ovirtmgmt"/> >> <alias >> name="ua-430d692e-6ef0-4529-8af0-b37a53a11564"/> >> <address bus="0x00" domain="0x0000" >> function="0x0" >> slot="0x03" type="pci"/> >> <mac address="00:16:3e:0e:39:42"/> >> <filterref filter="vdsm-no-mac-spoofing"/> >> <bandwidth/> >> </interface> >> >> Last login: Thu May 10 16:23:48 2018 from 172.27.1.32 >> [root@h2 ~]# ovs-vsctl show >> dfcf7463-ce51-4115-9a3a-ecab9efa8146 >> Bridge "vdsmbr_H91hH5sG" >> Port "vdsmbr_H91hH5sG" >> Interface "vdsmbr_H91hH5sG" >> type: internal >> Port ovirtmgmt >> Interface ovirtmgmt >> type: internal >> Port "dummy0" >> Interface "dummy0" >> ovs_version: "2.9.0" >> >> I assumed first there is a hook that make the needed >> change, but the >> only hooks I can find that mentions openvswitch are >> ovirt_provider_ovn_hook and 50_openstacknet but both >> those would set >> the source bridge to br-int and not look up the dynamic >> name of the >> bridge as created by vdsm. >> >> One special thing about the host where I try to run >> hosted engine is >> that the there is a dummy port since otherwise I couldn't >> get vdsm to >> create the bridge, but that shouldn't affect changing the >> interface >> definition for the vm. >> >> Where should I look next? >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org >> <mailto:users@ovirt.org> >> To unsubscribe send an email to users-leave(a)ovirt.org >> <mailto:users-leave@ovirt.org> >> >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org <mailto:users@ovirt.org> >> To unsubscribe send an email to users-leave(a)ovirt.org >> <mailto:users-leave@ovirt.org> >> >> >

6 years, 11 months

1
1
0 / 0

HE LUN change

by Arsène Gschwind

Hi, We are running HE on a separate FC LUN on a storage system which needs to be replaced, what would be the best method to move / copy that LUN to another FC LUN? Do we need to redeploy HE with backup/restore DB? Thanks for any hint. regards, Arsène -- Arsène Gschwind Fa. Sapify AG im Auftrag der Universität Basel IT Services Klingelbergstr. 70 | CH-4056 Basel | Switzerland Tel. +41 79 449 25 63 | http://its.unibas.ch <http://its.unibas.ch/> ITS-ServiceDesk: support-its(a)unibas.ch<mailto:support-its@unibas.ch> | +41 61 267 14 11

6 years, 11 months

2
3
0 / 0

Re: oVirt 4.2.3. iso question

by Joshua Blake

Hello, The SSH service should automatically start on boot. In your network configuration file in /etc/sysconfig/network-scripts/, do you have the line 'ONBOOT=yes'? Kind Regards, Joshua Blake On 16/05/2018 19:58, users-request(a)ovirt.org wrote: > Send Users mailing list submissions to > users(a)ovirt.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > users-request(a)ovirt.org > > You can reach the person managing the list at > users-owner(a)ovirt.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Users digest..." > > Today's Topics: > > 1. oVirt 4.2.3. iso question (ovirt(a)fateknollogee.com) > 2. Re: adding a host (Justin Zygmont) > > > ---------------------------------------------------------------------- > > Date: Wed, 16 May 2018 11:02:42 -0700 > From: ovirt(a)fateknollogee.com > Subject: [ovirt-users] oVirt 4.2.3. iso question > To: users(a)ovirt.org > Message-ID: <1fb9515bf0c5bc87ab1a6aa879c3c38b(a)fateknollogee.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > Downloaded "ovirt-node-ng-installer-ovirt-4.2-2018051606.iso" from > http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-4.2_build-artifacts-el7-... > > After rebooting any node, even though they all have valid IP addresses, > I can not connect (via SSH) to any node unless I "systemctl restart > network.service" > > Maybe I'm using the wrong iso? > > ------------------------------ > > Date: Wed, 16 May 2018 18:58:14 +0000 > From: Justin Zygmont <jzygmont(a)proofpoint.com> > Subject: [ovirt-users] Re: adding a host > To: Alona Kaplan <alkaplan(a)redhat.com> > Cc: "users(a)ovirt.org" <users(a)ovirt.org> > Message-ID: <CY4PR12MB1798DBD078B4054BA0C43EC4AB920(a)CY4PR12MB1798.namp > rd12.prod.outlook.com> > Content-Type: multipart/alternative; boundary="_000_CY4PR12MB1798DB > D078B4054BA0C43EC4AB920CY4PR12MB1798namp_" > > --_000_CY4PR12MB1798DBD078B4054BA0C43EC4AB920CY4PR12MB1798namp_ > Content-Type: text/plain; charset="utf-8" > Content-Transfer-Encoding: base64 > > TG9va3MgbGlrZSBJIGp1c3QgbWlzc2VkIHNlbGVjdGluZyB0aGUgSG9zdGVkIEVuZ2luZSB0YWIs > IEkgaGFkIHRvIHJlbW92ZSBhbmQgYWRkIGJhY2sgdGhlIGhvc3QsIGl0IHdvcmtzIG5vdy4NCg0K > DQoNCkZyb206IEp1c3RpbiBaeWdtb250DQpTZW50OiBUdWVzZGF5LCBNYXkgMTUsIDIwMTggNTo1 > NyBQTQ0KVG86IEFsb25hIEthcGxhbiA8YWxrYXBsYW5AcmVkaGF0LmNvbT4NCkNjOiBZYW5pciBR > dWlubiA8eXF1aW5uQHJlZGhhdC5jb20+OyB1c2Vyc0BvdmlydC5vcmcNClN1YmplY3Q6IFJFOiBb > b3ZpcnQtdXNlcnNdIGFkZGluZyBhIGhvc3QNCg0KSSByZWluc3RhbGxlZCB3aXRoIHRoZSBsYXRl > c3QgNC4yLjMgYW5kIEkgZ290IGl0IHRvIHdvcmsgdGhpcyB0aW1lLiAgU29tZSB0aGluZ3MgSSBu > b3RpY2VkLCBJIGhhdmUgdG8gYWRkIHRoZSB2bGFucyB0byB0aGUgbmV3IGhvc3QgbWFudWFsbHkg > b3IgaXQgc3RheXMgbm9uLW9wZXJhdGlvbmFsLCBhbmQgSSBjYW7igJl0IG1pZ3JhdGUgdGhlIGhv > c3RlZCBlbmdpbmUgdG8gdGhlIG90aGVyIGhvc3QsIEkgZ2V0Og0KRXJyb3Igd2hpbGUgZXhlY3V0 > aW5nIGFjdGlvbjogQ2Fubm90IHN3aXRjaCB0aGUgSG9zdChzKSB0byBNYWludGVuYW5jZSBtb2Rl > Lg0KVGhlcmUgYXJlIG5vIGF2YWlsYWJsZSBob3N0cyBjYXBhYmxlIG9mIHJ1bm5pbmcgdGhlIGVu > Z2luZSBWTS4NCg0KDQoNCkZyb206IEFsb25hIEthcGxhbiBbbWFpbHRvOmFsa2FwbGFuQHJlZGhh > dC5jb21dDQpTZW50OiBTdW5kYXksIE1heSA2LCAyMDE4IDExOjI1IFBNDQpUbzogSnVzdGluIFp5 > Z21vbnQgPGp6eWdtb250QHByb29mcG9pbnQuY29tPG1haWx0bzpqenlnbW9udEBwcm9vZnBvaW50 > LmNvbT4+DQpDYzogWWFuaXIgUXVpbm4gPHlxdWlubkByZWRoYXQuY29tPG1haWx0bzp5cXVpbm5A > cmVkaGF0LmNvbT4+OyB1c2Vyc0BvdmlydC5vcmc8bWFpbHRvOnVzZXJzQG92aXJ0Lm9yZz4NClN1 > YmplY3Q6IFJlOiBbb3ZpcnQtdXNlcnNdIGFkZGluZyBhIGhvc3QNCg0KRmlyc3QgcmVzdGFydCB0 > aGUgZW5naW5lLiBUaGVuIHRyeSB0byBjaGFuZ2UgdGhlIHJlcXVpcmVkIG5ldHdvcmsgdG8gYmUg > bm9uLXJlcXVpcmVkIGFuZCBjbGljayBvbiBSZWZyZXNoQ2FwYWJpbGl0aWVzIG9uIHRoZSBob3N0 > Lg0KSXQgc2hvdWxkIG1vdmUgdGhlIGhvc3QgdG8gYWN0aXZlIHN0YXRlIHdpdGhvdXQgdGhlIG5l > ZWQgdG8gcmVtb3ZlIGl0Lg0KSWYgaXQgZG9lc24ndCBoZWxwLCBwbGVhc2UgYXR0YWNoIHlvdXIg > ZnVsbCBlbmdpbmUubG9nIGFuZCBzZXJ2ZXIubG9nLg0KDQpBbnl3YXkgcGxlYXNlIHVwZGF0ZSB5 > b3VyIG92aXJ0IHRvIHZlcnNpb24gNC4yLjMuNCwgdGhlIGJ1ZyB3YXMgZml4ZWQgdGhlcmUuDQoN > ClRoYW5rcywNCkFsb25hLg0KDQpPbiBNb24sIE1heSA3LCAyMDE4IGF0IDc6MzAgQU0sIEp1c3Rp > biBaeWdtb250IDxqenlnbW9udEBwcm9vZnBvaW50LmNvbTxtYWlsdG86anp5Z21vbnRAcHJvb2Zw > b2ludC5jb20+PiB3cm90ZToNCknigJl2ZSBkZXNlbGVjdCB0aGUgcmVxdWlyZWQgc3RhdHVzLCBJ > IHdpbGwgdHJ5IHRvIGFkZCBpdCBhZ2FpbiBpZiBJIGFtIGV2ZXIgYWJsZSB0byByZW1vdmUgdGhl > IG9sZCBob3N0Lg0KDQoNCkZyb206IEFsb25hIEthcGxhbiBbbWFpbHRvOmFsa2FwbGFuQHJlZGhh > dC5jb208bWFpbHRvOmFsa2FwbGFuQHJlZGhhdC5jb20+XQ0KU2VudDogU3VuZGF5LCBNYXkgNiwg > MjAxOCA3OjMxIEFNDQpUbzogWWFuaXIgUXVpbm4gPHlxdWlubkByZWRoYXQuY29tPG1haWx0bzp5 > cXVpbm5AcmVkaGF0LmNvbT4+DQpDYzogSnVzdGluIFp5Z21vbnQgPGp6eWdtb250QHByb29mcG9p > bnQuY29tPG1haWx0bzpqenlnbW9udEBwcm9vZnBvaW50LmNvbT4+OyB1c2Vyc0BvdmlydC5vcmc8 > bWFpbHRvOnVzZXJzQG92aXJ0Lm9yZz4NCg0KU3ViamVjdDogUmU6IFtvdmlydC11c2Vyc10gYWRk > aW5nIGEgaG9zdA0KDQpUaGVyZSB3YXMgYSBidWcgd2hlbiBhZGRpbmcgYSBob3N0IHRvIGEgY2x1 > c3RlciB0aGF0IGNvbnRhaW5zIGEgcmVxdWlyZWQgbmV0d29yay4gSXQgd2FzIGZpeGVkIGluIDQu > Mi4zLjQuDQpCdWctVXJsLSBodHRwczovL2J1Z3ppbGxhLnJlZGhhdC5jb20vMTU3MDM4ODxodHRw > czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2J1Z3ppbGxh > LnJlZGhhdC5jb21fMTU3MDM4OCZkPUR3TUZhUSZjPVZ4dDVlME9zdnZ0MmdmbHdTbHNKNURtUEdj > UHZUUktMSnlwMDMxclhqaGcmcj1GaVBoTDBDbDF5bVpsblR5QUlJTDc1dEU0TDByZUhjRGRELTd3 > VXRVR0hBJm09YmYtT28xNGZCd0dOaG55c25XbFQ1Tk05VnUwUFZKTkJDaDdlTVpJT2tqUSZzPW1m > bjBwbm1uQUJFRm51WHNmYjBfOFVKX3Q5ck9nN3pwbGNFZXNFdUZZMXMmZT0+DQoNClRoYW5rcywN > CkFsb25hLg0KDQpPbiBTdW4sIE1heSA2LCAyMDE4IGF0IDM6NDkgUE0sIFlhbmlyIFF1aW5uIDx5 > cXVpbm5AcmVkaGF0LmNvbTxtYWlsdG86eXF1aW5uQHJlZGhhdC5jb20+PiB3cm90ZToNCkZvciBy > ZW1vdmluZyB0aGUgbm9uIG9wZXJhdGlvbmFsIGhvc3QgOg0KMS5SaWdodCBjbGljayBvbiB0aGUg > aG9zdCBuYW1lDQoyLkNsaWNrIG9uICAiQ29uZmlybSBob3N0IGhhcyBiZWVuIHJlYm9vdGVkIg0K > My5SZW1vdmUgdGhlIGhvc3QNCg0KDQpGb3IgdGhlIGlzc3VlIHlvdSBhcmUgZXhwZXJpZW5jaW5n > IHdpdGggaG9zdCBhZGRpdGlvbiwgYWNjb3JkaW5nIHRvIHRoZSBlbmdpbmUgbG9ncyB5b3UgaGF2 > ZSBzZW50LCB5b3UgbWlnaHQgbmVlZCB0byBwZXJmb3JtIGEgZmV3IHN0ZXBzICwgIHNlZToNCmh0 > dHBzOi8vYnVnemlsbGEucmVkaGF0LmNvbS9zaG93X2J1Zy5jZ2k/aWQ9MTUxNjI1NiNjMjxodHRw > czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2J1Z3ppbGxh > LnJlZGhhdC5jb21fc2hvdy01RmJ1Zy5jZ2ktM0ZpZC0zRDE1MTYyNTYtMjNjMiZkPUR3TUZhUSZj > PVZ4dDVlME9zdnZ0MmdmbHdTbHNKNURtUEdjUHZUUktMSnlwMDMxclhqaGcmcj1GaVBoTDBDbDF5 > bVpsblR5QUlJTDc1dEU0TDByZUhjRGRELTd3VXRVR0hBJm09YmYtT28xNGZCd0dOaG55c25XbFQ1 > Tk05VnUwUFZKTkJDaDdlTVpJT2tqUSZzPTIyeGdlajRLUndEVE1CUGZTMDNuakdtNW1KNEk5NkpM > bFVZLWk3blRxNVkmZT0+DQpJIHdvdWxkIGFsc28gcmVjb21tZW5kIHRvIGNoZWNrIHRoZSB0aGUg > aG9zdCdzIG5ldHdvcmsgaXMgbm90IGRvd24uDQpBbHNvLCBkdXJpbmcgaW5zdGFsbGF0aW9uIG9m > IHRoZSBob3N0LG9ic2VydmUgdGhlIG1lc3NhZ2VzIGluIHRoZSBFdmVudHMgc2VjdGlvbiAoVUkp > DQpIb3BlIHRoaXMgaGVscHMuDQoNCg0KDQoNCk9uIFRodSwgTWF5IDMsIDIwMTggYXQgMTA6MDcg > UE0sIEp1c3RpbiBaeWdtb250IDxqenlnbW9udEBwcm9vZnBvaW50LmNvbTxtYWlsdG86anp5Z21v > bnRAcHJvb2Zwb2ludC5jb20+PiB3cm90ZToNCkkgY2Fu4oCZdCBzZWVtIHRvIGRvIGFueXRoaW5n > IHRvIGNvbnRyb2wgdGhlIGhvc3QgZnJvbSB0aGUgZW5naW5lLCB3aGVuIEkgc2VsZWN0IGl0IGZv > ciBNYWludCwgdGhlIGVuZ2luZSBsb2cgc2hvd3M6DQoNCltvcmcub3ZpcnQuZW5naW5lLmNvcmUu > YmxsLk1haW50ZW5hbmNlTnVtYmVyT2ZWZHNzQ29tbWFuZF0gKGRlZmF1bHQgdGFzay01MCkgWzkw > YmE4MWVmLTIxZTQtNDI3Mi04YzU5LTg0Nzg2ZTk2OWZmN10gUnVubmluZyBjb21tYW5kOiBNYWlu > dGVuYW5jZU51bWJlck9mVmRzc0NvbW1hbmQgaW50ZXJuYWw6IGZhbHNlLiBFbnRpdGllcyBhZmZl > Y3RlZCA6ICBJRDogNzRkZmU5NjUtY2IxMS00OTVhLTk2YTAtM2RhZTZiM2NiZDc1IFR5cGU6IFZE > U0FjdGlvbiBncm91cCBNQU5JUFVMQVRFX0hPU1Qgd2l0aCByb2xlIHR5cGUgQURNSU4NCjIwMTgt > MDUtMDMgMTI6MDA6MzcsOTE4LTA3IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJv > a2VyLlNldFZkc1N0YXR1c1ZEU0NvbW1hbmRdIChkZWZhdWx0IHRhc2stNTApIFs5MGJhODFlZi0y > MWU0LTQyNzItOGM1OS04NDc4NmU5NjlmZjddIFNUQVJULCBTZXRWZHNTdGF0dXNWRFNDb21tYW5k > KEhvc3ROYW1lID0gb3Zub2RlMTAyLCBTZXRWZHNTdGF0dXNWRFNDb21tYW5kUGFyYW1ldGVyczp7 > aG9zdElkPSc3NGRmZTk2NS1jYjExLTQ5NWEtOTZhMC0zZGFlNmIzY2JkNzUnLCBzdGF0dXM9J1By > ZXBhcmluZ0Zvck1haW50ZW5hbmNlJywgbm9uT3BlcmF0aW9uYWxSZWFzb249J05PTkUnLCBzdG9w > U3BtRmFpbHVyZUxvZ2dlZD0ndHJ1ZScsIG1haW50ZW5hbmNlUmVhc29uPSdudWxsJ30pLCBsb2cg > aWQ6IDY0N2Q1Zjc4DQoNCg0KSSBoYXZlIG9ubHkgMSBob3N0IGluIHRoZSBEQywgc3RhdHVzIGlz > IFVwLCB0aGUgY2x1c3RlciBzYXlzIGhvc3QgY291bnQgaXMgMiBldmVuIHRob3VnaCB0aGUgc2Vj > b25kIGhvc3Qgc3RheXMgTm9uIE9wZXJhdGlvbmFsLiAgSSBkb27igJl0IGtub3cgaG93IHRvIHJl > bW92ZSBpdC4NCkkganVzdCBpbnN0YWxsZWQgYW5kIHRyaWVkIHRvIGpvaW4gdGhlIERDLCB0aGlz > IGlzIGEgZnJlc2ggaW5zdGFsbGF0aW9uLCB0aGUgZW5naW5lIHdhcyBsYXVuY2hlZCB0aHJvdWdo > IGNvY2twaXQuDQoNCkhlcmVzIHdoYXQgbm9kZWN0bCBzaG93cyBmcm9tIHRoZSBob3N0Og0KDQpv > dm5vZGUxMDIgfl0jIG5vZGVjdGwgY2hlY2sNClN0YXR1czogT0sNCkJvb3Rsb2FkZXIgLi4uIE9L > DQogIExheWVyIGJvb3QgZW50cmllcyAuLi4gT0sNCiAgVmFsaWQgYm9vdCBlbnRyaWVzIC4uLiBP > Sw0KTW91bnQgcG9pbnRzIC4uLiBPSw0KICBTZXBhcmF0ZSAvdmFyIC4uLiBPSw0KICBEaXNjYXJk > IGlzIHVzZWQgLi4uIE9LDQpCYXNpYyBzdG9yYWdlIC4uLiBPSw0KICBJbml0aWFsaXplZCBWRyAu > Li4gT0sNCiAgSW5pdGlhbGl6ZWQgVGhpbiBQb29sIC4uLiBPSw0KICBJbml0aWFsaXplZCBMVnMg > Li4uIE9LDQpUaGluIHN0b3JhZ2UgLi4uIE9LDQogIENoZWNraW5nIGF2YWlsYWJsZSBzcGFjZSBp > biB0aGlucG9vbCAuLi4gT0sNCiAgQ2hlY2tpbmcgdGhpbnBvb2wgYXV0by1leHRlbmQgLi4uIE9L > DQp2ZHNtZCAuLi4gT0sNCg0KDQoNClRoYW5rcywNCg0KDQpGcm9tOiBZYW5pciBRdWlubiBbbWFp > bHRvOnlxdWlubkByZWRoYXQuY29tPG1haWx0bzp5cXVpbm5AcmVkaGF0LmNvbT5dDQpTZW50OiBU > aHVyc2RheSwgTWF5IDMsIDIwMTggMToxOSBBTQ0KDQpUbzogSnVzdGluIFp5Z21vbnQgPGp6eWdt > b250QHByb29mcG9pbnQuY29tPG1haWx0bzpqenlnbW9udEBwcm9vZnBvaW50LmNvbT4+DQpDYzog > dXNlcnNAb3ZpcnQub3JnPG1haWx0bzp1c2Vyc0BvdmlydC5vcmc+DQpTdWJqZWN0OiBSZTogW292 > aXJ0LXVzZXJzXSBhZGRpbmcgYSBob3N0DQoNCkRpZCB5b3UgdHJ5IHN3aXRjaGluZyB0aGUgaG9z > dCB0byBtYWludGVuYW5jZSBtb2RlIGZpcnN0ID8NCldoYXQgaXMgdGhlIHN0YXRlIG9mIHRoZSBk > YXRhIGNlbnRlciBhbmQgaG93IG1hbnkgYWN0aXZlIGhvc3RzIGRvIHlvdSBoYXZlIG5vdz8NCkFu > ZCBkaWQgeW91IHBlcmZvcm0gYW55IHVwZGF0ZXMgcmVjZW50bHkgb3IganVzdCBydW4gYSBmcmVz > aCBpbnN0YWxsYXRpb24gPyAgaWYgc28gLCBkaWQgeW91IHJ1biBlbmdpbmUtc2V0dXAgYmVmb3Jl > IGxhdW5jaGluZyBlbmdpbmUgPw0KDQpPbiBUaHUsIE1heSAzLCAyMDE4IGF0IDEyOjQ3IEFNLCBK > dXN0aW4gWnlnbW9udCA8anp5Z21vbnRAcHJvb2Zwb2ludC5jb208bWFpbHRvOmp6eWdtb250QHBy > b29mcG9pbnQuY29tPj4gd3JvdGU6DQpJIHJlYWQgdGhpcyBwYWdlIGFuZCBpdCBkb2VzbuKAmXQg > aGVscCBzaW5jZSB0aGlzIGlzIGEgaG9zdCB0aGF0IGNhbuKAmXQgYmUgcmVtb3ZlZCwgdGhlIOKA > nHJlbW92ZeKAnSBidXR0b24gaXMgZGltbWVkIG91dC4NCg0KVGhpcyBpcyA0LjIyIG92aXJ0IG5v > ZGUsIGJ1dCB0aGUgaG9zdCBzdGF5cyBpbiBhIOKAnG5vbiBvcGVyYXRpb25hbOKAnSBzdGF0ZS4g > IEkgbm90aWNlIHRoZSBsb2dzIGhhdmUgYSBsb3Qgb2YgZXJyb3JzLCBmb3IgZXhhbXBsZToNCg0K > DQp0aGUgU0VSVkVSIGxvZzoNCg0KMjAxOC0wNS0wMiAxNDo0MDoyMyw4NDctMDcgV0FSTiAgW29y > Zy5qYm9zcy5qY2EuY29yZS5jb25uZWN0aW9ubWFuYWdlci5wb29sLnN0cmF0ZWd5Lk9uZVBvb2xd > IChGb3JrSm9pblBvb2wtMS13b3JrZXItMTQpIElKMDAwNjA5OiBBdHRlbXB0IHRvIHJldHVybiBj > b25uZWN0aW9uIHR3aWNlOiBvcmcuamJvc3MuamNhLmNvcmUuY29ubmVjdGlvbm1hbmFnZXIubGlz > dGVuZXIuVHhDb25uZWN0aW9uTGlzdGVuZXJAMWZhYjg0ZDdbc3RhdGU9Tk9STUFMPG1haWx0bzpv > cmcuamJvc3MuamNhLmNvcmUuY29ubmVjdGlvbm1hbmFnZXIubGlzdGVuZXIuVHhDb25uZWN0aW9u > TGlzdGVuZXJAMWZhYjg0ZDdbc3RhdGU9Tk9STUFMPiBtYW5hZ2VkIGNvbm5lY3Rpb249b3JnLmpi > b3NzLmpjYS5hZGFwdGVycy5qZGJjLmxvY2FsLkxvY2FsTWFuYWdlZENvbm5lY3Rpb25AM2YzN2Nm > MTA8bWFpbHRvOmNvbm5lY3Rpb249b3JnLmpib3NzLmpjYS5hZGFwdGVycy5qZGJjLmxvY2FsLkxv > Y2FsTWFuYWdlZENvbm5lY3Rpb25AM2YzN2NmMTA+IGNvbm5lY3Rpb24gaGFuZGxlcz0wIGxhc3RS > ZXR1cm5lZD0xNTI1Mjk3MjIzODQ3IGxhc3RWYWxpZGF0ZWQ9MTUyNTI5MDI2NzgxMSBsYXN0Q2hl > Y2tlZE91dD0xNTI1Mjk2OTIzNzcwIHRyYWNrQnlUeD1mYWxzZSBwb29sPW9yZy5qYm9zcy5qY2Eu > Y29yZS5jb25uZWN0aW9ubWFuYWdlci5wb29sLnN0cmF0ZWd5Lk9uZVBvb2xAMjA1NTBmMzU8bWFp > bHRvOnBvb2w9b3JnLmpib3NzLmpjYS5jb3JlLmNvbm5lY3Rpb25tYW5hZ2VyLnBvb2wuc3RyYXRl > Z3kuT25lUG9vbEAyMDU1MGYzNT4gbWNwPVNlbWFwaG9yZUNvbmN1cnJlbnRMaW5rZWRRdWV1ZU1h > bmFnZWRDb25uZWN0aW9uUG9vbEA1YmFhOTBmW3Bvb2w9RU5HSU5FRGF0YVNvdXJjZV0geGFSZXNv > dXJjZT1Mb2NhbFhBUmVzb3VyY2VJbXBsQDI0YTdmYzBiW2Nvbm5lY3Rpb25MaXN0ZW5lcj0xZmFi > ODRkNyBjb25uZWN0aW9uTWFuYWdlcj01YmVjNzBkMiB3YXJuZWQ9ZmFsc2UgY3VycmVudFhpZD1u > dWxsIHByb2R1Y3ROYW1lPVBvc3RncmVTUUwgcHJvZHVjdFZlcnNpb249OS41Ljkgam5kaU5hbWU9 > amF2YTovRU5HSU5FRGF0YVNvdXJjZV0gdHhTeW5jPW51bGxdOiBqYXZhLmxhbmcuVGhyb3dhYmxl > OiBTVEFDS1RSQUNFDQogICAgICAgIGF0IG9yZy5qYm9zcy5qY2EuY29yZS5jb25uZWN0aW9ubWFu > YWdlci5wb29sLm1jcC5TZW1hcGhvcmVDb25jdXJyZW50TGlua2VkRGVxdWVNYW5hZ2VkQ29ubmVj > dGlvblBvb2wucmV0dXJuQ29ubmVjdGlvbihTZW1hcGhvcmVDb25jdXJyZW50TGlua2VkRGVxdWVN > YW5hZ2VkQ29ubmVjdGlvblBvb2wuamF2YTo3MjIpDQogICAgICAgIGF0IG9yZy5qYm9zcy5qY2Eu > Y29yZS5jb25uZWN0aW9ubWFuYWdlci5wb29sLm1jcC5TZW1hcGhvcmVDb25jdXJyZW50TGlua2Vk > RGVxdWVNYW5hZ2VkQ29ubmVjdGlvblBvb2wucmV0dXJuQ29ubmVjdGlvbihTZW1hcGhvcmVDb25j > dXJyZW50TGlua2VkRGVxdWVNYW5hZ2VkQ29ubmVjdGlvblBvb2wuamF2YTo2MTEpDQogICAgICAg > IGF0IG9yZy5qYm9zcy5qY2EuY29yZS5jb25uZWN0aW9ubWFuYWdlci5wb29sLkFic3RyYWN0UG9v > bC5yZXR1cm5Db25uZWN0aW9uKEFic3RyYWN0UG9vbC5qYXZhOjg0NykNCiAgICAgICAgYXQgb3Jn > Lmpib3NzLmpjYS5jb3JlLmNvbm5lY3Rpb25tYW5hZ2VyLkFic3RyYWN0Q29ubmVjdGlvbk1hbmFn > ZXIucmV0dXJuTWFuYWdlZENvbm5lY3Rpb24oQWJzdHJhY3RDb25uZWN0aW9uTWFuYWdlci5qYXZh > OjcyNSkNCiAgICAgICAgYXQgb3JnLmpib3NzLmpjYS5jb3JlLmNvbm5lY3Rpb25tYW5hZ2VyLnR4 > LlR4Q29ubmVjdGlvbk1hbmFnZXJJbXBsLm1hbmFnZWRDb25uZWN0aW9uRGlzY29ubmVjdGVkKFR4 > Q29ubmVjdGlvbk1hbmFnZXJJbXBsLmphdmE6NTg1KQ0KICAgICAgICBhdCBvcmcuamJvc3MuamNh > LmNvcmUuY29ubmVjdGlvbm1hbmFnZXIuQWJzdHJhY3RDb25uZWN0aW9uTWFuYWdlci5kaXNjb25u > ZWN0TWFuYWdlZENvbm5lY3Rpb24oQWJzdHJhY3RDb25uZWN0aW9uTWFuYWdlci5qYXZhOjk4OCkN > CiAgICAgICAgYXQgb3JnLmpib3NzLmpjYS5jb3JlLmNvbm5lY3Rpb25tYW5hZ2VyLkFic3RyYWN0 > Q29ubmVjdGlvbk1hbmFnZXIucmVjb25uZWN0TWFuYWdlZENvbm5lY3Rpb24oQWJzdHJhY3RDb25u > ZWN0aW9uTWFuYWdlci5qYXZhOjk3NCkNCiAgICAgICAgYXQgb3JnLmpib3NzLmpjYS5jb3JlLmNv > bm5lY3Rpb25tYW5hZ2VyLkFic3RyYWN0Q29ubmVjdGlvbk1hbmFnZXIuYWxsb2NhdGVDb25uZWN0 > aW9uKEFic3RyYWN0Q29ubmVjdGlvbk1hbmFnZXIuamF2YTo3OTIpDQogICAgICAgIGF0IG9yZy5q > Ym9zcy5qY2EuYWRhcHRlcnMuamRiYy5XcmFwcGVyRGF0YVNvdXJjZS5nZXRDb25uZWN0aW9uKFdy > YXBwZXJEYXRhU291cmNlLmphdmE6MTM4KQ0KICAgICAgICBhdCBvcmcuamJvc3MuYXMuY29ubmVj > dG9yLnN1YnN5c3RlbXMuZGF0YXNvdXJjZXMuV2lsZEZseURhdGFTb3VyY2UuZ2V0Q29ubmVjdGlv > bihXaWxkRmx5RGF0YVNvdXJjZS5qYXZhOjY0KQ0KICAgICAgICBhdCBvcmcuc3ByaW5nZnJhbWV3 > b3JrLmpkYmMuZGF0YXNvdXJjZS5EYXRhU291cmNlVXRpbHMuZG9HZXRDb25uZWN0aW9uKERhdGFT > b3VyY2VVdGlscy5qYXZhOjExMSkgW3NwcmluZy1qZGJjLmphcjo0LjMuOS5SRUxFQVNFXQ0KICAg > ICAgICBhdCBvcmcuc3ByaW5nZnJhbWV3b3JrLmpkYmMuZGF0YXNvdXJjZS5EYXRhU291cmNlVXRp > bHMuZ2V0Q29ubmVjdGlvbihEYXRhU291cmNlVXRpbHMuamF2YTo3NykgW3NwcmluZy1qZGJjLmph > cjo0LjMuOS5SRUxFQVNFXQ0KICAgICAgICBhdCBvcmcuc3ByaW5nZnJhbWV3b3JrLmpkYmMuY29y > ZS5KZGJjVGVtcGxhdGUuZXhlY3V0ZShKZGJjVGVtcGxhdGUuamF2YTo2MTkpIFtzcHJpbmctamRi > Yy5qYXI6NC4zLjkuUkVMRUFTRV0NCiAgICAgICAgYXQgb3JnLnNwcmluZ2ZyYW1ld29yay5qZGJj > LmNvcmUuSmRiY1RlbXBsYXRlLnF1ZXJ5KEpkYmNUZW1wbGF0ZS5qYXZhOjY4NCkgW3NwcmluZy1q > ZGJjLmphcjo0LjMuOS5SRUxFQVNFXQ0KICAgICAgICBhdCBvcmcuc3ByaW5nZnJhbWV3b3JrLmpk > YmMuY29yZS5KZGJjVGVtcGxhdGUucXVlcnkoSmRiY1RlbXBsYXRlLmphdmE6NzE2KSBbc3ByaW5n > LWpkYmMuamFyOjQuMy45LlJFTEVBU0VdDQogICAgICAgIGF0IG9yZy5zcHJpbmdmcmFtZXdvcmsu > amRiYy5jb3JlLkpkYmNUZW1wbGF0ZS5xdWVyeShKZGJjVGVtcGxhdGUuamF2YTo3NjYpIFtzcHJp > bmctamRiYy5qYXI6NC4zLjkuUkVMRUFTRV0NCiAgICAgICAgYXQgb3JnLm92aXJ0LmVuZ2luZS5j > b3JlLmRhbC5kYmJyb2tlci5Qb3N0Z3Jlc0RiRW5naW5lRGlhbGVjdCRQb3N0Z3Jlc1NpbXBsZUpk > YmNDYWxsLmV4ZWN1dGVDYWxsSW50ZXJuYWwoUG9zdGdyZXNEYkVuZ2luZURpYWxlY3QuamF2YTox > NTIpIFtkYWwuamFyOl0NCiAgICAgICAgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmRhbC5kYmJy > b2tlci5Qb3N0Z3Jlc0RiRW5naW5lRGlhbGVjdCRQb3N0Z3Jlc1NpbXBsZUpkYmNDYWxsLmRvRXhl > Y3V0ZShQb3N0Z3Jlc0RiRW5naW5lRGlhbGVjdC5qYXZhOjExOCkgW2RhbC5qYXI6XQ0KICAgICAg > ICBhdCBvcmcuc3ByaW5nZnJhbWV3b3JrLmpkYmMuY29yZS5zaW1wbGUuU2ltcGxlSmRiY0NhbGwu > ZXhlY3V0ZShTaW1wbGVKZGJjQ2FsbC5qYXZhOjE5OCkgW3NwcmluZy1qZGJjLmphcjo0LjMuOS5S > RUxFQVNFXQ0KICAgICAgICBhdCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRiYnJva2VyLlNp > bXBsZUpkYmNDYWxsc0hhbmRsZXIuZXhlY3V0ZUltcGwoU2ltcGxlSmRiY0NhbGxzSGFuZGxlci5q > YXZhOjEzNSkgW2RhbC5qYXI6XQ0KICAgICAgICBhdCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFs > LmRiYnJva2VyLlNpbXBsZUpkYmNDYWxsc0hhbmRsZXIuZXhlY3V0ZVJlYWRMaXN0KFNpbXBsZUpk > YmNDYWxsc0hhbmRsZXIuamF2YToxMDUpIFtkYWwuamFyOl0NCiAgICAgICAgYXQgb3JnLm92aXJ0 > LmVuZ2luZS5jb3JlLmRhby5WbUR5bmFtaWNEYW9JbXBsLmdldEFsbFJ1bm5pbmdGb3JWZHMoVm1E > eW5hbWljRGFvSW1wbC5qYXZhOjUyKSBbZGFsLmphcjpdDQogICAgICAgIGF0IG9yZy5vdmlydC5l > bmdpbmUuY29yZS52ZHNicm9rZXIudmRzYnJva2VyLkhvc3ROZXR3b3JrVG9wb2xvZ3lQZXJzaXN0 > ZXJJbXBsLmlzVm1SdW5uaW5nT25Ib3N0KEhvc3ROZXR3b3JrVG9wb2xvZ3lQZXJzaXN0ZXJJbXBs > LmphdmE6MjEwKSBbdmRzYnJva2VyLmphcjpdDQogICAgICAgIGF0IG9yZy5vdmlydC5lbmdpbmUu > Y29yZS52ZHNicm9rZXIudmRzYnJva2VyLkhvc3ROZXR3b3JrVG9wb2xvZ3lQZXJzaXN0ZXJJbXBs > LmxvZ0NoYW5nZWREaXNwbGF5TmV0d29yayhIb3N0TmV0d29ya1RvcG9sb2d5UGVyc2lzdGVySW1w > bC5qYXZhOjE3OSkgW3Zkc2Jyb2tlci5qYXI6XQ0KICAgICAgICBhdCBvcmcub3ZpcnQuZW5naW5l > LmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5Ib3N0TmV0d29ya1RvcG9sb2d5UGVyc2lzdGVySW1w > bC5hdWRpdE5ldHdvcmtDb21wbGlhbmNlKEhvc3ROZXR3b3JrVG9wb2xvZ3lQZXJzaXN0ZXJJbXBs > LmphdmE6MTQ4KSBbdmRzYnJva2VyLmphcjpdDQogICAgICAgIGF0IG9yZy5vdmlydC5lbmdpbmUu > Y29yZS52ZHNicm9rZXIudmRzYnJva2VyLkhvc3ROZXR3b3JrVG9wb2xvZ3lQZXJzaXN0ZXJJbXBs > LmxhbWJkYSRwZXJzaXN0QW5kRW5mb3JjZU5ldHdvcmtDb21wbGlhbmNlJDAoSG9zdE5ldHdvcmtU > b3BvbG9neVBlcnNpc3RlckltcGwuamF2YToxMDApIFt2ZHNicm9rZXIuamFyOl0NCiAgICAgICAg > YXQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnV0aWxzLnRyPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v > ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19vcmcub3ZpcnQuZW5naW5lLmNvcmUudXRpbHMu > dHImZD1Ed01GYVEmYz1WeHQ1ZTBPc3Z2dDJnZmx3U2xzSjVEbVBHY1B2VFJLTEp5cDAzMXJYamhn > JnI9RmlQaEwwQ2wxeW1abG5UeUFJSUw3NXRFNEwwcmVIY0RkRC03d1V0VUdIQSZtPWJmLU9vMTRm > QndHTmhueXNuV2xUNU5NOVZ1MFBWSk5CQ2g3ZU1aSU9ralEmcz1kRm5vNTJZZEVVR19JR0lfUDBj > MTlvd0w1T0MwQzFOd3c0YW8yVWxnaFM0JmU9PmFuc2FjdGlvbi5UcmFuc2FjdGlvblN1cHBvcnQu > ZXhlY3V0ZUluTmV3VHJhbnNhY3Rpb24oVHJhbnNhY3Rpb25TdXBwb3J0LmphdmE6MjAyKSBbdXRp > bHMuamFyOl0NCiAgICAgICAgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnV0aWxzLnRyPGh0dHBz > Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19vcmcub3ZpcnQu > ZW5naW5lLmNvcmUudXRpbHMudHImZD1Ed01GYVEmYz1WeHQ1ZTBPc3Z2dDJnZmx3U2xzSjVEbVBH > Y1B2VFJLTEp5cDAzMXJYamhnJnI9RmlQaEwwQ2wxeW1abG5UeUFJSUw3NXRFNEwwcmVIY0RkRC03 > d1V0VUdIQSZtPWJmLU9vMTRmQndHTmhueXNuV2xUNU5NOVZ1MFBWSk5CQ2g3ZU1aSU9ralEmcz1k > Rm5vNTJZZEVVR19JR0lfUDBjMTlvd0w1T0MwQzFOd3c0YW8yVWxnaFM0JmU9PmFuc2FjdGlvbi5U > cmFuc2FjdGlvblN1cHBvcnQuZXhlY3V0ZUluUmVxdWlyZWQoVHJhbnNhY3Rpb25TdXBwb3J0Lmph > dmE6MTM3KSBbdXRpbHMuamFyOl0NCiAgICAgICAgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnV0 > aWxzLnRyPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNB > X19vcmcub3ZpcnQuZW5naW5lLmNvcmUudXRpbHMudHImZD1Ed01GYVEmYz1WeHQ1ZTBPc3Z2dDJn > Zmx3U2xzSjVEbVBHY1B2VFJLTEp5cDAzMXJYamhnJnI9RmlQaEwwQ2wxeW1abG5UeUFJSUw3NXRF > NEwwcmVIY0RkRC03d1V0VUdIQSZtPWJmLU9vMTRmQndHTmhueXNuV2xUNU5NOVZ1MFBWSk5CQ2g3 > ZU1aSU9ralEmcz1kRm5vNTJZZEVVR19JR0lfUDBjMTlvd0w1T0MwQzFOd3c0YW8yVWxnaFM0JmU9 > PmFuc2FjdGlvbi5UcmFuc2FjdGlvblN1cHBvcnQuZXhlY3V0ZUluU2NvcGUoVHJhbnNhY3Rpb25T > dXBwb3J0LmphdmE6MTA1KSBbdXRpbHMuamFyOl0NCiAgICAgICAgYXQgb3JnLm92aXJ0LmVuZ2lu > ZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuSG9zdE5ldHdvcmtUb3BvbG9neVBlcnNpc3Rlcklt > cGwucGVyc2lzdEFuZEVuZm9yY2VOZXR3b3JrQ29tcGxpYW5jZShIb3N0TmV0d29ya1RvcG9sb2d5 > UGVyc2lzdGVySW1wbC5qYXZhOjkzKSBbdmRzYnJva2VyLmphcjpdDQogICAgICAgIGF0IG9yZy5v > dmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIudmRzYnJva2VyLkhvc3ROZXR3b3JrVG9wb2xvZ3lQ > ZXJzaXN0ZXJJbXBsLnBlcnNpc3RBbmRFbmZvcmNlTmV0d29ya0NvbXBsaWFuY2UoSG9zdE5ldHdv > cmtUb3BvbG9neVBlcnNpc3RlckltcGwuamF2YToxNTQpIFt2ZHNicm9rZXIuamFyOl0NCiAgICAg > ICAgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci5WZHNNYW5hZ2VyLnByb2Nlc3NS > ZWZyZXNoQ2FwYWJpbGl0aWVzUmVzcG9uc2UoVmRzTWFuYWdlci5qYXZhOjc5NCkgW3Zkc2Jyb2tl > ci5qYXI6XQ0KICAgICAgICBhdCBvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLlZkc01h > bmFnZXIuaGFuZGxlUmVmcmVzaENhcGFiaWxpdGllc1Jlc3BvbnNlKFZkc01hbmFnZXIuamF2YTo1 > OTgpIFt2ZHNicm9rZXIuamFyOl0NCiAgICAgICAgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZk > c2Jyb2tlci5WZHNNYW5hZ2VyLnJlZnJlc2hIb3N0U3luYyhWZHNNYW5hZ2VyLmphdmE6NTY3KSBb > dmRzYnJva2VyLmphcjpdDQogICAgICAgIGF0IG9yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwuUmVm > cmVzaEhvc3RDYXBhYmlsaXRpZXNDb21tYW5kLmV4ZWN1dGVDb21tYW5kKFJlZnJlc2hIb3N0Q2Fw > YWJpbGl0aWVzQ29tbWFuZC5qYXZhOjQxKSBbYmxsLmphcjpdDQogICAgICAgIGF0IG9yZy5vdmly > dC5lbmdpbmUuY29yZS5ibGwuQ29tbWFuZEJhc2UuZXhlY3V0ZVdpdGhvdXRUcmFuc2FjdGlvbihD > b21tYW5kQmFzZS5qYXZhOjExMzMpIFtibGwuamFyOl0NCiAgICAgICAgYXQgb3JnLm92aXJ0LmVu > Z2luZS5jb3JlLmJsbC5Db21tYW5kQmFzZS5leGVjdXRlQWN0aW9uSW5UcmFuc2FjdGlvblNjb3Bl > KENvbW1hbmRCYXNlLmphdmE6MTI4NSkgW2JsbC5qYXI6XQ0KICAgICAgICBhdCBvcmcub3ZpcnQu > ZW5naW5lLmNvcmUuYmxsLkNvbW1hbmRCYXNlLnJ1bkluVHJhbnNhY3Rpb24oQ29tbWFuZEJhc2Uu > amF2YToxOTM0KSBbYmxsLmphcjpdDQogICAgICAgIGF0IG9yZy5vdmlydC5lbmdpbmUuY29yZS51 > dGlscy50cjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0z > QV9fb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnV0aWxzLnRyJmQ9RHdNRmFRJmM9Vnh0NWUwT3N2dnQy > Z2Zsd1Nsc0o1RG1QR2NQdlRSS0xKeXAwMzFyWGpoZyZyPUZpUGhMMENsMXltWmxuVHlBSUlMNzV0 > RTRMMHJlSGNEZEQtN3dVdFVHSEEmbT1iZi1PbzE0ZkJ3R05obnlzbldsVDVOTTlWdTBQVkpOQkNo > N2VNWklPa2pRJnM9ZEZubzUyWWRFVUdfSUdJX1AwYzE5b3dMNU9DMEMxTnd3NGFvMlVsZ2hTNCZl > PT5hbnNhY3Rpb24uVHJhbnNhY3Rpb25TdXBwb3J0LmV4ZWN1dGVJblN1cHByZXNzZWQoVHJhbnNh > Y3Rpb25TdXBwb3J0LmphdmE6MTY0KSBbdXRpbHMuamFyOl0NCiAgICAgICAgYXQgb3JnLm92aXJ0 > LmVuZ2luZS5jb3JlLnV0aWxzLnRyPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 > Mi91cmw/dT1odHRwLTNBX19vcmcub3ZpcnQuZW5naW5lLmNvcmUudXRpbHMudHImZD1Ed01GYVEm > Yz1WeHQ1ZTBPc3Z2dDJnZmx3U2xzSjVEbVBHY1B2VFJLTEp5cDAzMXJYamhnJnI9RmlQaEwwQ2wx > eW1abG5UeUFJSUw3NXRFNEwwcmVIY0RkRC03d1V0VUdIQSZtPWJmLU9vMTRmQndHTmhueXNuV2xU > NU5NOVZ1MFBWSk5CQ2g3ZU1aSU9ralEmcz1kRm5vNTJZZEVVR19JR0lfUDBjMTlvd0w1T0MwQzFO > d3c0YW8yVWxnaFM0JmU9PmFuc2FjdGlvbi5UcmFuc2FjdGlvblN1cHBvcnQuZXhlY3V0ZUluU2Nv > cGUoVHJhbnNhY3Rpb25TdXBwb3J0LmphdmE6MTAzKSBbdXRpbHMuamFyOl0NCiAgICAgICAgYXQg > b3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5Db21tYW5kQmFzZS5leGVjdXRlKENvbW1hbmRCYXNl > LmphdmE6MTM0NSkgW2JsbC5qYXI6XQ0KICAgICAgICBhdCBvcmcub3ZpcnQuZW5naW5lLmNvcmUu > YmxsLkNvbW1hbmRCYXNlLmV4ZWN1dGVBY3Rpb24oQ29tbWFuZEJhc2UuamF2YTo0MDApIFtibGwu > amFyOl0NCiAgICAgICAgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5leGVjdXRvci5EZWZh > dWx0QmFja2VuZEFjdGlvbkV4ZWN1dG9yLmV4ZWN1dGUoRGVmYXVsdEJhY2tlbmRBY3Rpb25FeGVj > dXRvci5qYXZhOjEzKSBbYmxsLmphcjpdDQogICAgICAgIGF0IG9yZy5vdmlydC5lbmdpbmUuY29y > ZS5ibGwuQmFja2VuZC5ydW5BY3Rpb24oQmFja2VuZC5qYXZhOjQ2OCkgW2JsbC5qYXI6XQ0KICAg > ICAgICBhdCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLkJhY2tlbmQucnVuQWN0aW9uSW1wbChC > YWNrZW5kLmphdmE6NDUwKSBbYmxsLmphcjpdDQogICAgICAgIGF0IG9yZy5vdmlydC5lbmdpbmUu > Y29yZS5ibGwuQmFja2VuZC5ydW5JbnRlcm5hbEFjdGlvbihCYWNrZW5kLmphdmE6MzkzKSBbYmxs > LmphcjpdDQogICAgICAgIGF0IHN1bi5yZWZsZWN0LkdlbmVyYXRlZE1ldGhvZEFjY2Vzc29yMTU4 > Lmludm9rZShVbmtub3duIFNvdXJjZSkgWzoxLjguMF8xNjFdDQogICAgICAgIGF0IHN1bi5yZWZs > ZWN0LkRlbGVnYXRpbmdNZXRob2RBY2Nlc3NvckltcGwuaW52b2tlKERlbGVnYXRpbmdNZXRob2RB > Y2Nlc3NvckltcGwuamF2YTo0MykgW3J0LmphcjoxLjguMF8xNjFdDQogICAgICAgIGF0IGphdmEu > bGFuZy5yZWZsZWN0Lk1ldGhvZC5pbnZva2UoTWV0aG9kLmphdmE6NDk4KSBbcnQuamFyOjEuOC4w > XzE2MV0NCiAgICAgICAgYXQgb3JnLmpib3NzLmFzLmVlLmNvbXBvbmVudC5NYW5hZ2VkUmVmZXJl > bmNlTWV0aG9kSW50ZXJjZXB0b3IucHJvY2Vzc0ludm9jYXRpb24oTWFuYWdlZFJlZmVyZW5jZU1l > dGhvZEludGVyY2VwdG9yLmphdmE6NTIpDQogICAgICAgIGF0IG9yZy5qYm9zcy5pbnZvY2F0aW9u > LkludGVyY2VwdG9yQ29udGV4dC5wcm9jZWVkKEludGVyY2VwdG9yQ29udGV4dC5qYXZhOjQyMikN > CiAgICAgICAgYXQgb3JnLmpib3NzLmludm9jYXRpb24uSW50ZXJjZXB0b3JDb250ZXh0JEludm9j > YXRpb24ucHJvY2VlZChJbnRlcmNlcHRvckNvbnRleHQuamF2YTo1MDkpDQogICAgICAgIGF0IG9y > Zy5qYm9zcy5hcy53ZWxkLmludGVyY2VwdG9ycy5Kc3IyOTlCaW5kaW5nc0ludGVyY2VwdG9yLmRl > bGVnYXRlSW50ZXJjZXB0aW9uKEpzcjI5OUJpbmRpbmdzSW50ZXJjZXB0b3IuamF2YTo3OCkNCiAg > ICAgICAgYXQgb3JnLmpib3NzLmFzLndlbGQuaW50ZXJjZXB0b3JzLkpzcjI5OUJpbmRpbmdzSW50 > ZXJjZXB0b3IuZG9NZXRob2RJbnRlcmNlcHRpb24oSnNyMjk5QmluZGluZ3NJbnRlcmNlcHRvci5q > YXZhOjg4KQ0KICAgICAgICBhdCBvcmcuamJvc3MuYXMud2VsZC5pbnRlcmNlcHRvcnMuSnNyMjk5 > QmluZGluZ3NJbnRlcmNlcHRvci5wcm9jZXNzSW52b2NhdGlvbihKc3IyOTlCaW5kaW5nc0ludGVy > Y2VwdG9yLmphdmE6MTAxKQ0KICAgICAgICBhdCBvcmcuamJvc3MuYXMuZWUuY29tcG9uZW50Lmlu > dGVyY2VwdG9ycy5Vc2VySW50ZXJjZXB0b3JGYWN0b3J5JDEucHJvY2Vzc0ludm9jYXRpb24oVXNl > ckludGVyY2VwdG9yRmFjdG9yeS5qYXZhOjYzKQ0KICAgICAgICBhdCBvcmcuamJvc3MuaW52b2Nh > dGlvbi5JbnRlcmNlcHRvckNvbnRleHQucHJvY2VlZChJbnRlcmNlcHRvckNvbnRleHQuamF2YTo0 > MjIpDQogICAgICAgIGF0IG9yZy5qYm9zcy5hcy5lamIzLmNvbXBvbmVudC5pbjxodHRwczovL3Vy > bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fb3JnLmpib3NzLmFzLmVq > YjMuY29tcG9uZW50LmluJmQ9RHdNRmFRJmM9Vnh0NWUwT3N2dnQyZ2Zsd1Nsc0o1RG1QR2NQdlRS > S0xKeXAwMzFyWGpoZyZyPUZpUGhMMENsMXltWmxuVHlBSUlMNzV0RTRMMHJlSGNEZEQtN3dVdFVH > SEEmbT1iZi1PbzE0ZkJ3R05obnlzbldsVDVOTTlWdTBQVkpOQkNoN2VNWklPa2pRJnM9cVlFaHN1 > eWtQVk1OVnJVeTcxZlZ6XzJUUW9IWXJCQWQ5WU9nbzFLNmUtRSZlPT52b2NhdGlvbm1ldHJpY3Mu > RXhlY3V0aW9uVGltZUludGVyY2VwdG9yLnByb2Nlc3NJbnZvY2F0aW9uKEV4ZWN1dGlvblRpbWVJ > bnRlcmNlcHRvci5qYXZhOjQzKSBbd2lsZGZseS1lamIzLTExLjAuMC5GaW5hbC5qYXI6MTEuMC4w > LkZpbmFsXQ0KICAgICAgICBhdCBvcmcuamJvc3MuaW52b2NhdGlvbi5JbnRlcmNlcHRvckNvbnRl > eHQucHJvY2VlZChJbnRlcmNlcHRvckNvbnRleHQuamF2YTo0MjIpDQogICAgICAgIGF0IG9yZy5q > Ym9zcy5hcy5lZS5jb25jdXJyZW50LkNvbmN1cnJlbnRDb250ZXh0SW50ZXJjZXB0b3IucHJvY2Vz > c0ludm9jYXRpb24oQ29uY3VycmVudENvbnRleHRJbnRlcmNlcHRvci5qYXZhOjQ1KSBbd2lsZGZs > eS1lZS0xMS4wLjAuRmluYWwuamFyOjExLjAuMC5GaW5hbF0NCiAgICAgICAgYXQgb3JnLmpib3Nz > Lmludm9jYXRpb24uSW50ZXJjZXB0b3JDb250ZXh0LnByb2NlZWQoSW50ZXJjZXB0b3JDb250ZXh0 > LmphdmE6NDIyKQ0KICAgICAgICBhdCBvcmcuamJvc3MuaW52b2NhdGlvbi5Jbml0aWFsSW50ZXJj > ZXB0b3IucHJvY2Vzc0ludm9jYXRpb24oSW5pdGlhbEludGVyY2VwdG9yLmphdmE6NDApDQogICAg > ICAgIGF0IG9yZy5qYm9zcy5pbnZvY2F0aW9uLkludGVyY2VwdG9yQ29udGV4dC5wcm9jZWVkKElu > dGVyY2VwdG9yQ29udGV4dC5qYXZhOjQyMikNCiAgICAgICAgYXQgb3JnLmpib3NzLmludm9jYXRp > b24uQ2hhaW5lZEludGVyY2VwdG9yLnByb2Nlc3NJbnZvY2F0aW9uKENoYWluZWRJbnRlcmNlcHRv > ci5qYXZhOjUzKQ0KICAgICAgICBhdCBvcmcuamJvc3MuYXMuZWUuY29tcG9uZW50LmludGVyY2Vw > dG9ycy5Db21wb25lbnREaXNwYXRjaGVySW50ZXJjZXB0b3IucHJvY2Vzc0ludm9jYXRpb24oQ29t > cG9uZW50RGlzcGF0Y2hlckludGVyY2VwdG9yLmphdmE6NTIpDQogICAgICAgIGF0IG9yZy5qYm9z > cy5pbnZvY2F0aW9uLkludGVyY2VwdG9yQ29udGV4dC5wcm9jZWVkKEludGVyY2VwdG9yQ29udGV4 > dC5qYXZhOjQyMikNCiAgICAgICAgYXQgb3JnLmpib3NzLmFzLmVqYjMuY29tcG9uZW50LnNpPGh0 > dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19vcmcuamJv > c3MuYXMuZWpiMy5jb21wb25lbnQuc2kmZD1Ed01GYVEmYz1WeHQ1ZTBPc3Z2dDJnZmx3U2xzSjVE > bVBHY1B2VFJLTEp5cDAzMXJYamhnJnI9RmlQaEwwQ2wxeW1abG5UeUFJSUw3NXRFNEwwcmVIY0Rk > RC03d1V0VUdIQSZtPWJmLU9vMTRmQndHTmhueXNuV2xUNU5NOVZ1MFBWSk5CQ2g3ZU1aSU9ralEm > cz0xZVBSZkE1U3JlYUdiVFRTVjNMSUhVOTB2UG1uVVZ0ZzZKT1F1Nnc4Ym44JmU9Pm5nbGV0b24u > U2luZ2xldG9uQ29tcG9uZW50SW5zdGFuY2VBc3NvY2lhdGlvbkludGVyY2VwdG9yLnByb2Nlc3NJ > bnZvY2F0aW9uKFNpbmdsZXRvbkNvbXBvbmVudEluc3RhbmNlQXNzb2NpYXRpb25JbnRlcmNlcHRv > ci5qYXZhOjUzKSBbd2lsZGZseS1lamIzLTExLjAuMC5GaW5hbC5qYXI6MTEuMC4wLkZpbmFsXQ0K > ICAgICAgICBhdCBvcmcuamJvc3MuaW52b2NhdGlvbi5JbnRlcmNlcHRvckNvbnRleHQucHJvY2Vl > ZChJbnRlcmNlcHRvckNvbnRleHQuamF2YTo0MjIpDQogICAgICAgIGF0IG9yZy5qYm9zcy5hcy5l > amIzLnR4LkNNVFR4SW50ZXJjZXB0b3IuaW52b2tlSW5Ob1R4KENNVFR4SW50ZXJjZXB0b3IuamF2 > YToyNjQpIFt3aWxkZmx5LWVqYjMtMTEuMC4wLkZpbmFsLmphcjoxMS4wLjAuRmluYWxdDQogICAg > ICAgIGF0IG9yZy5qYm9zcy5hcy5lamIzLnR4LkNNVFR4SW50ZXJjZXB0b3Iuc3VwcG9ydHMoQ01U > VHhJbnRlcmNlcHRvci5qYXZhOjM3OSkgW3dpbGRmbHktZWpiMy0xMS4wLjAuRmluYWwuamFyOjEx > LjAuMC5GaW5hbF0NCiAgICAgICAgYXQgb3JnLmpib3NzLmFzLmVqYjMudHguQ01UVHhJbnRlcmNl > cHRvci5wcm9jZXNzSW52b2NhdGlvbihDTVRUeEludGVyY2VwdG9yLmphdmE6MjQ0KSBbd2lsZGZs > eS1lamIzLTExLjAuMC5GaW5hbC5qYXI6MTEuMC4wLkZpbmFsXQ0KICAgICAgICBhdCBvcmcuamJv > c3MuaW52b2NhdGlvbi5JbnRlcmNlcHRvckNvbnRleHQucHJvY2VlZChJbnRlcmNlcHRvckNvbnRl > eHQuamF2YTo0MjIpDQogICAgICAgIGF0IG9yZy5qYm9zcy5pbnZvY2F0aW9uLkludGVyY2VwdG9y > Q29udGV4dCRJbnZvY2F0aW9uLnByb2NlZWQoSW50ZXJjZXB0b3JDb250ZXh0LmphdmE6NTA5KQ0K > ICAgICAgICBhdCBvcmcuamJvc3Mud2VsZC5lamIuQWJzdHJhY3RFSkJSZXF1ZXN0U2NvcGVBY3Rp > dmF0aW9uSW50ZXJjZXB0b3IuYXJvdW5kSW52b2tlKEFic3RyYWN0RUpCUmVxdWVzdFNjb3BlQWN0 > aXZhdGlvbkludGVyY2VwdG9yLmphdmE6NzMpIFt3ZWxkLWNvcmUtaW1wbC0yLjQuMy5GaW5hbC5q > YXI6Mi40LjMuRmluYWxdDQogICAgICAgIGF0IG9yZy5qYm9zcy5hcy53ZWxkLmVqYi5FamJSZXF1 > ZXN0U2NvcGVBY3RpdmF0aW9uSW50ZXJjZXB0b3IucHJvY2Vzc0ludm9jYXRpb24oRWpiUmVxdWVz > dFNjb3BlQWN0aXZhdGlvbkludGVyY2VwdG9yLmphdmE6ODkpDQogICAgICAgIGF0IG9yZy5qYm9z > cy5pbnZvY2F0aW9uLkludGVyY2VwdG9yQ29udGV4dC5wcm9jZWVkKEludGVyY2VwdG9yQ29udGV4 > dC5qYXZhOjQyMikNCiAgICAgICAgYXQgb3JnLmpib3NzLmFzLmVqYjMuY29tcG9uZW50LmluPGh0 > dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19vcmcuamJv > c3MuYXMuZWpiMy5jb21wb25lbnQuaW4mZD1Ed01GYVEmYz1WeHQ1ZTBPc3Z2dDJnZmx3U2xzSjVE > bVBHY1B2VFJLTEp5cDAzMXJYamhnJnI9RmlQaEwwQ2wxeW1abG5UeUFJSUw3NXRFNEwwcmVIY0Rk > RC03d1V0VUdIQSZtPWJmLU9vMTRmQndHTmhueXNuV2xUNU5NOVZ1MFBWSk5CQ2g3ZU1aSU9ralEm > cz1xWUVoc3V5a1BWTU5WclV5NzFmVnpfMlRRb0hZckJBZDlZT2dvMUs2ZS1FJmU9PnRlcmNlcHRv > cnMuQ3VycmVudEludm9jYXRpb25Db250ZXh0SW50ZXJjZXB0b3IucHJvY2Vzc0ludm9jYXRpb24o > Q3VycmVudEludm9jYXRpb25Db250ZXh0SW50ZXJjZXB0b3IuamF2YTo0MSkgW3dpbGRmbHktZWpi > My0xMS4wLjAuRmluYWwuamFyOjExLjAuMC5GaW5hbF0NCiAgICAgICAgYXQgb3JnLmpib3NzLmlu > dm9jYXRpb24uSW50ZXJjZXB0b3JDb250ZXh0LnByb2NlZWQoSW50ZXJjZXB0b3JDb250ZXh0Lmph > dmE6NDIyKQ0KICAgICAgICBhdCBvcmcuamJvc3MuYXMuZWpiMy5jb21wb25lbnQuaW48aHR0cHM6 > Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX29yZy5qYm9zcy5h > cy5lamIzLmNvbXBvbmVudC5pbiZkPUR3TUZhUSZjPVZ4dDVlME9zdnZ0MmdmbHdTbHNKNURtUEdj > UHZUUktMSnlwMDMxclhqaGcmcj1GaVBoTDBDbDF5bVpsblR5QUlJTDc1dEU0TDByZUhjRGRELTd3 > VXRVR0hBJm09YmYtT28xNGZCd0dOaG55c25XbFQ1Tk05VnUwUFZKTkJDaDdlTVpJT2tqUSZzPXFZ > RWhzdXlrUFZNTlZyVXk3MWZWel8yVFFvSFlyQkFkOVlPZ28xSzZlLUUmZT0+dm9jYXRpb25tZXRy > aWNzLldhaXRUaW1lSW50ZXJjZXB0b3IucHJvY2Vzc0ludm9jYXRpb24oV2FpdFRpbWVJbnRlcmNl > cHRvci5qYXZhOjQ3KSBbd2lsZGZseS1lamIzLTExLjAuMC5GaW5hbC5qYXI6MTEuMC4wLkZpbmFs > XQ0KICAgICAgICBhdCBvcmcuamJvc3MuaW52b2NhdGlvbi5JbnRlcmNlcHRvckNvbnRleHQucHJv > Y2VlZChJbnRlcmNlcHRvckNvbnRleHQuamF2YTo0MjIpDQogICAgICAgIGF0IG9yZy5qYm9zcy5h > cy5lamIzLnNlY3VyaXR5LlNlY3VyaXR5Q29udGV4dEludGVyY2VwdG9yLnByb2Nlc3NJbnZvY2F0 > aW9uKFNlY3VyaXR5Q29udGV4dEludGVyY2VwdG9yLmphdmE6MTAwKSBbd2lsZGZseS1lamIzLTEx > LjAuMC5GaW5hbC5qYXI6MTEuMC4wLkZpbmFsXQ0KICAgICAgICBhdCBvcmcuamJvc3MuaW52b2Nh > dGlvbi5JbnRlcmNlcHRvckNvbnRleHQucHJvY2VlZChJbnRlcmNlcHRvckNvbnRleHQuamF2YTo0 > MjIpDQogICAgICAgIGF0IG9yZy5qYm9zcy5hcy5lamIzLmRlcGxveW1lbnQucHJvY2Vzc29ycy5T > dGFydHVwQXdhaXRJbnRlcmNlcHRvci5wcm9jZXNzSW52b2NhdGlvbihTdGFydHVwQXdhaXRJbnRl > cmNlcHRvci5qYXZhOjIyKSBbd2lsZGZseS1lamIzLTExLjAuMC5GaW5hbC5qYXI6MTEuMC4wLkZp > bmFsXQ0KICAgICAgICBhdCBvcmcuamJvc3MuaW52b2NhdGlvbi5JbnRlcmNlcHRvckNvbnRleHQu > cHJvY2VlZChJbnRlcmNlcHRvckNvbnRleHQuamF2YTo0MjIpDQogICAgICAgIGF0IG9yZy5qYm9z > cy5hcy5lamIzLmNvbXBvbmVudC5pbjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v > djIvdXJsP3U9aHR0cC0zQV9fb3JnLmpib3NzLmFzLmVqYjMuY29tcG9uZW50LmluJmQ9RHdNRmFR > JmM9Vnh0NWUwT3N2dnQyZ2Zsd1Nsc0o1RG1QR2NQdlRSS0xKeXAwMzFyWGpoZyZyPUZpUGhMMENs > MXltWmxuVHlBSUlMNzV0RTRMMHJlSGNEZEQtN3dVdFVHSEEmbT1iZi1PbzE0ZkJ3R05obnlzblds > VDVOTTlWdTBQVkpOQkNoN2VNWklPa2pRJnM9cVlFaHN1eWtQVk1OVnJVeTcxZlZ6XzJUUW9IWXJC > QWQ5WU9nbzFLNmUtRSZlPT50ZXJjZXB0b3JzLlNodXREb3duSW50ZXJjZXB0b3JGYWN0b3J5JDEu > cHJvY2Vzc0ludm9jYXRpb24oU2h1dERvd25JbnRlcmNlcHRvckZhY3RvcnkuamF2YTo2NCkgW3dp > bGRmbHktZWpiMy0xMS4wLjAuRmluYWwuamFyOjExLjAuMC5GaW5hbF0NCiAgICAgICAgYXQgb3Jn > Lmpib3NzLmludm9jYXRpb24uSW50ZXJjZXB0b3JDb250ZXh0LnByb2NlZWQoSW50ZXJjZXB0b3JD > b250ZXh0LmphdmE6NDIyKQ0KICAgICAgICBhdCBvcmcuamJvc3MuYXMuZWpiMy5jb21wb25lbnQu > aW48aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX29y > Zy5qYm9zcy5hcy5lamIzLmNvbXBvbmVudC5pbiZkPUR3TUZhUSZjPVZ4dDVlME9zdnZ0MmdmbHdT > bHNKNURtUEdjUHZUUktMSnlwMDMxclhqaGcmcj1GaVBoTDBDbDF5bVpsblR5QUlJTDc1dEU0TDBy > ZUhjRGRELTd3VXRVR0hBJm09YmYtT28xNGZCd0dOaG55c25XbFQ1Tk05VnUwUFZKTkJDaDdlTVpJ > T2tqUSZzPXFZRWhzdXlrUFZNTlZyVXk3MWZWel8yVFFvSFlyQkFkOVlPZ28xSzZlLUUmZT0+dGVy > Y2VwdG9ycy5Mb2dnaW5nSW50ZXJjZXB0b3IucHJvY2Vzc0ludm9jYXRpb24oTG9nZ2luZ0ludGVy > Y2VwdG9yLmphdmE6NjcpIFt3aWxkZmx5LWVqYjMtMTEuMC4wLkZpbmFsLmphcjoxMS4wLjAuRmlu > YWxdDQogICAgICAgIGF0IG9yZy5qYm9zcy5pbnZvY2F0aW9uLkludGVyY2VwdG9yQ29udGV4dC5w > cm9jZWVkKEludGVyY2VwdG9yQ29udGV4dC5qYXZhOjQyMikNCiAgICAgICAgYXQgb3JnLmpib3Nz > LmFzLmVlLmNvbXBvbmVudC5OYW1lPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 > Mi91cmw/dT1odHRwLTNBX19vcmcuamJvc3MuYXMuZWUuY29tcG9uZW50Lk5hbWUmZD1Ed01GYVEm > Yz1WeHQ1ZTBPc3Z2dDJnZmx3U2xzSjVEbVBHY1B2VFJLTEp5cDAzMXJYamhnJnI9RmlQaEwwQ2wx > eW1abG5UeUFJSUw3NXRFNEwwcmVIY0RkRC03d1V0VUdIQSZtPWJmLU9vMTRmQndHTmhueXNuV2xU > NU5NOVZ1MFBWSk5CQ2g3ZU1aSU9ralEmcz1BY2VuQkEwamxjN2VLcW1qRThLNmFaRnNrdm5CRmpV > QmpaTlhNbzIxbm1rJmU9PnNwYWNlQ29udGV4dEludGVyY2VwdG9yLnByb2Nlc3NJbnZvY2F0aW9u > KE5hbWVzcGFjZUNvbnRleHRJbnRlcmNlcHRvci5qYXZhOjUwKQ0KICAgICAgICBhdCBvcmcuamJv > c3MuaW52b2NhdGlvbi5JbnRlcmNlcHRvckNvbnRleHQucHJvY2VlZChJbnRlcmNlcHRvckNvbnRl > eHQuamF2YTo0MjIpDQogICAgICAgIGF0IG9yZy5qYm9zcy5pbnZvY2F0aW9uLkNvbnRleHRDbGFz > c0xvYWRlckludGVyY2VwdG9yLnByb2Nlc3NJbnZvY2F0aW9uKENvbnRleHRDbGFzc0xvYWRlcklu > dGVyY2VwdG9yLmphdmE6NjApDQogICAgICAgIGF0IG9yZy5qYm9zcy5pbnZvY2F0aW9uLkludGVy > Y2VwdG9yQ29udGV4dC5wcm9jZWVkKEludGVyY2VwdG9yQ29udGV4dC5qYXZhOjQyMikNCiAgICAg > ICAgYXQgb3JnLmpib3NzLmludm9jYXRpb24uSW50ZXJjZXB0b3JDb250ZXh0LnJ1bihJbnRlcmNl > cHRvckNvbnRleHQuamF2YTo0MzgpDQogICAgICAgIGF0IG9yZy53aWxkZmx5LnNlY3VyaXR5Lm1h > bmFnZXIuV2lsZEZseVNlY3VyaXR5TWFuYWdlci5kb0NoZWNrZWQoV2lsZEZseVNlY3VyaXR5TWFu > YWdlci5qYXZhOjYwOSkNCiAgICAgICAgYXQgb3JnLmpib3NzLmludm9jYXRpb24uQWNjZXNzQ2hl > Y2tpbmdJbnRlcmNlcHRvci5wcm9jZXNzSW52b2NhdGlvbihBY2Nlc3NDaGVja2luZ0ludGVyY2Vw > dG9yLmphdmE6NTcpDQogICAgICAgIGF0IG9yZy5qYm9zcy5pbnZvY2F0aW9uLkludGVyY2VwdG9y > Q29udGV4dC5wcm9jZWVkKEludGVyY2VwdG9yQ29udGV4dC5qYXZhOjQyMikNCiAgICAgICAgYXQg > b3JnLmpib3NzLmludm9jYXRpb24uQ2hhaW5lZEludGVyY2VwdG9yLnByb2Nlc3NJbnZvY2F0aW9u > KENoYWluZWRJbnRlcmNlcHRvci5qYXZhOjUzKQ0KICAgICAgICBhdCBvcmcuamJvc3MuYXMuZWUu > Y29tcG9uZW50LlZpZXdTZXJ2aWNlJFZpZXcuaW52b2tlKFZpZXdTZXJ2aWNlLmphdmE6MTk4KQ0K > ICAgICAgICBhdCBvcmcuamJvc3MuYXMuZWUuY29tcG9uZW50LlZpZXdEZXNjcmlwdGlvbiQxLnBy > b2Nlc3NJbnZvY2F0aW9uKFZpZXdEZXNjcmlwdGlvbi5qYXZhOjE4NSkNCiAgICAgICAgYXQgb3Jn > Lmpib3NzLmFzLmVlLmNvbXBvbmVudC5Qcm94eUludm9jYXRpb25IYW5kbGVyLmludm9rZShQcm94 > eUludm9jYXRpb25IYW5kbGVyLmphdmE6ODEpDQogICAgICAgIGF0IG9yZy5vdmlydC5lbmdpbmUu > Y29yZS5ibGwuaW50ZXJmYWNlcy5CYWNrZW5kSW50ZXJuYWwkJCR2aWV3NC5ydW5JbnRlcm5hbEFj > dGlvbihVbmtub3duIFNvdXJjZSkgW2JsbC5qYXI6XQ0KICAgICAgICBhdCBzdW4ucmVmbGVjdC5H > ZW5lcmF0ZWRNZXRob2RBY2Nlc3NvcjE1Ny5pbnZva2UoVW5rbm93biBTb3VyY2UpIFs6MS44LjBf > MTYxXQ0KICAgICAgICBhdCBzdW4ucmVmbGVjdC5EZWxlZ2F0aW5nTWV0aG9kQWNjZXNzb3JJbXBs > Lmludm9rZShEZWxlZ2F0aW5nTWV0aG9kQWNjZXNzb3JJbXBsLmphdmE6NDMpIFtydC5qYXI6MS44 > LjBfMTYxXQ0KICAgICAgICBhdCBqYXZhLmxhbmcucmVmbGVjdC5NZXRob2QuaW52b2tlKE1ldGhv > ZC5qYXZhOjQ5OCkgW3J0LmphcjoxLjguMF8xNjFdDQogICAgICAgIGF0IG9yZy5qYm9zcy53ZWxk > LnV0aWwucmVmbGVjdGlvbi5SZWZsZWN0aW9ucy5pbnZva2VBbmRVbndyYXAoUmVmbGVjdGlvbnMu > amF2YTo0MzMpIFt3ZWxkLWNvcmUtaW1wbC0yLjQuMy5GaW5hbC5qYXI6Mi40LjMuRmluYWxdDQog > ICAgICAgIGF0IG9yZy5qYm9zcy53ZWxkLmJlYW4ucHJveHkuRW50ZXJwcmlzZUJlYW5Qcm94eU1l > dGhvZEhhbmRsZXIuaW52b2tlKEVudGVycHJpc2VCZWFuUHJveHlNZXRob2RIYW5kbGVyLmphdmE6 > MTI3KSBbd2VsZC1jb3JlLWltcGwtMi40LjMuRmluYWwuamFyOjIuNC4zLkZpbmFsXQ0KICAgICAg > ICBhdCBvcmcuamJvc3Mud2VsZC5iZWFuLnByb3h5LkVudGVycHJpc2VUYXJnZXRCZWFuSW5zdGFu > Y2UuaW52b2tlKEVudGVycHJpc2VUYXJnZXRCZWFuSW5zdGFuY2UuamF2YTo1NikgW3dlbGQtY29y > ZS1pbXBsLTIuNC4zLkZpbmFsLmphcjoyLjQuMy5GaW5hbF0NCiAgICAgICAgYXQgb3JnLmpib3Nz > LndlbGQuYmVhbi5wcm94eS5JbmplY3Rpb25Qb2ludFByb3BhZ2F0aW5nRW50ZXJwcmlzZVRhcmdl > dEJlYW5JbnN0YW5jZS5pbnZva2UoSW5qZWN0aW9uUG9pbnRQcm9wYWdhdGluZ0VudGVycHJpc2VU > YXJnZXRCZWFuSW5zdGFuY2UuamF2YTo2NykgW3dlbGQtY29yZS1pbXBsLTIuNC4zLkZpbmFsLmph > cjoyLjQuMy5GaW5hbF0NCiAgICAgICAgYXQgb3JnLmpib3NzLndlbGQuYmVhbi5wcm94eS5Qcm94 > eU1ldGhvZEhhbmRsZXIuaW52b2tlKFByb3h5TWV0aG9kSGFuZGxlci5qYXZhOjEwMCkgW3dlbGQt > Y29yZS1pbXBsLTIuNC4zLkZpbmFsLmphcjoyLjQuMy5GaW5hbF0NCiAgICAgICAgYXQgb3JnLm92 > aXJ0LmVuZ2luZS5jb3JlLmJsbC5CYWNrZW5kQ29tbWFuZE9iamVjdHNIYW5kbGVyJEJhY2tlbmRJ > bnRlcm5hbCRCYWNrZW5kTG9jYWwkMjA0OTI1OTYxOCRQcm94eSRfJCRfV2VsZCRFbnRlcnByaXNl > UHJveHkkLnJ1bkludGVybmFsQWN0aW9uKFVua25vd24gU291cmNlKSBbYmxsLmphcjpdDQogICAg > ICAgIGF0IG9yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwuVmRzRXZlbnRMaXN0ZW5lci5yZWZyZXNo > SG9zdENhcGFiaWxpdGllcyhWZHNFdmVudExpc3RlbmVyLmphdmE6NTk4KSBbYmxsLmphcjpdDQog > ICAgICAgIGF0IG9yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuSG9zdENvbm5lY3Rpb25S > ZWZyZXNoZXIkU3Vic2NyaWJlclJlZnJlc2hpbmdIb3N0T25Ib3N0Q29ubmVjdGlvbkNoYW5nZUV2 > ZW50Lm9uTmV4dChIb3N0Q29ubmVjdGlvblJlZnJlc2hlci5qYXZhOjQ3KSBbdmRzYnJva2VyLmph > cjpdDQogICAgICAgIGF0IG9yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuSG9zdENvbm5l > Y3Rpb25SZWZyZXNoZXIkU3Vic2NyaWJlclJlZnJlc2hpbmdIb3N0T25Ib3N0Q29ubmVjdGlvbkNo > YW5nZUV2ZW50Lm9uTmV4dChIb3N0Q29ubmVjdGlvblJlZnJlc2hlci5qYXZhOjMwKSBbdmRzYnJv > a2VyLmphcjpdDQogICAgICAgIGF0IG9yZy5vdmlydC52ZHNtLmpzb25ycGMuY2xpZW50LmV2ZW50 > cy5FdmVudFB1Ymxpc2hlciRFdmVudENhbGxhYmxlLmNhbGwoRXZlbnRQdWJsaXNoZXIuamF2YTox > MTgpIFt2ZHNtLWpzb25ycGMtamF2YS1jbGllbnQuamFyOl0NCiAgICAgICAgYXQgb3JnLm92aXJ0 > LnZkc20uanNvbnJwYy5jbGllbnQuZXZlbnRzLkV2ZW50UHVibGlzaGVyJEV2ZW50Q2FsbGFibGUu > Y2FsbChFdmVudFB1Ymxpc2hlci5qYXZhOjkzKSBbdmRzbS1qc29ucnBjLWphdmEtY2xpZW50Lmph > cjpdDQogICAgICAgIGF0IGphdmEudXRpbC5jb25jdXJyZW50LkZvcmtKb2luVGFzayRBZGFwdGVk > Q2FsbGFibGUuZXhlYyhGb3JrSm9pblRhc2suamF2YToxNDI0KSBbcnQuamFyOjEuOC4wXzE2MV0N > CiAgICAgICAgYXQgamF2YS51dGlsLmNvbmN1cnJlbnQuRm9ya0pvaW5UYXNrLmRvRXhlYyhGb3Jr > Sm9pblRhc2suamF2YToyODkpIFtydC5qYXI6MS44LjBfMTYxXQ0KICAgICAgICBhdCBqYXZhLnV0 > aWwuY29uY3VycmVudC5Gb3JrSm9pblBvb2wkV29ya1F1ZXVlLnJ1blRhc2soRm9ya0pvaW5Qb29s > LmphdmE6MTA1NikgW3J0LmphcjoxLjguMF8xNjFdDQogICAgICAgIGF0IGphdmEudXRpbC5jb25j > dXJyZW50LkZvcmtKb2luUG9vbC5ydW5Xb3JrZXIoRm9ya0pvaW5Qb29sLmphdmE6MTY5MikgW3J0 > LmphcjoxLjguMF8xNjFdDQogICAgICAgIGF0IGphdmEudXRpbC5jb25jdXJyZW50LkZvcmtKb2lu > V29ya2VyVGhyZWFkLnJ1bihGb3JrSm9pbldvcmtlclRocmVhZC5qYXZhOjE1NykgW3J0Lmphcjox > LjguMF8xNjFdDQoNCjIwMTgtMDUtMDIgMTQ6NDA6MjMsODUxLTA3IFdBUk4gIFtjb20uYXJqdW5h > LmF0cy5hcmp1bmFdIChGb3JrSm9pblBvb2wtMS13b3JrZXItMTQpIEFSSlVOQTAxMjA3NzogQWJv > cnQgY2FsbGVkIG9uIGFscmVhZHkgYWJvcnRlZCBhdG9taWMgYWN0aW9uIDA6ZmZmZjdmMDAwMDAx > Oi0yMWJkODgwMDo1YWU5MGM0ODoxMGFmYQ0KDQoNCg0KDQoNCkFuZCB0aGUgRU5HSU5FIGxvZzoN > Cg0KMjAxOC0wNS0wMiAxNDo0MDoyMyw4NTEtMDcgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29y > ZS51dGlscy50cmFuc2FjdGlvbi5UcmFuc2FjdGlvblN1cHBvcnRdIChGb3JrSm9pblBvb2wtMS13 > b3JrZXItMTQpIFs1MjI3NmRmNV0gdHJhbnNhY3Rpb24gcm9sbGVkIGJhY2sNCjIwMTgtMDUtMDIg > MTQ6NDA6MjMsODUxLTA3IEVSUk9SIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLlZk > c01hbmFnZXJdIChGb3JrSm9pblBvb2wtMS13b3JrZXItMTQpIFs1MjI3NmRmNV0gVW5hYmxlIHRv > IFJlZnJlc2hDYXBhYmlsaXRpZXM6IElsbGVnYWxTdGF0ZUV4Y2VwdGlvbjogVHJhbnNhY3Rpb24g > TG9jYWwgdHJhbnNhY3Rpb24gKGRlbGVnYXRlPVRyYW5zYWN0aW9uSW1wbGUgPCBhYywgQmFzaWNB > Y3Rpb246IDA6ZmZmZjdmMDAwMDAxOi0yMWJkODgwMDo1YWU5MGM0ODoxMGFmYSBzdGF0dXM6IEFj > dGlvblN0YXR1cy5BQk9SVEVEID4sIG93bmVyPUxvY2FsIHRyYW5zYWN0aW9uIGNvbnRleHQgZm9y > IHByb3ZpZGVyIEpCb3NzIEpUQSB0cmFuc2FjdGlvbiBwcm92aWRlcikgaXMgbm90IGFjdGl2ZSBT > VEFUVVNfUk9MTEVEQkFDSw0KMjAxOC0wNS0wMiAxNDo0MDoyMyw4ODgtMDcgSU5GTyAgW29yZy5v > dmlydC5lbmdpbmUuY29yZS5ibGwuSGFuZGxlVmRzQ3B1RmxhZ3NPckNsdXN0ZXJDaGFuZ2VkQ29t > bWFuZF0gKEZvcmtKb2luUG9vbC0xLXdvcmtlci0xNCkgWzVjNTExZTUxXSBSdW5uaW5nIGNvbW1h > bmQ6IEhhbmRsZVZkc0NwdUZsYWdzT3JDbHVzdGVyQ2hhbmdlZENvbW1hbmQgaW50ZXJuYWw6IHRy > dWUuIEVudGl0aWVzIGFmZmVjdGVkIDogIElEOiA3NGRmZTk2NS1jYjExLTQ5NWEtOTZhMC0zZGFl > NmIzY2JkNzUgVHlwZTogVkRTDQoyMDE4LTA1LTAyIDE0OjQwOjIzLDg5NS0wNyBJTkZPICBbb3Jn > Lm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5IYW5kbGVWZHNWZXJzaW9uQ29tbWFuZF0gKEZvcmtKb2lu > UG9vbC0xLXdvcmtlci0xNCkgWzJhMGVjOTBiXSBSdW5uaW5nIGNvbW1hbmQ6IEhhbmRsZVZkc1Zl > cnNpb25Db21tYW5kIGludGVybmFsOiB0cnVlLiBFbnRpdGllcyBhZmZlY3RlZCA6ICBJRDogNzRk > ZmU5NjUtY2IxMS00OTVhLTk2YTAtM2RhZTZiM2NiZDc1IFR5cGU6IFZEUw0KMjAxOC0wNS0wMiAx > NDo0MDoyMyw4OTgtMDcgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwuUmVmcmVzaEhv > c3RDYXBhYmlsaXRpZXNDb21tYW5kXSAoRm9ya0pvaW5Qb29sLTEtd29ya2VyLTE0KSBbMmEwZWM5 > MGJdIFJlZnJlc2ggaG9zdCBjYXBhYmlsaXRpZXMgZmluaXNoZWQuIExvY2sgcmVsZWFzZWQuIE1v > bml0b3JpbmcgY2FuIHJ1biBub3cgZm9yIGhvc3QgJ292bm9kZTEwMiBmcm9tIGRhdGEtY2VudGVy > ICdEZWZhdWx0Jw0KMjAxOC0wNS0wMiAxNDo0MDoyMyw4OTgtMDcgRVJST1IgW29yZy5vdmlydC5l > bmdpbmUuY29yZS5ibGwuUmVmcmVzaEhvc3RDYXBhYmlsaXRpZXNDb21tYW5kXSAoRm9ya0pvaW5Q > b29sLTEtd29ya2VyLTE0KSBbMmEwZWM5MGJdIENvbW1hbmQgJ29yZy5vdmlydC5lbmdpbmUuY29y > ZS5ibGwuUmVmcmVzaEhvc3RDYXBhYmlsaXRpZXNDb21tYW5kJyBmYWlsZWQ6IENvdWxkIG5vdCBn > ZXQgSkRCQyBDb25uZWN0aW9uOyBuZXN0ZWQgZXhjZXB0aW9uIGlzIGphdmEuc3FsLlNRTEV4Y2Vw > dGlvbjogamF2YXgucmVzb3VyY2UuUmVzb3VyY2VFeGNlcHRpb246IElKMDAwNDU3OiBVbmNoZWNr > ZWQgdGhyb3dhYmxlIGluIG1hbmFnZWRDb25uZWN0aW9uUmVjb25uZWN0ZWQoKSBjbD1vcmcuamJv > c3MuamNhLmNvcmUuY29ubmVjdGlvbm1hbmFnZXIubGlzdGVuZXIuVHhDb25uZWN0aW9uTGlzdGVu > ZXJAMWZhYjg0ZDdbc3RhdGU9Tk9STUFMPG1haWx0bzpjbD1vcmcuamJvc3MuamNhLmNvcmUuY29u > bmVjdGlvbm1hbmFnZXIubGlzdGVuZXIuVHhDb25uZWN0aW9uTGlzdGVuZXJAMWZhYjg0ZDdbc3Rh > dGU9Tk9STUFMPiBtYW5hZ2VkIGNvbm5lY3Rpb249b3JnLmpib3NzLmpjYS5hZGFwdGVycy5qZGJj > LmxvY2FsLkxvY2FsTWFuYWdlZENvbm5lY3Rpb25AM2YzN2NmMTA8bWFpbHRvOmNvbm5lY3Rpb249 > b3JnLmpib3NzLmpjYS5hZGFwdGVycy5qZGJjLmxvY2FsLkxvY2FsTWFuYWdlZENvbm5lY3Rpb25A > M2YzN2NmMTA+IGNvbm5lY3Rpb24gaGFuZGxlcz0wIGxhc3RSZXR1cm5lZD0xNTI1Mjk3MjIzODQ3 > IGxhc3RWYWxpZGF0ZWQ9MTUyNTI5MDI2NzgxMSBsYXN0Q2hlY2tlZE91dD0xNTI1Mjk2OTIzNzcw > IHRyYWNrQnlUeD1mYWxzZSBwb29sPW9yZy5qYm9zcy5qY2EuY29yZS5jb25uZWN0aW9ubWFuYWdl > ci5wb29sLnN0cmF0ZWd5Lk9uZVBvb2xAMjA1NTBmMzU8bWFpbHRvOnBvb2w9b3JnLmpib3NzLmpj > YS5jb3JlLmNvbm5lY3Rpb25tYW5hZ2VyLnBvb2wuc3RyYXRlZ3kuT25lUG9vbEAyMDU1MGYzNT4g > bWNwPVNlbWFwaG9yZUNvbmN1cnJlbnRMaW5rZWRRdWV1ZU1hbmFnZWRDb25uZWN0aW9uUG9vbEA1 > YmFhOTBmW3Bvb2w9RU5HSU5FRGF0YVNvdXJjZV0geGFSZXNvdXJjZT1Mb2NhbFhBUmVzb3VyY2VJ > bXBsQDI0YTdmYzBiW2Nvbm5lY3Rpb25MaXN0ZW5lcj0xZmFiODRkNyBjb25uZWN0aW9uTWFuYWdl > cj01YmVjNzBkMiB3YXJuZWQ9ZmFsc2UgY3VycmVudFhpZD1udWxsIHByb2R1Y3ROYW1lPVBvc3Rn > cmVTUUwgcHJvZHVjdFZlcnNpb249OS41Ljkgam5kaU5hbWU9amF2YTovRU5HSU5FRGF0YVNvdXJj > ZV0gdHhTeW5jPW51bGxdDQoyMDE4LTA1LTAyIDE0OjQwOjIzLDg5OC0wNyBFUlJPUiBbb3JnLm92 > aXJ0LmVuZ2luZS5jb3JlLmJsbC5SZWZyZXNoSG9zdENhcGFiaWxpdGllc0NvbW1hbmRdIChGb3Jr > Sm9pblBvb2wtMS13b3JrZXItMTQpIFsyYTBlYzkwYl0gRXhjZXB0aW9uOiBvcmcuc3ByaW5nZnJh > bWV3b3JrLmpkYmMuQ2Fubm90R2V0SmRiY0Nvbm5lY3Rpb25FeGNlcHRpb246IENvdWxkIG5vdCBn > ZXQgSkRCQyBDb25uZWN0aW9uOyBuZXN0ZWQgZXhjZXB0aW9uIGlzIGphdmEuc3FsLlNRTEV4Y2Vw > dGlvbjogamF2YXgucmVzb3VyY2UuUmVzb3VyY2VFeGNlcHRpb246IElKMDAwNDU3OiBVbmNoZWNr > ZWQgdGhyb3dhYmxlIGluIG1hbmFnZWRDb25uZWN0aW9uUmVjb25uZWN0ZWQoKSBjbD1vcmcuamJv > c3MuamNhLmNvcmUuY29ubmVjdGlvbm1hbmFnZXIubGlzdGVuZXIuVHhDb25uZWN0aW9uTGlzdGVu > ZXJAMWZhYjg0ZDdbc3RhdGU9Tk9STUFMPG1haWx0bzpjbD1vcmcuamJvc3MuamNhLmNvcmUuY29u > bmVjdGlvbm1hbmFnZXIubGlzdGVuZXIuVHhDb25uZWN0aW9uTGlzdGVuZXJAMWZhYjg0ZDdbc3Rh > dGU9Tk9STUFMPiBtYW5hZ2VkIGNvbm5lY3Rpb249b3JnLmpib3NzLmpjYS5hZGFwdGVycy5qZGJj > LmxvY2FsLkxvY2FsTWFuYWdlZENvbm5lY3Rpb25AM2YzN2NmMTA8bWFpbHRvOmNvbm5lY3Rpb249 > b3JnLmpib3NzLmpjYS5hZGFwdGVycy5qZGJjLmxvY2FsLkxvY2FsTWFuYWdlZENvbm5lY3Rpb25A > M2YzN2NmMTA+IGNvbm5lY3Rpb24gaGFuZGxlcz0wIGxhc3RSZXR1cm5lZD0xNTI1Mjk3MjIzODQ3 > IGxhc3RWYWxpZGF0ZWQ9MTUyNTI5MDI2NzgxMSBsYXN0Q2hlY2tlZE91dD0xNTI1Mjk2OTIzNzcw > IHRyYWNrQnlUeD1mYWxzZSBwb29sPW9yZy5qYm9zcy5qY2EuY29yZS5jb25uZWN0aW9ubWFuYWdl > ci5wb29sLnN0cmF0ZWd5Lk9uZVBvb2xAMjA1NTBmMzU8bWFpbHRvOnBvb2w9b3JnLmpib3NzLmpj > YS5jb3JlLmNvbm5lY3Rpb25tYW5hZ2VyLnBvb2wuc3RyYXRlZ3kuT25lUG9vbEAyMDU1MGYzNT4g > bWNwPVNlbWFwaG9yZUNvbmN1cnJlbnRMaW5rZWRRdWV1ZU1hbmFnZWRDb25uZWN0aW9uUG9vbEA1 > YmFhOTBmW3Bvb2w9RU5HSU5FRGF0YVNvdXJjZV0geGFSZXNvdXJjZT1Mb2NhbFhBUmVzb3VyY2VJ > bXBsQDI0YTdmYzBiW2Nvbm5lY3Rpb25MaXN0ZW5lcj0xZmFiODRkNyBjb25uZWN0aW9uTWFuYWdl > cj01YmVjNzBkMiB3YXJuZWQ9ZmFsc2UgY3VycmVudFhpZD1udWxsIHByb2R1Y3ROYW1lPVBvc3Rn > cmVTUUwgcHJvZHVjdFZlcnNpb249OS41Ljkgam5kaU5hbWU9amF2YTovRU5HSU5FRGF0YVNvdXJj > ZV0gdHhTeW5jPW51bGxdDQogICAgICAgIGF0IG9yZy5zcHJpbmdmcmFtZXdvcmsuamRiYy5kYXRh > c291cmNlLkRhdGFTb3VyY2VVdGlscy5nZXRDb25uZWN0aW9uKERhdGFTb3VyY2VVdGlscy5qYXZh > OjgwKSBbc3ByaW5nLWpkYmMuamFyOjQuMy45LlJFTEVBU0VdDQogICAgICAgIGF0IG9yZy5zcHJp > bmdmcmFtZXdvcmsuamRiYy5jb3JlLkpkYmNUZW1wbGF0ZS5leGVjdXRlKEpkYmNUZW1wbGF0ZS5q > YXZhOjYxOSkgW3NwcmluZy1qZGJjLmphcjo0LjMuOS5SRUxFQVNFXQ0KICAgICAgICBhdCBvcmcu > c3ByaW5nZnJhbWV3b3JrLmpkYmMuY29yZS5KZGJjVGVtcGxhdGUucXVlcnkoSmRiY1RlbXBsYXRl > LmphdmE6Njg0KSBbc3ByaW5nLWpkYmMuamFyOjQuMy45LlJFTEVBU0VdDQogICAgICAgIGF0IG9y > Zy5zcHJpbmdmcmFtZXdvcmsuamRiYy5jb3JlLkpkYmNUZW1wbGF0ZS5xdWVyeShKZGJjVGVtcGxh > dGUuamF2YTo3MTYpIFtzcHJpbmctamRiYy5qYXI6NC4zLjkuUkVMRUFTRV0NCiAgICAgICAgYXQg > b3JnLnNwcmluZ2ZyYW1ld29yay5qZGJjLmNvcmUuSmRiY1RlbXBsYXRlLnF1ZXJ5KEpkYmNUZW1w > bGF0ZS5qYXZhOjc2NikgW3NwcmluZy1qZGJjLmphcjo0LjMuOS5SRUxFQVNFXQ0KICAgICAgICBh > dCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRiYnJva2VyLlBvc3RncmVzRGJFbmdpbmVEaWFs > ZWN0JFBvc3RncmVzU2ltcGxlSmRiY0NhbGwuZXhlY3V0ZUNhbGxJbnRlcm5hbChQb3N0Z3Jlc0Ri > RW5naW5lRGlhbGVjdC5qYXZhOjE1MikgW2RhbC5qYXI6XQ0KLg0KLg0KLg0KLg0KMjAxOC0wNS0w > MiAxNDo0MDoyMyw5MDctMDcgRVJST1IgW29yZy5vdmlydC5lbmdpbmUuY29yZS5kYWwuZGJicm9r > ZXIuYXVkaXRsb2doYW5kbGluZy5BdWRpdExvZ0RpcmVjdG9yXSAoRm9ya0pvaW5Qb29sLTEtd29y > a2VyLTE0KSBbMmEwZWM5MGJdIEVWRU5UX0lEOiBIT1NUX1JFRlJFU0hfQ0FQQUJJTElUSUVTX0ZB > SUxFRCg2MDcpLCBGYWlsZWQgdG8gcmVmcmVzaCB0aGUgY2FwYWJpbGl0aWVzIG9mIGhvc3Qgb3Zu > b2RlMTAyLg0KMjAxOC0wNS0wMiAxNDo0MDoyMyw5MDctMDcgSU5GTyAgW29yZy5vdmlydC5lbmdp > bmUuY29yZS5ibGwuUmVmcmVzaEhvc3RDYXBhYmlsaXRpZXNDb21tYW5kXSAoRm9ya0pvaW5Qb29s > LTEtd29ya2VyLTE0KSBbMmEwZWM5MGJdIExvY2sgZnJlZWQgdG8gb2JqZWN0ICdFbmdpbmVMb2Nr > OntleGNsdXNpdmVMb2Nrcz0nWzc0ZGZlOTY1LWNiMTEtNDk1YS05NmEwLTNkYWU2YjNjYmQ3NT1W > RFMsIEhPU1RfTkVUV09SSzc0ZGZlOTY1LWNiMTEtNDk1YS05NmEwLTNkYWU2YjNjYmQ3NT1IT1NU > X05FVFdPUktdJywgc2hhcmVkTG9ja3M9Jyd9Jw0KMjAxOC0wNS0wMiAxNDo0MDoyNSw3NzUtMDcg > SU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIudmRzYnJva2VyLkdldEhhcmR3 > YXJlSW5mb0FzeW5jVkRTQ29tbWFuZF0gKEVFLU1hbmFnZWRUaHJlYWRGYWN0b3J5LWVuZ2luZVNj > aGVkdWxlZC1UaHJlYWQtMzEpIFtdIFNUQVJULCBHZXRIYXJkd2FyZUluZm9Bc3luY1ZEU0NvbW1h > bmQoSG9zdE5hbWUgPSBvdm5vZGUxMDIsIFZkc0lkQW5kVmRzVkRTQ29tbWFuZFBhcmFtZXRlcnNC > YXNlOntob3N0SWQ9Jzc0ZGZlOTY1LWNiMTEtNDk1YS05NmEwLTNkYWU2YjNjYmQ3NScsIHZkcz0n > SG9zdFtvdm5vZGUxMDIsNzRkZmU5NjUtY2IxMS00OTVhLTk2YTAtM2RhZTZiM2NiZDc1XSd9KSwg > bG9nIGlkOiAzMDBmNzM0NQ0KMjAxOC0wNS0wMiAxNDo0MDoyNSw3NzUtMDcgSU5GTyAgW29yZy5v > dmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIudmRzYnJva2VyLkdldEhhcmR3YXJlSW5mb0FzeW5j > VkRTQ29tbWFuZF0gKEVFLU1hbmFnZWRUaHJlYWRGYWN0b3J5LWVuZ2luZVNjaGVkdWxlZC1UaHJl > YWQtMzEpIFtdIEZJTklTSCwgR2V0SGFyZHdhcmVJbmZvQXN5bmNWRFNDb21tYW5kLCBsb2cgaWQ6 > IDMwMGY3MzQ1DQoyMDE4LTA1LTAyIDE0OjQwOjI1LDgwMi0wNyBJTkZPICBbb3JnLm92aXJ0LmVu > Z2luZS5jb3JlLmJsbC5TZXROb25PcGVyYXRpb25hbFZkc0NvbW1hbmRdIChFRS1NYW5hZ2VkVGhy > ZWFkRmFjdG9yeS1lbmdpbmVTY2hlZHVsZWQtVGhyZWFkLTMxKSBbZjJlZjIxZV0gUnVubmluZyBj > b21tYW5kOiBTZXROb25PcGVyYXRpb25hbFZkc0NvbW1hbmQgaW50ZXJuYWw6IHRydWUuIEVudGl0 > aWVzIGFmZmVjdGVkIDogIElEOiA3NGRmZTk2NS1jYjExLTQ5NWEtOTZhMC0zZGFlNmIzY2JkNzUg > VHlwZTogVkRTDQoyMDE4LTA1LTAyIDE0OjQwOjI1LDgwNS0wNyBJTkZPICBbb3JnLm92aXJ0LmVu > Z2luZS5jb3JlLnZkc2Jyb2tlci5TZXRWZHNTdGF0dXNWRFNDb21tYW5kXSAoRUUtTWFuYWdlZFRo > cmVhZEZhY3RvcnktZW5naW5lU2NoZWR1bGVkLVRocmVhZC0zMSkgW2YyZWYyMWVdIFNUQVJULCBT > ZXRWZHNTdGF0dXNWRFNDb21tYW5kKEhvc3ROYW1lID0gb3Zub2RlMTAyLiwgU2V0VmRzU3RhdHVz > VkRTQ29tbWFuZFBhcmFtZXRlcnM6e2hvc3RJZD0nNzRkZmU5NjUtY2IxMS00OTVhLTk2YTAtM2Rh > ZTZiM2NiZDc1Jywgc3RhdHVzPSdOb25PcGVyYXRpb25hbCcsIG5vbk9wZXJhdGlvbmFsUmVhc29u > PSdORVRXT1JLX1VOUkVBQ0hBQkxFJywgc3RvcFNwbUZhaWx1cmVMb2dnZWQ9J2ZhbHNlJywgbWFp > bnRlbmFuY2VSZWFzb249J251bGwnfSksIGxvZyBpZDogNzYxMWQ4ZDgNCjIwMTgtMDUtMDIgMTQ6 > NDA6NTYsNzIyLTA3IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLnBybzxodHRwczov > L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fb3JnLm92aXJ0LmVu > Z2luZS5jb3JlLmJsbC5wcm8mZD1Ed01GYVEmYz1WeHQ1ZTBPc3Z2dDJnZmx3U2xzSjVEbVBHY1B2 > VFJLTEp5cDAzMXJYamhnJnI9RmlQaEwwQ2wxeW1abG5UeUFJSUw3NXRFNEwwcmVIY0RkRC03d1V0 > VUdIQSZtPWJmLU9vMTRmQndHTmhueXNuV2xUNU5NOVZ1MFBWSk5CQ2g3ZU1aSU9ralEmcz1XREJS > a2tyMm9NM3BxQU0tb0E2R0g0aWw3SWpBQTZ1M1BpbThnM1pmNGxVJmU9PnZpZGVyLm5ldHdvcmsu > U3luY05ldHdvcmtQcm92aWRlckNvbW1hbmRdIChFRS1NYW5hZ2VkVGhyZWFkRmFjdG9yeS1lbmdp > bmVTY2hlZHVsZWQtVGhyZWFkLTU4KSBbMzNiZGRhN2ZdIExvY2sgQWNxdWlyZWQgdG8gb2JqZWN0 > ICdFbmdpbmVMb2NrOntleGNsdXNpdmVMb2Nrcz0nW2Y1MGJkMDgxLTdjNWItNDE2MS1hMDQ1LTA2 > OGY4NWQyYTQ3Nj1QUk9WSURFUl0nLCBzaGFyZWRMb2Nrcz0nJ30nDQoyMDE4LTA1LTAyIDE0OjQw > OjU2LDczMi0wNyBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5wcm88aHR0cHM6Ly91 > cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX29yZy5vdmlydC5lbmdp > bmUuY29yZS5ibGwucHJvJmQ9RHdNRmFRJmM9Vnh0NWUwT3N2dnQyZ2Zsd1Nsc0o1RG1QR2NQdlRS > S0xKeXAwMzFyWGpoZyZyPUZpUGhMMENsMXltWmxuVHlBSUlMNzV0RTRMMHJlSGNEZEQtN3dVdFVH > SEEmbT1iZi1PbzE0ZkJ3R05obnlzbldsVDVOTTlWdTBQVkpOQkNoN2VNWklPa2pRJnM9V0RCUmtr > cjJvTTNwcUFNLW9BNkdINGlsN0lqQUE2dTNQaW04ZzNaZjRsVSZlPT52aWRlci5uZXR3b3JrLlN5 > bmNOZXR3b3JrUHJvdmlkZXJDb21tYW5kXSAoRUUtTWFuYWdlZFRocmVhZEZhY3RvcnktZW5naW5l > U2NoZWR1bGVkLVRocmVhZC01OCkgWzMzYmRkYTdmXSBSdW5uaW5nIGNvbW1hbmQ6IFN5bmNOZXR3 > b3JrUHJvdmlkZXJDb21tYW5kIGludGVybmFsOiB0cnVlLg0KMjAxOC0wNS0wMiAxNDo0MDo1Niw4 > NDQtMDcgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS5zc28udXRpbHMuQXV0aGVudGljYXRp > b25VdGlsc10gKGRlZmF1bHQgdGFzay00MCkgW10gVXNlciBhZG1pbkBpbnRlcm5hbCBzdWNjZXNz > ZnVsbHkgbG9nZ2VkIGluIHdpdGggc2NvcGVzOiBvdmlydC1hcHAtYXBpIG92aXJ0LWV4dD10b2tl > bi1pbmZvOmF1dGh6LXNlYXJjaCBvdmlydC1leHQ9dG9rZW4taW5mbzpwdWJsaWMtYXV0aHotc2Vh > cmNoIG92aXJ0LWV4dD10b2tlbi1pbmZvOnZhbGlkYXRlIG92aXJ0LWV4dD10b2tlbjpwYXNzd29y > ZC1hY2Nlc3MNCjIwMTgtMDUtMDIgMTQ6NDA6NTcsMDAxLTA3IElORk8gIFtvcmcub3ZpcnQuZW5n > aW5lLmNvcmUuYmxsLnBybzxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs > P3U9aHR0cC0zQV9fb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5wcm8mZD1Ed01GYVEmYz1WeHQ1 > ZTBPc3Z2dDJnZmx3U2xzSjVEbVBHY1B2VFJLTEp5cDAzMXJYamhnJnI9RmlQaEwwQ2wxeW1abG5U > eUFJSUw3NXRFNEwwcmVIY0RkRC03d1V0VUdIQSZtPWJmLU9vMTRmQndHTmhueXNuV2xUNU5NOVZ1 > MFBWSk5CQ2g3ZU1aSU9ralEmcz1XREJSa2tyMm9NM3BxQU0tb0E2R0g0aWw3SWpBQTZ1M1BpbThn > M1pmNGxVJmU9PnZpZGVyLm5ldHdvcmsuU3luY05ldHdvcmtQcm92aWRlckNvbW1hbmRdIChFRS1N > YW5hZ2VkVGhyZWFkRmFjdG9yeS1lbmdpbmVTY2hlZHVsZWQtVGhyZWFkLTU4KSBbMzNiZGRhN2Zd > IExvY2sgZnJlZWQgdG8gb2JqZWN0ICdFbmdpbmVMb2NrOntleGNsdXNpdmVMb2Nrcz0nW2Y1MGJk > MDgxLTdjNWItNDE2MS1hMDQ1LTA2OGY4NWQyYTQ3Nj1QUk9WSURFUl0nLCBzaGFyZWRMb2Nrcz0n > J30nDQoyMDE4LTA1LTAyIDE0OjQ0OjM5LDE5MS0wNyBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5j > b3JlLmJsbC51dGlscy5UaHJlYWRQb29sTW9uaXRvcmluZ1NlcnZpY2VdIChFRS1NYW5hZ2VkVGhy > ZWFkRmFjdG9yeS1lbmdpbmVUaHJlYWRNb25pdG9yaW5nLVRocmVhZC0xKSBbXSBUaHJlYWQgcG9v > bCAnZGVmYXVsdCcgaXMgdXNpbmcgMCB0aHJlYWRzIG91dCBvZiAxIGFuZCA1IHRhc2tzIGFyZSB3 > YWl0aW5nIGluIHRoZSBxdWV1ZS4NCjIwMTgtMDUtMDIgMTQ6NDQ6MzksMTkxLTA3IElORk8gIFtv > cmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLnV0aWxzLlRocmVhZFBvb2xNb25pdG9yaW5nU2Vydmlj > ZV0gKEVFLU1hbmFnZWRUaHJlYWRGYWN0b3J5LWVuZ2luZVRocmVhZE1vbml0b3JpbmctVGhyZWFk > LTEpIFtdIFRocmVhZCBwb29sICdlbmdpbmUnIGlzIHVzaW5nIDAgdGhyZWFkcyBvdXQgb2YgNTAw > LCA4IHRocmVhZHMgd2FpdGluZyBmb3IgdGFza3MgYW5kIDAgdGFza3MgaW4gcXVldWUuDQoyMDE4 > LTA1LTAyIDE0OjQ0OjM5LDE5MS0wNyBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC51 > dGlscy5UaHJlYWRQb29sTW9uaXRvcmluZ1NlcnZpY2VdIChFRS1NYW5hZ2VkVGhyZWFkRmFjdG9y > eS1lbmdpbmVUaHJlYWRNb25pdG9yaW5nLVRocmVhZC0xKSBbXSBUaHJlYWQgcG9vbCAnZW5naW5l > U2NoZWR1bGVkJyBpcyB1c2luZyAxIHRocmVhZHMgb3V0IG9mIDEwMCBhbmQgOTkgdGFza3MgYXJl > IHdhaXRpbmcgaW4gdGhlIHF1ZXVlLg0KMjAxOC0wNS0wMiAxNDo0NDozOSwxOTEtMDcgSU5GTyAg > W29yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwudXRpbHMuVGhyZWFkUG9vbE1vbml0b3JpbmdTZXJ2 > aWNlXSAoRUUtTWFuYWdlZFRocmVhZEZhY3RvcnktZW5naW5lVGhyZWFkTW9uaXRvcmluZy1UaHJl > YWQtMSkgW10gVGhyZWFkIHBvb2wgJ2VuZ2luZVRocmVhZE1vbml0b3JpbmcnIGlzIHVzaW5nIDEg > dGhyZWFkcyBvdXQgb2YgMSBhbmQgMCB0YXNrcyBhcmUgd2FpdGluZyBpbiB0aGUgcXVldWUuDQoy > MDE4LTA1LTAyIDE0OjQ0OjM5LDE5MS0wNyBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJs > bC51dGlscy5UaHJlYWRQb29sTW9uaXRvcmluZ1NlcnZpY2VdIChFRS1NYW5hZ2VkVGhyZWFkRmFj > dG9yeS1lbmdpbmVUaHJlYWRNb25pdG9yaW5nLVRocmVhZC0xKSBbXSBUaHJlYWQgcG9vbCAnaG9z > dFVwZGF0ZXNDaGVja2VyJyBpcyB1c2luZyAwIHRocmVhZHMgb3V0IG9mIDUgYW5kIDEgdGFza3Mg > YXJlIHdhaXRpbmcgaW4gdGhlIHF1ZXVlLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkZyb206IFlh > bmlyIFF1aW5uIFttYWlsdG86eXF1aW5uQHJlZGhhdC5jb208bWFpbHRvOnlxdWlubkByZWRoYXQu > Y29tPl0NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDIsIDIwMTggMTI6MzQgQU0NClRvOiBKdXN0aW4g > WnlnbW9udCA8anp5Z21vbnRAcHJvb2Zwb2ludC5jb208bWFpbHRvOmp6eWdtb250QHByb29mcG9p > bnQuY29tPj4NCkNjOiB1c2Vyc0BvdmlydC5vcmc8bWFpbHRvOnVzZXJzQG92aXJ0Lm9yZz4NClN1 > YmplY3Q6IFJlOiBbb3ZpcnQtdXNlcnNdIGFkZGluZyBhIGhvc3QNCg0KSGksDQpXaGF0IGRvY3Vt > ZW50IGFyZSB5b3UgdXNpbmcgPw0KU2VlIGlmIHlvdSBmaW5kIHRoZSBuZWVkZWQgaW5mb3JtYXRp > b24gaGVyZSA6ICBodHRwczovL292aXJ0Lm9yZy9kb2N1bWVudGF0aW9uL2FkbWluLWd1aWRlL2No > YXAtSG9zdHMvPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw > cy0zQV9fb3ZpcnQub3JnX2RvY3VtZW50YXRpb25fYWRtaW4tMkRndWlkZV9jaGFwLTJESG9zdHNf > JmQ9RHdNRmFRJmM9Vnh0NWUwT3N2dnQyZ2Zsd1Nsc0o1RG1QR2NQdlRSS0xKeXAwMzFyWGpoZyZy > PUZpUGhMMENsMXltWmxuVHlBSUlMNzV0RTRMMHJlSGNEZEQtN3dVdFVHSEEmbT1GTjAtM1IzeGsw > Y2tjRFZqSlNYUURhSXJqcUM3b3ZHR2ZIVlhaN0xkbVhzJnM9c2FCaGpXWHd2RUhVSEJzby1ZbVR2 > cnk4aWx6SUNZT0lFZW4wNXk5cThQayZlPT4NCg0KRm9yIGVuZ2luZSByZWxhdGVkIHBvdGVudGlh > bCBlcnJvcnMgaSByZWNvbW1lbmQgYWxzbyBjaGVja2luZyB0aGUgZW5naW5lLmxvZyBhbmQgaW4g > VUkgY2hlY2sgdGhlIGV2ZW50cyBzZWN0aW9uLg0KUmVnYXJkcywNCllhbmlyIFF1aW5uDQoNCk9u > IFR1ZSwgTWF5IDEsIDIwMTggYXQgMTE6MTEgUE0sIEp1c3RpbiBaeWdtb250IDxqenlnbW9udEBw > cm9vZnBvaW50LmNvbTxtYWlsdG86anp5Z21vbnRAcHJvb2Zwb2ludC5jb20+PiB3cm90ZToNCkkg > aGF2ZSB0cmllZCB0byBhZGQgYSBob3N0IHRvIHRoZSBlbmdpbmUgYW5kIGl0IGp1c3QgdGFrZXMg > Zm9yZXZlciBuZXZlciB3b3JraW5nIG9yIGdpdmluZyBhbnkgZXJyb3IgbWVzc2FnZS4gIFdoZW4g > SSBsb29rIGluIHRoZSBlbmdpbmXigJlzIHNlcnZlci5sb2cgSSBzZWUgaXQgc2F5cyB0aGUgbmV0 > d29ya3MgYXJlIG1pc3NpbmcuDQpJIHRob3VnaHQgd2hlbiB5b3UgaW5zdGFsbCBhIG5vZGUgYW5k > IGFkZCBpdCB0byB0aGUgZW5naW5lIGl0IHdpbGwgYWRkIHRoZSBuZXR3b3JrcyBhdXRvbWF0aWNh > bGx5PyAgVGhlIGRvY3MgZG9u4oCZdCBnaXZlIG11Y2ggaW5mb3JtYXRpb24gYWJvdXQgdGhpcywg > YW5kIEkgY2Fu4oCZdCBldmVuIHJlbW92ZSB0aGUgaG9zdCB0aHJvdWdoIHRoZSBVSS4gIFdoYXQg > c3RlcHMgYXJlIHJlcXVpcmVkIHRvIHByZXBhcmUgYSBub2RlIHdoZW4gc2V2ZXJhbCB2bGFucyBh > cmUgaW52b2x2ZWQ/DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f > X19fX19fX19fXw0KVXNlcnMgbWFpbGluZyBsaXN0DQpVc2Vyc0BvdmlydC5vcmc8bWFpbHRvOlVz > ZXJzQG92aXJ0Lm9yZz4NCmh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91 > c2VyczxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9f > bGlzdHMub3ZpcnQub3JnX21haWxtYW5fbGlzdGluZm9fdXNlcnMmZD1Ed01GYVEmYz1WeHQ1ZTBP > c3Z2dDJnZmx3U2xzSjVEbVBHY1B2VFJLTEp5cDAzMXJYamhnJnI9RmlQaEwwQ2wxeW1abG5UeUFJ > SUw3NXRFNEwwcmVIY0RkRC03d1V0VUdIQSZtPUZOMC0zUjN4azBja2NEVmpKU1hRRGFJcmpxQzdv > dkdHZkhWWFo3TGRtWHMmcz1YN3E4bUVpbl9rMTVxRjZQaDBHcnJnbjNFSC1RUGQ0OXB1ejFRbHhR > djhvJmU9Pg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f > X19fX19fXw0KVXNlcnMgbWFpbGluZyBsaXN0DQpVc2Vyc0BvdmlydC5vcmc8bWFpbHRvOlVzZXJz > QG92aXJ0Lm9yZz4NCmh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vy > czxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fbGlz > dHMub3ZpcnQub3JnX21haWxtYW5fbGlzdGluZm9fdXNlcnMmZD1Ed01GYVEmYz1WeHQ1ZTBPc3Z2 > dDJnZmx3U2xzSjVEbVBHY1B2VFJLTEp5cDAzMXJYamhnJnI9RmlQaEwwQ2wxeW1abG5UeUFJSUw3 > NXRFNEwwcmVIY0RkRC03d1V0VUdIQSZtPWJmLU9vMTRmQndHTmhueXNuV2xUNU5NOVZ1MFBWSk5C > Q2g3ZU1aSU9ralEmcz1Pd1NyY29QTWpHSHVpSGIxLTNxejV0bXc4NGlScGxZSGpWSk1iRHh0VzJZ > JmU9Pg0KDQoNCg== > > --_000_CY4PR12MB1798DBD078B4054BA0C43EC4AB920CY4PR12MB1798namp_ > Content-Type: text/html; charset="utf-8" > Content-Transfer-Encoding: base64 > > PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy > bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt > YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj > cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv > VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg > Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv > ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl > PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 > IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m > YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy > IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws > IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ > Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 > DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj > b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu > Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw > dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv > cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K > CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp > emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNv > bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 > bXNvbm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 > YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K > CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l > cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl > OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMx > RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw > bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9 > DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp > emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt > YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl > OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 > c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu > ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk > aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ > PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 > ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 > Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 > b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkxvb2tzIGxpa2UgSSBq > dXN0IG1pc3NlZCBzZWxlY3RpbmcgdGhlIEhvc3RlZCBFbmdpbmUgdGFiLCBJIGhhZCB0byByZW1v > dmUgYW5kIGFkZCBiYWNrIHRoZSBob3N0LCBpdCB3b3JrcyBub3cuPG86cD48L286cD48L3NwYW4+ > PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 > Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi > PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu > IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss > c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 > cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh > bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m > bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv > cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N > CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv > bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i > PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm > cXVvdDssc2Fucy1zZXJpZiI+IEp1c3RpbiBaeWdtb250DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVl > c2RheSwgTWF5IDE1LCAyMDE4IDU6NTcgUE08YnI+DQo8Yj5Ubzo8L2I+IEFsb25hIEthcGxhbiAm > bHQ7YWxrYXBsYW5AcmVkaGF0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFlhbmlyIFF1aW5uICZs > dDt5cXVpbm5AcmVkaGF0LmNvbSZndDs7IHVzZXJzQG92aXJ0Lm9yZzxicj4NCjxiPlN1YmplY3Q6 > PC9iPiBSRTogW292aXJ0LXVzZXJzXSBhZGRpbmcgYSBob3N0PG86cD48L286cD48L3NwYW4+PC9w > Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ > PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 > Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi > PkkgcmVpbnN0YWxsZWQgd2l0aCB0aGUgbGF0ZXN0IDQuMi4zIGFuZCBJIGdvdCBpdCB0byB3b3Jr > IHRoaXMgdGltZS4mbmJzcDsgU29tZSB0aGluZ3MgSSBub3RpY2VkLCBJIGhhdmUgdG8gYWRkIHRo > ZSB2bGFucyB0byB0aGUgbmV3IGhvc3QgbWFudWFsbHkgb3IgaXQgc3RheXMgbm9uLW9wZXJhdGlv > bmFsLA0KIGFuZCBJIGNhbuKAmXQgbWlncmF0ZSB0aGUgaG9zdGVkIGVuZ2luZSB0byB0aGUgb3Ro > ZXIgaG9zdCwgSSBnZXQ6IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt > YWwiPkVycm9yIHdoaWxlIGV4ZWN1dGluZyBhY3Rpb246IENhbm5vdCBzd2l0Y2ggdGhlIEhvc3Qo > cykgdG8gTWFpbnRlbmFuY2UgbW9kZS48YnI+DQpUaGVyZSBhcmUgbm8gYXZhaWxhYmxlIGhvc3Rz > IGNhcGFibGUgb2YgcnVubmluZyB0aGUgZW5naW5lIFZNLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh > c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs > Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp > JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ > PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 > Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi > PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz > cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv > dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu > MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFsb25hIEth > cGxhbiBbPGEgaHJlZj0ibWFpbHRvOmFsa2FwbGFuQHJlZGhhdC5jb20iPm1haWx0bzphbGthcGxh > bkByZWRoYXQuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE1heSA2LCAyMDE4 > IDExOjI1IFBNPGJyPg0KPGI+VG86PC9iPiBKdXN0aW4gWnlnbW9udCAmbHQ7PGEgaHJlZj0ibWFp > bHRvOmp6eWdtb250QHByb29mcG9pbnQuY29tIj5qenlnbW9udEBwcm9vZnBvaW50LmNvbTwvYT4m > Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBZYW5pciBRdWlubiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlxdWlu > bkByZWRoYXQuY29tIj55cXVpbm5AcmVkaGF0LmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRv > OnVzZXJzQG92aXJ0Lm9yZyI+dXNlcnNAb3ZpcnQub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i > PiBSZTogW292aXJ0LXVzZXJzXSBhZGRpbmcgYSBob3N0PG86cD48L286cD48L3NwYW4+PC9wPg0K > PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N > CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZpcnN0IHJlc3RhcnQg > dGhlIGVuZ2luZS4gVGhlbiB0cnkgdG8gY2hhbmdlIHRoZSByZXF1aXJlZCBuZXR3b3JrIHRvIGJl > IG5vbi1yZXF1aXJlZCBhbmQgY2xpY2sgb24gUmVmcmVzaENhcGFiaWxpdGllcyBvbiB0aGUgaG9z > dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h > cmdpbi1ib3R0b206MTIuMHB0Ij5JdCBzaG91bGQgbW92ZSB0aGUgaG9zdCB0byBhY3RpdmUgc3Rh > dGUgd2l0aG91dCB0aGUgbmVlZCB0byByZW1vdmUgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N > CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGl0IGRvZXNuJ3QgaGVscCwgcGxlYXNlIGF0dGFjaCB5 > b3VyIGZ1bGwgZW5naW5lLmxvZyBhbmQgc2VydmVyLmxvZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 > Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k > aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW55d2F5IHBsZWFzZSB1cGRhdGUgeW91 > ciBvdmlydCB0byB2ZXJzaW9uIDQuMi4zLjQsIHRoZSBidWcgd2FzIGZpeGVkIHRoZXJlLjxvOnA+ > PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz > cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwv > bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxvbmEuPG86cD48L286cD48 > L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw > PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1heSA3LCAyMDE4IGF0 > IDc6MzAgQU0sIEp1c3RpbiBaeWdtb250ICZsdDs8YSBocmVmPSJtYWlsdG86anp5Z21vbnRAcHJv > b2Zwb2ludC5jb20iIHRhcmdldD0iX2JsYW5rIj5qenlnbW9udEBwcm9vZnBvaW50LmNvbTwvYT4m > Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l > O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw > dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy > Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 > eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ > PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx > dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPknigJl2ZSBkZXNlbGVjdCB0aGUgcmVxdWly > ZWQgc3RhdHVzLCBJIHdpbGwgdHJ5IHRvIGFkZCBpdCBhZ2FpbiBpZiBJIGFtIGV2ZXIgYWJsZSB0 > byByZW1vdmUgdGhlIG9sZCBob3N0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN > c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv > bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 > b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 > bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv > cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt > c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv > bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O > b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h > bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 > b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 > ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl > cmlmIj4gQWxvbmEgS2FwbGFuIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmFsa2FwbGFuQHJlZGhh > dC5jb20iIHRhcmdldD0iX2JsYW5rIj5hbGthcGxhbkByZWRoYXQuY29tPC9hPl0NCjxicj4NCjxi > PlNlbnQ6PC9iPiBTdW5kYXksIE1heSA2LCAyMDE4IDc6MzEgQU08YnI+DQo8Yj5Ubzo8L2I+IFlh > bmlyIFF1aW5uICZsdDs8YSBocmVmPSJtYWlsdG86eXF1aW5uQHJlZGhhdC5jb20iIHRhcmdldD0i > X2JsYW5rIj55cXVpbm5AcmVkaGF0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKdXN0aW4g > WnlnbW9udCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp6eWdtb250QHByb29mcG9pbnQuY29tIiB0YXJn > ZXQ9Il9ibGFuayI+anp5Z21vbnRAcHJvb2Zwb2ludC5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1h > aWx0bzp1c2Vyc0BvdmlydC5vcmciIHRhcmdldD0iX2JsYW5rIj51c2Vyc0BvdmlydC5vcmc8L2E+ > PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs > Ij48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtvdmlydC11c2Vyc10gYWRkaW5nIGEgaG9zdDxv > OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z > b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t > LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw > IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t > Ym90dG9tOjEyLjBwdCI+VGhlcmUgd2FzIGEgYnVnIHdoZW4gYWRkaW5nIGEgaG9zdCB0byBhIGNs > dXN0ZXIgdGhhdCBjb250YWlucyBhIHJlcXVpcmVkIG5ldHdvcmsuIEl0IHdhcyBmaXhlZCBpbiA0 > LjIuMy40LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls > ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJ1 > Zy1VcmwtDQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs > P3U9aHR0cHMtM0FfX2J1Z3ppbGxhLnJlZGhhdC5jb21fMTU3MDM4OCZhbXA7ZD1Ed01GYVEmYW1w > O2M9Vnh0NWUwT3N2dnQyZ2Zsd1Nsc0o1RG1QR2NQdlRSS0xKeXAwMzFyWGpoZyZhbXA7cj1GaVBo > TDBDbDF5bVpsblR5QUlJTDc1dEU0TDByZUhjRGRELTd3VXRVR0hBJmFtcDttPWJmLU9vMTRmQndH > TmhueXNuV2xUNU5NOVZ1MFBWSk5CQ2g3ZU1aSU9ralEmYW1wO3M9bWZuMHBubW5BQkVGbnVYc2Zi > MF84VUpfdDlyT2c3enBsY0Vlc0V1RlkxcyZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz > Oi8vYnVnemlsbGEucmVkaGF0LmNvbS8xNTcwMzg4PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ > DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph > dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv > ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h > bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzLDxvOnA+PC9vOnA+PC9w > Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 > OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFsb25hLjxvOnA+PC9vOnA+PC9wPg0K > PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w > LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv > cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 > OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFN1biwgTWF5IDYsIDIwMTggYXQg > Mzo0OSBQTSwgWWFuaXIgUXVpbm4gJmx0OzxhIGhyZWY9Im1haWx0bzp5cXVpbm5AcmVkaGF0LmNv > bSIgdGFyZ2V0PSJfYmxhbmsiPnlxdWlubkByZWRoYXQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 > L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s > aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu > OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 > Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 > Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z > by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gb3IgcmVtb3ZpbmcgdGhlIG5vbiBvcGVyYXRpb25h > bCBob3N0IDoNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz > dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i > PjEuUmlnaHQgY2xpY2sgb24gdGhlIGhvc3QgbmFtZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 > cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h > cmdpbi1ib3R0b20tYWx0OmF1dG8iPjIuQ2xpY2sgb24mbmJzcDsgJnF1b3Q7Q29uZmlybSBob3N0 > IGhhcyBiZWVuIHJlYm9vdGVkJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz > PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t > OjEyLjBwdCI+My5SZW1vdmUgdGhlIGhvc3Q8YnI+DQo8YnI+DQo8YnI+DQpGb3IgdGhlIGlzc3Vl > IHlvdSBhcmUgZXhwZXJpZW5jaW5nIHdpdGggaG9zdCBhZGRpdGlvbiwgYWNjb3JkaW5nIHRvIHRo > ZSBlbmdpbmUgbG9ncyB5b3UgaGF2ZSBzZW50LCB5b3UgbWlnaHQgbmVlZCB0byBwZXJmb3JtIGEg > ZmV3IHN0ZXBzICwmbmJzcDsgc2VlOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5w > cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fYnVnemlsbGEucmVkaGF0LmNvbV9zaG93 > LTVGYnVnLmNnaS0zRmlkLTNEMTUxNjI1Ni0yM2MyJmFtcDtkPUR3TUZhUSZhbXA7Yz1WeHQ1ZTBP > c3Z2dDJnZmx3U2xzSjVEbVBHY1B2VFJLTEp5cDAzMXJYamhnJmFtcDtyPUZpUGhMMENsMXltWmxu > VHlBSUlMNzV0RTRMMHJlSGNEZEQtN3dVdFVHSEEmYW1wO209YmYtT28xNGZCd0dOaG55c25XbFQ1 > Tk05VnUwUFZKTkJDaDdlTVpJT2tqUSZhbXA7cz0yMnhnZWo0S1J3RFRNQlBmUzAzbmpHbTVtSjRJ > OTZKTGxVWS1pN25UcTVZJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vYnVnemlsbGEu > cmVkaGF0LmNvbS9zaG93X2J1Zy5jZ2k/aWQ9MTUxNjI1NiNjMjwvYT4NCjxvOnA+PC9vOnA+PC9w > Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t > dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHdvdWxkIGFsc28gcmVj > b21tZW5kIHRvIGNoZWNrIHRoZSB0aGUgaG9zdCdzIG5ldHdvcmsgaXMgbm90IGRvd24uDQo8bzpw > PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt > c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+QWxzbywgZHVyaW5n > IGluc3RhbGxhdGlvbiBvZiB0aGUgaG9zdCxvYnNlcnZlIHRoZSBtZXNzYWdlcyBpbiB0aGUgRXZl > bnRzIHNlY3Rpb24gKFVJKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 > Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 > dG9tLWFsdDphdXRvIj5Ib3BlIHRoaXMgaGVscHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk > aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 > bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ > DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv > LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 > L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K > PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 > bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp > dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 > Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t > YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw > PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp > bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgTWF5IDMs > IDIwMTggYXQgMTA6MDcgUE0sIEp1c3RpbiBaeWdtb250ICZsdDs8YSBocmVmPSJtYWlsdG86anp5 > Z21vbnRAcHJvb2Zwb2ludC5jb20iIHRhcmdldD0iX2JsYW5rIj5qenlnbW9udEBwcm9vZnBvaW50 > LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv > cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu > IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo > dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O > b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h > bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 > Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgY2Fu4oCZdCBzZWVtIHRv > IGRvIGFueXRoaW5nIHRvIGNvbnRyb2wgdGhlIGhvc3QgZnJvbSB0aGUgZW5naW5lLCB3aGVuIEkg > c2VsZWN0IGl0IGZvciBNYWludCwgdGhlIGVuZ2luZQ0KIGxvZyBzaG93czo8L3NwYW4+PG86cD48 > L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 > OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 > MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj > MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs > IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 > dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli > cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bb3JnLm92aXJ0LmVuZ2luZS5jb3Jl > LmJsbC5NYWludGVuYW5jZU51bWJlck9mVmRzc0NvbW1hbmRdIChkZWZhdWx0IHRhc2stNTApIFs5 > MGJhODFlZi0yMWU0LTQyNzItOGM1OS04NDc4NmU5NjlmZjddDQogUnVubmluZyBjb21tYW5kOiBN > YWludGVuYW5jZU51bWJlck9mVmRzc0NvbW1hbmQgaW50ZXJuYWw6IGZhbHNlLiBFbnRpdGllcyBh > ZmZlY3RlZCA6Jm5ic3A7IElEOiA3NGRmZTk2NS1jYjExLTQ5NWEtOTZhMC0zZGFlNmIzY2JkNzUg > VHlwZTogVkRTQWN0aW9uIGdyb3VwIE1BTklQVUxBVEVfSE9TVCB3aXRoIHJvbGUgdHlwZSBBRE1J > Tjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t > bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 > bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z > LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjIwMTgtMDUtMDMgMTI6MDA6MzcsOTE4LTA3IElORk8mbmJz > cDsgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuU2V0VmRzU3RhdHVzVkRTQ29tbWFu > ZF0gKGRlZmF1bHQNCiB0YXNrLTUwKSBbOTBiYTgxZWYtMjFlNC00MjcyLThjNTktODQ3ODZlOTY5 > ZmY3XSBTVEFSVCwgU2V0VmRzU3RhdHVzVkRTQ29tbWFuZChIb3N0TmFtZSA9IG92bm9kZTEwMiwg > U2V0VmRzU3RhdHVzVkRTQ29tbWFuZFBhcmFtZXRlcnM6e2hvc3RJZD0nNzRkZmU5NjUtY2IxMS00 > OTVhLTk2YTAtM2RhZTZiM2NiZDc1Jywgc3RhdHVzPSdQcmVwYXJpbmdGb3JNYWludGVuYW5jZScs > IG5vbk9wZXJhdGlvbmFsUmVhc29uPSdOT05FJywgc3RvcFNwbUZhaWx1cmVMb2dnZWQ9J3RydWUn > LA0KIG1haW50ZW5hbmNlUmVhc29uPSdudWxsJ30pLCBsb2cgaWQ6IDY0N2Q1Zjc4PC9zcGFuPjxv > OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w > LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z > aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s > b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v > cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs > dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD > YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ > PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs > dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl > OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 > IzFGNDk3RCI+SSBoYXZlIG9ubHkgMSBob3N0IGluIHRoZSBEQywgc3RhdHVzIGlzIFVwLCB0aGUg > Y2x1c3RlciBzYXlzIGhvc3QgY291bnQgaXMgMiBldmVuIHRob3VnaCB0aGUgc2Vjb25kDQogaG9z > dCBzdGF5cyBOb24gT3BlcmF0aW9uYWwuJm5ic3A7IEkgZG9u4oCZdCBrbm93IGhvdyB0byByZW1v > dmUgaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 > Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh > biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 > LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBqdXN0IGluc3RhbGxlZCBhbmQgdHJpZWQgdG8g > am9pbiB0aGUgREMsIHRoaXMgaXMgYSBmcmVzaCBpbnN0YWxsYXRpb24sIHRoZSBlbmdpbmUgd2Fz > IGxhdW5jaGVkIHRocm91Z2gNCiBjb2NrcGl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs > YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu > LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p > bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv > c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy > Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 > ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl > cmlmO2NvbG9yOiMxRjQ5N0QiPkhlcmVzIHdoYXQgbm9kZWN0bCBzaG93cyBmcm9tIHRoZSBob3N0 > Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t > bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 > bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z > LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs > YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu > LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p > bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPm92bm9kZTEw > MiB+XSMgbm9kZWN0bCBjaGVjazwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O > b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h > bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 > Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlN0YXR1czogT0s8L3NwYW4+ > PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 > b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 > LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj > b2xvcjojMUY0OTdEIj5Cb290bG9hZGVyIC4uLiBPSzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw > IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy > Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m > YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw > OyBMYXllciBib290IGVudHJpZXMgLi4uIE9LPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh > c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t > Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls > eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IFZh > bGlkIGJvb3QgZW50cmllcyAuLi4gT0s8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i > TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 > b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx > dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Nb3VudCBwb2ludHMg > Li4uIE9LPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 > Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh > biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 > LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IFNlcGFyYXRlIC92YXIgLi4uIE9LPC9z > cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn > aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i > Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy > aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IERpc2NhcmQgaXMgdXNlZCAuLi4gT0s8L3NwYW4+PG86 > cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At > YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp > emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv > cjojMUY0OTdEIj5CYXNpYyBzdG9yYWdlIC4uLiBPSzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw > IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy > Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m > YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw > OyBJbml0aWFsaXplZCBWRyAuLi4gT0s8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i > TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 > b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx > dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsgSW5pdGlh > bGl6ZWQgVGhpbiBQb29sIC4uLiBPSzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN > c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv > bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 > b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyBJbml0aWFs > aXplZCBMVnMgLi4uIE9LPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h > bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph > dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp > YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpbiBzdG9yYWdlIC4uLiBPSzwv > c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy > Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 > ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl > cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyBDaGVja2luZyBhdmFpbGFibGUgc3BhY2UgaW4gdGhp > bnBvb2wgLi4uIE9LPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg > c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv > Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp > JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IENoZWNraW5nIHRoaW5wb29s > IGF1dG8tZXh0ZW5kIC4uLiBPSzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O > b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h > bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 > Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnZkc21kIC4uLiBPSzwvc3Bh > bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu > LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv > bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm > O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN > c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv > bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 > b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 > bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv > cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt > c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv > bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O > b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h > bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 > Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86 > cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At > YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp > emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv > cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y > bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 > OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh > bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 > L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 > OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp > emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv > bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx > dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFlhbmlyIFF1aW5uIFttYWlsdG86PGEgaHJl > Zj0ibWFpbHRvOnlxdWlubkByZWRoYXQuY29tIiB0YXJnZXQ9Il9ibGFuayI+eXF1aW5uQHJlZGhh > dC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXkgMywgMjAxOCAxOjE5 > IEFNPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y > bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 > OmF1dG8iPjxicj4NCjxiPlRvOjwvYj4gSnVzdGluIFp5Z21vbnQgJmx0OzxhIGhyZWY9Im1haWx0 > bzpqenlnbW9udEBwcm9vZnBvaW50LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmp6eWdtb250QHByb29m > cG9pbnQuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzp1c2Vyc0Bv > dmlydC5vcmciIHRhcmdldD0iX2JsYW5rIj51c2Vyc0BvdmlydC5vcmc8L2E+PGJyPg0KPGI+U3Vi > amVjdDo8L2I+IFJlOiBbb3ZpcnQtdXNlcnNdIGFkZGluZyBhIGhvc3Q8bzpwPjwvbzpwPjwvcD4N > CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl > PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i > c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y > bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 > OmF1dG8iPkRpZCB5b3UgdHJ5IHN3aXRjaGluZyB0aGUgaG9zdCB0byBtYWludGVuYW5jZSBtb2Rl > IGZpcnN0ID8NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz > dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i > PldoYXQgaXMgdGhlIHN0YXRlIG9mIHRoZSBkYXRhIGNlbnRlciBhbmQgaG93IG1hbnkgYWN0aXZl > IGhvc3RzIGRvIHlvdSBoYXZlIG5vdz8NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz > cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i > b3R0b20tYWx0OmF1dG8iPkFuZCBkaWQgeW91IHBlcmZvcm0gYW55IHVwZGF0ZXMgcmVjZW50bHkg > b3IganVzdCBydW4gYSBmcmVzaCBpbnN0YWxsYXRpb24gPyZuYnNwOyBpZiBzbyAsIGRpZCB5b3Ug > cnVuIGVuZ2luZS1zZXR1cCBiZWZvcmUgbGF1bmNoaW5nIGVuZ2luZSA/DQo8bzpwPjwvbzpwPjwv > cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu > LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 > cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w > LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUsIE1heSAzLCAyMDE4 > IGF0IDEyOjQ3IEFNLCBKdXN0aW4gWnlnbW9udCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp6eWdtb250 > QHByb29mcG9pbnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+anp5Z21vbnRAcHJvb2Zwb2ludC5jb208 > L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 > bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g > Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGlu > O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs > IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 > dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli > cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHJlYWQgdGhpcyBwYWdlIGFuZCBp > dCBkb2VzbuKAmXQgaGVscCBzaW5jZSB0aGlzIGlzIGEgaG9zdCB0aGF0IGNhbuKAmXQgYmUgcmVt > b3ZlZCwgdGhlIOKAnHJlbW92ZeKAnSBidXR0b24NCiBpcyBkaW1tZWQgb3V0LiZuYnNwOyA8L3Nw > YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp > bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm > b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp > Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i > TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 > b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx > dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIGlzIDQuMjIg > b3ZpcnQgbm9kZSwgYnV0IHRoZSBob3N0IHN0YXlzIGluIGEg4oCcbm9uIG9wZXJhdGlvbmFs4oCd > IHN0YXRlLiZuYnNwOyBJIG5vdGljZSB0aGUgbG9ncyBoYXZlIGENCiBsb3Qgb2YgZXJyb3JzLCBm > b3IgZXhhbXBsZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz > dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i > PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm > cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 > L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 > bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 > O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE > Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls > ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz > cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv > dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj50aGUgU0VSVkVSIGxvZzo8L3NwYW4+PG86cD48 > L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 > OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 > MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj > MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs > IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 > dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli > cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4yMDE4LTA1LTAyIDE0OjQwOjIzLDg0 > Ny0wNyBXQVJOJm5ic3A7IFtvcmcuamJvc3MuamNhLmNvcmUuY29ubmVjdGlvbm1hbmFnZXIucG9v > bC5zdHJhdGVneS5PbmVQb29sXSAoRm9ya0pvaW5Qb29sLTEtd29ya2VyLTE0KQ0KIElKMDAwNjA5 > OiBBdHRlbXB0IHRvIHJldHVybiBjb25uZWN0aW9uIHR3aWNlOiA8YSBocmVmPSJtYWlsdG86b3Jn > Lmpib3NzLmpjYS5jb3JlLmNvbm5lY3Rpb25tYW5hZ2VyLmxpc3RlbmVyLlR4Q29ubmVjdGlvbkxp > c3RlbmVyQDFmYWI4NGQ3W3N0YXRlPU5PUk1BTCIgdGFyZ2V0PSJfYmxhbmsiPg0Kb3JnLmpib3Nz > LmpjYS5jb3JlLmNvbm5lY3Rpb25tYW5hZ2VyLmxpc3RlbmVyLlR4Q29ubmVjdGlvbkxpc3RlbmVy > QDFmYWI4NGQ3W3N0YXRlPU5PUk1BTDwvYT4gbWFuYWdlZA0KPGEgaHJlZj0ibWFpbHRvOmNvbm5l > Y3Rpb249b3JnLmpib3NzLmpjYS5hZGFwdGVycy5qZGJjLmxvY2FsLkxvY2FsTWFuYWdlZENvbm5l > Y3Rpb25AM2YzN2NmMTAiIHRhcmdldD0iX2JsYW5rIj4NCmNvbm5lY3Rpb249b3JnLmpib3NzLmpj > YS5hZGFwdGVycy5qZGJjLmxvY2FsLkxvY2FsTWFuYWdlZENvbm5lY3Rpb25AM2YzN2NmMTA8L2E+ > IGNvbm5lY3Rpb24gaGFuZGxlcz0wIGxhc3RSZXR1cm5lZD0xNTI1Mjk3MjIzODQ3IGxhc3RWYWxp > ZGF0ZWQ9MTUyNTI5MDI2NzgxMSBsYXN0Q2hlY2tlZE91dD0xNTI1Mjk2OTIzNzcwIHRyYWNrQnlU > eD1mYWxzZQ0KPGEgaHJlZj0ibWFpbHRvOnBvb2w9b3JnLmpib3NzLmpjYS5jb3JlLmNvbm5lY3Rp > b25tYW5hZ2VyLnBvb2wuc3RyYXRlZ3kuT25lUG9vbEAyMDU1MGYzNSIgdGFyZ2V0PSJfYmxhbmsi > Pg0KcG9vbD1vcmcuamJvc3MuamNhLmNvcmUuY29ubmVjdGlvbm1hbmFnZXIucG9vbC5zdHJhdGVn > eS5PbmVQb29sQDIwNTUwZjM1PC9hPiBtY3A9U2VtYXBob3JlQ29uY3VycmVudExpbmtlZFF1ZXVl > TWFuYWdlZENvbm5lY3Rpb25Qb29sQDViYWE5MGZbcG9vbD1FTkdJTkVEYXRhU291cmNlXSB4YVJl > c291cmNlPUxvY2FsWEFSZXNvdXJjZUltcGxAMjRhN2ZjMGJbY29ubmVjdGlvbkxpc3RlbmVyPTFm > YWI4NGQ3IGNvbm5lY3Rpb25NYW5hZ2VyPTViZWM3MGQyDQogd2FybmVkPWZhbHNlIGN1cnJlbnRY > aWQ9bnVsbCBwcm9kdWN0TmFtZT1Qb3N0Z3JlU1FMIHByb2R1Y3RWZXJzaW9uPTkuNS45IGpuZGlO > YW1lPWphdmE6L0VOR0lORURhdGFTb3VyY2VdIHR4U3luYz1udWxsXTogamF2YS5sYW5nLlRocm93 > YWJsZTogU1RBQ0tUUkFDRTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt > YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 > YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs > aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZu > YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcuamJvc3MuamNhLmNvcmUuY29ubmVjdGlvbm1h > bmFnZXIucG9vbC5tY3AuU2VtYXBob3JlQ29uY3VycmVudExpbmtlZERlcXVlTWFuYWdlZENvbm5l > Y3Rpb25Qb29sLnJldHVybkNvbm5lY3Rpb24oU2VtYXBob3JlQ29uY3VycmVudExpbmtlZERlcXVl > TWFuYWdlZENvbm5lY3Rpb25Qb29sLmphdmE6NzIyKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw > IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy > Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m > YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw > OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcuamJvc3MuamNhLmNv > cmUuY29ubmVjdGlvbm1hbmFnZXIucG9vbC5tY3AuU2VtYXBob3JlQ29uY3VycmVudExpbmtlZERl > cXVlTWFuYWdlZENvbm5lY3Rpb25Qb29sLnJldHVybkNvbm5lY3Rpb24oU2VtYXBob3JlQ29uY3Vy > cmVudExpbmtlZERlcXVlTWFuYWdlZENvbm5lY3Rpb25Qb29sLmphdmE6NjExKTwvc3Bhbj48bzpw > PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h > bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 > ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y > OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBv > cmcuamJvc3MuamNhLmNvcmUuY29ubmVjdGlvbm1hbmFnZXIucG9vbC5BYnN0cmFjdFBvb2wucmV0 > dXJuQ29ubmVjdGlvbihBYnN0cmFjdFBvb2wuamF2YTo4NDcpPC9zcGFuPjxvOnA+PC9vOnA+PC9w > Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z > by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm > b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ > Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9yZy5qYm9zcy5q > Y2EuY29yZS5jb25uZWN0aW9ubWFuYWdlci5BYnN0cmFjdENvbm5lY3Rpb25NYW5hZ2VyLnJldHVy > bk1hbmFnZWRDb25uZWN0aW9uKEFic3RyYWN0Q29ubmVjdGlvbk1hbmFnZXIuamF2YTo3MjUpPC9z > cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn > aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i > Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy > aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i > c3A7IGF0IG9yZy5qYm9zcy5qY2EuY29yZS5jb25uZWN0aW9ubWFuYWdlci50eC5UeENvbm5lY3Rp > b25NYW5hZ2VySW1wbC5tYW5hZ2VkQ29ubmVjdGlvbkRpc2Nvbm5lY3RlZChUeENvbm5lY3Rpb25N > YW5hZ2VySW1wbC5qYXZhOjU4NSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv > Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t > YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 > O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz > cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLmpib3NzLmpjYS5jb3JlLmNvbm5lY3Rp > b25tYW5hZ2VyLkFic3RyYWN0Q29ubmVjdGlvbk1hbmFnZXIuZGlzY29ubmVjdE1hbmFnZWRDb25u > ZWN0aW9uKEFic3RyYWN0Q29ubmVjdGlvbk1hbmFnZXIuamF2YTo5ODgpPC9zcGFuPjxvOnA+PC9v > OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph > dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx > LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG > NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9yZy5q > Ym9zcy5qY2EuY29yZS5jb25uZWN0aW9ubWFuYWdlci5BYnN0cmFjdENvbm5lY3Rpb25NYW5hZ2Vy > LnJlY29ubmVjdE1hbmFnZWRDb25uZWN0aW9uKEFic3RyYWN0Q29ubmVjdGlvbk1hbmFnZXIuamF2 > YTo5NzQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 > Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh > biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 > LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 > Jm5ic3A7Jm5ic3A7IGF0IG9yZy5qYm9zcy5qY2EuY29yZS5jb25uZWN0aW9ubWFuYWdlci5BYnN0 > cmFjdENvbm5lY3Rpb25NYW5hZ2VyLmFsbG9jYXRlQ29ubmVjdGlvbihBYnN0cmFjdENvbm5lY3Rp > b25NYW5hZ2VyLmphdmE6NzkyKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O > b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h > bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 > Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw > OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcuamJvc3MuamNhLmFkYXB0ZXJzLmpkYmMu > V3JhcHBlckRhdGFTb3VyY2UuZ2V0Q29ubmVjdGlvbihXcmFwcGVyRGF0YVNvdXJjZS5qYXZhOjEz > OCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv > LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 > eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu > cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz > cDsmbmJzcDsgYXQgb3JnLmpib3NzLmFzLmNvbm5lY3Rvci5zdWJzeXN0ZW1zLmRhdGFzb3VyY2Vz > LldpbGRGbHlEYXRhU291cmNlLmdldENvbm5lY3Rpb24oV2lsZEZseURhdGFTb3VyY2UuamF2YTo2 > NCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv > LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 > eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu > cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz > cDsmbmJzcDsgYXQgb3JnLnNwcmluZ2ZyYW1ld29yay5qZGJjLmRhdGFzb3VyY2UuRGF0YVNvdXJj > ZVV0aWxzLmRvR2V0Q29ubmVjdGlvbihEYXRhU291cmNlVXRpbHMuamF2YToxMTEpDQogW3Nwcmlu > Zy1qZGJjLmphcjo0LjMuOS5SRUxFQVNFXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz > PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv > dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 > JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw > OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcuc3ByaW5nZnJhbWV3b3JrLmpk > YmMuZGF0YXNvdXJjZS5EYXRhU291cmNlVXRpbHMuZ2V0Q29ubmVjdGlvbihEYXRhU291cmNlVXRp > bHMuamF2YTo3NykNCiBbc3ByaW5nLWpkYmMuamFyOjQuMy45LlJFTEVBU0VdPC9zcGFuPjxvOnA+ > PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs > dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl > OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 > IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9y > Zy5zcHJpbmdmcmFtZXdvcmsuamRiYy5jb3JlLkpkYmNUZW1wbGF0ZS5leGVjdXRlKEpkYmNUZW1w > bGF0ZS5qYXZhOjYxOSkgW3NwcmluZy1qZGJjLmphcjo0LjMuOS5SRUxFQVNFXTwvc3Bhbj48bzpw > PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h > bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 > ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y > OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBv > cmcuc3ByaW5nZnJhbWV3b3JrLmpkYmMuY29yZS5KZGJjVGVtcGxhdGUucXVlcnkoSmRiY1RlbXBs > YXRlLmphdmE6Njg0KSBbc3ByaW5nLWpkYmMuamFyOjQuMy45LlJFTEVBU0VdPC9zcGFuPjxvOnA+ > PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs > dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl > OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 > IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9y > Zy5zcHJpbmdmcmFtZXdvcmsuamRiYy5jb3JlLkpkYmNUZW1wbGF0ZS5xdWVyeShKZGJjVGVtcGxh > dGUuamF2YTo3MTYpIFtzcHJpbmctamRiYy5qYXI6NC4zLjkuUkVMRUFTRV08L3NwYW4+PG86cD48 > L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 > OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 > MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj > MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3Jn > LnNwcmluZ2ZyYW1ld29yay5qZGJjLmNvcmUuSmRiY1RlbXBsYXRlLnF1ZXJ5KEpkYmNUZW1wbGF0 > ZS5qYXZhOjc2NikgW3NwcmluZy1qZGJjLmphcjo0LjMuOS5SRUxFQVNFXTwvc3Bhbj48bzpwPjwv > bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 > YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox > MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx > RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcu > b3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRiYnJva2VyLlBvc3RncmVzRGJFbmdpbmVEaWFsZWN0JFBv > c3RncmVzU2ltcGxlSmRiY0NhbGwuZXhlY3V0ZUNhbGxJbnRlcm5hbChQb3N0Z3Jlc0RiRW5naW5l > RGlhbGVjdC5qYXZhOjE1MikNCiBbZGFsLmphcjpdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg > Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn > aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh > bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 > Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9yZy5vdmlydC5lbmdpbmUu > Y29yZS5kYWwuZGJicm9rZXIuUG9zdGdyZXNEYkVuZ2luZURpYWxlY3QkUG9zdGdyZXNTaW1wbGVK > ZGJjQ2FsbC5kb0V4ZWN1dGUoUG9zdGdyZXNEYkVuZ2luZURpYWxlY3QuamF2YToxMTgpDQogW2Rh > bC5qYXI6XTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl > PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw > YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 > OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw > OyZuYnNwOyZuYnNwOyBhdCBvcmcuc3ByaW5nZnJhbWV3b3JrLmpkYmMuY29yZS5zaW1wbGUuU2lt > cGxlSmRiY0NhbGwuZXhlY3V0ZShTaW1wbGVKZGJjQ2FsbC5qYXZhOjE5OCkgW3NwcmluZy1qZGJj > Lmphcjo0LjMuOS5SRUxFQVNFXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O > b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h > bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 > Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw > OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRi > YnJva2VyLlNpbXBsZUpkYmNDYWxsc0hhbmRsZXIuZXhlY3V0ZUltcGwoU2ltcGxlSmRiY0NhbGxz > SGFuZGxlci5qYXZhOjEzNSkNCiBbZGFsLmphcjpdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg > Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn > aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh > bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 > Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9yZy5vdmlydC5lbmdpbmUu > Y29yZS5kYWwuZGJicm9rZXIuU2ltcGxlSmRiY0NhbGxzSGFuZGxlci5leGVjdXRlUmVhZExpc3Qo > U2ltcGxlSmRiY0NhbGxzSGFuZGxlci5qYXZhOjEwNSkNCiBbZGFsLmphcjpdPC9zcGFuPjxvOnA+ > PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs > dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl > OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 > IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9y > Zy5vdmlydC5lbmdpbmUuY29yZS5kYW8uVm1EeW5hbWljRGFvSW1wbC5nZXRBbGxSdW5uaW5nRm9y > VmRzKFZtRHluYW1pY0Rhb0ltcGwuamF2YTo1MikNCiBbZGFsLmphcjpdPC9zcGFuPjxvOnA+PC9v > OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph > dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx > LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG > NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9yZy5v > dmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIudmRzYnJva2VyLkhvc3ROZXR3b3JrVG9wb2xvZ3lQ > ZXJzaXN0ZXJJbXBsLmlzVm1SdW5uaW5nT25Ib3N0KEhvc3ROZXR3b3JrVG9wb2xvZ3lQZXJzaXN0 > ZXJJbXBsLmphdmE6MjEwKQ0KIFt2ZHNicm9rZXIuamFyOl08L3NwYW4+PG86cD48L286cD48L3A+ > DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv > LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv > bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m > bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLm92aXJ0LmVu > Z2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuSG9zdE5ldHdvcmtUb3BvbG9neVBlcnNpc3Rl > ckltcGwubG9nQ2hhbmdlZERpc3BsYXlOZXR3b3JrKEhvc3ROZXR3b3JrVG9wb2xvZ3lQZXJzaXN0 > ZXJJbXBsLmphdmE6MTc5KQ0KIFt2ZHNicm9rZXIuamFyOl08L3NwYW4+PG86cD48L286cD48L3A+ > DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv > LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv > bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m > bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLm92aXJ0LmVu > Z2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuSG9zdE5ldHdvcmtUb3BvbG9neVBlcnNpc3Rl > ckltcGwuYXVkaXROZXR3b3JrQ29tcGxpYW5jZShIb3N0TmV0d29ya1RvcG9sb2d5UGVyc2lzdGVy > SW1wbC5qYXZhOjE0OCkNCiBbdmRzYnJva2VyLmphcjpdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K > PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t > YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 > LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i > c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9yZy5vdmlydC5lbmdp > bmUuY29yZS52ZHNicm9rZXIudmRzYnJva2VyLkhvc3ROZXR3b3JrVG9wb2xvZ3lQZXJzaXN0ZXJJ > bXBsLmxhbWJkYSRwZXJzaXN0QW5kRW5mb3JjZU5ldHdvcmtDb21wbGlhbmNlJDAoSG9zdE5ldHdv > cmtUb3BvbG9neVBlcnNpc3RlckltcGwuamF2YToxMDApDQogW3Zkc2Jyb2tlci5qYXI6XTwvc3Bh > bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu > LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv > bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm > O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw > OyBhdA0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 > PWh0dHAtM0FfX29yZy5vdmlydC5lbmdpbmUuY29yZS51dGlscy50ciZhbXA7ZD1Ed01GYVEmYW1w > O2M9Vnh0NWUwT3N2dnQyZ2Zsd1Nsc0o1RG1QR2NQdlRSS0xKeXAwMzFyWGpoZyZhbXA7cj1GaVBo > TDBDbDF5bVpsblR5QUlJTDc1dEU0TDByZUhjRGRELTd3VXRVR0hBJmFtcDttPWJmLU9vMTRmQndH > TmhueXNuV2xUNU5NOVZ1MFBWSk5CQ2g3ZU1aSU9ralEmYW1wO3M9ZEZubzUyWWRFVUdfSUdJX1Aw > YzE5b3dMNU9DMEMxTnd3NGFvMlVsZ2hTNCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCm9yZy5v > dmlydC5lbmdpbmUuY29yZS51dGlscy50cjwvYT5hbnNhY3Rpb24uVHJhbnNhY3Rpb25TdXBwb3J0 > LmV4ZWN1dGVJbk5ld1RyYW5zYWN0aW9uKFRyYW5zYWN0aW9uU3VwcG9ydC5qYXZhOjIwMikgW3V0 > aWxzLmphcjpdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 > bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 > c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 > b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i > c3A7Jm5ic3A7Jm5ic3A7IGF0DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu > dC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnV0aWxzLnRyJmFt > cDtkPUR3TUZhUSZhbXA7Yz1WeHQ1ZTBPc3Z2dDJnZmx3U2xzSjVEbVBHY1B2VFJLTEp5cDAzMXJY > amhnJmFtcDtyPUZpUGhMMENsMXltWmxuVHlBSUlMNzV0RTRMMHJlSGNEZEQtN3dVdFVHSEEmYW1w > O209YmYtT28xNGZCd0dOaG55c25XbFQ1Tk05VnUwUFZKTkJDaDdlTVpJT2tqUSZhbXA7cz1kRm5v > NTJZZEVVR19JR0lfUDBjMTlvd0w1T0MwQzFOd3c0YW8yVWxnaFM0JmFtcDtlPSIgdGFyZ2V0PSJf > YmxhbmsiPg0Kb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnV0aWxzLnRyPC9hPmFuc2FjdGlvbi5UcmFu > c2FjdGlvblN1cHBvcnQuZXhlY3V0ZUluUmVxdWlyZWQoVHJhbnNhY3Rpb25TdXBwb3J0LmphdmE6 > MTM3KSBbdXRpbHMuamFyOl08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y > bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 > OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh > bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm > bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQNCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5w > cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19vcmcub3ZpcnQuZW5naW5lLmNvcmUudXRp > bHMudHImYW1wO2Q9RHdNRmFRJmFtcDtjPVZ4dDVlME9zdnZ0MmdmbHdTbHNKNURtUEdjUHZUUktM > SnlwMDMxclhqaGcmYW1wO3I9RmlQaEwwQ2wxeW1abG5UeUFJSUw3NXRFNEwwcmVIY0RkRC03d1V0 > VUdIQSZhbXA7bT1iZi1PbzE0ZkJ3R05obnlzbldsVDVOTTlWdTBQVkpOQkNoN2VNWklPa2pRJmFt > cDtzPWRGbm81MllkRVVHX0lHSV9QMGMxOW93TDVPQzBDMU53dzRhbzJVbGdoUzQmYW1wO2U9IiB0 > YXJnZXQ9Il9ibGFuayI+DQpvcmcub3ZpcnQuZW5naW5lLmNvcmUudXRpbHMudHI8L2E+YW5zYWN0 > aW9uLlRyYW5zYWN0aW9uU3VwcG9ydC5leGVjdXRlSW5TY29wZShUcmFuc2FjdGlvblN1cHBvcnQu > amF2YToxMDUpIFt1dGlscy5qYXI6XTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN > c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv > bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 > b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu > YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRz > YnJva2VyLnZkc2Jyb2tlci5Ib3N0TmV0d29ya1RvcG9sb2d5UGVyc2lzdGVySW1wbC5wZXJzaXN0 > QW5kRW5mb3JjZU5ldHdvcmtDb21wbGlhbmNlKEhvc3ROZXR3b3JrVG9wb2xvZ3lQZXJzaXN0ZXJJ > bXBsLmphdmE6OTMpDQogW3Zkc2Jyb2tlci5qYXI6XTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw > IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy > Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m > YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw > OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcub3ZpcnQuZW5naW5l > LmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5Ib3N0TmV0d29ya1RvcG9sb2d5UGVyc2lzdGVySW1w > bC5wZXJzaXN0QW5kRW5mb3JjZU5ldHdvcmtDb21wbGlhbmNlKEhvc3ROZXR3b3JrVG9wb2xvZ3lQ > ZXJzaXN0ZXJJbXBsLmphdmE6MTU0KQ0KIFt2ZHNicm9rZXIuamFyOl08L3NwYW4+PG86cD48L286 > cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 > dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu > MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 > OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLm92 > aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci5WZHNNYW5hZ2VyLnByb2Nlc3NSZWZyZXNoQ2FwYWJp > bGl0aWVzUmVzcG9uc2UoVmRzTWFuYWdlci5qYXZhOjc5NCkNCiBbdmRzYnJva2VyLmphcjpdPC9z > cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn > aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i > Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy > aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i > c3A7IGF0IG9yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuVmRzTWFuYWdlci5oYW5kbGVS > ZWZyZXNoQ2FwYWJpbGl0aWVzUmVzcG9uc2UoVmRzTWFuYWdlci5qYXZhOjU5OCkNCiBbdmRzYnJv > a2VyLmphcjpdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 > bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 > c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 > b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i > c3A7Jm5ic3A7Jm5ic3A7IGF0IG9yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuVmRzTWFu > YWdlci5yZWZyZXNoSG9zdFN5bmMoVmRzTWFuYWdlci5qYXZhOjU2NykgW3Zkc2Jyb2tlci5qYXI6 > XTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t > bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 > bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z > LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw > OyZuYnNwOyBhdCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLlJlZnJlc2hIb3N0Q2FwYWJpbGl0 > aWVzQ29tbWFuZC5leGVjdXRlQ29tbWFuZChSZWZyZXNoSG9zdENhcGFiaWxpdGllc0NvbW1hbmQu > amF2YTo0MSkNCiBbYmxsLmphcjpdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z > b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t > LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv > dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i > c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwu > Q29tbWFuZEJhc2UuZXhlY3V0ZVdpdGhvdXRUcmFuc2FjdGlvbihDb21tYW5kQmFzZS5qYXZhOjEx > MzMpIFtibGwuamFyOl08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs > IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 > dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli > cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz > cDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5Db21tYW5k > QmFzZS5leGVjdXRlQWN0aW9uSW5UcmFuc2FjdGlvblNjb3BlKENvbW1hbmRCYXNlLmphdmE6MTI4 > NSkNCiBbYmxsLmphcjpdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h > bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph > dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp > YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i > c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwuQ29tbWFu > ZEJhc2UucnVuSW5UcmFuc2FjdGlvbihDb21tYW5kQmFzZS5qYXZhOjE5MzQpIFtibGwuamFyOl08 > L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h > cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl > PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z > ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm > bmJzcDsgYXQNCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 > cmw/dT1odHRwLTNBX19vcmcub3ZpcnQuZW5naW5lLmNvcmUudXRpbHMudHImYW1wO2Q9RHdNRmFR > JmFtcDtjPVZ4dDVlME9zdnZ0MmdmbHdTbHNKNURtUEdjUHZUUktMSnlwMDMxclhqaGcmYW1wO3I9 > RmlQaEwwQ2wxeW1abG5UeUFJSUw3NXRFNEwwcmVIY0RkRC03d1V0VUdIQSZhbXA7bT1iZi1PbzE0 > ZkJ3R05obnlzbldsVDVOTTlWdTBQVkpOQkNoN2VNWklPa2pRJmFtcDtzPWRGbm81MllkRVVHX0lH > SV9QMGMxOW93TDVPQzBDMU53dzRhbzJVbGdoUzQmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpv > cmcub3ZpcnQuZW5naW5lLmNvcmUudXRpbHMudHI8L2E+YW5zYWN0aW9uLlRyYW5zYWN0aW9uU3Vw > cG9ydC5leGVjdXRlSW5TdXBwcmVzc2VkKFRyYW5zYWN0aW9uU3VwcG9ydC5qYXZhOjE2NCkgW3V0 > aWxzLmphcjpdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 > bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 > c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 > b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i > c3A7Jm5ic3A7Jm5ic3A7IGF0DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu > dC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnV0aWxzLnRyJmFt > cDtkPUR3TUZhUSZhbXA7Yz1WeHQ1ZTBPc3Z2dDJnZmx3U2xzSjVEbVBHY1B2VFJLTEp5cDAzMXJY > amhnJmFtcDtyPUZpUGhMMENsMXltWmxuVHlBSUlMNzV0RTRMMHJlSGNEZEQtN3dVdFVHSEEmYW1w > O209YmYtT28xNGZCd0dOaG55c25XbFQ1Tk05VnUwUFZKTkJDaDdlTVpJT2tqUSZhbXA7cz1kRm5v > NTJZZEVVR19JR0lfUDBjMTlvd0w1T0MwQzFOd3c0YW8yVWxnaFM0JmFtcDtlPSIgdGFyZ2V0PSJf > YmxhbmsiPg0Kb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnV0aWxzLnRyPC9hPmFuc2FjdGlvbi5UcmFu > c2FjdGlvblN1cHBvcnQuZXhlY3V0ZUluU2NvcGUoVHJhbnNhY3Rpb25TdXBwb3J0LmphdmE6MTAz > KSBbdXRpbHMuamFyOl08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs > IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 > dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli > cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz > cDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5Db21tYW5k > QmFzZS5leGVjdXRlKENvbW1hbmRCYXNlLmphdmE6MTM0NSkgW2JsbC5qYXI6XTwvc3Bhbj48bzpw > PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h > bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 > ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y > OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDthdCBv > cmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLkNvbW1hbmRCYXNlLmV4ZWN1dGVBY3Rpb24oQ29tbWFu > ZEJhc2UuamF2YTo0MDApIFtibGwuamFyOl08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz > cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i > b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 > OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz > cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3Jl > LmJsbC5leGVjdXRvci5EZWZhdWx0QmFja2VuZEFjdGlvbkV4ZWN1dG9yLmV4ZWN1dGUoRGVmYXVs > dEJhY2tlbmRBY3Rpb25FeGVjdXRvci5qYXZhOjEzKQ0KIFtibGwuamFyOl08L3NwYW4+PG86cD48 > L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 > OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 > MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj > MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3Jn > Lm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5CYWNrZW5kLnJ1bkFjdGlvbihCYWNrZW5kLmphdmE6NDY4 > KSBbYmxsLmphcjpdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg > c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv > Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp > JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 > Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwuQmFja2VuZC5y > dW5BY3Rpb25JbXBsKEJhY2tlbmQuamF2YTo0NTApIFtibGwuamFyOl08L3NwYW4+PG86cD48L286 > cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 > dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu > MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 > OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLm92 > aXJ0LmVuZ2luZS5jb3JlLmJsbC5CYWNrZW5kLnJ1bkludGVybmFsQWN0aW9uKEJhY2tlbmQuamF2 > YTozOTMpIFtibGwuamFyOl08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y > bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 > OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh > bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm > bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgc3VuLnJlZmxlY3QuR2VuZXJhdGVkTWV0aG9kQWNj > ZXNzb3IxNTguaW52b2tlKFVua25vd24gU291cmNlKSBbOjEuOC4wXzE2MV08L3NwYW4+PG86cD48 > L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 > OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 > MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj > MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgc3Vu > LnJlZmxlY3QuRGVsZWdhdGluZ01ldGhvZEFjY2Vzc29ySW1wbC5pbnZva2UoRGVsZWdhdGluZ01l > dGhvZEFjY2Vzc29ySW1wbC5qYXZhOjQzKSBbcnQuamFyOjEuOC4wXzE2MV08L3NwYW4+PG86cD48 > L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 > OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 > MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj > MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgamF2 > YS5sYW5nLnJlZmxlY3QuTWV0aG9kLmludm9rZShNZXRob2QuamF2YTo0OTgpIFtydC5qYXI6MS44 > LjBfMTYxXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl > PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw > YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 > OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw > OyZuYnNwOyZuYnNwOyBhdCBvcmcuamJvc3MuYXMuZWUuY29tcG9uZW50Lk1hbmFnZWRSZWZlcmVu > Y2VNZXRob2RJbnRlcmNlcHRvci5wcm9jZXNzSW52b2NhdGlvbihNYW5hZ2VkUmVmZXJlbmNlTWV0 > aG9kSW50ZXJjZXB0b3IuamF2YTo1Mik8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i > TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 > b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx > dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsm > bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLmpib3NzLmludm9jYXRpb24uSW50 > ZXJjZXB0b3JDb250ZXh0LnByb2NlZWQoSW50ZXJjZXB0b3JDb250ZXh0LmphdmE6NDIyKTwvc3Bh > bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu > LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv > bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm > O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw > OyBhdCBvcmcuamJvc3MuaW52b2NhdGlvbi5JbnRlcmNlcHRvckNvbnRleHQkSW52b2NhdGlvbi5w > cm9jZWVkKEludGVyY2VwdG9yQ29udGV4dC5qYXZhOjUwOSk8L3NwYW4+PG86cD48L286cD48L3A+ > DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv > LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv > bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m > bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLmpib3NzLmFz > LndlbGQuaW50ZXJjZXB0b3JzLkpzcjI5OUJpbmRpbmdzSW50ZXJjZXB0b3IuZGVsZWdhdGVJbnRl > cmNlcHRpb24oSnNyMjk5QmluZGluZ3NJbnRlcmNlcHRvci5qYXZhOjc4KTwvc3Bhbj48bzpwPjwv > bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 > YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox > MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx > RjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcu > amJvc3MuYXMud2VsZC5pbnRlcmNlcHRvcnMuSnNyMjk5QmluZGluZ3NJbnRlcmNlcHRvci5kb01l > dGhvZEludGVyY2VwdGlvbihKc3IyOTlCaW5kaW5nc0ludGVyY2VwdG9yLmphdmE6ODgpPC9zcGFu > PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t > dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u > dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 > Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 > IGF0IG9yZy5qYm9zcy5hcy53ZWxkLmludGVyY2VwdG9ycy5Kc3IyOTlCaW5kaW5nc0ludGVyY2Vw > dG9yLnByb2Nlc3NJbnZvY2F0aW9uKEpzcjI5OUJpbmRpbmdzSW50ZXJjZXB0b3IuamF2YToxMDEp > PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t > YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls > ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt > c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 > Jm5ic3A7IGF0IG9yZy5qYm9zcy5hcy5lZS5jb21wb25lbnQuaW50ZXJjZXB0b3JzLlVzZXJJbnRl > cmNlcHRvckZhY3RvcnkkMS5wcm9jZXNzSW52b2NhdGlvbihVc2VySW50ZXJjZXB0b3JGYWN0b3J5 > LmphdmE6NjMpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 > bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 > c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 > b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i > c3A7Jm5ic3A7Jm5ic3A7IGF0IG9yZy5qYm9zcy5pbnZvY2F0aW9uLkludGVyY2VwdG9yQ29udGV4 > dC5wcm9jZWVkKEludGVyY2VwdG9yQ29udGV4dC5qYXZhOjQyMik8L3NwYW4+PG86cD48L286cD48 > L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 > bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 > O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE > Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQNCjxhIGhyZWY9 > Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19vcmcu > amJvc3MuYXMuZWpiMy5jb21wb25lbnQuaW4mYW1wO2Q9RHdNRmFRJmFtcDtjPVZ4dDVlME9zdnZ0 > MmdmbHdTbHNKNURtUEdjUHZUUktMSnlwMDMxclhqaGcmYW1wO3I9RmlQaEwwQ2wxeW1abG5UeUFJ > SUw3NXRFNEwwcmVIY0RkRC03d1V0VUdIQSZhbXA7bT1iZi1PbzE0ZkJ3R05obnlzbldsVDVOTTlW > dTBQVkpOQkNoN2VNWklPa2pRJmFtcDtzPXFZRWhzdXlrUFZNTlZyVXk3MWZWel8yVFFvSFlyQkFk > OVlPZ28xSzZlLUUmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpvcmcuamJvc3MuYXMuZWpiMy5j > b21wb25lbnQuaW48L2E+dm9jYXRpb25tZXRyaWNzLkV4ZWN1dGlvblRpbWVJbnRlcmNlcHRvci5w > cm9jZXNzSW52b2NhdGlvbihFeGVjdXRpb25UaW1lSW50ZXJjZXB0b3IuamF2YTo0MykgW3dpbGRm > bHktZWpiMy0xMS4wLjAuRmluYWwuamFyOjExLjAuMC5GaW5hbF08L3NwYW4+PG86cD48L286cD48 > L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 > bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 > O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE > Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLmpib3Nz > Lmludm9jYXRpb24uSW50ZXJjZXB0b3JDb250ZXh0LnByb2NlZWQoSW50ZXJjZXB0b3JDb250ZXh0 > LmphdmE6NDIyKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 > eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ > PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx > dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu > YnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcuamJvc3MuYXMuZWUuY29uY3VycmVudC5Db25jdXJyZW50 > Q29udGV4dEludGVyY2VwdG9yLnByb2Nlc3NJbnZvY2F0aW9uKENvbmN1cnJlbnRDb250ZXh0SW50 > ZXJjZXB0b3IuamF2YTo0NSkNCiBbd2lsZGZseS1lZS0xMS4wLjAuRmluYWwuamFyOjExLjAuMC5G > aW5hbF08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i > bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu > IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss > c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm > bmJzcDsmbmJzcDsgYXQgb3JnLmpib3NzLmludm9jYXRpb24uSW50ZXJjZXB0b3JDb250ZXh0LnBy > b2NlZWQoSW50ZXJjZXB0b3JDb250ZXh0LmphdmE6NDIyKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N > CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t > bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u > dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu > YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcuamJvc3MuaW52 > b2NhdGlvbi5Jbml0aWFsSW50ZXJjZXB0b3IucHJvY2Vzc0ludm9jYXRpb24oSW5pdGlhbEludGVy > Y2VwdG9yLmphdmE6NDApPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h > bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph > dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp > YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i > c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9yZy5qYm9zcy5pbnZvY2F0aW9uLkludGVyY2VwdG9y > Q29udGV4dC5wcm9jZWVkKEludGVyY2VwdG9yQ29udGV4dC5qYXZhOjQyMik8L3NwYW4+PG86cD48 > L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 > OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 > MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj > MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3Jn > Lmpib3NzLmludm9jYXRpb24uQ2hhaW5lZEludGVyY2VwdG9yLnByb2Nlc3NJbnZvY2F0aW9uKENo > YWluZWRJbnRlcmNlcHRvci5qYXZhOjUzKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz > PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv > dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 > JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw > OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcuamJvc3MuYXMuZWUuY29tcG9u > ZW50LmludGVyY2VwdG9ycy5Db21wb25lbnREaXNwYXRjaGVySW50ZXJjZXB0b3IucHJvY2Vzc0lu > dm9jYXRpb24oQ29tcG9uZW50RGlzcGF0Y2hlckludGVyY2VwdG9yLmphdmE6NTIpPC9zcGFuPjxv > OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w > LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z > aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s > b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0 > IG9yZy5qYm9zcy5pbnZvY2F0aW9uLkludGVyY2VwdG9yQ29udGV4dC5wcm9jZWVkKEludGVyY2Vw > dG9yQ29udGV4dC5qYXZhOjQyMik8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv > Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t > YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 > O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz > cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQNCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z > ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19vcmcuamJvc3MuYXMuZWpiMy5jb21w > b25lbnQuc2kmYW1wO2Q9RHdNRmFRJmFtcDtjPVZ4dDVlME9zdnZ0MmdmbHdTbHNKNURtUEdjUHZU > UktMSnlwMDMxclhqaGcmYW1wO3I9RmlQaEwwQ2wxeW1abG5UeUFJSUw3NXRFNEwwcmVIY0RkRC03 > d1V0VUdIQSZhbXA7bT1iZi1PbzE0ZkJ3R05obnlzbldsVDVOTTlWdTBQVkpOQkNoN2VNWklPa2pR > JmFtcDtzPTFlUFJmQTVTcmVhR2JUVFNWM0xJSFU5MHZQbW5VVnRnNkpPUXU2dzhibjgmYW1wO2U9 > IiB0YXJnZXQ9Il9ibGFuayI+DQpvcmcuamJvc3MuYXMuZWpiMy5jb21wb25lbnQuc2k8L2E+bmds > ZXRvbi5TaW5nbGV0b25Db21wb25lbnRJbnN0YW5jZUFzc29jaWF0aW9uSW50ZXJjZXB0b3IucHJv > Y2Vzc0ludm9jYXRpb24oU2luZ2xldG9uQ29tcG9uZW50SW5zdGFuY2VBc3NvY2lhdGlvbkludGVy > Y2VwdG9yLmphdmE6NTMpIFt3aWxkZmx5LWVqYjMtMTEuMC4wLkZpbmFsLmphcjoxMS4wLjAuRmlu > YWxdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z > by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz > dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh > bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i > c3A7Jm5ic3A7IGF0IG9yZy5qYm9zcy5pbnZvY2F0aW9uLkludGVyY2VwdG9yQ29udGV4dC5wcm9j > ZWVkKEludGVyY2VwdG9yQ29udGV4dC5qYXZhOjQyMik8L3NwYW4+PG86cD48L286cD48L3A+DQo8 > cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h > cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt > ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz > cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLmpib3NzLmFzLmVq > YjMudHguQ01UVHhJbnRlcmNlcHRvci5pbnZva2VJbk5vVHgoQ01UVHhJbnRlcmNlcHRvci5qYXZh > OjI2NCkgW3dpbGRmbHktZWpiMy0xMS4wLjAuRmluYWwuamFyOjExLjAuMC5GaW5hbF08L3NwYW4+ > PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 > b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 > LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj > b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg > YXQgb3JnLmpib3NzLmFzLmVqYjMudHguQ01UVHhJbnRlcmNlcHRvci5zdXBwb3J0cyhDTVRUeElu > dGVyY2VwdG9yLmphdmE6Mzc5KSBbd2lsZGZseS1lamIzLTExLjAuMC5GaW5hbC5qYXI6MTEuMC4w > LkZpbmFsXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl > PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw > YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 > OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw > OyZuYnNwOyZuYnNwOyBhdCBvcmcuamJvc3MuYXMuZWpiMy50eC5DTVRUeEludGVyY2VwdG9yLnBy > b2Nlc3NJbnZvY2F0aW9uKENNVFR4SW50ZXJjZXB0b3IuamF2YToyNDQpIFt3aWxkZmx5LWVqYjMt > MTEuMC4wLkZpbmFsLmphcjoxMS4wLjAuRmluYWxdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg > Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn > aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh > bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 > Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9yZy5qYm9zcy5pbnZvY2F0 > aW9uLkludGVyY2VwdG9yQ29udGV4dC5wcm9jZWVkKEludGVyY2VwdG9yQ29udGV4dC5qYXZhOjQy > Mik8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv > LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 > eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu > cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz > cDsmbmJzcDsgYXQgb3JnLmpib3NzLmludm9jYXRpb24uSW50ZXJjZXB0b3JDb250ZXh0JEludm9j > YXRpb24ucHJvY2VlZChJbnRlcmNlcHRvckNvbnRleHQuamF2YTo1MDkpPC9zcGFuPjxvOnA+PC9v > OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph > dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx > LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG > NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9yZy5q > Ym9zcy53ZWxkLmVqYi5BYnN0cmFjdEVKQlJlcXVlc3RTY29wZUFjdGl2YXRpb25JbnRlcmNlcHRv > ci5hcm91bmRJbnZva2UoQWJzdHJhY3RFSkJSZXF1ZXN0U2NvcGVBY3RpdmF0aW9uSW50ZXJjZXB0 > b3IuamF2YTo3MykNCiBbd2VsZC1jb3JlLWltcGwtMi40LjMuRmluYWwuamFyOjIuNC4zLkZpbmFs > XTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t > bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 > bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z > LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw > OyZuYnNwOyBhdCBvcmcuamJvc3MuYXMud2VsZC5lamIuRWpiUmVxdWVzdFNjb3BlQWN0aXZhdGlv > bkludGVyY2VwdG9yLnByb2Nlc3NJbnZvY2F0aW9uKEVqYlJlcXVlc3RTY29wZUFjdGl2YXRpb25J > bnRlcmNlcHRvci5qYXZhOjg5KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O > b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h > bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 > Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw > OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcuamJvc3MuaW52b2NhdGlvbi5JbnRlcmNl > cHRvckNvbnRleHQucHJvY2VlZChJbnRlcmNlcHRvckNvbnRleHQuamF2YTo0MjIpPC9zcGFuPjxv > OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w > LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z > aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s > b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0 > DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 > cC0zQV9fb3JnLmpib3NzLmFzLmVqYjMuY29tcG9uZW50LmluJmFtcDtkPUR3TUZhUSZhbXA7Yz1W > eHQ1ZTBPc3Z2dDJnZmx3U2xzSjVEbVBHY1B2VFJLTEp5cDAzMXJYamhnJmFtcDtyPUZpUGhMMENs > MXltWmxuVHlBSUlMNzV0RTRMMHJlSGNEZEQtN3dVdFVHSEEmYW1wO209YmYtT28xNGZCd0dOaG55 > c25XbFQ1Tk05VnUwUFZKTkJDaDdlTVpJT2tqUSZhbXA7cz1xWUVoc3V5a1BWTU5WclV5NzFmVnpf > MlRRb0hZckJBZDlZT2dvMUs2ZS1FJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0Kb3JnLmpib3Nz > LmFzLmVqYjMuY29tcG9uZW50LmluPC9hPnRlcmNlcHRvcnMuQ3VycmVudEludm9jYXRpb25Db250 > ZXh0SW50ZXJjZXB0b3IucHJvY2Vzc0ludm9jYXRpb24oQ3VycmVudEludm9jYXRpb25Db250ZXh0 > SW50ZXJjZXB0b3IuamF2YTo0MSkgW3dpbGRmbHktZWpiMy0xMS4wLjAuRmluYWwuamFyOjExLjAu > MC5GaW5hbF08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls > ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz > cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv > dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz > cDsmbmJzcDsmbmJzcDsgYXQgb3JnLmpib3NzLmludm9jYXRpb24uSW50ZXJjZXB0b3JDb250ZXh0 > LnByb2NlZWQoSW50ZXJjZXB0b3JDb250ZXh0LmphdmE6NDIyKTwvc3Bhbj48bzpwPjwvbzpwPjwv > cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt > c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 > Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi > PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdA0KPGEgaHJlZj0i > aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX29yZy5q > Ym9zcy5hcy5lamIzLmNvbXBvbmVudC5pbiZhbXA7ZD1Ed01GYVEmYW1wO2M9Vnh0NWUwT3N2dnQy > Z2Zsd1Nsc0o1RG1QR2NQdlRSS0xKeXAwMzFyWGpoZyZhbXA7cj1GaVBoTDBDbDF5bVpsblR5QUlJ > TDc1dEU0TDByZUhjRGRELTd3VXRVR0hBJmFtcDttPWJmLU9vMTRmQndHTmhueXNuV2xUNU5NOVZ1 > MFBWSk5CQ2g3ZU1aSU9ralEmYW1wO3M9cVlFaHN1eWtQVk1OVnJVeTcxZlZ6XzJUUW9IWXJCQWQ5 > WU9nbzFLNmUtRSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCm9yZy5qYm9zcy5hcy5lamIzLmNv > bXBvbmVudC5pbjwvYT52b2NhdGlvbm1ldHJpY3MuV2FpdFRpbWVJbnRlcmNlcHRvci5wcm9jZXNz > SW52b2NhdGlvbihXYWl0VGltZUludGVyY2VwdG9yLmphdmE6NDcpIFt3aWxkZmx5LWVqYjMtMTEu > MC4wLkZpbmFsLmphcjoxMS4wLjAuRmluYWxdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh > c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t > Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls > eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i > c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9yZy5qYm9zcy5pbnZvY2F0aW9u > LkludGVyY2VwdG9yQ29udGV4dC5wcm9jZWVkKEludGVyY2VwdG9yQ29udGV4dC5qYXZhOjQyMik8 > L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h > cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl > PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z > ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm > bmJzcDsgYXQgb3JnLmpib3NzLmFzLmVqYjMuc2VjdXJpdHkuU2VjdXJpdHlDb250ZXh0SW50ZXJj > ZXB0b3IucHJvY2Vzc0ludm9jYXRpb24oU2VjdXJpdHlDb250ZXh0SW50ZXJjZXB0b3IuamF2YTox > MDApDQogW3dpbGRmbHktZWpiMy0xMS4wLjAuRmluYWwuamFyOjExLjAuMC5GaW5hbF08L3NwYW4+ > PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 > b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 > LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj > b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg > YXQgb3JnLmpib3NzLmludm9jYXRpb24uSW50ZXJjZXB0b3JDb250ZXh0LnByb2NlZWQoSW50ZXJj > ZXB0b3JDb250ZXh0LmphdmE6NDIyKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN > c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv > bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 > b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu > YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcuamJvc3MuYXMuZWpiMy5kZXBsb3lt > ZW50LnByb2Nlc3NvcnMuU3RhcnR1cEF3YWl0SW50ZXJjZXB0b3IucHJvY2Vzc0ludm9jYXRpb24o > U3RhcnR1cEF3YWl0SW50ZXJjZXB0b3IuamF2YToyMikNCiBbd2lsZGZseS1lamIzLTExLjAuMC5G > aW5hbC5qYXI6MTEuMC4wLkZpbmFsXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN > c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv > bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 > b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu > YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcuamJvc3MuaW52b2NhdGlvbi5JbnRl > cmNlcHRvckNvbnRleHQucHJvY2VlZChJbnRlcmNlcHRvckNvbnRleHQuamF2YTo0MjIpPC9zcGFu > PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t > dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u > dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 > Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 > IGF0DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 > aHR0cC0zQV9fb3JnLmpib3NzLmFzLmVqYjMuY29tcG9uZW50LmluJmFtcDtkPUR3TUZhUSZhbXA7 > Yz1WeHQ1ZTBPc3Z2dDJnZmx3U2xzSjVEbVBHY1B2VFJLTEp5cDAzMXJYamhnJmFtcDtyPUZpUGhM > MENsMXltWmxuVHlBSUlMNzV0RTRMMHJlSGNEZEQtN3dVdFVHSEEmYW1wO209YmYtT28xNGZCd0dO > aG55c25XbFQ1Tk05VnUwUFZKTkJDaDdlTVpJT2tqUSZhbXA7cz1xWUVoc3V5a1BWTU5WclV5NzFm > VnpfMlRRb0hZckJBZDlZT2dvMUs2ZS1FJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0Kb3JnLmpi > b3NzLmFzLmVqYjMuY29tcG9uZW50LmluPC9hPnRlcmNlcHRvcnMuU2h1dERvd25JbnRlcmNlcHRv > ckZhY3RvcnkkMS5wcm9jZXNzSW52b2NhdGlvbihTaHV0RG93bkludGVyY2VwdG9yRmFjdG9yeS5q > YXZhOjY0KSBbd2lsZGZseS1lamIzLTExLjAuMC5GaW5hbC5qYXI6MTEuMC4wLkZpbmFsXTwvc3Bh > bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu > LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv > bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm > O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw > OyBhdCBvcmcuamJvc3MuaW52b2NhdGlvbi5JbnRlcmNlcHRvckNvbnRleHQucHJvY2VlZChJbnRl > cmNlcHRvckNvbnRleHQuamF2YTo0MjIpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 > Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 > dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom > cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 > Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0DQo8YSBocmVmPSJodHRwczovL3VybGRl > ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fb3JnLmpib3NzLmFzLmVqYjMu > Y29tcG9uZW50LmluJmFtcDtkPUR3TUZhUSZhbXA7Yz1WeHQ1ZTBPc3Z2dDJnZmx3U2xzSjVEbVBH > Y1B2VFJLTEp5cDAzMXJYamhnJmFtcDtyPUZpUGhMMENsMXltWmxuVHlBSUlMNzV0RTRMMHJlSGNE > ZEQtN3dVdFVHSEEmYW1wO209YmYtT28xNGZCd0dOaG55c25XbFQ1Tk05VnUwUFZKTkJDaDdlTVpJ > T2tqUSZhbXA7cz1xWUVoc3V5a1BWTU5WclV5NzFmVnpfMlRRb0hZckJBZDlZT2dvMUs2ZS1FJmFt > cDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0Kb3JnLmpib3NzLmFzLmVqYjMuY29tcG9uZW50LmluPC9h > PnRlcmNlcHRvcnMuTG9nZ2luZ0ludGVyY2VwdG9yLnByb2Nlc3NJbnZvY2F0aW9uKExvZ2dpbmdJ > bnRlcmNlcHRvci5qYXZhOjY3KSBbd2lsZGZseS1lamIzLTExLjAuMC5GaW5hbC5qYXI6MTEuMC4w > LkZpbmFsXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl > PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw > YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 > OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw > OyAmbmJzcDsmbmJzcDthdCBvcmcuamJvc3MuaW52b2NhdGlvbi5JbnRlcmNlcHRvckNvbnRleHQu > cHJvY2VlZChJbnRlcmNlcHRvckNvbnRleHQuamF2YTo0MjIpPC9zcGFuPjxvOnA+PC9vOnA+PC9w > Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z > by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm > b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ > Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0DQo8YSBocmVmPSJo > dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fb3JnLmpi > b3NzLmFzLmVlLmNvbXBvbmVudC5OYW1lJmFtcDtkPUR3TUZhUSZhbXA7Yz1WeHQ1ZTBPc3Z2dDJn > Zmx3U2xzSjVEbVBHY1B2VFJLTEp5cDAzMXJYamhnJmFtcDtyPUZpUGhMMENsMXltWmxuVHlBSUlM > NzV0RTRMMHJlSGNEZEQtN3dVdFVHSEEmYW1wO209YmYtT28xNGZCd0dOaG55c25XbFQ1Tk05VnUw > UFZKTkJDaDdlTVpJT2tqUSZhbXA7cz1BY2VuQkEwamxjN2VLcW1qRThLNmFaRnNrdm5CRmpVQmpa > TlhNbzIxbm1rJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0Kb3JnLmpib3NzLmFzLmVlLmNvbXBv > bmVudC5OYW1lPC9hPnNwYWNlQ29udGV4dEludGVyY2VwdG9yLnByb2Nlc3NJbnZvY2F0aW9uKE5h > bWVzcGFjZUNvbnRleHRJbnRlcmNlcHRvci5qYXZhOjUwKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N > CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t > bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u > dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu > YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcuamJvc3MuaW52 > b2NhdGlvbi5JbnRlcmNlcHRvckNvbnRleHQucHJvY2VlZChJbnRlcmNlcHRvckNvbnRleHQuamF2 > YTo0MjIpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 > Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh > biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 > LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 > Jm5ic3A7Jm5ic3A7IGF0IG9yZy5qYm9zcy5pbnZvY2F0aW9uLkNvbnRleHRDbGFzc0xvYWRlcklu > dGVyY2VwdG9yLnByb2Nlc3NJbnZvY2F0aW9uKENvbnRleHRDbGFzc0xvYWRlckludGVyY2VwdG9y > LmphdmE6NjApPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 > bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 > c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 > b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i > c3A7Jm5ic3A7Jm5ic3A7IGF0IG9yZy5qYm9zcy5pbnZvY2F0aW9uLkludGVyY2VwdG9yQ29udGV4 > dC5wcm9jZWVkKEludGVyY2VwdG9yQ29udGV4dC5qYXZhOjQyMik8L3NwYW4+PG86cD48L286cD48 > L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 > bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 > O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE > Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLmpib3Nz > Lmludm9jYXRpb24uSW50ZXJjZXB0b3JDb250ZXh0LnJ1bihJbnRlcmNlcHRvckNvbnRleHQuamF2 > YTo0MzgpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 > Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh > biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 > LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 > Jm5ic3A7Jm5ic3A7IGF0IG9yZy53aWxkZmx5LnNlY3VyaXR5Lm1hbmFnZXIuV2lsZEZseVNlY3Vy > aXR5TWFuYWdlci5kb0NoZWNrZWQoV2lsZEZseVNlY3VyaXR5TWFuYWdlci5qYXZhOjYwOSk8L3Nw > YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp > bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm > b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp > Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz > cDsgYXQgb3JnLmpib3NzLmludm9jYXRpb24uQWNjZXNzQ2hlY2tpbmdJbnRlcmNlcHRvci5wcm9j > ZXNzSW52b2NhdGlvbihBY2Nlc3NDaGVja2luZ0ludGVyY2VwdG9yLmphdmE6NTcpPC9zcGFuPjxv > OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w > LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z > aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s > b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0 > IG9yZy5qYm9zcy5pbnZvY2F0aW9uLkludGVyY2VwdG9yQ29udGV4dC5wcm9jZWVkKEludGVyY2Vw > dG9yQ29udGV4dC5qYXZhOjQyMik8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv > Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t > YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 > O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz > cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLmpib3NzLmludm9jYXRpb24uQ2hhaW5l > ZEludGVyY2VwdG9yLnByb2Nlc3NJbnZvY2F0aW9uKENoYWluZWRJbnRlcmNlcHRvci5qYXZhOjUz > KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t > bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 > bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z > LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw > OyZuYnNwOyBhdCBvcmcuamJvc3MuYXMuZWUuY29tcG9uZW50LlZpZXdTZXJ2aWNlJFZpZXcuaW52 > b2tlKFZpZXdTZXJ2aWNlLmphdmE6MTk4KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz > PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv > dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 > JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw > OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcuamJvc3MuYXMuZWUuY29tcG9u > ZW50LlZpZXdEZXNjcmlwdGlvbiQxLnByb2Nlc3NJbnZvY2F0aW9uKFZpZXdEZXNjcmlwdGlvbi5q > YXZhOjE4NSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls > ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz > cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv > dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz > cDsmbmJzcDsmbmJzcDsgYXQgb3JnLmpib3NzLmFzLmVlLmNvbXBvbmVudC5Qcm94eUludm9jYXRp > b25IYW5kbGVyLmludm9rZShQcm94eUludm9jYXRpb25IYW5kbGVyLmphdmE6ODEpPC9zcGFuPjxv > OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w > LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z > aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s > b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0 > IG9yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwuaW50ZXJmYWNlcy5CYWNrZW5kSW50ZXJuYWwkJCR2 > aWV3NC5ydW5JbnRlcm5hbEFjdGlvbihVbmtub3duIFNvdXJjZSkNCiBbYmxsLmphcjpdPC9zcGFu > PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t > dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u > dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 > Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 > IGF0IHN1bi5yZWZsZWN0LkdlbmVyYXRlZE1ldGhvZEFjY2Vzc29yMTU3Lmludm9rZShVbmtub3du > IFNvdXJjZSkgWzoxLjguMF8xNjFdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z > b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t > LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv > dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i > c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IHN1bi5yZWZsZWN0LkRlbGVnYXRpbmdNZXRo > b2RBY2Nlc3NvckltcGwuaW52b2tlKERlbGVnYXRpbmdNZXRob2RBY2Nlc3NvckltcGwuamF2YTo0 > MykgW3J0LmphcjoxLjguMF8xNjFdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z > b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t > LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv > dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i > c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IGphdmEubGFuZy5yZWZsZWN0Lk1ldGhvZC5p > bnZva2UoTWV0aG9kLmphdmE6NDk4KSBbcnQuamFyOjEuOC4wXzE2MV08L3NwYW4+PG86cD48L286 > cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 > dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu > MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 > OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLmpi > b3NzLndlbGQudXRpbC5yZWZsZWN0aW9uLlJlZmxlY3Rpb25zLmludm9rZUFuZFVud3JhcChSZWZs > ZWN0aW9ucy5qYXZhOjQzMykgW3dlbGQtY29yZS1pbXBsLTIuNC4zLkZpbmFsLmphcjoyLjQuMy5G > aW5hbF08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i > bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu > IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss > c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm > bmJzcDsmbmJzcDsgYXQgb3JnLmpib3NzLndlbGQuYmVhbi5wcm94eS5FbnRlcnByaXNlQmVhblBy > b3h5TWV0aG9kSGFuZGxlci5pbnZva2UoRW50ZXJwcmlzZUJlYW5Qcm94eU1ldGhvZEhhbmRsZXIu > amF2YToxMjcpDQogW3dlbGQtY29yZS1pbXBsLTIuNC4zLkZpbmFsLmphcjoyLjQuMy5GaW5hbF08 > L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h > cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl > PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z > ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm > bmJzcDsgYXQgb3JnLmpib3NzLndlbGQuYmVhbi5wcm94eS5FbnRlcnByaXNlVGFyZ2V0QmVhbklu > c3RhbmNlLmludm9rZShFbnRlcnByaXNlVGFyZ2V0QmVhbkluc3RhbmNlLmphdmE6NTYpDQogW3dl > bGQtY29yZS1pbXBsLTIuNC4zLkZpbmFsLmphcjoyLjQuMy5GaW5hbF08L3NwYW4+PG86cD48L286 > cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 > dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu > MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 > OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLmpi > b3NzLndlbGQuYmVhbi5wcm94eS5JbmplY3Rpb25Qb2ludFByb3BhZ2F0aW5nRW50ZXJwcmlzZVRh > cmdldEJlYW5JbnN0YW5jZS5pbnZva2UoSW5qZWN0aW9uUG9pbnRQcm9wYWdhdGluZ0VudGVycHJp > c2VUYXJnZXRCZWFuSW5zdGFuY2UuamF2YTo2NykNCiBbd2VsZC1jb3JlLWltcGwtMi40LjMuRmlu > YWwuamFyOjIuNC4zLkZpbmFsXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O > b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h > bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 > Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw > OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcuamJvc3Mud2VsZC5iZWFuLnByb3h5LlBy > b3h5TWV0aG9kSGFuZGxlci5pbnZva2UoUHJveHlNZXRob2RIYW5kbGVyLmphdmE6MTAwKSBbd2Vs > ZC1jb3JlLWltcGwtMi40LjMuRmluYWwuamFyOjIuNC4zLkZpbmFsXTwvc3Bhbj48bzpwPjwvbzpw > PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 > bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w > cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 > N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBvcmcub3Zp > cnQuZW5naW5lLmNvcmUuYmxsLkJhY2tlbmRDb21tYW5kT2JqZWN0c0hhbmRsZXIkQmFja2VuZElu > dGVybmFsJEJhY2tlbmRMb2NhbCQyMDQ5MjU5NjE4JFByb3h5JF8kJF9XZWxkJEVudGVycHJpc2VQ > cm94eSQucnVuSW50ZXJuYWxBY3Rpb24oVW5rbm93bg0KIFNvdXJjZSkgW2JsbC5qYXI6XTwvc3Bh > bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu > LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv > bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm > O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw > OyBhdCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLlZkc0V2ZW50TGlzdGVuZXIucmVmcmVzaEhv > c3RDYXBhYmlsaXRpZXMoVmRzRXZlbnRMaXN0ZW5lci5qYXZhOjU5OCkNCiBbYmxsLmphcjpdPC9z > cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn > aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i > Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy > aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i > c3A7IGF0IG9yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuSG9zdENvbm5lY3Rpb25SZWZy > ZXNoZXIkU3Vic2NyaWJlclJlZnJlc2hpbmdIb3N0T25Ib3N0Q29ubmVjdGlvbkNoYW5nZUV2ZW50 > Lm9uTmV4dChIb3N0Q29ubmVjdGlvblJlZnJlc2hlci5qYXZhOjQ3KQ0KIFt2ZHNicm9rZXIuamFy > Ol08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv > LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 > eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu > cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz > cDsmbmJzcDsgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci5Ib3N0Q29ubmVjdGlv > blJlZnJlc2hlciRTdWJzY3JpYmVyUmVmcmVzaGluZ0hvc3RPbkhvc3RDb25uZWN0aW9uQ2hhbmdl > RXZlbnQub25OZXh0KEhvc3RDb25uZWN0aW9uUmVmcmVzaGVyLmphdmE6MzApDQogW3Zkc2Jyb2tl > ci5qYXI6XTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl > PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw > YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 > OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw > OyZuYnNwOyZuYnNwOyBhdCBvcmcub3ZpcnQudmRzbS5qc29ucnBjLmNsaWVudC5ldmVudHMuRXZl > bnRQdWJsaXNoZXIkRXZlbnRDYWxsYWJsZS5jYWxsKEV2ZW50UHVibGlzaGVyLmphdmE6MTE4KQ0K > IFt2ZHNtLWpzb25ycGMtamF2YS1jbGllbnQuamFyOl08L3NwYW4+PG86cD48L286cD48L3A+DQo8 > cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h > cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt > ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz > cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgb3JnLm92aXJ0LnZkc20u > anNvbnJwYy5jbGllbnQuZXZlbnRzLkV2ZW50UHVibGlzaGVyJEV2ZW50Q2FsbGFibGUuY2FsbChF > dmVudFB1Ymxpc2hlci5qYXZhOjkzKQ0KIFt2ZHNtLWpzb25ycGMtamF2YS1jbGllbnQuamFyOl08 > L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h > cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl > PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z > ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm > bmJzcDsgYXQgamF2YS51dGlsLmNvbmN1cnJlbnQuRm9ya0pvaW5UYXNrJEFkYXB0ZWRDYWxsYWJs > ZS5leGVjKEZvcmtKb2luVGFzay5qYXZhOjE0MjQpIFtydC5qYXI6MS44LjBfMTYxXTwvc3Bhbj48 > bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv > cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt > c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv > bG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBh > dCBqYXZhLnV0aWwuY29uY3VycmVudC5Gb3JrSm9pblRhc2suZG9FeGVjKEZvcmtKb2luVGFzay5q > YXZhOjI4OSkgW3J0LmphcjoxLjguMF8xNjFdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh > c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t > Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls > eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i > c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IGphdmEudXRpbC5jb25jdXJyZW50 > LkZvcmtKb2luUG9vbCRXb3JrUXVldWUucnVuVGFzayhGb3JrSm9pblBvb2wuamF2YToxMDU2KSBb > cnQuamFyOjEuOC4wXzE2MV08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y > bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 > OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh > bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm > bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQgamF2YS51dGlsLmNvbmN1cnJlbnQuRm9ya0pvaW5Q > b29sLnJ1bldvcmtlcihGb3JrSm9pblBvb2wuamF2YToxNjkyKSBbcnQuamFyOjEuOC4wXzE2MV08 > L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h > cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl > PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z > ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm > bmJzcDsgYXQgamF2YS51dGlsLmNvbmN1cnJlbnQuRm9ya0pvaW5Xb3JrZXJUaHJlYWQucnVuKEZv > cmtKb2luV29ya2VyVGhyZWFkLmphdmE6MTU3KSBbcnQuamFyOjEuOC4wXzE2MV08L3NwYW4+PG86 > cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At > YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp > emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv > cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y > bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 > OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh > bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4yMDE4LTA1LTAyIDE0OjQwOjIz > LDg1MS0wNyBXQVJOJm5ic3A7IFtjb20uYXJqdW5hLmF0cy5hcmp1bmFdIChGb3JrSm9pblBvb2wt > MS13b3JrZXItMTQpIEFSSlVOQTAxMjA3NzogQWJvcnQNCiBjYWxsZWQgb24gYWxyZWFkeSBhYm9y > dGVkIGF0b21pYyBhY3Rpb24gMDpmZmZmN2YwMDAwMDE6LTIxYmQ4ODAwOjVhZTkwYzQ4OjEwYWZh > PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t > YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls > ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt > c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh > c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t > Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls > eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z > cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn > aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i > Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy > aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 > Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 > dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom > cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu > PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t > dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u > dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 > Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z > b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t > LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv > dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kIHRoZSBFTkdJTkUg > bG9nOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt > c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g > c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz > YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw > IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy > Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m > YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjIwMTgt > MDUtMDIgMTQ6NDA6MjMsODUxLTA3IElORk8mbmJzcDsgW29yZy5vdmlydC5lbmdpbmUuY29yZS51 > dGlscy50cmFuc2FjdGlvbi5UcmFuc2FjdGlvblN1cHBvcnRdIChGb3JrSm9pblBvb2wtMS13b3Jr > ZXItMTQpDQogWzUyMjc2ZGY1XSB0cmFuc2FjdGlvbiByb2xsZWQgYmFjazwvc3Bhbj48bzpwPjwv > bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 > YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox > MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx > RjQ5N0QiPjIwMTgtMDUtMDIgMTQ6NDA6MjMsODUxLTA3IEVSUk9SIFtvcmcub3ZpcnQuZW5naW5l > LmNvcmUudmRzYnJva2VyLlZkc01hbmFnZXJdIChGb3JrSm9pblBvb2wtMS13b3JrZXItMTQpDQog > WzUyMjc2ZGY1XSBVbmFibGUgdG8gUmVmcmVzaENhcGFiaWxpdGllczogSWxsZWdhbFN0YXRlRXhj > ZXB0aW9uOiBUcmFuc2FjdGlvbiBMb2NhbCB0cmFuc2FjdGlvbiAoZGVsZWdhdGU9VHJhbnNhY3Rp > b25JbXBsZSAmbHQ7IGFjLCBCYXNpY0FjdGlvbjogMDpmZmZmN2YwMDAwMDE6LTIxYmQ4ODAwOjVh > ZTkwYzQ4OjEwYWZhIHN0YXR1czogQWN0aW9uU3RhdHVzLkFCT1JURUQgJmd0Oywgb3duZXI9TG9j > YWwgdHJhbnNhY3Rpb24gY29udGV4dCBmb3IgcHJvdmlkZXINCiBKQm9zcyBKVEEgdHJhbnNhY3Rp > b24gcHJvdmlkZXIpIGlzIG5vdCBhY3RpdmUgU1RBVFVTX1JPTExFREJBQ0s8L3NwYW4+PG86cD48 > L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 > OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 > MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj > MUY0OTdEIj4yMDE4LTA1LTAyIDE0OjQwOjIzLDg4OC0wNyBJTkZPJm5ic3A7IFtvcmcub3ZpcnQu > ZW5naW5lLmNvcmUuYmxsLkhhbmRsZVZkc0NwdUZsYWdzT3JDbHVzdGVyQ2hhbmdlZENvbW1hbmRd > DQogKEZvcmtKb2luUG9vbC0xLXdvcmtlci0xNCkgWzVjNTExZTUxXSBSdW5uaW5nIGNvbW1hbmQ6 > IEhhbmRsZVZkc0NwdUZsYWdzT3JDbHVzdGVyQ2hhbmdlZENvbW1hbmQgaW50ZXJuYWw6IHRydWUu > IEVudGl0aWVzIGFmZmVjdGVkIDombmJzcDsgSUQ6IDc0ZGZlOTY1LWNiMTEtNDk1YS05NmEwLTNk > YWU2YjNjYmQ3NSBUeXBlOiBWRFM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv > Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t > YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 > O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4yMDE4LTA1LTAyIDE0OjQw > OjIzLDg5NS0wNyBJTkZPJm5ic3A7IFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLkhhbmRsZVZk > c1ZlcnNpb25Db21tYW5kXSAoRm9ya0pvaW5Qb29sLTEtd29ya2VyLTE0KQ0KIFsyYTBlYzkwYl0g > UnVubmluZyBjb21tYW5kOiBIYW5kbGVWZHNWZXJzaW9uQ29tbWFuZCBpbnRlcm5hbDogdHJ1ZS4g > RW50aXRpZXMgYWZmZWN0ZWQgOiZuYnNwOyBJRDogNzRkZmU5NjUtY2IxMS00OTVhLTk2YTAtM2Rh > ZTZiM2NiZDc1IFR5cGU6IFZEUzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O > b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h > bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 > Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjIwMTgtMDUtMDIgMTQ6NDA6 > MjMsODk4LTA3IElORk8mbmJzcDsgW29yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwuUmVmcmVzaEhv > c3RDYXBhYmlsaXRpZXNDb21tYW5kXSAoRm9ya0pvaW5Qb29sLTEtd29ya2VyLTE0KQ0KIFsyYTBl > YzkwYl0gUmVmcmVzaCBob3N0IGNhcGFiaWxpdGllcyBmaW5pc2hlZC4gTG9jayByZWxlYXNlZC4g > TW9uaXRvcmluZyBjYW4gcnVuIG5vdyBmb3IgaG9zdCAnb3Zub2RlMTAyIGZyb20gZGF0YS1jZW50 > ZXIgJ0RlZmF1bHQnPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg > c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv > Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp > JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+MjAxOC0wNS0wMiAxNDo0MDoyMyw4OTgt > MDcgRVJST1IgW29yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwuUmVmcmVzaEhvc3RDYXBhYmlsaXRp > ZXNDb21tYW5kXSAoRm9ya0pvaW5Qb29sLTEtd29ya2VyLTE0KQ0KIFsyYTBlYzkwYl0gQ29tbWFu > ZCAnb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5SZWZyZXNoSG9zdENhcGFiaWxpdGllc0NvbW1h > bmQnIGZhaWxlZDogQ291bGQgbm90IGdldCBKREJDIENvbm5lY3Rpb247IG5lc3RlZCBleGNlcHRp > b24gaXMgamF2YS5zcWwuU1FMRXhjZXB0aW9uOiBqYXZheC5yZXNvdXJjZS5SZXNvdXJjZUV4Y2Vw > dGlvbjogSUowMDA0NTc6IFVuY2hlY2tlZCB0aHJvd2FibGUgaW4gbWFuYWdlZENvbm5lY3Rpb25S > ZWNvbm5lY3RlZCgpDQo8YSBocmVmPSJtYWlsdG86Y2w9b3JnLmpib3NzLmpjYS5jb3JlLmNvbm5l > Y3Rpb25tYW5hZ2VyLmxpc3RlbmVyLlR4Q29ubmVjdGlvbkxpc3RlbmVyQDFmYWI4NGQ3W3N0YXRl > PU5PUk1BTCIgdGFyZ2V0PSJfYmxhbmsiPg0KY2w9b3JnLmpib3NzLmpjYS5jb3JlLmNvbm5lY3Rp > b25tYW5hZ2VyLmxpc3RlbmVyLlR4Q29ubmVjdGlvbkxpc3RlbmVyQDFmYWI4NGQ3W3N0YXRlPU5P > Uk1BTDwvYT4gbWFuYWdlZA0KPGEgaHJlZj0ibWFpbHRvOmNvbm5lY3Rpb249b3JnLmpib3NzLmpj > YS5hZGFwdGVycy5qZGJjLmxvY2FsLkxvY2FsTWFuYWdlZENvbm5lY3Rpb25AM2YzN2NmMTAiIHRh > cmdldD0iX2JsYW5rIj4NCmNvbm5lY3Rpb249b3JnLmpib3NzLmpjYS5hZGFwdGVycy5qZGJjLmxv > Y2FsLkxvY2FsTWFuYWdlZENvbm5lY3Rpb25AM2YzN2NmMTA8L2E+IGNvbm5lY3Rpb24gaGFuZGxl > cz0wIGxhc3RSZXR1cm5lZD0xNTI1Mjk3MjIzODQ3IGxhc3RWYWxpZGF0ZWQ9MTUyNTI5MDI2Nzgx > MSBsYXN0Q2hlY2tlZE91dD0xNTI1Mjk2OTIzNzcwIHRyYWNrQnlUeD1mYWxzZQ0KPGEgaHJlZj0i > bWFpbHRvOnBvb2w9b3JnLmpib3NzLmpjYS5jb3JlLmNvbm5lY3Rpb25tYW5hZ2VyLnBvb2wuc3Ry > YXRlZ3kuT25lUG9vbEAyMDU1MGYzNSIgdGFyZ2V0PSJfYmxhbmsiPg0KcG9vbD1vcmcuamJvc3Mu > amNhLmNvcmUuY29ubmVjdGlvbm1hbmFnZXIucG9vbC5zdHJhdGVneS5PbmVQb29sQDIwNTUwZjM1 > PC9hPiBtY3A9U2VtYXBob3JlQ29uY3VycmVudExpbmtlZFF1ZXVlTWFuYWdlZENvbm5lY3Rpb25Q > b29sQDViYWE5MGZbcG9vbD1FTkdJTkVEYXRhU291cmNlXSB4YVJlc291cmNlPUxvY2FsWEFSZXNv > dXJjZUltcGxAMjRhN2ZjMGJbY29ubmVjdGlvbkxpc3RlbmVyPTFmYWI4NGQ3IGNvbm5lY3Rpb25N > YW5hZ2VyPTViZWM3MGQyDQogd2FybmVkPWZhbHNlIGN1cnJlbnRYaWQ9bnVsbCBwcm9kdWN0TmFt > ZT1Qb3N0Z3JlU1FMIHByb2R1Y3RWZXJzaW9uPTkuNS45IGpuZGlOYW1lPWphdmE6L0VOR0lORURh > dGFTb3VyY2VdIHR4U3luYz1udWxsXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN > c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv > bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 > b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjIwMTgtMDUtMDIgMTQ6 > NDA6MjMsODk4LTA3IEVSUk9SIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLlJlZnJlc2hIb3N0 > Q2FwYWJpbGl0aWVzQ29tbWFuZF0gKEZvcmtKb2luUG9vbC0xLXdvcmtlci0xNCkNCiBbMmEwZWM5 > MGJdIEV4Y2VwdGlvbjogb3JnLnNwcmluZ2ZyYW1ld29yay5qZGJjLkNhbm5vdEdldEpkYmNDb25u > ZWN0aW9uRXhjZXB0aW9uOiBDb3VsZCBub3QgZ2V0IEpEQkMgQ29ubmVjdGlvbjsgbmVzdGVkIGV4 > Y2VwdGlvbiBpcyBqYXZhLnNxbC5TUUxFeGNlcHRpb246IGphdmF4LnJlc291cmNlLlJlc291cmNl > RXhjZXB0aW9uOiBJSjAwMDQ1NzogVW5jaGVja2VkIHRocm93YWJsZSBpbiBtYW5hZ2VkQ29ubmVj > dGlvblJlY29ubmVjdGVkKCkNCjxhIGhyZWY9Im1haWx0bzpjbD1vcmcuamJvc3MuamNhLmNvcmUu > Y29ubmVjdGlvbm1hbmFnZXIubGlzdGVuZXIuVHhDb25uZWN0aW9uTGlzdGVuZXJAMWZhYjg0ZDdb > c3RhdGU9Tk9STUFMIiB0YXJnZXQ9Il9ibGFuayI+DQpjbD1vcmcuamJvc3MuamNhLmNvcmUuY29u > bmVjdGlvbm1hbmFnZXIubGlzdGVuZXIuVHhDb25uZWN0aW9uTGlzdGVuZXJAMWZhYjg0ZDdbc3Rh > dGU9Tk9STUFMPC9hPiBtYW5hZ2VkDQo8YSBocmVmPSJtYWlsdG86Y29ubmVjdGlvbj1vcmcuamJv > c3MuamNhLmFkYXB0ZXJzLmpkYmMubG9jYWwuTG9jYWxNYW5hZ2VkQ29ubmVjdGlvbkAzZjM3Y2Yx > MCIgdGFyZ2V0PSJfYmxhbmsiPg0KY29ubmVjdGlvbj1vcmcuamJvc3MuamNhLmFkYXB0ZXJzLmpk > YmMubG9jYWwuTG9jYWxNYW5hZ2VkQ29ubmVjdGlvbkAzZjM3Y2YxMDwvYT4gY29ubmVjdGlvbiBo > YW5kbGVzPTAgbGFzdFJldHVybmVkPTE1MjUyOTcyMjM4NDcgbGFzdFZhbGlkYXRlZD0xNTI1Mjkw > MjY3ODExIGxhc3RDaGVja2VkT3V0PTE1MjUyOTY5MjM3NzAgdHJhY2tCeVR4PWZhbHNlDQo8YSBo > cmVmPSJtYWlsdG86cG9vbD1vcmcuamJvc3MuamNhLmNvcmUuY29ubmVjdGlvbm1hbmFnZXIucG9v > bC5zdHJhdGVneS5PbmVQb29sQDIwNTUwZjM1IiB0YXJnZXQ9Il9ibGFuayI+DQpwb29sPW9yZy5q > Ym9zcy5qY2EuY29yZS5jb25uZWN0aW9ubWFuYWdlci5wb29sLnN0cmF0ZWd5Lk9uZVBvb2xAMjA1 > NTBmMzU8L2E+IG1jcD1TZW1hcGhvcmVDb25jdXJyZW50TGlua2VkUXVldWVNYW5hZ2VkQ29ubmVj > dGlvblBvb2xANWJhYTkwZltwb29sPUVOR0lORURhdGFTb3VyY2VdIHhhUmVzb3VyY2U9TG9jYWxY > QVJlc291cmNlSW1wbEAyNGE3ZmMwYltjb25uZWN0aW9uTGlzdGVuZXI9MWZhYjg0ZDcgY29ubmVj > dGlvbk1hbmFnZXI9NWJlYzcwZDINCiB3YXJuZWQ9ZmFsc2UgY3VycmVudFhpZD1udWxsIHByb2R1 > Y3ROYW1lPVBvc3RncmVTUUwgcHJvZHVjdFZlcnNpb249OS41Ljkgam5kaU5hbWU9amF2YTovRU5H > SU5FRGF0YVNvdXJjZV0gdHhTeW5jPW51bGxdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh > c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t > Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls > eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i > c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9yZy5zcHJpbmdmcmFtZXdvcmsu > amRiYy5kYXRhc291cmNlLkRhdGFTb3VyY2VVdGlscy5nZXRDb25uZWN0aW9uKERhdGFTb3VyY2VV > dGlscy5qYXZhOjgwKQ0KIFtzcHJpbmctamRiYy5qYXI6NC4zLjkuUkVMRUFTRV08L3NwYW4+PG86 > cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At > YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp > emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv > cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQg > b3JnLnNwcmluZ2ZyYW1ld29yay5qZGJjLmNvcmUuSmRiY1RlbXBsYXRlLmV4ZWN1dGUoSmRiY1Rl > bXBsYXRlLmphdmE6NjE5KSBbc3ByaW5nLWpkYmMuamFyOjQuMy45LlJFTEVBU0VdPC9zcGFuPjxv > OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w > LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z > aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s > b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0 > IG9yZy5zcHJpbmdmcmFtZXdvcmsuamRiYy5jb3JlLkpkYmNUZW1wbGF0ZS5xdWVyeShKZGJjVGVt > cGxhdGUuamF2YTo2ODQpIFtzcHJpbmctamRiYy5qYXI6NC4zLjkuUkVMRUFTRV08L3NwYW4+PG86 > cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At > YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp > emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv > cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXQg > b3JnLnNwcmluZ2ZyYW1ld29yay5qZGJjLmNvcmUuSmRiY1RlbXBsYXRlLnF1ZXJ5KEpkYmNUZW1w > bGF0ZS5qYXZhOjcxNikgW3NwcmluZy1qZGJjLmphcjo0LjMuOS5SRUxFQVNFXTwvc3Bhbj48bzpw > PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h > bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 > ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y > OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhdCBv > cmcuc3ByaW5nZnJhbWV3b3JrLmpkYmMuY29yZS5KZGJjVGVtcGxhdGUucXVlcnkoSmRiY1RlbXBs > YXRlLmphdmE6NzY2KSBbc3ByaW5nLWpkYmMuamFyOjQuMy45LlJFTEVBU0VdPC9zcGFuPjxvOnA+ > PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs > dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl > OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 > IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0IG9y > Zy5vdmlydC5lbmdpbmUuY29yZS5kYWwuZGJicm9rZXIuUG9zdGdyZXNEYkVuZ2luZURpYWxlY3Qk > UG9zdGdyZXNTaW1wbGVKZGJjQ2FsbC5leGVjdXRlQ2FsbEludGVybmFsKFBvc3RncmVzRGJFbmdp > bmVEaWFsZWN0LmphdmE6MTUyKQ0KIFtkYWwuamFyOl08L3NwYW4+PG86cD48L286cD48L3A+DQo8 > cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h > cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt > ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4uPC9z > cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn > aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i > Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy > aWY7Y29sb3I6IzFGNDk3RCI+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O > b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h > bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 > Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi48L3NwYW4+PG86cD48L286 > cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 > dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu > MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 > OTdEIj4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 > Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh > biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 > LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+MjAxOC0wNS0wMiAxNDo0MDoyMyw5MDctMDcgRVJS > T1IgW29yZy5vdmlydC5lbmdpbmUuY29yZS5kYWwuZGJicm9rZXIuYXVkaXRsb2doYW5kbGluZy5B > dWRpdExvZ0RpcmVjdG9yXQ0KIChGb3JrSm9pblBvb2wtMS13b3JrZXItMTQpIFsyYTBlYzkwYl0g > RVZFTlRfSUQ6IEhPU1RfUkVGUkVTSF9DQVBBQklMSVRJRVNfRkFJTEVEKDYwNyksIEZhaWxlZCB0 > byByZWZyZXNoIHRoZSBjYXBhYmlsaXRpZXMgb2YgaG9zdCBvdm5vZGUxMDIuPC9zcGFuPjxvOnA+ > PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs > dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl > OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 > IzFGNDk3RCI+MjAxOC0wNS0wMiAxNDo0MDoyMyw5MDctMDcgSU5GTyZuYnNwOyBbb3JnLm92aXJ0 > LmVuZ2luZS5jb3JlLmJsbC5SZWZyZXNoSG9zdENhcGFiaWxpdGllc0NvbW1hbmRdIChGb3JrSm9p > blBvb2wtMS13b3JrZXItMTQpDQogWzJhMGVjOTBiXSBMb2NrIGZyZWVkIHRvIG9iamVjdCAnRW5n > aW5lTG9jazp7ZXhjbHVzaXZlTG9ja3M9J1s3NGRmZTk2NS1jYjExLTQ5NWEtOTZhMC0zZGFlNmIz > Y2JkNzU9VkRTLCBIT1NUX05FVFdPUks3NGRmZTk2NS1jYjExLTQ5NWEtOTZhMC0zZGFlNmIzY2Jk > NzU9SE9TVF9ORVRXT1JLXScsIHNoYXJlZExvY2tzPScnfSc8L3NwYW4+PG86cD48L286cD48L3A+ > DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv > LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv > bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4y > MDE4LTA1LTAyIDE0OjQwOjI1LDc3NS0wNyBJTkZPJm5ic3A7IFtvcmcub3ZpcnQuZW5naW5lLmNv > cmUudmRzYnJva2VyLnZkc2Jyb2tlci5HZXRIYXJkd2FyZUluZm9Bc3luY1ZEU0NvbW1hbmRdDQog > KEVFLU1hbmFnZWRUaHJlYWRGYWN0b3J5LWVuZ2luZVNjaGVkdWxlZC1UaHJlYWQtMzEpIFtdIFNU > QVJULCBHZXRIYXJkd2FyZUluZm9Bc3luY1ZEU0NvbW1hbmQoSG9zdE5hbWUgPSBvdm5vZGUxMDIs > IFZkc0lkQW5kVmRzVkRTQ29tbWFuZFBhcmFtZXRlcnNCYXNlOntob3N0SWQ9Jzc0ZGZlOTY1LWNi > MTEtNDk1YS05NmEwLTNkYWU2YjNjYmQ3NScsIHZkcz0nSG9zdFtvdm5vZGUxMDIsNzRkZmU5NjUt > Y2IxMS00OTVhLTk2YTAtM2RhZTZiM2NiZDc1XSd9KSwNCiBsb2cgaWQ6IDMwMGY3MzQ1PC9zcGFu > PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t > dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u > dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 > Y29sb3I6IzFGNDk3RCI+MjAxOC0wNS0wMiAxNDo0MDoyNSw3NzUtMDcgSU5GTyZuYnNwOyBbb3Jn > Lm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuR2V0SGFyZHdhcmVJbmZvQXN5 > bmNWRFNDb21tYW5kXQ0KIChFRS1NYW5hZ2VkVGhyZWFkRmFjdG9yeS1lbmdpbmVTY2hlZHVsZWQt > VGhyZWFkLTMxKSBbXSBGSU5JU0gsIEdldEhhcmR3YXJlSW5mb0FzeW5jVkRTQ29tbWFuZCwgbG9n > IGlkOiAzMDBmNzM0NTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi > IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 > byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy > aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjIwMTgtMDUtMDIgMTQ6NDA6MjUsODAy > LTA3IElORk8mbmJzcDsgW29yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwuU2V0Tm9uT3BlcmF0aW9u > YWxWZHNDb21tYW5kXSAoRUUtTWFuYWdlZFRocmVhZEZhY3RvcnktZW5naW5lU2NoZWR1bGVkLVRo > cmVhZC0zMSkNCiBbZjJlZjIxZV0gUnVubmluZyBjb21tYW5kOiBTZXROb25PcGVyYXRpb25hbFZk > c0NvbW1hbmQgaW50ZXJuYWw6IHRydWUuIEVudGl0aWVzIGFmZmVjdGVkIDombmJzcDsgSUQ6IDc0 > ZGZlOTY1LWNiMTEtNDk1YS05NmEwLTNkYWU2YjNjYmQ3NSBUeXBlOiBWRFM8L3NwYW4+PG86cD48 > L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 > OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 > MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj > MUY0OTdEIj4yMDE4LTA1LTAyIDE0OjQwOjI1LDgwNS0wNyBJTkZPJm5ic3A7IFtvcmcub3ZpcnQu > ZW5naW5lLmNvcmUudmRzYnJva2VyLlNldFZkc1N0YXR1c1ZEU0NvbW1hbmRdIChFRS1NYW5hZ2Vk > VGhyZWFkRmFjdG9yeS1lbmdpbmVTY2hlZHVsZWQtVGhyZWFkLTMxKQ0KIFtmMmVmMjFlXSBTVEFS > VCwgU2V0VmRzU3RhdHVzVkRTQ29tbWFuZChIb3N0TmFtZSA9IG92bm9kZTEwMi4sIFNldFZkc1N0 > YXR1c1ZEU0NvbW1hbmRQYXJhbWV0ZXJzOntob3N0SWQ9Jzc0ZGZlOTY1LWNiMTEtNDk1YS05NmEw > LTNkYWU2YjNjYmQ3NScsIHN0YXR1cz0nTm9uT3BlcmF0aW9uYWwnLCBub25PcGVyYXRpb25hbFJl > YXNvbj0nTkVUV09SS19VTlJFQUNIQUJMRScsIHN0b3BTcG1GYWlsdXJlTG9nZ2VkPSdmYWxzZScs > IG1haW50ZW5hbmNlUmVhc29uPSdudWxsJ30pLA0KIGxvZyBpZDogNzYxMWQ4ZDg8L3NwYW4+PG86 > cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At > YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp > emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv > cjojMUY0OTdEIj4yMDE4LTA1LTAyIDE0OjQwOjU2LDcyMi0wNyBJTkZPJm5ic3A7IFs8YSBocmVm > PSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fb3Jn > Lm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5wcm8mYW1wO2Q9RHdNRmFRJmFtcDtjPVZ4dDVlME9zdnZ0 > MmdmbHdTbHNKNURtUEdjUHZUUktMSnlwMDMxclhqaGcmYW1wO3I9RmlQaEwwQ2wxeW1abG5UeUFJ > SUw3NXRFNEwwcmVIY0RkRC03d1V0VUdIQSZhbXA7bT1iZi1PbzE0ZkJ3R05obnlzbldsVDVOTTlW > dTBQVkpOQkNoN2VNWklPa2pRJmFtcDtzPVdEQlJra3Iyb00zcHFBTS1vQTZHSDRpbDdJakFBNnUz > UGltOGczWmY0bFUmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+b3JnLm92aXJ0LmVuZ2luZS5jb3Jl > LmJsbC5wcm88L2E+dmlkZXIubmV0d29yay5TeW5jTmV0d29ya1Byb3ZpZGVyQ29tbWFuZF0NCiAo > RUUtTWFuYWdlZFRocmVhZEZhY3RvcnktZW5naW5lU2NoZWR1bGVkLVRocmVhZC01OCkgWzMzYmRk > YTdmXSBMb2NrIEFjcXVpcmVkIHRvIG9iamVjdCAnRW5naW5lTG9jazp7ZXhjbHVzaXZlTG9ja3M9 > J1tmNTBiZDA4MS03YzViLTQxNjEtYTA0NS0wNjhmODVkMmE0NzY9UFJPVklERVJdJywgc2hhcmVk > TG9ja3M9Jyd9Jzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 > eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ > PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx > dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjIwMTgtMDUtMDIgMTQ6NDA6NTYsNzMyLTA3 > IElORk8mbmJzcDsgWzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 > Mi91cmw/dT1odHRwLTNBX19vcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLnBybyZhbXA7ZD1Ed01G > YVEmYW1wO2M9Vnh0NWUwT3N2dnQyZ2Zsd1Nsc0o1RG1QR2NQdlRSS0xKeXAwMzFyWGpoZyZhbXA7 > cj1GaVBoTDBDbDF5bVpsblR5QUlJTDc1dEU0TDByZUhjRGRELTd3VXRVR0hBJmFtcDttPWJmLU9v > MTRmQndHTmhueXNuV2xUNU5NOVZ1MFBWSk5CQ2g3ZU1aSU9ralEmYW1wO3M9V0RCUmtrcjJvTTNw > cUFNLW9BNkdINGlsN0lqQUE2dTNQaW04ZzNaZjRsVSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5v > cmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLnBybzwvYT52aWRlci5uZXR3b3JrLlN5bmNOZXR3b3Jr > UHJvdmlkZXJDb21tYW5kXQ0KIChFRS1NYW5hZ2VkVGhyZWFkRmFjdG9yeS1lbmdpbmVTY2hlZHVs > ZWQtVGhyZWFkLTU4KSBbMzNiZGRhN2ZdIFJ1bm5pbmcgY29tbWFuZDogU3luY05ldHdvcmtQcm92 > aWRlckNvbW1hbmQgaW50ZXJuYWw6IHRydWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh > c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t > Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls > eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+MjAxOC0wNS0w > MiAxNDo0MDo1Niw4NDQtMDcgSU5GTyZuYnNwOyBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnNzby51 > dGlscy5BdXRoZW50aWNhdGlvblV0aWxzXSAoZGVmYXVsdCB0YXNrLTQwKQ0KIFtdIFVzZXIgYWRt > aW5AaW50ZXJuYWwgc3VjY2Vzc2Z1bGx5IGxvZ2dlZCBpbiB3aXRoIHNjb3Blczogb3ZpcnQtYXBw > LWFwaSBvdmlydC1leHQ9dG9rZW4taW5mbzphdXRoei1zZWFyY2ggb3ZpcnQtZXh0PXRva2VuLWlu > Zm86cHVibGljLWF1dGh6LXNlYXJjaCBvdmlydC1leHQ9dG9rZW4taW5mbzp2YWxpZGF0ZSBvdmly > dC1leHQ9dG9rZW46cGFzc3dvcmQtYWNjZXNzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh > c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t > Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls > eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+MjAxOC0wNS0w > MiAxNDo0MDo1NywwMDEtMDcgSU5GTyZuYnNwOyBbPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl > LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX29yZy5vdmlydC5lbmdpbmUuY29yZS5i > bGwucHJvJmFtcDtkPUR3TUZhUSZhbXA7Yz1WeHQ1ZTBPc3Z2dDJnZmx3U2xzSjVEbVBHY1B2VFJL > TEp5cDAzMXJYamhnJmFtcDtyPUZpUGhMMENsMXltWmxuVHlBSUlMNzV0RTRMMHJlSGNEZEQtN3dV > dFVHSEEmYW1wO209YmYtT28xNGZCd0dOaG55c25XbFQ1Tk05VnUwUFZKTkJDaDdlTVpJT2tqUSZh > bXA7cz1XREJSa2tyMm9NM3BxQU0tb0E2R0g0aWw3SWpBQTZ1M1BpbThnM1pmNGxVJmFtcDtlPSIg > dGFyZ2V0PSJfYmxhbmsiPm9yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwucHJvPC9hPnZpZGVyLm5l > dHdvcmsuU3luY05ldHdvcmtQcm92aWRlckNvbW1hbmRdDQogKEVFLU1hbmFnZWRUaHJlYWRGYWN0 > b3J5LWVuZ2luZVNjaGVkdWxlZC1UaHJlYWQtNTgpIFszM2JkZGE3Zl0gTG9jayBmcmVlZCB0byBv > YmplY3QgJ0VuZ2luZUxvY2s6e2V4Y2x1c2l2ZUxvY2tzPSdbZjUwYmQwODEtN2M1Yi00MTYxLWEw > NDUtMDY4Zjg1ZDJhNDc2PVBST1ZJREVSXScsIHNoYXJlZExvY2tzPScnfSc8L3NwYW4+PG86cD48 > L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 > OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 > MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj > MUY0OTdEIj4yMDE4LTA1LTAyIDE0OjQ0OjM5LDE5MS0wNyBJTkZPJm5ic3A7IFtvcmcub3ZpcnQu > ZW5naW5lLmNvcmUuYmxsLnV0aWxzLlRocmVhZFBvb2xNb25pdG9yaW5nU2VydmljZV0gKEVFLU1h > bmFnZWRUaHJlYWRGYWN0b3J5LWVuZ2luZVRocmVhZE1vbml0b3JpbmctVGhyZWFkLTEpDQogW10g > VGhyZWFkIHBvb2wgJ2RlZmF1bHQnIGlzIHVzaW5nIDAgdGhyZWFkcyBvdXQgb2YgMSBhbmQgNSB0 > YXNrcyBhcmUgd2FpdGluZyBpbiB0aGUgcXVldWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg > Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn > aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh > bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+MjAxOC0w > NS0wMiAxNDo0NDozOSwxOTEtMDcgSU5GTyZuYnNwOyBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJs > bC51dGlscy5UaHJlYWRQb29sTW9uaXRvcmluZ1NlcnZpY2VdIChFRS1NYW5hZ2VkVGhyZWFkRmFj > dG9yeS1lbmdpbmVUaHJlYWRNb25pdG9yaW5nLVRocmVhZC0xKQ0KIFtdIFRocmVhZCBwb29sICdl > bmdpbmUnIGlzIHVzaW5nIDAgdGhyZWFkcyBvdXQgb2YgNTAwLCA4IHRocmVhZHMgd2FpdGluZyBm > b3IgdGFza3MgYW5kIDAgdGFza3MgaW4gcXVldWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg > Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn > aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh > bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+MjAxOC0w > NS0wMiAxNDo0NDozOSwxOTEtMDcgSU5GTyZuYnNwOyBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJs > bC51dGlscy5UaHJlYWRQb29sTW9uaXRvcmluZ1NlcnZpY2VdIChFRS1NYW5hZ2VkVGhyZWFkRmFj > dG9yeS1lbmdpbmVUaHJlYWRNb25pdG9yaW5nLVRocmVhZC0xKQ0KIFtdIFRocmVhZCBwb29sICdl > bmdpbmVTY2hlZHVsZWQnIGlzIHVzaW5nIDEgdGhyZWFkcyBvdXQgb2YgMTAwIGFuZCA5OSB0YXNr > cyBhcmUgd2FpdGluZyBpbiB0aGUgcXVldWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh > c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t > Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls > eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+MjAxOC0wNS0w > MiAxNDo0NDozOSwxOTEtMDcgSU5GTyZuYnNwOyBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC51 > dGlscy5UaHJlYWRQb29sTW9uaXRvcmluZ1NlcnZpY2VdIChFRS1NYW5hZ2VkVGhyZWFkRmFjdG9y > eS1lbmdpbmVUaHJlYWRNb25pdG9yaW5nLVRocmVhZC0xKQ0KIFtdIFRocmVhZCBwb29sICdlbmdp > bmVUaHJlYWRNb25pdG9yaW5nJyBpcyB1c2luZyAxIHRocmVhZHMgb3V0IG9mIDEgYW5kIDAgdGFz > a3MgYXJlIHdhaXRpbmcgaW4gdGhlIHF1ZXVlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs > YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu > LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p > bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjIwMTgtMDUt > MDIgMTQ6NDQ6MzksMTkxLTA3IElORk8mbmJzcDsgW29yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwu > dXRpbHMuVGhyZWFkUG9vbE1vbml0b3JpbmdTZXJ2aWNlXSAoRUUtTWFuYWdlZFRocmVhZEZhY3Rv > cnktZW5naW5lVGhyZWFkTW9uaXRvcmluZy1UaHJlYWQtMSkNCiBbXSBUaHJlYWQgcG9vbCAnaG9z > dFVwZGF0ZXNDaGVja2VyJyBpcyB1c2luZyAwIHRocmVhZHMgb3V0IG9mIDUgYW5kIDEgdGFza3Mg > YXJlIHdhaXRpbmcgaW4gdGhlIHF1ZXVlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz > PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv > dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 > JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh > bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu > LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv > bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm > O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN > c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv > bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 > b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 > bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv > cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt > c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv > bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O > b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h > bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 > Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw > PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h > bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 > ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y > OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt > YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 > YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs > aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv > bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 > YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox > MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx > RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi > IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 > byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy > aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw > PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 > bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w > cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 > N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 > eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ > PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx > dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv > cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt > c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w > cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh > bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs > aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gWWFuaXIgUXVpbm4gW21haWx0bzo8YSBocmVmPSJtYWls > dG86eXF1aW5uQHJlZGhhdC5jb20iIHRhcmdldD0iX2JsYW5rIj55cXVpbm5AcmVkaGF0LmNvbTwv > YT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgMiwgMjAxOCAxMjozNCBBTTxi > cj4NCjxiPlRvOjwvYj4gSnVzdGluIFp5Z21vbnQgJmx0OzxhIGhyZWY9Im1haWx0bzpqenlnbW9u > dEBwcm9vZnBvaW50LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmp6eWdtb250QHByb29mcG9pbnQuY29t > PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzp1c2Vyc0BvdmlydC5vcmci > IHRhcmdldD0iX2JsYW5rIj51c2Vyc0BvdmlydC5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ > IFJlOiBbb3ZpcnQtdXNlcnNdIGFkZGluZyBhIGhvc3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8 > ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h > bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ > DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh > c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 > b206MTIuMHB0Ij5IaSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h > bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph > dXRvIj5XaGF0IGRvY3VtZW50IGFyZSB5b3UgdXNpbmcgPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ > DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv > LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNlZSBpZiB5b3UgZmluZCB0aGUgbmVlZGVkIGluZm9y > bWF0aW9uIGhlcmUgOiZuYnNwOw0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p > bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19vdmlydC5vcmdfZG9jdW1lbnRhdGlvbl9hZG1pbi0y > RGd1aWRlX2NoYXAtMkRIb3N0c18mYW1wO2Q9RHdNRmFRJmFtcDtjPVZ4dDVlME9zdnZ0MmdmbHdT > bHNKNURtUEdjUHZUUktMSnlwMDMxclhqaGcmYW1wO3I9RmlQaEwwQ2wxeW1abG5UeUFJSUw3NXRF > NEwwcmVIY0RkRC03d1V0VUdIQSZhbXA7bT1GTjAtM1IzeGswY2tjRFZqSlNYUURhSXJqcUM3b3ZH > R2ZIVlhaN0xkbVhzJmFtcDtzPXNhQmhqV1h3dkVIVUhCc28tWW1UdnJ5OGlseklDWU9JRWVuMDV5 > OXE4UGsmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL292aXJ0Lm9yZy9kb2N1bWVu > dGF0aW9uL2FkbWluLWd1aWRlL2NoYXAtSG9zdHMvPC9hPiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 > Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z > by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K > PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp > bi1ib3R0b206MTIuMHB0Ij5Gb3IgZW5naW5lIHJlbGF0ZWQgcG90ZW50aWFsIGVycm9ycyBpIHJl > Y29tbWVuZCBhbHNvIGNoZWNraW5nIHRoZSBlbmdpbmUubG9nIGFuZCBpbiBVSSBjaGVjayB0aGUg > ZXZlbnRzIHNlY3Rpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt > YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 > YXV0byI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h > bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph > dXRvIj5ZYW5pciBRdWlubjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 > Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 > dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv > Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t > YWx0OmF1dG8iPk9uIFR1ZSwgTWF5IDEsIDIwMTggYXQgMTE6MTEgUE0sIEp1c3RpbiBaeWdtb250 > ICZsdDs8YSBocmVmPSJtYWlsdG86anp5Z21vbnRAcHJvb2Zwb2ludC5jb20iIHRhcmdldD0iX2Js > YW5rIj5qenlnbW9udEBwcm9vZnBvaW50LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w > Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND > Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn > aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 > Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 > YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBoYXZlIHRyaWVkIHRvIGFkZCBhIGhv > c3QgdG8gdGhlIGVuZ2luZSBhbmQgaXQganVzdCB0YWtlcyBmb3JldmVyIG5ldmVyIHdvcmtpbmcg > b3IgZ2l2aW5nIGFueSBlcnJvciBtZXNzYWdlLiZuYnNwOyBXaGVuIEkgbG9vayBpbiB0aGUgZW5n > aW5l4oCZcyBzZXJ2ZXIubG9nIEkgc2VlIGl0IHNheXMgdGhlIG5ldHdvcmtzDQogYXJlIG1pc3Np > bmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp > bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhvdWdodCB3aGVu > IHlvdSBpbnN0YWxsIGEgbm9kZSBhbmQgYWRkIGl0IHRvIHRoZSBlbmdpbmUgaXQgd2lsbCBhZGQg > dGhlIG5ldHdvcmtzIGF1dG9tYXRpY2FsbHk/Jm5ic3A7IFRoZSBkb2NzIGRvbuKAmXQgZ2l2ZSBt > dWNoIGluZm9ybWF0aW9uIGFib3V0IHRoaXMsIGFuZCBJIGNhbuKAmXQgZXZlbiByZW1vdmUgdGhl > DQogaG9zdCB0aHJvdWdoIHRoZSBVSS4mbmJzcDsgV2hhdCBzdGVwcyBhcmUgcmVxdWlyZWQgdG8g > cHJlcGFyZSBhIG5vZGUgd2hlbiBzZXZlcmFsIHZsYW5zIGFyZSBpbnZvbHZlZD88bzpwPjwvbzpw > PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 > bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj > bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp > bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N > CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn > aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f > X19fX19fX19fX19fX188YnI+DQpVc2VycyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls > dG86VXNlcnNAb3ZpcnQub3JnIiB0YXJnZXQ9Il9ibGFuayI+VXNlcnNAb3ZpcnQub3JnPC9hPjxi > cj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o > dHRwLTNBX19saXN0cy5vdmlydC5vcmdfbWFpbG1hbl9saXN0aW5mb191c2VycyZhbXA7ZD1Ed01G > YVEmYW1wO2M9Vnh0NWUwT3N2dnQyZ2Zsd1Nsc0o1RG1QR2NQdlRSS0xKeXAwMzFyWGpoZyZhbXA7 > cj1GaVBoTDBDbDF5bVpsblR5QUlJTDc1dEU0TDByZUhjRGRELTd3VXRVR0hBJmFtcDttPUZOMC0z > UjN4azBja2NEVmpKU1hRRGFJcmpxQzdvdkdHZkhWWFo3TGRtWHMmYW1wO3M9WDdxOG1FaW5fazE1 > cUY2UGgwR3JyZ24zRUgtUVBkNDlwdXoxUWx4UXY4byZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5o > dHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnM8L2E+PG86cD48L286 > cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl > PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i > c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 > Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv > LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv > OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv > YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn > aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv > bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 > eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0K > X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpVc2Vy > cyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VXNlcnNAb3ZpcnQub3JnIiB0YXJn > ZXQ9Il9ibGFuayI+VXNlcnNAb3ZpcnQub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJs > ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19saXN0cy5vdmlydC5vcmdf > bWFpbG1hbl9saXN0aW5mb191c2VycyZhbXA7ZD1Ed01GYVEmYW1wO2M9Vnh0NWUwT3N2dnQyZ2Zs > d1Nsc0o1RG1QR2NQdlRSS0xKeXAwMzFyWGpoZyZhbXA7cj1GaVBoTDBDbDF5bVpsblR5QUlJTDc1 > dEU0TDByZUhjRGRELTd3VXRVR0hBJmFtcDttPWJmLU9vMTRmQndHTmhueXNuV2xUNU5NOVZ1MFBW > Sk5CQ2g3ZU1aSU9ralEmYW1wO3M9T3dTcmNvUE1qR0h1aUhiMS0zcXo1dG13ODRpUnBsWUhqVkpN > YkR4dFcyWSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbGlzdHMub3ZpcnQub3JnL21h > aWxtYW4vbGlzdGluZm8vdXNlcnM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 > L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 > bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp > dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ > DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k > aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= > > --_000_CY4PR12MB1798DBD078B4054BA0C43EC4AB920CY4PR12MB1798namp_-- > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > > > ------------------------------ > > End of Users Digest, Vol 80, Issue 70 > *************************************

6 years, 11 months

2
3
0 / 0

data flow for statistics for hosts and vms

by Peter Hudec

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I'm trying to understand the flow how the stats from the VM and HOSTS are imported into the engine. On each host there is VDSM. Using the vsdm-client I'm able to get HOST and VM stats vdsm-client Host getAllVmStats vdsm-client Host getStats Are the hosts pushing the data to the engine or vice versa? On the engine side there is java based vdsm-jsonrpc client so I guess the data are pulled from the hosts to the engine database. And of course the question is which component on engine side is getting/requesting the data. I'm trying to get the stat less painless as query the API. Maybe the engine/dwh database could help but the scheme could change between releases, isn't it. or the engine DB. regards Peter - -- *Peter Hudec* Infraštruktúrny architekt phudec(a)cnc.sk <mailto:phudec@cnc.sk> *CNC, a.s.* Borská 6, 841 04 Bratislava Recepcia: +421 2 35 000 100 Mobil:+421 905 997 203 *www.cnc.sk* <http:///www.cnc.sk> -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEqSUbhuEwhryifNeVQnvVWOJ35BAFAlr63zYACgkQQnvVWOJ3 5BC1BxAApSg29lv1KohiVeJNsFdF4i77e2H77drLe9Ffq1kg/+VESh6+ggeZIH1U W5e06PJeifoZbtWL2enaJsml9JZM/3kvqU5TC93sR8chvhfRo3GXS50tWCEe5b0R UPdpjgyYipN+i3Xibl/YxHMu9fwpFIH+VY+JWn70Dz5pjvgwn71ogCcRUA6Itvom 700Pwv4yV31hWyE6qXiWOth0Rfey3+QkEXtNhRrEOHeAzpNABS5Zixjocr9c5xhz AdLkUAGVvEQEYy/Nzyv8A8KRSY1z63Ijyv5hgQIpGkKfbXhRYrotY6EeqdJ6PYsF tQvkjjT+kJ5SBYClK/et9X4y2ZMe+4YX7lrsZnk8V/Oj3YYw2y1XlvXcrt0pZlHA G9QIhcn/chtBTslGOW0t4B603YRykausunc9XXq1IGKNyLHb/lrDiDh+x2dCg5vT sGJE/gQffSNSwk5oFBlG2U9aOgWvZ8m3nVCDdGo+1a9fc/KR8toQi9axsiIMVYb/ dzbDmaYlXbKNwWdVirftTetxuwn44j2Kgv4b048ZmGwTvwc79UuoS8H9hv9LlBM6 7E7iqaGfKbExg0/EMZurd90P62zn8nIGnYEJUrxVU3aJ4E2gWflfSelYMymNtE+u aZAMxvK6gILQP2n45AVkKOTacQwX07QCzlvJ2sL4gNzQQ+UL52c= =RNAH -----END PGP SIGNATURE-----

6 years, 11 months

2
2
0 / 0

Data Center Upgrade to 3.6 fails with "Upgrading a pool while an upgrade is in process is unsupported" - any fix for this ?

by Joseph Kelly

--_000_DM5PR1601MB1307D6E7B77C0E86F3CAE6A0889B0DM5PR1601MB1307_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All - I'm trying to upgrade a Data Center in ovirt 3.6.4 from 3.4 to = 3.6 but I'm getting this error when I tried: May 7, 2018 3:07:55 PM VDSM command failed: Upgrading a pool while an upgra= de is in process is unsupported (pool: `9667c5e8-97b1-4e09-be44-2696a69f8959`) Please note that all clusters are already at 3.6 compatability and the fina= l step is to upgrade the Data Center to 3.6. So I've tried these steps as a workaorund from the RHEV tech-doc below but = it hasn't worked for me: Deactivate the Export and ISO domains. Switch SPM to another host. Try the upgrade again Activate Export and ISO domains as required. (From https://access.redhat.com/solutions/2332581 ) And I also tried to search mail-archive.com for past Email but didn't find = anything matching this particular issue. https://www.mail-archive.com/search?l=3Dusers%40ovirt.org&q=3D3.6+compat&x= =3D0&y=3D0 https://www.mail-archive.com/search?l=3Dusers%40ovirt.org&q=3Dovirt+Data+ce= nter+compat&x=3D0&y=3D0 So has anyone found another way to fix this problem e.g. does the ovirt DB = need to be directly updated ? Thanks, Joe. -- J. Kelly Infrastructure Engineer TradingScreen www.tradingscreen.com<http://www.tradingscreen.com/> email: joseph.kelly(a)tradingscreen.com<mailto:joseph.kelly@tradingscreen.com= > Follow TradingScreen on Twitter<http://twitter.com/#%21/TradingScreen>, Fac= ebook<http://www.facebook.com/pages/TradingScreen/214046251945650>, or our = blog, Trading Smarter<http://tradingsmarter.tradingscreen.com/> This message is intended only for the recipient(s) named above and may cont= ain confidential information. If you are not an intended recipient, you sho= uld not review, distribute or copy this message. Please notify the sender i= mmediately by e-mail if you have received this message in error and delete = it from your system. --_000_DM5PR1601MB1307D6E7B77C0E86F3CAE6A0889B0DM5PR1601MB1307_ 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"> <div id=3D"divtagdefaultwrapper" style=3D"font-size:10pt;color:#000000;font= -family:Verdana,Geneva,sans-serif;" dir=3D"ltr"> <p style=3D"margin-top:0;margin-bottom:0"></p> <div>Hello All - I'm trying to upgrade a Data Center in ovirt 3.6.4 from 3.= 4 to 3.6 but I'm getting this error when I tried:</div> <div><span style=3D"font-size: 10pt; white-space: pre;"></span><br> </div> <div>May 7, 2018 3:07:55 PM VDSM command failed: Upgrading a pool while an = upgrade is in process is unsupported </div> <div>(pool: `9667c5e8-97b1-4e09-be44-2696a69f8959`)</div> <div><br> </div> <div><span>Please note that all clusters are already at 3.6 compa= tability and the final step is to upgrade the Data Center to 3.6.</spa= n></div> <div>So I've tried these steps as a workaorund from the RHEV tech-doc below=  but it hasn't worked for me: </div> <div><br> </div> <div>    Deactivate the Export and ISO domains.</div> <div>    Switch SPM to another host.</div> <div>    Try the upgrade again</div> <div>    Activate Export and ISO domains as required.</div> <div><br> </div> <div>(From <a href=3D"https://access.redhat.com/solutions/2332581" cla= ss=3D"OWAAutoLink">https://access.redhat.com/solutions/2332581</a> )</= div> <div><br> </div> <div>And I also tried to search mail-archive.com for past Email but di= dn't find anything matching this particular issue.</div> <div><br> </div> <div>https://www.mail-archive.com/search?l=3Dusers%40ovirt.org&q=3D3.6&= #43;compat&x=3D0&y=3D0</div> <div>https://www.mail-archive.com/search?l=3Dusers%40ovirt.org&q=3Dovir= t+Data+center+compat&x=3D0&y=3D0</div> <div><br> </div> <div>So has anyone found another way to fix this problem e.g. doe= s the ovirt DB need to be directly updated ? </div> <div><br> </div> <div>Thanks,</div> <div>Joe.</div> <p></p> <p style=3D"margin-top:0;margin-bottom:0"><br> </p> <div id=3D"Signature"> <div id=3D"divtagdefaultwrapper" dir=3D"ltr" style=3D"font-size:12pt; color= :rgb(0,0,0); font-family:Calibri,Arial,Helvetica,sans-serif,"EmojiFont= ","Apple Color Emoji","Segoe UI Emoji",NotoColorEm= oji,"Segoe UI Symbol","Android Emoji",EmojiSymbols,&quo= t;EmojiFont","Apple Color Emoji","Segoe UI Emoji",= NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiS= ymbols,"EmojiFont","Apple Color Emoji","Segoe UI E= moji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji&q= uot;,EmojiSymbols"> <div style=3D"font-family:Tahoma; font-size:13px"> <table class=3D"" cellspacing=3D"0" cellpadding=3D"0" width=3D"100%" style= =3D"font-family:Cantarell; letter-spacing:normal; orphans:auto; text-indent= :0px; text-transform:none; widows:auto; word-spacing:0px"> <tbody> <tr class=3D""> <td class=3D""> <div>-- <br> <span style=3D"font-size:12pt; color:#000000; font-style:Arial,sans-serif; = font-weight:bold">J. Kelly</span><br> <span style=3D"font-size:10pt; color:#000000; font-style:Arial,sans-serif">= Infrastructure Engineer</span><br> <span style=3D"font-size:12pt; color:#808080; font-style:Arial,sans-serif; = font-weight:bold">TradingScreen</span><br> <span style=3D"font-size:10pt; color:#808080; font-style:Arial,sans-serif">= <a href=3D"http://www.tradingscreen.com/" id=3D"LPNoLP">www.tradingscreen.c= om</a></span><br> <span style=3D"font-size:10pt; color:#808080; font-style:Arial,sans-serif">= email: <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:joseph.kel= ly(a)tradingscreen.com" id=3D"LPNoLP">joseph.kelly(a)tradingscreen.com</a></spa= n></div> <br> </td> </tr> <tr class=3D""> <td rowspan=3D"1" class=3D""><span style=3D"font-size:10.0pt; color:gray">F= ollow TradingScreen on <a href=3D"http://twitter.com/#%21/TradingScreen" id=3D"LPNoLP">Twitter</a>= , <a href=3D"http://www.facebook.com/pages/TradingScreen/214046251945650" i= d=3D"LPNoLP"> Facebook</a>, or our blog, <a href=3D"http://tradingsmarter.tradingscreen.c= om/" id=3D"LPNoLP"> Trading Smarter</a></span><br> <br> <span style=3D"font-size:8.0pt; color:gray">This message is intended only f= or the recipient(s) named above and may contain confidential information. I= f you are not an intended recipient, you should not review, distribute or c= opy this message. Please notify the sender immediately by e-mail if you have received this message in error an= d delete it from your system.</span><br> </td> </tr> <tr class=3D""> <td rowspan=3D"1" class=3D""><br> </td> </tr> </tbody> </table> <br> </div> </div> </div> </div> </body> </html> --_000_DM5PR1601MB1307D6E7B77C0E86F3CAE6A0889B0DM5PR1601MB1307_--

6 years, 11 months

2
2
0 / 0

Re: [ovirt-devel] [FYI] Blog entry about oVirt on the mainframe

by Michal Skrivanek

> On 17 May 2018, at 16:41, Viktor VM Mihajlovski <mihajlov(a)linux.vnet.ibm.com> wrote: > > Hi, > > as some of you know the support for s390x KVM hosts has been in oVirt > for a while now - without raising too much attention. The following > article highlights the availability and describes how to add a mainframe > to an oVirt cluster: > https://kvmonz.blogspot.co.uk/2018/05/knowledge-series-managing-kvm-on-ib... thanks! looks great cross-posting to users list too > > -- > Regards, > Viktor Mihajlovski > _______________________________________________ > Devel mailing list -- devel(a)ovirt.org > To unsubscribe send an email to devel-leave(a)ovirt.org

6 years, 11 months

1
0
0 / 0

Re: VM's disk stuck in migrating state

by nicolas＠devels.es

Thanks. I've been able to see the line in the log, however, the format differs slightly from yours. 2018-05-17 12:24:44,132+0100 DEBUG (jsonrpc/6) [jsonrpc.JsonRpcServer] Calling 'Volume.getInfo' in bridge with {u'storagepoolID': u'75bf8f48-970f-42bc-8596-f8ab6efb2b63', u'imageID': u'b4013aba-a936-4a54-bb14-670d3a8b7c38', u'volumeID': u'c2cfbb02-9981-4fb7-baea-7257a824145c', u'storagedomainID': u'1876ab86-216f-4a37-a36b-2b5d99fcaad0'} (__init__:556) 2018-05-17 12:24:44,689+0100 DEBUG (jsonrpc/6) [jsonrpc.JsonRpcServer] Return 'Volume.getInfo' in bridge with {'status': 'OK', 'domain': '1876ab86-216f-4a37-a36b-2b5d99fcaad0', 'voltype': 'INTERNAL', 'description': 'None', 'parent': 'ea9a0182-329f-4b8f-abe3-e894de95dac0', 'format': 'COW', 'generation': 1, 'image': 'b4013aba-a936-4a54-bb14-670d3a8b7c38', 'ctime': '1526470759', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824', 'children': [], 'pool': '', 'capacity': '21474836480', 'uuid': u'c2cfbb02-9981-4fb7-baea-7257a824145c', 'truesize': '1073741824', 'type': 'SPARSE', 'lease': {'owners': [8], 'version': 1L}} (__init__:582) As you can see, there's no path field there. How should I procceed? El 2018-05-17 12:01, Benny Zlotnik escribió: > vdsm-client replaces vdsClient, take a look > here: https://lists.ovirt.org/pipermail/devel/2016-July/013535.html > [4] > > On Thu, May 17, 2018 at 1:57 PM, <nicolas(a)devels.es> wrote: > >> The issue is present in the logs: >> >> 2018-05-17 11:50:44,822+01 INFO >> [org.ovirt.engine.core.bll.storage.disk.image.VdsmImagePoller] >> (DefaultQuartzScheduler1) [39755bb7-9082-40d6-ae5e-64b5b2b5f98e] >> Command CopyData id: '84a49b25-0e37-4338-834e-08bd67c42860': the >> volume lease is not FREE - the job is running >> >> I tried setting the log level to debug but it seems I have not a >> vdsm-client command. All I have is a vdsm-tool command. Is it >> equivalent? >> >> Thanks >> >> El 2018-05-17 11:49, Benny Zlotnik escribió: >> By the way, please verify it's the same issue, you should see "the >> volume lease is not FREE - the job is running" in the engine log >> >> On Thu, May 17, 2018 at 1:21 PM, Benny Zlotnik >> <bzlotnik(a)redhat.com> >> wrote: >> >> I see because I am on debug level, you need to enable it in order >> to >> see >> >> https://www.ovirt.org/develop/developer-guide/vdsm/log-files/ [1] >> [3] >> >> On Thu, 17 May 2018, 13:10 , <nicolas(a)devels.es> wrote: >> >> Hi, >> >> Thanks. I've checked vdsm logs on all my hosts but the only entry >> I can >> find grepping by Volume.getInfo is like this: >> >> 2018-05-17 10:14:54,892+0100 INFO (jsonrpc/0) >> [jsonrpc.JsonRpcServer] >> RPC call Volume.getInfo succeeded in 0.30 seconds (__init__:539) >> >> I cannot find a line like yours... any other way on how to obtain >> those >> parameters. This is an iSCSI based storage FWIW (both source and >> destination of the movement). >> >> Thanks. >> >> El 2018-05-17 10:01, Benny Zlotnik escribió: >> In the vdsm log you will find the volumeInfo log which looks >> like >> this: >> >> 2018-05-17 11:55:03,257+0300 DEBUG (jsonrpc/6) >> [jsonrpc.JsonRpcServer] >> Return 'Volume.getInfo' in bridge with {'status': 'OK', >> 'domain': >> '5c4d2216- >> 2eb3-4e24-b254-d5f83fde4dbe', 'voltype': 'INTERNAL', >> 'description': >> '{"DiskAlias":"vm_Disk1","DiskDescription":""}', 'parent': >> '00000000-0000-0000- >> 0000-000000000000', 'format': 'RAW', 'generation': 3, 'image': >> 'b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc', 'ctime': '1526543244', >> 'disktype': 'DATA', ' >> legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824', >> 'children': [], 'pool': '', 'capacity': '1073741824', 'uuid': >> u'7190913d-320c-4fc9- >> a5b3-c55b26aa30f4', 'truesize': '0', 'type': 'SPARSE', 'lease': >> {'path': > > > u'/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2e > >> > > > b3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease', > >> 'owners': [1], 'version': 8L, 'o >> ffset': 0}} (__init__:355) >> >> The lease path in my case is: >> /rhev/data-center/mnt/10.35.0. [2] > > > [1]233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease > >> Then you can look in /var/log/sanlock.log >> >> 2018-05-17 11:35:18 243132 [14847]: s2:r9 resource > > > 5c4d2216-2eb3-4e24-b254-d5f83fde4dbe:7190913d-320c-4fc9-a5b3-c55b26aa30f4:/rhev/data-center/mnt/10.35.0.233:_root_storage__domains_sd1/5c4d2216-2eb3-4e24-b254-d5f83fde4dbe/images/b8eb8c82-fddd-4fbc-b80d-6ee04c1255bc/7190913d-320c-4fc9-a5b3-c55b26aa30f4.lease:0 > >> for 2,9,5049 >> >> Then you can use this command to unlock, the pid in this case >> is 5049 >> >> sanlock client release -r RESOURCE -p pid >> >> On Thu, May 17, 2018 at 11:52 AM, Benny Zlotnik >> <bzlotnik(a)redhat.com> >> wrote: >> >> I believe you've hit this >> bug: https://bugzilla.redhat.com/show_bug.cgi?id=1565040 [3] [2] > > [1] > >>> You can try to release the lease manually using the > sanlock client > >>> command (there's an example in the comments on the bug), >>> once the lease is free the job will fail and the disk can be > unlock > >> On Thu, May 17, 2018 at 11:05 AM, <nicolas(a)devels.es> wrote: >> >> Hi, >> >> We're running oVirt 4.1.9 (I know it's not the recommended >> version, but we can't upgrade yet) and recently we had an > issue > >> with a Storage Domain while a VM was moving a disk. The > Storage > >> Domain went down for a few minutes, then it got back. >> >> However, the disk's state has stuck in a 'Migrating: 10%' > state > >> (see ss-2.png). >> >> I run the 'unlock_entity.sh' script to try to unlock the > disk, > >> with these parameters: >> >> # PGPASSWORD=... >> /usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh -t > disk -u > >> engine -v b4013aba-a936-4a54-bb14-670d3a8b7c38 >> >> The disk's state changed to 'OK', but the actual state still >> states it's migrating (see ss-1.png). >> >> Calling the script with -t all doesn't make a difference > either. > >> Currently, the disk is unmanageable: cannot be deactivated, > moved > >> or copied, as it says there's a copying operation running > already. > >> Could someone provide a way to unlock this disk? I don't mind >> modifying a value directly into the database, I just need the >> copying process cancelled. >> >> Thanks. >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org >> To unsubscribe send an email to users-leave(a)ovirt.org > > Links: > ------ > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1565040 [3] [2] > > Links: > ------ > [1] http://10.35.0 [5]. > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1565040 [3] > [3] https://www.ovirt.org/develop/developer-guide/vdsm/log-files/ [1] > > > > Links: > ------ > [1] https://www.ovirt.org/develop/developer-guide/vdsm/log-files/ > [2] http://10.35.0. > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1565040 > [4] https://lists.ovirt.org/pipermail/devel/2016-July/013535.html > [5] http://10.35.0

6 years, 11 months

2
5
0 / 0

VM interface bonding (LACP)

by Doug Ingham

Hi All, My hosts have all of their interfaces bonded via LACP to maximise throughput, however the VMs are still limited to Gbit virtual interfaces. Is there a way to configure my VMs to take full advantage of the bonded physical interfaces? One way might be adding several VIFs to each VM & using ALB bonding, however I'd rather use LACP if possible... Cheers, -- Doug

6 years, 11 months

6
13
0 / 0

oVirt setup help

by Lakhwinder Rai

Hello guy's, I am planning to set up home lab with ovirt.I am confused with hardware selection.Anybody has a same setup ,Any suggestion will be appreciated. Thanks Lakhwinder Rai

6 years, 11 months

2
1
0 / 0

oVirt 4.1 upgrade hosted-engine

by dlotarev＠yahoo.com

Hi! I have a two nodes (A and B), and running vm HostedEngine on host A. After upgrade host B to latest release CentOS (7.5.1804), i trying to upgrade host A, but i cannot migrate HostedEngine to host B for next upgrade CentOS. Another VMs migrated to Host B w/o problems. In logs on host A i have following lines: May 17 12:58:16 ovirt-h1 libvirtd: 2018-05-17 07:58:16.728+0000: 3637: error : virNetClientProgramDispatchError:177 : internal error: cannot execute command QEMU «cont»: Failed to lock byte 100 May 17 12:58:38 ovirt-h1 journal: ovirt-ha-agent ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine ERROR Migration failed: {u'status': {'message': 'Done', 'code': 0}, u'progress': 100} Please explain me what is my mistake? P.S I found, that host B have a missmatch in version of packages: # rpm -aq|grep qemu|sort -n centos-release-qemu-ev-1.0-2.el7.noarch ipxe-roms-qemu-20170123-1.git4e85b27.el7_4.1.noarch libvirt-daemon-driver-qemu-3.9.0-14.el7_5.2.x86_64 qemu-img-ev-2.10.0-21.el7_5.2.1.x86_64 qemu-kvm-common-ev-2.10.0-21.el7_5.2.1.x86_64 qemu-kvm-ev-2.10.0-21.el7_5.2.1.x86_64 qemu-kvm-tools-ev-2.9.0-16.el7_4.14.1.x86_64 Package qemu-kvm-tools-ev has version 2.9.0, while another packages of qemu has 2.10 version. Thank you so much for response.

6 years, 11 months

1
2
0 / 0

hosted-engine deploy not use FQDN

by dhy336＠sina.com

Hi I deploy hosted-engine by #hosted-engine --deploy, but I do not use FQDN, I want to visit engine directly by ip besides, I have not DNS server, I want to skip setup Engine VM FQDN， because my project can not to setup /etc/hosts Please provide the FQDN you would like to use for the engine appliance. Note: This will be the FQDN of the engine VM you are now going to launch, it should not point to the base host or to any other existing machine. Engine VM FQDN: (leave it empty to skip): []:

6 years, 11 months

2
1
0 / 0

Self-Hosted engine deploy fails but hosted-engine --vm-status shows engine in good health

by 03ce007＠gmail.com

I am setting up self-hosted engine (4.2) on centos 7.4. The setup runs all the way through and creates the local VM, but fails on task "Wait for the local bootstrap VM to be down at engine eyes". But if I then run hosted-engine --vm-start, it comes back up and shows it is in good health, but when I do an api call with curl, it shows me that the host is in 'non responsive' state! I cannot deploy any VM on the engine VM, the ssh connection fails. How and what could have caused it, where can i find more detailed information related to this error/status of engine vm ? Thanks

6 years, 11 months

3
2
0 / 0

Hosts : Upgrade failed - 4.2.3

by Nicolas Ecarnot

Hello, I was on 4.2.2 and it failed. I upgraded to 4.2.3 and it's still failing. From the GUI, I switch one host into maintenance mode, try to upgrade it, and it is failing. On the engine, the engine.log is not saying anything helpful. But on the engine, I see in /var/log/ovirt-engine/host-deploy/ovirt-host-mgmt-ansible-20180516121013-xxx-dacf1972-f184-4d01-a863-7974579e6bc8.log, I see : > http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8/repodata/rep...: [Errno 14] HTTP Error 404 - Not Found > Essai d'un autre miroir. > To address this issue please refer to the below wiki article > > https://wiki.centos.org/yum-errors > > If above article doesn't help to resolve this issue please use https://bugs.centos.org/. > > http://mirror.centos.org/centos/7/virt/x86_64/ovirt-4.1/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found > Essai d'un autre miroir. This is french, but I'm sure you understand that it translates into "gluster repo issue". Is there something I could do? Thank you. -- Nicolas ECARNOT

6 years, 11 months

3
3
0 / 0

ovirt 4.2 failed deploy

by Alex K

Hi all, I am trying to setup ovirt 4.2 self hosted with 3 nodes. I have done several 4.1 installations without issues. Now at 4.2 I get: [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "Unable to resolve address\n"} [ ERROR ] Failed to execute stage 'Closing up': Failed executing ansible-playbook I am running: hosted-engine --deploy --config-append=/root/ovirt/storage.conf Checking the log doesn't give an easy reference of the issue. Seems to be related with DNS but I can confirm that the host can resolve the engine FQDN from /etc/hosts or from the DNS server. Any ideas? Thanx, Alex

6 years, 11 months

4
12
0 / 0

ovirt engine frequently rebooting/changing host

by Bernhard Dick

Hi, currently I'm evaluating oVirt and I have three hosts installed within nested KVM. They're sharing a gluster environment which has been configured using the oVirt Node Wizards. It seems to work quite well, but after some hours I get many status update mails from the ovirt engine which are either going to EngineStop or EngeineForceStop. Sometimes the host where the engine runs is switched. After some of those reboots there is silence for some hours before it is starting over. Can you tell me where I should look at to fix that problem? Regards Bernhard Dick

6 years, 11 months

2
5
0 / 0

VM's disk stuck in migrating state

by nicolas＠devels.es

Hi, We're running oVirt 4.1.9 (I know it's not the recommended version, but we can't upgrade yet) and recently we had an issue with a Storage Domain while a VM was moving a disk. The Storage Domain went down for a few minutes, then it got back. However, the disk's state has stuck in a 'Migrating: 10%' state (see ss-2.png). I run the 'unlock_entity.sh' script to try to unlock the disk, with these parameters: # PGPASSWORD=... /usr/share/ovirt-engine/setup/dbutils/unlock_entity.sh -t disk -u engine -v b4013aba-a936-4a54-bb14-670d3a8b7c38 The disk's state changed to 'OK', but the actual state still states it's migrating (see ss-1.png). Calling the script with -t all doesn't make a difference either. Currently, the disk is unmanageable: cannot be deactivated, moved or copied, as it says there's a copying operation running already. Could someone provide a way to unlock this disk? I don't mind modifying a value directly into the database, I just need the copying process cancelled. Thanks.

6 years, 11 months

2
6
0 / 0

Re: Mailing-Lists upgrade

by Marc Dequènes (Duck)

I forgot to cross-post to other lists. Please read announcement below. On 05/08/2018 12:45 PM, Marc Dequènes (Duck) wrote: > Quack, > > On 04/28/2018 09:34 AM, Marc Dequènes (Duck) wrote: > >> A few months ago we had to rollback the migration because of a nasty >> bug. This is fixed in recent versions of Mailman 3 so we're rescheduling >> it on Tuesday 8th during the slot 11:00-12:00 JST. > > Just a word to say the migration happened and no problem was detected. > > The archive posts reindexation is not finished yet, and greylisting is > slowing down things a bit, but it should soon be over. Some information > like post count and little graphs in the web UI are handled via regular > cron jobs and should also soon be accurate. > > Old links to the archives, for pre-migration posts, are still working. > Posts URLS were not stable in Mailman 2 but been synced in > https://lists.ovirt.org/pipermail/ > > You can contact me directly by mail or IRC, or open a JIRA ticket if you > hit any problem. > > \_o< >

6 years, 11 months

9
20
1 / 0

adding a host

by Justin Zygmont

--_000_CY4PR12MB17986EA4B9FC960BE74D4896AB810CY4PR12MB1798namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have tried to add a host to the engine and it just takes forever never wo= rking or giving any error message. When I look in the engine's server.log = I see it says the networks are missing. I thought when you install a node and add it to the engine it will add the = networks automatically? The docs don't give much information about this, a= nd I can't even remove the host through the UI. What steps are required to= prepare a node when several vlans are involved? --_000_CY4PR12MB17986EA4B9FC960BE74D4896AB810CY4PR12MB1798namp_ 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"> <p class=3D"MsoNormal">I have tried to add a host to the engine and it just= takes forever never working or giving any error message.  When I look= in the engine’s server.log I see it says the networks are missing.<o= :p></o:p></p> <p class=3D"MsoNormal">I thought when you install a node and add it to the = engine it will add the networks automatically?  The docs don’t g= ive much information about this, and I can’t even remove the host thr= ough the UI.  What steps are required to prepare a node when several vlans are involved?<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </body> </html> --_000_CY4PR12MB17986EA4B9FC960BE74D4896AB810CY4PR12MB1798namp_--

6 years, 11 months

3
13
0 / 0

oVirt 4.2.3. iso question

by ovirt＠fateknollogee.com

Downloaded "ovirt-node-ng-installer-ovirt-4.2-2018051606.iso" from http://jenkins.ovirt.org/job/ovirt-node-ng_ovirt-4.2_build-artifacts-el7-... After rebooting any node, even though they all have valid IP addresses, I can not connect (via SSH) to any node unless I "systemctl restart network.service" Maybe I'm using the wrong iso?

6 years, 11 months

1
0
0 / 0

Custom Intel AMT fencing question

by Shawn Southern

I'm now using Intel AMT and the wsmancli package to reboot/power off/power on my entry level systems... but now I want oVirt to use this for fencing. I created 3 xml files: powercycle.xml (uses PowerState 10), poweron.xml (uses PowerState 2) and poweroff.xml (uses PowerState 8). Here is the poweroff.xml file: <p:RequestPowerStateChange_INPUT xmlns:p="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_PowerManagementService"> <p:PowerState>8</p:PowerState> <p:ManagedElement xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsman="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd"> <wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address> <wsa:ReferenceParameters> <wsman:ResourceURI>http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ComputerSystem</wsman:ResourceURI> <wsman:SelectorSet> <wsman:Selector Name="CreationClassName">CIM_ComputerSystem</wsman:Selector> <wsman:Selector Name="Name">ManagedSystem</wsman:Selector> </wsman:SelectorSet> </wsa:ReferenceParameters> </p:ManagedElement> </p:RequestPowerStateChange_INPUT> I can then reboot or power on/off the server with: wsman invoke -a RequestPowerStateChange http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_PowerManagementService -h [AMT IP] -P 16992 -u admin -p [amt password] -J /fencing/poweron.xml (or poweroff.xml, etc). My question is, how do I move from this to using this for fencing in oVirt? Thanks!

6 years, 11 months

3
5
0 / 0

IP change in hyperconverged setup

by Demeter Tibor

Hi, I would like to change IP subnets of my hosts, but I have a glustered setup and I can't remove/re-add my hosts because "server having gluster volume". What will happen If I do force remove the host? It will kill or stop gluster on host? Thanks Regards, Tibor

6 years, 11 months

1
0
0 / 0

Copying/Cloning a VM to another server

by Alex Bartonek

Just trying to make sure there isnt an easier way to do what I'm doing. I dont have an HA environment in my homelab. I have 3 VM's and I wanted to copy them to my backup r710 which runs oVirt 4.2. I basically shut down my VM, exported it to an export domain on my primary r710. Then detached the export domain on the primary. On my "standby" r710 I imported the export domain from the primary r710, attached, activated and imported the VM. Worked as expected. I'm assuming this is the correct way to do so. I've tried Export to OVA but that didnt work like I wanted and I didnt care to keep messing with that option. Thanks -Alex Sent with [ProtonMail](https://protonmail.com) Secure Email.

6 years, 11 months

3
5
0 / 0

Upgrade from 4.1 to 4.2.3 failed

by John Florian

When I run engine-setup, I get this error: [ ERROR ] Yum [u'Errors were encountered while downloading packages.', u'gdeploy-2.0.6-1.el7.noarch: failure: gdeploy-2.0.6-1.el7.noarch.rpm from ovirt-4.1-centos-gluster38: [Errno 256] No more mirrors to try.\nhttp://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8/gdeplo...: [Errno 14] HTTP Error 404 - Not Found'] [ ERROR ] Failed to execute stage 'Package installation': [u'Errors were encountered while downloading packages.', u'gdeploy-2.0.6-1.el7.noarch: failure: gdeploy-2.0.6-1.el7.noarch.rpm from ovirt-4.1-centos-gluster38: [Errno 256] No more mirrors to try.\nhttp://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8/gdeplo...: [Errno 14] HTTP Error 404 - Not Found'] If I go exploring with my browser, it doesn't appear that http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.8 exists any more. The oldest there is 3.10. I didn't see any mention of needing to revise this repo config, but I obviously must have missed something. -- John Florian

6 years, 11 months

3
3
0 / 0

Unable to connect to vm's via Console

by Bryan Sockel

Not entirely sure what happened, but I am no longer able to connect to the console on any of my vm’s. I receive the error “No CA Found!”.

6 years, 11 months

1
0
0 / 0

Volume id incorrect

by Marcelo Leandro

Description of problem: I tried do an live storage migration but this failed, after I re-tried and I had this error menssage. storage origem (10.16.2.110) storage destination (10.16.2.105) HSMGetAllTasksStatusesVDS failed: Volume already exists: ('4072fd70-962c-40f7-898c-e7df5ad25725',) this volume exists in the 2 storages. but in database show that the vm run in the frist storage(origem). find / -name 4072fd70-962c-40f7-898c-e7df5ad25725 /rhev/data-center/mnt/10.16.2.110:_home_nfs/49b89dd4-b718-4a9e-8024-8d656ac9b3bd/images/67f7d6aa-d983-48c4-852b-7258d09c3881/4072fd70-962c-40f7-898c-e7df5ad25725 /rhev/data-center/mnt/10.16.2.105:_home_nfs/3d65830f-afb3-4663-828c-42adff11de85/images/67f7d6aa-d983-48c4-852b-7258d09c3881/4072fd70-962c-40f7-898c-e7df5ad25725 but when a run this command in the host that vm started: ps aux | grep SEMARH* Show that run another volume id: -drive file=/rhev/data-center/mnt/10.16.2.110:_home_nfs/49b89dd4-b718-4a9e-8024-8d656ac9b3bd/images/67f7d6aa-d983-48c4-852b-7258d09c3881/fe85c5da-10fe-4698-975d-22bfa6362762 and this volume not exist: qemu-img info /rhev/data-center/mnt/10.16.2.110:_home_nfs/49b89dd4-b718-4a9e-8024-8d656ac9b3bd/images/67f7d6aa-d983-48c4-852b-7258d09c3881/fe85c5da-10fe-4698-975d-22bfa6362762 qemu-img: Could not open '/rhev/data-center/mnt/10.16.2.110:_home_nfs/49b89dd4-b718-4a9e-8024-8d656ac9b3bd/images/67f7d6aa-d983-48c4-852b-7258d09c3881/fe85c5da-10fe-4698-975d-22bfa6362762': Could not open '/rhev/data-center/mnt/10.16.2.110:_home_nfs/49b89dd4-b718-4a9e-8024-8d656ac9b3bd/images/67f7d6aa-d983-48c4-852b-7258d09c3881/fe85c5da-10fe-4698-975d-22bfa6362762': No such file or directory qemu-img info /rhev/data-center/mnt/10.16.2.110:_home_nfs/49b89dd4-b718-4a9e-8024-8d656ac9b3bd/images/67f7d6aa-d983-48c4-852b-7258d09c3881/fe85c5da-10fe-4698-975d-22bfa6362762 qemu-img: Could not open '/rhev/data-center/mnt/10.16.2.110:_home_nfs/49b89dd4-b718-4a9e-8024-8d656ac9b3bd/images/67f7d6aa-d983-48c4-852b-7258d09c3881/fe85c5da-10fe-4698-975d-22bfa6362762': Could not open '/rhev/data-center/mnt/10.16.2.110:_home_nfs/49b89dd4-b718-4a9e-8024-8d656ac9b3bd/images/67f7d6aa-d983-48c4-852b-7258d09c3881/fe85c5da-10fe-4698-975d-22bfa6362762': No such file or directory If I run md5sum and hash not change: md5sum /rhev/data-center/mnt/10.16.2.110\:_home_nfs/49b89dd4-b718-4a9e-8024-8d656ac9b3bd/images/67f7d6aa-d983-48c4-852b-7258d09c3881/4072fd70-962c-40f7-898c-e7df5ad25725 38021c8f670332f2f6ade6486b7a06eb /rhev/data-center/mnt/10.16.2.110:_home_nfs/49b89dd4-b718-4a9e-8024-8d656ac9b3bd/images/67f7d6aa-d983-48c4-852b-7258d09c3881/4072fd70-962c-40f7-898c-e7df5ad25725 after 10 min: md5sum /rhev/data-center/mnt/10.16.2.110\:_home_nfs/49b89dd4-b718-4a9e-8024-8d656ac9b3bd/images/67f7d6aa-d983-48c4-852b-7258d09c3881/4072fd70-962c-40f7-898c-e7df5ad25725 38021c8f670332f2f6ade6486b7a06eb /rhev/data-center/mnt/10.16.2.110:_home_nfs/49b89dd4-b718-4a9e-8024-8d656ac9b3bd/images/67f7d6aa-d983-48c4-852b-7258d09c3881/4072fd70-962c-40f7-898c-e7df5ad25725 another storage: 24eeb2845cbfda238b78fa165c21607d /rhev/data-center/mnt/10.16.2.105:_home_nfs/3d65830f-afb3-4663-828c-42adff11de85/images/67f7d6aa-d983-48c4-852b-7258d09c3881/4072fd70-962c-40f7-898c-e7df5ad25725 after 10 min: 24eeb2845cbfda238b78fa165c21607d /rhev/data-center/mnt/10.16.2.105:_home_nfs/3d65830f-afb3-4663-828c-42adff11de85/images/67f7d6aa-d983-48c4-852b-7258d09c3881/4072fd70-962c-40f7-898c-e7df5ad25725 Version-Release number of selected component (if applicable): oVirt engine - 4.1.9 Vdsm - 4.20.23 the vm run normaly and I already restart this. Thank you.

6 years, 11 months

1
0
0 / 0

Hosted Engine Setup error (v4.2.3)

by ovirt＠fateknollogee.com

Engine network config error Following this blog post: https://www.ovirt.org/blog/2018/02/up-and-running-with-ovirt-4-2-and-glus... I get an error saying the hosted engine setup is "trying" to use vibr0 (192.168.xxx.x) even though I have the bridge interface set to "eno1" Regardless of whether the Edit Hosts File is checked or unchecked, it overwrites my engine IP entry from 10.50.235.x to 192.168.xxx.x The same thing happens whether I set the engine IP to Static or DHCP (I don't have DNS, I'm using static entries in /etc/hosts). Any ideas it "insists" on using "vibr0" instead of "eno1"? **also posted this on IRC

6 years, 11 months

1
0
0 / 0

Private VLANs

by Colin Coe

Hi all We running RHEV 4.1.10 on HPE Blade servers using Virtual Connect which talk to Cisco switches. I want to implement private VLANs, does the combination of oVirt + Cisco switches + HPE Virtual Connect work with private VLANs? To be clear, I want to have a couple of logical networks (i.e. VLANs) where the nodes in that VLAN cannot talk directly but must go through the router/firewall. Thanks CC

6 years, 11 months

3
2
0 / 0

Ovirt host becomes non_operational

by 03ce007＠gmail.com

I am setting up self-hosted-ovirt-engine (4.2) on centos7.4. While running hosted-engine --deploy script, it fails at "Check host status" with 'host has been set in non_operational status' error. logs on engine vm at /var/log/ovirt-engine/host-deploy shows ansible tasl for "add host" ran successfully, but yet after that the host becomes non_operational! Where can i find more information on this error? Thank you.

6 years, 11 months

2
1
0 / 0

[ANN] introducing ovirt-openshift-extensions

by Roy Golan

Hi all, Running Openshift on oVirt seems more and more attractive and is starting to get attention. It is very easy to do so today without needing any special configuration, however, to tighten the integration and to take advantage of the underlying infra provider(ovirt) we can do better. For example, oVirt can connect various storage providers, and serve disk space to containers[1][2]. Also, Openshift can ask oVirt for VMs and deploy them as master or application nodes for its usage, without making the administrator doing all that manually. This project[1] is the home for the ovirt-flexvolume-driver and ovirt-provisioner[3] and merging ovirt-cloudprovider[4] is a work in progress. The code under this repository is work-in-progress and moving quickly, however, it has automation (stdci v2 :)) and is working and does at least what you observe in the demo videos. Yet I highly appreciate if any of you that will try will provide feedback be that #ovirt channel/ mailing list or to report bugs directly in the Github project page <https://github.com/oVirt/ovirt-openshift-extensions> [1] https://github.com/oVirt/ovirt-openshift-extensions [2] https://ovirt.org/blog/2018/02/your-container-volumes-served-by-ovirt/ [3] https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/ [4] https://github.com/rgolangh/ovirt-k8s-cloudprovider Thanks, Roy

6 years, 11 months

1
0
0 / 0

Host needs to be reinstalled message

by Gianluca Cecchi

Hello, on a test environment in 4.1 when selecting an host, I get in the below pane the exclamation mark and aside it the phrase: Host needs to be reinstalled as important configuration changes were applied on it Where to get more information about what it thanks has changed? Could it be a change in bonding mode to generate this kind of message? Thanks, Gianluca

6 years, 11 months

1
0
0 / 0

What is "Active VM" snapshot

by nikita.a.ogurtsov＠gmail.com

Hi! Can anybody explain what is "Active VM" snapshot that present on each VM and does it contain VM memory snapshot? I need it for PCI assessment and did not found answer in documentation or any other public sources. Thanks!

6 years, 11 months

2
1
0 / 0

Re: Ovirt Self Hosted engine deploy fails

by Sumit Bharadia

thanks, i get below message *Failed to start ovn-controller.service: Unit not found.* isn't it included within appliance we get for self-hosted-ovirt-engine? On 14 May 2018 at 12:53, Simone Tiraboschi <stirabos(a)redhat.com> wrote: > > > On Mon, May 14, 2018 at 11:52 AM, Sumit Bharadia <03ce007(a)gmail.com> > wrote: > >> the output of: journalctl -xe -u ovn-controller >> -- No entries -- >> >> what is the command to manual restart of this service? >> > > systemctl start ovn-controller > > >> >> Thank you. >> >> On 14 May 2018 at 09:12, Simone Tiraboschi <stirabos(a)redhat.com> wrote: >> >>> >>> >>> On Mon, May 14, 2018 at 10:03 AM, Sumit Bharadia <03ce007(a)gmail.com> >>> wrote: >>> >>>> attached from engine VM. >>>> >>> >>> >>> The issue is here: >>> >>> 2018-05-14 08:04:50,596 p=26024 u=ovirt | TASK >>> [ovirt-provider-ovn-driver : Ensure ovn-controller is started] ************ >>> 2018-05-14 08:04:51,991 p=26024 u=ovirt | fatal: [ovirt]: FAILED! => { >>> "changed": false >>> } >>> >>> MSG: >>> >>> Unable to start service ovn-controller: A dependency job for >>> ovn-controller.service failed. See 'journalctl -xe' for details. >>> >>> >>> Can you please double check the output of: >>> journalctl -xe -u ovn-controller >>> >>> >>> >>>> >>>> Thank you. >>>> >>>> On 14 May 2018 at 08:46, Simone Tiraboschi <stirabos(a)redhat.com> wrote: >>>> >>>>> Hi, >>>>> can you please attach host-deploy logs? >>>>> You can find them under /var/log/ovirt-engine/host-deploy on the >>>>> engine VM (you can reach it with ssh from the host you tried to deploy). >>>>> >>>>> On Mon, May 14, 2018 at 9:27 AM, <03ce007(a)gmail.com> wrote: >>>>> >>>>>> I am trying to setup self hosted ovirt engine (4.2) on centos 7.4, >>>>>> but the setup fails after 'Add host' task on 'wait for the host to be up'. >>>>>> The log doesn't seem to give clear indication where the issue might be. But >>>>>> I got below when ssh manually into ovirt appliance where the engine-deploy >>>>>> runs and I see the host status as'install_failed'. >>>>>> >>>>>> Where the issue might be, and where can i find detailed log on >>>>>> failure? >>>>>> >>>>>> "ovirt_hosts": [ >>>>>> { >>>>>> "address": "ovirt", >>>>>> "affinity_labels": [], >>>>>> "auto_numa_status": "unknown", >>>>>> "certificate": { >>>>>> "organization": "ovirt", >>>>>> "subject": "O=ovirt,CN=ovirt" >>>>>> }, >>>>>> "cluster": { >>>>>> "href": "/ovirt-engine/api/clusters/ba >>>>>> 170b8e-5744-11e8-8676-00163e3c9a32", >>>>>> "id": "ba170b8e-5744-11e8-8676-00163e3c9a32" >>>>>> }, >>>>>> "comment": "", >>>>>> "cpu": { >>>>>> "speed": 0.0, >>>>>> "topology": {} >>>>>> }, >>>>>> "device_passthrough": { >>>>>> "enabled": false >>>>>> }, >>>>>> "devices": [], >>>>>> "external_network_provider_configurations": [], >>>>>> "external_status": "ok", >>>>>> "hardware_information": { >>>>>> "supported_rng_sources": [] >>>>>> }, >>>>>> "hooks": [], >>>>>> "href": "/ovirt-engine/api/hosts/aad0f >>>>>> e84-2a9b-446d-ac02-82a8f6eb2a3c", >>>>>> "id": "aad0fe84-2a9b-446d-ac02-82a8f6eb2a3c", >>>>>> "katello_errata": [], >>>>>> "kdump_status": "unknown", >>>>>> "ksm": { >>>>>> "enabled": false >>>>>> }, >>>>>> "max_scheduling_memory": 0, >>>>>> "memory": 0, >>>>>> "name": "ovirt", >>>>>> "network_attachments": [], >>>>>> "nics": [], >>>>>> "numa_nodes": [], >>>>>> "numa_supported": false, >>>>>> "os": { >>>>>> "custom_kernel_cmdline": "" >>>>>> }, >>>>>> "permissions": [], >>>>>> "port": 54321, >>>>>> "power_management": { >>>>>> "automatic_pm_enabled": true, >>>>>> "enabled": false, >>>>>> "kdump_detection": true, >>>>>> "pm_proxies": [] >>>>>> }, >>>>>> "protocol": "stomp", >>>>>> "se_linux": {}, >>>>>> "spm": { >>>>>> "priority": 5, >>>>>> "status": "none" >>>>>> }, >>>>>> "ssh": { >>>>>> "fingerprint": "SHA256:o98ZOygBK0jcfY+l5nfi0E >>>>>> GV9v3A4zjclG9d+C3U0WA", >>>>>> "port": 22 >>>>>> }, >>>>>> "statistics": [], >>>>>> "status": "install_failed", >>>>>> "storage_connection_extensions": [], >>>>>> "summary": { >>>>>> "total": 0 >>>>>> }, >>>>>> "tags": [], >>>>>> "transparent_huge_pages": { >>>>>> "enabled": false >>>>>> }, >>>>>> "type": "rhel", >>>>>> "unmanaged_networks": [], >>>>>> "update_available": false >>>>>> } >>>>>> _______________________________________________ >>>>>> Users mailing list -- users(a)ovirt.org >>>>>> To unsubscribe send an email to users-leave(a)ovirt.org >>>>>> >>>>> >>>>> >>>> >>> >> >

6 years, 11 months

1
0
0 / 0

Failed to upgrade from 4.1 to 4.2 - Postgre version required

by Aziz

Hi Ovirt users, I'm trying to upgrade my Ovirt from version 4.1 to 4.2, but I'm stuck when issuing the command *engine-setup* which returns the following errors : Upgrading PostgreSQL *[ ERROR ] Failed to execute stage 'Misc configuration': Command '/opt/rh/rh-postgresql95/root/usr/bin/postgresql-setup' failed to execute* [ INFO ] Yum Performing yum transaction rollback [ INFO ] Rolling back to the previous PostgreSQL instance (postgresql). [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20180426122630-rpkrel.log [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20180426122823-setup.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination *[ ERROR ] Execution of setup failed* Can anyone help to resolve this ? Thank you in advance. BR.

6 years, 11 months

4
12
0 / 0

Export Domain Lock File

by Nicholas Vaughan

Hi, Is there a lock file on the Export Domain which stops it being mounted to a 2nd instance of oVirt? We have a replicated Export Domain in a separate location that we would like to mount to a backup instance of oVirt for DR purposes. Thanks in advance. Nick

6 years, 11 months

1
0
0 / 0

Gluster quorum

by Demeter Tibor

Dear Ovirt Users, I've followed up the self-hosted-engine upgrade documentation, I upgraded my 4.1 system to 4.2.3. I upgaded the first node with yum upgrade, it seems working now fine. But since upgrade, the gluster informations seems to displayed incorrect on the admin panel. The volume yellow, and there are red bricks from that node. I've checked in console, I think my gluster is not degraded: root@n1 ~]# gluster volume list volume1 volume2 [root@n1 ~]# gluster volume info Volume Name: volume1 Type: Distributed-Replicate Volume ID: e0f568fa-987c-4f5c-b853-01bce718ee27 Status: Started Snapshot Count: 0 Number of Bricks: 3 x 3 = 9 Transport-type: tcp Bricks: Brick1: 10.104.0.1:/gluster/brick/brick1 Brick2: 10.104.0.2:/gluster/brick/brick1 Brick3: 10.104.0.3:/gluster/brick/brick1 Brick4: 10.104.0.1:/gluster/brick/brick2 Brick5: 10.104.0.2:/gluster/brick/brick2 Brick6: 10.104.0.3:/gluster/brick/brick2 Brick7: 10.104.0.1:/gluster/brick/brick3 Brick8: 10.104.0.2:/gluster/brick/brick3 Brick9: 10.104.0.3:/gluster/brick/brick3 Options Reconfigured: transport.address-family: inet performance.readdir-ahead: on nfs.disable: on storage.owner-uid: 36 storage.owner-gid: 36 performance.quick-read: off performance.read-ahead: off performance.io-cache: off performance.stat-prefetch: off performance.low-prio-threads: 32 network.remote-dio: enable cluster.eager-lock: enable cluster.quorum-type: auto cluster.server-quorum-type: server cluster.data-self-heal-algorithm: full cluster.locking-scheme: granular cluster.shd-max-threads: 8 cluster.shd-wait-qlength: 10000 features.shard: on user.cifs: off server.allow-insecure: on Volume Name: volume2 Type: Distributed-Replicate Volume ID: 68cfb061-1320-4042-abcd-9228da23c0c8 Status: Started Snapshot Count: 0 Number of Bricks: 3 x 3 = 9 Transport-type: tcp Bricks: Brick1: 10.104.0.1:/gluster2/brick/brick1 Brick2: 10.104.0.2:/gluster2/brick/brick1 Brick3: 10.104.0.3:/gluster2/brick/brick1 Brick4: 10.104.0.1:/gluster2/brick/brick2 Brick5: 10.104.0.2:/gluster2/brick/brick2 Brick6: 10.104.0.3:/gluster2/brick/brick2 Brick7: 10.104.0.1:/gluster2/brick/brick3 Brick8: 10.104.0.2:/gluster2/brick/brick3 Brick9: 10.104.0.3:/gluster2/brick/brick3 Options Reconfigured: nfs.disable: on performance.readdir-ahead: on transport.address-family: inet cluster.quorum-type: auto network.ping-timeout: 10 auth.allow: * performance.quick-read: off performance.read-ahead: off performance.io-cache: off performance.stat-prefetch: off performance.low-prio-threads: 32 network.remote-dio: enable cluster.eager-lock: enable cluster.server-quorum-type: server cluster.data-self-heal-algorithm: full cluster.locking-scheme: granular cluster.shd-max-threads: 8 cluster.shd-wait-qlength: 10000 features.shard: on user.cifs: off storage.owner-uid: 36 storage.owner-gid: 36 server.allow-insecure: on [root@n1 ~]# gluster volume status Status of volume: volume1 Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick 10.104.0.1:/gluster/brick/brick1 49152 0 Y 3464 Brick 10.104.0.2:/gluster/brick/brick1 49152 0 Y 68937 Brick 10.104.0.3:/gluster/brick/brick1 49161 0 Y 94506 Brick 10.104.0.1:/gluster/brick/brick2 49153 0 Y 3457 Brick 10.104.0.2:/gluster/brick/brick2 49153 0 Y 68943 Brick 10.104.0.3:/gluster/brick/brick2 49162 0 Y 94514 Brick 10.104.0.1:/gluster/brick/brick3 49154 0 Y 3465 Brick 10.104.0.2:/gluster/brick/brick3 49154 0 Y 68949 Brick 10.104.0.3:/gluster/brick/brick3 49163 0 Y 94520 Self-heal Daemon on localhost N/A N/A Y 54356 Self-heal Daemon on 10.104.0.2 N/A N/A Y 962 Self-heal Daemon on 10.104.0.3 N/A N/A Y 108977 Self-heal Daemon on 10.104.0.4 N/A N/A Y 61603 Task Status of Volume volume1 ------------------------------------------------------------------------------ There are no active volume tasks Status of volume: volume2 Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick 10.104.0.1:/gluster2/brick/brick1 49155 0 Y 3852 Brick 10.104.0.2:/gluster2/brick/brick1 49158 0 Y 68955 Brick 10.104.0.3:/gluster2/brick/brick1 49164 0 Y 94527 Brick 10.104.0.1:/gluster2/brick/brick2 49156 0 Y 3851 Brick 10.104.0.2:/gluster2/brick/brick2 49159 0 Y 68961 Brick 10.104.0.3:/gluster2/brick/brick2 49165 0 Y 94533 Brick 10.104.0.1:/gluster2/brick/brick3 49157 0 Y 3883 Brick 10.104.0.2:/gluster2/brick/brick3 49160 0 Y 68968 Brick 10.104.0.3:/gluster2/brick/brick3 49166 0 Y 94541 Self-heal Daemon on localhost N/A N/A Y 54356 Self-heal Daemon on 10.104.0.2 N/A N/A Y 962 Self-heal Daemon on 10.104.0.3 N/A N/A Y 108977 Self-heal Daemon on 10.104.0.4 N/A N/A Y 61603 Task Status of Volume volume2 ------------------------------------------------------------------------------ There are no active volume tasks I think ovirt can't read valid informations about gluster. I can't contiune upgrade of other hosts until this problem exist. Please help me:) Thanks Regards, Tibor

6 years, 11 months

3
14
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Users May 2018