February 2015 - Users - oVirt List Archives

Problem deploying ovirt-hosted-engine to iSCSI
by Justin Clacherty 26 Feb '15

26 Feb '15

Hi, I'm back to testing oVirt again but have come across a problem when trying to deploy the ovirt hosted engine with iSCSI. The deploy asks questions about iSCSI, finds the iSCSI target, asks for the iqn, then goes to start the storage server but stops there, hanging forever. In this state I can see that the iSCSI session has logged in and the drive appears in the system (as sdb) but that's it. It appears as though it's getting stuck when it tries to get the list of luns. Has anyone else come across this issue? Any ideas where I can start with troubleshooting? Cheers, Justin.

4 9

3.5.1 not detecting Haswell CPU
by Blaster 26 Feb '15

26 Feb '15

I just upgraded from a working 3.5.0 on F20 to 3.5.1. After the upgrade, 3.5.1 started detecting my i7-4790k as a Sandy Bridge, and not the Haswell it properly detected with 3.5.0. I had to force the CPU type to Sandy Bridge in order to bring the node up. vdsClient -s 0 getVdsCaps | grep cpu cpuCores = '4' cpuFlags = 'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,pdpe1gb,rdtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,est,tm2,ssse3,fma,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,movbe,popcnt,tsc_deadline_timer,aes,xsave,avx,f16c,rdrand,lahf_lm,abm,ida,arat,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,fsgsbase,tsc_adjust,bmi1,hle,avx2,smep,bmi2,erms,invpcid,rtm,xsaveopt,model_Nehalem,model_Conroe,model_coreduo,model_core2duo,model_Penryn,model_Westmere,model_n270,model_SandyBridge' cpuModel = 'Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz' cpuSockets = '1' cpuSpeed = '4300.000' cpuThreads = '8' numaNodes = {'0': {'cpus': [0, 1, 2, 3, 4, 5, 6, 7], 'totalMemory': '32022'}} # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz stepping : 3 microcode : 0x1c cpu MHz : 4299.843 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm xsaveopt bugs : bogomips : 7999.90 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management:

2 1

Automation and engine-setup
by Trey Dockendorf 26 Feb '15

26 Feb '15

I am attempting to update my Puppet module [1] that manages oVirt and have found my method for executing engine-setup works on a fresh install but fails if run after install, for example to enable reports. Normally I run this: yes 'Yes' | engine-setup --config-append=/var/lib/ovirt-engine/setup/answers/ovirt-engine-setup.conf However if I've already installed ovirt-engine and then install the packages for reports and re-run the above command it gets stuck at this step: [ INFO ] Stage: Setup validation During execution engine service will be stopped (OK, Cancel) [OK]: Since "Yes" is not a valid response my method does not work. Is there a flag I can provide in the answers file that would prevent the above prompt? I am semi familiar with using expect but was hoping to avoid using expect from within a Puppet module. Thanks, - Trey [1]: https://github.com/treydock/puppet-ovirt/tree/1.x

2 1

oVirt Weekly Meeting Minutes -- 2015-02-25
by Yaniv Dary 25 Feb '15

25 Feb '15

This is a multi-part message in MIME format. --------------090006090609050906030207 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Minutes: http://ovirt.org/meetings/ovirt/2015/ovirt.2015-02-25-15.01.html Minutes (text): http://ovirt.org/meetings/ovirt/2015/ovirt.2015-02-25-15.01.txt Log: http://ovirt.org/meetings/ovirt/2015/ovirt.2015-02-25-15.01.log.html ========================= #ovirt: oVirt Weekly Sync ========================= Meeting started by ydary at 15:01:18 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2015/ovirt.2015-02-25-15.01.log.html . Meeting summary --------------- * Agenda and roll Call (ydary, 15:01:30) * infra update (ydary, 15:01:30) * 3.5.z updates (ydary, 15:01:30) * 3.6.0 status (ydary, 15:01:30) * conferences and workshops (ydary, 15:01:30) * other topics (ydary, 15:01:30) * infra update (ydary, 15:03:42) * oVirt gerrit has been updated to version 2.10 and now uses SSL. (ydary, 15:06:00) * Strict generic cleanup was added to some jobs and is planned for all jobs, this is to release as much disk space possible. (ydary, 15:07:41) * Slaves have been losing network configuration (dhclient dying), troubleshooting done this week to resolve this. (ydary, 15:08:45) * Some hosts of phx lab are a bit overloaded due to lack of RAM, workload has increased. (ydary, 15:13:21) * ACTION: mvk to discuss how to balance the memory capacity automatically with SLA team (rgolan). (ydary, 15:14:06) * there are plans to upgrade RAM on phx hosts, no schedule set. Memory usage is on average 70-80%~. (ydary, 15:15:38) * 3.5.z updates (ydary, 15:16:46) * Status update at: http://lists.ovirt.org/pipermail/users/2015-February/031551.html (ydary, 15:17:19) * 3.5.2 RC postponed due to blockers. (ydary, 15:17:41) * ACTION: please re-targeted 3.5.2 bugs that did not converge to 3.5.3. (ydary, 15:18:58) * Blocker was about bad handling of zombie tasks while upgrading from previous versions. Taskclenaer util has been now changed by infra and setup must be updated for using the new command line options. (ydary, 15:19:58) * 3.6 status (ydary, 15:21:22) * Status update for 3.6.0: http://lists.ovirt.org/pipermail/users/2015-February/031587.html. (ydary, 15:21:55) * Schedule for 3.6 published. (ydary, 15:22:04) * LINK: https://hibernate.atlassian.net/browse/HV-861 (jhernand, 15:26:35) * Integration 3.6.0 Update: Fedora >= 21 we have jdk 1.8 which doesn't work with jboss-as 7. fc21 doesn't have Java 7 rpms and will EOL in April. (ydary, 15:29:40) * A suggestion was made to move to wildfly. A patch for packaging wildfly 8.2 binaries on EL was submitted. (ydary, 15:31:01) * A bug in one of JBoss' packages is holding us back. That bug will be fixed in Hibernate validator 5.2. (ydary, 15:31:59) * Link to issue: https://hibernate.atlassian.net/browse/HV-861 (ydary, 15:32:49) * It was suggested to replace the hibernate validator included in WildFly 8.2 with version 5.2, where the bug will be fixed. (ydary, 15:33:56) * This suggestion is only valid on fc22. On f21, el6 and el7 we can ship wildfly 8.2 binaries in our repositories. (ydary, 15:35:46) * This is similar to the current approach on some platform aka ovirt-engine-jboss-as providing jboss. (ydary, 15:36:43) * ACTION: If we plan to move to wildfly 8.2 we need to prepare the jenkins job for the packaging, spec file is already merged. (ydary, 15:37:21) * ACTION: sbonazzo rgolan1 jhernand to discuss who will push engine patches, create build job for engine ans so on and will update next week. (ydary, 15:40:43) * ACTION: sbonazzo rgolan1 jhernand to get commitment for this task from infra team. (ydary, 15:41:44) * Moving to wildfly will have to come together with support for Java 8. (ydary, 15:44:09) * Other integration topics: (ydary, 15:44:16) * FC support for hosted engine now available for testing in master snapshot (ydary, 15:44:44) * tiraboschi started porting vdsm to debian jessie. (ydary, 15:45:08) * Debian support led to several patches and opened several bugs about vdsm, ioprocess and others. (ydary, 15:45:40) * New RFEs on docker images for OpenStack services for oVirt 3.6.0. (ydary, 15:48:34) * Node 3.6.0 Update: Progress on node automation and regular el6 and el7 builds in jenkins are available for download. Also continued planning fo 3.6 and will add a feature page for the installation through anaconda. (ydary, 15:50:44) * UX 3.6.0 Update: No updates. Patches are pending for review\merge. (ydary, 15:52:55) * Network 3.6.0 Update: Progress on SR-IOV, some functionality already working already. Other than that no updates. (ydary, 15:54:40) * SLA 3.6.0 Update: ongoing effort for the REST API of quota. A Wiki with the progress will be up hopefully this week (ydary, 15:59:19) * also rgolan started researching edit hosted engine ongoing with sbonazzo and mlipchuk from storage team. Technical gap analysis and initial design pending. (ydary, 16:00:34) * Gluster update for 3.6.0: Sahina made progress on snapshot and geo-replication management - number of patches merged. Gluster storage network role patches posted. (ydary, 16:03:01) * ACTION: network team needs to review gluster storage network role patches posted. (ydary, 16:03:21) * Brick provisioning patches to be reviewed. (ydary, 16:05:06) * Storage update for 3.6.0: SPM removal had good discussions with infra stakeholders. we have a clear path forward, although some infra work is required. (ydary, 16:07:01) * Cinder-Ceph work had several good discussions with other stakeholders, seems on track. (ydary, 16:07:22) * Several other minor RFEs converging. (ydary, 16:07:50) * Storage integration work with EL7.1 being done and should be backported to 3.5.3. (ydary, 16:08:52) * Virt update for 3.6.0: No one attended from the team. (ydary, 16:10:53) * Infra update for 3.6.0: All the items are updated in the 3.6 planning wiki. Work in progress on most items that include: upgrade manager, uniform SSO support, fencing re-factoring, events mechanism, SPM removal action items, v2v action items, etc. (ydary, 16:12:25) * conferences and workshops (ydary, 16:13:17) * SCALE and LF Collab were a big success! *Lots* of new oVirt t-shirts and discussions were held at the booth. People definitely know more about oVirt now. (ydary, 16:14:37) * mlipchuk and bkp will be attending FOSSAsia in a couple of weeks, and hosting the half-day workshop on March 14. (ydary, 16:15:06) * ACTION: Push the workshop in FOSSAsia on social media as you can, and if you have colleagues in east Asia, ask them for some social media love, too, please! (ydary, 16:15:41) * bkp will be on the planning board for KVM Forum this year, which will be in Seattle on Aug 19-21. (ydary, 16:16:19) * Rene Koch will be speaking at Chemnitzer Linux Days on Sunday March, 22nd. gshereme will be speaking on "Using Bootstrap with Google Web Toolkit" as POSSCON in South Carolina on April 14-15. (ydary, 16:16:43) * ACTION: if you have any local LUG or datacenter user group in your area, check in with bkp and we can get you set up for a mini-talk to spread the oVirt word. (ydary, 16:17:22) * other topics (ydary, 16:17:46) * CentOS Virt SIG Meeting Minutes at: http://www.centos.org/minutes/2015/february/centos-devel.2015-02-24-14.07.l… (ydary, 16:18:16) * Some packages have been built for virt sig, roadmap is still long. See link: http://wiki.centos.org/SpecialInterestGroup/Virtualization/Roadmap . (ydary, 16:20:04) * ACTION: help needed to sbonazzo to provide missing packages for CentOS Virt SIG. (ydary, 16:20:51) * A new case study is out (http://www.ovirt.org/Universidad_de_Sevilla_Case_Study) oVirt is helping to deploy virtual desktops for up to 3,000 students at the Universidad de Sevilla in Spain. Eventually, over 60,000 students wil be served as this program scales up. (ydary, 16:22:21) * getting reports that oVirt is in use by LibreOffice, BP, Samsung and possibly even Apple. I am tracking those down for future case studies. If you have any knowledge of users running oVirt that could be interesting, let bkp know! (ydary, 16:22:49) * because of their respective work on containers and NFV, Joe Brockmeier and Frank Zdarsky will be visiting TLV this Spring to meet with people. bkp will join as well. Exact schedule is still not set. (ydary, 16:23:39) Meeting ended at 16:25:08 UTC. Action Items ------------ * mvk to discuss how to balance the memory capacity automatically with SLA team (rgolan). * please re-targeted 3.5.2 bugs that did not converge to 3.5.3. * If we plan to move to wildfly 8.2 we need to prepare the jenkins job for the packaging, spec file is already merged. * sbonazzo rgolan1 jhernand to discuss who will push engine patches, create build job for engine ans so on and will update next week. * sbonazzo rgolan1 jhernand to get commitment for this task from infra team. * network team needs to review gluster storage network role patches posted. * Push the workshop in FOSSAsia on social media as you can, and if you have colleagues in east Asia, ask them for some social media love, too, please! * if you have any local LUG or datacenter user group in your area, check in with bkp and we can get you set up for a mini-talk to spread the oVirt word. * help needed to sbonazzo to provide missing packages for CentOS Virt SIG. Action Items, by person ----------------------- * bkp * if you have any local LUG or datacenter user group in your area, check in with bkp and we can get you set up for a mini-talk to spread the oVirt word. * jhernand * sbonazzo rgolan1 jhernand to discuss who will push engine patches, create build job for engine ans so on and will update next week. * sbonazzo rgolan1 jhernand to get commitment for this task from infra team. * mvk * mvk to discuss how to balance the memory capacity automatically with SLA team (rgolan). * rgolan * mvk to discuss how to balance the memory capacity automatically with SLA team (rgolan). * sbonazzo rgolan1 jhernand to discuss who will push engine patches, create build job for engine ans so on and will update next week. * sbonazzo rgolan1 jhernand to get commitment for this task from infra team. * rgolan1 * sbonazzo rgolan1 jhernand to discuss who will push engine patches, create build job for engine ans so on and will update next week. * sbonazzo rgolan1 jhernand to get commitment for this task from infra team. * sbonazzo * sbonazzo rgolan1 jhernand to discuss who will push engine patches, create build job for engine ans so on and will update next week. * sbonazzo rgolan1 jhernand to get commitment for this task from infra team. * help needed to sbonazzo to provide missing packages for CentOS Virt SIG. * **UNASSIGNED** * please re-targeted 3.5.2 bugs that did not converge to 3.5.3. * If we plan to move to wildfly 8.2 we need to prepare the jenkins job for the packaging, spec file is already merged. * network team needs to review gluster storage network role patches posted. * Push the workshop in FOSSAsia on social media as you can, and if you have colleagues in east Asia, ask them for some social media love, too, please! People Present (lines said) --------------------------- * ydary (131) * sbonazzo (59) * rgolan1 (27) * bkp (20) * jhernand (18) * lvernia (17) * mvk (11) * sahina (10) * dcaro (10) * amureini (9) * rgolan (6) * obelix (5) * fabiand (5) * awels (2) * alonbl (2) * saggi (2) * ovirtbot (2) * alitke (1) * doron_afk (1) * fkobzik (1) * didi (1) * ykaplan (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Yaniv Dary Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: ydary(a)redhat.com IRC : ydary --------------090006090609050906030207 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"> Minutes: <a class="moz-txt-link-freetext" href="http://ovirt.org/meetings/ovirt/2015/ovirt.2015-02-25-15.01.html">http://ovirt.org/meetings/ovirt/2015/ovirt.2015-02-25-15.01.html</a> Minutes (text): <a class="moz-txt-link-freetext" href="http://ovirt.org/meetings/ovirt/2015/ovirt.2015-02-25-15.01.txt">http://ovirt.org/meetings/ovirt/2015/ovirt.2015-02-25-15.01.txt</a> Log: <a class="moz-txt-link-freetext" href="http://ovirt.org/meetings/ovirt/2015/ovirt.2015-02-25-15.01.log.html">http://ovirt.org/meetings/ovirt/2015/ovirt.2015-02-25-15.01.log.html</a> <pre>========================= #ovirt: oVirt Weekly Sync ========================= Meeting started by ydary at 15:01:18 UTC. The full logs are available at <a class="moz-txt-link-freetext" href="http://ovirt.org/meetings/ovirt/2015/ovirt.2015-02-25-15.01.log.html">http://ovirt.org/meetings/ovirt/2015/ovirt.2015-02-25-15.01.log.html</a> . Meeting summary --------------- * Agenda and roll Call (ydary, 15:01:30) * infra update (ydary, 15:01:30) * 3.5.z updates (ydary, 15:01:30) * 3.6.0 status (ydary, 15:01:30) * conferences and workshops (ydary, 15:01:30) * other topics (ydary, 15:01:30) * infra update (ydary, 15:03:42) * oVirt gerrit has been updated to version 2.10 and now uses SSL. (ydary, 15:06:00) * Strict generic cleanup was added to some jobs and is planned for all jobs, this is to release as much disk space possible. (ydary, 15:07:41) * Slaves have been losing network configuration (dhclient dying), troubleshooting done this week to resolve this. (ydary, 15:08:45) * Some hosts of phx lab are a bit overloaded due to lack of RAM, workload has increased. (ydary, 15:13:21) * ACTION: mvk to discuss how to balance the memory capacity automatically with SLA team (rgolan). (ydary, 15:14:06) * there are plans to upgrade RAM on phx hosts, no schedule set. Memory usage is on average 70-80%~. (ydary, 15:15:38) * 3.5.z updates (ydary, 15:16:46) * Status update at: <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/pipermail/users/2015-February/031551.html">http://lists.ovirt.org/pipermail/users/2015-February/031551.html</a> (ydary, 15:17:19) * 3.5.2 RC postponed due to blockers. (ydary, 15:17:41) * ACTION: please re-targeted 3.5.2 bugs that did not converge to 3.5.3. (ydary, 15:18:58) * Blocker was about bad handling of zombie tasks while upgrading from previous versions. Taskclenaer util has been now changed by infra and setup must be updated for using the new command line options. (ydary, 15:19:58) * 3.6 status (ydary, 15:21:22) * Status update for 3.6.0: <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/pipermail/users/2015-February/031587.html">http://lists.ovirt.org/pipermail/users/2015-February/031587.html</a>. (ydary, 15:21:55) * Schedule for 3.6 published. (ydary, 15:22:04) * LINK: <a class="moz-txt-link-freetext" href="https://hibernate.atlassian.net/browse/HV-861">https://hibernate.atlassian.net/browse/HV-861</a> (jhernand, 15:26:35) * Integration 3.6.0 Update: Fedora >= 21 we have jdk 1.8 which doesn't work with jboss-as 7. fc21 doesn't have Java 7 rpms and will EOL in April. (ydary, 15:29:40) * A suggestion was made to move to wildfly. A patch for packaging wildfly 8.2 binaries on EL was submitted. (ydary, 15:31:01) * A bug in one of JBoss' packages is holding us back. That bug will be fixed in Hibernate validator 5.2. (ydary, 15:31:59) * Link to issue: <a class="moz-txt-link-freetext" href="https://hibernate.atlassian.net/browse/HV-861">https://hibernate.atlassian.net/browse/HV-861</a> (ydary, 15:32:49) * It was suggested to replace the hibernate validator included in WildFly 8.2 with version 5.2, where the bug will be fixed. (ydary, 15:33:56) * This suggestion is only valid on fc22. On f21, el6 and el7 we can ship wildfly 8.2 binaries in our repositories. (ydary, 15:35:46) * This is similar to the current approach on some platform aka ovirt-engine-jboss-as providing jboss. (ydary, 15:36:43) * ACTION: If we plan to move to wildfly 8.2 we need to prepare the jenkins job for the packaging, spec file is already merged. (ydary, 15:37:21) * ACTION: sbonazzo rgolan1 jhernand to discuss who will push engine patches, create build job for engine ans so on and will update next week. (ydary, 15:40:43) * ACTION: sbonazzo rgolan1 jhernand to get commitment for this task from infra team. (ydary, 15:41:44) * Moving to wildfly will have to come together with support for Java 8. (ydary, 15:44:09) * Other integration topics: (ydary, 15:44:16) * FC support for hosted engine now available for testing in master snapshot (ydary, 15:44:44) * tiraboschi started porting vdsm to debian jessie. (ydary, 15:45:08) * Debian support led to several patches and opened several bugs about vdsm, ioprocess and others. (ydary, 15:45:40) * New RFEs on docker images for OpenStack services for oVirt 3.6.0. (ydary, 15:48:34) * Node 3.6.0 Update: Progress on node automation and regular el6 and el7 builds in jenkins are available for download. Also continued planning fo 3.6 and will add a feature page for the installation through anaconda. (ydary, 15:50:44) * UX 3.6.0 Update: No updates. Patches are pending for review\merge. (ydary, 15:52:55) * Network 3.6.0 Update: Progress on SR-IOV, some functionality already working already. Other than that no updates. (ydary, 15:54:40) * SLA 3.6.0 Update: ongoing effort for the REST API of quota. A Wiki with the progress will be up hopefully this week (ydary, 15:59:19) * also rgolan started researching edit hosted engine ongoing with sbonazzo and mlipchuk from storage team. Technical gap analysis and initial design pending. (ydary, 16:00:34) * Gluster update for 3.6.0: Sahina made progress on snapshot and geo-replication management - number of patches merged. Gluster storage network role patches posted. (ydary, 16:03:01) * ACTION: network team needs to review gluster storage network role patches posted. (ydary, 16:03:21) * Brick provisioning patches to be reviewed. (ydary, 16:05:06) * Storage update for 3.6.0: SPM removal had good discussions with infra stakeholders. we have a clear path forward, although some infra work is required. (ydary, 16:07:01) * Cinder-Ceph work had several good discussions with other stakeholders, seems on track. (ydary, 16:07:22) * Several other minor RFEs converging. (ydary, 16:07:50) * Storage integration work with EL7.1 being done and should be backported to 3.5.3. (ydary, 16:08:52) * Virt update for 3.6.0: No one attended from the team. (ydary, 16:10:53) * Infra update for 3.6.0: All the items are updated in the 3.6 planning wiki. Work in progress on most items that include: upgrade manager, uniform SSO support, fencing re-factoring, events mechanism, SPM removal action items, v2v action items, etc. (ydary, 16:12:25) * conferences and workshops (ydary, 16:13:17) * SCALE and LF Collab were a big success! *Lots* of new oVirt t-shirts and discussions were held at the booth. People definitely know more about oVirt now. (ydary, 16:14:37) * mlipchuk and bkp will be attending FOSSAsia in a couple of weeks, and hosting the half-day workshop on March 14. (ydary, 16:15:06) * ACTION: Push the workshop in FOSSAsia on social media as you can, and if you have colleagues in east Asia, ask them for some social media love, too, please! (ydary, 16:15:41) * bkp will be on the planning board for KVM Forum this year, which will be in Seattle on Aug 19-21. (ydary, 16:16:19) * Rene Koch will be speaking at Chemnitzer Linux Days on Sunday March, 22nd. gshereme will be speaking on "Using Bootstrap with Google Web Toolkit" as POSSCON in South Carolina on April 14-15. (ydary, 16:16:43) * ACTION: if you have any local LUG or datacenter user group in your area, check in with bkp and we can get you set up for a mini-talk to spread the oVirt word. (ydary, 16:17:22) * other topics (ydary, 16:17:46) * CentOS Virt SIG Meeting Minutes at: <a class="moz-txt-link-freetext" href="http://www.centos.org/minutes/2015/february/centos-devel.2015-02-24-14.07.l…">http://www.centos.org/minutes/2015/february/centos-devel.2015-02-24-14.07.l…</a> (ydary, 16:18:16) * Some packages have been built for virt sig, roadmap is still long. See link: <a class="moz-txt-link-freetext" href="http://wiki.centos.org/SpecialInterestGroup/Virtualization/Roadmap">http://wiki.centos.org/SpecialInterestGroup/Virtualization/Roadmap</a> . (ydary, 16:20:04) * ACTION: help needed to sbonazzo to provide missing packages for CentOS Virt SIG. (ydary, 16:20:51) * A new case study is out (<a class="moz-txt-link-freetext" href="http://www.ovirt.org/Universidad_de_Sevilla_Case_Study">http://www.ovirt.org/Universidad_de_Sevilla_Case_Study</a>). oVirt is helping to deploy virtual desktops for up to 3,000 students at the Universidad de Sevilla in Spain. Eventually, over 60,000 students wil be served as this program scales up. (ydary, 16:22:21) * getting reports that oVirt is in use by LibreOffice, BP, Samsung and possibly even Apple. I am tracking those down for future case studies. If you have any knowledge of users running oVirt that could be interesting, let bkp know! (ydary, 16:22:49) * because of their respective work on containers and NFV, Joe Brockmeier and Frank Zdarsky will be visiting TLV this Spring to meet with people. bkp will join as well. Exact schedule is still not set. (ydary, 16:23:39) Meeting ended at 16:25:08 UTC. Action Items ------------ * mvk to discuss how to balance the memory capacity automatically with SLA team (rgolan). * please re-targeted 3.5.2 bugs that did not converge to 3.5.3. * If we plan to move to wildfly 8.2 we need to prepare the jenkins job for the packaging, spec file is already merged. * sbonazzo rgolan1 jhernand to discuss who will push engine patches, create build job for engine ans so on and will update next week. * sbonazzo rgolan1 jhernand to get commitment for this task from infra team. * network team needs to review gluster storage network role patches posted. * Push the workshop in FOSSAsia on social media as you can, and if you have colleagues in east Asia, ask them for some social media love, too, please! * if you have any local LUG or datacenter user group in your area, check in with bkp and we can get you set up for a mini-talk to spread the oVirt word. * help needed to sbonazzo to provide missing packages for CentOS Virt SIG. Action Items, by person ----------------------- * bkp * if you have any local LUG or datacenter user group in your area, check in with bkp and we can get you set up for a mini-talk to spread the oVirt word. * jhernand * sbonazzo rgolan1 jhernand to discuss who will push engine patches, create build job for engine ans so on and will update next week. * sbonazzo rgolan1 jhernand to get commitment for this task from infra team. * mvk * mvk to discuss how to balance the memory capacity automatically with SLA team (rgolan). * rgolan * mvk to discuss how to balance the memory capacity automatically with SLA team (rgolan). * sbonazzo rgolan1 jhernand to discuss who will push engine patches, create build job for engine ans so on and will update next week. * sbonazzo rgolan1 jhernand to get commitment for this task from infra team. * rgolan1 * sbonazzo rgolan1 jhernand to discuss who will push engine patches, create build job for engine ans so on and will update next week. * sbonazzo rgolan1 jhernand to get commitment for this task from infra team. * sbonazzo * sbonazzo rgolan1 jhernand to discuss who will push engine patches, create build job for engine ans so on and will update next week. * sbonazzo rgolan1 jhernand to get commitment for this task from infra team. * help needed to sbonazzo to provide missing packages for CentOS Virt SIG. * **UNASSIGNED** * please re-targeted 3.5.2 bugs that did not converge to 3.5.3. * If we plan to move to wildfly 8.2 we need to prepare the jenkins job for the packaging, spec file is already merged. * network team needs to review gluster storage network role patches posted. * Push the workshop in FOSSAsia on social media as you can, and if you have colleagues in east Asia, ask them for some social media love, too, please! People Present (lines said) --------------------------- * ydary (131) * sbonazzo (59) * rgolan1 (27) * bkp (20) * jhernand (18) * lvernia (17) * mvk (11) * sahina (10) * dcaro (10) * amureini (9) * rgolan (6) * obelix (5) * fabiand (5) * awels (2) * alonbl (2) * saggi (2) * ovirtbot (2) * alitke (1) * doron_afk (1) * fkobzik (1) * didi (1) * ykaplan (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: <a class="moz-txt-link-freetext" href="http://wiki.debian.org/MeetBot">http://wiki.debian.org/MeetBot</a> </pre> <pre class="moz-signature" cols="72">-- Yaniv Dary Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: <a class="moz-txt-link-abbreviated" href="mailto:ydary@redhat.com">ydary(a)redhat.com</a> IRC : ydary</pre> </body> </html> --------------090006090609050906030207--

1 0

[QE][ACTION NEEDED] oVirt 3.5.2 RC status - postponing
by Sandro Bonazzola 25 Feb '15

25 Feb '15

Hi, We still have one open blocker for 3.5.2[1]: Bug ID Whiteboard Status Summary 1161012 infra POST task cleaning utility should erase commands that have running tasks We need to postpone the RC until this will be fixed. The patch is already under review and verification so it shouldn't take too much. There are still 48 bugs [2] targeted to 3.5.2. Excluding node and documentation bugs we still have 42 bugs [3] targeted to 3.5.2. Whiteboard NEW ASSIGNED POST Total doc 1 0 0 1 docs 1 0 0 1 gluster 4 0 1 5 infra 4 2 8 14 integration 0 0 1 1 network 1 1 0 2 node 4 0 1 5 ppc 0 0 1 1 sla 4 0 0 4 storage 11 0 0 11 ux 1 0 0 1 virt 1 0 1 2 Total 32 3 13 48 Maintainers / Assignee: - Please add the bugs to the tracker if you think that 3.5.2 should not be released without them fixed. - Please update the target to 3.5.3 or later for bugs that won't be in 3.5.2: it will ease gathering the blocking bugs for next releases. - Please fill release notes, the page has been created and updated 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/1186161 [2] http://goo.gl/crVJPH [3] http://goo.gl/2qTZZU [4] http://www.ovirt.org/OVirt_3.5.2_Release_Notes [5] http://www.ovirt.org/Testing/oVirt_3.5.2_Testing -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 2

[QE][ACTION REQUIRED] oVirt 3.6.0 status
by Sandro Bonazzola 25 Feb '15

25 Feb '15

Hi, here's an update on 3.6 status on integration / rel-eng side Schedule for 3.6.0 has been published[1] and external project schedules have been updated[2]. The tracker bug for 3.6.0 [3] currently shows no blockers. There are 561 bugs [4] targeted to 3.6.0. Excluding node and documentation bugs we have 514 bugs [5] targeted to 3.6.0. NEW ASSIGNED POST Total docs 11 0 0 11 gluster 30 2 1 33 i18n 2 0 0 2 infra 83 8 5 96 integration 61 6 4 71 network 32 2 9 43 node 27 3 3 33 ppc 0 0 1 1 sla 53 3 0 56 spice 1 0 0 1 storage 74 4 5 83 ux 34 0 8 42 virt 73 6 10 89 Total 481 34 46 561 Features submission is still open until 2015-04-22 as per current release schedule. Be sure to have your features tracked in the google doc[6] >From integration side, Hosted Engine support for FC is available in nightly builds for testing. [1] http://www.ovirt.org/OVirt_3.6_Release_Management#Key_Milestones [2] http://www.ovirt.org/OVirt_3.6_Release_Management#External_Project_Schedules [3] https://bugzilla.redhat.com/show_bug.cgi?id=1155425 [4] https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_release%3A3.6.0%… [5] http://goo.gl/ZbUiMc [6] http://goo.gl/9X3G49 -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Error: Validating CPU Compatibility
by ronald suza 25 Feb '15

25 Feb '15

I am still a newbie and going through the ovirt "engine-setup" And I am getting an error ---> AIO: Validating CPU Compatibility... [ ERROR ] oVirt Engine will be installed using the following configuration: ================================================================= http-port: 80 https-port: 443 host-fqdn: ovirtmgr.localdomain auth-pass: ******** org-name: home default-dc-type: NFS db-remote-install: local db-local-pass: ******** nfs-mp: /mnt/iso iso-domain-name: iso override-iptables: no config-allinone: yes storage-path: /mnt/data superuser-pass: ******** Proceed with the configuration listed above? (yes|no): yes Installing: AIO: Validating CPU Compatibility... [ ERROR ] Error: Could not start libvirt service. Please try starting it manually and rerun the setup. Please check log file /var/log/ovirt-engine/engine-setup_2015_02_24_23_49_33.log for more information I examined the log " /var/log/ovirt-engine/engine-setup_2015_02_24_23_49_33.log": It consists of the following info: File "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py", line 184, in startLibvirt raise Exception(ERROR_LIBVIRT_START) Exception: Error: Could not start libvirt service. Please try starting it manually and rerun the setup. Please find the attached file "/usr/share/ovirt-engine/scripts/plugins/all_in_one_100.py" Appreciate your help.

2 1

Have some issues I am hoping to get resolution - farely new to administrating oVirt
by George Fleming 25 Feb '15

25 Feb '15

--_000_A0CC2893696FAC44AD706334E42C4D32822A36C9sisaex02sj_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Will try to be brief. I have had the following issue: Trying with spice console sessions access o= n VMs, was working till last week. I get: " Unable to connec= t to libvirt with URI: [none]. " I also tried to access thro= ugh ovirt-shell, the window pops up and disappears immediately. Revision: oVirt Engine Version: 3.5.1.1-1.= el6, recently upgraded to, to resolve a snapshot removal issue. I started seeing this after adding a new host to my oVirt C= luster. I have also recently had a problem had the root directory f= illing up, I have added space, but the disk was full a couple of days befor= e it was noticed. I have taken over management of this cluster, while I have = root to the host, vms, and engine - I don't have the admin password to oVir= t Engine, I would like to correct this as well. Thanks in advance for any help. George --_000_A0CC2893696FAC44AD706334E42C4D32822A36C9sisaex02sj_ 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 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Hi All,<o:p></o:p> <o:p> </o:p>         &nbs= p;       Will try to be brief.<o:p></o:p> <o:p> </o:p>         &nbs= p;       I have had the following issue:<o:p>= </o:p> <o:p> </o:p>         &nbs= p;            &= nbsp;          Trying with spi= ce console sessions access on VMs, was working till last week.<o:p></o:p></= p> <o:p> </o:p>         &nbs= p;            &= nbsp;            &nb= sp;            = I get:   “ Unable to connect to libvirt with URI: [none]. = ”<o:p></o:p> <o:p> </o:p>         &nbs= p;             =              &n= bsp;            I al= so tried to access through ovirt-shell, the window pops up and disappears i= mmediately. <o:p></o:p> <o:p> </o:p>         &nbs= p;            &= nbsp;          Revision: = oVirt Engine Version: 3.5.1.1-1.el6, recently upgraded to, to resolve a sna= pshot removal issue.<o:p></o:p> <o:p> </o:p>         &nbs= p;       I started seeing this after adding a= new host to my oVirt Cluster.<o:p></o:p> <o:p> </o:p>         &nbs= p;       I have also recently had a problem h= ad the root directory filling up, I have added space, but the disk was full= a couple of days before it was noticed.<o:p></o:p> <o:p> </o:p>         &nbs= p;       I have taken over management of this= cluster, while I have root to the host, vms, and engine – I don&#821= 7;t have the admin password to oVirt Engine, I would like to correct this a= s well.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Thanks in advance for any help.<o:p></o:p> <o:p> </o:p> George<o:p></o:p> <o:p> </o:p> <o:p> </o:p> </div> </body> </html> --_000_A0CC2893696FAC44AD706334E42C4D32822A36C9sisaex02sj_--

2 3

HA of VMs
by Matt Wells 24 Feb '15

24 Feb '15

I've been poking around for a better way to perform HA. With VM's like IPA or even HA web sites behind an HAProxy; how do I ensure that they are never on the same host? I've seen the options for watchdog and I can see where that may help a little, but not without the initial outage to trigger the alert. There are many ways to do this however I see few that scale. I'm sure I'm missing something and I really appreciate any guidance. Thanks all

2 1

oVirt Manager problem
by Massimo Mad 24 Feb '15

24 Feb '15

I have a problem on my oVirt manager, the problem is that the directory /var/lib/pgsql/data/base fills. Initially thinking that my file system /var/log 2Gb was too small now have increased to 4Gb and is refilled, i have increased again to 5 Gb and is refilled again. Why ? I have implemented the backup of the manager with the script backup.sh, this could be the cause of the problem ? Sorry in the script backup.sh there is this #!/bin/bash /usr/bin/engine-backup --mode=backup --scope=all --file="/root/ovirt-engine-backups/$(hostname)-backup-$(date +%A).tar.bz2" --log=/var/log/ovirt-engine-backups.log

1 0

oVirt Manager problem
by Massimo Mad 24 Feb '15

24 Feb '15

I have a problem on my oVirt manager, the problem is that the directory /var/lib/pgsql/data fills. Initially thinking that my file system /var/log 2Gb was too small now have increased to 4Gb and is refilled, i have increased again to 5 Gb and is refilled again. Why ? I have implemented the backup of the manager with the script backup.sh, this could be the cause of the problem ? Regards Massimo

2 1

Ovirt 3.5.x Power failure recovery
by Raymond 24 Feb '15

24 Feb '15

