- Users - oVirt List Archives

Re: [ovirt-users] oVirt VM backups
by Victor José Acosta Domínguez 27 Jul '17

27 Jul '17

Also you could try the option i created: http://blog.infratic.com/blog/2017/07/07/create-ovirtrhevs-vm-backup/ Victor Acosta

1 0

Add CentOS 7 host fails during setup validation with 'Cannot locate vdsm package, possible cause is incorrect channels.'
by Schorschi 27 Jul '17

27 Jul '17

Trying to add a CentOS 7 host to oVirt instance, but fails during setup validation with 'Cannot locate vdsm package, possible cause is incorrect channels.' Of course, given this is oVirt (not RHEV) and CentOS not RHEL, there is not any RHEL applicable channel. Anyone have this issue as well? Version of KVM host (CentOS)... Linux node01.dachshund-digital.org 3.10.0-514.26.2.el7.x86_64 #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux CentOS Linux release 7.3.1611 (Core) NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" CentOS Linux release 7.3.1611 (Core) CentOS Linux release 7.3.1611 (Core) Version of oVirt (and CentOS hosting oVirt)... Is release 4.1 per install http://resources.ovirt.org/pub/yum-repo/ovirt-release41.rpm Linux ovirt.dachshund-digital.org 3.10.0-514.26.2.el7.x86_64 #1 SMP Tue Jul 4 15:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux CentOS Linux release 7.3.1611 (Core) NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" CentOS Linux release 7.3.1611 (Core) CentOS Linux release 7.3.1611 (Core) Any help appreciated. Thanks.

2 1

Re: [ovirt-users] Help get oVirt's add featured on Stack Overflow
by Karli Sjöberg 27 Jul '17

27 Jul '17

1 0

Help get oVirt's add featured on Stack Overflow
by Allon Mureinik 27 Jul '17

27 Jul '17

Hi lists, Thanks to Eldan, we have a community ad for oVirt proposed on Stack Overflow [1]. Now, we need some upvotes (current threshold is 6) before SO starts serving it. Have a SO account? Want to help? Just drop by and upvote. Have a great weekend, Allon [1] https://meta.stackoverflow.com/a/351453/2422776

3 4

oVirt VM backups
by Abi Askushi 27 Jul '17

27 Jul '17

Hi All, For VM backups I am using some python script to automate the snapshot -> clone -> export -> delete steps (although with some issues when trying to backups a Windows 10 VM) I was wondering if there is there any plan to integrate VM backups in the GUI or what other recommended ways exist out there. Thanx, Abi

5 6

Windows 2016 Sysprep - Fixed IP
by Sven Achtelik 27 Jul '17

27 Jul '17

--_000_BFAB40933B3367488CE6299BAF8592D1014E52F1255BSOCRATESasl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I'm looking into configuring a Windows 2016 Template via Run Once to have a= n static IP. Is there any way to do that ? Maybe over the Sysrep Section ? = I didn't find an answer about how to use it or what syntax should be used ?= Must I put a complete answer file into it or will this section on overwrit= e specific parts of the original file that resides on the engine ? Thank you, Sven --_000_BFAB40933B3367488CE6299BAF8592D1014E52F1255BSOCRATESasl_ 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=3DGenerator content=3D"Micros= oft Word 15 (filtered medium)"><style></style></head><body lang=3DDE link=3D"#0563C1" v= link=3D"#954F72"><div class=3DWordSection1><p class=3DMsoNormal>Hi All, <o:= p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal>= <span lang=3DEN-US>I’m looking into configuring a Windows 2016 Templa= te via Run Once to have an static IP. Is there any way to do that ? Maybe o= ver the Sysrep Section ? I didn’t find an answer about how to use it = or what syntax should be used ? Must I put a complete answer file into it o= r will this section on overwrite specific parts of the original file that r= esides on the engine ? <o:p></o:p></span></p><p class=3DMsoNormal><span lan= g=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span lang=3DEN-= US>Thank you, <o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US= >Sven <o:p></o:p></span></p></div></body></html>= --_000_BFAB40933B3367488CE6299BAF8592D1014E52F1255BSOCRATESasl_--

2 4