Hi, Long time read-only user here :) Unfortunately I need some info which I can't seem to find in the archives and on Google. In the past 5 months we’ve had two very rare occasions of power failures in my hometown. First one was a ms during spike or drop, just enough to cause a reboot, the other was a 30min failure. Problem After the power failure my ovirt nodes boot into CentOS 6.6 and are running fine. In both cases my ovirt-engine-VM wouldn't "start" due to service Postgresql not starting. I tried some things before reverting back to an older DB snapshot that was on the VM disk, but still not working. Postgresql is not starting due to "Duplicate UUID" My solution Calm down girlfriend and don't sleep Reinstall 1 node, create new ovirt-engine, recreate VM's and copy VM disk data from old store to new store. Add second node Other solutions I can think of 1. Start cluster without reinstall ;) 2. Buy UPS (€150 one time, extra €60 yearly power usage = €450 in 5 years) At this moment I’m 1 click away from buying the UPS, but I prefer a more elegant solution. After the last power failure I did NOT reinstall my second ovirt node and the old engine is also on storage available. Is there someone that wants some data to troubleshoot/analyse? Or is this just one of those things? Buy the UPS and get on with your life? Short HW overview 2x ovirt 3.5.x (i3/32GB ram,1Gb eth VM network, dual x520 NFS eth) 1x NFS (i3/4GB ram, 5TB SAS and 6TB SATA on Dell PERC,1Gb eth mgmt, dual x520 10Gb) 1Gb is used for VM networking, the 10Gb is connected via DAC cables and runs NFS-storage. This works great! Whole cluster runs below 120w and VM disk performance is around 700MB/s :) I bought all the HW with power usage in mind, PicoPSU's and 35w CPU's in all nodes. So adding 30w "extra" just for the UPS feels a bit like killing an elephant with tissues... kind regards Raymond

4 4

el6 vs el7
by Nathanaël Blanchet 24 Feb '15

24 Feb '15

Hi all, I'm planning to migrate my ovirt el6 hosts to el7. Excepting that el6 will not be supported in next release of ovirt, is there a difference of performance between el7 and el6? I mean, are qemu or libvirt for example at the same level of performance/capabilities in el6 than in el7 (knowing that qemu-kvm 0.12 is still backported on el6) ? I heard that el7.1 will support live merge, if true will el6.7 support it as well or the difference between them is there?

4 5

Local and remote storage?
by Pat Riehecky 24 Feb '15

24 Feb '15

Hello, I've run into an "odd" problem with oVirt 3.5.1. I've two sets of VMs: A) some fairly critical VMs which need HA and have access to shared storage B) some less important systems which can be reconstructed in the event of a disaster My plan was to use the slack disk on my oVirt nodes to host the 'B' systems while still allowing the 'A' systems to run there. This seems to not be allowed[1]. Is there a way I can utilize both the spare disk on my compute nodes and have HA configured for some VMs with shared storage? Pat [1] http://www.ovirt.org/OVirt_Administration_Guide#Preparing_Local_Storage -- Pat Riehecky Scientific Linux developer Fermi National Accelerator Laboratory www.fnal.gov www.scientificlinux.org

3 2

Re: [ovirt-users] [ovirt-devel] [QE][ACTION NEEDED] oVirt 3.5.2 RC status - postponing
by Oved Ourfali 24 Feb '15

24 Feb '15

On Feb 24, 2015 4:54 PM, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote: > > Hi, > We still have one open blocker for 3.5.2[1]: > > Bug ID Whiteboard Status Summary > 1161012 infra POST task cleaning utility should erase commands that have running tasks > Yair and Simone, what's blocking this one from getting merged? > We need to postpone the RC until this will be fixed. > The patch is already under review and verification so it shouldn't take too much. > > > There are still 48 bugs [2] targeted to 3.5.2. > Excluding node and documentation bugs we still have 42 bugs [3] targeted to 3.5.2. > > Whiteboard NEW ASSIGNED POST Total > doc 1 0 0 1 > docs 1 0 0 1 > gluster 4 0 1 5 > infra 4 2 8 14 > integration 0 0 1 1 > network 1 1 0 2 > node 4 0 1 5 > ppc 0 0 1 1 > sla 4 0 0 4 > storage 11 0 0 11 > ux 1 0 0 1 > virt 1 0 1 2 > Total 32 3 13 48 > > > Maintainers / Assignee: > - Please add the bugs to the tracker if you think that 3.5.2 should not be released without them fixed. > - Please update the target to 3.5.3 or later for bugs that won't be in 3.5.2: > it will ease gathering the blocking bugs for next releases. > - Please fill release notes, the page has been created and updated 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/1186161 > [2] http://goo.gl/crVJPH > [3] http://goo.gl/2qTZZU > [4] http://www.ovirt.org/OVirt_3.5.2_Release_Notes > [5] http://www.ovirt.org/Testing/oVirt_3.5.2_Testing > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > _______________________________________________ > Devel mailing list > Devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel

2 1

FYI FreeBSD on POWER8
by Jiri Belka 24 Feb '15

24 Feb '15

http://adrianchadd.blogspot.cz/2015/02/freebsd-on-power8-its-alive.html "...FreeBSD now boots inside of the hypervisor environment and seems stable enough to do development on." -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ~~ http://en.wikipedia.org/wiki/Posting_style

1 0

[ACTION REQUIRED] oVirt 3.5.2 branch created
by Sandro Bonazzola 24 Feb '15

24 Feb '15

Hi, oVirt 3.5.2 branch has been created on hash: * 405c933 - userportal, webadmin: allow SSO robots to fill in the login form (34 minutes ago) <Greg Sheremeta> All patches targeted to 3.5.2 will need to be cherry-picked on the 3.5.2 branch too. Thanks -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Guest VM Running 160 RCU Processes
by Punit Dambiwal 24 Feb '15

24 Feb '15

Hi, I have one Ovirt cluster and under this cluster all the guest machines (such as centos,ubuntu,debian etc) almost 160 RCU processes running.... i searched on google about the RCU (It's kernel process "read-copy-upate") http://lwn.net/Articles/518953/ I want to know how i can modify this 160 processes to 10-20 or how i can to disable it....is there any bed impact if i disable it.... Thanks, Punit

5 7

Ovirt & VPS & SingleSignOn
by Dubravko Sever 24 Feb '15

24 Feb '15

Hi, Currently I'm looking for new solution for providing VPS-s to my organization users, we don't need biling infrastructure.. Does anyone has case of ovirt as VPS management and user interface (please provide me some feedbacks)? And another question, what about integration with SingleSignOn infrastructure like shibboleth, based od SAML2? Thanks Dubravko -- Dubravko Sever Sektor za računalne sustave Sveučilište u Zagrebu, Sveučilišni računski centar (Srce), www.srce.unizg.hr Dubravko.Sever(a)srce.hr, tel: +385 1 616 5807, fax: +385 1 616 5559

2 2

Re: [ovirt-users] Problems re-attaching an export domain
by Allon Mureinik 23 Feb '15

23 Feb '15

Maor, don't we have an REF to improve this on our radar? ----- Original Message ----- > From: "Donny Davis" <donny(a)cloudspin.me> > To: "Chris Burckhard" <chris.burckhard(a)gmail.com> > Cc: users(a)ovirt.org > Sent: Saturday, February 7, 2015 12:20:26 AM > Subject: Re: [ovirt-users] Problems re-attaching an export domain > > Give this a try > > http://www.ovirt.org/How_to_clear_the_storage_domain_pool_config_of_an_expo… > Feb 4, 2015 2:30 PM, Chris Burckhard <chris.burckhard(a)gmail.com> wrote: > > > > I had some issues with the virtual manager after upgrading, so exported my > > virtual machines to an export domain, then I tried to do a reinstall of > > the os and ovirt to go back to a previous version. I know now, that I > > should have put the storage into maintenance before re-installing, but I > > didn’t. Is there any way to get the export domain added to a new storage > > domain if the old one is gone? > > > > Error message that I get I try to attach the storage: > > error while executing action attach storage domain: the domain is already > > used by another data center > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > > >

2 1

Re: [ovirt-users] ovirt and glusterfs setup
by Donny D 23 Feb '15

23 Feb '15

----_com.android.email_88339792828010 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CiAgICAKCldoYXQgaGUgc2FpZAoKSGFwcHkgQ29ubmVjdGluZy4gU2VudCBmcm9tIG15IFNwcmlu dCBTYW1zdW5nIEdhbGF4eSBTwq4gNQoKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0t LQpGcm9tOiBTY290dCBXb3J0aGluZ3RvbiA8c2NvdHQuYy53b3J0aGluZ3RvbkBnbWFpbC5jb20+ IApEYXRlOiAwMi8xOC8yMDE1ICAyOjAzIFBNICAoR01ULTA3OjAwKSAKVG86IERvbm55IEQgPGRv bm55QGNsb3Vkc3Bpbi5tZT4gClN1YmplY3Q6IFJlOiBbb3ZpcnQtdXNlcnNdIG92aXJ0IGFuZCBn bHVzdGVyZnMgc2V0dXAgCgo+IEkgZGlkIG5vdCBoYXZlIGEgZ29vZCBleHBlcmllbmNlIHB1dHRp bmcgYm90aCBnbHVzdGVyIGFuZCB2aXJ0IG9uIHRoZSBzYW1lCj4gbm9kZS4gSSB3YXMgZG9pbmcg aG9zdGVkIGVuZ2luZSB3aXRoIHJlcGxpY2F0ZSBhY3Jvc3MgdHdvIG5vZGVzLCBhbmQgb25lIGRh eQo+IGl0IHdlbnQgaW50byBzcGxpdCBicmFpbiBoZWxsLi4uIGkgd2FzIG5ldmVyIGFibGUgdG8g dHJhY2sgZG93biB3aHkuIEhvd2V2ZXIKPiBpIGRvIGhhdmUgYSBnbHVzdGVyIHdpdGggZGlzdHJp YnV0ZSBhbmQgcmVwbGljYSBzZXR1cCBvbiBpdHMgb3duIHdpdGggYQo+IGNvdXBsZSBub2Rlcywg YW5kIGl0IGhhcyBnaXZlbiBtZSB6ZXJvIHByb2JsZW1zIGluIHRoZSBsYXN0IDYwIGRheXMuIEl0 Cj4gc2VlbXMgdG8gbWUgdGhhdCBnbHVzdGVyIGFuZCB2aXJ0IG5lZWQgdG8gc3RheSBzZXBlcmF0 ZSBmb3Igbm93LiBCb3RoIGFyZQo+IGdyZWF0IHByb2R1Y3RzIGFuZCBib3RoIHdvcmsgYXMgZGVz Y3JpYmVkLCBqdXN0IG5vdCBvbiB0aGUgc2FtZSBub2RlIGF0IHRoZQo+IHNhbWUgdGltZS4KPgoK VGhlIGlzc3VlLCBhcyBJIHBlcmNlaXZlIGl0LCBpcyBuZXdiaWVzIGZpbmQgSmFzb24gQnJvb2sn cyBibG9nOgrCoCBodHRwOi8vY29tbXVuaXR5LnJlZGhhdC5jb20vYmxvZy8yMDE0LzExL3VwLWFu ZC1ydW5uaW5nLXdpdGgtb3ZpcnQtMy01LXBhcnQtdHdvLwoKQW5kIHRoZW4gbmV3YmllcyB0aGlu ayB0aGlzIFJlZCBIYXQgYmxvZyBpcyBwcm9kdWN0aW9uIHF1YWxpdHkuwqAgSW4gbXkKb3Bpbmlv biwgdGhlIGJsb2cgaG93LXRvIGlzIG9rYXkgKG5vdCByZWFsbHksIElNSE8pIGZvciBhIGxhYiwg YnV0IG5vdCBmb3IKcHJvZHVjdGlvbi4KClNpbmNlIGZlbmNpbmcgaXMgaW1wb3J0YW50IGluIG9W aXJ0LCBoYXZpbmcgZ2x1c3RlciBvbiB0aGUgaG9zdHMgaXMgYSBuby1ubwpzaW5jZSBhIG5vbi1y ZXNwb25zaXZlIGhvc3QgY291bGQgYmUgZmVuY2VkIGF0IGFueSB0aW1lIC0tIGFuZCB0aGUgZW5n aW5lCmNvdWxkIGZlbmNlIG11bHRpcGxlIGhvc3RzIChhbmQgYm9yayBhIGxvY2FsbHkgaG9zdGVk IGdsdXN0ZXIgZmlsZSBzeXN0ZW0gYW5kCnRoZW4gc2NyZXcgdXAgdGhlIGVudGlyZSBnbHVzdGVy IGNsdXN0ZXIpLgoKLS1TY290dFcK ----_com.android.email_88339792828010 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT4KICAgIAo8ZGl2Pjxicj48L2Rpdj48 ZGl2PldoYXQgaGUgc2FpZDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYg aWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjoj NTc1NzU3Ij5IYXBweSBDb25uZWN0aW5nLiBTZW50IGZyb20gbXkgU3ByaW50IFNhbXN1bmcgR2Fs YXh5IFPCriA1PC9kaXY+PC9kaXY+PGJyPjxicj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0t LS0tLS0tPGJyPkZyb206IFNjb3R0IFdvcnRoaW5ndG9uICZsdDtzY290dC5jLndvcnRoaW5ndG9u QGdtYWlsLmNvbSZndDsgPGJyPkRhdGU6IDAyLzE4LzIwMTUgIDI6MDMgUE0gIChHTVQtMDc6MDAp IDxicj5UbzogRG9ubnkgRCAmbHQ7ZG9ubnlAY2xvdWRzcGluLm1lJmd0OyA8YnI+U3ViamVjdDog UmU6IFtvdmlydC11c2Vyc10gb3ZpcnQgYW5kIGdsdXN0ZXJmcyBzZXR1cCA8YnI+PGJyPiZndDsg SSBkaWQgbm90IGhhdmUgYSBnb29kIGV4cGVyaWVuY2UgcHV0dGluZyBib3RoIGdsdXN0ZXIgYW5k IHZpcnQgb24gdGhlIHNhbWU8YnI+Jmd0OyBub2RlLiBJIHdhcyBkb2luZyBob3N0ZWQgZW5naW5l IHdpdGggcmVwbGljYXRlIGFjcm9zcyB0d28gbm9kZXMsIGFuZCBvbmUgZGF5PGJyPiZndDsgaXQg d2VudCBpbnRvIHNwbGl0IGJyYWluIGhlbGwuLi4gaSB3YXMgbmV2ZXIgYWJsZSB0byB0cmFjayBk b3duIHdoeS4gSG93ZXZlcjxicj4mZ3Q7IGkgZG8gaGF2ZSBhIGdsdXN0ZXIgd2l0aCBkaXN0cmli dXRlIGFuZCByZXBsaWNhIHNldHVwIG9uIGl0cyBvd24gd2l0aCBhPGJyPiZndDsgY291cGxlIG5v ZGVzLCBhbmQgaXQgaGFzIGdpdmVuIG1lIHplcm8gcHJvYmxlbXMgaW4gdGhlIGxhc3QgNjAgZGF5 cy4gSXQ8YnI+Jmd0OyBzZWVtcyB0byBtZSB0aGF0IGdsdXN0ZXIgYW5kIHZpcnQgbmVlZCB0byBz dGF5IHNlcGVyYXRlIGZvciBub3cuIEJvdGggYXJlPGJyPiZndDsgZ3JlYXQgcHJvZHVjdHMgYW5k IGJvdGggd29yayBhcyBkZXNjcmliZWQsIGp1c3Qgbm90IG9uIHRoZSBzYW1lIG5vZGUgYXQgdGhl PGJyPiZndDsgc2FtZSB0aW1lLjxicj4mZ3Q7PGJyPjxicj5UaGUgaXNzdWUsIGFzIEkgcGVyY2Vp dmUgaXQsIGlzIG5ld2JpZXMgZmluZCBKYXNvbiBCcm9vaydzIGJsb2c6PGJyPiZuYnNwOyBodHRw Oi8vY29tbXVuaXR5LnJlZGhhdC5jb20vYmxvZy8yMDE0LzExL3VwLWFuZC1ydW5uaW5nLXdpdGgt b3ZpcnQtMy01LXBhcnQtdHdvLzxicj48YnI+QW5kIHRoZW4gbmV3YmllcyB0aGluayB0aGlzIFJl ZCBIYXQgYmxvZyBpcyBwcm9kdWN0aW9uIHF1YWxpdHkuJm5ic3A7IEluIG15PGJyPm9waW5pb24s IHRoZSBibG9nIGhvdy10byBpcyBva2F5IChub3QgcmVhbGx5LCBJTUhPKSBmb3IgYSBsYWIsIGJ1 dCBub3QgZm9yPGJyPnByb2R1Y3Rpb24uPGJyPjxicj5TaW5jZSBmZW5jaW5nIGlzIGltcG9ydGFu dCBpbiBvVmlydCwgaGF2aW5nIGdsdXN0ZXIgb24gdGhlIGhvc3RzIGlzIGEgbm8tbm88YnI+c2lu Y2UgYSBub24tcmVzcG9uc2l2ZSBob3N0IGNvdWxkIGJlIGZlbmNlZCBhdCBhbnkgdGltZSAtLSBh bmQgdGhlIGVuZ2luZTxicj5jb3VsZCBmZW5jZSBtdWx0aXBsZSBob3N0cyAoYW5kIGJvcmsgYSBs b2NhbGx5IGhvc3RlZCBnbHVzdGVyIGZpbGUgc3lzdGVtIGFuZDxicj50aGVuIHNjcmV3IHVwIHRo ZSBlbnRpcmUgZ2x1c3RlciBjbHVzdGVyKS48YnI+PGJyPi0tU2NvdHRXPGJyPjwvYm9keT48L2h0 bWw+ ----_com.android.email_88339792828010--

3 2

Exporting a VM's disks
by John Gardeniers 22 Feb '15

22 Feb '15

Hi All, Having recently had a need to manually export a VM from our RHEV environment I searched for a way to identify the VM's disks with the files on the storage system. The search led me to http://rhevdup.blogspot.com.au/2013/05/manual-export-of-vm-from-rhev.html but unfortunately, the script in that post only lists the first drive for a VM, making it less than useful for exporting VMs with multiple drives. Inspired by that post I wrote my own version in Perl (I detest Python). The script works on our RHEV 3.4 with a Gluster storage back end. I would greatly appreciate it if some of you could test it on other RHEV/Ovirt versions and on different storage systems. Thanks for any feedback. regards, John #! /usr/bin/env perl # Run this script on the RHEV/Ovirt engine (management) machine # # Find the files on the storage which belong to a VM's disk(s) # Input parameter: A single VM name (case sensitive) use DBI; my $vm = shift or die "No VM specified\n"; my $conf = '/etc/ovirt-engine/engine.conf.d/10-setup-database.conf'; my $host = 'localhost'; my $db; my $user; my $pass; my $port = 5432; open my $fi, '<', $conf or die "Can't read $conf\n"; while(<$fi>) { my $line = $_; $host = $1 if($line =~ /ENGINE_DB_HOST="(.*)"/); $db = $1 if($line =~ /ENGINE_DB_DATABASE="(.*)"/); $user = $1 if($line =~ /ENGINE_DB_USER="(.*)"/); $pass = $1 if($line =~ /ENGINE_DB_PASSWORD="(.*)"/); $port = $1 if($line =~ /ENGINE_DB_PORT="(.*)"/); } die "Unable to get all database details\n" if(!$db || !$user || !$pass); my $dbh = DBI->connect("dbi:Pg:dbname=$db;host=$host;port=$port", $user, $pass, {AutoCommit=>1,RaiseError=>1,PrintError=>0}); die "Error connecting to the database\n" if(!$dbh); # Get the device ID my $sql = "select device_id from vms_for_disk_view where array_vm_names = '{$vm}'"; my @row = $dbh->selectrow_array($sql); my $vm_id = $row[0]; if($vm_id) { print "\nVM ID: $vm_id\n"; # Get the drive ID(s) $sql = "select image_guid, to_char(size/1024/1024/1024.0, '999G999D99'), to_char(actual_size/1024/1024/1024.0, '999G999D99'), storage_name from images_storage_domain_view where vm_names = '$vm' and entity_type = 'VM'"; my $sth = $dbh->prepare($sql) || die "Error preparing the SQL string \"$sql\"\n$dbh::errstr"; print "\nError executing $sql\n$DBI::errstr\n\n" unless $sth->execute(); print "Disk ID(s): "; my $cnt = 0; while (@row = $sth->fetchrow_array) { print " " if($cnt++); print "$row[0], $row[1]GB allocated, $row[2]GB actual, on $row[3]\n"; } $sth->finish; print "\n"; } else { print "\nVM \"$vm\" not found. Be aware that the name is case sensitive.\n\n"; } $dbh->disconnect;

2 2

It is possible - Ovirt ? different CHAP authentication credentials
by Eduardo Terzella 22 Feb '15

22 Feb '15

Hello, We have a requirement where when we add storage to our Ovirt cluster, each node in the cluster must use a different iSCSI CHAP username. This unfortunately does not work correctly when adding storage from the web interface for Ovirt as it only allows you to specify a shared username/password combination. We need to be able to use different CHAP authentication credentials when we add storage to Ovirt

2 1

reinstall hosted engine vm (centos 6.6 -> 7)
by Pete 22 Feb '15

22 Feb '15

Hi, I currently have Centos 6.6 engine vm running, the server it self is running centos 7 with oVirt. How I could get rid of the 6.6 Centos engine vm and update to Centos 7 engine vm ? I was unable to find any docs on how to do it. Thanks in advance. Br, Pete

2 2

self hosted engine add second host - maintenance mode needed?
by Mike 22 Feb '15

22 Feb '15

Hi Got a running self hosted install with VMs running on the host, now adding a second host to get ha for the engine & VMs. Do I need to put the engine into maintenance mode before running hosted-engine --deploy on new host node? Thanks Mike

3 2

Problem with Neutron + Ovirt 3.5.1 [Centos 7]
by Eduardo Terzella 22 Feb '15

22 Feb '15

Good night, I'm trying oVirt 3.5 + neutron appliance in BareMetal servers, but I am facing some problems. structure: 2 servers with: oVirt 3.5.1 hundreds 7 4 network adapter int = 0 + int2 bond0 => public network => ovirtmgmt int = 1 + int3 bond1 => private network => neutron Virtual Appliance Neutron: http://www.ovirt.org/Features/NeutronVirtualAppliance NOTE: All steps were followed, and checked several times. Openvswitch configuration: *[root@ovirt01 network-scripts]# ovs-vsctl show* 62feffa7-3f3a-48f7-9299-0830ebcd8fd8 Bridge br-neutron Port phy-br-neutron Interface phy-br-neutron Port br-neutron Interface br-neutron type: internal Port neutron Interface neutron Bridge br-int fail_mode: secure Port int-br-neutron Interface int-br-neutron Port "qvof206e358-8f" tag: 1 Interface "qvof206e358-8f" Port br-int Interface br-int type: internal ovs_version: "2.1.3" *[root@ovirt02 /]# ovs-vsctl show* 9d40dda2-62ea-4538-9f82-d5babff0837b Bridge br-int fail_mode: secure Port "qvo723ce1c1-56" tag: 1 Interface "qvo723ce1c1-56" Port int-br-neutron Interface int-br-neutron Port br-int Interface br-int type: internal Bridge br-neutron Port br-neutron Interface br-neutron type: internal Port neutron Interface neutron Port phy-br-neutron Interface phy-br-neutron ovs_version: "2.1.3" *[root@ovirt01 /]# ovs-dpctl show* system@ovs-system: lookups: hit:1946392 missed:6566 lost:1 flows: 4 masks: hit:2490944 total:2 hit/pkt:1.28 port 0: ovs-system (internal) port 1: br-neutron (internal) port 2: br-int (internal) port 3: neutron port 4: int-br-neutron port 5: phy-br-neutron port 7: qvof206e358-8f *[root@ovirt02 /]# ovs-dpctl show* system@ovs-system: lookups: hit:2041047 missed:6445 lost:0 flows: 4 masks: hit:2234366 total:2 hit/pkt:1.09 port 0: ovs-system (internal) port 1: br-neutron (internal) port 2: br-int (internal) port 3: int-br-neutron port 4: phy-br-neutron port 5: neutron port 6: qvo723ce1c1-56 *Testing:* Connectivity between my virtual machines only work when both are running on the same node, when virtual machines are running on different hosts can not make a machine ping the other. *Tcpdump:* *[root@ovirt01 network-scripts]# tcpdump -e -i neutron -p -n not port nfs* tcpdump: WARNING: neutron: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on neutron, link-type EN10MB (Ethernet), capture size 65535 bytes 16:57:25.469628 00:1a:4a:2c:3f:02 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.4 tell 192.168.100.2, length 28 16:57:26.469565 00:1a:4a:2c:3f:02 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.4 tell 192.168.100.2, length 28 16:57:28.469910 00:1a:4a:2c:3f:02 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.4 tell 192.168.100.2, length 28 16:57:29.469479 00:1a:4a:2c:3f:02 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.4 tell 192.168.100.2, length 28 16:57:30.469472 00:1a:4a:2c:3f:02 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.4 tell 192.168.100.2, length 28 16:57:32.469715 00:1a:4a:2c:3f:02 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.4 tell 192.168.100.2, length 28 16:57:33.469374 00:1a:4a:2c:3f:02 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.4 tell 192.168.100.2, length 28 16:57:34.469367 00:1a:4a:2c:3f:02 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.4 tell 192.168.100.2, length 28 16:57:36.469617 00:1a:4a:2c:3f:02 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.4 tell 192.168.100.2, length 28 16:57:37.469251 00:1a:4a:2c:3f:02 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.4 tell 192.168.100.2, length 28 16:57:38.469258 00:1a:4a:2c:3f:02 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.4 tell 192.168.100.2, length 28 *[root@ovirt02 /]# tcpdump -e -i neutron -p -n not port nfs* tcpdump: WARNING: neutron: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on neutron, link-type EN10MB (Ethernet), capture size 65535 bytes 16:57:23.188238 00:1a:4a:2c:3f:03 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.2 tell 192.168.100.4, length 28 16:57:24.187726 00:1a:4a:2c:3f:03 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.2 tell 192.168.100.4, length 28 16:57:25.187781 00:1a:4a:2c:3f:03 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.2 tell 192.168.100.4, length 28 16:57:27.189224 00:1a:4a:2c:3f:03 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.2 tell 192.168.100.4, length 28 16:57:28.188720 00:1a:4a:2c:3f:03 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.2 tell 192.168.100.4, length 28 16:57:29.188715 00:1a:4a:2c:3f:03 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.2 tell 192.168.100.4, length 28 16:57:31.190152 00:1a:4a:2c:3f:03 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.2 tell 192.168.100.4, length 28 16:57:32.189646 00:1a:4a:2c:3f:03 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.2 tell 192.168.100.4, length 28 16:57:33.189622 00:1a:4a:2c:3f:03 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.2 tell 192.168.100.4, length 28 16:57:35.190959 00:1a:4a:2c:3f:03 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.2 tell 192.168.100.4, length 28 16:57:36.190585 00:1a:4a:2c:3f:03 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.2 tell 192.168.100.4, length 28 16:57:37.190544 00:1a:4a:2c:3f:03 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.2 tell 192.168.100.4, length 28 16:57:39.191885 00:1a:4a:2c:3f:03 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.2 tell 192.168.100.4, length 28 16:57:40.191492 00:1a:4a:2c:3f:03 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.2 tell 192.168.100.4, length 28 16:57:41.191511 00:1a:4a:2c:3f:03 > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 1024, p 0, ethertype ARP, Request who-has 192.168.100.2 tell 192.168.100.4, length 28

2 3

Still blocked...
by Pascal Jakobi 21 Feb '15

21 Feb '15

This is a multi-part message in MIME format. --------------070200090500010505040401 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi there Still stuck when creating an NFS storage domain with an AIO installation. Below is the engine trace. Can someone say what means that 351 error ? Many thanks in advance P PS. I could observe that the NFS mount is done. Ovirt fails afterward. 2015-02-19 10:53:23,842 INFO [org.ovirt.engine.core.bll.storage.AddStorageServerConnectionCommand] (ajp--127.0.0.1-8702-1) [2c3317b1] Lock Acquired to object EngineLock [exclusiveLocks= key: spirou.jakobi.fr:/var/lib/nfs/data value: STORAGE_CONNECTION , sharedLocks= ] 2015-02-19 10:53:23,875 INFO [org.ovirt.engine.core.bll.storage.AddStorageServerConnectionCommand] (ajp--127.0.0.1-8702-1) [2c3317b1] Running command: AddStorageServerConnectionCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_STORAGE_DOMAIN with role type ADMIN 2015-02-19 10:53:23,877 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (ajp--127.0.0.1-8702-1) [2c3317b1] START, ConnectStorageServerVDSCommand(HostName = lab1, HostId = c291c28b-3c3e-49f1-94c5-be0078e7b014, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = NFS, connectionList = [{ id: null, connection: spirou.jakobi.fr:/var/lib/nfs/data, iqn: null, vfsType: null, mountOptions: null, nfsVersion: null, nfsRetrans: null, nfsTimeo: null };]), log id: 7e2f307b 2015-02-19 10:53:29,131 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (ajp--127.0.0.1-8702-1) [2c3317b1] FINISH, ConnectStorageServerVDSCommand, return: {00000000-0000-0000-0000-000000000000=0}, log id: 7e2f307b 2015-02-19 10:53:29,169 INFO [org.ovirt.engine.core.bll.storage.AddStorageServerConnectionCommand] (ajp--127.0.0.1-8702-1) [2c3317b1] Lock freed to object EngineLock [exclusiveLocks= key: spirou.jakobi.fr:/var/lib/nfs/data value: STORAGE_CONNECTION , sharedLocks= ] 2015-02-19 10:53:34,250 INFO [org.ovirt.engine.core.bll.storage.AddNFSStorageDomainCommand] (ajp--127.0.0.1-8702-7) [47bf1185] Running command: AddNFSStorageDomainCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_STORAGE_DOMAIN with role type ADMIN 2015-02-19 10:53:34,265 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (ajp--127.0.0.1-8702-7) [47bf1185] START, ConnectStorageServerVDSCommand(HostName = lab1, HostId = c291c28b-3c3e-49f1-94c5-be0078e7b014, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = NFS, connectionList = [{ id: 7bc8d667-ae81-4462-b825-daebfba2b0bd, connection: spirou.jakobi.fr:/var/lib/nfs/data, iqn: null, vfsType: null, mountOptions: null, nfsVersion: null, nfsRetrans: null, nfsTimeo: null };]), log id: 1d8d975 2015-02-19 10:53:34,273 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (ajp--127.0.0.1-8702-7) [47bf1185] FINISH, ConnectStorageServerVDSCommand, return: {7bc8d667-ae81-4462-b825-daebfba2b0bd=0}, log id: 1d8d975 2015-02-19 10:53:34,274 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--127.0.0.1-8702-7) [47bf1185] START, CreateStorageDomainVDSCommand(HostName = lab1, HostId = c291c28b-3c3e-49f1-94c5-be0078e7b014, storageDomain=StorageDomainStatic[Store, 4bb1e26a-a59b-41f2-b0c5-99a0a55837df], args=spirou.jakobi.fr:/var/lib/nfs/data), log id: 254d3442 2015-02-19 10:53:34,446 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--127.0.0.1-8702-7) [47bf1185] Failed in CreateStorageDomainVDS method 2015-02-19 10:53:34,447 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--127.0.0.1-8702-7) [47bf1185] Command org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand return value StatusOnlyReturnForXmlRpc [mStatus=StatusForXmlRpc [mCode=351, mMessage=Error creating a storage domain: (u'storageType=1, sdUUID=4bb1e26a-a59b-41f2-b0c5-99a0a55837df, domainName=Store, domClass=1, typeSpecificArg=spirou.jakobi.fr:/var/lib/nfs/data domVersion=3',)]] 2015-02-19 10:53:34,447 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--127.0.0.1-8702-7) [47bf1185] HostName = lab1 2015-02-19 10:53:34,447 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--127.0.0.1-8702-7) [47bf1185] Command CreateStorageDomainVDSCommand(HostName = lab1, HostId = c291c28b-3c3e-49f1-94c5-be0078e7b014, storageDomain=StorageDomainStatic[Store, 4bb1e26a-a59b-41f2-b0c5-99a0a55837df], args=spirou.jakobi.fr:/var/lib/nfs/data) execution failed. Exception: VDSErrorException: VDSGenericException: VDSErrorException: Failed to CreateStorageDomainVDS, error = Error creating a storage domain: (u'storageType=1, sdUUID=4bb1e26a-a59b-41f2-b0c5-99a0a55837df, domainName=Store, domClass=1, typeSpecificArg=spirou.jakobi.fr:/var/lib/nfs/data domVersion=3',), code = 351 2015-02-19 10:53:34,448 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--127.0.0.1-8702-7) [47bf1185] FINISH, CreateStorageDomainVDSCommand, log id: 254d3442 *2015-02-19 10:53:34,448 ERROR [org.ovirt.engine.core.bll.storage.AddNFSStorageDomainCommand] (ajp--127.0.0.1-8702-7) [47bf1185] Command org.ovirt.engine.core.bll.storage.AddNFSStorageDomainCommand throw Vdc Bll exception. With error message VdcBLLException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to CreateStorageDomainVDS, error = Error creating a storage domain: (u'storageType=1, sdUUID=4bb1e26a-a59b-41f2-b0c5-99a0a55837df, domainName=Store, domClass=1, typeSpecificArg=spirou.jakobi.fr:/var/lib/nfs/data domVersion=3',), code = 351 (Failed with error StorageDomainCreationError and code 351)* 2015-02-19 10:53:34,449 INFO [org.ovirt.engine.core.bll.storage.AddNFSStorageDomainCommand] (ajp--127.0.0.1-8702-7) [47bf1185] Command [id=a20bdf09-e2d3-41aa-a0ab-fc2c10bdbed6]: Compensating NEW_ENTITY_ID of org.ovirt.engine.core.common.businessentities.StorageDomainDynamic; snapshot: 4bb1e26a-a59b-41f2-b0c5-99a0a55837df. 2015-02-19 10:53:34,450 INFO [org.ovirt.engine.core.bll.storage.AddNFSStorageDomainCommand] (ajp--127.0.0.1-8702-7) [47bf1185] Command [id=a20bdf09-e2d3-41aa-a0ab-fc2c10bdbed6]: Compensating NEW_ENTITY_ID of org.ovirt.engine.core.common.businessentities.StorageDomainStatic; snapshot: 4bb1e26a-a59b-41f2-b0c5-99a0a55837df. 2015-02-19 10:53:34,469 ERROR [org.ovirt.engine.core.bll.storage.AddNFSStorageDomainCommand] (ajp--127.0.0.1-8702-7) [47bf1185] Transaction rolled-back for command: org.ovirt.engine.core.bll.storage.AddNFSStorageDomainCommand. 2015-02-19 10:53:34,482 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp--127.0.0.1-8702-7) [47bf1185] Correlation ID: 47bf1185, Job ID: e5e52e53-8501-4dec-a5b0-20780183d522, Call Stack: null, Custom Event ID: -1, Message: Failed to add Storage Domain Store. (User: admin@internal) 2015-02-19 10:53:49,050 INFO [org.ovirt.engine.core.bll.storage.RemoveStorageServerConnectionCommand] (ajp--127.0.0.1-8702-8) [7588445e] Lock Acquired to object EngineLock [exclusiveLocks= key: 7bc8d667-ae81-4462-b825-daebfba2b0bd value: STORAGE_CONNECTION key: spirou.jakobi.fr:/var/lib/nfs/data value: STORAGE_CONNECTION , sharedLocks= ] 2015-02-19 10:53:49,088 INFO [org.ovirt.engine.core.bll.storage.RemoveStorageServerConnectionCommand] (ajp--127.0.0.1-8702-8) [7588445e] Running command: RemoveStorageServerConnectionCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_STORAGE_DOMAIN with role type ADMIN 2015-02-19 10:53:49,101 INFO [org.ovirt.engine.core.bll.storage.RemoveStorageServerConnectionCommand] (ajp--127.0.0.1-8702-8) [7588445e] Removing connection 7bc8d667-ae81-4462-b825-daebfba2b0bd from database 2015-02-19 10:53:49,102 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStorageServerVDSCommand] (ajp--127.0.0.1-8702-8) [7588445e] START, DisconnectStorageServerVDSCommand(HostName = lab1, HostId = c291c28b-3c3e-49f1-94c5-be0078e7b014, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = NFS, connectionList = [{ id: 7bc8d667-ae81-4462-b825-daebfba2b0bd, connection: spirou.jakobi.fr:/var/lib/nfs/data, iqn: null, vfsType: null, mountOptions: null, nfsVersion: null, nfsRetrans: null, nfsTimeo: null };]), log id: 5b7d6be4 2015-02-19 10:53:49,235 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStorageServerVDSCommand] (ajp--127.0.0.1-8702-8) [7588445e] FINISH, DisconnectStorageServerVDSCommand, return: {7bc8d667-ae81-4462-b825-daebfba2b0bd=0}, log id: 5b7d6be4 2015-02-19 10:53:49,248 INFO [org.ovirt.engine.core.bll.storage.RemoveStorageServerConnectionCommand] (ajp--127.0.0.1-8702-8) [7588445e] Lock freed to object EngineLock [exclusiveLocks= key: 7bc8d667-ae81-4462-b825-daebfba2b0bd value: STORAGE_CONNECTION key: spirou.jakobi.fr:/var/lib/nfs/data value: STORAGE_CONNECTION , sharedLocks= ] --------------070200090500010505040401 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi there Still stuck when creating an NFS storage domain with an AIO installation. Below is the engine trace. Can someone say what means that 351 error ? Many thanks in advance P PS. I could observe that the NFS mount is done. Ovirt fails afterward. 2015-02-19 10:53:23,842 INFO [org.ovirt.engine.core.bll.storage.AddStorageServerConnectionCommand] (ajp--127.0.0.1-8702-1) [2c3317b1] Lock Acquired to object EngineLock [exclusiveLocks= key: spirou.jakobi.fr:/var/lib/nfs/data value: STORAGE_CONNECTION , sharedLocks= ] 2015-02-19 10:53:23,875 INFO [org.ovirt.engine.core.bll.storage.AddStorageServerConnectionCommand] (ajp--127.0.0.1-8702-1) [2c3317b1] Running command: AddStorageServerConnectionCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_STORAGE_DOMAIN with role type ADMIN 2015-02-19 10:53:23,877 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (ajp--127.0.0.1-8702-1) [2c3317b1] START, ConnectStorageServerVDSCommand(HostName = lab1, HostId = c291c28b-3c3e-49f1-94c5-be0078e7b014, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = NFS, connectionList = [{ id: null, connection: spirou.jakobi.fr:/var/lib/nfs/data, iqn: null, vfsType: null, mountOptions: null, nfsVersion: null, nfsRetrans: null, nfsTimeo: null };]), log id: 7e2f307b 2015-02-19 10:53:29,131 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (ajp--127.0.0.1-8702-1) [2c3317b1] FINISH, ConnectStorageServerVDSCommand, return: {00000000-0000-0000-0000-000000000000=0}, log id: 7e2f307b 2015-02-19 10:53:29,169 INFO [org.ovirt.engine.core.bll.storage.AddStorageServerConnectionCommand] (ajp--127.0.0.1-8702-1) [2c3317b1] Lock freed to object EngineLock [exclusiveLocks= key: spirou.jakobi.fr:/var/lib/nfs/data value: STORAGE_CONNECTION , sharedLocks= ] 2015-02-19 10:53:34,250 INFO [org.ovirt.engine.core.bll.storage.AddNFSStorageDomainCommand] (ajp--127.0.0.1-8702-7) [47bf1185] Running command: AddNFSStorageDomainCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_STORAGE_DOMAIN with role type ADMIN 2015-02-19 10:53:34,265 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (ajp--127.0.0.1-8702-7) [47bf1185] START, ConnectStorageServerVDSCommand(HostName = lab1, HostId = c291c28b-3c3e-49f1-94c5-be0078e7b014, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = NFS, connectionList = [{ id: 7bc8d667-ae81-4462-b825-daebfba2b0bd, connection: spirou.jakobi.fr:/var/lib/nfs/data, iqn: null, vfsType: null, mountOptions: null, nfsVersion: null, nfsRetrans: null, nfsTimeo: null };]), log id: 1d8d975 2015-02-19 10:53:34,273 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.ConnectStorageServerVDSCommand] (ajp--127.0.0.1-8702-7) [47bf1185] FINISH, ConnectStorageServerVDSCommand, return: {7bc8d667-ae81-4462-b825-daebfba2b0bd=0}, log id: 1d8d975 2015-02-19 10:53:34,274 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--127.0.0.1-8702-7) [47bf1185] START, CreateStorageDomainVDSCommand(HostName = lab1, HostId = c291c28b-3c3e-49f1-94c5-be0078e7b014, storageDomain=StorageDomainStatic[Store, 4bb1e26a-a59b-41f2-b0c5-99a0a55837df], args=spirou.jakobi.fr:/var/lib/nfs/data), log id: 254d3442 2015-02-19 10:53:34,446 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--127.0.0.1-8702-7) [47bf1185] Failed in CreateStorageDomainVDS method 2015-02-19 10:53:34,447 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--127.0.0.1-8702-7) [47bf1185] Command org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand return value StatusOnlyReturnForXmlRpc [mStatus=StatusForXmlRpc [mCode=351, mMessage=Error creating a storage domain: (u'storageType=1, sdUUID=4bb1e26a-a59b-41f2-b0c5-99a0a55837df, domainName=Store, domClass=1, typeSpecificArg=spirou.jakobi.fr:/var/lib/nfs/data domVersion=3',)]] 2015-02-19 10:53:34,447 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--127.0.0.1-8702-7) [47bf1185] HostName = lab1 2015-02-19 10:53:34,447 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--127.0.0.1-8702-7) [47bf1185] Command CreateStorageDomainVDSCommand(HostName = lab1, HostId = c291c28b-3c3e-49f1-94c5-be0078e7b014, storageDomain=StorageDomainStatic[Store, 4bb1e26a-a59b-41f2-b0c5-99a0a55837df], args=spirou.jakobi.fr:/var/lib/nfs/data) execution failed. Exception: VDSErrorException: VDSGenericException: VDSErrorException: Failed to CreateStorageDomainVDS, error = Error creating a storage domain: (u'storageType=1, sdUUID=4bb1e26a-a59b-41f2-b0c5-99a0a55837df, domainName=Store, domClass=1, typeSpecificArg=spirou.jakobi.fr:/var/lib/nfs/data domVersion=3',), code = 351 2015-02-19 10:53:34,448 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--127.0.0.1-8702-7) [47bf1185] FINISH, CreateStorageDomainVDSCommand, log id: 254d3442 2015-02-19 10:53:34,448 ERROR [org.ovirt.engine.core.bll.storage.AddNFSStorageDomainCommand] (ajp--127.0.0.1-8702-7) [47bf1185] Command org.ovirt.engine.core.bll.storage.AddNFSStorageDomainCommand throw Vdc Bll exception. With error message VdcBLLException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to CreateStorageDomainVDS, error = Error creating a storage domain: (u'storageType=1, sdUUID=4bb1e26a-a59b-41f2-b0c5-99a0a55837df, domainName=Store, domClass=1, typeSpecificArg=spirou.jakobi.fr:/var/lib/nfs/data domVersion=3',), code = 351 (Failed with error StorageDomainCreationError and code 351) 2015-02-19 10:53:34,449 INFO [org.ovirt.engine.core.bll.storage.AddNFSStorageDomainCommand] (ajp--127.0.0.1-8702-7) [47bf1185] Command [id=a20bdf09-e2d3-41aa-a0ab-fc2c10bdbed6]: Compensating NEW_ENTITY_ID of org.ovirt.engine.core.common.businessentities.StorageDomainDynamic; snapshot: 4bb1e26a-a59b-41f2-b0c5-99a0a55837df. 2015-02-19 10:53:34,450 INFO [org.ovirt.engine.core.bll.storage.AddNFSStorageDomainCommand] (ajp--127.0.0.1-8702-7) [47bf1185] Command [id=a20bdf09-e2d3-41aa-a0ab-fc2c10bdbed6]: Compensating NEW_ENTITY_ID of org.ovirt.engine.core.common.businessentities.StorageDomainStatic; snapshot: 4bb1e26a-a59b-41f2-b0c5-99a0a55837df. 2015-02-19 10:53:34,469 ERROR [org.ovirt.engine.core.bll.storage.AddNFSStorageDomainCommand] (ajp--127.0.0.1-8702-7) [47bf1185] Transaction rolled-back for command: org.ovirt.engine.core.bll.storage.AddNFSStorageDomainCommand. 2015-02-19 10:53:34,482 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp--127.0.0.1-8702-7) [47bf1185] Correlation ID: 47bf1185, Job ID: e5e52e53-8501-4dec-a5b0-20780183d522, Call Stack: null, Custom Event ID: -1, Message: Failed to add Storage Domain Store. (User: admin@internal) 2015-02-19 10:53:49,050 INFO [org.ovirt.engine.core.bll.storage.RemoveStorageServerConnectionCommand] (ajp--127.0.0.1-8702-8) [7588445e] Lock Acquired to object EngineLock [exclusiveLocks= key: 7bc8d667-ae81-4462-b825-daebfba2b0bd value: STORAGE_CONNECTION key: spirou.jakobi.fr:/var/lib/nfs/data value: STORAGE_CONNECTION , sharedLocks= ] 2015-02-19 10:53:49,088 INFO [org.ovirt.engine.core.bll.storage.RemoveStorageServerConnectionCommand] (ajp--127.0.0.1-8702-8) [7588445e] Running command: RemoveStorageServerConnectionCommand internal: false. Entities affected : ID: aaa00000-0000-0000-0000-123456789aaa Type: SystemAction group CREATE_STORAGE_DOMAIN with role type ADMIN 2015-02-19 10:53:49,101 INFO [org.ovirt.engine.core.bll.storage.RemoveStorageServerConnectionCommand] (ajp--127.0.0.1-8702-8) [7588445e] Removing connection 7bc8d667-ae81-4462-b825-daebfba2b0bd from database 2015-02-19 10:53:49,102 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStorageServerVDSCommand] (ajp--127.0.0.1-8702-8) [7588445e] START, DisconnectStorageServerVDSCommand(HostName = lab1, HostId = c291c28b-3c3e-49f1-94c5-be0078e7b014, storagePoolId = 00000000-0000-0000-0000-000000000000, storageType = NFS, connectionList = [{ id: 7bc8d667-ae81-4462-b825-daebfba2b0bd, connection: spirou.jakobi.fr:/var/lib/nfs/data, iqn: null, vfsType: null, mountOptions: null, nfsVersion: null, nfsRetrans: null, nfsTimeo: null };]), log id: 5b7d6be4 2015-02-19 10:53:49,235 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DisconnectStorageServerVDSCommand] (ajp--127.0.0.1-8702-8) [7588445e] FINISH, DisconnectStorageServerVDSCommand, return: {7bc8d667-ae81-4462-b825-daebfba2b0bd=0}, log id: 5b7d6be4 2015-02-19 10:53:49,248 INFO [org.ovirt.engine.core.bll.storage.RemoveStorageServerConnectionCommand] (ajp--127.0.0.1-8702-8) [7588445e] Lock freed to object EngineLock [exclusiveLocks= key: 7bc8d667-ae81-4462-b825-daebfba2b0bd value: STORAGE_CONNECTION key: spirou.jakobi.fr:/var/lib/nfs/data value: STORAGE_CONNECTION , sharedLocks= ] </body> </html> --------------070200090500010505040401--

2 1

Slow storage migration towards nfs
by Tobias Fiebig 21 Feb '15

21 Feb '15

Heho, I currently move some vms from fcal-store to nfs, so i can restructure the fcal storage. However, i noticed, that dd is running with oflag=direct. I/o is currently very slow (~160mbit) on the nfs-servers network. Starting dd without oflag=direct leads to link-speed transmission (~1gbit/s). So... is this intended beheaviour? With best Regards, Tobias

1 1

Re: [ovirt-users] Unable to run noVNC console un recent browsers
by Donny Davis 20 Feb '15

20 Feb '15

No, I made my life easy and used nginx to proxy for the websocket. I was then able to use my commercial ssl cert to avoid all of these issues. Using a proxy for a proxy has been working out quite well for cloudspin, because I don't have to mess with anything internal to the engine and noVNC works without issue. DonnyD -----Original Message----- From: Simone Tiraboschi [mailto:stirabos@redhat.com] Sent: Friday, February 20, 2015 7:03 AM To: Donny Davis Subject: Re: [ovirt-users] Unable to run noVNC console un recent browsers ----- Original Message ----- > From: "Donny Davis" <donny(a)cloudspin.me> > To: "Simone Tiraboschi" <stirabos(a)redhat.com> > Sent: Friday, February 20, 2015 2:23:56 PM > Subject: RE: [ovirt-users] Unable to run noVNC console un recent > browsers > > Is your websocket proxy on the same machine as your engine. I also get > the CA error when the time it off. The proxy throws the error to > /var/log/messages Hi Donny, I'm using the proxy on the same machine where the engine runs. No error till now no my side. I also trusted oVirt internal CA to sign other certs in my browser. Did you? You can find it at https://{engine}/ca.crt You should download it and add to the list of trusted certification authorities in your browser. > -----Original Message----- > From: users-bounces(a)ovirt.org [mailto:users-bounces@ovirt.org] On > Behalf Of Simone Tiraboschi > Sent: Friday, February 20, 2015 5:57 AM > To: Stefano Danzi > Cc: users(a)ovirt.org > Subject: Re: [ovirt-users] Unable to run noVNC console un recent > browsers > > > > ----- Original Message ----- > > From: "Stefano Danzi" <s.danzi(a)hawai.it> > > To: "Darrell Budic" <budic(a)onholyground.com> > > Cc: users(a)ovirt.org > > Sent: Friday, February 20, 2015 9:07:51 AM > > Subject: Re: [ovirt-users] Unable to run noVNC console un recent > > browsers > > > > Hello! > > Already done but this didn't help. > > > > I downloaded a portable version of Firefox 17 and noVNC work as expected. > > > > Il 20/02/2015 5.18, Darrell Budic ha scritto: > > > > > > > > Try reimporting the ca.cert for noVNC by connecting directly to the > > webproxy address at port 6100. Do this by trying to connect to a > > console and then, once the 1006 error shows up, just strip off > > everything after :6100/ . I've found that somewhere in or after 3.5, > > restarting the webproxy causes it to generate its own new ca.cert > > even > through it shouldn't. > > > > -Darrell > > > > > > > > On Feb 19, 2015, at 4:09 PM, Stefano Danzi <s.danzi(a)hawai.it> wrote: > > > > Hello, > > > > I can't make work noVNC console on recent browsers (Chrome 40, > > Firefox > > 35 and IE 11). > > > > The error that I have is already explained here: > > https://forge.univention.org/bugzilla/show_bug.cgi?id=33587 I tried > > to change websocket like suggested ( > > http://errata.univention.de/ucs/3.2/31.html ) but this not helped. > > noVNC 0.5.1 should be soon released in EPEL6/EPEL7 as for [1]. > noVNC 0.5.1 should also improve compatibility with recent browsers. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1193454#c3 > > > > Someone know a workaround? > > _______________________________________________ > > Users mailing list Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > > > > > _______________________________________________ > > Users mailing list > > Users(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > >

4 6

Problem: My VM's keep logging off
by Pedro ML Sousa 20 Feb '15

20 Feb '15