Feature: Maximum memory size | BUG
by Ladislav Humenik 27 Jul '17

27 Jul '17

Hallo, after engine update to 4.1.2 from 4.0.6 we have following bug *Your Future Description: * Maximum memory value is stored in |VmBase.maxMemorySizeMb| property. It is validated against range [/memory of VM/, /*MaxMemorySizeInMB/], where /*MaxMemorySizeInMB/ is one of |VM32BitMaxMemorySizeInMB|, |VM64BitMaxMemorySizeInMB| and |VMPpc64BitMaxMemorySizeInMB| configuration options depending on selected operating system of the VM. Default value in webadmin UI is 4x size of memory. During migration of engine 4.0 -> 4.1 all VM-like entities will get max memory = 4x memory. If a VM (or template) is imported (from export domain, snapshot, external system) and doesn't have max memory set yet, the maximum value of max memory is set (|*MaxMemorySizeInMB| config options). *Our engine settings:* [root@ovirt]# engine-config -g VM64BitMaxMemorySizeInMB VM64BitMaxMemorySizeInMB: 8388608 version: 4.1 VM64BitMaxMemorySizeInMB: 8388608 version: 3.6 VM64BitMaxMemorySizeInMB: 8388608 version: 4.0 [root@ovirt# engine-config -g VM32BitMaxMemorySizeInMB VM32BitMaxMemorySizeInMB: 20480 version: general *Template: *engine=# select vm_guid,vm_name,mem_size_mb,max_memory_size_mb from vm_static where vm_name LIKE 'Blank'; vm_guid | vm_name | mem_size_mb | max_memory_size_mb --------------------------------------+---------+-------------+-------------------- 00000000-0000-0000-0000-000000000000 | Blank | 8192 | 32768 (1 row) *Created VM* - expected is mem_size_mb * VM64BitMaxMemorySizeInMB - we get mem_size_mb * 4 (default) *Engine: *engine=# select vm_guid,vm_name,mem_size_mb,max_memory_size_mb from vm_static where vm_name LIKE 'vm-hotplug%'; vm_guid | vm_name | mem_size_mb | max_memory_size_mb --------------------------------------+-------------+-------------+-------------------- 254a0c61-3c0a-41e7-a2ec-5f77cabbe533 | vm-hotplug | 1024 | 4096 c0794a03-58ba-4e68-8f43-e0320032830c | vm-hotplug2 | 3072 | 12288 (2 rows) *Question:* It is possible to change this (default * 4) behavior in DB?? Kind Regards, Ladislav Humenik, System administrator

3 5

Wrong CPU type set on ovirt node on ovirt version 3.6.4.1-1.el6 - anyone know a fix ?
by Joseph Kelly 26 Jul '17

26 Jul '17

--_000_CY1PR16MB0393574D1CEE59FBF5F2696288BE0CY1PR16MB0393namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Has anyone come across a fix for this, in that I have a one node cluster in= which the cluster CPU type is reporting correctly as: Cluster CPU Type:Intel SandyBridge Family But the only node is showing: CPU Type:Intel Haswell-noTSX Family However on my node both vdsm and cpuinfo agree on the the cpu model its jus= t that webadmin GUI is reporting "Intel Haswell-noTSX Family" as the CPU type. # vdsClient -s 0 getVdsCapabilities | egrep -i cpuModel cpuModel =3D 'Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz' #cat /proc/cpuinfo | grep "model name" | head -n 1 model name : Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz We're still using ovirt t version 3.6.4.1-1.el6 but are trying to move to 4= .1.x And I suspect that a possible fix might to do this: 1) shutdown VM's on the problem node put it into maintenance mode and onlin= e it again. 2) if that doesn't work then put into maintenance mode again and restart vd= smd and online the node again. or does this need to be directly updated in the postgres DB for that node ?= If so does anyone know how to do that ? Thanks, Joe. -- J. Kelly Infrastructure Engineer TradingScreen www.tradingscreen.com<http://www.tradingscreen.com/> --_000_CY1PR16MB0393574D1CEE59FBF5F2696288BE0CY1PR16MB0393namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"></style> </head> <body dir=3D"ltr"> <div id=3D"divtagdefaultwrapper" style=3D"font-size:10pt;color:#000000;font= -family:Verdana,Geneva,sans-serif;" dir=3D"ltr"> <p></p> <div><span style=3D"font-family: Verdana, Geneva, sans-serif;">Hello,</span= ></div> <div><br> </div> <div><span style=3D"font-family: Verdana, Geneva, sans-serif;">Has anyone c= ome across a fix for this, in that I have a one node cluster in which the c= luster CPU type is reporting correctly as:</span></div> <div><span style=3D"font-size: 10pt; font-family: Verdana, Geneva, sans-ser= if;">Cluster CPU Type:</span><span style=3D"font-size: 10pt; font-family: V= erdana, Geneva, sans-serif;">Intel SandyBridge Family</span><br> </div> <p></p> <p><span style=3D"font-size: 10pt;"><br> </span></p> <p><span style=3D"font-size: 10pt; font-family: Verdana, Geneva, sans-serif= ;">But the only node is showing: </span><br> </p> <p><span style=3D"font-size: 10pt; font-family: Verdana, Geneva, sans-serif= ;">CPU Type:</span><span style=3D"font-size: 10pt; font-family: Verdana, Ge= neva, sans-serif;">Intel Haswell-noTSX Family</span><br> </p> <p></p> <div><br> </div> <div><span style=3D"font-size: 10pt;"><span style=3D"font-family: Verdana, = Geneva, sans-serif;">However on my node </span><span style=3D"font-fam= ily: Verdana, Geneva, sans-serif;">both vdsm and cpuinfo agree on the the c= pu model its just that webadmin GUI is reporting </span></span><br> </div> <div><span style=3D"font-family: Verdana, Geneva, sans-serif;">"Intel = Haswell-noTSX Family" as the CPU type.</span></div> <div><br> </div> <div> <div><span style=3D"font-family: Verdana, Geneva, sans-serif;"># vdsClient = -s 0 getVdsCapabilities | egrep -i cpuModel</span></div> <div><span style=3D"white-space: pre; font-family: Verdana, Geneva, sans-se= rif;"></span><span style=3D"font-family: Verdana, Geneva, sans-serif;">cpuM= odel =3D 'Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz'</span></div> <div><span style=3D"font-family: Verdana, Geneva, sans-serif;">#cat /proc/c= puinfo | grep "model name" | head -n 1</span></div> <div><span style=3D"font-family: Verdana, Geneva, sans-serif;">model name</= span><span style=3D"white-space: pre; font-family: Verdana, Geneva, sans-se= rif;"> </span><span style=3D"font-family: Verdana, Geneva, sans-serif;">: Intel(R)= Xeon(R) CPU E5-2670 v3 @ 2.30GHz</span></div> <div><br> </div> <span style=3D"font-family: Verdana, Geneva, sans-serif;">We're still = </span><span style=3D"font-family: Verdana, Geneva, sans-serif;">using ovir= t </span><span style=3D"font-family: Verdana, Geneva, sans-serif;">t v= ersion 3.6.4.1-1.el6 but are trying to move to 4.1.x</span></div> <div><span><br> </span></div> <div><span><span style=3D"font-family: Verdana, Geneva, sans-serif;">And&nb= sp;I suspect that a possible </span><span style=3D"font-family: Verdan= a, Geneva, sans-serif;">fix might to do this:</span></span></div> <div><span><br> </span></div> <div><span><span style=3D"font-family: Verdana, Geneva, sans-serif;">1)&nbs= p;</span><span style=3D"font-family: Verdana, Geneva, sans-serif;">shutdown= VM's on the problem node put it into maintenance</span><span style=3D"font= -family: Verdana, Geneva, sans-serif;"> mode and online it again.</span></span></div> <div><span><span style=3D"font-family: Verdana, Geneva, sans-serif;">2)&nbs= p;if that doesn't work then put into maintenance</span><span style=3D"font-= family: Verdana, Geneva, sans-serif;"> mode again and restart vdsmd an= d online the node again.</span></span></div> <div><span><br> </span></div> <div><span><span style=3D"font-family: Verdana, Geneva, sans-serif;">or doe= s this need to be directly </span><span style=3D"font-family: Verdana,= Geneva, sans-serif;">updated in the postgres DB for that node ? If so does= anyone know how to do that ? </span></span></div> <div><span><br> </span></div> <div><span style=3D"font-family: Verdana, Geneva, sans-serif;">Thanks,</spa= n></div> <div><span style=3D"font-family: Verdana, Geneva, sans-serif;">Joe.</span><= /div> <p></p> <p><br> </p> <div id=3D"Signature"> <div id=3D"divtagdefaultwrapper" dir=3D"ltr" style=3D"font-size: 12pt; colo= r: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-serif, EmojiF= ont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEm= oji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols, = EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoC= olorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSym= bols, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji",= NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", Em= ojiSymbols, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji&= quot;, NotoColorEmoji, "Segoe UI Symbol", "Android Emoji&quo= t;, EmojiSymbols;"> <div style=3D"font-family:Tahoma; font-size:13px"> <table class=3D"" cellspacing=3D"0" cellpadding=3D"0" width=3D"100%" style= =3D"font-family:Cantarell; letter-spacing:normal; orphans:auto; text-indent= :0px; text-transform:none; widows:auto; word-spacing:0px"> <tbody> <tr class=3D""> <td class=3D""> <div>-- <br> <span style=3D"font-size:12pt; color:#000000; font-style:Arial,sans-serif; = font-weight:bold">J. Kelly</span><br> <span style=3D"font-size:10pt; color:#000000; font-style:Arial,sans-serif">= Infrastructure Engineer</span><br> <span style=3D"font-size:12pt; color:#808080; font-style:Arial,sans-serif; = font-weight:bold">TradingScreen</span><br> <span style=3D"font-size:10pt; color:#808080; font-style:Arial,sans-serif">= <a href=3D"http://www.tradingscreen.com/" id=3D"LPNoLP">www.tradingscreen.c= om</a></span><br> </div> </td> </tr> </tbody> </table> <br> </div> </div> </div> </div> </body> </html> --_000_CY1PR16MB0393574D1CEE59FBF5F2696288BE0CY1PR16MB0393namp_--

1 0

user can see other user's vms
by Hari Gowtham 26 Jul '17

26 Jul '17

Hi, we have been trying to use ovirt to let the other devs in our team spawn vms and use it. we are nearly done with the setup. we have the hosted engine up, created gluster volumes and now we have setup the login to the portal too. While trying to spawn vms we noticed that, The admin can view, start or stop the vms on the machines which is fine. But we can see that the users can see each other user's vms too. This will make it possible for one user to start or stop other user's vm which we don't want to happen. we need to avoid this situation were one user has access to other user's vm. A particular user should be able to see the vms created by him alone So that he will have the ability to stop his own vms alone. What is the best way to create this setup? Is this the way it was designed to work or have i done something wrong here? Do let me know. -- Regards, Hari Gowtham.

3 3

iSCSI Multipath issues
by Vinícius Ferrão 25 Jul '17

25 Jul '17

--_000_FAC906FE18D64366A7C371126A43C191ifufrjbr_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCknigJltIGpvaW5pbmcgdGhlIGNyb3dkIHdpdGggaVNDU0kgTXVsdGlwYXRoIGlz c3VlcyBvbiBvVmlydCBoZXJlLiBJ4oCZbSB0cnlpbmcgdG8gZW5hYmxlIHRoZSBmZWF0dXJlIHdp dGhvdXQgc3VjY2VzcyB0b28uDQoNCkhlcmXigJlzIHdoYXQgSeKAmXZlIGRvbmUsIHN0ZXAtYnkt c3RlcC4NCg0KMS4gSW5zdGFsbGVkIG9WaXJ0IE5vZGUgNC4xLjMgd2l0aCB0aGUgZm9sbG93aW5n IG5ldHdvcmsgc2V0dGluZ3M6DQoNCmVubzEgYW5kIGVubzIgb24gYSA4MDIuM2FkIChMQUNQKSBC b25kLCBjcmVhdGluZyBhIGJvbmQwIGludGVyZmFjZS4NCmVubzMgd2l0aCA5MjE2IE1UVS4NCmVu bzQgd2l0aCA5MjE2IE1UVS4NCnZsYW4xMSBvbiBlbm8zIHdpdGggOTIxNiBNVFUgYW5kIGZpeGVk IElQIGFkZHJlc3Nlcy4NCnZsYW4xMiBvbiBlbm80IHdpdGggOTIxNiBNVFUgYW5kIGZpeGVkIElQ IGFkZHJlc3Nlcy4NCg0KZW5vMyBhbmQgZW5vNCBhcmUgbXkgaVNDU0kgTVBJTyBJbnRlcmZhY2Vz LCBjb21wbGV0ZWxseSBzZWdyZWdhdGVkLCBvbiBkaWZmZXJlbnQgc3dpdGNoZXMuDQoNCjIuIFN0 YXJ0ZWQgdGhlIGluc3RhbGxhdGlvbiBvZiBTZWxmLWhvc3RlZCBlbmdpbmUgYWZ0ZXIgdGhyZWUg aG91cnMgb2Ygd2FpdGluZywgYmVjYXVzZTogaHR0cHM6Ly9idWd6aWxsYS5yZWRoYXQuY29tL3No b3dfYnVnLmNnaT9pZD0xNDU0NTM2DQoNCjMuIFNlbGVjdGVkIGlTQ1NJIGFzIGRlZmF1bHQgaW50 ZXJmYWNlIGZvciBIb3N0ZWQgRW5naW5lLiBFdmVyeXRoaW5nIHdhcyBmaW5lLg0KDQo0LiBPbiB0 aGUgSG9zdGVkIEVuZ2luZSBJ4oCZdmUgZG9uZSB0aGUgZm9sbG93aW5nOg0KDQphLiBTeXN0ZW0g PiBEYXRhIENlbnRlcnMgPiBEZWZhdWx0ID4gTmV0d29ya3MNCi4gQ3JlYXRlZCBpU0NTSTEgd2l0 aCBWTEFOIDExIGFuZCBNVFUgOTIxNiwgcmVtb3ZlZCBWTSBOZXR3b3JrIG9wdGlvbi4NCi4gQ3Jl YXRlZCBpU0NTSTIgd2l0aCBWTEFOIDEyIGFuZCBNVFUgOTIxNiwgcmVtb3ZlZCBWTSBOZXR3b3Jr IG9wdGlvbi4NCg0KYi4gU3lzdGVtID4gRGF0YSBDZW50ZXJzID4gRGVmYXVsdCA+IENsdXN0ZXJz ID4gRGVmYXVsdCA+IEhvc3RzID4gb3ZpcnQzLmNjLmlmLnVmcmouYnI8aHR0cDovL292aXJ0My5j Yy5pZi51ZnJqLmJyPiAobXkgbWFjaGluZSkNCg0KU2VsZWN0ZWQgU2V0dXAgSG9zdCBOZXR3b3Jr cyBhbmQgbW92ZWQgaVNDU0kxIHRvIGVubzMgYW5kIGlTQ1NJMiB0byBlbm80LiBCb3RoIGljb25z IGdvbmUgZ3JlZW4sIGluZGljYXRpbmcgYW4g4oCcdXDigJ0gc3RhdGUuDQoNCmMuIFN5c3RlbSA+ IERhdGEgQ2VudGVycyA+IERlZmF1bHQgPiBDbHVzdGVycw0KDQpTZWxlY3RlZCBMb2dpY2FsIE5l dHdvcmtzIGFuZCB0aGVtIE1hbmFnZSBOZXR3b3JrLiBSZW1vdmVkIHRoZSBSZXF1aXJlZCBjaGVj a2JveCBmcm9tIGJvdGggaVNDU0kgY29ubmVjdGlvbnMuDQoNCmQuIFN5c3RlbSA+IERhdGEgQ2Vu dGVycyA+IERlZmF1bHQgPiBTdG9yYWdlDQoNCkFkZGVkIGFuIGlTQ1NJIFNoYXJlIHdpdGggdHdv IGluaXRpYXRvcnMuIEJvdGggc2hvd3MgdXAgY29ycmVjdGx5Lg0KDQplLiBTeXN0ZW0gPiBEYXRh IENlbnRlcnMNCg0KTm93IHRoZSBpU0NTSSBNdWx0aXBhdGggdGFiIGlzIHZpc2libGUuIFNlbGVj dGVkIGl0IGFuZCBhZGRlZCBhbiBpU0NTSSBCb25kOg0KLiBpU0NTSTEgYW5kIGlTQ1NJMiBzZWxl Y3RlZCBvbiBMb2dpY2FsIE5ldHdvcmtzLg0KLiBUd28gaXFu4oCZcyBzZWxlY3RlZCBvbiBTdG9y YWdlIFRhcmdldHMuDQoNCjUuIG9WaXJ0IGp1c3QgZ29lcyBkb3duLiBWRFNNIGdldHMgY3Jhenkg YW5kIGV2ZXJ5dGhpbmcg4oCcY3Jhc2hlc+KAnS4gaVNDU0kgaXMgc3RpbGwgYWxpdmUsIHNpbmNl IHdlIGNhbiBzdGlsbCB0YWxrIHdpdGggdGhlIFNlbGYgSG9zdGVkIEVuZ2luZSwgYnV0ICoqTk9U SElORyoqIHdvcmtzLiBJZiB0aGUgaVNDU0kgQm9uZCBpcyByZW1vdmVkIGV2ZXJ5dGhpbmcgcmVn ZW5lcmF0ZXMgdG8gYSB1c2FibGUgc3RhdGUuDQoNCknigJl2ZSBhZGRlZCB0aGUgZm9sbG93aW5n IGZpbGVzIG9uIG15IHB1YmxpYyBwYWdlIHRvIGhlbHAgb24gZGVidWdnaW5nOg0KL3Zhci9sb2cv dmRzbS92ZHNtLmxvZw0KL3Zhci9sb2cvc2FubG9jay5sb2cNCi92YXIvbG9nL3Zkc20vbW9tLmxv Zw0KL3Zhci9sb2cvbWVzc2FnZXMNCg0KVGhlcmUgYXJlIHNvbWUgcmFuZG9tIGltYWdlcyBvZiBt eSBjb25maWd1cmF0aW9uIHRvbzogaHR0cDovL3d3dy5pZi51ZnJqLmJyL35mZXJyYW8vb3ZpcnQv DQoNCldoYXQgc2hvdWxkIGJlIGRvbmUgbm93PyBJc3N1ZSBhIGJ1ZyBmaXggcmVxdWVzdD8NCg0K VGhhbmtzLA0KVi4NCg0KUFM6IE15IG1hY2hpbmUgaXMgcmVhY2hhYmxlIG92ZXIgdGhlIGludGVy bmV0LiBTbyBpZiBhbnlvbmUgd291bGQgbGlrZSB0byBjb25uZWN0IHRvIGl0LCBqdXN0IGxldCBt ZSBrbm93Lg0KDQoNCg== --_000_FAC906FE18D64366A7C371126A43C191ifufrjbr_ Content-Type: text/html; charset="utf-8" Content-ID: <AC8E9BA23F15D441A9985204E5D2DA9B(a)if.ufrj.br> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGVsbG8sDQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5J4oCZbSBqb2luaW5nIHRoZSBj cm93ZCB3aXRoIGlTQ1NJIE11bHRpcGF0aCBpc3N1ZXMgb24gb1ZpcnQgaGVyZS4gSeKAmW0gdHJ5 aW5nIHRvIGVuYWJsZSB0aGUgZmVhdHVyZSB3aXRob3V0IHN1Y2Nlc3MgdG9vLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SGVyZeKAmXMg d2hhdCBJ4oCZdmUgZG9uZSwgc3RlcC1ieS1zdGVwLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+MS4gSW5zdGFsbGVkIG9WaXJ0IE5vZGUg NC4xLjMgd2l0aCB0aGUgZm9sbG93aW5nIG5ldHdvcmsgc2V0dGluZ3M6PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0i QXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5lbm8xIGFuZCBl bm8yIG9uIGEgODAyLjNhZCAoTEFDUCkgQm9uZCwgY3JlYXRpbmcgYSBib25kMCBpbnRlcmZhY2Uu PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9 IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPmVubzMgd2l0aCA5MjE2IE1UVS48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6 cHJlIj48L3NwYW4+ZW5vNCB3aXRoIDkyMTYgTVRVLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3Bh biBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj52 bGFuMTEgb24gZW5vMyB3aXRoIDkyMTYgTVRVIGFuZCBmaXhlZCBJUCBhZGRyZXNzZXMuPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRl LXNwYWNlOnByZSI+PC9zcGFuPnZsYW4xMiBvbiBlbm80IHdpdGggOTIxNiBNVFUgYW5kIGZpeGVk IElQIGFkZHJlc3Nlcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRl LXNwYWNlOnByZSI+PC9zcGFuPmVubzMgYW5kIGVubzQgYXJlIG15IGlTQ1NJIE1QSU8gSW50ZXJm YWNlcywgY29tcGxldGVsbHkgc2VncmVnYXRlZCwgb24gZGlmZmVyZW50IHN3aXRjaGVzLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Mi4g U3RhcnRlZCB0aGUgaW5zdGFsbGF0aW9uIG9mIFNlbGYtaG9zdGVkIGVuZ2luZSBhZnRlciB0aHJl ZSBob3VycyBvZiB3YWl0aW5nLCBiZWNhdXNlOg0KPGEgaHJlZj0iaHR0cHM6Ly9idWd6aWxsYS5y ZWRoYXQuY29tL3Nob3dfYnVnLmNnaT9pZD0xNDU0NTM2IiBjbGFzcz0iIj5odHRwczovL2J1Z3pp bGxhLnJlZGhhdC5jb20vc2hvd19idWcuY2dpP2lkPTE0NTQ1MzY8L2E+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4zLiBTZWxlY3RlZCBp U0NTSSBhcyBkZWZhdWx0IGludGVyZmFjZSBmb3IgSG9zdGVkIEVuZ2luZS4gRXZlcnl0aGluZyB3 YXMgZmluZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjQuIE9uIHRoZSBIb3N0ZWQgRW5naW5lIEnigJl2ZSBkb25lIHRoZSBmb2xsb3dp bmc6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUi Pjwvc3Bhbj5hLiZuYnNwO1N5c3RlbSAmZ3Q7IERhdGEgQ2VudGVycyAmZ3Q7IERlZmF1bHQgJmd0 OyBOZXR3b3JrczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNw YW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3Nw YW4+LiBDcmVhdGVkIGlTQ1NJMSB3aXRoIFZMQU4gMTEgYW5kIE1UVSA5MjE2LCByZW1vdmVkIFZN IE5ldHdvcmsgb3B0aW9uLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUt dGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj4uIENyZWF0ZWQgaVNDU0ky IHdpdGggVkxBTiAxMiBhbmQgTVRVIDkyMTYsIHJlbW92ZWQgVk0gTmV0d29yayBvcHRpb24uPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bh bj5iLiZuYnNwO1N5c3RlbSAmZ3Q7IERhdGEgQ2VudGVycyAmZ3Q7IERlZmF1bHQgJmd0OyBDbHVz dGVycyAmZ3Q7IERlZmF1bHQgJmd0OyBIb3N0cyAmZ3Q7DQo8YSBocmVmPSJodHRwOi8vb3ZpcnQz LmNjLmlmLnVmcmouYnIiIGNsYXNzPSIiPm92aXJ0My5jYy5pZi51ZnJqLmJyPC9hPiZuYnNwOyht eSBtYWNoaW5lKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3Bh Y2U6cHJlIj48L3NwYW4+U2VsZWN0ZWQgU2V0dXAgSG9zdCBOZXR3b3JrcyBhbmQgbW92ZWQgaVND U0kxIHRvIGVubzMgYW5kIGlTQ1NJMiB0byBlbm80LiBCb3RoIGljb25zIGdvbmUgZ3JlZW4sIGlu ZGljYXRpbmcgYW4g4oCcdXDigJ0gc3RhdGUuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4i IHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5jLiZuYnNwO1N5c3RlbSAmZ3Q7IERhdGEg Q2VudGVycyAmZ3Q7IERlZmF1bHQgJmd0OyBDbHVzdGVyczwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRh Yi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+U2VsZWN0ZWQgTG9naWNhbCBO ZXR3b3JrcyBhbmQgdGhlbSBNYW5hZ2UgTmV0d29yay4gUmVtb3ZlZCB0aGUgUmVxdWlyZWQgY2hl Y2tib3ggZnJvbSBib3RoIGlTQ1NJIGNvbm5lY3Rpb25zLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRh Yi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+ZC4gU3lzdGVtICZndDsgRGF0 YSBDZW50ZXJzICZndDsgRGVmYXVsdCAmZ3Q7IFN0b3JhZ2U8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10 YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPkFkZGVkIGFuIGlTQ1NJIFNo YXJlIHdpdGggdHdvIGluaXRpYXRvcnMuIEJvdGggc2hvd3MgdXAgY29ycmVjdGx5LjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4g Y2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+ZS4g U3lzdGVtICZndDsgRGF0YSBDZW50ZXJzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0 eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5Ob3cgdGhlIGlTQ1NJIE11bHRpcGF0aCB0YWIg aXMgdmlzaWJsZS4gU2VsZWN0ZWQgaXQgYW5kIGFkZGVkIGFuIGlTQ1NJIEJvbmQ6PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNw YWNlOnByZSI+PC9zcGFuPi4gaVNDU0kxIGFuZCBpU0NTSTIgc2VsZWN0ZWQgb24gTG9naWNhbCBO ZXR3b3Jrcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFu IiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+LiBUd28gaXFu4oCZcyBzZWxlY3RlZCBv biBTdG9yYWdlIFRhcmdldHMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj41LiBvVmlydCBqdXN0IGdvZXMgZG93bi4gVkRTTSBnZXRzIGNy YXp5IGFuZCBldmVyeXRoaW5nIOKAnGNyYXNoZXPigJ0uIGlTQ1NJIGlzIHN0aWxsIGFsaXZlLCBz aW5jZSB3ZSBjYW4gc3RpbGwgdGFsayB3aXRoIHRoZSBTZWxmIEhvc3RlZCBFbmdpbmUsIGJ1dCAq Kk5PVEhJTkcqKiB3b3Jrcy4gSWYgdGhlIGlTQ1NJIEJvbmQgaXMgcmVtb3ZlZCBldmVyeXRoaW5n IHJlZ2VuZXJhdGVzIHRvIGEgdXNhYmxlIHN0YXRlLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SeKAmXZlIGFkZGVkIHRoZSBmb2xsb3dp bmcgZmlsZXMgb24gbXkgcHVibGljIHBhZ2UgdG8gaGVscCBvbiBkZWJ1Z2dpbmc6PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPi92YXIvbG9nL3Zkc20vdmRzbS5sb2c8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ L3Zhci9sb2cvc2FubG9jay5sb2c8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+L3Zhci9sb2cvdmRzbS9t b20ubG9nPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi92YXIvbG9nL21lc3NhZ2VzPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGVyZSBhcmUg c29tZSByYW5kb20gaW1hZ2VzIG9mIG15IGNvbmZpZ3VyYXRpb24gdG9vOiZuYnNwOzxhIGhyZWY9 Imh0dHA6Ly93d3cuaWYudWZyai5ici9+ZmVycmFvL292aXJ0LyIgY2xhc3M9IiI+aHR0cDovL3d3 dy5pZi51ZnJqLmJyL35mZXJyYW8vb3ZpcnQvPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2hhdCBzaG91bGQgYmUgZG9uZSBub3c/ IElzc3VlIGEgYnVnIGZpeCByZXF1ZXN0PzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmtzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5W LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+UFM6IE15IG1hY2hpbmUgaXMgcmVhY2hhYmxlIG92ZXIgdGhlIGludGVybmV0LiBTbyBpZiBh bnlvbmUgd291bGQgbGlrZSB0byBjb25uZWN0IHRvIGl0LCBqdXN0IGxldCBtZSBrbm93LjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10YWIt c3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwv c3Bhbj48L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_FAC906FE18D64366A7C371126A43C191ifufrjbr_--

4 8