This is a multi-part message in MIME format. --------------050100040509080004020406 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit My VM's keep logging off I have a HP server with 64GB of ram and 2 TB of disk space, the cpu is a Intel E5-2420v2 and 13 thin clients from igel (https://www.igel.com/products/thin-client-zero-client-hardware/iz2ud2-serie…) i've purchase the clients and a service from a company, they installed the thins clients and the system but they are not finding a solution to my problem. The company installed centos 6.6 (final) (kernel linux 23.32-504.3.3.el6.x86_64) and ovirt 3.5.1 for virtualization (o.o.master.20141206225404) I have 12 VM's with centos (when i edit then is shows red hat enterprise linux 6.x x64) and gnome desktop 2.28.2 and 1 VM with windows xp prof. The problem only occurs on the VM's with linux. On linux display type is: Spice I use virtual machine viewer 1.0256 *Problem: when working the vm seems to log off and i have to put the username and password again, all the work that was open is losed.* 1 VM seems to log off more or less at the same hour each day 1h40 pm and 6h15 pm. This VM now as a newer thin client version UD3 instead of UD2 (https://www.igel.com/products/thin-client-zero-client-hardware/iz3ud3-serie…) and now the problem only occur 1 time each day (at 12h30/12h45pm). All of the VM's including the one with XP Pro suffers from slowness, and on libreoffice the mouse scrooll seems nuts scrolling up and down by itself, now the exception is the VM with the new thin client. On the same network switch i have VM's that logs off and others that remain on. So the problem doesn't seem to be with the network. The different VM's logs off from 1 to 7 times a day. Mostly 4 to 5 times a day. When the VM logs off the caps lock become to work on the opposite condition off with caps light on and on with the caps light off. Beside this i have problems with the canon's printes i have, they stop printing quite often. I have access to the logs if anyone can help me i can upload the logs you like. Hope anyone can help me, i'm glad to provide more information if you need. Thanks in advance. PS pedromls(a)pmls.pt --------------050100040509080004020406 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> My VM's keep logging off <div class="linestyle2 colourline"> I have a HP server with 64GB of ram and 2 TB of disk space, the cpu is a Intel E5-2420v2 and 13 thin clients from igel (<a class="moz-txt-link-freetext" href="https://www.igel.com/products/thin-client-zero-client-hardware/iz2ud2-serie…">https://www.igel.com/products/thin-client-zero-client-hardware/iz2ud2-serie…</a>) i've purchase the clients and a service from a company, they installed the thins clients and the system but they are not finding a solution to my problem. </div> <div class="linestyle1 colourline">The company installed centos 6.6 (final) (kernel linux 23.32-504.3.3.el6.x86_64) and ovirt 3.5.1 for virtualization (o.o.master.20141206225404) </div> <div class="linestyle1 colourline">I have 12 VM's with centos (when i edit then is shows red hat enterprise linux 6.x x64) and gnome desktop 2.28.2 and 1 VM with windows xp prof. The problem only occurs on the VM's with linux. On linux display type is: Spice I use virtual machine viewer 1.0256 </div> Problem: when working the vm seems to log off and i have to put the username and password again, all the work that was open is losed. 1 VM seems to log off more or less at the same hour each day 1h40 pm and 6h15 pm. This VM now as a newer thin client version UD3 instead of UD2 (<a class="moz-txt-link-freetext" href="https://www.igel.com/products/thin-client-zero-client-hardware/iz3ud3-serie…">https://www.igel.com/products/thin-client-zero-client-hardware/iz3ud3-serie…</a>) and now the problem only occur 1 time each day (at 12h30/12h45pm). All of the VM's including the one with XP Pro suffers from slowness, and on libreoffice the mouse scrooll seems nuts scrolling up and down by itself, now the exception is the VM with the new thin client. On the same network switch i have VM's that logs off and others that remain on. So the problem doesn't seem to be with the network. The different VM's logs off from 1 to 7 times a day. Mostly 4 to 5 times a day. When the VM logs off the caps lock become to work on the opposite condition off with caps light on and on with the caps light off. Beside this i have problems with the canon's printes i have, they stop printing quite often. I have access to the logs if anyone can help me i can upload the logs you like. Hope anyone can help me, i'm glad to provide more information if you need. Thanks in advance. PS <a class="moz-txt-link-abbreviated" href="mailto:pedromls@pmls.pt">pedromls(a)pmls.pt</a> </body> </html> --------------050100040509080004020406--

2 2

Unable to run noVNC console un recent browsers
by Stefano Danzi 20 Feb '15

20 Feb '15

Hello, I can't make work noVNC console on recent browsers (Chrome 40, Firefox 35 and IE 11). The error that I have is already explained here: https://forge.univention.org/bugzilla/show_bug.cgi?id=33587 I tried to change websocket like suggested (http://errata.univention.de/ucs/3.2/31.html) but this not helped. Someone know a workaround?

5 6

Ovirt spice cannot log
by tharaka 20 Feb '15

20 Feb '15

This is a multi-part message in MIME format. --------------080200000709010709000606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, My ovirt version *oVirt Engine Version: 3.5.0.1-1.el6 , *i cannot connect to ovirt graphical server via spice , i have already installed firebox plug-in, but i'm using *Version 3.1.0-3.26ovirt *server without any spice issue, Please guide me to resolve this problem. Thank You, Malinda Tharaka. --------------080200000709010709000606 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 text="#000000" bgcolor="#FFFFFF"> Hi, My ovirt version oVirt Engine Version: 3.5.0.1-1.el6 , i cannot connect to ovirt graphical server via spice , i have already installed firebox plug-in, but i'm using Version 3.1.0-3.26ovirt server without any spice issue, Please guide me to resolve this problem. Thank You, Malinda Tharaka. </body> </html> --------------080200000709010709000606--

1 0

Re: [ovirt-users] Announcing the moVirt Incubator Project!
by Donny D 20 Feb '15

20 Feb '15

----_com.android.email_2495776108079720 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CiAgICAKVGhhdCBpcyBncmVhdCBwcm9qZWN0LiBUaGlzIG1ha2VzIG1lIHZlcnkgaGFwcHkuwqAK CgpIYXBweSBDb25uZWN0aW5nLiBTZW50IGZyb20gbXkgU3ByaW50IFNhbXN1bmcgR2FsYXh5IFPC riA1CgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tCkZyb206IEJyaWFuIFByb2Zm aXR0IDxicHJvZmZpdEByZWRoYXQuY29tPiAKRGF0ZTogMDIvMTcvMjAxNSAgOToxNyBBTSAgKEdN VC0wNzowMCkgClRvOiBib2FyZCA8Ym9hcmRAb3ZpcnQub3JnPiAKQ2M6IGFubm91bmNlQG92aXJ0 Lm9yZywgdXNlcnMgPHVzZXJzQG92aXJ0Lm9yZz4sIGRldmVsQG92aXJ0Lm9yZyAKU3ViamVjdDog W292aXJ0LXVzZXJzXSBBbm5vdW5jaW5nIHRoZSBtb1ZpcnQgSW5jdWJhdG9yIFByb2plY3QhIAoK VGhpcyBtZXNzYWdlIGlzIHRvIGFubm91bmNlIG1vVmlydCBhcyBhIG5ldyBvVmlydCBpbmN1YmF0 b3IgcHJvamVjdCwgYXBwcm92ZWQgYnkgdW5hbmltb3VzIHZvdGUgb2YgdGhlIEJvYXJkIG1haWxp bmcgbGlzdCEKCkRldGFpbHMgYWJvdXQgdGhlIHByb2plY3QgY2FuIGJlIGZvdW5kIGF0CgpodHRw Oi8vd3d3Lm92aXJ0Lm9yZy9Qcm9qZWN0X21vVmlydAoKTW9yZSBpbmZvcm1hdGlvbiBhYm91dCB0 aGUgaW5jdWJhdG9yIGF0IG9WaXJ0IGNhbiBiZSBmb3VuZCBhdAoKaHR0cDovL3d3dy5vdmlydC5v cmcvSW5jdWJhdGluZ19hbl9vVmlydF9TdWJwcm9qZWN0CgpQbGVhc2UgY2hlY2sgb3V0IHRoaXMg cHJvamVjdCBhbmQgc2VlIHdoYXQgeW91IGNhbiBkbyB0byBoZWxwIQoKLS0gCkJyaWFuIFByb2Zm aXR0CgpDb21tdW5pdHkgTGlhaXNvbgpvVmlydApPcGVuIFNvdXJjZSBhbmQgU3RhbmRhcmRzLCBS ZWQgSGF0IC0gaHR0cDovL2NvbW11bml0eS5yZWRoYXQuY29tClBob25lOiArMSA1NzQgMzgzIDlC S1AKSVJDOiBia3AgQCBPRlRDCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fClVzZXJzIG1haWxpbmcgbGlzdApVc2Vyc0BvdmlydC5vcmcKaHR0cDovL2xpc3Rz Lm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzCg== ----_com.android.email_2495776108079720 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT4KICAgIAo8ZGl2PlRoYXQgaXMgZ3Jl YXQgcHJvamVjdC4gVGhpcyBtYWtlcyBtZSB2ZXJ5IGhhcHB5LiZuYnNwOzwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3Np Z25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3Ij5IYXBweSBD b25uZWN0aW5nLiBTZW50IGZyb20gbXkgU3ByaW50IFNhbXN1bmcgR2FsYXh5IFPCriA1PC9kaXY+ PC9kaXY+PGJyPjxicj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJyPkZyb206 IEJyaWFuIFByb2ZmaXR0ICZsdDticHJvZmZpdEByZWRoYXQuY29tJmd0OyA8YnI+RGF0ZTogMDIv MTcvMjAxNSAgOToxNyBBTSAgKEdNVC0wNzowMCkgPGJyPlRvOiBib2FyZCAmbHQ7Ym9hcmRAb3Zp cnQub3JnJmd0OyA8YnI+Q2M6IGFubm91bmNlQG92aXJ0Lm9yZywgdXNlcnMgJmx0O3VzZXJzQG92 aXJ0Lm9yZyZndDssIGRldmVsQG92aXJ0Lm9yZyA8YnI+U3ViamVjdDogW292aXJ0LXVzZXJzXSBB bm5vdW5jaW5nIHRoZSBtb1ZpcnQgSW5jdWJhdG9yIFByb2plY3QhIDxicj48YnI+VGhpcyBtZXNz YWdlIGlzIHRvIGFubm91bmNlIG1vVmlydCBhcyBhIG5ldyBvVmlydCBpbmN1YmF0b3IgcHJvamVj dCwgYXBwcm92ZWQgYnkgdW5hbmltb3VzIHZvdGUgb2YgdGhlIEJvYXJkIG1haWxpbmcgbGlzdCE8 YnI+PGJyPkRldGFpbHMgYWJvdXQgdGhlIHByb2plY3QgY2FuIGJlIGZvdW5kIGF0PGJyPjxicj5o dHRwOi8vd3d3Lm92aXJ0Lm9yZy9Qcm9qZWN0X21vVmlydDxicj48YnI+TW9yZSBpbmZvcm1hdGlv biBhYm91dCB0aGUgaW5jdWJhdG9yIGF0IG9WaXJ0IGNhbiBiZSBmb3VuZCBhdDxicj48YnI+aHR0 cDovL3d3dy5vdmlydC5vcmcvSW5jdWJhdGluZ19hbl9vVmlydF9TdWJwcm9qZWN0PGJyPjxicj5Q bGVhc2UgY2hlY2sgb3V0IHRoaXMgcHJvamVjdCBhbmQgc2VlIHdoYXQgeW91IGNhbiBkbyB0byBo ZWxwITxicj48YnI+LS0gPGJyPkJyaWFuIFByb2ZmaXR0PGJyPjxicj5Db21tdW5pdHkgTGlhaXNv bjxicj5vVmlydDxicj5PcGVuIFNvdXJjZSBhbmQgU3RhbmRhcmRzLCBSZWQgSGF0IC0gaHR0cDov L2NvbW11bml0eS5yZWRoYXQuY29tPGJyPlBob25lOiArMSA1NzQgMzgzIDlCS1A8YnI+SVJDOiBi a3AgQCBPRlRDPGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPlVzZXJzIG1haWxpbmcgbGlzdDxicj5Vc2Vyc0BvdmlydC5vcmc8YnI+aHR0cDovL2xp c3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzPGJyPjwvYm9keT48L2h0bWw+ ----_com.android.email_2495776108079720--

6 6

Re: [ovirt-users] importing iscsi storage domain
by Elad Ben Aharon 19 Feb '15

19 Feb '15

------=_Part_9372914_326988970.1423648670110 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Steven - can you please attach engine.log also? (/var/log/ovirt-engine/engi= ne.log)=20 Adding Maor and Liron from DEV.=20 Maor, Liron, can you take a look?=20 In vdsm.log I see the following:=20 Thread-77065::WARNING::2015-02-10 09:43:49,917::resourceManager::591::Stora= ge.ResourceManager::(registerResource) Resource factory failed to create re= source '2e94bbac-1648-49db-8605-ce574d2bc240_imageNS.952af113-8219-43a4-92a= 9-bfe913ec8b69'. Canceling request.=20 Traceback (most recent call last):=20 File "/usr/share/vdsm/storage/resourceManager.py", line 587, in registerRes= ource=20 obj =3D namespaceObj.factory.createResource(name, lockType)=20 File "/usr/share/vdsm/storage/resourceFactories.py", line 193, in createRes= ource=20 lockType)=20 File "/usr/share/vdsm/storage/resourceFactories.py", line 119, in __getReso= urceCandidatesList=20 repoPath =3D os.path.join(self.storage_repository, dom.getPools()[0])=20 IndexError: list index out of range=20 Thread-77065::DEBUG::2015-02-10 09:43:49,918::resourceManager::210::Storage= .ResourceManager.Request::(cancel) ResName=3D`2e94bbac-1648-49db-8605-ce574= d2bc240_imageNS.952af113-8219-43a4-92a9-bfe913ec8b69`ReqID=3D`10e68fbb-ac50= -461f-92ac-d8c43060ed43`::Canceled request=20 Thread-77065::WARNING::2015-02-10 09:43:49,918::resourceManager::203::Stora= ge.ResourceManager.Request::(cancel) ResName=3D`2e94bbac-1648-49db-8605-ce5= 74d2bc240_imageNS.952af113-8219-43a4-92a9-bfe913ec8b69`ReqID=3D`10e68fbb-ac= 50-461f-92ac-d8c43060ed43`::Tried to cancel a processed request=20 Thread-77065::ERROR::2015-02-10 09:43:49,918::task::866::Storage.TaskManage= r.Task::(_setError) Task=3D`6e023655-23ad-42cd-9b7e-6c5e5e3b08b9`::Unexpect= ed error=20 Traceback (most recent call last):=20 File "/usr/share/vdsm/storage/task.py", line 873, in _run=20 return fn(*args, **kargs)=20 File "/usr/share/vdsm/logUtils.py", line 45, in wrapper=20 res =3D f(*args, **kwargs)=20 File "/usr/share/vdsm/storage/hsm.py", line 1285, in setVolumeDescription= =20 pool.setVolumeDescription(sdUUID, imgUUID, volUUID, description)=20 File "/usr/share/vdsm/storage/securable.py", line 77, in wrapper=20 return method(self, *args, **kwargs)=20 File "/usr/share/vdsm/storage/sp.py", line 1884, in setVolumeDescription=20 rm.LockType.exclusive):=20 File "/usr/share/vdsm/storage/resourceManager.py", line 523, in acquireReso= urce=20 raise se.ResourceAcqusitionFailed()=20 ResourceAcqusitionFailed: Could not acquire resource. Probably resource fac= tory threw an exception.: ()=20 ----- Original Message ----- From: "Steven M. Bellistri" <SBellistri(a)ldirx.com>=20 To: "Elad Ben Aharon" <ebenahar(a)redhat.com>=20 Sent: Tuesday, 10 February, 2015 6:35:32 PM=20 Subject: RE: [ovirt-users] importing iscsi storage domain=20 Another issue, when I failback the 2 storage domains, the 2 nd SD is not wo= rking. The vm that has the DB drives will not boot after I failover (I chec= ked the virtio-scsi setting and it was checked), but I was getting an error= in the manager saying that: Failed to update OVF disks 952af113-8219-43a4-= 92a9-bfe913ec8b69, OVF data isn't updated on those OVF stores (Data Center = Default, Storage Domain iSCSI_2). So then I tried putting the SD2 into main= tenance mode and then reactivating it, but it would not active or would it = detach. I had to destroy the SD. The weird thing is that I had no problems = with the 1 st SD. I am sending the vdsm.log file from the host in the PR si= te.=20 From: Elad Ben Aharon [mailto:ebenahar@redhat.com]=20 Sent: Monday, February 9, 2015 1:26 AM=20 To: Steven M. Bellistri=20 Cc: Aharon Canan; users(a)ovirt.org=20 Subject: Re: [ovirt-users] importing iscsi storage domain=20 The import domain operation consists of several stages which their executio= n time can vary.=20 It would be almost impossible to estimate how long it will take. But, since= the whole import operation, along with the VMs registration in the new env= ironment, doesn't involve any long time operations, like disks creation, it= shouldn't take more than a few minutes.=20 ----- Original Message ----- From: "Steven M. Bellistri" <SBellistri(a)ldirx.com>=20 To: "Elad Ben Aharon" <ebenahar(a)redhat.com>=20 Cc: "Aharon Canan" <acanan(a)redhat.com>, users(a)ovirt.org=20 Sent: Thursday, 5 February, 2015 5:41:11 PM=20 Subject: RE: [ovirt-users] importing iscsi storage domain=20 I put the storage domain in maintenance mode, then changed the time from 60= minutes to 5min, then after I failed the storage over I was able to import = the domain. Thanks so much for the help. I just have one more question, is = there anyway to calculate how long it will take to import a domain, because= our production environment is about 5.5TB with about 40vm=E2=80=99s?=20 thanks=20 From: Elad Ben Aharon [mailto:ebenahar@redhat.com]=20 Sent: Thursday, February 5, 2015 1:49 AM=20 To: Steven M. Bellistri=20 Cc: Aharon Canan; users(a)ovirt.org=20 Subject: Re: [ovirt-users] importing iscsi storage domain=20 If you can't see the VMs under 'VM Import' subtab under the imported storag= e domain, it means that you won't be able to recover those VMs (because the= ir configuration files weren't uploaded to the domain).=20 For the next time, you can decrease the time interval of the OVFs upload as= explained below in the thread.=20 Regarding the upgrade, it is possible to upgrade from 3.4 to 3.5 and once y= ou'll upgrade the setup and the DC compatibility version to 3.5, the OVFs o= f the VMs will be uploaded to the storage domains where the VMs's disks are= located on. (again, every 60 minutes by default).=20 Elad Ben Aharon=20 RHEV-QE storage=20 From: "Steven M. Bellistri" < SBellistri(a)ldirx.com >=20 To: "Elad Ben Aharon" < ebenahar(a)redhat.com >=20 Cc: "Aharon Canan" < acanan(a)redhat.com >, users(a)ovirt.org=20 Sent: Wednesday, 4 February, 2015 5:44:37 PM=20 Subject: RE: [ovirt-users] importing iscsi storage domain=20 No, I did not wait 60 minutes before I tried to failover. Do, I need to sta= rt over, or can I just failback and wait the hour for the ovfs to upload? I= do have a question, is this feature possible for an environment that was u= pgraded from 3.4 to 3.5? My production environment is 3.4, the 3.5 environm= ent is a clean test environment, but if I cant upgrade to 3.5 from 3.4 then= this will not be a good DR option for me.=20 thanks=20 From: Elad Ben Aharon [ mailto:ebenahar@redhat.com ]=20 Sent: Wednesday, February 4, 2015 8:56 AM=20 To: Steven M. Bellistri=20 Cc: Aharon Canan; users(a)ovirt.org=20 Subject: Re: [ovirt-users] importing iscsi storage domain=20 Hi Steven,=20 In order to import the VMs from the imported storage domain, the VMs config= uration files (which are called OVFs) have to be uploaded first before the = domain is detached from the setup. This is being done by engine in a time i= nterval of 60 minutes (it's configurable using rhevm-config --set OvfUpdate= InMinutes=3D<value> and restart ovirt-engine service). From 3.5.1, the OVFs= are uploaded once you move the storage domain to maintenance. did you do s= o in the original RHEV environment? What was the version of this environmen= t?=20 If you didn't deactivate the domain in the first environment and then tried= to attach it to the DR environment, the existence of the VMs in the domain= depends on the OVFs upload that was supposed to be done by the first engin= e, which is being done every 60 minutes as explained, so if you've created = those VMs and immediately destroyed the setup, those VMs probably won't be = available for you in the DR environment.=20 Elad Ben Aharon=20 RHEV-QE storage=20 From: "Steven M. Bellistri" < SBellistri(a)LDIRx.com >=20 To: "Aharon Canan" < acanan(a)redhat.com >=20 Cc: users(a)ovirt.org=20 Sent: Tuesday, 3 February, 2015 6:16:01 PM=20 Subject: Re: [ovirt-users] importing iscsi storage domain=20 version 3.5.1=20 From: Aharon Canan [ mailto:acanan@redhat.com ]=20 Sent: Tuesday, February 3, 2015 6:22 AM=20 To: Steven M. Bellistri=20 Cc: users(a)ovirt.org=20 Subject: Re: [ovirt-users] importing iscsi storage domain=20 What version are you using?=20 Regards,=20 __________________________________________________=20 Aharon Canan=20 int phone - 8272036=20 ext phone - +97297692036=20 email - acanan(a)redhat.com=20 From: "Steven M. Bellistri" < SBellistri(a)ldirx.com >=20 To: "Aharon Canan" < acanan(a)redhat.com >=20 Cc: users(a)ovirt.org=20 Sent: Monday, February 2, 2015 8:12:00 PM=20 Subject: RE: [ovirt-users] importing iscsi storage domain=20 Thank you for the response.=20 I went thru the steps 1-9, and when I get to step 10 there is no import vms= or import templates sub-tabs. I am including the vdsm.log from the host. A= lso, when I do a lvs on the host, I can see the disks that reside in the im= ported SD, one is 30gb and the other is 40gb. The storage domain I am impor= ting is called iSCSI.=20 From: Aharon Canan [ mailto:acanan@redhat.com ]=20 Sent: Sunday, February 1, 2015 9:55 AM=20 To: Steven M. Bellistri=20 Cc: users(a)ovirt.org=20 Subject: Re: [ovirt-users] importing iscsi storage domain=20 Hi=20 Please check below link for info, ovirt version should be 3.5=20 http://www.ovirt.org/Features/ImportStorageDomain=20 please be aware to step 10 under " Work flow for Import block Storage Domai= n - UI flow "=20 In case it is not working, please add exact steps and engine/vdsm logs so w= e will be able to check=20 Regards,=20 __________________________________________________=20 Aharon Canan=20 int phone - 8272036=20 ext phone - +97297692036=20 email - acanan(a)redhat.com=20 <blockquote> From: "Steven M. Bellistri" < SBellistri(a)LDIRx.com >=20 To: " users(a)ovirt.org " < users(a)ovirt.org >=20 Sent: Friday, January 30, 2015 12:18:54 AM=20 Subject: [ovirt-users] importing iscsi storage domain=20 I am trying to test failing over to a DR site using the storage domain impo= rt. The DR site shows that it imported the iscsi storage domain, and activa= tes it in the datacenter, but none of the vm=E2=80=99s or anything shows up= . What am I missing.=20 thanks=20 Steven Bellistri=20 This email and its attachments may contain privileged and confidential info= rmation and/or protected health information (PHI) intended solely for the u= se of LDI Integrated Pharmacy Services and the recipient(s) named above. If= you are not the recipient, or the employee or agent responsible for delive= ring this message to the intended recipient, you are hereby notified that a= ny review, dissemination, distribution, printing or copying of this email m= essage and/or any attachments is strictly prohibited. If you have received = this transmission in error, please notify the sender immediately at 1-866-5= 16-3121 and permanently delete this email and any attachments.=20 _______________________________________________=20 Users mailing list=20 Users(a)ovirt.org=20 http://lists.ovirt.org/mailman/listinfo/users=20 This email and its attachments may contain privileged and confidential info= rmation and/or protected health information (PHI) intended solely for the u= se of LDI Integrated Pharmacy Services and the recipient(s) named above. If= you are not the recipient, or the employee or agent responsible for delive= ring this message to the intended recipient, you are hereby notified that a= ny review, dissemination, distribution, printing or copying of this email m= essage and/or any attachments is strictly prohibited. If you have received = this transmission in error, please notify the sender immediately at 1-866-5= 16-3121 and permanently delete this email and any attachments.=20 </blockquote> This email and its attachments may contain privileged and confidential info= rmation and/or protected health information (PHI) intended solely for the u= se of LDI Integrated Pharmacy Services and the recipient(s) named above. If= you are not the recipient, or the employee or agent responsible for delive= ring this message to the intended recipient, you are hereby notified that a= ny review, dissemination, distribution, printing or copying of this email m= essage and/or any attachments is strictly prohibited. If you have received = this transmission in error, please notify the sender immediately at 1-866-5= 16-3121 and permanently delete this email and any attachments.=20 _______________________________________________=20 Users mailing list=20 Users(a)ovirt.org=20 http://lists.ovirt.org/mailman/listinfo/users=20 This email and its attachments may contain privileged and confidential info= rmation and/or protected health information (PHI) intended solely for the u= se of LDI Integrated Pharmacy Services and the recipient(s) named above. If= you are not the recipient, or the employee or agent responsible for delive= ring this message to the intended recipient, you are hereby notified that a= ny review, dissemination, distribution, printing or copying of this email m= essage and/or any attachments is strictly prohibited. If you have received = this transmission in error, please notify the sender immediately at 1-866-5= 16-3121 and permanently delete this email and any attachments.=20 This email and its attachments may contain privileged and confidential info= rmation and/or protected health information (PHI) intended solely for the u= se of LDI Integrated Pharmacy Services and the recipient(s) named above. If= you are not the recipient, or the employee or agent responsible for delive= ring this message to the intended recipient, you are hereby notified that a= ny review, dissemination, distribution, printing or copying of this email m= essage and/or any attachments is strictly prohibited. If you have received = this transmission in error, please notify the sender immediately at 1-866-5= 16-3121 and permanently delete this email and any attachments.=20 This email and its attachments may contain privileged and confidential info= rmation and/or protected health information (PHI) intended solely for the u= se of LDI Integrated Pharmacy Services and the recipient(s) named above. If= you are not the recipient, or the employee or agent responsible for delive= ring this message to the intended recipient, you are hereby notified that a= ny review, dissemination, distribution, printing or copying of this email m= essage and/or any attachments is strictly prohibited. If you have received = this transmission in error, please notify the sender immediately at 1-866-5= 16-3121 and permanently delete this email and any attachments.=20 ------=_Part_9372914_326988970.1423648670110 Content-Type: multipart/related; boundary="----=_Part_9372915_292966117.1423648670110" ------=_Part_9372915_292966117.1423648670110 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: times new roman, new york, times, se= rif; font-size: 12pt; color: #000000"><div><div>Steven - can you please att= ach engine.log also? (/var/log/ovirt-engine/engine.log) </div></div><div= > </div><div>Adding Maor and Liron from DEV. </div><div> Maor, L= iron, can you take a look? </div><div> </div><div>In vdsm.log I see = the following: </div><div> </div><div>Thread-77065::WARNING::2015-02-= 10 09:43:49,917::resourceManager::591::Storage.ResourceManager::(registerRe= source) Resource factory failed to create resource '2e94bbac-1648-49db-8605= -ce574d2bc240_imageNS.952af113-8219-43a4-92a9-bfe913ec8b69'. Canceling requ= est. Traceback (most recent call last):   File "/usr/share/vdsm/= storage/resourceManager.py", line 587, in registerResource   &= nbsp; obj =3D namespaceObj.factory.createResource(name, lockType)  = File "/usr/share/vdsm/storage/resourceFactories.py", line 193, in createRe= source     lockType)   File "/usr/share/vdsm/stor= age/resourceFactories.py", line 119, in __getResourceCandidatesList &nbs= p;   repoPath =3D os.path.join(self.storage_repository, dom.getPo= ols()[0]) IndexError: list index out of range Thread-77065::DEBUG::20= 15-02-10 09:43:49,918::resourceManager::210::Storage.ResourceManager.Reques= t::(cancel) ResName=3D`2e94bbac-1648-49db-8605-ce574d2bc240_imageNS.952af11= 3-8219-43a4-92a9-bfe913ec8b69`ReqID=3D`10e68fbb-ac50-461f-92ac-d8c43060ed43= `::Canceled request Thread-77065::WARNING::2015-02-10 09:43:49,918::reso= urceManager::203::Storage.ResourceManager.Request::(cancel) ResName=3D`2e94= bbac-1648-49db-8605-ce574d2bc240_imageNS.952af113-8219-43a4-92a9-bfe913ec8b= 69`ReqID=3D`10e68fbb-ac50-461f-92ac-d8c43060ed43`::Tried to cancel a proces= sed request Thread-77065::ERROR::2015-02-10 09:43:49,918::task::866::Sto= rage.TaskManager.Task::(_setError) Task=3D`6e023655-23ad-42cd-9b7e-6c5e5e3b= 08b9`::Unexpected error Traceback (most recent call last):   Fil= e "/usr/share/vdsm/storage/task.py", line 873, in _run   &nbsp= ; return fn(*args, **kargs)   File "/usr/share/vdsm/logUtils.py", l= ine 45, in wrapper     res =3D f(*args, **kwargs) &nbs= p; File "/usr/share/vdsm/storage/hsm.py", line 1285, in setVolumeDescriptio= n     pool.setVolumeDescription(sdUUID, imgUUID, volUUID,= description)   File "/usr/share/vdsm/storage/securable.py", line 7= 7, in wrapper     return method(self, *args, **kwargs)<br= >  File "/usr/share/vdsm/storage/sp.py", line 1884, in setVolumeDescri= ption     rm.LockType.exclusive):   File "/usr/sh= are/vdsm/storage/resourceManager.py", line 523, in acquireResource &nbsp= ;   raise se.ResourceAcqusitionFailed() ResourceAcqusitionFail= ed: Could not acquire resource. Probably resource factory threw an exceptio= n.: ()</div><div> </div><div> </div><hr id=3D"zwchr"><div style=3D"co= lor:#000;font-weight:normal;font-style:normal;text-decoration:none;font-fam= ily:Helvetica,Arial,sans-serif;font-size:12pt;">From: "Steven M. Bel= listri" <SBellistri(a)ldirx.com> To: "Elad Ben Aharon" <eb= enahar(a)redhat.com> Sent: Tuesday, 10 February, 2015 6:35:32 PM= Subject: RE: [ovirt-users] importing iscsi storage domain <di= v> </div> <style></style> <div class=3D"WordSection1"> Another issue, when I = failback the 2 storage domains, the 2nd SD is not working. = The vm that has the DB drives will not boot after I failover (I checked th= e virtio-scsi setting and it was checked), but I was getting an error in the manager saying that: Failed to update OV= F disks 952af113-8219-43a4-92a9-bfe913ec8b69, OVF data isn't updated on tho= se OVF stores (Data Center Default, Storage Domain iSCSI_2).   So= then I tried putting the SD2 into maintenance mode and then reactivating it, but it would not active or would it detach.=   I had to destroy the SD.  The weird thing is that I had no prob= lems with the 1st SD.  I am sending the vdsm.log file from = the host in the PR site.   <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> From: Elad Ben Aharon [mailto:ebenahar@redhat= .com] Sent: Monday, February 9, 2015 1:26 AM To: Steven M. Bellistri Cc: Aharon Canan; users(a)ovirt.org Subject: Re: [ovirt-users] importing iscsi storage domain </div> </div>   <div> <div> The import domain operat= ion consists of several stages which their execution time can vary.<= span style=3D"font-size:12.0pt;color:black"> </div> <div> It would be almost impos= sible to estimate how long it will take. But, since the whole import operat= ion, along with the VMs registration in the new environment, doesn't involv= e any long time operations, like disks creation, it shouldn't take more than a few minutes. </div> <div>   </div> <div>   </div> <div class=3D"MsoNormal" style=3D"text-align:center" align=3D"center"><span= style=3D"color:black"> <hr id=3D"zwchr" size=3D"2" width=3D"100%" align=3D"center"> </div> <div> From: "Steven M. Bellistri" <SBellistri(a)ldirx.com> To: "Elad Ben Aharon" <ebenahar(a)redhat.com> Cc: "Aharon Canan" <acanan(a)redhat.com>, users(a)ovirt.org Sent: Thursday, 5 February, 2015 5:41:11 PM Subject: RE: [ovirt-users] importing iscsi storage domain <div>   </div> I put the storage doma= in in maintenance mode, then changed the time from 60minutes to 5min, then = after I failed the storage over I was able to import the domain.  Than= ks so much for the help.  I just have one more question, is there anyway to calculate how long it will take to impor= t a domain, because our production environment is about 5.5TB with about 40= vm=E2=80=99s?   thanks   <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> From:<span= style=3D"color:black"> Elad Ben Aharon [mailto:ebenahar@redhat.com] Sent: Thursday, February 5, 2015 1:49 AM To: Steven M. Bellistri Cc: Aharon Canan; users(a)ovirt.org Subject: Re: [ovirt-users] importing iscsi storage domain </div> </div>   <div> <div> If you can't see the VMs= under 'VM Import' subtab under the imported storage domain, it means that = you won't be able to recover those VMs (because their configuration files w= eren't uploaded to the domain). </div> <div> For the next time, you c= an decrease the time interval of the OVFs upload as explained below in the = thread. </div> <div> Regarding the upgrade, i= t is possible to upgrade from 3.4 to 3.5 and once you'll upgrade the setup = and the DC compatibility version to 3.5, the OVFs of the VMs will be upload= ed to the storage domains where the VMs's disks are located on. (again, every 60 minutes by default). </div> <div> </div> <div> <div>   </div>    Elad Ben Aharon RHEV-QE storage <div> <img id=3D"_x0000_i1025"= src=3D"cid:image001.jpg@01D0451B.AEA225C0" height=3D"68" width=3D"150"></s= pan> </div> <div>     </spa= n> </div>   </div> <div>   </div> <div class=3D"MsoNormal" style=3D"text-align:center" align=3D"center"><span= style=3D"color:black"> <hr size=3D"2" width=3D"100%" align=3D"center"> </div> <div> From: "Steven M. Bellistri" <<a href=3D"mailto:SBellistri@ldirx.com" = target=3D"_blank">SBellistri(a)ldirx.com</a>> To: "Elad Ben Aharon" <<a href=3D"mailto:ebenahar@redhat.com" tar= get=3D"_blank">ebenahar(a)redhat.com</a>> Cc: "Aharon Canan" <<a href=3D"mailto:acanan@redhat.com" target= =3D"_blank">acanan(a)redhat.com</a>>, <a href=3D"mailto:users@ovirt.org" target=3D"_blank">users(a)ovirt.org</a><br= > Sent: Wednesday, 4 February, 2015 5:44:37 PM Subject: RE: [ovirt-users] importing iscsi storage domain<spa= n style=3D"color:black"> <div>   </div> No, I did not wait 60 = minutes before I tried to failover.  Do, I need to start over, or can = I just failback and wait the hour for the ovfs to upload?  I do have a= question, is this feature possible for an environment that was upgraded from 3.4 to 3.5?  My production environment is 3.4,= the 3.5 environment is a clean test environment, but if I cant upgrade to = 3.5 from 3.4 then this will not be a good DR option for me.    thanks   <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> From:<span= style=3D"color:black"> Elad Ben Aharon [<a href=3D"mailto:ebenahar@redhat.= com" target=3D"_blank">mailto:ebenahar@redhat.com</a>] Sent: Wednesday, February 4, 2015 8:56 AM To: Steven M. Bellistri Cc: Aharon Canan; <a href=3D"mailto:users@ovirt.org" target=3D"_blan= k">users(a)ovirt.org</a> Subject: Re: [ovirt-users] importing iscsi storage domain </div> </div>   <div> <div> Hi Steven, </div> <div>   </div> <div> In order to import the V= Ms from the imported storage domain, the VMs configuration files (which are= called OVFs) have to be uploaded first before the domain is detached from = the setup. This is being done by engine in a time interval of 60 minutes (it's configurable using rhevm-config --s= et OvfUpdateInMinutes=3D<value> and restart ovirt-engine service). Fr= om 3.5.1, the OVFs are uploaded once you move the storage domain to mainten= ance.  did you do so in the original RHEV environment? What was the version of this environment? </div> <div> If you didn't deactivate= the domain in the first environment and then tried to attach it to the DR = environment, the existence of the VMs in the domain depends on the OVFs upl= oad that was supposed to be done by the first engine, which is being done every 60 minutes as explained, so if= you've created those VMs and immediately destroyed the setup, those VMs pr= obably won't be available for you in the DR environment. </div> <div>   </div> <div>   </div> <div>   </div> <div> <div>   </div>    Elad Ben Aharon RHEV-QE storage <div> <img id=3D"_x0000_i1027"= src=3D"cid:image001.jpg@01D0451B.AEA225C0" height=3D"68" width=3D"150" bor= der=3D"0"> </div> <div>     </spa= n> </div>   </div> <div>   </div> <div class=3D"MsoNormal" style=3D"text-align:center" align=3D"center"><span= style=3D"color:black"> <hr size=3D"2" width=3D"100%" align=3D"center"> </div> <div> From: "Steven M. Bellistri" <<a href=3D"mailto:SBellistri@LDIRx.com" = target=3D"_blank">SBellistri(a)LDIRx.com</a>> To: "Aharon Canan" <<a href=3D"mailto:acanan@redhat.com" target= =3D"_blank">acanan(a)redhat.com</a>> Cc: <a href=3D"mailto:users@ovirt.org" target=3D"_blank">users@ovirt= .org</a> Sent: Tuesday, 3 February, 2015 6:16:01 PM Subject: Re: [ovirt-users] importing iscsi storage domain<spa= n style=3D"color:black"> <div>   </div> version 3.5.1<s= pan style=3D"color:black">   <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> From:<span= style=3D"color:black"> Aharon Canan [<a href=3D"mailto:acanan@redhat.com" = target=3D"_blank">mailto:acanan@redhat.com</a>] Sent: Tuesday, February 3, 2015 6:22 AM To: Steven M. Bellistri Cc: <a href=3D"mailto:users@ovirt.org" target=3D"_blank">users@ovirt= .org</a> Subject: Re: [ovirt-users] importing iscsi storage domain </div> </div>   <div> <div> What version are you using? </div> <div>  </s= pan> </div> <div> <div>  </s= pan> </div> <div>  </s= pan> </div> <div> Regards, __________________________________________________ Aharon Canan = int phone - 8272036 = ext phone - +97297692036 = email - <a href=3D"mailto:acanan@redhat.com" target=3D"_blank"> acanan(a)redhat.com</a> </div>  </s= pan> </div> <div class=3D"MsoNormal" style=3D"text-align:center" align=3D"center"><span= style=3D"color:black"> <hr size=3D"2" width=3D"100%" align=3D"center"> </div> <blockquote style=3D"border:none;border-left:solid #1010FF 1.5pt;padding:0i= n 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-bottom:5.0pt"> From: "Steven M. Bellistri" <<a href=3D"mailto:SBellistri@ldirx.com" = target=3D"_blank">SBellistri(a)ldirx.com</a>> To: "Aharon Canan" <<a href=3D"mailto:acanan@redhat.com" target= =3D"_blank">acanan(a)redhat.com</a>> Cc: <a href=3D"mailto:users@ovirt.org" target=3D"_blank">users@ovirt= .org</a> Sent: Monday, February 2, 2015 8:12:00 PM Subject: RE: [ovirt-users] importing iscsi storage domain<spa= n style=3D"color:black"> <div>   </div> Thank you for the resp= onse.   I went thru the steps = 1-9, and when I get to step 10 there is no import vms or import templates s= ub-tabs.  I am including the vdsm.log from the host.  Also, when = I do a lvs on the host, I can see the disks that reside in the imported SD, one is 30gb and the other is 40gb.  The st= orage domain I am importing is called iSCSI.     <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> From:<span= style=3D"color:black"> Aharon Canan [<a href=3D"mailto:acanan@redhat.com" = target=3D"_blank">mailto:acanan@redhat.com</a>] Sent: Sunday, February 1, 2015 9:55 AM To: Steven M. Bellistri Cc: <a href=3D"mailto:users@ovirt.org" target=3D"_blank">users@ovirt= .org</a> Subject: Re: [ovirt-users] importing iscsi storage domain </div> </div>   <div> <div> Hi= </div> <div>  </s= pan> </div> <div> Please check below link for info, ovirt vers= ion should be 3.5 </div> <div> <a href=3D"http://www.ovirt.org/Features/Imp= ortStorageDomain" target=3D"_blank">http://www.ovirt.org/Features/ImportSto= rageDomain</a> </div> <div>  </s= pan> </div> <div> please be aware to step 10 under "Work flow for Import block Storage Domain - UI flow</span= >" </div> <div>  </s= pan> </div> <div> In case it is not working, please add exact = steps and engine/vdsm logs so we will be able to check </div> <div>  </s= pan> </div> <div> <div>  </s= pan> </div> <div>  </s= pan> </div> <div> Regards, __________________________________________________ Aharon Canan = int phone - 8272036 = ext phone - +97297692036 = email - <a href=3D"mailto:acanan@redhat.com" target=3D"_blank"> acanan(a)redhat.com</a> </div>  </s= pan> </div> <div class=3D"MsoNormal" style=3D"text-align:center" align=3D"center"><span= style=3D"color:black"> <hr size=3D"2" width=3D"100%" align=3D"center"> </div> <blockquote style=3D"border:none;border-left:solid #1010FF 1.5pt;padding:0i= n 0in 0in 4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-bottom:5.0pt"> From: "Steven M. Bellistri" <<a href=3D"mailto:SBellistri@LDIRx.com" = target=3D"_blank">SBellistri(a)LDIRx.com</a>> To: "<a href=3D"mailto:users@ovirt.org" target=3D"_blank">users@ovir= t.org</a>" <<a href=3D"mailto:users@ovirt.org" target=3D"_blank">users@o= virt.org</a>> Sent: Friday, January 30, 2015 12:18:54 AM Subject: [ovirt-users] importing iscsi storage domain <div>   </div> I am trying to test fail= ing over to a DR site using the storage domain import.  The DR site sh= ows that it imported the iscsi storage domain, and activates it in the data= center, but none of the vm=E2=80=99s or anything shows up.  What am I missing.   thanks   Steven Bellistri<= /p> This email and its attachments may contain privileged and confidential info= rmation and/or protected health information (PHI) intended solely for the u= se of LDI Integrated Pharmacy Services and the recipient(s) named above. If= you are not the recipient, or the employee or agent responsible for delivering this message to the intended = recipient, you are hereby notified that any review, dissemination, distribu= tion, printing or copying of this email message and/or any attachments is s= trictly prohibited. If you have received this transmission in error, please notify the sender immediately = at 1-866-516-3121 and permanently delete this email and any attachments. _______________________________________________ Users mailing list <a href=3D"mailto:Users@ovirt.org" target=3D"_blank">Users(a)ovirt.org</a><br= > <a href=3D"http://lists.ovirt.org/mailman/listinfo/users" target=3D"_blank"= >http://lists.ovirt.org/mailman/listinfo/users</a> </blockquote> <div>  </s= pan> </div> </div> This email and its attachments may contain privileged and confidential info= rmation and/or protected health information (PHI) intended solely for the u= se of LDI Integrated Pharmacy Services and the recipient(s) named above. If= you are not the recipient, or the employee or agent responsible for delivering this message to the intended = recipient, you are hereby notified that any review, dissemination, distribu= tion, printing or copying of this email message and/or any attachments is s= trictly prohibited. If you have received this transmission in error, please notify the sender immediately = at 1-866-516-3121 and permanently delete this email and any attachments. </blockquote> <div>  </s= pan> </div> </div> This email and its attachments may contain privileged and confidential info= rmation and/or protected health information (PHI) intended solely for the u= se of LDI Integrated Pharmacy Services and the recipient(s) named above. If= you are not the recipient, or the employee or agent responsible for delivering this message to the intended = recipient, you are hereby notified that any review, dissemination, distribu= tion, printing or copying of this email message and/or any attachments is s= trictly prohibited. If you have received this transmission in error, please notify the sender immediately = at 1-866-516-3121 and permanently delete this email and any attachments. _______________________________________________ Users mailing list <a href=3D"mailto:Users@ovirt.org" target=3D"_blank">Users(a)ovirt.org</a><br= > <a href=3D"http://lists.ovirt.org/mailman/listinfo/users" target=3D"_blank"= >http://lists.ovirt.org/mailman/listinfo/users</a> </div> <div>   </div> </div> This email and its attachments may contain privileged and confidential info= rmation and/or protected health information (PHI) intended solely for the u= se of LDI Integrated Pharmacy Services and the recipient(s) named above. If= you are not the recipient, or the employee or agent responsible for delivering this message to the intended = recipient, you are hereby notified that any review, dissemination, distribu= tion, printing or copying of this email message and/or any attachments is s= trictly prohibited. If you have received this transmission in error, please notify the sender immediately = at 1-866-516-3121 and permanently delete this email and any attachments.</s= pan> </div> <div>   </div> </div> This email and its attachments may contain privileged and confidential info= rmation and/or protected health information (PHI) intended solely for the u= se of LDI Integrated Pharmacy Services and the recipient(s) named above. If= you are not the recipient, or the employee or agent responsible for delivering this message to the intended = recipient, you are hereby notified that any review, dissemination, distribu= tion, printing or copying of this email message and/or any attachments is s= trictly prohibited. If you have received this transmission in error, please notify the sender immediately = at 1-866-516-3121 and permanently delete this email and any attachments.</s= pan> </div> <div>   </div> </div> </div> This email and its attachments may contain privileged and confidential info= rmation and/or protected health information (PHI) intended solely for the u= se of LDI Integrated Pharmacy Services and the recipient(s) named above. If= you are not the recipient, or the employee or agent responsible for delive= ring this message to the intended recipient, you are hereby notified that a= ny review, dissemination, distribution, printing or copying of this email m= essage and/or any attachments is strictly prohibited. If you have received = this transmission in error, please notify the sender immediately at 1-866-5= 16-3121 and permanently delete this email and any attachments. </div><div> </div></div></body></html> ------=_Part_9372915_292966117.1423648670110 Content-Type: image/jpeg; name=image001.jpg Content-Disposition: attachment; filename=image001.jpg Content-Transfer-Encoding: base64 Content-Description: image001.jpg Content-ID: <image001.jpg(a)01D0451B.AEA225C0> /9j/4AAQSkZJRgABAQEASABIAAD/4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlubwIQAABtbnRyUkdC IFhZWiAHzgACAAkABgAxAABhY3NwTVNGVAAAAABJRUMgc1JHQgAAAAAAAAAAAAAAAAAA9tYAAQAA AADTLUhQICAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFj cHJ0AAABUAAAADNkZXNjAAABhAAAAGx3dHB0AAAB8AAAABRia3B0AAACBAAAABRyWFlaAAACGAAA ABRnWFlaAAACLAAAABRiWFlaAAACQAAAABRkbW5kAAACVAAAAHBkbWRkAAACxAAAAIh2dWVkAAAD TAAAAIZ2aWV3AAAD1AAAACRsdW1pAAAD+AAAABRtZWFzAAAEDAAAACR0ZWNoAAAEMAAAAAxyVFJD AAAEPAAACAxnVFJDAAAEPAAACAxiVFJDAAAEPAAACAx0ZXh0AAAAAENvcHlyaWdodCAoYykgMTk5 OCBIZXdsZXR0LVBhY2thcmQgQ29tcGFueQAAZGVzYwAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEA AAAAAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVogAAAAAAAAAAAAAAAA AAAAAFhZWiAAAAAAAABvogAAOPUAAAOQWFlaIAAAAAAAAGKZAAC3hQAAGNpYWVogAAAAAAAAJKAA AA+EAAC2z2Rlc2MAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAFklFQyBo dHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABkZXNjAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAt IHNSR0IAAAAAAAAAAAAAAC5JRUMgNjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAt IHNSR0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcg Q29uZGl0aW9uIGluIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAALFJlZmVyZW5jZSBWaWV3aW5nIENv bmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHZpZXcAAAAA ABOk/gAUXy4AEM8UAAPtzAAEEwsAA1yeAAAAAVhZWiAAAAAAAEwJVgBQAAAAVx/nbWVhcwAAAAAA AAABAAAAAAAAAAAAAAAAAAAAAAAAAo8AAAACc2lnIAAAAABDUlQgY3VydgAAAAAAAAQAAAAABQAK AA8AFAAZAB4AIwAoAC0AMgA3ADsAQABFAEoATwBUAFkAXgBjAGgAbQByAHcAfACBAIYAiwCQAJUA mgCfAKQAqQCuALIAtwC8AMEAxgDLANAA1QDbAOAA5QDrAPAA9gD7AQEBBwENARMBGQEfASUBKwEy ATgBPgFFAUwBUgFZAWABZwFuAXUBfAGDAYsBkgGaAaEBqQGxAbkBwQHJAdEB2QHhAekB8gH6AgMC DAIUAh0CJgIvAjgCQQJLAlQCXQJnAnECegKEAo4CmAKiAqwCtgLBAssC1QLgAusC9QMAAwsDFgMh Ay0DOANDA08DWgNmA3IDfgOKA5YDogOuA7oDxwPTA+AD7AP5BAYEEwQgBC0EOwRIBFUEYwRxBH4E jASaBKgEtgTEBNME4QTwBP4FDQUcBSsFOgVJBVgFZwV3BYYFlgWmBbUFxQXVBeUF9gYGBhYGJwY3 BkgGWQZqBnsGjAadBq8GwAbRBuMG9QcHBxkHKwc9B08HYQd0B4YHmQesB78H0gflB/gICwgfCDII RghaCG4IggiWCKoIvgjSCOcI+wkQCSUJOglPCWQJeQmPCaQJugnPCeUJ+woRCicKPQpUCmoKgQqY Cq4KxQrcCvMLCwsiCzkLUQtpC4ALmAuwC8gL4Qv5DBIMKgxDDFwMdQyODKcMwAzZDPMNDQ0mDUAN Wg10DY4NqQ3DDd4N+A4TDi4OSQ5kDn8Omw62DtIO7g8JDyUPQQ9eD3oPlg+zD88P7BAJECYQQxBh EH4QmxC5ENcQ9RETETERTxFtEYwRqhHJEegSBxImEkUSZBKEEqMSwxLjEwMTIxNDE2MTgxOkE8UT 5RQGFCcUSRRqFIsUrRTOFPAVEhU0FVYVeBWbFb0V4BYDFiYWSRZsFo8WshbWFvoXHRdBF2UXiReu F9IX9xgbGEAYZRiKGK8Y1Rj6GSAZRRlrGZEZtxndGgQaKhpRGncanhrFGuwbFBs7G2MbihuyG9oc AhwqHFIcexyjHMwc9R0eHUcdcB2ZHcMd7B4WHkAeah6UHr4e6R8THz4faR+UH78f6iAVIEEgbCCY IMQg8CEcIUghdSGhIc4h+yInIlUigiKvIt0jCiM4I2YjlCPCI/AkHyRNJHwkqyTaJQklOCVoJZcl xyX3JicmVyaHJrcm6CcYJ0kneierJ9woDSg/KHEooijUKQYpOClrKZ0p0CoCKjUqaCqbKs8rAis2 K2krnSvRLAUsOSxuLKIs1y0MLUEtdi2rLeEuFi5MLoIuty7uLyQvWi+RL8cv/jA1MGwwpDDbMRIx SjGCMbox8jIqMmMymzLUMw0zRjN/M7gz8TQrNGU0njTYNRM1TTWHNcI1/TY3NnI2rjbpNyQ3YDec N9c4FDhQOIw4yDkFOUI5fzm8Ofk6Njp0OrI67zstO2s7qjvoPCc8ZTykPOM9Ij1hPaE94D4gPmA+ oD7gPyE/YT+iP+JAI0BkQKZA50EpQWpBrEHuQjBCckK1QvdDOkN9Q8BEA0RHRIpEzkUSRVVFmkXe RiJGZ0arRvBHNUd7R8BIBUhLSJFI10kdSWNJqUnwSjdKfUrESwxLU0uaS+JMKkxyTLpNAk1KTZNN 3E4lTm5Ot08AT0lPk0/dUCdQcVC7UQZRUFGbUeZSMVJ8UsdTE1NfU6pT9lRCVI9U21UoVXVVwlYP VlxWqVb3V0RXklfgWC9YfVjLWRpZaVm4WgdaVlqmWvVbRVuVW+VcNVyGXNZdJ114XcleGl5sXr1f D19hX7NgBWBXYKpg/GFPYaJh9WJJYpxi8GNDY5dj62RAZJRk6WU9ZZJl52Y9ZpJm6Gc9Z5Nn6Wg/ aJZo7GlDaZpp8WpIap9q92tPa6dr/2xXbK9tCG1gbbluEm5rbsRvHm94b9FwK3CGcOBxOnGVcfBy S3KmcwFzXXO4dBR0cHTMdSh1hXXhdj52m3b4d1Z3s3gReG54zHkqeYl553pGeqV7BHtje8J8IXyB fOF9QX2hfgF+Yn7CfyN/hH/lgEeAqIEKgWuBzYIwgpKC9INXg7qEHYSAhOOFR4Wrhg6GcobXhzuH n4gEiGmIzokziZmJ/opkisqLMIuWi/yMY4zKjTGNmI3/jmaOzo82j56QBpBukNaRP5GokhGSepLj k02TtpQglIqU9JVflcmWNJaflwqXdZfgmEyYuJkkmZCZ/JpomtWbQpuvnByciZz3nWSd0p5Anq6f HZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+CoUqjEqTepqaocqo+rAqt1 q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUTtYq2AbZ5tvC3aLfguFm4 0blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NYw9TEUcTOxUvFyMZG xsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC60TzRvtI/0sHTRNPG1EnU y9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A24L3hROHM4lPi2+Nj 4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/8ozz GfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t////4QCMRXhpZgAA TU0AKgAAAAgABQESAAMAAAABAAEAAAEaAAUAAAABAAAASgEbAAUAAAABAAAAUgEoAAMAAAABAAIA AIdpAAQAAAABAAAAWgAAAAAAAABIAAAAAQAAAEgAAAABAAOgAQADAAAAAQABAACgAgAEAAAAAQAA AJagAwAEAAAAAQAAAEQAAAAA/9sAQwABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB/9sAQwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB/8AAEQgARACWAwEiAAIR AQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAAB fQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5 OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeo qaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMB AQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYS QVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNU VVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5 usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A/v4ooooA KK+T/wBrX9ub9kr9hbwH/wALH/aw+PHgD4LeGp47s6OninVTJ4k8VXNlaz3k+neC/BmlxX/i7xnq ogtpWXTfDWi6ndtj/Viv58Pil/weC/8ABNXwNry6R4O+FH7YPxZsMTlvEvh/4WeEvBejsIfJ2tb2 /wAVviD4H12bzzK/lI2kxSgQsZY4y0e8bS3f3jSlLZN+ib3P6v6K/nn/AGYP+Dn3/gkv+0hd6Lo2 t/GDxV+zN4h1uEPBZ/tQeDZ/hr4chuhFFJLYXfxPtL3xB8KrK6iMpQLfeM7VLjypZbZ5oUMlf0Fa bqenazp9lq2kX9lqul6lawX2nalp11BfWF/ZXUazW15ZXtrJLbXdrcROksFxbyyQyxsro7KQaHdb 7+ZKaklKLUk1dNO6a7prRrzL1FFFAwooooAKKKKACiiigAooooAKKKKACiiigAr8jf8Agsv/AMFT vA//AASr/ZTvvinc2+leJvjb8Q7zUPBH7Pnw71SS6Fj4h8axaTc6rqXifxOLANfwfD/4e6RBJ4i8 XT2my71HZpvhXSpRrviPSkk/XEnAJ9AT+XNf5fH/AAc2/tPab8ev+CxOr/Bfx9d6ovwh/Zj8H+CP gtomnXd1BD4bm8X+JvDejfGPx7rDi2m+0pb6nrPiz4a6DrVxcG2ZpPCGn2xjFgtxNc8uOxSwOCxe NlSrV44TDV8S6OHh7TEVlQpyqOlQp3j7StU5eWnDmjzTaV1e57vC+RVOKeJeH+GqOPy3KqvEGd5X ktPM85xTwWUZdPNMbQwSx+aYxU6zwuX4R1vrGNxCpVXRw9OpUVObjyv8KfG37Q/xx/b2/am1z4z/ ALRnjbxZ8VfGviK01bVfEmqaxdta6pqPh/Q47m503wXoljBcx6V4L8GrqOrx2mleBPDLad4Y060f 7PeDWdTkvdf1D0rwv4P+C3jc2c1r8Gb3R2aFmkl1jwRd6LZWt1GiGezuZZylpeTwSs0AdFurSSaO RElfaRWt4x+FNzo9vpPiH4I6d4W8JeLdEnnkaOPTba0s/Euk3dv5dzo+o3MSHzoXZYbqATl45JYk 2z20nlXUXEaV+0L420LW9L0H4sfDa58MpeXtpptx4itpLqLTbee8mit4r2T7RHc6Z/Z4lk3XDW+v TyW6HISYKSf50z3Psz43jPM+Gq1eM6GD9lHK6OfvLM0wVSlUxTxGInlcakaWZU8VSnhnSqYerOov ZvDyUpWhH/Zjwp8J+BfouVcPwP434DKa2HzbiKnmVXj3MfCKlxzwHxRhcwwmQUsnyrC8d18FXx/B OKyPHYfO6eYYTOMDh8HUjjY5thqlGipYirb8ffAEXnh/xne6K+iWmrxWq3XhGDRNBh0e5SztInfU /Duv3dpcQW/iKw1uANbx293YRwWcjKzLeISlfq3/AMEB/wDgvn8S/wDgn78UfC/7P/x68Sa/44/Y r8e+ItM0vXNE1XUvt7fs8Pq7Q2h+K/w1Go3QfQfBGgyeVqHxV+F+kSHw6fDr6v448GaPousaDrOm eJ/k4EHByGXrkchl65GPvAjkY4bt1r84fiN+zr4r8Ox6x8R9KGn6lZW+qax4hvfCnlNFqGn6FNql 3eGxkcSTWWrQjTJXi1S1iWB1tpbi3iF6keybv8K/EDmljMr4jzOlB1sRgo5VPEONK9arTlQqYaPJ BQhGX1ejUc6jhB4irVnUnKviff8Ak/p7/REVGjw3x34L8D4/Ewy/KOJ6/H2GyhV8c6eX4DG4fNMJ nVV4jE1MRiK1P+18xwiw2FWIrwyjAYKhhMNRyrJZLDf7idhf2Wq2Nnqem3dtf6fqFrb31hfWc0dz Z3tldwpcWt3aXELPFcW1zBJHPBNE7RyxSI6MVYGrdfgl/wAG1P7SfiD9pD/gkp8A28Ya/H4m8XfA vVvHX7OGra2DdGfUdJ+E/iG4034f3N613eX88l83w0u/CEd5O91J9quInuQsayrGv7AftCftH/A7 9lH4Xa18a/2i/iV4d+Enwq8O3mi6frnjnxXLdQaHpd54i1W20TRILua0truWNtS1a8tdPtiYSjXN xFGzKXFf0Mf47b6nttFfHPhr/goH+xr40/aE8K/sqeD/ANoHwH4p/aD8ZeAF+KOj/C7w/dX2r+I4 PAsvh3TvFtprviBbKyls/Cn9oeG9W07WtN03xPdaVq9/p17b3VrYSRyqT4b+0B/wWX/4Jgfsu/FK 7+C3xy/bQ+DPgr4oaTqMGleJPB/9tXfiHU/B9/cW0d3HaeMz4ZsdYtvCd2LaaGea016eyureKeCS 4gjSeJnAP04pGYKrMxCqoLMxIAAAySSSAABySTgdSa4TwD8Ufhx8U/h94d+LHw28d+EvHfwy8W6D B4o8M+P/AAn4g0zXfB+u+HbiA3MWtaZ4h0+5n0y607yVd5LqO4McPlyrMY2ikC/mXqX/AAWi/wCC VvxC8T+J/gH4M/bp/Z98Q/E7V9I8R+HtG0iw8ZwvouueIJdK1G1g0TRPGkkMfgvV9Turlfs9lbWG v3DX9y8VrZG4uZoonAP1tWRHVXRlZGVXV1IKsrAFWVgSrKQQQykg560+v4Rf+CEP7Tf7QfgX/g35 /wCClfxg8M/FfxvffFH4B+OvFx+D+ueLNT1n4ny+AL3w3+zZ8A9XstC0LQPGV5rsSaLZ+J9Q1i5k 8E2cdvpX27UNStLKws2udif12eM/+Cg/7G3wz8TXfg34h/tC+A/DOsaLr+keDfFOrahLqv8Awgng 7xtrMmkWuneD/HXxNtdLn+G3gTxZqF9ruj2ln4a8W+K9G1m4u9X0u1isjPf2scoB9nUV5h8V/jV8 J/gZ4M/4WF8XviF4V+HngxtW0Hw/ba/4o1e206z1LxD4q1G30jwv4c0ZWZrjXPEnibVru10zw54f 0iG+1jXdRuYLLSrO7uZo4287+D37X37OPx517xR4T+F/xQ0vW/GngvRLHxP4p8B6xpPibwR8QtE8 LardX9jpfiu88AePNE8NeMR4T1S+0rUrDTfFEWiSaFqF/YXtlaX81zbTRIAfSdFfmR8Mf+Cpv7Nf j/48fHz4SXXxB8FaTovwt1j4P6H4H8SQ3/iS9vPiFffErwmmualv01/DNvDo39i61c2vhy0hS6vT fSrLeTTWyyxwp+m9ABRRRQA1+Vb/AHT/ACNf5IH/AAcV/Bf4laj/AMFs/wBqrwBo3hPXtb8WfEjx /wCC/G3w90HQtC1zxLr/AI40Txv8C/hXBYSeGPDfhjTdc8Q635GpeCfE2kXkdlpU5jutPkWRRBLH K/8Arg1mNo2kNqQ1h9M09tVVFiXUzY2h1BYwGRY1vjCbsIFdlCibaFYgAAnIHW/VO6fW61T9b6n+ bB/wT2/4Ie/Gr9o3/gnd8Q/ip8Kvixf63+2H8KPjN4g8A+IP2KPjH4Yt/hJc+CdD8PanYxWHhLxV 4m8WaVL8Tvhx8RPF/gbULT4q+D5PFmljwTLpWo6J4VuPDmn28154ktvy8+PGlat+zH8avG37O37R miy/Bv4s+AdWuNM13wp48utPtLOaBHzp+v8Ah/xDLJFonijwl4htGi1Twz4o0x1sdZ0yaOQxWOpQ ajpOm/61Ol/Br4U6J8U/FHxv0b4e+EtK+L3jfwvoXgrxl8R9O0SysvGHizwr4Yurq88N6H4l1u3j ju9dsfD9xfXraKmpvcvpa3l1FZPDDcTI+H8UvgF8IfivNa+IfGnwh+D3j7xx4c0++j8D+Ivid8N/ DvjiTw5qEkTyWTQzalaHVodNS/EM97ZaZqVhLcRq6wXFvMyzL+fcQ+GXC3EVWeKq4arl2OnJznjc sqQw86s27uVejOnVw1SUpNynU9jGvOTvKsz+v/B36cPj34OYHDZFgM8wHGXCmFpwoYfhrjnC184w 2Cw0EoxoZZmWHxmAzrBUqdOMKWGwrzGvlmFpQjCjl6Wh/kan4kfDMIX/AOFnfDLYozgfELwaW2hc /LCNa804HARYy5PyqhOBXzx8af2j/CFl4a1vw34K1EeIvEOr2N1pX23T45H0zSReRNbzzG7ePy72 /WKR0trG2E2Lhla7aKNWr/UD/bRvvCX7KH7FPxY8efFb9nb9l7xH+1V49ufEXw+/Zg+Hf7O/wjGp eIvjJ+0b4s8Can4b+Fll4M0zXfCGreLJPHWorY6p4r8Qm103XLb4a/D3RdaudS17xHonhTVPEt7/ ACA/Av8A4M7v26/iP8M/CnxG+Ifxg/Z5+BPjfV/D/h3VdP8Ahr4m0/4j+LPGHhN10TTGtLXxvceH Lmw8IaV4vtLhHn1zQ9Li8YaPYaqJbV9c1+IzXEvz2VeC/DuXY/D42tjsxzBYarCvDDV3h6dGdSnO M6ftvZUVOpBSV5QU4Rnop80HKMv2Ljz9pn4ycY8KZxwxlvC3BfCU87wGJyzFZ3lcc4xmZ4fB42hU w+L/ALO+v5jUwuExNWlUlThiZ4fE1MPGUp4d0sRGliKf9GH/AAaOfD/VPBv/AASkutdvWDad8R/2 pPjz4p8OOs808Uuj6JqWjfDuWeEyfu/KfW/BerIrwErKUaR/3pevbv8Ag6NtoLz/AII1/tAWl1GJ ba6+Jn7LdtcRHBEsE/7SXwzimjIYMpDxsykMGXnkGv0z/Yp+EvhP9j74W/CX9hT4eeEfFH/CCfs7 fBbwf4b0r4k6nDYR2vjLU9PtreLxBrGpx6fZWNtH4g8T61dX/iTULi2iS2vNRvtRWG2thbMi+af8 Fcf2GvGn/BRj9hz4jfsp+APHXhX4ceJ/Gvi34R+JLHxZ4z0zWNZ8PWCfDX4oeFviFc297pugz2uq XP8AaUPh1tOiW2urUpJciRriILur9i/H11fzfU/zeSSSSSSWiSVkl0SS0SXRI/Ej9iP9lP4E/sM/ 8EK7z/gp58L/AIeaX4s/b0vf+Cc/xA/acuv2nPiI194t+Kx8beMfgbfeIbfR7bxNfXMl9p3gnwnp 40rw/pPhzT3trFtI0G0uL0TajJdX8v5T/wDBGbxj+0t4P/4J96hpvgT/AIIPf8PDvDn7SfiX4w3v xp/ap8XfG/4O215+0Tc3njbxX4T1nTte0b4iad4k8U2Nn4bt7S68KX1pf6lG+q67a654smtodY12 /ubj+2/9kL9lCL4DfsG/AP8AYv8Aild+HviVafDL9m3wZ+z748u7Oyu4fDPjjT9C8EQeCvEDxafq GLyLSdfskuAbW6PnpBcmN2LLuP4UfCP/AIItf8FRP+Ce/iTxx4L/AOCXX/BSj4d+BP2TPFfiO98R eGvgB+0n8F5fiGPhteaqbE3c2j67bTaiuo38cVktlPqek2/g+LxFAF1bxZo2veNrjVvGGqAH4g69 4I/4KDf8E6/+Den/AIKP/CD41/CD4p/ADwz8RP2tvh1ofwe8A+MvFug+LtW074C/tAa5oMHxb+G2 j694d8S+LpBouttpmoeEdc1H7Ta6tr1z4y13X/sVjq+vXjxf0TfsVf8ABJD/AIJ2eIv+CM/wt8B+ JvgP8GviZD8cv2TPDPxP+I3xjk8LaPJ428VeO/G/wyt/Fk3j7w548CyeIvCyeHdRntv+FdWfh/V7 LTPA2h6NoujaDBa6dp0UI+3IP+CfHxd/aS/4J7/Ff9jP/gpj+0Np37S3jn4wal4pv9T+Mfwz+Huk /CmfwEbnXLLxT8Mpfh/opXUrCHV/g34k0+w1Hwjrl/Y+ZfjTbFdds7+Y39xf/kr+zj/wRK/4K3/C j4Yf8MQeL/8AgrLoif8ABPtlfw/qWifDD4STaB8e5/hjqB1AeJvhp4C8XeIZ9bu/hFofi5L65iuo tK8XeI7LwdZ38uk+BLTSNEtbPS4gD8mf+CMouZ/+DaT/AILJG3uLjTL+/wDEfxKlTULYul3aahqf 7JH7O0zatatG9u0Vyt3ctqNqYZIBDMYzBJEqIy/3o6R8EfhTbfBRPgIPAnhuf4QXvgW68A6n4Bvd LtL/AMOax4U1vSJtN13S9b029int9aTX4L29fXptUS7uNaur69vNUlurm7uJZPwN/Yy/4Ia/FP8A ZQ/4Jp/8FBv2B4/jN8M9avP2tfGvjzXvhd4qg0bxnNofw88P+Jvh14F+HWg6L4wt7y6g1rX5tB03 wPZS3NxpV1ZtqBlkSOWzLK0X9JdtE0MEMTEFo4ooyRnBKRqhIzzglSRnnHWgD8df2Sv2jdC/Z2/4 J3fsD+F/Fdj8TP2gPi54w8Oaf8CPgR4F0S20rxL8XPjB4q+Fnh/xqlvdXmu+I9Q8PeEPDv8AYfw1 +Hep+IvHfxL8c+IvCvhPRra0nN7rA1bWdG0nVPO/j94z/afl/wCCgf8AwSY8Y/Eb4CfB/wCDWkeI v2gP2hvg9L4r8NfHO9+KPxZ1Pwd4t/Y3+O/xG1T4XeItFHwS8JeHtN8Fa74n+EXgfx5rM+i/ErXR b+L/AIc+DYY9L1CEnV7T2u3/AGEPjp4A+Gf7EGs/Cf4kfDWP9oL9i3WfiiRY+LtL8RSfB74yeAPj JY+IdJ8ffDrWb+xhuPGHgK7uEuvCPiXwz8QdG0rX7/w74l8IRWl94c8R+GNa1rSb3e8WfsoftXfH j9pD9jP9pL4zfEn4VeCNO/ZR+MPjjx5afs8/DNPE3ivwdq+mePPgL8U/hDqPibWPih4l0Lwx4m8U fE7SLnx1p8fhSO38KeDvAmgeErrx7p+qaR4t8Sa54a8S+EgDuv2Zif8Ahu//AIKYZJP/ABP/ANkb v0z+z3aZ+me/+TX6JV+fmqfA/wDaa+Gv7W/xK+OnwJvfgl4t+Gv7RWg/A7R/i34H+KeqeM/BXijw H4m+EQ8U+H9Q+I/gHxF4R8LeNLTxz/wlvw+1vQNCl8BeJLLwhBpOteCtN1W18Xva6/qtpZ/V3hb/ AIW5/wALF8fHxafDH/CtnXTB8Po9LhkXXImjjC6idWuHupTcm4ctJKJLWzW1lWOGzN1C7ygA9Voo ooAKKKKACiiigDgtY+F3w+8QePvCHxS1zwlo2sfED4f6X4j0fwN4p1O2+3an4PsfF6WUPin/AIRl rl5INEvPENrp9nYavqenQ2+p3+mQLplxePp5a2bvaKKADHOefzP8ulFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB/9k= ------=_Part_9372915_292966117.1423648670110-- ------=_Part_9372914_326988970.1423648670110--

4 6

oVirt 3.6.0 release schedule update
by Sandro Bonazzola 19 Feb '15

19 Feb '15

Hi, here is the proposed schedule for oVirt 3.6.0. These are tentative planning dates and may change: 2015-04-22 - Feature Submission Closed 2015-05-06 - Alpha Release 2015-05-12 - Alpha Release Test Day 2015-06-16 - Feature freeze - Stable branch 2015-07-15 - Beta Release 2015-07-20 - Beta Release Test Day 2015-08-03 - String Freeze 2015-08-19 - Release Candidate 2015-08-24 - Release Candidate Test Day 2015-09-16 - Release Release management page has been updated accordingly: http://www.ovirt.org/OVirt_3.6_Release_Management oVirt Google Calendar has been updated accordingly: ICAL: https://www.google.com/calendar/ical/ppqtk46u9cglj7l987ruo2l0f8%40group.cal… XML: https://www.google.com/calendar/feeds/ppqtk46u9cglj7l987ruo2l0f8%40group.ca… HTML: https://www.google.com/calendar/embed?src=ppqtk46u9cglj7l987ruo2l0f8%40grou… Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 2

SELinux is preventing /usr/sbin/glusterfsd from write access on the sock_file
by Nathanaël Blanchet 19 Feb '15

19 Feb '15

On freshly installed el7 hosts, selinux prevents gluster from running. Setting selinux to permissive or building the relative .pp module resolves the issue. Does otopi configure selinux for gluster when installing?

2 1

Ovirt 3.5.1, Windows 2008 hangs
by wodel youchi 19 Feb '15

19 Feb '15

------=_Part_3325810_102070030.1423671665987 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, I've a two nodes hosted-engine ovirt 3.5used storage is NFS4 for the: engine, vms, iso and export I have many Linux VMs and one Windows 2008 VM. The windows 2008 VMs is acting as a second AD, it's the second time in a month where the VM hangs and the cpu usage is 100%.I have this problem only with this VM only. I tried to look into vdsm logs, but no luck so far, all I found isGuestMonitor-Win2k8x64-AD2::DEBUG::2015-02-11 12:01:02,158::vm::486::vm.Vm::(_getUserCpuTuneInfo) vmId=`ce0bcb92-90e8-45a7-9b9f-cfed10e920d6`::Domain Metadata is not set Is there a log file where I can follow the behaviour of the VM, because for now I have no clue about what is causing this problem. any advice? PS: is there a good solution to gather and analyze all the logs from ovirt's hypervisors and engine, storage...etc? thanks in advance. ------=_Part_3325810_102070030.1423671665987 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:He= lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;fo= nt-size:16px"><div id=3D"yui_3_16_0_1_1423652121743_87447">Hi,</div><div id= =3D"yui_3_16_0_1_1423652121743_87448"> </div><div id=3D"yui_3_16_0_1_142= 3652121743_82672" dir=3D"ltr">I've a two nodes hosted-engine ovirt 3.5</div= ><div id=3D"yui_3_16_0_1_1423652121743_82673" dir=3D"ltr">used storage is N= FS4 for the: engine, vms, iso and export</div><div id=3D"yui_3_16_0_1_14236= 52121743_87449" dir=3D"ltr"> </div><div id=3D"yui_3_16_0_1_1423652121743= _87446" dir=3D"ltr">I have many Linux VMs and one Windows 2008 VM. </div= ><div id=3D"yui_3_16_0_1_1423652121743_87445" dir=3D"ltr">The windows 2008 = VMs is acting as a second AD, it's the second time in a month where the VM = hangs and the cpu usage is 100%.</div><div dir=3D"ltr">I have this problem = only with this VM only. </div><div id=3D"yui_3_16_0_1_1423652121743_8744= 4" dir=3D"ltr"> </div><div id=3D"yui_3_16_0_1_1423652121743_87443" dir= =3D"ltr">I tried to look into vdsm logs, but no luck so far, all I found is= </div><div dir=3D"ltr">GuestMonitor-Win2k8x64-AD2::DEBUG::2015-02-11 12:01:= 02,158::vm::486::vm.Vm::(_getUserCpuTuneInfo) vmId=3D`ce0bcb92-90e8-45a7-9b= 9f-cfed10e920d6`::Domain Metadata is not set </div><div dir=3D"ltr"> = </div><div dir=3D"ltr">Is there a log file where I can follow the behaviour= of the VM, because for now I have no clue about what is causing this probl= em.</div><div id=3D"yui_3_16_0_1_1423652121743_87455" dir=3D"ltr"> </div= ><div id=3D"yui_3_16_0_1_1423652121743_87466" dir=3D"ltr">any advice?</div>= <div id=3D"yui_3_16_0_1_1423652121743_87454" dir=3D"ltr"> </div><div id= =3D"yui_3_16_0_1_1423652121743_87467" dir=3D"ltr">PS: is there a good solut= ion to gather and analyze all the logs from ovirt's hypervisors and engine,= storage...etc? </div><div id=3D"yui_3_16_0_1_1423652121743_87451" dir= =3D"ltr"> </div><div id=3D"yui_3_16_0_1_1423652121743_87450" dir=3D"ltr"= >thanks in advance.</div><div id=3D"yui_3_16_0_1_1423652121743_82653"> <= /div></div></body></html> ------=_Part_3325810_102070030.1423671665987--

4 6

messages from journal in centos7 hosts
by Vadq 19 Feb '15

19 Feb '15

Hi, ovirt 3.5.1, engine on centos7 + storage type iscsi( using LIO™ on one of the vdsm host) + four hosts on centos7 After installation of vdsm at all cenos7 hosts in cluster in /var/log/messages every few seconds have such record Feb 19 16:47:08 kvm05 journal: metadata not found: Requested metadata element is not present Feb 19 16:47:19 kvm05 journal: metadata not found: Requested metadata element is not present Feb 19 16:47:23 kvm05 journal: metadata not found: Requested metadata element is not present Feb 19 16:47:34 kvm05 journal: metadata not found: Requested metadata element is not present Feb 19 16:47:38 kvm05 journal: metadata not found: Requested metadata element is not present is it possible to fix this without disabling systemd-journald? -- Thanks, Vadim

1 0

RHEV 3.5 problem with connecting rhev-m to nodes
by Jakub Bittner 19 Feb '15

19 Feb '15

Hello, after restart we had problem with manager to connect to nodes. All nodes are down and not reachable. When I try to remove and readd to engine it fails too. 10 days ago we changed SSL certs of rhev-m apache to IPA's generated. We have this in logs: 2015-02-19 11:41:33,491 ERROR [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-30) Failure to refresh Vds runtime info: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: java.io.EOFException: SSL peer shut down incorrectly at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.createNetworkException(VdsBrokerCommand.java:126) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:101) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:56) [vdsbroker.jar:] at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:31) [dal.jar:] at org.ovirt.engine.core.vdsbroker.VdsManager.refreshCapabilities(VdsManager.java:571) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo.refreshVdsRunTimeInfo(VdsUpdateRunTimeInfo.java:648) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo.refresh(VdsUpdateRunTimeInfo.java:494) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.VdsManager.onTimer(VdsManager.java:236) [vdsbroker.jar:] at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) [:1.7.0_75] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_75] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_75] at org.ovirt.engine.core.utils.timer.JobWrapper.execute(JobWrapper.java:60) [scheduler.jar:] at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz.jar:] at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557) [quartz.jar:] Caused by: java.io.EOFException: SSL peer shut down incorrectly at sun.security.ssl.InputRecord.read(InputRecord.java:482) [jsse.jar:1.7.0_75] at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934) [jsse.jar:1.7.0_75] at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332) [jsse.jar:1.7.0_75] at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:709) [jsse.jar:1.7.0_75] at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122) [jsse.jar:1.7.0_75] at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) [rt.jar:1.7.0_75] at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) [rt.jar:1.7.0_75] at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) [rt.jar:1.7.0_75] at java.io.FilterOutputStream.flush(FilterOutputStream.java:140) [rt.jar:1.7.0_75] at org.apache.xmlrpc.client.XmlRpcCommonsTransport$1$1.close(XmlRpcCommonsTransport.java:204) [xmlrpc-client.jar:3.1.3] at org.apache.xmlrpc.client.XmlRpcHttpTransport$ByteArrayReqWriter.write(XmlRpcHttpTransport.java:55) [xmlrpc-client.jar:3.1.3] at org.apache.xmlrpc.client.XmlRpcCommonsTransport$1.writeRequest(XmlRpcCommonsTransport.java:214) [xmlrpc-client.jar:3.1.3] at org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:499) [commons-httpclient.jar:] at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2114) [commons-httpclient.jar:] at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096) [commons-httpclient.jar:] at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398) [commons-httpclient.jar:] at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171) [commons-httpclient.jar:] at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397) [commons-httpclient.jar:] at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323) [commons-httpclient.jar:] at org.apache.xmlrpc.client.XmlRpcCommonsTransport.writeRequest(XmlRpcCommonsTransport.java:227) [xmlrpc-client.jar:3.1.3] at org.apache.xmlrpc.client.XmlRpcStreamTransport.sendRequest(XmlRpcStreamTransport.java:151) [xmlrpc-client.jar:3.1.3] at org.apache.xmlrpc.client.XmlRpcHttpTransport.sendRequest(XmlRpcHttpTransport.java:143) [xmlrpc-client.jar:3.1.3] at org.apache.xmlrpc.client.XmlRpcClientWorker.execute(XmlRpcClientWorker.java:56) [xmlrpc-client.jar:3.1.3] at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:167) [xmlrpc-client.jar:3.1.3] at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:137) [xmlrpc-client.jar:3.1.3] at org.apache.xmlrpc.client.XmlRpcClient.execute(XmlRpcClient.java:126) [xmlrpc-client.jar:3.1.3] at org.apache.xmlrpc.client.util.ClientFactory$1.invoke(ClientFactory.java:140) [xmlrpc-client.jar:3.1.3] at com.sun.proxy.$Proxy97.getVdsCapabilities(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_75] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_75] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_75] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_75] at org.ovirt.engine.core.vdsbroker.xmlrpc.XmlRpcUtils$AsyncProxy$InternalCallable.call(XmlRpcUtils.java:255) [vdsbroker.jar:] at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_75] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_75] at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_75] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75] 2015-02-19 11:41:33,506 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-30) Failed to refresh VDS , vds = 3c9f5126-8c0e-4037-ab61-29de6d02d487 : nodep01.example.com, VDS Network Error, continuing.

3 3

movirt -> ovirt 3.5.1 -> server error 500
by Markus Stockhausen 19 Feb '15

19 Feb '15

This is a multi-part message in MIME format. ------=_NextPartTM-000-01931aef-0e79-4067-9583-6cee81c33885 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=0A= =0A= just installed movirt on my mobile. Upon connection it breaks with the atta= ched error in the 3.5.1 engine server logs. =0A= =0A= Something I'm missing?=0A= =0A= Markus=0A= =0A= 2015-02-19 12:21:19,757 ERROR [org.apache.catalina.core.ContainerBase.[jbos= s.web].[default-host].[/ovirt-engine/api]] (ajp--127.0.0.1-8702-11) Standar= dWrapper.Throwable: java.lang.RuntimeException: java.lang.RuntimeException:= Unable to instantiate MessageBodyWriter=0A= at org.jboss.resteasy.plugins.providers.RegisterBuiltin.register(Re= gisterBuiltin.java:35) [resteasy-jaxrs-2.3.2.Final.jar:]=0A= at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployme= nt.java:211) [resteasy-jaxrs-2.3.2.Final.jar:]=0A= at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispat= cher.init(ServletContainerDispatcher.java:67) [resteasy-jaxrs-2.3.2.Final.j= ar:]=0A= at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.= init(HttpServletDispatcher.java:36) [resteasy-jaxrs-2.3.2.Final.jar:]=0A= at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWra= pper.java:1202) [jbossweb-7.0.13.Final.jar:]=0A= at org.apache.catalina.core.StandardWrapper.allocate(StandardWrappe= r.java:952) [jbossweb-7.0.13.Final.jar:]=0A= at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWra= pperValve.java:188) [jbossweb-7.0.13.Final.jar:]=0A= at org.apache.catalina.core.StandardContextValve.invoke(StandardCon= textValve.java:161) [jbossweb-7.0.13.Final.jar:]=0A= at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authe= nticatorBase.java:489) [jbossweb-7.0.13.Final.jar:]=0A= at org.jboss.as.web.security.SecurityContextAssociationValve.invoke= (SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.= 1.1.Final]=0A= at org.apache.catalina.core.StandardHostValve.invoke(StandardHostVa= lve.java:155) [jbossweb-7.0.13.Final.jar:]=0A= at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportVa= lve.java:102) [jbossweb-7.0.13.Final.jar:]=0A= at org.jboss.web.rewrite.RewriteValve.invoke(RewriteValve.java:466)= [jbossweb-7.0.13.Final.jar:]=0A= at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngi= neValve.java:109) [jbossweb-7.0.13.Final.jar:]=0A= at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapte= r.java:368) [jbossweb-7.0.13.Final.jar:]=0A= at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505= ) [jbossweb-7.0.13.Final.jar:]=0A= at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(A= jpProtocol.java:445) [jbossweb-7.0.13.Final.jar:]=0A= at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.ja= va:930) [jbossweb-7.0.13.Final.jar:]=0A= at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55]=0A= Caused by: java.lang.RuntimeException: Unable to instantiate MessageBodyWri= ter=0A= at org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(= ResteasyProviderFactory.java:772) [resteasy-jaxrs-2.3.2.Final.jar:]=0A= at org.jboss.resteasy.plugins.providers.RegisterBuiltin.registerPro= viders(RegisterBuiltin.java:70) [resteasy-jaxrs-2.3.2.Final.jar:]=0A= at org.jboss.resteasy.plugins.providers.RegisterBuiltin.register(Re= gisterBuiltin.java:31) [resteasy-jaxrs-2.3.2.Final.jar:]=0A= ... 18 more=0A= Caused by: java.lang.RuntimeException: Failed to construct public org.ovirt= .engine.api.pdf.FOPMessageBodyWriter()=0A= at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(Constr= uctorInjectorImpl.java:144) [resteasy-jaxrs-2.3.2.Final.jar:]=0A= at org.jboss.resteasy.spi.ResteasyProviderFactory.getProviderInstan= ce(ResteasyProviderFactory.java:1039) [resteasy-jaxrs-2.3.2.Final.jar:]=0A= at org.jboss.resteasy.spi.ResteasyProviderFactory.addMessageBodyWri= ter(ResteasyProviderFactory.java:519) [resteasy-jaxrs-2.3.2.Final.jar:]=0A= at org.jboss.resteasy.spi.ResteasyProviderFactory.registerProvider(= ResteasyProviderFactory.java:768) [resteasy-jaxrs-2.3.2.Final.jar:]=0A= ... 20 more=0A= Caused by: java.lang.NoClassDefFoundError: org/apache/fop/apps/FopFactory= =0A= ------=_NextPartTM-000-01931aef-0e79-4067-9583-6cee81c33885 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" **************************************************************************** Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Über das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 **************************************************************************** ------=_NextPartTM-000-01931aef-0e79-4067-9583-6cee81c33885--

3 4

Poor iSCSI Performance
by John Florian 19 Feb '15

19 Feb '15

This is a multi-part message in MIME format. --------------070002020309040609070902 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi all, I've been trying to resolve a storage performance issue but have had no luck in identifying the exact cause. I have my storage domain on iSCSI and I can get the expected performance (limited by the Gbit Ethernet) when running bonnie++ on: * a regular physical machine configured with the iSCSI initiator connected to a dedicated iSCSI test target -- thus oVirt and VM technology are completely out of the picture * my oVirt host with the initiator connected to that same dedicated target -- thus I have an iSCSI connection on the oVirt host but I'm not using the iSCSI connection provided by oVirt's storage domain * a VM (hosted by oVirt) with the initiator (inside the VM) connected to that target -- thus bypassing oVirt's storage domain and the virtual disk it provides this VM However, if I just use a regular virtual disk via oVirt's storage domain the performance is much worse. I've tried both VirtIO and VirtIO-SCSI and have found no appreciable difference. Here's a typical example of the poor performance I get (as tested with bonnie++) with the normal virtual disk setup: # bonnie++ -d . -r 2048 -u root:root <snip> Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP narvi-f21.double 4G 806 91 18507 1 15675 1 3174 56 33175 1 176.4 3 Latency 15533us 8142ms 2440ms 262ms 1289ms 780ms Version 1.96 ------Sequential Create------ --------Random Create-------- narvi-f21.doubledog -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 13641 24 +++++ +++ 22702 17 18919 31 +++++ +++ +++++ +++ Latency 27724us 247us 292us 71us 30us 172us For comparison, here's what I see if I run the same test, same VM, same host but this time the file system is mounted from a device obtained using iscsi-initiator-utils within the VM, i.e., the 3rd bullet config above: bonnie++ -d . -r 2048 -u root:root <snip> Version 1.96 ------Sequential Output------ --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP narvi-f21.double 4G 2051 89 103877 4 36286 3 4803 88 88166 4 163.6 3 Latency 7724us 191ms 396ms 48734us 73004us 1645ms Version 1.96 ------Sequential Create------ --------Random Create-------- narvi-f21.doubledog -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 16 6531 18 +++++ +++ 16388 20 5924 15 +++++ +++ 17906 23 Latency 15623us 64us 92us 1281us 14us 256us My host is Fedora 20 running oVirt 3.5 (hosted-engine). VM is running Fedora Server 21. Tonight I tried updating the host with the Fedora virt preview repo and I didn't see any significant change in the performance. Where should I look next? --------------070002020309040609070902 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 all, I've been trying to resolve a storage performance issue but have had no luck in identifying the exact cause. I have my storage domain on iSCSI and I can get the expected performance (limited by the Gbit Ethernet) when running bonnie++ on: <ul> <li>a regular physical machine configured with the iSCSI initiator connected to a dedicated iSCSI test target -- thus oVirt and VM technology are completely out of the picture </li> <li>my oVirt host with the initiator connected to that same dedicated target -- thus I have an iSCSI connection on the oVirt host but I'm not using the iSCSI connection provided by oVirt's storage domain </li> <li>a VM (hosted by oVirt) with the initiator (inside the VM) connected to that target -- thus bypassing oVirt's storage domain and the virtual disk it provides this VM</li> </ul> However, if I just use a regular virtual disk via oVirt's storage domain the performance is much worse. I've tried both VirtIO and VirtIO-SCSI and have found no appreciable difference. Here's a typical example of the poor performance I get (as tested with bonnie++) with the normal virtual disk setup: <tt># bonnie++ -d . -r 2048 -u root:root <snip> Version 1.96 ------Sequential Output------ --Sequential Input- --Random-</tt><tt> </tt><tt>Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--</tt><tt> </tt><tt>Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP</tt><tt> </tt><tt>narvi-f21.double 4G 806 91 18507 1 15675 1 3174 56 33175 1 176.4 3</tt><tt> </tt><tt>Latency 15533us 8142ms 2440ms 262ms 1289ms 780ms</tt><tt> </tt><tt>Version 1.96 ------Sequential Create------ --------Random Create--------</tt><tt> </tt><tt>narvi-f21.doubledog -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--</tt><tt> </tt><tt> files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP</tt><tt> </tt><tt> 16 13641 24 +++++ +++ 22702 17 18919 31 +++++ +++ +++++ +++</tt><tt> </tt><tt>Latency 27724us 247us 292us 71us 30us 172us</tt> For comparison, here's what I see if I run the same test, same VM, same host but this time the file system is mounted from a device obtained using iscsi-initiator-utils within the VM, i.e., the 3rd bullet config above: <tt>bonnie++ -d . -r 2048 -u root:root</tt><tt> </tt><tt><snip></tt><tt> </tt><tt>Version 1.96 ------Sequential Output------ --Sequential Input- --Random-</tt><tt> </tt><tt>Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--</tt><tt> </tt><tt>Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP</tt><tt> </tt><tt>narvi-f21.double 4G 2051 89 103877 4 36286 3 4803 88 88166 4 163.6 3</tt><tt> </tt><tt>Latency 7724us 191ms 396ms 48734us 73004us 1645ms</tt><tt> </tt><tt>Version 1.96 ------Sequential Create------ --------Random Create--------</tt><tt> </tt><tt>narvi-f21.doubledog -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--</tt><tt> </tt><tt> files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP</tt><tt> </tt><tt> 16 6531 18 +++++ +++ 16388 20 5924 15 +++++ +++ 17906 23</tt><tt> </tt><tt>Latency 15623us 64us 92us 1281us 14us 256us</tt> My host is Fedora 20 running oVirt 3.5 (hosted-engine). VM is running Fedora Server 21. Tonight I tried updating the host with the Fedora virt preview repo and I didn't see any significant change in the performance. Where should I look next? </body> </html> --------------070002020309040609070902--

2 1

How long do your migrations last?
by Nicolas Ecarnot 19 Feb '15

19 Feb '15

Hello list, Our storage domains are iSCSI on dedicated network, and when migrating VMs, the duration varies according to the size of the vDisks. The smallest VMs are migrated in about 20 seconds, while the biggest one may take more than 5 or 10 minutes. The average duration is 90 seconds. Questions : 1- Though I may have understood that the task of migration was made by the SPM, I don't know what it actually does? (which bytes goes where) 2- Do our times sound OK, or does it look like improvable? 3- What bottleneck should I investigate? I'm thinking about the dedicated hardware NICs setup of the hosts, the SAN, the MTU has already been setup at 9000... Any ideas welcomed. -- Nicolas Ecarnot

4 3

Where do you run oVirt?
by Sandro Bonazzola 18 Feb '15

18 Feb '15

Hi, As we continue developing oVirt 3.6 and future releases of oVirt, the development and integration team are seeking input from users on how oVirt is being run and on what platforms. We would appreciate you help by taking this quick survey! https://docs.google.com/forms/d/1u-YccuNRza4_WmS5VMdy0mEkXuKxt4lzrALKKcnEMB… Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 2

Re: [ovirt-users] ovirt and glusterfs setup
by Donny D 18 Feb '15

18 Feb '15

----_com.android.email_82515713991120 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CiAgICAKSSBkaWQgbm90IGhhdmUgYSBnb29kIGV4cGVyaWVuY2UgcHV0dGluZyBib3RoIGdsdXN0 ZXIgYW5kIHZpcnQgb24gdGhlIHNhbWUgbm9kZS4gSSB3YXMgZG9pbmcgaG9zdGVkIGVuZ2luZSB3 aXRoIHJlcGxpY2F0ZSBhY3Jvc3MgdHdvIG5vZGVzLCBhbmQgb25lIGRheSBpdCB3ZW50IGludG8g c3BsaXQgYnJhaW4gaGVsbC4uLiBpIHdhcyBuZXZlciBhYmxlIHRvIHRyYWNrIGRvd24gd2h5LiBI b3dldmVyIGkgZG8gaGF2ZSBhIGdsdXN0ZXIgd2l0aCBkaXN0cmlidXRlIGFuZCByZXBsaWNhIHNl dHVwIG9uIGl0cyBvd24gd2l0aCBhIGNvdXBsZSBub2RlcywgYW5kIGl0IGhhcyBnaXZlbiBtZSB6 ZXJvIHByb2JsZW1zIGluIHRoZSBsYXN0IDYwIGRheXMuIEl0IHNlZW1zIHRvIG1lIHRoYXQgZ2x1 c3RlciBhbmQgdmlydCBuZWVkIHRvIHN0YXkgc2VwZXJhdGUgZm9yIG5vdy4gQm90aCBhcmUgZ3Jl YXQgcHJvZHVjdHMgYW5kIGJvdGggd29yayBhcyBkZXNjcmliZWQsIGp1c3Qgbm90IG9uIHRoZSBz YW1lIG5vZGUgYXQgdGhlIHNhbWUgdGltZS4KCgpIYXBweSBDb25uZWN0aW5nLiBTZW50IGZyb20g bXkgU3ByaW50IFNhbXN1bmcgR2FsYXh5IFPCriA1CgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdl IC0tLS0tLS0tCkZyb206IEdlb3JnZSBTa29ydXAgPGdlb3JnZUBtd2NvbW0uY29tPiAKRGF0ZTog MDIvMTgvMjAxNSAgMTI6NTAgUE0gIChHTVQtMDc6MDApIApUbzogdXNlcnNAb3ZpcnQub3JnIApT dWJqZWN0OiBSZTogW292aXJ0LXVzZXJzXSBvdmlydCBhbmQgZ2x1c3RlcmZzIHNldHVwIAoKCiAg ICBCaWxsLAoKICAgIAoKICAgIEkgaGF2ZSBkb25lIGV4YWN0bHkgd2hhdCB5b3UncmUgbG9va2lu ZyB0byBkby4gSSB3YXMgdHJ5aW5nIHRvIG1pbWljCiAgICB2U0FOIGFzIHdlbGwuIFRoZXkgaGFk IFZTQSBmb3IgYSB3aGlsZSB3aGljaCB3YXMgYWNjZXB0YWJsZQogICAgbGljZW5zaW5nIGNvc3Rz LCBidXQgdGhhdCB3YXMgcmVwbGFjZWQgd2l0aCB2U0FOIHdoaWNoIGlzCiAgICByaWRpY3Vsb3Vz bHkgZXhwZW5zaXZlIGZvciBhbiBleHRyYS1zbWFsbCBidXNpbmVzcy4KCiAgICAKCiAgICBJIGhh dmUgYSBmb3VyIG5vZGUgY2x1c3RlciB3aXRoIDFUQiBvZiBzdG9yYWdlIGVhY2guIEdsdXN0ZXIg aXMKICAgIGNvbmZpZ3VyZWQgd2l0aCByZXBsaWNhIDQuIFNvIGJhc2ljYWxseSBJIGhhdmUgMVRC IG9mIHVzYWJsZQogICAgc3RvcmFnZSwgd2hpY2ggaXMgZmluZSBmb3IgbXkgbmVlZHMuIFZNIG1p Z3JhdGlvbiwgR2x1c3RlcgogICAgcmVwbGljYXRpb24sIGhvc3RlZCBlbmdpbmUgYW5kIGFsbCB0 aGF0IHdvcmtzIGZpbmUuIFBlcmZvcm1hbmNlIGlzCiAgICBnZW5lcmFsbHkgZmluZSwgZXZlbiB3 aXRoIG9ubHkgZHVhbCBMQUNQIGJvbmRlZCAxR2JFIE5JQ3MgaW4gZWFjaAogICAgbm9kZS4gSSBj YW4gZG8gd2hhdCBJIHdhbnQgd2l0aCBuZXR3b3JraW5nIHRvIGZpdCBvdXIgTk9DIGFuZCBvZmZp Y2UKICAgIG5ldHdvcmsgZW52aXJvbm1lbnQuCgogICAgCgogICAgSSBoYXZlIGJlZW4gcGxheWlu ZyB3aXRoIHRoaXMgZm9yIGFib3V0IHRocmVlIHdlZWtzLiBPdmVyIHRoZQogICAgd2Vla2VuZCwg SSBoYWQgYSBoYW5kZnVsIG9mIFZNcyBydW5uaW5nLCBpbmNsdWRpbmcgdGhlIGhvc3RlZAogICAg ZW5naW5lLiBUaGV5IHdlcmUgcHJldHR5IG11Y2ggc2l0dGluZyBpZGxlIGRvaW5nIG5vdGhpbmcu IEkgY2FtZSBpbgogICAgTW9uZGF5IGFuZCBmb3VuZCBldmVyeXRoaW5nIG9mZmxpbmUuIE5vIHBv d2VyIG91dGFnZXMsCiAgICBuZXR3b3JrL3N3aXRjaCBkaWRuJ3QgZmFpbCBvciByZWJvb3QsIG5v bmUgb2YgdGhlIGhhcmR3YXJlIHJlc2V0LgogICAgV2hhdCBJIGZvdW5kIGhhcHBlbmVkIHdhcyB0 aGF0IGdsdXN0ZXJkIHdlbnQgbnV0cyBvbiB0d28gb2YgdGhlCiAgICBub2RlcyAoSSBoYXZlIG5v IGlkZWEgd2h5KS4gR2x1c3RlciB3YXMgc3BpdHRpbmcgb3V0IGxvZ3MgbGlrZQogICAgY3Jhenks IC92YXIgZmlsbGVkIHVwLCB0aGVuIFJBTSBhbmQgc3dhcCB3YXMgZGVwbGV0ZWQuIFR3byBnbHVz dGVyCiAgICBwcm9jZXNzZXMvaG9zdHMgb2ZmbGluZSBvdXQgb2YgdGhlIGZvdXIgbWVhbnQgcXVv cnVtIGJyb2tlLAogICAgZXZlcnl0aGluZyBjYW1lIHRvIGEgaGFsdC4gSSB3YXMgdW5hYmxlIHRv IHJlY292ZXIgdGhlIGdsdXN0ZXIgbG9ncwogICAgc2luY2UgdGhleSBoYWQgdG8gYmUgZGVsZXRl ZCB0byBmcmVlIHVwIHNwYWNlIGluIC92YXIuCgogICAgCgogICAgSSB3YXMgYWJsZSB0byBnZXQg ZXZlcnl0aGluZyBmaXhlZCBhbmQgYmFjayBvbmxpbmUgaW4gYWJvdXQgMi0xLzIKICAgIGhvdXJz LiBTbyB0aGlzIGlzIGltcG9zc2libGUgdG8gcHV0IGludG8gcHJvZHVjdGlvbi4gU3RvcmFnZSBp cyB0aGUKICAgIHdlYWtlc3QgbGluayBhbmQgbW9zdGx5IGxpa2VseSB0byBmYWlsLCB3aGljaCBp biB0aGlzIGNhc2UgaXQgZGlkLgoKICAgIAoKICAgIEkgZG8gbm90IHJlY29tbWVuZCB0aGlzIGNv bmZpZ3VyYXRpb24gYXQgYWxsLiBBIGRlZGljYXRlZCBtYWNoaW5lCiAgICBmb3IgdGhlIGVuZ2lu ZSwgZGVkaWNhdGVkIGh5cGVydmlzb3JzIGFuZCBkZWRpY2F0ZWQgc3RvcmFnZSBub2RlcyBvcgog ICAgYSBTQU4gaXMgbmVlZGVkIGZvciBhbnl0aGluZyBiZXlvbmQgZXhwZXJpbWVudGF0aW9uLgoK ICAgIAoKICAgIEkgaGF2ZSB6ZXJvIGtub3dsZWRnZSBvZiBWTVdhcmUncyB2U0FOLCBvdGhlciB0 aGFuIGJhc2ljIGNvbmNlcHRzLAogICAgc28gSSBjYW5ub3Qgc2F5IHRoZSByZXN1bHRzIHdvdWxk IGJlIHNpbWlsYXIuCgogICAgCgogICAgCgogICAgT24gMi8xOC8yMDE1IDU6MzIgQU0sIEJpbGwg RG9zc2V0dAogICAgICB3cm90ZToKCiAgICAKICAgIAogICAgICAKICAgICAgCiAgICAgIDwhLS0K LyogRm9udCBEZWZpbml0aW9ucyAqLwpAZm9udC1mYWNlCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEg TWF0aCI7CglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30KQGZvbnQtZmFjZQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9Ci8qIFN0eWxl IERlZmluaXRpb25zICovCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwK CXttYXJnaW46MGNtOwoJbWFyZ2luLWJvdHRvbTouMDAwMXB0OwoJZm9udC1zaXplOjExLjBwdDsK CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Cgltc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUzt9CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsKCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7Cgljb2xvcjojMDU2M0MxOwoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9CmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZAoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsKCWNv bG9yOiM5NTRGNzI7Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30Kc3Bhbi5FbWFpbFN0eWxl MTcKCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOwoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsKCWNvbG9yOndpbmRvd3RleHQ7fQouTXNvQ2hwRGVmYXVsdAoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5OwoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsKCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30KQHBhZ2UgV29yZFNlY3Rpb24xCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30KZGl2LldvcmRTZWN0aW9uMQoJe3BhZ2U6V29yZFNlY3Rpb24xO30KLS0+CiAgICAgIAogICAg ICAgIEhpLAogICAgICAgIMKgCiAgICAgICAgSeKAmW0gaW4gYXQgdGhlIGRlZXAgZW5k4oCmCiAg ICAgICAgwqAKICAgICAgICBMb29raW5nIGZvciBzb21lIGFkdmljZSBvbiBpZiB0aGlzIGlzCiAg ICAgICAgICBwb3NzaWJsZSDigJMgYW5kIHdoYXQgdmVyc2lvbiBJIHNob3VsZCB0cnkgSSB3aXRo IGlmIHNvLgogICAgICAgIMKgCiAgICAgICAgV2UgYXJlIGEgaGVhdmlseSBWTXdhcmUgb3JpZW50 ZWQgY29tcGFueeKApgogICAgICAgICAgYnV0IEkgYW0gdHJ5aW5nIHRvIGdldCBSSEVWL29WaXJ0 IGluIHRoZSBkb29yLsKgIEhvbmVzdGx5IEkKICAgICAgICAgIHdvdWxkIHByZWZlciBvVmlydCwg YnV0IGlmIHRoZXkgaW5zaXN0IG9uIGVudGVycHJpc2Ugc3VwcG9ydCBJCiAgICAgICAgICBnbyB0 byBSZWRoYXQuCiAgICAgICAgwqAKICAgICAgICBTbyBJIGhhdmUgaGFkIGEgcGxheSB3aXRoIFZN d2FyZSBWU0FOIGFuZAogICAgICAgICAga25vdyBob3cgaXQgd29ya3MuwqAgSSBhbSB0cnlpbmcg dG8gbW9yZSBvciBsZXNzIHJlcGxpY2F0ZSB0aGlzCiAgICAgICAgICBzZXR1cCB1c2luZyBvcGVu IHNvdXJjZS4KICAgICAgICDCoAogICAgICAgIFNvIFZTQU4gdXNlcyAzIG9yIG1vcmUgRVNYaSBu b2Rlcywgd2l0aAogICAgICAgICAgbG9jYWwgaGFyZGRpc2tzIGFzIHRoZSBzdG9yYWdlIG1lZGl1 bSBhcyBhIHZpcnR1YWwgU0FOLsKgIFRoZQogICAgICAgICAgU0FOIHBlcmZvcm1hbmNlIGlzIHF1 aXRlIGhpZ2ggYXMgeW91IHB1dCBhdCBsZWFzdCAxIFNTRCBpbgogICAgICAgICAgZWFjaCBub2Rl LgogICAgICAgIMKgCiAgICAgICAgV2hhdCBpcyBuaWNlIGlzIHlvdSBkb27igJl0IGhhdmUgdGhl IE5BUwogICAgICAgICAgZWxlbWVudCBoZXJlLsKgIFZNcyBhcmUgb24gdGhlIGxvY2FsIHN0b3Jh Z2UsIHdoaWNoIGlzCiAgICAgICAgICBwYXJ0aWFsbHkgU1NELCBzbyBwZXJmb3JtYW5jZSBpcyBx dWl0ZSBnb29kLgogICAgICAgIMKgCiAgICAgICAgSSB3ZW50IHRvIGEgUmVkaGF0IHByZXNlbnRh dGlvbiBvbiBSZWRoYXQKICAgICAgICAgIHN0b3JhZ2UgYW5kIEdsdXN0ZXJGUyBhbmQgYmFzaWNh bGx5IHRoaXMgYWN0cyBhcyBhIGJpZwogICAgICAgICAgc29mdHdhcmUgZGVmaW5lZCBOQVMgd2hp Y2ggZG9lcyBzb21lIHByZXR0eSBjb29sIHRoaW5ncywgYnV0CiAgICAgICAgICB0aGF04oCZcyBu b3QgZXhhY3RseSB3aGF0IEkgbmVlZC4KICAgICAgICDCoAogICAgICAgIEkgd291bGQgbGlrZSB0 byBidWlsZCBvVmlydCBvbiB0b3Agb2YKICAgICAgICAgIENlbnRPUyBPc3PigKYgdGhhdCBoYXZl IGxvY2FsIHN0b3JhZ2UgaW4gdGhlbSB0aGF0IGlzCiAgICAgICAgICBkaXN0cmlidXRlZCBhbmQg cmVkdW5kYW50IGluIHRoZSBldmVudCBvZiBhIG5vZGUgZmFpbHVyZS4KICAgICAgICDCoAogICAg ICAgIEFuZCBJIHByb2JhYmx5IG5lZWQgdG8gdHJ5IGFuZCBidWlsZCB0aGlzCiAgICAgICAgICBp biBhIGxhYiB1bmRlciBGdXNpb24gb24gbXkgTWFjIEJvb2sgcHJvIHRvIGJlZ2luIHdpdGggYW55 d2F5CiAgICAgICAgICAodGhhdCBiaXQgSeKAmW0gZmFyaWx5IGNvbmZpZGVudCB3aXRoKSBhbmQg aWYgSSBnZXQgdGhhdCB3b3JraW5nCiAgICAgICAgICBjYW4gcHJvYmFibHkgZ2V0IHNvbWUgb2xk ZXIga2l0IHRvIHRyeSBpdCBvdXQgZm9yIHJlYWwgYXMgYQogICAgICAgICAgUG9DIHRvIGZldyBw ZW9wbGUuCiAgICAgICAgwqAKICAgICAgICBTbywgSeKAmXZlIHNldCB1cCBvVmlydCBiZWZvcmUg dGhhdCBzaG91bGQgYmUKICAgICAgICAgIG9rLCBJIGhhdmVu4oCZdCBzZXR1cCBHbHVzdGVyIGlz IHRoZXJlIGFueSBkb2N1bWVudHMgdGhhdCB3b3VsZAogICAgICAgICAgaGVscCBtZSBkb3duIHRo aXMgcm9hZCBhbmQgbWFrZSBzdXJlIEkgc3RhcnQgb3V0IHVzaW5nIHRoZQogICAgICAgICAgYmVz dCB2ZXJzaW9uLgogICAgICAgIMKgCiAgICAgICAgQW55IGFkdmljZSBvciBwb2ludGVycyB3b3Vs ZCBiZSBncmF0ZWZ1bGx5CiAgICAgICAgICByZWNlaXZlZC4KICAgICAgICDCoAogICAgICAgIFRo YW5rcwogICAgICAgIMKgCiAgICAgICAgCiAgICAgICAgICAKICAgICAgICAgICAgCiAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICBCaWxsCiAgICAgICAgICAgICAgICAgICAgICBEb3NzZXR0 CiAgICAgICAgICAgICAgICBTeXN0ZW1zCiAgICAgICAgICAgICAgICAgICAgQXJjaGl0ZWN0CiAg ICAgICAgICAgICAgCiAgICAgICAgICAgIAogICAgICAgICAgICAKICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgIFRlY2gKICAgICAgICAgICAgICAgICAgICAgIENlbnRyYWwg4oCTIEdsb2Jh bCBFbmdpbmVlcmluZyBTZXJ2aWNlcwogICAgICAgICAgICAgICAgwqAKICAgICAgICAgICAgICAg IFTCoCs0NAogICAgICAgICAgICAgICAgICAgICgwKTE5MjMgMjc5MzUzCiAgICAgICAgICAgICAg ICBNwqArNDQKICAgICAgICAgICAgICAgICAgICAoMCk3NzcgNTkwIDg2MTIKICAgICAgICAgICAg ICAgIGJpbGwuZG9zc2V0dEBwYi5jb20KICAgICAgICAgICAgICAgIHBpdG5leWJvd2VzLmNvbQog ICAgICAgICAgICAgICAgCgogICAgICAgICAgICAgICAgICBQaXRuZXkKICAgICAgICAgICAgICAg ICAgICAgIEJvd2VzCiAgICAgICAgICAgICAgICA2CiAgICAgICAgICAgICAgICAgICAgSGVyY3Vs ZXMgV2F5IHwgTGVhdmVzZGVuIHwgV0QyNSA3R1MgfCBVSwogICAgICAgICAgICAgICAgwqAKICAg ICAgICAgICAgICAKICAgICAgICAgICAgCiAgICAgICAgICAgIAogICAgICAgICAgICAgIAoKICAg ICAgICAgICAgICAKICAgICAgICAgICAgCiAgICAgICAgICAgIAogICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgTGVhcm4gbW9yZSBhYm91dCBHbG9iYWwKICAgICAgICAgICAgICAgICAgICAg ICAgRW5naW5lZXJpbmcgU2VydmljZXMKICAgICAgICAgICAgICAgIMKgCiAgICAgICAgICAgICAg ICBJbgogICAgICAgICAgICAgICAgICAgIEVuZ2luZWVyaW5nPwogICAgICAgICAgICAgICAgUmFp c2UKICAgICAgICAgICAgICAgICAgICAgIGEgdGlja2V0IHZpYSBSZW1lZHkgQW55d2hlcmUgW0hF UkVdwqB0YWtlcyBsZXNzIHRoYW4gYQogICAgICAgICAgICAgICAgICAgICAgbWludXRlCiAgICAg ICAgICAgICAgICDCoAogICAgICAgICAgICAgICAgQ2xvdWRGb3JtcwogICAgICAgICAgICAgICAg ICAgICAgVXNlciBHdWlkZSBhdmFpbGFibGXCoFtIRVJFXQogICAgICAgICAgICAgIAogICAgICAg ICAgICAKICAgICAgICAgIAogICAgICAgIAogICAgICAgIMKgCiAgICAgICAgwqAKICAgICAgCiAg ICAgIAoKICAgICAgCiAgICAgIAoKICAgICAgCiAgICAgIAoKICAgICAgCiAgICAgIAoKICAgICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVXNlcnMgbWFp bGluZyBsaXN0ClVzZXJzQG92aXJ0Lm9yZwpodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4v bGlzdGluZm8vdXNlcnMKCiAgICAKICAgIAoKICA= ----_com.android.email_82515713991120 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT4KICAgIAo8ZGl2PkkgZGlkIG5vdCBo YXZlIGEgZ29vZCBleHBlcmllbmNlIHB1dHRpbmcgYm90aCBnbHVzdGVyIGFuZCB2aXJ0IG9uIHRo ZSBzYW1lIG5vZGUuIEkgd2FzIGRvaW5nIGhvc3RlZCBlbmdpbmUgd2l0aCByZXBsaWNhdGUgYWNy b3NzIHR3byBub2RlcywgYW5kIG9uZSBkYXkgaXQgd2VudCBpbnRvIHNwbGl0IGJyYWluIGhlbGwu Li4gaSB3YXMgbmV2ZXIgYWJsZSB0byB0cmFjayBkb3duIHdoeS4gSG93ZXZlciBpIGRvIGhhdmUg YSBnbHVzdGVyIHdpdGggZGlzdHJpYnV0ZSBhbmQgcmVwbGljYSBzZXR1cCBvbiBpdHMgb3duIHdp dGggYSBjb3VwbGUgbm9kZXMsIGFuZCBpdCBoYXMgZ2l2ZW4gbWUgemVybyBwcm9ibGVtcyBpbiB0 aGUgbGFzdCA2MCBkYXlzLiBJdCBzZWVtcyB0byBtZSB0aGF0IGdsdXN0ZXIgYW5kIHZpcnQgbmVl ZCB0byBzdGF5IHNlcGVyYXRlIGZvciBub3cuIEJvdGggYXJlIGdyZWF0IHByb2R1Y3RzIGFuZCBi b3RoIHdvcmsgYXMgZGVzY3JpYmVkLCBqdXN0IG5vdCBvbiB0aGUgc2FtZSBub2RlIGF0IHRoZSBz YW1lIHRpbWUuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJlIj48ZGl2IHN0eWxlPSJmb250LXNpemU6ODUl O2NvbG9yOiM1NzU3NTciPkhhcHB5IENvbm5lY3RpbmcuIFNlbnQgZnJvbSBteSBTcHJpbnQgU2Ft c3VuZyBHYWxheHkgU8KuIDU8L2Rpdj48L2Rpdj48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIG1l c3NhZ2UgLS0tLS0tLS08YnI+RnJvbTogR2VvcmdlIFNrb3J1cCAmbHQ7Z2VvcmdlQG13Y29tbS5j b20mZ3Q7IDxicj5EYXRlOiAwMi8xOC8yMDE1ICAxMjo1MCBQTSAgKEdNVC0wNzowMCkgPGJyPlRv OiB1c2Vyc0BvdmlydC5vcmcgPGJyPlN1YmplY3Q6IFJlOiBbb3ZpcnQtdXNlcnNdIG92aXJ0IGFu ZCBnbHVzdGVyZnMgc2V0dXAgPGJyPjxicj4KICAgIEJpbGwsPGJyPgogICAgPGJyPgogICAgSSBo YXZlIGRvbmUgZXhhY3RseSB3aGF0IHlvdSdyZSBsb29raW5nIHRvIGRvLiBJIHdhcyB0cnlpbmcg dG8gbWltaWMKICAgIHZTQU4gYXMgd2VsbC4gVGhleSBoYWQgVlNBIGZvciBhIHdoaWxlIHdoaWNo IHdhcyBhY2NlcHRhYmxlCiAgICBsaWNlbnNpbmcgY29zdHMsIGJ1dCB0aGF0IHdhcyByZXBsYWNl ZCB3aXRoIHZTQU4gd2hpY2ggaXMKICAgIHJpZGljdWxvdXNseSBleHBlbnNpdmUgZm9yIGFuIGV4 dHJhLXNtYWxsIGJ1c2luZXNzLjxicj4KICAgIDxicj4KICAgIEkgaGF2ZSBhIGZvdXIgbm9kZSBj bHVzdGVyIHdpdGggMVRCIG9mIHN0b3JhZ2UgZWFjaC4gR2x1c3RlciBpcwogICAgY29uZmlndXJl ZCB3aXRoIHJlcGxpY2EgNC4gU28gYmFzaWNhbGx5IEkgaGF2ZSAxVEIgb2YgdXNhYmxlCiAgICBz dG9yYWdlLCB3aGljaCBpcyBmaW5lIGZvciBteSBuZWVkcy4gVk0gbWlncmF0aW9uLCBHbHVzdGVy CiAgICByZXBsaWNhdGlvbiwgaG9zdGVkIGVuZ2luZSBhbmQgYWxsIHRoYXQgd29ya3MgZmluZS4g UGVyZm9ybWFuY2UgaXMKICAgIGdlbmVyYWxseSBmaW5lLCBldmVuIHdpdGggb25seSBkdWFsIExB Q1AgYm9uZGVkIDFHYkUgTklDcyBpbiBlYWNoCiAgICBub2RlLiBJIGNhbiBkbyB3aGF0IEkgd2Fu dCB3aXRoIG5ldHdvcmtpbmcgdG8gZml0IG91ciBOT0MgYW5kIG9mZmljZQogICAgbmV0d29yayBl bnZpcm9ubWVudC48YnI+CiAgICA8YnI+CiAgICBJIGhhdmUgYmVlbiBwbGF5aW5nIHdpdGggdGhp cyBmb3IgYWJvdXQgdGhyZWUgd2Vla3MuIE92ZXIgdGhlCiAgICB3ZWVrZW5kLCBJIGhhZCBhIGhh bmRmdWwgb2YgVk1zIHJ1bm5pbmcsIGluY2x1ZGluZyB0aGUgaG9zdGVkCiAgICBlbmdpbmUuIFRo ZXkgd2VyZSBwcmV0dHkgbXVjaCBzaXR0aW5nIGlkbGUgZG9pbmcgbm90aGluZy4gSSBjYW1lIGlu CiAgICBNb25kYXkgYW5kIGZvdW5kIGV2ZXJ5dGhpbmcgb2ZmbGluZS4gTm8gcG93ZXIgb3V0YWdl cywKICAgIG5ldHdvcmsvc3dpdGNoIGRpZG4ndCBmYWlsIG9yIHJlYm9vdCwgbm9uZSBvZiB0aGUg aGFyZHdhcmUgcmVzZXQuCiAgICBXaGF0IEkgZm91bmQgaGFwcGVuZWQgd2FzIHRoYXQgZ2x1c3Rl cmQgd2VudCBudXRzIG9uIHR3byBvZiB0aGUKICAgIG5vZGVzIChJIGhhdmUgbm8gaWRlYSB3aHkp LiBHbHVzdGVyIHdhcyBzcGl0dGluZyBvdXQgbG9ncyBsaWtlCiAgICBjcmF6eSwgL3ZhciBmaWxs ZWQgdXAsIHRoZW4gUkFNIGFuZCBzd2FwIHdhcyBkZXBsZXRlZC4gVHdvIGdsdXN0ZXIKICAgIHBy b2Nlc3Nlcy9ob3N0cyBvZmZsaW5lIG91dCBvZiB0aGUgZm91ciBtZWFudCBxdW9ydW0gYnJva2Us CiAgICBldmVyeXRoaW5nIGNhbWUgdG8gYSBoYWx0LiBJIHdhcyB1bmFibGUgdG8gcmVjb3ZlciB0 aGUgZ2x1c3RlciBsb2dzCiAgICBzaW5jZSB0aGV5IGhhZCB0byBiZSBkZWxldGVkIHRvIGZyZWUg dXAgc3BhY2UgaW4gL3Zhci48YnI+CiAgICA8YnI+CiAgICBJIHdhcyBhYmxlIHRvIGdldCBldmVy eXRoaW5nIGZpeGVkIGFuZCBiYWNrIG9ubGluZSBpbiBhYm91dCAyLTEvMgogICAgaG91cnMuIFNv IHRoaXMgaXMgaW1wb3NzaWJsZSB0byBwdXQgaW50byBwcm9kdWN0aW9uLiBTdG9yYWdlIGlzIHRo ZQogICAgd2Vha2VzdCBsaW5rIGFuZCBtb3N0bHkgbGlrZWx5IHRvIGZhaWwsIHdoaWNoIGluIHRo aXMgY2FzZSBpdCBkaWQuPGJyPgogICAgPGJyPgogICAgSSBkbyBub3QgcmVjb21tZW5kIHRoaXMg Y29uZmlndXJhdGlvbiBhdCBhbGwuIEEgZGVkaWNhdGVkIG1hY2hpbmUKICAgIGZvciB0aGUgZW5n aW5lLCBkZWRpY2F0ZWQgaHlwZXJ2aXNvcnMgYW5kIGRlZGljYXRlZCBzdG9yYWdlIG5vZGVzIG9y CiAgICBhIFNBTiBpcyBuZWVkZWQgZm9yIGFueXRoaW5nIGJleW9uZCBleHBlcmltZW50YXRpb24u PGJyPgogICAgPGJyPgogICAgSSBoYXZlIHplcm8ga25vd2xlZGdlIG9mIFZNV2FyZSdzIHZTQU4s IG90aGVyIHRoYW4gYmFzaWMgY29uY2VwdHMsCiAgICBzbyBJIGNhbm5vdCBzYXkgdGhlIHJlc3Vs dHMgd291bGQgYmUgc2ltaWxhci48YnI+CiAgICA8YnI+CiAgICA8YnI+CiAgICA8ZGl2IGNsYXNz PSJtb3otY2l0ZS1wcmVmaXgiPk9uIDIvMTgvMjAxNSA1OjMyIEFNLCBCaWxsIERvc3NldHQKICAg ICAgd3JvdGU6PGJyPgogICAgPC9kaXY+CiAgICA8YmxvY2txdW90ZSBjaXRlPSJtaWQ6QjQ3RjAw ODI1RDY4NDQ0QUJDMDM3MzMwNzgyNzUzNjAzNzcxQTM2NEAwMTMtQlIxTVBOMS0wMTIuTUdEUEJJ Lmdsb2JhbC5wdnQiIHR5cGU9ImNpdGUiPgogICAgICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50 LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsKICAgICAgICBjaGFyc2V0PXdpbmRvd3MtMTI1MiI+ CiAgICAgIDxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkCiAgICAgICAgbWVkaXVtKSI+CiAgICAgIDxzdHlsZT48IS0tCi8qIEZvbnQgRGVm aW5pdGlvbnMgKi8KQGZvbnQtZmFjZQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOwoJcGFu b3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9CkBmb250LWZhY2UKCXtmb250LWZhbWlseTpDYWxp YnJpOwoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLwpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsCgl7bWFyZ2luOjBj bTsKCW1hcmdpbi1ib3R0b206LjAwMDFwdDsKCWZvbnQtc2l6ZToxMS4wcHQ7Cglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOwoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6 IzA1NjNDMTsKCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjojOTU0Rjcy OwoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9CnNwYW4uRW1haWxTdHlsZTE3Cgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Cgljb2xvcjp3aW5kb3d0ZXh0O30KLk1zb0NocERlZmF1bHQKCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsKCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Cgltc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9CkBwYWdlIFdvcmRTZWN0aW9uMQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0OwoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9CmRpdi5Xb3Jk U2VjdGlvbjEKCXtwYWdlOldvcmRTZWN0aW9uMTt9Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPgo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+CiAgICAgIDxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+CiAgICAg ICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CiAgICAgICAgPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SeKAmW0gaW4gYXQgdGhlIGRlZXAgZW5k4oCmPG86cD48L286cD48 L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CiAg ICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+TG9va2luZyBmb3Igc29tZSBhZHZpY2Ugb24gaWYg dGhpcyBpcwogICAgICAgICAgcG9zc2libGUg4oCTIGFuZCB3aGF0IHZlcnNpb24gSSBzaG91bGQg dHJ5IEkgd2l0aCBpZiBzby48bzpwPjwvbzpwPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5X ZSBhcmUgYSBoZWF2aWx5IFZNd2FyZSBvcmllbnRlZCBjb21wYW554oCmCiAgICAgICAgICBidXQg SSBhbSB0cnlpbmcgdG8gZ2V0IFJIRVYvb1ZpcnQgaW4gdGhlIGRvb3IuJm5ic3A7IEhvbmVzdGx5 IEkKICAgICAgICAgIHdvdWxkIHByZWZlciBvVmlydCwgYnV0IGlmIHRoZXkgaW5zaXN0IG9uIGVu dGVycHJpc2Ugc3VwcG9ydCBJCiAgICAgICAgICBnbyB0byBSZWRoYXQuPG86cD48L286cD48L3A+ CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CiAgICAg ICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gSSBoYXZlIGhhZCBhIHBsYXkgd2l0aCBWTXdhcmUg VlNBTiBhbmQKICAgICAgICAgIGtub3cgaG93IGl0IHdvcmtzLiZuYnNwOyBJIGFtIHRyeWluZyB0 byBtb3JlIG9yIGxlc3MgcmVwbGljYXRlIHRoaXMKICAgICAgICAgIHNldHVwIHVzaW5nIG9wZW4g c291cmNlLjxvOnA+PC9vOnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIFZTQU4gdXNl cyAzIG9yIG1vcmUgRVNYaSBub2Rlcywgd2l0aAogICAgICAgICAgbG9jYWwgaGFyZGRpc2tzIGFz IHRoZSBzdG9yYWdlIG1lZGl1bSBhcyBhIHZpcnR1YWwgU0FOLiZuYnNwOyBUaGUKICAgICAgICAg IFNBTiBwZXJmb3JtYW5jZSBpcyBxdWl0ZSBoaWdoIGFzIHlvdSBwdXQgYXQgbGVhc3QgMSBTU0Qg aW4KICAgICAgICAgIGVhY2ggbm9kZS48bzpwPjwvbzpwPjwvcD4KICAgICAgICA8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj5XaGF0IGlzIG5pY2UgaXMgeW91IGRvbuKAmXQgaGF2ZSB0aGUgTkFTCiAgICAgICAgICBl bGVtZW50IGhlcmUuJm5ic3A7IFZNcyBhcmUgb24gdGhlIGxvY2FsIHN0b3JhZ2UsIHdoaWNoIGlz CiAgICAgICAgICBwYXJ0aWFsbHkgU1NELCBzbyBwZXJmb3JtYW5jZSBpcyBxdWl0ZSBnb29kLjxv OnA+PC9vOnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2VudCB0byBhIFJlZGhhdCBw cmVzZW50YXRpb24gb24gUmVkaGF0CiAgICAgICAgICBzdG9yYWdlIGFuZCBHbHVzdGVyRlMgYW5k IGJhc2ljYWxseSB0aGlzIGFjdHMgYXMgYSBiaWcKICAgICAgICAgIHNvZnR3YXJlIGRlZmluZWQg TkFTIHdoaWNoIGRvZXMgc29tZSBwcmV0dHkgY29vbCB0aGluZ3MsIGJ1dAogICAgICAgICAgdGhh dOKAmXMgbm90IGV4YWN0bHkgd2hhdCBJIG5lZWQuPG86cD48L286cD48L3A+CiAgICAgICAgPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CiAgICAgICAgPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSB3b3VsZCBsaWtlIHRvIGJ1aWxkIG9WaXJ0IG9uIHRvcCBvZgogICAgICAg ICAgQ2VudE9TIE9zc+KApiB0aGF0IGhhdmUgbG9jYWwgc3RvcmFnZSBpbiB0aGVtIHRoYXQgaXMK ICAgICAgICAgIGRpc3RyaWJ1dGVkIGFuZCByZWR1bmRhbnQgaW4gdGhlIGV2ZW50IG9mIGEgbm9k ZSBmYWlsdXJlLjxvOnA+PC9vOnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZCBJIHBy b2JhYmx5IG5lZWQgdG8gdHJ5IGFuZCBidWlsZCB0aGlzCiAgICAgICAgICBpbiBhIGxhYiB1bmRl ciBGdXNpb24gb24gbXkgTWFjIEJvb2sgcHJvIHRvIGJlZ2luIHdpdGggYW55d2F5CiAgICAgICAg ICAodGhhdCBiaXQgSeKAmW0gZmFyaWx5IGNvbmZpZGVudCB3aXRoKSBhbmQgaWYgSSBnZXQgdGhh dCB3b3JraW5nCiAgICAgICAgICBjYW4gcHJvYmFibHkgZ2V0IHNvbWUgb2xkZXIga2l0IHRvIHRy eSBpdCBvdXQgZm9yIHJlYWwgYXMgYQogICAgICAgICAgUG9DIHRvIGZldyBwZW9wbGUuPG86cD48 L286cD48L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28sIEnigJl2ZSBzZXQgdXAgb1ZpcnQg YmVmb3JlIHRoYXQgc2hvdWxkIGJlCiAgICAgICAgICBvaywgSSBoYXZlbuKAmXQgc2V0dXAgR2x1 c3RlciBpcyB0aGVyZSBhbnkgZG9jdW1lbnRzIHRoYXQgd291bGQKICAgICAgICAgIGhlbHAgbWUg ZG93biB0aGlzIHJvYWQgYW5kIG1ha2Ugc3VyZSBJIHN0YXJ0IG91dCB1c2luZyB0aGUKICAgICAg ICAgIGJlc3QgdmVyc2lvbi48bzpwPjwvbzpwPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5B bnkgYWR2aWNlIG9yIHBvaW50ZXJzIHdvdWxkIGJlIGdyYXRlZnVsbHkKICAgICAgICAgIHJlY2Vp dmVkLjxvOnA+PC9vOnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rczxvOnA+PC9v OnA+PC9wPgogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PgogICAgICAgIDx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIHN0eWxlPSJ3aWR0aDo0ODAu MHB0IiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCIgd2lkdGg9IjY0 MCI+CiAgICAgICAgICA8dGJvZHk+CiAgICAgICAgICAgIDx0cj4KICAgICAgICAgICAgICA8dGQg c3R5bGU9IndpZHRoOjQ4MC4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSAwY20iIHdpZHRoPSI2NDAi PgogICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDA4MkQ1O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5CaWxs CiAgICAgICAgICAgICAgICAgICAgICBEb3NzZXR0PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KICAgICAgICAg ICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPlN5c3RlbXMKICAgICAgICAgICAgICAgICAgICBBcmNo aXRlY3Q8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+CiAgICAgICAgICAgICAgPC90ZD4KICAgICAgICAgICAgPC90cj4K ICAgICAgICAgICAgPHRyPgogICAgICAgICAgICAgIDx0ZCBzdHlsZT0id2lkdGg6NDgwLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDBjbSIgd2lkdGg9IjY0MCI+CiAgICAgICAgICAgICAgICA8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLUdCIj5UZWNoCiAgICAgICAgICAgICAgICAgICAgICBDZW50cmFsIOKAkyBH bG9iYWwgRW5naW5lZXJpbmcgU2VydmljZXM8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPgogICAgICAgICAgICAg ICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KICAgICAgICAgICAg ICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPiZuYnNwOys0NAogICAgICAgICAgICAg ICAgICAgICgwKTE5MjMgMjc5MzUzPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPgogICAgICAgICAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1HQiI+TTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+Jm5ic3A7KzQ0CiAgICAgICAgICAgICAgICAgICAgKDAp Nzc3IDU5MCA4NjEyPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1H QiI+PG86cD48L286cD48L3NwYW4+PC9wPgogICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48YSBtb3otZG8t bm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzpqZWZmLmdvbnphbGV6QHBiLmNvbSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpwdXJwbGUiPmI8L3NwYW4+PC9hPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDgyRDU7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tR0IiPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRvOmlsbC5kb3NzZXR0 QHBiLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPmlsbC5kb3NzZXR0QHBiLmNvbTwvc3Bh bj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldwpSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPgogICAgICAgICAgICAgICAgPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA4MkQ1 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhy ZWY9InBpdG5leWJvd2VzLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDgyRDUiPnBpdG5leWJv d2VzLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPgogICAgICAgICAgICAgICAgPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tR0IiPjxicj4KICAgICAgICAgICAgICAgICAgPC9zcGFuPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPlBpdG5leQogICAgICAg ICAgICAgICAgICAgICAgQm93ZXM8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPgogICAgICAgICAgICAgICAgPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1HQiI+NgogICAgICAgICAgICAgICAgICAgIEhlcmN1bGVzIFdheSB8IExlYXZl c2RlbiB8IFdEMjUgN0dTIHwgVUs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CiAgICAgICAgICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLUdCIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CiAgICAgICAgICAgICAgPC90ZD4KICAgICAg ICAgICAgPC90cj4KICAgICAgICAgICAgPHRyPgogICAgICAgICAgICAgIDx0ZCBzdHlsZT0id2lk dGg6NDgwLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSIgd2lkdGg9IjY0MCI+PGJyPgogICAg ICAgICAgICAgIDwvdGQ+CiAgICAgICAgICAgIDwvdHI+CiAgICAgICAgICAgIDx0cj4KICAgICAg ICAgICAgICA8dGQgc3R5bGU9IndpZHRoOjQ4MC4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSAwY20i IHdpZHRoPSI2NDAiPgogICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA4MkQ1O21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LUdCIj48YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0dHA6Ly90ZWFtc2l0ZS5pbnNp ZGUucGIuY29tL3NpdGVzL1RDUFBNL0dFUy9TaXRlUGFnZXMvSG9tZS5hc3B4Ij48c3BhbiBzdHls ZT0iY29sb3I6IzAwODJENSI+TGVhcm4gbW9yZSBhYm91dCBHbG9iYWwKICAgICAgICAgICAgICAg ICAgICAgICAgRW5naW5lZXJpbmcgU2VydmljZXM8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KICAg ICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWFmdGVy OmF2b2lkIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LUdCIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CiAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0icGFnZS1icmVhay1hZnRlcjphdm9pZCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+SW4KICAgICAgICAgICAgICAgICAgICBF bmdpbmVlcmluZz88L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdC Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CiAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LUdCIj5SYWlzZQogICAgICAgICAgICAgICAgICAgICAgYSB0aWNrZXQgdmlhIFJlbWVkeSBBbnl3 aGVyZSBbPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDgyRDUiPjxhIG1vei1kby1ub3Qtc2VuZD0idHJ1 ZSIgaHJlZj0idGVhbXNpdGUuaW5zaWRlLnBiLmNvbS9zaXRlcy9UQ1BQTS9HRVMvTGlzdHMvQ3Jl YXRlJTIwSW5jaWRlbnQvbmV3SW5jaWRlbnQuYXNweCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDgy RDUiPkhFUkU8L3NwYW4+PC9hPjwvc3Bhbj5dPHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPiZuYnNw Ozwvc3Bhbj50YWtlcyBsZXNzIHRoYW4gYQogICAgICAgICAgICAgICAgICAgICAgbWludXRlPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4KICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPiZuYnNw Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+CiAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5D bG91ZEZvcm1zCiAgICAgICAgICAgICAgICAgICAgICBVc2VyIEd1aWRlIGF2YWlsYWJsZTwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1H QiI+Jm5ic3A7WzxiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA4MkQ1Ij48YSBtb3otZG8tbm90LXNl bmQ9InRydWUiIGhyZWY9Imh0dHBzOi8vZGwuZHJvcGJveHVzZXJjb250ZW50LmNvbS91LzYyMTk0 NDEvTWFuYWdlSVElMjAtJTIwVXNlciUyME1hbnVhbCUyMFBCJTIwdjUucGRmIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwODJENSI+SEVSRTwvc3Bhbj48L2E+PC9zcGFuPjwvYj5dPC9zcGFuPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w PgogICAgICAgICAgICAgIDwvdGQ+CiAgICAgICAgICAgIDwvdHI+CiAgICAgICAgICA8L3Rib2R5 PgogICAgICAgIDwvdGFibGU+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3CiAgICAgICAg ICAgIFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CiAgICAgICAgPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CiAgICAgIDwvZGl2PgogICAgICA8YnI+CiAgICAg IDxocj4KICAgICAgPGZvbnQgY29sb3I9IkJsYWNrIiBmYWNlPSJBcmlhbCIgc2l6ZT0iMiI+PGJy PgogICAgICA8L2ZvbnQ+CiAgICAgIDxicj4KICAgICAgPGZpZWxkc2V0IGNsYXNzPSJtaW1lQXR0 YWNobWVudEhlYWRlciI+PC9maWVsZHNldD4KICAgICAgPGJyPgogICAgICA8cHJlIHdyYXA9IiI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVXNlcnMgbWFp bGluZyBsaXN0CjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0 bzpVc2Vyc0BvdmlydC5vcmciPlVzZXJzQG92aXJ0Lm9yZzwvYT4KPGEgY2xhc3M9Im1vei10eHQt bGluay1mcmVldGV4dCIgaHJlZj0iaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3VzZXJzIj5odHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnM8 L2E+CjwvcHJlPgogICAgPC9ibG9ja3F1b3RlPgogICAgPGJyPgogIDwvYm9keT48L2h0bWw+ ----_com.android.email_82515713991120--

1 0

how to prepare for an engine re-install
by Robert Story 18 Feb '15

18 Feb '15

--Sig_/9FfbJVEsL_QD6_U8ceRqc4+ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I'm running ovirt (engine 3.4.0-1.el6) on a dedicated engine machine with a degraded raid array. This has caused the root filesystem to go read-only, and the engine crashed. I can restart the engine, but after doing so, the web page just loads a blank page. All nodes and VMs seem to be fine, I just can't manage them via oVirt. Because I'm offsite, my recovery option is likely limited to a reinstall of the OS and ovirt. I'm hoping for some pointers on what I can do in advance to minimize the pain of this transition.=20 - Am I going to be able to recover without having to shut down VMs, exporting and importing? - what directories should I back up? - when I reinstall, should I upgrade and install 3.5.1, or first install 3.4, get it working, and then think about upgrading? - Is it possible/recommended/crazy to migrate to a hosted engine instead of a dedicated machine? So I want to prepare for the worst before I try a reboot. If I'm lucky, the reboot will at least come up with a writable filesystem, and I won't need to re-install. If it doesn't come up, I want to be as ready as possible for the reinstall. Any hints and/or tips appreciated.. (I'll also be hanging out in the irc channel if anyone wants to respond in that venue..) Robert --=20 Senior Software Engineer @ Parsons --Sig_/9FfbJVEsL_QD6_U8ceRqc4+ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU5KvuAAoJEMHFVuy5l8Y48rwQAKbV/omCGFyztV/QDBF+T4qX ZtI7+j263nisA38eN7XHbfdfvEux00rqYMy9n7e+IPmsvbMIdPqps9BO9iH7fFjx 7ZtkMqyhKEju6vCiIwdWi3/KWPAhfufQvPXGOqMdgro2tim6yC1cwWQS/bAVexKh RnvntPo3WAdDdE986OdQ4JofJQqUwKAde7oPEWMjhbzx4Mxb/NSq7ExhyfWj0+wh 2iWqEEQLs2KaSOSzaqbXjIoJhxVmQPxToKdUxs1hmAhB4X/lFdIRkSY/x7SMhrKV eDB+4vd55saNz5dPfNSokQ1tTFR7z4iRkOEh5knKlRJwNdrabm+oIwrtrUbR4BX+ L0sHdB12x08aM2aio1OzY5xMLhpJSD/YiAfXs8oCPtHRbYrO2HyvOjilktY4azeO bZkCard2zxUO+UVWOEllcrXVpEgYRMlaCwhs1vsEI0mArpe0Ip9zEGYVN3IgHR6w sKrWi9u2JueqTiJOmuvGwE4EEsYKW4KRId6r1sS16neWAcbuBLjLMVzZkZ7pET5j hoERFPonAURGz1wXUuW8xK/hpZJ4xW71QpqKQfs86rwP1rIMnw3KaFqtf0AFUEPs LTKT44ibC6DNMNj3g3Kdj0iUW6/IM5xRL9QZ4exKipEyJxPf2Er6SZoYC2HffKfo gqTOxAdaa3bCVIn19Zro =ife/ -----END PGP SIGNATURE----- --Sig_/9FfbJVEsL_QD6_U8ceRqc4+--

2 2

ovirt and glusterfs setup
by Bill Dossett 18 Feb '15

18 Feb '15

--_000_B47F00825D68444ABC037330782753603771A364013BR1MPN1012MG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'm in at the deep end... Looking for some advice on if this is possible - and what version I should = try I with if so. We are a heavily VMware oriented company... but I am trying to get RHEV/oVi= rt in the door. Honestly I would prefer oVirt, but if they insist on enter= prise support I go to Redhat. So I have had a play with VMware VSAN and know how it works. I am trying t= o more or less replicate this setup using open source. So VSAN uses 3 or more ESXi nodes, with local harddisks as the storage medi= um as a virtual SAN. The SAN performance is quite high as you put at least= 1 SSD in each node. What is nice is you don't have the NAS element here. VMs are on the local = storage, which is partially SSD, so performance is quite good. I went to a Redhat presentation on Redhat storage and GlusterFS and basical= ly this acts as a big software defined NAS which does some pretty cool thin= gs, but that's not exactly what I need. I would like to build oVirt on top of CentOS Oss... that have local storage= in them that is distributed and redundant in the event of a node failure. And I probably need to try and build this in a lab under Fusion on my Mac B= ook pro to begin with anyway (that bit I'm farily confident with) and if I = get that working can probably get some older kit to try it out for real as = a PoC to few people. So, I've set up oVirt before that should be ok, I haven't setup Gluster is = there any documents that would help me down this road and make sure I start= out using the best version. Any advice or pointers would be gratefully received. Thanks Bill Dossett Systems Architect Tech Central - Global Engineering Services T +44 (0)1923 279353 M +44 (0)777 590 8612 b<mailto:jeff.gonzalez@pb.com>ill.dossett(a)pb.com<mailto:ill.dossett@pb.com> pitneybowes.com Pitney Bowes 6 Hercules Way | Leavesden | WD25 7GS | UK Learn more about Global Engineering Services<http://teamsite.inside.pb.com/= sites/TCPPM/GES/SitePages/Home.aspx> In Engineering? Raise a ticket via Remedy Anywhere [HERE<teamsite.inside.pb.com/sites/TCPPM= /GES/Lists/Create%20Incident/newIncident.aspx>] takes less than a minute CloudForms User Guide available [HERE<https://dl.dropboxusercontent.com/u/6= 219441/ManageIQ%20-%20User%20Manual%20PB%20v5.pdf>] ________________________________ --_000_B47F00825D68444ABC037330782753603771A364013BR1MPN1012MG_ 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-GB" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Hi,<o:p></o:p> <o:p> </o:p> I’m in at the deep end…<o:p></o:p> <o:p> </o:p> Looking for some advice on if this is possible &#821= 1; and what version I should try I with if so.<o:p></o:p> <o:p> </o:p> We are a heavily VMware oriented company… but = I am trying to get RHEV/oVirt in the door.  Honestly I would prefer oV= irt, but if they insist on enterprise support I go to Redhat.<o:p></o:p></p= > <o:p> </o:p> So I have had a play with VMware VSAN and know how i= t works.  I am trying to more or less replicate this setup using open = source.<o:p></o:p> <o:p> </o:p> So VSAN uses 3 or more ESXi nodes, with local harddi= sks as the storage medium as a virtual SAN.  The SAN performance is qu= ite high as you put at least 1 SSD in each node.<o:p></o:p> <o:p> </o:p> What is nice is you don’t have the NAS element= here.  VMs are on the local storage, which is partially SSD, so perfo= rmance is quite good.<o:p></o:p> <o:p> </o:p> I went to a Redhat presentation on Redhat storage an= d GlusterFS and basically this acts as a big software defined NAS which doe= s some pretty cool things, but that’s not exactly what I need.<o:p></= o:p> <o:p> </o:p> I would like to build oVirt on top of CentOS Oss&#82= 30; that have local storage in them that is distributed and redundant in th= e event of a node failure.<o:p></o:p> <o:p> </o:p> And I probably need to try and build this in a lab u= nder Fusion on my Mac Book pro to begin with anyway (that bit I’m far= ily confident with) and if I get that working can probably get some older k= it to try it out for real as a PoC to few people.<o:p></o:p> <o:p> </o:p> So, I’ve set up oVirt before that should be ok= , I haven’t setup Gluster is there any documents that would help me d= own this road and make sure I start out using the best version.<o:p></o:p><= /p> <o:p> </o:p> Any advice or pointers would be gratefully received.= <o:p></o:p> <o:p> </o:p> Thanks<o:p></o:p> <o:p> </o:p> <table class=3D"MsoNormalTable" border=3D"0" cellspacing=3D"0" cellpadding= =3D"0" width=3D"640" style=3D"width:480.0pt"> <tbody> <tr> <td width=3D"640" style=3D"width:480.0pt;padding:0cm 0cm 0cm 0cm"> Bill Dossett<o:p><= /o:p> Systems Archit= ect<o:p></o:p> </td> </tr> <tr> <td width=3D"640" style=3D"width:480.0pt;padding:0cm 0cm 0cm 0cm"> Tech Centra= l – Global Engineering Services<o:p></o:p>  <o:p></o:p>= T</b= > +44 (0)1923 279353<= span style=3D"mso-fareast-language:EN-GB"><o:p></o:p> M</b= > +44 (0)777 590 8612= <o:p></o:p> <a href= =3D"mailto:jeff.gonzalez@pb.com">b</a></span= ><a href=3D"mailto:ill.= dossett(a)pb.com">ill.dossett(a)pb.com</a></s= pan><o:p></o:p> = <a href=3D"pitneybowes.com">pitneybowes.com</= span></a><o:p></o:p></spa= n> Pitney Bowes<spa= n style=3D"mso-fareast-language:EN-GB"><o:p></o:p> 6 Hercules Way= | Leavesden | WD25 7GS | UK<o:p></o:p>  <= span style=3D"mso-fareast-language:EN-GB"><o:p></o:p> </td> </tr> <tr> <td width=3D"640" style=3D"width:480.0pt;padding:0cm 0cm 0cm 0cm"></td> </tr> <tr> <td width=3D"640" style=3D"width:480.0pt;padding:0cm 0cm 0cm 0cm"> = <a href=3D"http://teamsite.inside.pb.com/sites/TCPPM/GES/SitePages/Home.asp= x">Learn more about Global Engineering Services</a><o:p>= </o:p>  = <o:p></o:p> In Engineering?<o:p></o:p> Raise a tic= ket via Remedy Anywhere [<a href=3D"teamsite.= inside.pb.com/sites/TCPPM/GES/Lists/Create%20Incident/newIncident.aspx"><sp= an style=3D"color:#0082D5">HERE</a>] takes less than a minute<o= :p></o:p>  </spa= n><o:p></o:p> CloudForms = User Guide available = [<a href=3D"https://dl.dropboxusercontent.= com/u/6219441/ManageIQ%20-%20User%20Manual%20PB%20v5.pdf">HERE</a>]<o:p></o:p> </td> </tr> </tbody> </table> <o:p>&nbs= p;</o:p> <o:p> </o:p> </div> <hr> </body> </html> --_000_B47F00825D68444ABC037330782753603771A364013BR1MPN1012MG_--

2 1

Re: [ovirt-users] FW: ovirt and glusterfs setup
by Donny D 18 Feb '15

18 Feb '15

----_com.android.email_67919836813260 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CiAgICAKTXkgcHJvamVjdCBpcyBmcmVlIGFuZCBvcGVuLiBXaGF0IHdvdWxkIHlvdSBsaWtlIHRv IGtub3c/Ci1Eb25ueSBECllvdSBjYW4gYWxzbyBnaXZlIG1lIGEgY2FsbCBhdCA4MDUgODE0IDY4 MDAgaWYgdGhlIHBob25lIGlzIGJldHRlciBmb3IgeW91LsKgCgoKSGFwcHkgQ29ubmVjdGluZy4g U2VudCBmcm9tIG15IFNwcmludCBTYW1zdW5nIEdhbGF4eSBTwq4gNQoKLS0tLS0tLS0gT3JpZ2lu YWwgbWVzc2FnZSAtLS0tLS0tLQpGcm9tOiBCaWxsIERvc3NldHQgPGJpbGwuZG9zc2V0dEBwYi5j b20+IApEYXRlOiAwMi8xOC8yMDE1ICAxMDozNyBBTSAgKEdNVC0wNzowMCkgClRvOiB1c2Vyc0Bv dmlydC5vcmcgClN1YmplY3Q6IFtvdmlydC11c2Vyc10gRlc6ICBvdmlydCBhbmQgZ2x1c3RlcmZz IHNldHVwIAoKCgpTb3JyeSwgZm9yZ290IHRvIGNvcHlhbGzigKYKwqAKCgpGcm9tOiBCaWxsIERv c3NldHQgcwoKU2VudDogMTggRmVicnVhcnkgMjAxNSAxNzozNwoKVG86ICdEb25ueSBEYXZpcycK ClN1YmplY3Q6IFJFOiBbb3ZpcnQtdXNlcnNdIG92aXJ0IGFuZCBnbHVzdGVyZnMgc2V0dXAKCgrC oApXZWxsLCBpdCBzZWVtcyB0byBiZSBzb21ldGhpbmcgdGhhdCBSZWRIYXQgd2VyZSBzYXlpbmcg d2FzIGdvaW5nIHRvIGJlIHN1cHBvcnRlZC4KwqAKSSBhbSBmYXIgbW9yZSBmYW1pbGlhciB3aXRo IFZNd2FyZSBWU0FOIGFuZCB0aGF0IGlzIGN1cnJlbnQgYSBWRVJZIGhvdCB0b3BpYy4KwqAKV2l0 aCBWTXdhcmUgSEEgYW5kIFZTQU4gY2FwYWJpbGl0aWVzIGFuZCBuZXcgY2hhc3NpcyBjb21pbmcg b3V0IHdpdGggdmVyeSBoaWdoIGRlbnNpdHkgZHJpdmUgY2FwYWJpbGl0aWVzIGFuZCB0aGUgY29y cmVjdCBudW1iZXIgb2Ygbm9kZXMsIHlvdSBjYW4gbG9zZSBhIG5vZGUgd2l0aCBubyBtb3JlIGRv d250aW1lCiB0aGFuIGlmIGNvbXB1dGUgYW5kIHN0b3JhZ2UgYXJlIHNlcGFyYXRlZCBhbmQgaXTi gJlzIGEgaGVsbHV2YSBsb3QgbGVzcyBleHBlbnNpdmUgdGhhbiB0cmFkaXRpb25hbCBGaWJyZSBT QU4uCsKgClNheWluZyB0aGF0IGl0IGlzIGluIGl04oCZcyBpbmZhbmN5LgrCoApJ4oCZbSBpbnRl cmVzdGVkIGluIHlvdXIgb3ZpcnQgZGVwbG95bWVudCDigJMgdGhhbmtzIGZvciB0aGUga2luZCBv ZmZlciAtIGJ1dCB2ZXJ5IHNob3J0IG9uIHRpbWUgYXMgd2VsbCBhcyB0aGlzIGlzIGEgc2lkZSBw cm9qZWN0IOKAkyBzbyB0aGlzIG1heSBtb3ZlIGF0IGEgc25haWxzIHBhY2XigKYgc28gSSB0aG91 Z2h0IEkgY291bGQKIGdldCBzdGFydGVkIG9uIG15IG93bi4KwqAKSSB0aGluayBJIGluc3Rhc2xs ZWQgb3ZpcnQgMy4yIHByZXZpb3VzbHnigKYgYW5kIEkgZGlkIHNlZSBtZW50aW9uIG9mIEdsdXN0 ZXIgRG9tYWlucy7CoCBJZiB5b3UgbGV0IG1lIGtub3cgd2hhdCBJIG5lZWQgdG8gZG8gdG8gaGF2 ZSBhIGxvb2sgYXQgeW91ciBkZXBsb3ltZW50IEkgd291bGQgYXBwcmVjaWF0ZSBpdC4KwqAKSSBt YXkgYmUgc2xvdyBhdCByZXNwb25kaW5nIHRob3VnaCBhcyBJIGFtIHNwcmVhZCB2ZXJ5IHRoaW4g cmlnaHQgbm93LgrCoApUaGFua3MKQmlsbArCoArCoAoKCkZyb206IERvbm55IERhdmlzIFttYWls dG86ZG9ubnlAY2xvdWRzcGluLm1lXQoKClNlbnQ6IDE4IEZlYnJ1YXJ5IDIwMTUgMTM6MzAKClRv OiBCaWxsIERvc3NldHQKClN1YmplY3Q6IFJFOiBbb3ZpcnQtdXNlcnNdIG92aXJ0IGFuZCBnbHVz dGVyZnMgc2V0dXAKCgrCoApJIGNhbiB0ZWxsIHlvdSBmcm9tIG15IGV4cGVyaWVuY2UgdGhhdCB5 b3Ugc2hvdWxkIGhhdmUgeW91ciBzdG9yYWdlIGFuZCBjb21wdXRlIG5vZGUgc2VwYXJhdGUuIEds dXN0ZXIgc3VwcG9ydCBpcyBidWlsdCBpbnRvIG92aXJ0LCBhbmQgeW91IGp1c3QgbmVlZCB0byBt YWtlIHN1cmUgd2hlbiBzZXR0aW5nIHVwIHlvdXIgZW5naW5lIHlvdQogdGVsbCBpdCB0byBiZSBb Ym90aF0KwqAKVGhlIGFyY2hpdGVjdHVyZSB5b3UgZGVzY3JpYmUgd2hldGhlciBpdCBiZSB2bXdh cmUgb3Igb3ZpcnQgaXMgZGVzdGluZWQgdG8gYmUgYSBkaXNhc3Rlci4gwqBUaGF0IGlzIG15IG1h dHRlciBvZiBvcGluaW9uIGJhc2VkIG9uIG15IGV4cGVyaWVuY2UuIMKgCsKgCkkgaGF2ZSBhIGZy ZWUgdG8gdXNlIG92aXJ0IGRlcGxveW1lbnQgdGhhdCB5b3UgY291bGQgcnVuIHlvdXIgZGVzaXJl ZCBzZXR1cCBvbi4KCsKgCkRvbm55IEQKwqAKY2xvdWRzcGluLm1lIArCoAoKCkZyb206CnVzZXJz LWJvdW5jZXNAb3ZpcnQub3JnIFttYWlsdG86dXNlcnMtYm91bmNlc0BvdmlydC5vcmddCk9uIEJl aGFsZiBPZiBCaWxsIERvc3NldHQKClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTgsIDIwMTUg NDozMyBBTQoKVG86IHVzZXJzQG92aXJ0Lm9yZwoKU3ViamVjdDogW292aXJ0LXVzZXJzXSBvdmly dCBhbmQgZ2x1c3RlcmZzIHNldHVwCgoKwqAKSGksCsKgCknigJltIGluIGF0IHRoZSBkZWVwIGVu ZOKApgrCoApMb29raW5nIGZvciBzb21lIGFkdmljZSBvbiBpZiB0aGlzIGlzIHBvc3NpYmxlIOKA kyBhbmQgd2hhdCB2ZXJzaW9uIEkgc2hvdWxkIHRyeSBJIHdpdGggaWYgc28uCsKgCldlIGFyZSBh IGhlYXZpbHkgVk13YXJlIG9yaWVudGVkIGNvbXBhbnnigKYgYnV0IEkgYW0gdHJ5aW5nIHRvIGdl dCBSSEVWL29WaXJ0IGluIHRoZSBkb29yLsKgIEhvbmVzdGx5IEkgd291bGQgcHJlZmVyIG9WaXJ0 LCBidXQgaWYgdGhleSBpbnNpc3Qgb24gZW50ZXJwcmlzZSBzdXBwb3J0IEkgZ28gdG8gUmVkaGF0 LgrCoApTbyBJIGhhdmUgaGFkIGEgcGxheSB3aXRoIFZNd2FyZSBWU0FOIGFuZCBrbm93IGhvdyBp dCB3b3Jrcy7CoCBJIGFtIHRyeWluZyB0byBtb3JlIG9yIGxlc3MgcmVwbGljYXRlIHRoaXMgc2V0 dXAgdXNpbmcgb3BlbiBzb3VyY2UuCsKgClNvIFZTQU4gdXNlcyAzIG9yIG1vcmUgRVNYaSBub2Rl cywgd2l0aCBsb2NhbCBoYXJkZGlza3MgYXMgdGhlIHN0b3JhZ2UgbWVkaXVtIGFzIGEgdmlydHVh bCBTQU4uwqAgVGhlIFNBTiBwZXJmb3JtYW5jZSBpcyBxdWl0ZSBoaWdoIGFzIHlvdSBwdXQgYXQg bGVhc3QgMSBTU0QgaW4gZWFjaCBub2RlLgrCoApXaGF0IGlzIG5pY2UgaXMgeW91IGRvbuKAmXQg aGF2ZSB0aGUgTkFTIGVsZW1lbnQgaGVyZS7CoCBWTXMgYXJlIG9uIHRoZSBsb2NhbCBzdG9yYWdl LCB3aGljaCBpcyBwYXJ0aWFsbHkgU1NELCBzbyBwZXJmb3JtYW5jZSBpcyBxdWl0ZSBnb29kLgrC oApJIHdlbnQgdG8gYSBSZWRoYXQgcHJlc2VudGF0aW9uIG9uIFJlZGhhdCBzdG9yYWdlIGFuZCBH bHVzdGVyRlMgYW5kIGJhc2ljYWxseSB0aGlzIGFjdHMgYXMgYSBiaWcgc29mdHdhcmUgZGVmaW5l ZCBOQVMgd2hpY2ggZG9lcyBzb21lIHByZXR0eSBjb29sIHRoaW5ncywgYnV0IHRoYXTigJlzIG5v dCBleGFjdGx5IHdoYXQgSSBuZWVkLgrCoApJIHdvdWxkIGxpa2UgdG8gYnVpbGQgb1ZpcnQgb24g dG9wIG9mIENlbnRPUyBPc3PigKYgdGhhdCBoYXZlIGxvY2FsIHN0b3JhZ2UgaW4gdGhlbSB0aGF0 IGlzIGRpc3RyaWJ1dGVkIGFuZCByZWR1bmRhbnQgaW4gdGhlIGV2ZW50IG9mIGEgbm9kZSBmYWls dXJlLgrCoApBbmQgSSBwcm9iYWJseSBuZWVkIHRvIHRyeSBhbmQgYnVpbGQgdGhpcyBpbiBhIGxh YiB1bmRlciBGdXNpb24gb24gbXkgTWFjIEJvb2sgcHJvIHRvIGJlZ2luIHdpdGggYW55d2F5ICh0 aGF0IGJpdCBJ4oCZbSBmYXJpbHkgY29uZmlkZW50IHdpdGgpIGFuZCBpZiBJIGdldCB0aGF0IHdv cmtpbmcgY2FuIHByb2JhYmx5IGdldCBzb21lIG9sZGVyIGtpdCB0byB0cnkgaXQgb3V0IGZvciBy ZWFsIGFzIGEgUG9DIHRvIGZldwogcGVvcGxlLgrCoApTbywgSeKAmXZlIHNldCB1cCBvVmlydCBi ZWZvcmUgdGhhdCBzaG91bGQgYmUgb2ssIEkgaGF2ZW7igJl0IHNldHVwIEdsdXN0ZXIgaXMgdGhl cmUgYW55IGRvY3VtZW50cyB0aGF0IHdvdWxkIGhlbHAgbWUgZG93biB0aGlzIHJvYWQgYW5kIG1h a2Ugc3VyZSBJIHN0YXJ0IG91dCB1c2luZyB0aGUgYmVzdCB2ZXJzaW9uLgrCoApBbnkgYWR2aWNl IG9yIHBvaW50ZXJzIHdvdWxkIGJlIGdyYXRlZnVsbHkgcmVjZWl2ZWQuCsKgClRoYW5rcwrCoAoK CgoKQmlsbCBEb3NzZXR0ClN5c3RlbXMgQXJjaGl0ZWN0CgoKCgpUZWNoIENlbnRyYWwg4oCTIEds b2JhbCBFbmdpbmVlcmluZyBTZXJ2aWNlcwrCoApUwqArNDQgKDApMTkyMyAyNzkzNTMKTcKgKzQ0 ICgwKTc3NyA1OTAgODYxMgpiaWxsLmRvc3NldHRAcGIuY29tCnBpdG5leWJvd2VzLmNvbQoKClBp dG5leSBCb3dlcwo2IEhlcmN1bGVzIFdheSB8IExlYXZlc2RlbiB8IFdEMjUgN0dTIHwgVUsKwqAK CgoKCgoKCkxlYXJuIG1vcmUgYWJvdXQgR2xvYmFsIEVuZ2luZWVyaW5nIFNlcnZpY2VzCsKgCklu IEVuZ2luZWVyaW5nPwpSYWlzZSBhIHRpY2tldCB2aWEgUmVtZWR5IEFueXdoZXJlIFtIRVJFXcKg dGFrZXMKIGxlc3MgdGhhbiBhIG1pbnV0ZQrCoApDbG91ZEZvcm1zIFVzZXIgR3VpZGUgYXZhaWxh YmxlwqBbSEVSRV0KCgoKCsKgCsKgCsKgCgoKCsKgCgoKCgoKCgo= ----_com.android.email_67919836813260 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT4KICAgIAo8ZGl2Pk15IHByb2plY3Qg aXMgZnJlZSBhbmQgb3Blbi4gV2hhdCB3b3VsZCB5b3UgbGlrZSB0byBrbm93PzwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+LURvbm55IEQ8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PllvdSBjYW4g YWxzbyBnaXZlIG1lIGEgY2FsbCBhdCA4MDUgODE0IDY4MDAgaWYgdGhlIHBob25lIGlzIGJldHRl ciBmb3IgeW91LiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1z aXplOjg1JTtjb2xvcjojNTc1NzU3Ij5IYXBweSBDb25uZWN0aW5nLiBTZW50IGZyb20gbXkgU3By aW50IFNhbXN1bmcgR2FsYXh5IFPCriA1PC9kaXY+PC9kaXY+PGJyPjxicj4tLS0tLS0tLSBPcmln aW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJyPkZyb206IEJpbGwgRG9zc2V0dCAmbHQ7YmlsbC5kb3Nz ZXR0QHBiLmNvbSZndDsgPGJyPkRhdGU6IDAyLzE4LzIwMTUgIDEwOjM3IEFNICAoR01ULTA3OjAw KSA8YnI+VG86IHVzZXJzQG92aXJ0Lm9yZyA8YnI+U3ViamVjdDogW292aXJ0LXVzZXJzXSBGVzog IG92aXJ0IGFuZCBnbHVzdGVyZnMgc2V0dXAgPGJyPjxicj4KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNvcnJ5LCBmb3Jnb3QgdG8gY29weWFsbOKApjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4KPGRpdj4KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIj4gQmlsbCBEb3NzZXR0IHM8YnI+CjxiPlNlbnQ6PC9iPiAxOCBGZWJydWFyeSAyMDE1IDE3 OjM3PGJyPgo8Yj5Ubzo8L2I+ICdEb25ueSBEYXZpcyc8YnI+CjxiPlN1YmplY3Q6PC9iPiBSRTog W292aXJ0LXVzZXJzXSBvdmlydCBhbmQgZ2x1c3RlcmZzIHNldHVwPG86cD48L286cD48L3NwYW4+ PC9wPgo8L2Rpdj4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2VsbCwgaXQgc2VlbXMgdG8gYmUgc29tZXRoaW5nIHRo YXQgUmVkSGF0IHdlcmUgc2F5aW5nIHdhcyBnb2luZyB0byBiZSBzdXBwb3J0ZWQuPG86cD48L286 cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBhbSBmYXIgbW9yZSBmYW1pbGlhciB3aXRoIFZNd2Fy ZSBWU0FOIGFuZCB0aGF0IGlzIGN1cnJlbnQgYSBWRVJZIGhvdCB0b3BpYy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5XaXRoIFZNd2FyZSBIQSBhbmQgVlNBTiBjYXBhYmlsaXRpZXMg YW5kIG5ldyBjaGFzc2lzIGNvbWluZyBvdXQgd2l0aCB2ZXJ5IGhpZ2ggZGVuc2l0eSBkcml2ZSBj YXBhYmlsaXRpZXMgYW5kIHRoZSBjb3JyZWN0IG51bWJlciBvZiBub2RlcywgeW91IGNhbiBsb3Nl IGEgbm9kZSB3aXRoIG5vIG1vcmUgZG93bnRpbWUKIHRoYW4gaWYgY29tcHV0ZSBhbmQgc3RvcmFn ZSBhcmUgc2VwYXJhdGVkIGFuZCBpdOKAmXMgYSBoZWxsdXZhIGxvdCBsZXNzIGV4cGVuc2l2ZSB0 aGFuIHRyYWRpdGlvbmFsIEZpYnJlIFNBTi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5TYXlpbmcgdGhhdCBpdCBpcyBpbiBpdOKAmXMgaW5mYW5jeS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5J4oCZbSBpbnRlcmVzdGVkIGluIHlvdXIgb3ZpcnQgZGVwbG95bWVudCDi gJMgdGhhbmtzIGZvciB0aGUga2luZCBvZmZlciAtIGJ1dCB2ZXJ5IHNob3J0IG9uIHRpbWUgYXMg d2VsbCBhcyB0aGlzIGlzIGEgc2lkZSBwcm9qZWN0IOKAkyBzbyB0aGlzIG1heSBtb3ZlIGF0IGEg c25haWxzIHBhY2XigKYgc28gSSB0aG91Z2h0IEkgY291bGQKIGdldCBzdGFydGVkIG9uIG15IG93 bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHRoaW5rIEkgaW5zdGFzbGxlZCBv dmlydCAzLjIgcHJldmlvdXNseeKApiBhbmQgSSBkaWQgc2VlIG1lbnRpb24gb2YgR2x1c3RlciBE b21haW5zLiZuYnNwOyBJZiB5b3UgbGV0IG1lIGtub3cgd2hhdCBJIG5lZWQgdG8gZG8gdG8gaGF2 ZSBhIGxvb2sgYXQgeW91ciBkZXBsb3ltZW50IEkgd291bGQgYXBwcmVjaWF0ZSBpdC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIG1heSBiZSBzbG93IGF0IHJlc3BvbmRpbmcgdGhv dWdoIGFzIEkgYW0gc3ByZWFkIHZlcnkgdGhpbiByaWdodCBub3cuPG86cD48L286cD48L3NwYW4+ PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+QmlsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4KPGRpdj4KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPgo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gRG9ubnkgRGF2aXMgWzxhIGhyZWY9Im1haWx0bzpkb25ueUBjbG91ZHNwaW4u bWUiPm1haWx0bzpkb25ueUBjbG91ZHNwaW4ubWU8L2E+XQo8YnI+CjxiPlNlbnQ6PC9iPiAxOCBG ZWJydWFyeSAyMDE1IDEzOjMwPGJyPgo8Yj5Ubzo8L2I+IEJpbGwgRG9zc2V0dDxicj4KPGI+U3Vi amVjdDo8L2I+IFJFOiBbb3ZpcnQtdXNlcnNdIG92aXJ0IGFuZCBnbHVzdGVyZnMgc2V0dXA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8L2Rpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBjYW4gdGVsbCB5b3UgZnJvbSBteSBleHBlcmllbmNl IHRoYXQgeW91IHNob3VsZCBoYXZlIHlvdXIgc3RvcmFnZSBhbmQgY29tcHV0ZSBub2RlIHNlcGFy YXRlLiBHbHVzdGVyIHN1cHBvcnQgaXMgYnVpbHQgaW50byBvdmlydCwgYW5kIHlvdSBqdXN0IG5l ZWQgdG8gbWFrZSBzdXJlIHdoZW4gc2V0dGluZyB1cCB5b3VyIGVuZ2luZSB5b3UKIHRlbGwgaXQg dG8gYmUgW2JvdGhdPG86cD48L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5UaGUgYXJjaGl0ZWN0dXJlIHlvdSBkZXNjcmliZSB3aGV0aGVyIGl0 IGJlIHZtd2FyZSBvciBvdmlydCBpcyBkZXN0aW5lZCB0byBiZSBhIGRpc2FzdGVyLiAmbmJzcDtU aGF0IGlzIG15IG1hdHRlciBvZiBvcGluaW9uIGJhc2VkIG9uIG15IGV4cGVyaWVuY2UuICZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+SSBoYXZlIGEgZnJlZSB0byB1c2Ugb3ZpcnQgZGVwbG95bWVudCB0aGF0IHlvdSBjb3Vs ZCBydW4geW91ciBkZXNpcmVkIHNldHVwIG9uLgo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkRvbm55IEQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPmNsb3Vkc3Bpbi5t ZSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pgo8ZGl2Pgo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+CjxhIGhyZWY9Im1haWx0 bzp1c2Vycy1ib3VuY2VzQG92aXJ0Lm9yZyI+dXNlcnMtYm91bmNlc0BvdmlydC5vcmc8L2E+IFs8 YSBocmVmPSJtYWlsdG86dXNlcnMtYm91bmNlc0BvdmlydC5vcmciPm1haWx0bzp1c2Vycy1ib3Vu Y2VzQG92aXJ0Lm9yZzwvYT5dCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmlsbCBEb3NzZXR0PGJyPgo8 Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAxOCwgMjAxNSA0OjMzIEFNPGJyPgo8Yj5U bzo8L2I+IDxhIGhyZWY9Im1haWx0bzp1c2Vyc0BvdmlydC5vcmciPnVzZXJzQG92aXJ0Lm9yZzwv YT48YnI+CjxiPlN1YmplY3Q6PC9iPiBbb3ZpcnQtdXNlcnNdIG92aXJ0IGFuZCBnbHVzdGVyZnMg c2V0dXA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8L2Rpdj4KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBpbiBhdCB0 aGUgZGVlcCBlbmTigKY8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxvb2tpbmcgZm9yIHNvbWUgYWR2 aWNlIG9uIGlmIHRoaXMgaXMgcG9zc2libGUg4oCTIGFuZCB3aGF0IHZlcnNpb24gSSBzaG91bGQg dHJ5IEkgd2l0aCBpZiBzby48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFyZSBhIGhlYXZpbHkg Vk13YXJlIG9yaWVudGVkIGNvbXBhbnnigKYgYnV0IEkgYW0gdHJ5aW5nIHRvIGdldCBSSEVWL29W aXJ0IGluIHRoZSBkb29yLiZuYnNwOyBIb25lc3RseSBJIHdvdWxkIHByZWZlciBvVmlydCwgYnV0 IGlmIHRoZXkgaW5zaXN0IG9uIGVudGVycHJpc2Ugc3VwcG9ydCBJIGdvIHRvIFJlZGhhdC48bzpw PjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNvIEkgaGF2ZSBoYWQgYSBwbGF5IHdpdGggVk13YXJlIFZTQU4g YW5kIGtub3cgaG93IGl0IHdvcmtzLiZuYnNwOyBJIGFtIHRyeWluZyB0byBtb3JlIG9yIGxlc3Mg cmVwbGljYXRlIHRoaXMgc2V0dXAgdXNpbmcgb3BlbiBzb3VyY2UuPG86cD48L286cD48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TbyBWU0FOIHVzZXMgMyBvciBtb3JlIEVTWGkgbm9kZXMsIHdpdGggbG9jYWwgaGFyZGRp c2tzIGFzIHRoZSBzdG9yYWdlIG1lZGl1bSBhcyBhIHZpcnR1YWwgU0FOLiZuYnNwOyBUaGUgU0FO IHBlcmZvcm1hbmNlIGlzIHF1aXRlIGhpZ2ggYXMgeW91IHB1dCBhdCBsZWFzdCAxIFNTRCBpbiBl YWNoIG5vZGUuPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGlzIG5pY2UgaXMgeW91IGRvbuKA mXQgaGF2ZSB0aGUgTkFTIGVsZW1lbnQgaGVyZS4mbmJzcDsgVk1zIGFyZSBvbiB0aGUgbG9jYWwg c3RvcmFnZSwgd2hpY2ggaXMgcGFydGlhbGx5IFNTRCwgc28gcGVyZm9ybWFuY2UgaXMgcXVpdGUg Z29vZC48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2VudCB0byBhIFJlZGhhdCBwcmVzZW50YXRp b24gb24gUmVkaGF0IHN0b3JhZ2UgYW5kIEdsdXN0ZXJGUyBhbmQgYmFzaWNhbGx5IHRoaXMgYWN0 cyBhcyBhIGJpZyBzb2Z0d2FyZSBkZWZpbmVkIE5BUyB3aGljaCBkb2VzIHNvbWUgcHJldHR5IGNv b2wgdGhpbmdzLCBidXQgdGhhdOKAmXMgbm90IGV4YWN0bHkgd2hhdCBJIG5lZWQuPG86cD48L286 cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHdvdWxkIGxpa2UgdG8gYnVpbGQgb1ZpcnQgb24gdG9wIG9mIENlbnRP UyBPc3PigKYgdGhhdCBoYXZlIGxvY2FsIHN0b3JhZ2UgaW4gdGhlbSB0aGF0IGlzIGRpc3RyaWJ1 dGVkIGFuZCByZWR1bmRhbnQgaW4gdGhlIGV2ZW50IG9mIGEgbm9kZSBmYWlsdXJlLjxvOnA+PC9v OnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QW5kIEkgcHJvYmFibHkgbmVlZCB0byB0cnkgYW5kIGJ1aWxkIHRoaXMg aW4gYSBsYWIgdW5kZXIgRnVzaW9uIG9uIG15IE1hYyBCb29rIHBybyB0byBiZWdpbiB3aXRoIGFu eXdheSAodGhhdCBiaXQgSeKAmW0gZmFyaWx5IGNvbmZpZGVudCB3aXRoKSBhbmQgaWYgSSBnZXQg dGhhdCB3b3JraW5nIGNhbiBwcm9iYWJseSBnZXQgc29tZSBvbGRlciBraXQgdG8gdHJ5IGl0IG91 dCBmb3IgcmVhbCBhcyBhIFBvQyB0byBmZXcKIHBlb3BsZS48bzpwPjwvbzpwPjwvcD4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PlNvLCBJ4oCZdmUgc2V0IHVwIG9WaXJ0IGJlZm9yZSB0aGF0IHNob3VsZCBiZSBvaywgSSBoYXZl buKAmXQgc2V0dXAgR2x1c3RlciBpcyB0aGVyZSBhbnkgZG9jdW1lbnRzIHRoYXQgd291bGQgaGVs cCBtZSBkb3duIHRoaXMgcm9hZCBhbmQgbWFrZSBzdXJlIEkgc3RhcnQgb3V0IHVzaW5nIHRoZSBi ZXN0IHZlcnNpb24uPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbnkgYWR2aWNlIG9yIHBvaW50ZXJz IHdvdWxkIGJlIGdyYXRlZnVsbHkgcmVjZWl2ZWQuPG86cD48L286cD48L3A+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFu a3M8bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+Cjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9 IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNjQwIiBzdHlsZT0id2lkdGg6NDgwLjBwdCI+Cjx0 Ym9keT4KPHRyPgo8dGQgd2lkdGg9IjY0MCIgc3R5bGU9IndpZHRoOjQ4MC4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSAwY20iPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMwMDgyRDUiPkJpbGwgRG9zc2V0dDwvc3Bhbj48L2I+PG86cD48L286 cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlN5 c3RlbXMgQXJjaGl0ZWN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8L3RkPgo8L3RyPgo8dHI+Cjx0 ZCB3aWR0aD0iNjQwIiBzdHlsZT0id2lkdGg6NDgwLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBj bSI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRl Y2ggQ2VudHJhbCDigJMgR2xvYmFsIEVuZ2luZWVyaW5nIFNlcnZpY2VzPC9zcGFuPjwvYj48bzpw PjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7KzQ0ICgwKTE5MjMgMjc5MzUzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsrNDQgKDApNzc3IDU5MCA4 NjEyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJt YWlsdG86amVmZi5nb256YWxlekBwYi5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6cHVycGxlIj5iPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMw MDgyRDUiPjxhIGhyZWY9Im1haWx0bzppbGwuZG9zc2V0dEBwYi5jb20iPjxzcGFuIHN0eWxlPSJj b2xvcjpibHVlIj5pbGwuZG9zc2V0dEBwYi5jb208L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA4MkQ1Ij48YSBocmVm PSJwaXRuZXlib3dlcy5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA4MkQ1Ij5waXRuZXlib3dl cy5jb208L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4KPC9zcGFuPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPlBpdG5leSBCb3dlczwvc3Bhbj48L2I+PG86cD48L286cD48L3A+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjYgSGVyY3Vs ZXMgV2F5IHwgTGVhdmVzZGVuIHwgV0QyNSA3R1MgfCBVSzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPgo8L3RkPgo8L3RyPgo8dHI+Cjx0ZCB3aWR0aD0iNjQwIiBzdHls ZT0id2lkdGg6NDgwLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+PC90ZD4KPC90cj4KPHRy Pgo8dGQgd2lkdGg9IjY0MCIgc3R5bGU9IndpZHRoOjQ4MC4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSAwY20iPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMwMDgyRDUiPjxhIGhyZWY9Imh0dHA6Ly90ZWFtc2l0ZS5pbnNpZGUucGIuY29tL3NpdGVz L1RDUFBNL0dFUy9TaXRlUGFnZXMvSG9tZS5hc3B4Ij48c3BhbiBzdHlsZT0iY29sb3I6IzAwODJE NSI+TGVhcm4gbW9yZSBhYm91dCBHbG9iYWwgRW5naW5lZXJpbmcgU2VydmljZXM8L3NwYW4+PC9h Pjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2Ut YnJlYWstYWZ0ZXI6YXZvaWQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWst YWZ0ZXI6YXZvaWQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkluIEVuZ2luZWVyaW5nPzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+UmFpc2UgYSB0aWNrZXQgdmlhIFJlbWVkeSBBbnl3aGVyZSBbPHNwYW4g c3R5bGU9ImNvbG9yOiMwMDgyRDUiPjxhIGhyZWY9InRlYW1zaXRlLmluc2lkZS5wYi5jb20vc2l0 ZXMvVENQUE0vR0VTL0xpc3RzL0NyZWF0ZSUyMEluY2lkZW50L25ld0luY2lkZW50LmFzcHgiPjxz cGFuIHN0eWxlPSJjb2xvcjojMDA4MkQ1Ij5IRVJFPC9zcGFuPjwvYT48L3NwYW4+XTxzcGFuIHN0 eWxlPSJjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+dGFrZXMKIGxlc3MgdGhhbiBhIG1pbnV0ZTwv c3Bhbj48L2I+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L2I+PG86cD48L286cD48L3A+CjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNsb3VkRm9ybXMg VXNlciBHdWlkZSBhdmFpbGFibGU8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwO1s8Yj48c3BhbiBzdHlsZT0iY29sb3I6IzAwODJENSI+PGEgaHJlZj0iaHR0cHM6Ly9k bC5kcm9wYm94dXNlcmNvbnRlbnQuY29tL3UvNjIxOTQ0MS9NYW5hZ2VJUSUyMC0lMjBVc2VyJTIw TWFudWFsJTIwUEIlMjB2NS5wZGYiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA4MkQ1Ij5IRVJFPC9z cGFuPjwvYT48L3NwYW4+PC9iPl08L3NwYW4+PG86cD48L286cD48L3A+CjwvdGQ+CjwvdHI+Cjwv dGJvZHk+CjwvdGFibGU+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxkaXYg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVy Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPgo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEw MCUiIGFsaWduPSJjZW50ZXIiPgo8L3NwYW4+PC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pgo8L2Rpdj4KPGJyPgo8aHI+Cjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iQmxhY2siIHNpemU9 IjIiPjxicj4KPC9mb250Pgo8L2JvZHk+PC9odG1sPg== ----_com.android.email_67919836813260--

1 0

FW: ovirt and glusterfs setup
by Bill Dossett 18 Feb '15

18 Feb '15

--_000_B47F00825D68444ABC037330782753603771B72A013BR1MPN1012MG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, forgot to copyall... From: Bill Dossett s Sent: 18 February 2015 17:37 To: 'Donny Davis' Subject: RE: [ovirt-users] ovirt and glusterfs setup Well, it seems to be something that RedHat were saying was going to be supp= orted. I am far more familiar with VMware VSAN and that is current a VERY hot topi= c. With VMware HA and VSAN capabilities and new chassis coming out with very h= igh density drive capabilities and the correct number of nodes, you can los= e a node with no more downtime than if compute and storage are separated an= d it's a helluva lot less expensive than traditional Fibre SAN. Saying that it is in it's infancy. I'm interested in your ovirt deployment - thanks for the kind offer - but v= ery short on time as well as this is a side project - so this may move at a= snails pace... so I thought I could get started on my own. I think I instaslled ovirt 3.2 previously... and I did see mention of Glust= er Domains. If you let me know what I need to do to have a look at your de= ployment I would appreciate it. I may be slow at responding though as I am spread very thin right now. Thanks Bill From: Donny Davis [mailto:donny@cloudspin.me] Sent: 18 February 2015 13:30 To: Bill Dossett Subject: RE: [ovirt-users] ovirt and glusterfs setup I can tell you from my experience that you should have your storage and com= pute node separate. Gluster support is built into ovirt, and you just need = to make sure when setting up your engine you tell it to be [both] The architecture you describe whether it be vmware or ovirt is destined to = be a disaster. That is my matter of opinion based on my experience. I have a free to use ovirt deployment that you could run your desired setup= on. Donny D cloudspin.me From: users-bounces(a)ovirt.org<mailto:users-bounces@ovirt.org> [mailto:users= -bounces(a)ovirt.org] On Behalf Of Bill Dossett Sent: Wednesday, February 18, 2015 4:33 AM To: users(a)ovirt.org<mailto:users@ovirt.org> Subject: [ovirt-users] ovirt and glusterfs setup Hi, I'm in at the deep end... Looking for some advice on if this is possible - and what version I should = try I with if so. We are a heavily VMware oriented company... but I am trying to get RHEV/oVi= rt in the door. Honestly I would prefer oVirt, but if they insist on enter= prise support I go to Redhat. So I have had a play with VMware VSAN and know how it works. I am trying t= o more or less replicate this setup using open source. So VSAN uses 3 or more ESXi nodes, with local harddisks as the storage medi= um as a virtual SAN. The SAN performance is quite high as you put at least= 1 SSD in each node. What is nice is you don't have the NAS element here. VMs are on the local = storage, which is partially SSD, so performance is quite good. I went to a Redhat presentation on Redhat storage and GlusterFS and basical= ly this acts as a big software defined NAS which does some pretty cool thin= gs, but that's not exactly what I need. I would like to build oVirt on top of CentOS Oss... that have local storage= in them that is distributed and redundant in the event of a node failure. And I probably need to try and build this in a lab under Fusion on my Mac B= ook pro to begin with anyway (that bit I'm farily confident with) and if I = get that working can probably get some older kit to try it out for real as = a PoC to few people. So, I've set up oVirt before that should be ok, I haven't setup Gluster is = there any documents that would help me down this road and make sure I start= out using the best version. Any advice or pointers would be gratefully received. Thanks Bill Dossett Systems Architect Tech Central - Global Engineering Services T +44 (0)1923 279353 M +44 (0)777 590 8612 b<mailto:jeff.gonzalez@pb.com>ill.dossett(a)pb.com<mailto:ill.dossett@pb.com> pitneybowes.com Pitney Bowes 6 Hercules Way | Leavesden | WD25 7GS | UK Learn more about Global Engineering Services<http://teamsite.inside.pb.com/= sites/TCPPM/GES/SitePages/Home.aspx> In Engineering? Raise a ticket via Remedy Anywhere [HERE<teamsite.inside.pb.com/sites/TCPPM= /GES/Lists/Create%20Incident/newIncident.aspx>] takes less than a minute CloudForms User Guide available [HERE<https://dl.dropboxusercontent.com/u/6= 219441/ManageIQ%20-%20User%20Manual%20PB%20v5.pdf>] ________________________________ ________________________________ --_000_B47F00825D68444ABC037330782753603771B72A013BR1MPN1012MG_ 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-GB" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Sorry, forgot to copyall…<o:p></o:p> <o:p> </o:p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> From: Bill Dossett s Sent: 18 February 2015 17:37 To: 'Donny Davis' Subject: RE: [ovirt-users] ovirt and glusterfs setup<o:p></o:p></spa= n> </div> </div> <o:p> </o:p> Well, it seems to be something that RedHat were saying was going to be= supported.<o:p></o:p> <o:p> </o:p> I am far more familiar with VMware VSAN and that is current a VERY hot= topic.<o:p></o:p> <o:p> </o:p> With VMware HA and VSAN capabilities and new chassis coming out with v= ery high density drive capabilities and the correct number of nodes, you ca= n lose a node with no more downtime than if compute and storage are separated and it’s a helluva lot les= s expensive than traditional Fibre SAN.<o:p></o:p> <o:p> </o:p> Saying that it is in it’s infancy.<o:p></o:p> <o:p> </o:p> I’m interested in your ovirt deployment – thanks for the k= ind offer - but very short on time as well as this is a side project &#8211= ; so this may move at a snails pace… so I thought I could get started on my own.<o:p></o:p> <o:p> </o:p> I think I instaslled ovirt 3.2 previously… and I did see mention= of Gluster Domains.  If you let me know what I need to do to have a l= ook at your deployment I would appreciate it.<o:p></o:p> <o:p> </o:p> I may be slow at responding though as I am spread very thin right now.= <o:p></o:p> <o:p> </o:p> Thanks<o:p></o:p> Bill<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> From: Donny Davis [<a href=3D"mailto:donny@cloudspin.me">mailto:donny= @cloudspin.me</a>] Sent: 18 February 2015 13:30 To: Bill Dossett Subject: RE: [ovirt-users] ovirt and glusterfs setup<o:p></o:p></spa= n> </div> </div> <o:p> </o:p> I can t= ell you from my experience that you should have your storage and compute no= de separate. Gluster support is built into ovirt, and you just need to make= sure when setting up your engine you tell it to be [both]<o:p></o:p> <o:p>&n= bsp;</o:p> The arc= hitecture you describe whether it be vmware or ovirt is destined to be a di= saster.  That is my matter of opinion based on my experience.  <o= :p></o:p> <o:p>&n= bsp;</o:p> I have = a free to use ovirt deployment that you could run your desired setup on. <o:p></o:p> <o:p>&n= bsp;</o:p> Donny D= <o:p></o:p> <o:p>&n= bsp;</o:p> cloudsp= in.me <o:p></o:p> <o:p>&n= bsp;</o:p> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> From: <a href=3D"mailto:users-bounces@ovirt.org">users-bounces(a)ovirt.org</a> [<a = href=3D"mailto:users-bounces@ovirt.org">mailto:users-bounces@ovirt.org</a>] On Behalf Of Bill Dossett Sent: Wednesday, February 18, 2015 4:33 AM To: <a href=3D"mailto:users@ovirt.org">users(a)ovirt.org</a> Subject: [ovirt-users] ovirt and glusterfs setup<o:p></o:p></= p> </div> </div> <o:p> </o:p> Hi,<o:p></o:p> <o:p> </o:p> I’m in at the deep end…<o:p></o:p> <o:p> </o:p> Looking for some advice on if this is possible &#821= 1; and what version I should try I with if so.<o:p></o:p> <o:p> </o:p> We are a heavily VMware oriented company… but = I am trying to get RHEV/oVirt in the door.  Honestly I would prefer oV= irt, but if they insist on enterprise support I go to Redhat.<o:p></o:p></p= > <o:p> </o:p> So I have had a play with VMware VSAN and know how i= t works.  I am trying to more or less replicate this setup using open = source.<o:p></o:p> <o:p> </o:p> So VSAN uses 3 or more ESXi nodes, with local harddi= sks as the storage medium as a virtual SAN.  The SAN performance is qu= ite high as you put at least 1 SSD in each node.<o:p></o:p> <o:p> </o:p> What is nice is you don’t have the NAS element= here.  VMs are on the local storage, which is partially SSD, so perfo= rmance is quite good.<o:p></o:p> <o:p> </o:p> I went to a Redhat presentation on Redhat storage an= d GlusterFS and basically this acts as a big software defined NAS which doe= s some pretty cool things, but that’s not exactly what I need.<o:p></= o:p> <o:p> </o:p> I would like to build oVirt on top of CentOS Oss&#82= 30; that have local storage in them that is distributed and redundant in th= e event of a node failure.<o:p></o:p> <o:p> </o:p> And I probably need to try and build this in a lab u= nder Fusion on my Mac Book pro to begin with anyway (that bit I’m far= ily confident with) and if I get that working can probably get some older k= it to try it out for real as a PoC to few people.<o:p></o:p> <o:p> </o:p> So, I’ve set up oVirt before that should be ok= , I haven’t setup Gluster is there any documents that would help me d= own this road and make sure I start out using the best version.<o:p></o:p><= /p> <o:p> </o:p> Any advice or pointers would be gratefully received.= <o:p></o:p> <o:p> </o:p> Thanks<o:p></o:p> <o:p> </o:p> <table class=3D"MsoNormalTable" border=3D"0" cellspacing=3D"0" cellpadding= =3D"0" width=3D"640" style=3D"width:480.0pt"> <tbody> <tr> <td width=3D"640" style=3D"width:480.0pt;padding:0cm 0cm 0cm 0cm"> Bill Dossett<= o:p></o:p> Systems Architect<o:p></o:p> </td> </tr> <tr> <td width=3D"640" style=3D"width:480.0pt;padding:0cm 0cm 0cm 0cm"> Tech Central – Global Engineerin= g Services<o:p></o:p>  <o:p><= /o:p> T +44 (= 0)1923 279353<o:p></o:p> M +44 (= 0)777 590 8612<o:p></o:p> <a href=3D"mailto:jeff.gonzalez@pb.com">b</a><a href=3D"mailto:ill.dos= sett(a)pb.com">ill.dossett(a)pb.com</a></span= ><o:p></o:p> <a href=3D"pitneybowes.com"= >pitneybowes.com</a><o:p></o:p>= Pitney Bowes<o:p></o:p> 6 Hercules Way | Leavesden | WD25 7GS | U= K<o:p></o:p>  <o:p></o:p> </td> </tr> <tr> <td width=3D"640" style=3D"width:480.0pt;padding:0cm 0cm 0cm 0cm"></td> </tr> <tr> <td width=3D"640" style=3D"width:480.0pt;padding:0cm 0cm 0cm 0cm"> <a href=3D"http://teamsite.= inside.pb.com/sites/TCPPM/GES/SitePages/Home.aspx">Learn more about Global Engineering Services</a><o:p></= o:p>  </= span><o:p></o:p> In Engin= eering?<o:p></o:p> Raise a ticket via Remedy Anywhere [<s= pan style=3D"color:#0082D5"><a href=3D"teamsite.inside.pb.com/sites/TCPPM/G= ES/Lists/Create%20Incident/newIncident.aspx">= HERE</a>] takes less than a minute<o:p></o:p>  <o:p></o:p> CloudForms User Guide available=  [<a href=3D"https://d= l.dropboxusercontent.com/u/6219441/ManageIQ%20-%20User%20Manual%20PB%20v5.p= df">HERE</a>]<o:p></= o:p> </td> </tr> </tbody> </table> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center"><span= style=3D"font-size:12.0pt;font-family:"Times New Roman","se= rif""> <hr size=3D"2" width=3D"100%" align=3D"center"> </div> <o:p> </o:p> </div> <hr> </body> </html> --_000_B47F00825D68444ABC037330782753603771B72A013BR1MPN1012MG_--

1 0

oVirt Weekly Meeting Minutes -- 2015-01-21
by Yaniv Dary 18 Feb '15

18 Feb '15

Minutes: http://ovirt.org/meetings/ovirt/2015/ovirt.2015-01-21-15.01.html Minutes (text): http://ovirt.org/meetings/ovirt/2015/ovirt.2015-01-21-15.01.txt Log: http://ovirt.org/meetings/ovirt/2015/ovirt.2015-01-21-15.01.log.html ========================= #ovirt: oVirt Weekly Sync ========================= Meeting started by ydary_ at 15:01:35 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2015/ovirt.2015-01-21-15.01.log.html . Meeting summary --------------- * Agenda and roll Call (ydary_, 15:03:56) * infra update (ydary_, 15:04:15) * 3.5.z updates (ydary_, 15:04:16) * 3.6.0 status (ydary_, 15:04:16) * conferences and workshops (ydary_, 15:04:16) * other topics (ydary_, 15:04:16) * infra update (ydary_, 15:04:40) * sbonazzo resolved kernel based issues in some of the jobs. (doron, 15:13:12) * the teams need to start working\testing JDK 8, since JDK 7 EOL is in April 2015 (ydary_, 15:14:45) * some jenkins slaves had issues on running out of entropy, solved by installing haveged (ydary_, 15:16:21) * 3.6 memory errors in gwt resolved by vszocs (ydary_, 15:17:38) * progress in moving oVirt resources to phx lab (ydary_, 15:18:47) * ACTION: eedri to follow up on nightly issues with lvernia (ydary_, 15:20:28) * 3.5.z updates (ydary_, 15:08:07) * 3.5.1 to be released today. (ydary_, 15:22:42) * ACTION: please fill release notes, the page has been created here http://www.ovirt.org/OVirt_3.5.1_Release_Notes (ydary_, 15:23:19) * all open bugs on 3.5.1 will be re-targeted to 3.5.2 post the GA release (ydary_, 15:25:12) * 3.6 status (ydary_, 15:25:35) * 3.6.0 currently shows no blockers. There are 502 bugs targeted to 3.6.0. (ydary_, 15:26:55) * integration update on 3.6.0: added glusterfs support on hosted engine (for existing replica 3 gluster storage) (ydary_, 15:27:43) * integration update on 3.6.0: jboss-as 7.1 doesn't work at all with jdk 1.8 so for supporting fc21 we need to move to wildfly (ydary_, 15:30:36) * ACTION: oved to report next week on JDK 1.8 and wildfly status (ydary_, 15:32:42) * Host Network QoS and MAC pool per DC are in. Once 3.6 clusters can be created, it will be available. (ydary_, 15:35:38) * network 3.6 updates: currently nothing at risk. (ydary_, 15:36:23) * ceph-cinder integration have WIP patches. (ydary_, 15:38:34) * storage 3.6 updates: minor RFEs also making progress (ydary_, 15:39:05) * node 3.6 updates: currently no updates (ydary_, 15:41:42) * UX 3.6 updates: UI over REST api and tool tip infrastructure over patternfly making progress (ydary_, 15:44:44) * SLA 3.6 updates: SLA still in planning, no further updates. (ydary_, 15:45:46) * virt 3.6 updates: no one for virt team to update (ydary_, 15:47:18) * conferences and workshops (ydary_, 15:47:43) * conferences and workshops FOSDEM is a go. Booth schedules and talks are here at http://etherpad.ovirt.org/p/ovirt-fosdem-15 (ydary_, 15:50:33) * conferences and workshops After taking a quick poll, the FOSDEM social meetup will be Sat., Jan. 31, at 2030 in the Au Bon Vieux Temps, (ydary_, 15:50:33) * conferences and workshops The half-day workshop for FOSSAsia in Singapore is getting planned. The Korea user group has responded with interest now. (ydary_, 15:52:08) * conferences and workshops amureini will be giving a talk at DevConfCZ in Feb, after FOSDEM (ydary_, 15:52:08) * conferences and workshops oVCirt will have a very strong presense at SCALE 13X in LA this year. (ydary_, 15:52:08) * conferences and workshops sbonazzo and tirsboschi_ may be at 11th Intl. Conf. on Open Source Systems http://www.oss2015.org (ydary_, 15:52:08) * conferences and workshops As a general reminder: if you *ever* need slides for an oVirt presentation, there are many to choose from here: http://www.ovirt.org/OVirt_Slide_Decks They are all under CC license. (ydary_, 15:52:09) * other topics (ydary_, 15:52:36) * mskrivanek and tjelinek have approached me to start the process for launching moVirt as an incubator project within oVirt. This will be a mobile app that will enable users to manage oVirt on the go. This will likely supercede the Nomad project, which has not moved forward in years. We may need to retire the Nomad incubator. (ydary_, 15:56:23) * ACTION: bkp to looking into setting up an oVirt account in the Google Play store now, as well as checking trademarks, if any, for moVirt. (ydary_, 15:56:58) * bkp will have meeting with designers at FOSDEM to discuss the revamp of ovirt.org for 2015. (ydary_, 15:57:48) * bkp updates that in 2015, there will be a stronger focus on what it takes to get new users to oVirt to the final production stage. I will be holding meetings with other FOSS project community leads to build a map for this process. (ydary_, 15:58:18) * bkp updates that in 2015, there will be a stronger focus on what it takes to get new users to oVirt to the final production stage. he will be holding meetings with other FOSS project community leads to build a map for this process. (ydary_, 15:58:47) Meeting ended at 16:00:14 UTC. Action Items ------------ * eedri to follow up on nightly issues with lvernia * please fill release notes, the page has been created here http://www.ovirt.org/OVirt_3.5.1_Release_Notes * oved to report next week on JDK 1.8 and wildfly status * bkp to looking into setting up an oVirt account in the Google Play store now, as well as checking trademarks, if any, for moVirt. Action Items, by person ----------------------- * bkp * bkp to looking into setting up an oVirt account in the Google Play store now, as well as checking trademarks, if any, for moVirt. * eedri * eedri to follow up on nightly issues with lvernia * lvernia * eedri to follow up on nightly issues with lvernia * **UNASSIGNED** * please fill release notes, the page has been created here http://www.ovirt.org/OVirt_3.5.1_Release_Notes * oved to report next week on JDK 1.8 and wildfly status People Present (lines said) --------------------------- * ydary_ (90) * doron (29) * bkp (28) * eedri (25) * lvernia (22) * sbonazzo (22) * awels (5) * amureini (5) * ovirtbot (2) * fabiand (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 1

network drag and drop
by Nathanaël Blanchet 18 Feb '15

18 Feb '15

Hi all, With ovirt 3.5.1, I can't anymore drag and drop network on any physical or bonding interface, but right click attachment still works. Is it an expected behaviour or a bug?

3 4