November 2015 - Users - oVirt List Archives

MAC spoofing for specific VMs
by Christopher Young 13 Mar '16

13 Mar '16

I'm working on some load-balancing solutions and they appear to require MAC spoofing. I did some searching and reading and as I understand it, you can disable the MAC spoofing protection through a few methods. I was wondering about the best manner to enable this for the VMs that require it and not across the board (if that is even possible). I'd like to just allow my load-balancer VMs to do what they need to, but keep the others untouched as a security mechanism. If anyone has any advice on the best method to handle this scenario, I would greatly appreciate it. It seems that this might turn into some type of feature request, though I'm not sure if this is something that has to be done at the Linux bridge level, the port level, or the VM level. Any explanations into that would also help in my education. Thanks, Chris

3 5

Highly Available in 3.6 and USB support
by jaumotte, styve 21 Feb '16

21 Feb '16

--_000_AM3PR02MB29653FCC03F78819A980A6A86070AM3PR02MB296eurprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everybody, After testing some features on 3.5, we are planning to finaly go to 3.6. So= me problems still exist. A major problem still remain on the < Highly Available > option on vm wich = doesn't work. I had a cluster with 4 engines and a simple vm. When I start = a poweroff from the node where this vm is living, the node is shutting down= but my vm doesn't restart on another node of the cluster. The power managm= ent of all the node are correctly configure. The HA feature of then hosted-= engine is working well (except it is very long). Another problem consist of passing usb host device to the virtual machine. = We've got some specials usb keys for activating old application and we need= to attach this key to vm. At first, I try with standard usb mass storage k= ey to test this approach. I can't start virtual machine when I add usb devi= ce, I always have the message < The host ... did not satisfy internal filte= r HostDevice because it does not support host device passthrough >. Have an= y idea where I can find an HowTo to help me ? Tanks for your help, SJ --_000_AM3PR02MB29653FCC03F78819A980A6A86070AM3PR02MB296eurprd_ 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"FR" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial",sans-serif;color:black">Hi everybody,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial",sans-serif;color:black"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial",sans-serif;color:black">After testing some features on 3.5, we ar= e planning to finaly go to 3.6. Some problems still exist. <o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial",sans-serif;color:black"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial",sans-serif;color:black">A major problem still remain on the &laqu= o; Highly Available » option on vm wich doesn’t work.= I had a cluster with 4 engines and a simple vm. When I start a poweroff fr= om the node where this vm is living, the node is shutting down but my vm does= n’t restart on another node of the cluster. The power managment of al= l the node are correctly configure. The HA feature of then hosted-engine is= working well (except it is very long).<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial",sans-serif;color:black"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial",sans-serif;color:black">Another problem consist of passing usb ho= st device to the virtual machine. We’ve got some specials usb keys fo= r activating old application and we need to attach this key to vm. At first, I try with standard usb mass storage key to test this= approach. I can’t start virtual machine when I add usb device, I alw= ays have the message « The host … did not satisfy internal= filter HostDevice because it does not support host device passthrough ». Have any idea where I can find an HowTo to help = me ?<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial",sans-serif;color:black"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial",sans-serif;color:black">Tanks for your help,<o:p></o:p></span></p= > <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial",sans-serif;color:black"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial",sans-serif;color:black">SJ<o:p></o:p></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:10.0pt;font-family:"Ar= ial",sans-serif;color:black"><o:p> </o:p></span></p> </div> </body> </html> --_000_AM3PR02MB29653FCC03F78819A980A6A86070AM3PR02MB296eurprd_--

4 7

How to add faster NIC to oVirt cluser / host?
by Christophe TREFOIS 10 Jan '16

10 Jan '16

Dear all, I have currently a data center with two clusters and each cluster had 1 host. On one of the hosts, I now enabled 10 GbE NIC called p4p1. Currently everything is going over a 1 GbE NIC called em1 (ovirtmgmt). My question now is, how I could add my 10 GbE NIC to the setup for instance to use for transferring data during transmissions to export domain or to simply replace the 1 GbE? I prefer little downtime (eg only temp network loss), but a full downtime (shutting down) could be acceptable. Thank you for any pointers or starting points you could provide, Kind regards, — Christophe

3 8

python floppy in RunOnce mode
by Giulio Casella 07 Jan '16

07 Jan '16

Hi, I'm trying to boot a vm with non persistent floppy using python ovirt sdk (the "RunOnce" way in administrator portal), but guest OS can't see floppy drive. The ultimate goal is to deploy floppy with sysprep unattend.xml file for windows 7 pools of vm. Here is a snippet of code I use: ------------------------------------------------- myvm = api.vms.get(name="vmname") content="This is file content!" f=params.File(name="foobar.txt",content=content) fs=params.Files() fs.add_file(f) payload=params.Payload() payload.set_type("floppy") payload.set_files(fs) payloads=params.Payloads() payloads.add_payload(payload) thevm=params.VM() thevm.set_payloads(payloads) action=params.Action(vm=thevm) myvm.start(action=action) xml = ParseHelper.toXml(action) print xml ------------------------------------------------- As you can see, for debugging purpose, I print my xml action, and I get: ------------------------------------------------- <action> <vm> <payloads> <payload type="floppy"> <files> <file> <name>foobar.txt</name> <content>This is file content</content> </file> </files> </payload> </payloads> </vm> </action> ------------------------------------------------- in the admin portal I can see my vm in "RunOnce" state, but no floppy is present... In fact in the vm process command line (ps -ef | grep qemu-kvm | grep vmname) I can't see -drive option referring to floppy (I only see 2 "-drive" options, referring to vm system disk and to a correctly mounted cdrom ISO) What I'm doing wrong? (The engine is RHEV-M version 3.4.1-0.31.el6ev) Thanks in advance, Giulio

3 11

Delete disk references without deleting the disk
by Johan Kooijman 06 Jan '16

06 Jan '16

Hi all, I have about 100 old VM's in my cluster. They're powered down, ready for deletion. What I want to do is delete the VM's including disks without actually deleting the disk images from the storage array itself. Is that possible? At the end I want to be able to delete the storage domain (which then should not hold any data, as far as ovirt is concerned). Reason for this: it's a ZFS pool with dedup enabled, deleting the images one by one will kill the array with 100% iowa for some time. -- Met vriendelijke groeten / With kind regards, Johan Kooijman

4 9

HA cluster
by Budur Nagaraju 04 Jan '16

04 Jan '16

HI Getting below error while configuring Hosted engine, root@he ~]# hosted-engine --deploy [ INFO ] Stage: Initializing [ INFO ] Generating a temporary VNC password. [ INFO ] Stage: Environment setup Continuing will configure this host for serving as hypervisor and create a VM where you have to install oVirt Engine afterwards. Are you sure you want to continue? (Yes, No)[Yes]: yes Configuration files: [] Log file: /var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20151126102302-bkozgk.log Version: otopi-1.3.2 (otopi-1.3.2-1.el6) It has been detected that this program is executed through an SSH connection without using screen. Continuing with the installation may lead to broken installation if the network connection fails. It is highly recommended to abort the installation and run it inside a screen session using command "screen". Do you want to continue anyway? (Yes, No)[No]: yes [WARNING] Cannot detect if hardware supports virtualization [ INFO ] Bridge ovirtmgmt already created [ INFO ] Stage: Environment packages setup [ INFO ] Stage: Programs detection [ INFO ] Stage: Environment setup *[ ERROR ] The following VMs has been found: 2b8d6d91-d838-44f6-ae3b-c92cda014280[ ERROR ] Failed to execute stage 'Environment setup': Cannot setup Hosted Engine with other VMs running* [ INFO ] Stage: Clean up [ INFO ] Generating answer file '/var/lib/ovirt-hosted-engine-setup/answers/answers-20151126102310.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [root@he ~]#

5 23

Upgrade path from Fedora 20 oVirt 3.5 to Fedora 22 oVirt 3.6
by David Marzal Canovas 04 Jan '16

04 Jan '16

--=_35f37747b7409088194fea6f348517b4 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi would like to be sure of the correct upgrate path to take. Should I first upgrade Fedora 20 -> Fedora 21 -> Fedora 22 and then upgrade oVirt from 3.5 to 3.6? Or would be better to upgrade in the Fedora 20: oVirt 3.5 -> oVirt 3.6 and then make the OS upgrades FD20->FD21->FD22 In the release notes http://www.ovirt.org/OVirt_3.6_Release_Notes#Install_.2F_Upgrade_from_previ… [1] don't says anything about the upgrade path of the OS, but searching I'm aware that oVirt 3.5 is only compatible with FD20 not with 21, or 22 oVirt 3.6 is only compatible with FD20 not with 21 or 20 Thanks in advance -- David Marzal Cánovas Servicio de Mecanización e Informática Asamblea Regional de Murcia Paseo Alfonso XIII, nº53 30203 - Cartagena Tlfno: 968326800 Links: ------ [1] http://www.ovirt.org/OVirt_3.6_Release_Notes#Install_.2F_Upgrade_from_previ… --=_35f37747b7409088194fea6f348517b4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset= =3DUTF-8" /></head><body style=3D'font-size: 10pt'> <p>Hi would like to be sure of the correct upgrate path to take.</p> <p>Should I first upgrade Fedora 20 -> Fedora 21 -> Fedora 22</p> <p>and then upgrade oVirt from 3.5 to 3.6?</p> <p>Or would be better to upgrade in the Fedora 20: oVirt 3.5 -> oVirt 3= =2E6</p> <p>and then make the OS upgrades FD20->FD21->FD22</p> <p>In the release notes <a href=3D"http://www.ovirt.org/OVirt_3.6_Release_N= otes#Install_.2F_Upgrade_from_previous_versions">http://www.ovirt.org/OVirt= _3.6_Release_Notes#Install_.2F_Upgrade_from_previous_versions</a></p> <p>don't says anything about the upgrade path of the OS, but searching I'm = aware that</p> <p>oVirt 3.5 is only compatible with FD20 not with 21, or 22</p> <p>oVirt 3.6 is only compatible with FD20 not with 21 or 20</p> <p>Thanks in advance</p> <div>-- <br /> <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> <tbody> <tr> <td><img src=3D"http://www.asambleamurcia.es/templates/sumandoesfuerzos/ima= ges/ARM.png" alt=3D"" width=3D"130" height=3D"79" /></td> <td>David Marzal Cánovas <br />Servicio de Mecanización = e Informática<br />Asamblea Regional de Murcia<br />Paseo Alfonso XI= II, nº53<br />30203 - Cartagena<br />Tlfno: 968326800</td> </tr> </tbody> </table> </div> </body></html> --=_35f37747b7409088194fea6f348517b4--

5 5

Problem with hosted engine setup - vsdmd does not start
by Willard Dennis 19 Dec '15

19 Dec '15

--Apple-Mail=_6ED95494-A5E5-4D6F-BDAF-D1727917E172 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi all, Tried to run the hosted engine setup, got: [ ERROR ] Failed to execute stage 'Environment setup': [Errno 111] = Connection refused ( full run output here: = https://gist.githubusercontent.com/wdennis/4390042447354b2cb1c4/raw/c0f912= 7c676759b19b1d32a212c8c3694fac580e/hosted-engine-setup-output.txt = <https://gist.githubusercontent.com/wdennis/4390042447354b2cb1c4/raw/c0f91= 27c676759b19b1d32a212c8c3694fac580e/hosted-engine-setup-output.txt> ) Looked at the setup log file referenced in the output, saw this = traceback in it that also referenced the Error 111: = https://gist.githubusercontent.com/wdennis/4390042447354b2cb1c4/raw/c0f912= 7c676759b19b1d32a212c8c3694fac580e/configurevm-py_error.txt = <https://gist.githubusercontent.com/wdennis/4390042447354b2cb1c4/raw/c0f91= 27c676759b19b1d32a212c8c3694fac580e/configurevm-py_error.txt> I diagnosed it (Google ftw) and saw that it was likely a vdsmd problem; = sure enough, when I did a 'systemctl status vdsmd=E2=80=99 I saw that it = was in error state - Process: 28163 ExecStart=3D/usr/share/vdsm/daemonAdapter -0 /dev/null -1 = /dev/null -2 /dev/null /usr/share/vdsm/vdsm (code=3Dexited, = status=3D1/FAILURE) ( full status output here: = https://gist.githubusercontent.com/wdennis/4390042447354b2cb1c4/raw/c0f912= 7c676759b19b1d32a212c8c3694fac580e/systemctl_status_vdsmd.txt = <https://gist.githubusercontent.com/wdennis/4390042447354b2cb1c4/raw/c0f91= 27c676759b19b1d32a212c8c3694fac580e/systemctl_status_vdsmd.txt> ) Does anyone know how I can troubleshoot and fix the VDSM daemon start = process? Thanks, Will --Apple-Mail=_6ED95494-A5E5-4D6F-BDAF-D1727917E172 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D"">Hi all,<div class=3D""><br class=3D""></div><div = class=3D"">Tried to run the hosted engine setup, got:<div class=3D"">[ = ERROR ] Failed to execute stage 'Environment setup': [Errno 111] = Connection refused</div><div class=3D""><br class=3D""></div><div = class=3D"">( full run output here: <a = href=3D"https://gist.githubusercontent.com/wdennis/4390042447354b2cb1c4/ra= w/c0f9127c676759b19b1d32a212c8c3694fac580e/hosted-engine-setup-output.txt"= = class=3D"">https://gist.githubusercontent.com/wdennis/4390042447354b2cb1c4= /raw/c0f9127c676759b19b1d32a212c8c3694fac580e/hosted-engine-setup-output.t= xt</a> )</div><div class=3D""><br class=3D""></div><div = class=3D"">Looked at the setup log file referenced in the output, saw = this traceback in it that also referenced the Error 111:</div><div = class=3D""><a = href=3D"https://gist.githubusercontent.com/wdennis/4390042447354b2cb1c4/ra= w/c0f9127c676759b19b1d32a212c8c3694fac580e/configurevm-py_error.txt" = class=3D"">https://gist.githubusercontent.com/wdennis/4390042447354b2cb1c4= /raw/c0f9127c676759b19b1d32a212c8c3694fac580e/configurevm-py_error.txt</a>= </div><div class=3D""><br class=3D""></div><div class=3D"">I diagnosed = it (Google ftw) and saw that it was likely a vdsmd problem; sure enough, = when I did a 'systemctl status vdsmd=E2=80=99 I saw that it was in error = state -</div><div class=3D"">Process: 28163 = ExecStart=3D/usr/share/vdsm/daemonAdapter -0 /dev/null -1 /dev/null -2 = /dev/null /usr/share/vdsm/vdsm (code=3Dexited, = status=3D1/FAILURE)</div><div class=3D""><br class=3D""></div><div = class=3D"">( full status output here: <a = href=3D"https://gist.githubusercontent.com/wdennis/4390042447354b2cb1c4/ra= w/c0f9127c676759b19b1d32a212c8c3694fac580e/systemctl_status_vdsmd.txt" = class=3D"">https://gist.githubusercontent.com/wdennis/4390042447354b2cb1c4= /raw/c0f9127c676759b19b1d32a212c8c3694fac580e/systemctl_status_vdsmd.txt</= a> )</div><div class=3D""><br class=3D""></div><div class=3D"">Does = anyone know how I can troubleshoot and fix the VDSM daemon start = process?</div><div class=3D""><br class=3D""></div><div = class=3D"">Thanks,</div><div class=3D"">Will</div><div class=3D""><br = class=3D""></div></div></body></html>= --Apple-Mail=_6ED95494-A5E5-4D6F-BDAF-D1727917E172--

7 30

Re: [ovirt-users] Error during hosted-engine-setup for 3.5.1 on F20 (Cannot add the host to cluster ... SSH has failed)
by Bob Doolittle 18 Dec '15

18 Dec '15

On 03/09/2015 07:12 AM, Simone Tiraboschi wrote: > > ----- Original Message ----- >> From: "Bob Doolittle" <bob(a)doolittle.us.com> >> To: "Simone Tiraboschi" <stirabos(a)redhat.com> >> Sent: Monday, March 9, 2015 12:02:49 PM >> Subject: Re: [ovirt-users] Error during hosted-engine-setup for 3.5.1 on F20 (Cannot add the host to cluster ... SSH >> has failed) >> >> On Mar 9, 2015 5:23 AM, "Simone Tiraboschi" <stirabos(a)redhat.com> wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Bob Doolittle" <bob(a)doolittle.us.com> >>>> To: "users-ovirt" <users(a)ovirt.org> >>>> Sent: Friday, March 6, 2015 9:21:20 PM >>>> Subject: [ovirt-users] Error during hosted-engine-setup for 3.5.1 on >> F20 (Cannot add the host to cluster ... SSH has >>>> failed) >>>> >>>> Hi, >>>> >>>> I'm following the instructions here: >> http://www.ovirt.org/Hosted_Engine_Howto >>>> My self-hosted install failed near the end: >>>> >>>> To continue make a selection from the options below: >>>> (1) Continue setup - engine installation is complete >>>> (2) Power off and restart the VM >>>> (3) Abort setup >>>> (4) Destroy VM and abort setup >>>> >>>> (1, 2, 3, 4)[1]: 1 >>>> [ INFO ] Engine replied: DB Up!Welcome to Health Status! >>>> Enter the name of the cluster to which you want to add the >> host >>>> (Default) [Default]: >>>> [ ERROR ] Cannot automatically add the host to cluster Default: Cannot >> add >>>> Host. Connecting to host via SSH has failed, verify that the host is >>>> reachable (IP address, routable address etc.) You may refer to the >>>> engine.log file for further details. >>>> [ ERROR ] Failed to execute stage 'Closing up': Cannot add the host to >>>> cluster Default >>>> [ INFO ] Stage: Clean up >>>> [ INFO ] Generating answer file >>>> '/var/lib/ovirt-hosted-engine-setup/answers/answers-20150306135624.conf' >>>> [ INFO ] Stage: Pre-termination >>>> [ INFO ] Stage: Termination >>>> >>>> I can ssh into the engine VM both locally and remotely. There is no >>>> /root/.ssh directory, however. Did I need to set that up somehow? >>> It's the engine that needs to open an SSH connection to the host calling >> it by its hostname. >>> So please be sure that you can SSH to the host from the engine using its >> hostname and not its IP address. >> >> I'm assuming this should be a password-less login (key-based >> authentication?). > Yes, it is. > >> As what user? > root OK, I see a couple of problems. First off, I didn't have my deploying-host hostname in the hosts map for my engine. After adding it to /etc/hosts (both hostname and FQDN), when I try to ssh from root@engine to root@host it is prompting me for a password. On my engine, ~root/.ssh does not contain any keys. On my host, ~root/.ssh has authorized_keys, and in it there is a key with the comment "ovirt-engine". It's possible that I inadvertently removed ~root/.ssh on engine while I was preparing the engine (I started to set up my own no-password logins and then thought better and cleaned up, not realizing that some prior setup affecting that directory had occurred). That would explain the second issue. How/when does the key for root@engine get populated to the host's ~root/.ssh/authenticated_keys during setup? -Bob > >> -Bob >> >>> Till hosted-engine hosts were simply identified by their IP address but >> than we had some bug report on side effects of that. >>> So now we generate and sign certs using host hostnames and so the engine >> should be able to correctly resolve them. >>>> When I log into the Administration portal, the engine VM does not appear >>>> under the Virtual machine view (it's empty). >>> It's cause the setup didn't complete. >>> >>>> I've attached what I think are the relevant logs. >>>> >>>> Also, when my host reboots, the ovirt-ha-broker and ovirt-ha-agent >> services >>>> do not come up automatically. I have to use systemctl to start them >>>> manually. >>> It's cause the setup didn't complete. >>> >>>> This is a fresh Fedora 20 machine installing a fresh copy of Ovirt >> 3.5.1. >>>> What's the cleanest approach to restore/complete sanity of my setup >> please? >>> First step is to clarify what went wrong in order to avoid it in the >> future. >>> Than, if you want a really sanity environment for production use I'd >> suggest to redeploy. >>> So >>> hosted-engine --vm-poweroff >>> empty the storage domain share and deploy again >>> >>>> Thanks, >>>> Bob >>>> >>>> >>>> I've linked 3 files to this email: >>>> server.log (12.4 MB) Dropbox https://db.tt/g5p09AaD >>>> vdsm.log (3.2 MB) Dropbox https://db.tt/P4572SUm >>>> ovirt-hosted-engine-setup-20150306123622-tad1fy.log (413 KB) Dropbox >>>> https://db.tt/XAM9ffhi >>>> Mozilla Thunderbird makes it easy to share large files over email. >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/users >>>>

4 17

Re: [ovirt-users] Hosted engine notifications don't work after upgrading ovirt from 3.5 to 3.6
by Stefano Danzi 16 Dec '15

16 Dec '15

This is a multi-part message in MIME format. --------------020306050904050501090802 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit > the content is: > > [email] > smtp-server=localhost > smtp-port=25 > destination-emails=root@localhost > source-email=root@localhost > > [notify] > state_transition=maintenance|start|stop|migrate|up|down > and is the default. My conf was lost during upgrade. If I restart ovirt-ha-broker the broker.conf is replaced with the default If I don't restart ovirt-ha-broker, the broker.conf is silently replaced after a while. Looking here http://lists.ovirt.org/pipermail/engine-commits/2015-June/022940.html I understand that broker.conf is stored in another place and overwrite at runtime. > > Il 05/11/2015 18.44, Simone Tiraboschi ha scritto: >> Can you please paste here the content of >> /var/lib/ovirt-hosted-engine-ha/broker.conf ? >> eventually make it anonymous if you prefer >> >> >> >> On Thu, Nov 5, 2015 at 6:42 PM, Stefano Danzi <s.danzi(a)hawai.it >> <mailto:s.danzi@hawai.it>> wrote: >> >> After upgrading from 3.5 to 3.6 Hosted engine notifications stop >> to work. >> I think that broker.conf was lost during upgrade. >> >> I found this: https://bugzilla.redhat.com/show_bug.cgi?id=1260757 >> But I don't undertand how to change the configuration now. >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> >> http://lists.ovirt.org/mailman/listinfo/users >> >> > --------------020306050904050501090802 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <br> <br> <div class="moz-cite-prefix"><br> </div> <blockquote cite="mid:563B97C7.8050600@hawai.it" type="cite"> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> the content is:<br> <br> [email]<br> smtp-server=localhost<br> smtp-port=25<br> destination-emails=root@localhost<br> source-email=root@localhost<br> <br> [notify]<br> state_transition=maintenance|start|stop|migrate|up|down<br> <br> </blockquote> and is the default. My conf was lost during upgrade.<br> If I restart ovirt-ha-broker the broker.conf is replaced with the default<br> <br> If I don't restart ovirt-ha-broker, the broker.conf is silently replaced after a while.<br> <br> Looking here <a class="moz-txt-link-freetext" href="http://lists.ovirt.org/pipermail/engine-commits/2015-June/022940.html">http://lists.ovirt.org/pipermail/engine-commits/2015-June/022940.html</a><br> I understand that broker.conf is stored in another place and overwrite at runtime.<br> <br> <blockquote cite="mid:563B97C7.8050600@hawai.it" type="cite"> <br> <div class="moz-cite-prefix">Il 05/11/2015 18.44, Simone Tiraboschi ha scritto:<br> </div> <blockquote cite="mid:CAN8-ONpSxYVP050rp0ZGOxTmqKPDUUZy+8+2wf3Y8XSXgSTZMA@mail.gmail.com" type="cite"> <div dir="ltr">Can you please paste here the content of /var/lib/ovirt-hosted-engine-ha/broker.conf ? <div>eventually make it anonymous if you prefer<br> <div><br> </div> <div><br> </div> </div> </div> <div class="gmail_extra"><br> <div class="gmail_quote">On Thu, Nov 5, 2015 at 6:42 PM, Stefano Danzi <span dir="ltr"><<a moz-do-not-send="true" href="mailto:s.danzi@hawai.it" target="_blank">s.danzi(a)hawai.it</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">After upgrading from 3.5 to 3.6 Hosted engine notifications stop to work.<br> I think that broker.conf was lost during upgrade.<br> <br> I found this: <a moz-do-not-send="true" href="https://bugzilla.redhat.com/show_bug.cgi?id=1260757" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1260757</a><br> But I don't undertand how to change the configuration now.<br> _______________________________________________<br> Users mailing list<br> <a moz-do-not-send="true" href="mailto:Users@ovirt.org" target="_blank">Users(a)ovirt.org</a><br> <a moz-do-not-send="true" href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a><br> </blockquote> </div> <br> </div> </blockquote> <br> </blockquote> <br> <pre class="moz-signature" cols="72"> </pre> </body> </html> --------------020306050904050501090802--

4 11

no guest info shown and timezone warning
by Paul Groeneweg | Pazion 14 Dec '15

14 Dec '15

We have upgraded to oVirt 3.6, all went without any trouble and integration with satellite looks very nice! I also see a guest info tab, but this holds no info ( timezone unknown ) and the virtual machines give a timezone mismatch warning. I do have the ovirt-guest-agent installed and running. See screenshot for details: http://screencast.com/t/fJ9dnE9u Kind Regards, Paul Groeneweg -- Met vriendelijke groeten, Paul Groeneweg Pazion Webdevelopment - Hosting - Apps T +31 26 3020038 M +31 614 277 577 E paul(a)pazion.nl ***disclaimer*** "This e-mail and any attachments thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by persons other than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation."

6 8

Strange permissions on Hosted Engine HA Agent log files
by Giuseppe Ragusa 10 Dec '15

10 Dec '15

Hi all, I'm installing oVirt (3.6) in self-hosted mode, hyperconverged with GlusterFS (3.7.6). I'm using the oVirt snapshot generated the night between the 18th and 19th of November, 2015. The (single, at the moment) host and the Engine are both CentOS 7.1 fully up-to-date. After ovirt-hosted-engine-setup successful completion, I found the following (about 3 days after setup completed) "anomalies": 666 1 vdsm kvm - /var/log/ovirt-hosted-engine-ha/agent.log 666 1 vdsm kvm - /var/log/ovirt-hosted-engine-ha/agent.log.2015-11-23 666 1 vdsm kvm - /var/log/ovirt-hosted-engine-ha/broker.log 666 1 vdsm kvm - /var/log/ovirt-hosted-engine-ha/broker.log.2015-11-23 The listing above comes from a custom security checking script that gives: "octal permissions" "number of links" "owner" "group" - "absolute pathname" Is the ominous "666" mark actually intended/necessary? ;-) Do I need to open a bugzilla notification for this? Many thanks in advance for your attention. Regards, Giuseppe

3 2

Importing a Windows Guest in oVirt
by David Lo Bascio 10 Dec '15

10 Dec '15

This is a multi-part message in MIME format. --------------090807030805030403030506 Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi everyone, I migrated several Linux guest this way: /virt-v2v -ic qemu+ssh://root@<host>/system -o rhev -os <host>:<path> --network <network> <guest>/ Now, I have some Windows guest running on KVM managed by libvirt and I would like to import them in oVirt through virt-v2v in a similar way. Can you help me? Thanks a lot! David --------------090807030805030403030506 Content-Type: text/html; charset=iso-8859-15 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=iso-8859-15"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi everyone,<br> <br> I migrated several Linux guest this way:<br> <i>virt-v2v -ic qemu+ssh://root@<host>/system -o rhev -os <host>:<path> --network <network> <guest></i><br> <br> Now, I have some Windows guest running on KVM managed by libvirt and I would like to import them in oVirt through virt-v2v in a similar way. <br> Can you help me?<br> <br> Thanks a lot!<br> David<br> <br> <br> <br> </body> </html> --------------090807030805030403030506--

3 2

Multiple export domains limit?
by Nicolas Ecarnot 08 Dec '15

08 Dec '15

Hello, How comes there is a limitation (of one) in the number of simultaneously mounted export domains? Thank you. -- Nicolas ECARNOT

4 4

Unknown libvirterror - where to start?
by Christophe TREFOIS 06 Dec '15

06 Dec '15

--_000_ABC69195C9484895AAFF1900F54BBE43unilu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgY2hlY2tlZCB0aGUgbG9ncyBvbiBteSBoeXBlcnZpc29yIHRoYXQgY29udGFpbnMg YWxzbyB0aGUgb3ZlcnQtZW5naW5lIChzZWxmLWhvc3RlZCkgYW5kIEkgc2VlIHN0cmFuZ2UgdW5r bm93biBsaWJ2aXJ0ZXJyb3JzIHRoYXQgY29tZSBwZXJpb2RpY2FsbHkgaW4gdGhlIHZkc20ubG9n IGZpbGUuIFRoZSBzdG9yYWdlIGlzIGdsdXN0ZXJGUyBydW5uaW5nIG9uIHRoZSBoeXBlcnZpc29y IGFzIHdlbGwsIG9uZSBORlMgZXhwb3J0IGRvbWFpbiBhbmQgYW4gSVNPIGRvbWFpbi4gQSBORlMg ZG9tYWluIGZyb20gYW5vdGhlciBwbGFjZSBpcyBpbiBtYWludGVuYW5jZSBtb2RlLg0KDQpJIGFt IHJ1bm5pbmcgb1ZpcnQgMy41LjMuDQoNClRoYW5rIHlvdSBmb3IgYW55IHBvaW50ZXJzIGFzIHRv IHdoZXJlIHRvIHN0YXJ0IGZpeGluZyB0aGlzIGlzc3VlLg0KDQrigJQgbG9nIGV4Y2VycHQgLS0N Cg0KVGhyZWFkLTE5NDc2NDE6OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjMxLDM5ODo6c3RvbXBS ZWFjdG9yOjoxNjM6OnlhanNvbnJwYy5TdG9tcFNlcnZlcjo6KHNlbmQpIFNlbmRpbmcgcmVzcG9u c2UNClRocmVhZC04MTA4OjpERUJVRzo6MjAxNS0xMS0wMyAwODo0NzozMSw0MTA6OmxpYnZpcnRj b25uZWN0aW9uOjoxNDM6OnJvb3Q6Oih3cmFwcGVyKSBVbmtub3duIGxpYnZpcnRlcnJvcjogZWNv ZGU6IDgwIGVkb206IDIwIGxldmVsOiAyIG1lc3NhZ2U6IG1ldGFkYXRhIG5vdCBmb3VuZDogUmVx dWVzdGVkIG1ldGFkYXRhIGVsZW1lbnQgaXMgbm90IHByZXNlbnQNCkR1bW15LTE4OTUyNjA6OkRF QlVHOjoyMDE1LTExLTAzIDA4OjQ3OjMxLDQ3Nzo6c3RvcmFnZV9tYWlsYm94Ojo3MzE6OlN0b3Jh Z2UuTWlzYy5leGNDbWQ6OihfY2hlY2tGb3JNYWlsKSBkZCBpZj0vcmhldi9kYXRhLWNlbnRlci8w MDAwMDAwMi0wMDAyLTAwMDItMDAwMi0wMDAwMDAwMDAzZDUvbWFzdGVyc2QvZG9tX21kL2luYm94 IGlmbGFnPWRpcmVjdCxmdWxsYmxvY2sgY291bnQ9MSBicz0xMDI0MDAwIChjd2QgTm9uZSkNCkR1 bW15LTE4OTUyNjA6OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjMxLDUwMTo6c3RvcmFnZV9tYWls Ym94Ojo3MzE6OlN0b3JhZ2UuTWlzYy5leGNDbWQ6OihfY2hlY2tGb3JNYWlsKSBTVUNDRVNTOiA8 ZXJyPiA9ICcxKzAgcmVjb3JkcyBpblxuMSswIHJlY29yZHMgb3V0XG4xMDI0MDAwIGJ5dGVzICgx LjAgTUIpIGNvcGllZCwgMC4wMDMzMTI3OCBzLCAzMDkgTUIvc1xuJzsgPHJjPiA9IDANClRocmVh ZC03OTEzOjpERUJVRzo6MjAxNS0xMS0wMyAwODo0NzozMiwyOTg6OmxpYnZpcnRjb25uZWN0aW9u OjoxNDM6OnJvb3Q6Oih3cmFwcGVyKSBVbmtub3duIGxpYnZpcnRlcnJvcjogZWNvZGU6IDgwIGVk b206IDIwIGxldmVsOiAyIG1lc3NhZ2U6IG1ldGFkYXRhIG5vdCBmb3VuZDogUmVxdWVzdGVkIG1l dGFkYXRhIGVsZW1lbnQgaXMgbm90IHByZXNlbnQNClRocmVhZC01NjgyOjpERUJVRzo6MjAxNS0x MS0wMyAwODo0NzozMiw0MTc6OmxpYnZpcnRjb25uZWN0aW9uOjoxNDM6OnJvb3Q6Oih3cmFwcGVy KSBVbmtub3duIGxpYnZpcnRlcnJvcjogZWNvZGU6IDgwIGVkb206IDIwIGxldmVsOiAyIG1lc3Nh Z2U6IG1ldGFkYXRhIG5vdCBmb3VuZDogUmVxdWVzdGVkIG1ldGFkYXRhIGVsZW1lbnQgaXMgbm90 IHByZXNlbnQNCkRldGVjdG9yIHRocmVhZDo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzIsNTkx Ojpwcm90b2NvbGRldGVjdG9yOjoxODc6OnZkcy5NdWx0aVByb3RvY29sQWNjZXB0b3I6OihfYWRk X2Nvbm5lY3Rpb24pIEFkZGluZyBjb25uZWN0aW9uIGZyb20gMTI3LjAuMC4xOjQ0NjcxDQpEZXRl Y3RvciB0aHJlYWQ6OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjMyLDU5ODo6cHJvdG9jb2xkZXRl Y3Rvcjo6MjAxOjp2ZHMuTXVsdGlQcm90b2NvbEFjY2VwdG9yOjooX3JlbW92ZV9jb25uZWN0aW9u KSBDb25uZWN0aW9uIHJlbW92ZWQgZnJvbSAxMjcuMC4wLjE6NDQ2NzENCkRldGVjdG9yIHRocmVh ZDo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzIsNTk5Ojpwcm90b2NvbGRldGVjdG9yOjoyNDc6 OnZkcy5NdWx0aVByb3RvY29sQWNjZXB0b3I6OihfaGFuZGxlX2Nvbm5lY3Rpb25fcmVhZCkgRGV0 ZWN0ZWQgcHJvdG9jb2wgeG1sIGZyb20gMTI3LjAuMC4xOjQ0NjcxDQpEZXRlY3RvciB0aHJlYWQ6 OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjMyLDU5OTo6QmluZGluZ1hNTFJQQzo6MTE3Mzo6WG1s RGV0ZWN0b3I6OihoYW5kbGVTb2NrZXQpIHhtbCBvdmVyIGh0dHAgZGV0ZWN0ZWQgZnJvbSAoJzEy Ny4wLjAuMScsIDQ0NjcxKQ0KVGhyZWFkLTE5NDc2NDI6OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3 OjMyLDYwMjo6dGFzazo6NTk1OjpTdG9yYWdlLlRhc2tNYW5hZ2VyLlRhc2s6OihfdXBkYXRlU3Rh dGUpIFRhc2s9YDFkOTlhMTY2LWNiOWEtNDAyNS04MjExLWE0OGUyMTBiNTIzNGA6Om1vdmluZyBm cm9tIHN0YXRlIGluaXQgLT4gc3RhdGUgcHJlcGFyaW5nDQpUaHJlYWQtMTk0NzY0Mjo6SU5GTzo6 MjAxNS0xMS0wMyAwODo0NzozMiw2MDM6OmxvZ1V0aWxzOjo0NDo6ZGlzcGF0Y2hlcjo6KHdyYXBw ZXIpIFJ1biBhbmQgcHJvdGVjdDogcmVwb1N0YXRzKG9wdGlvbnM9Tm9uZSkNClRocmVhZC0xOTQ3 NjQyOjpJTkZPOjoyMDE1LTExLTAzIDA4OjQ3OjMyLDYwMzo6bG9nVXRpbHM6OjQ3OjpkaXNwYXRj aGVyOjood3JhcHBlcikgUnVuIGFuZCBwcm90ZWN0OiByZXBvU3RhdHMsIFJldHVybiByZXNwb25z ZToge3UnZGU5ZWI3MzctNjkxZi00NjIyLTkwNzAtODkxNTMxZDU5OWEwJzogeydjb2RlJzogMCwg J2FjdHVhbCc6IFRydWUsICd2ZXJzaW9uJzogMCwgJ2FjcXVpcmVkJzogVHJ1ZSwgJ2RlbGF5Jzog JzAuMDAwMzczNjEzJywgJ2xhc3RDaGVjayc6ICcyLjUnLCAndmFsaWQnOiBUcnVlfSwgdSdmZTRm ZDE5YS04NzE0LTQ0ZTAtYWU0MS02NjNhNGI2MmRhN2EnOiB7J2NvZGUnOiAwLCAnYWN0dWFsJzog VHJ1ZSwgJ3ZlcnNpb24nOiAwLCAnYWNxdWlyZWQnOiBUcnVlLCAnZGVsYXknOiAnMC4wMDA0MDk0 NDYnLCAnbGFzdENoZWNrJzogJzYuNCcsICd2YWxpZCc6IFRydWV9LCB1JzgyNTNhODliLTY1MWUt NGZmNC04NjViLTU3YWRlZjA1ZDM4Myc6IHsnY29kZSc6IDAsICdhY3R1YWwnOiBUcnVlLCAndmVy c2lvbic6IDMsICdhY3F1aXJlZCc6IFRydWUsICdkZWxheSc6ICcwLjAwMDUyMDY3MScsICdsYXN0 Q2hlY2snOiAnMS44JywgJ3ZhbGlkJzogVHJ1ZX0sICdiMThlYjI5ZS04YmIxLTQ1YjktYTYwZS1h OGUwNzIxMGUwNjYnOiB7J2NvZGUnOiAwLCAnYWN0dWFsJzogVHJ1ZSwgJ3ZlcnNpb24nOiAzLCAn YWNxdWlyZWQnOiBUcnVlLCAnZGVsYXknOiAnMC4wMDA0MjQ0NDUnLCAnbGFzdENoZWNrJzogJzYu NScsICd2YWxpZCc6IFRydWV9fQ0KVGhyZWFkLTE5NDc2NDI6OkRFQlVHOjoyMDE1LTExLTAzIDA4 OjQ3OjMyLDYwMzo6dGFzazo6MTE5MTo6U3RvcmFnZS5UYXNrTWFuYWdlci5UYXNrOjoocHJlcGFy ZSkgVGFzaz1gMWQ5OWExNjYtY2I5YS00MDI1LTgyMTEtYTQ4ZTIxMGI1MjM0YDo6ZmluaXNoZWQ6 IHt1J2RlOWViNzM3LTY5MWYtNDYyMi05MDcwLTg5MTUzMWQ1OTlhMCc6IHsnY29kZSc6IDAsICdh Y3R1YWwnOiBUcnVlLCAndmVyc2lvbic6IDAsICdhY3F1aXJlZCc6IFRydWUsICdkZWxheSc6ICcw LjAwMDM3MzYxMycsICdsYXN0Q2hlY2snOiAnMi41JywgJ3ZhbGlkJzogVHJ1ZX0sIHUnZmU0ZmQx OWEtODcxNC00NGUwLWFlNDEtNjYzYTRiNjJkYTdhJzogeydjb2RlJzogMCwgJ2FjdHVhbCc6IFRy dWUsICd2ZXJzaW9uJzogMCwgJ2FjcXVpcmVkJzogVHJ1ZSwgJ2RlbGF5JzogJzAuMDAwNDA5NDQ2 JywgJ2xhc3RDaGVjayc6ICc2LjQnLCAndmFsaWQnOiBUcnVlfSwgdSc4MjUzYTg5Yi02NTFlLTRm ZjQtODY1Yi01N2FkZWYwNWQzODMnOiB7J2NvZGUnOiAwLCAnYWN0dWFsJzogVHJ1ZSwgJ3ZlcnNp b24nOiAzLCAnYWNxdWlyZWQnOiBUcnVlLCAnZGVsYXknOiAnMC4wMDA1MjA2NzEnLCAnbGFzdENo ZWNrJzogJzEuOCcsICd2YWxpZCc6IFRydWV9LCAnYjE4ZWIyOWUtOGJiMS00NWI5LWE2MGUtYThl MDcyMTBlMDY2Jzogeydjb2RlJzogMCwgJ2FjdHVhbCc6IFRydWUsICd2ZXJzaW9uJzogMywgJ2Fj cXVpcmVkJzogVHJ1ZSwgJ2RlbGF5JzogJzAuMDAwNDI0NDQ1JywgJ2xhc3RDaGVjayc6ICc2LjUn LCAndmFsaWQnOiBUcnVlfX0NClRocmVhZC0xOTQ3NjQyOjpERUJVRzo6MjAxNS0xMS0wMyAwODo0 NzozMiw2MDM6OnRhc2s6OjU5NTo6U3RvcmFnZS5UYXNrTWFuYWdlci5UYXNrOjooX3VwZGF0ZVN0 YXRlKSBUYXNrPWAxZDk5YTE2Ni1jYjlhLTQwMjUtODIxMS1hNDhlMjEwYjUyMzRgOjptb3Zpbmcg ZnJvbSBzdGF0ZSBwcmVwYXJpbmcgLT4gc3RhdGUgZmluaXNoZWQNClRocmVhZC0xOTQ3NjQyOjpE RUJVRzo6MjAxNS0xMS0wMyAwODo0NzozMiw2MDQ6OnJlc291cmNlTWFuYWdlcjo6OTQwOjpTdG9y YWdlLlJlc291cmNlTWFuYWdlci5Pd25lcjo6KHJlbGVhc2VBbGwpIE93bmVyLnJlbGVhc2VBbGwg cmVxdWVzdHMge30gcmVzb3VyY2VzIHt9DQpUaHJlYWQtMTk0NzY0Mjo6REVCVUc6OjIwMTUtMTEt MDMgMDg6NDc6MzIsNjA0OjpyZXNvdXJjZU1hbmFnZXI6Ojk3Nzo6U3RvcmFnZS5SZXNvdXJjZU1h bmFnZXIuT3duZXI6OihjYW5jZWxBbGwpIE93bmVyLmNhbmNlbEFsbCByZXF1ZXN0cyB7fQ0KVGhy ZWFkLTE5NDc2NDI6OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjMyLDYwNDo6dGFzazo6OTkzOjpT dG9yYWdlLlRhc2tNYW5hZ2VyLlRhc2s6OihfZGVjcmVmKSBUYXNrPWAxZDk5YTE2Ni1jYjlhLTQw MjUtODIxMS1hNDhlMjEwYjUyMzRgOjpyZWYgMCBhYm9ydGluZyBGYWxzZQ0KVGhyZWFkLTYzNDg6 OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjMzLDI2MTo6bGlidmlydGNvbm5lY3Rpb246OjE0Mzo6 cm9vdDo6KHdyYXBwZXIpIFVua25vd24gbGlidmlydGVycm9yOiBlY29kZTogODAgZWRvbTogMjAg bGV2ZWw6IDIgbWVzc2FnZTogbWV0YWRhdGEgbm90IGZvdW5kOiBSZXF1ZXN0ZWQgbWV0YWRhdGEg ZWxlbWVudCBpcyBub3QgcHJlc2VudA0KVGhyZWFkLTcyODY6OkRFQlVHOjoyMDE1LTExLTAzIDA4 OjQ3OjMzLDQ2Mjo6bGlidmlydGNvbm5lY3Rpb246OjE0Mzo6cm9vdDo6KHdyYXBwZXIpIFVua25v d24gbGlidmlydGVycm9yOiBlY29kZTogODAgZWRvbTogMjAgbGV2ZWw6IDIgbWVzc2FnZTogbWV0 YWRhdGEgbm90IGZvdW5kOiBSZXF1ZXN0ZWQgbWV0YWRhdGEgZWxlbWVudCBpcyBub3QgcHJlc2Vu dA0KRHVtbXktMTg5NTI2MDo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzMsNTE0OjpzdG9yYWdl X21haWxib3g6OjczMTo6U3RvcmFnZS5NaXNjLmV4Y0NtZDo6KF9jaGVja0Zvck1haWwpIGRkIGlm PS9yaGV2L2RhdGEtY2VudGVyLzAwMDAwMDAyLTAwMDItMDAwMi0wMDAyLTAwMDAwMDAwMDNkNS9t YXN0ZXJzZC9kb21fbWQvaW5ib3ggaWZsYWc9ZGlyZWN0LGZ1bGxibG9jayBjb3VudD0xIGJzPTEw MjQwMDAgKGN3ZCBOb25lKQ0KRHVtbXktMTg5NTI2MDo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6 MzMsNTQwOjpzdG9yYWdlX21haWxib3g6OjczMTo6U3RvcmFnZS5NaXNjLmV4Y0NtZDo6KF9jaGVj a0Zvck1haWwpIFNVQ0NFU1M6IDxlcnI+ID0gJzErMCByZWNvcmRzIGluXG4xKzAgcmVjb3JkcyBv dXRcbjEwMjQwMDAgYnl0ZXMgKDEuMCBNQikgY29waWVkLCAwLjAwMzg1OTAxIHMsIDI2NSBNQi9z XG4nOyA8cmM+ID0gMA0KVGhyZWFkLTc2Mjc6OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjMzLDkz ODo6bGlidmlydGNvbm5lY3Rpb246OjE0Mzo6cm9vdDo6KHdyYXBwZXIpIFVua25vd24gbGlidmly dGVycm9yOiBlY29kZTogODAgZWRvbTogMjAgbGV2ZWw6IDIgbWVzc2FnZTogbWV0YWRhdGEgbm90 IGZvdW5kOiBSZXF1ZXN0ZWQgbWV0YWRhdGEgZWxlbWVudCBpcyBub3QgcHJlc2VudA0KVGhyZWFk LTc5NTE6OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjMzLDkzODo6bGlidmlydGNvbm5lY3Rpb246 OjE0Mzo6cm9vdDo6KHdyYXBwZXIpIFVua25vd24gbGlidmlydGVycm9yOiBlY29kZTogODAgZWRv bTogMjAgbGV2ZWw6IDIgbWVzc2FnZTogbWV0YWRhdGEgbm90IGZvdW5kOiBSZXF1ZXN0ZWQgbWV0 YWRhdGEgZWxlbWVudCBpcyBub3QgcHJlc2VudA0KVGhyZWFkLTM4ODI6OkRFQlVHOjoyMDE1LTEx LTAzIDA4OjQ3OjMzLDk0MDo6bGlidmlydGNvbm5lY3Rpb246OjE0Mzo6cm9vdDo6KHdyYXBwZXIp IFVua25vd24gbGlidmlydGVycm9yOiBlY29kZTogODAgZWRvbTogMjAgbGV2ZWw6IDIgbWVzc2Fn ZTogbWV0YWRhdGEgbm90IGZvdW5kOiBSZXF1ZXN0ZWQgbWV0YWRhdGEgZWxlbWVudCBpcyBub3Qg cHJlc2VudA0KVGhyZWFkLTc5Njc6OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjMzLDk0MDo6bGli dmlydGNvbm5lY3Rpb246OjE0Mzo6cm9vdDo6KHdyYXBwZXIpIFVua25vd24gbGlidmlydGVycm9y OiBlY29kZTogODAgZWRvbTogMjAgbGV2ZWw6IDIgbWVzc2FnZTogbWV0YWRhdGEgbm90IGZvdW5k OiBSZXF1ZXN0ZWQgbWV0YWRhdGEgZWxlbWVudCBpcyBub3QgcHJlc2VudA0KVGhyZWFkLTc4OTk6 OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjMzLDk1MTo6bGlidmlydGNvbm5lY3Rpb246OjE0Mzo6 cm9vdDo6KHdyYXBwZXIpIFVua25vd24gbGlidmlydGVycm9yOiBlY29kZTogODAgZWRvbTogMjAg bGV2ZWw6IDIgbWVzc2FnZTogbWV0YWRhdGEgbm90IGZvdW5kOiBSZXF1ZXN0ZWQgbWV0YWRhdGEg ZWxlbWVudCBpcyBub3QgcHJlc2VudA0KVk0gQ2hhbm5lbHMgTGlzdGVuZXI6OkRFQlVHOjoyMDE1 LTExLTAzIDA4OjQ3OjM0LDM4Mzo6dm1jaGFubmVsczo6OTY6OnZkczo6KF9oYW5kbGVfdGltZW91 dHMpIFRpbWVvdXQgb24gZmlsZW5vIDEzMy4NClZNIENoYW5uZWxzIExpc3RlbmVyOjpERUJVRzo6 MjAxNS0xMS0wMyAwODo0NzozNCwzODM6OnZtY2hhbm5lbHM6Ojk2Ojp2ZHM6OihfaGFuZGxlX3Rp bWVvdXRzKSBUaW1lb3V0IG9uIGZpbGVubyAxMzUuDQpWTSBDaGFubmVscyBMaXN0ZW5lcjo6REVC VUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsMzgzOjp2bWNoYW5uZWxzOjo5Njo6dmRzOjooX2hhbmRs ZV90aW1lb3V0cykgVGltZW91dCBvbiBmaWxlbm8gMTM2Lg0KVk0gQ2hhbm5lbHMgTGlzdGVuZXI6 OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjM0LDM4Mzo6dm1jaGFubmVsczo6OTY6OnZkczo6KF9o YW5kbGVfdGltZW91dHMpIFRpbWVvdXQgb24gZmlsZW5vIDE0Ni4NClZNIENoYW5uZWxzIExpc3Rl bmVyOjpERUJVRzo6MjAxNS0xMS0wMyAwODo0NzozNCwzODQ6OnZtY2hhbm5lbHM6Ojk2Ojp2ZHM6 OihfaGFuZGxlX3RpbWVvdXRzKSBUaW1lb3V0IG9uIGZpbGVubyAxNjAuDQpWTSBDaGFubmVscyBM aXN0ZW5lcjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsMzg0Ojp2bWNoYW5uZWxzOjo5Njo6 dmRzOjooX2hhbmRsZV90aW1lb3V0cykgVGltZW91dCBvbiBmaWxlbm8gMTYxLg0KVk0gQ2hhbm5l bHMgTGlzdGVuZXI6OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjM0LDM4NDo6dm1jaGFubmVsczo6 OTY6OnZkczo6KF9oYW5kbGVfdGltZW91dHMpIFRpbWVvdXQgb24gZmlsZW5vIDE2Ny4NClZNIENo YW5uZWxzIExpc3RlbmVyOjpERUJVRzo6MjAxNS0xMS0wMyAwODo0NzozNCwzODQ6OnZtY2hhbm5l bHM6Ojk2Ojp2ZHM6OihfaGFuZGxlX3RpbWVvdXRzKSBUaW1lb3V0IG9uIGZpbGVubyAxNzEuDQpW TSBDaGFubmVscyBMaXN0ZW5lcjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsMzg0Ojp2bWNo YW5uZWxzOjo5Njo6dmRzOjooX2hhbmRsZV90aW1lb3V0cykgVGltZW91dCBvbiBmaWxlbm8gMTcy Lg0KVk0gQ2hhbm5lbHMgTGlzdGVuZXI6OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjM0LDM4NDo6 dm1jaGFubmVsczo6OTY6OnZkczo6KF9oYW5kbGVfdGltZW91dHMpIFRpbWVvdXQgb24gZmlsZW5v IDE1OS4NClZNIENoYW5uZWxzIExpc3RlbmVyOjpERUJVRzo6MjAxNS0xMS0wMyAwODo0NzozNCwz ODU6OnZtY2hhbm5lbHM6Ojk2Ojp2ZHM6OihfaGFuZGxlX3RpbWVvdXRzKSBUaW1lb3V0IG9uIGZp bGVubyAxODkuDQpWTSBDaGFubmVscyBMaXN0ZW5lcjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6 MzQsMzg1Ojp2bWNoYW5uZWxzOjo5Njo6dmRzOjooX2hhbmRsZV90aW1lb3V0cykgVGltZW91dCBv biBmaWxlbm8gMTkwLg0KVk0gQ2hhbm5lbHMgTGlzdGVuZXI6OkRFQlVHOjoyMDE1LTExLTAzIDA4 OjQ3OjM0LDM4NTo6dm1jaGFubmVsczo6OTY6OnZkczo6KF9oYW5kbGVfdGltZW91dHMpIFRpbWVv dXQgb24gZmlsZW5vIDE5NS4NClZNIENoYW5uZWxzIExpc3RlbmVyOjpERUJVRzo6MjAxNS0xMS0w MyAwODo0NzozNCwzODU6OnZtY2hhbm5lbHM6Ojk2Ojp2ZHM6OihfaGFuZGxlX3RpbWVvdXRzKSBU aW1lb3V0IG9uIGZpbGVubyAxOTcuDQpWTSBDaGFubmVscyBMaXN0ZW5lcjo6REVCVUc6OjIwMTUt MTEtMDMgMDg6NDc6MzQsMzg1Ojp2bWNoYW5uZWxzOjo5Njo6dmRzOjooX2hhbmRsZV90aW1lb3V0 cykgVGltZW91dCBvbiBmaWxlbm8gMTk4Lg0KVk0gQ2hhbm5lbHMgTGlzdGVuZXI6OkRFQlVHOjoy MDE1LTExLTAzIDA4OjQ3OjM0LDM4NTo6dm1jaGFubmVsczo6OTY6OnZkczo6KF9oYW5kbGVfdGlt ZW91dHMpIFRpbWVvdXQgb24gZmlsZW5vIDIxMy4NClZNIENoYW5uZWxzIExpc3RlbmVyOjpERUJV Rzo6MjAxNS0xMS0wMyAwODo0NzozNCwzODY6OnZtY2hhbm5lbHM6Ojk2Ojp2ZHM6OihfaGFuZGxl X3RpbWVvdXRzKSBUaW1lb3V0IG9uIGZpbGVubyAyMTUuDQpWTSBDaGFubmVscyBMaXN0ZW5lcjo6 REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsMzg2Ojp2bWNoYW5uZWxzOjo5Njo6dmRzOjooX2hh bmRsZV90aW1lb3V0cykgVGltZW91dCBvbiBmaWxlbm8gOTguDQpWTSBDaGFubmVscyBMaXN0ZW5l cjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsMzg2Ojp2bWNoYW5uZWxzOjo5Njo6dmRzOjoo X2hhbmRsZV90aW1lb3V0cykgVGltZW91dCBvbiBmaWxlbm8gMTI1Lg0KSnNvblJwYyAoU3RvbXBS ZWFjdG9yKTo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsNDEyOjpzdG9tcFJlYWN0b3I6Ojk4 OjpCcm9rZXIuU3RvbXBBZGFwdGVyOjooaGFuZGxlX2ZyYW1lKSBIYW5kbGluZyBtZXNzYWdlIDxT dG9tcEZyYW1lIGNvbW1hbmQ9J1NFTkQnPg0KSnNvblJwY1NlcnZlcjo6REVCVUc6OjIwMTUtMTEt MDMgMDg6NDc6MzQsNDEzOjpfX2luaXRfXzo6NTMwOjpqc29ucnBjLkpzb25ScGNTZXJ2ZXI6Oihz ZXJ2ZV9yZXF1ZXN0cykgV2FpdGluZyBmb3IgcmVxdWVzdA0KVGhyZWFkLTE5NDc2NDM6OkRFQlVH OjoyMDE1LTExLTAzIDA4OjQ3OjM0LDQzNzo6c3RvbXBSZWFjdG9yOjoxNjM6OnlhanNvbnJwYy5T dG9tcFNlcnZlcjo6KHNlbmQpIFNlbmRpbmcgcmVzcG9uc2UNClRocmVhZC03NjEzOjpERUJVRzo6 MjAxNS0xMS0wMyAwODo0NzozNCw3MTM6OmxpYnZpcnRjb25uZWN0aW9uOjoxNDM6OnJvb3Q6Oih3 cmFwcGVyKSBVbmtub3duIGxpYnZpcnRlcnJvcjogZWNvZGU6IDgwIGVkb206IDIwIGxldmVsOiAy IG1lc3NhZ2U6IG1ldGFkYXRhIG5vdCBmb3VuZDogUmVxdWVzdGVkIG1ldGFkYXRhIGVsZW1lbnQg aXMgbm90IHByZXNlbnQNClRocmVhZC02MzkzOjpERUJVRzo6MjAxNS0xMS0wMyAwODo0NzozNCw3 MTM6OmxpYnZpcnRjb25uZWN0aW9uOjoxNDM6OnJvb3Q6Oih3cmFwcGVyKSBVbmtub3duIGxpYnZp cnRlcnJvcjogZWNvZGU6IDgwIGVkb206IDIwIGxldmVsOiAyIG1lc3NhZ2U6IG1ldGFkYXRhIG5v dCBmb3VuZDogUmVxdWVzdGVkIG1ldGFkYXRhIGVsZW1lbnQgaXMgbm90IHByZXNlbnQNClRocmVh ZC0yMjY5NDE6OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjM1LDUxMTo6dGFzazo6NTk1OjpTdG9y YWdlLlRhc2tNYW5hZ2VyLlRhc2s6OihfdXBkYXRlU3RhdGUpIFRhc2s9YGJkZjI2NDAxLTMyNGMt NDIyMC05MDM0LTE5YzdkODE2ZjY0MmA6Om1vdmluZyBmcm9tIHN0YXRlIGluaXQgLT4gc3RhdGUg cHJlcGFyaW5nDQpUaHJlYWQtNDcwOTo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzUsNTExOjp0 YXNrOjo1OTU6OlN0b3JhZ2UuVGFza01hbmFnZXIuVGFzazo6KF91cGRhdGVTdGF0ZSkgVGFzaz1g MGFjMmY4NTQtNDFlMy00NDI3LWEwZjQtNWVhYTE4NDJlMjEyYDo6bW92aW5nIGZyb20gc3RhdGUg aW5pdCAtPiBzdGF0ZSBwcmVwYXJpbmcNCg0KLS0NCg0KQ2hyaXN0b3BoZQ0KDQoNCg== --_000_ABC69195C9484895AAFF1900F54BBE43unilu_ Content-Type: text/html; charset="utf-8" Content-ID: <05E547F58ADC464D9D0F9ACEF203BCD2(a)uni.lux> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGNoZWNrZWQgdGhlIGxvZ3Mgb24g bXkgaHlwZXJ2aXNvciB0aGF0IGNvbnRhaW5zIGFsc28gdGhlIG92ZXJ0LWVuZ2luZSAoc2VsZi1o b3N0ZWQpIGFuZCBJIHNlZSBzdHJhbmdlIHVua25vd24gbGlidmlydGVycm9ycyB0aGF0IGNvbWUg cGVyaW9kaWNhbGx5IGluIHRoZSB2ZHNtLmxvZyBmaWxlLiBUaGUgc3RvcmFnZSBpcyBnbHVzdGVy RlMgcnVubmluZyBvbiB0aGUgaHlwZXJ2aXNvciBhcyB3ZWxsLCBvbmUgTkZTIGV4cG9ydA0KIGRv bWFpbiBhbmQgYW4gSVNPIGRvbWFpbi4gQSBORlMgZG9tYWluIGZyb20gYW5vdGhlciBwbGFjZSBp cyBpbiBtYWludGVuYW5jZSBtb2RlLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBhbSBydW5uaW5nIG9WaXJ0IDMuNS4zLjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhhbmsg eW91IGZvciBhbnkgcG9pbnRlcnMgYXMgdG8gd2hlcmUgdG8gc3RhcnQgZml4aW5nIHRoaXMgaXNz dWUuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj7igJQgbG9nIGV4Y2VycHQgLS08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ VGhyZWFkLTE5NDc2NDE6OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjMxLDM5ODo6c3RvbXBSZWFj dG9yOjoxNjM6OnlhanNvbnJwYy5TdG9tcFNlcnZlcjo6KHNlbmQpIFNlbmRpbmcgcmVzcG9uc2U8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhyZWFkLTgxMDg6OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3 OjMxLDQxMDo6bGlidmlydGNvbm5lY3Rpb246OjE0Mzo6cm9vdDo6KHdyYXBwZXIpIFVua25vd24g bGlidmlydGVycm9yOiBlY29kZTogODAgZWRvbTogMjAgbGV2ZWw6IDIgbWVzc2FnZTogbWV0YWRh dGEgbm90IGZvdW5kOiBSZXF1ZXN0ZWQgbWV0YWRhdGEgZWxlbWVudCBpcyBub3QgcHJlc2VudDwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5EdW1teS0xODk1MjYwOjpERUJVRzo6MjAxNS0xMS0wMyAwODo0 NzozMSw0Nzc6OnN0b3JhZ2VfbWFpbGJveDo6NzMxOjpTdG9yYWdlLk1pc2MuZXhjQ21kOjooX2No ZWNrRm9yTWFpbCkgZGQgaWY9L3JoZXYvZGF0YS1jZW50ZXIvMDAwMDAwMDItMDAwMi0wMDAyLTAw MDItMDAwMDAwMDAwM2Q1L21hc3RlcnNkL2RvbV9tZC9pbmJveCBpZmxhZz1kaXJlY3QsZnVsbGJs b2NrIGNvdW50PTEgYnM9MTAyNDAwMCAoY3dkIE5vbmUpPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkR1 bW15LTE4OTUyNjA6OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjMxLDUwMTo6c3RvcmFnZV9tYWls Ym94Ojo3MzE6OlN0b3JhZ2UuTWlzYy5leGNDbWQ6OihfY2hlY2tGb3JNYWlsKSBTVUNDRVNTOiAm bHQ7ZXJyJmd0OyA9ICcxJiM0MzswIHJlY29yZHMgaW5cbjEmIzQzOzAgcmVjb3JkcyBvdXRcbjEw MjQwMDAgYnl0ZXMgKDEuMCBNQikgY29waWVkLCAwLjAwMzMxMjc4IHMsIDMwOSBNQi9zXG4nOyAm bHQ7cmMmZ3Q7ID0gMDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaHJlYWQtNzkxMzo6REVCVUc6OjIw MTUtMTEtMDMgMDg6NDc6MzIsMjk4OjpsaWJ2aXJ0Y29ubmVjdGlvbjo6MTQzOjpyb290Ojood3Jh cHBlcikgVW5rbm93biBsaWJ2aXJ0ZXJyb3I6IGVjb2RlOiA4MCBlZG9tOiAyMCBsZXZlbDogMiBt ZXNzYWdlOiBtZXRhZGF0YSBub3QgZm91bmQ6IFJlcXVlc3RlZCBtZXRhZGF0YSBlbGVtZW50IGlz IG5vdCBwcmVzZW50PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRocmVhZC01NjgyOjpERUJVRzo6MjAx NS0xMS0wMyAwODo0NzozMiw0MTc6OmxpYnZpcnRjb25uZWN0aW9uOjoxNDM6OnJvb3Q6Oih3cmFw cGVyKSBVbmtub3duIGxpYnZpcnRlcnJvcjogZWNvZGU6IDgwIGVkb206IDIwIGxldmVsOiAyIG1l c3NhZ2U6IG1ldGFkYXRhIG5vdCBmb3VuZDogUmVxdWVzdGVkIG1ldGFkYXRhIGVsZW1lbnQgaXMg bm90IHByZXNlbnQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RGV0ZWN0b3IgdGhyZWFkOjpERUJVRzo6 MjAxNS0xMS0wMyAwODo0NzozMiw1OTE6OnByb3RvY29sZGV0ZWN0b3I6OjE4Nzo6dmRzLk11bHRp UHJvdG9jb2xBY2NlcHRvcjo6KF9hZGRfY29ubmVjdGlvbikgQWRkaW5nIGNvbm5lY3Rpb24gZnJv bSAxMjcuMC4wLjE6NDQ2NzE8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RGV0ZWN0b3IgdGhyZWFkOjpE RUJVRzo6MjAxNS0xMS0wMyAwODo0NzozMiw1OTg6OnByb3RvY29sZGV0ZWN0b3I6OjIwMTo6dmRz Lk11bHRpUHJvdG9jb2xBY2NlcHRvcjo6KF9yZW1vdmVfY29ubmVjdGlvbikgQ29ubmVjdGlvbiBy ZW1vdmVkIGZyb20gMTI3LjAuMC4xOjQ0NjcxPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkRldGVjdG9y IHRocmVhZDo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzIsNTk5Ojpwcm90b2NvbGRldGVjdG9y OjoyNDc6OnZkcy5NdWx0aVByb3RvY29sQWNjZXB0b3I6OihfaGFuZGxlX2Nvbm5lY3Rpb25fcmVh ZCkgRGV0ZWN0ZWQgcHJvdG9jb2wgeG1sIGZyb20gMTI3LjAuMC4xOjQ0NjcxPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkRldGVjdG9yIHRocmVhZDo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzIsNTk5 OjpCaW5kaW5nWE1MUlBDOjoxMTczOjpYbWxEZXRlY3Rvcjo6KGhhbmRsZVNvY2tldCkgeG1sIG92 ZXIgaHR0cCBkZXRlY3RlZCBmcm9tICgnMTI3LjAuMC4xJywgNDQ2NzEpPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPlRocmVhZC0xOTQ3NjQyOjpERUJVRzo6MjAxNS0xMS0wMyAwODo0NzozMiw2MDI6OnRh c2s6OjU5NTo6U3RvcmFnZS5UYXNrTWFuYWdlci5UYXNrOjooX3VwZGF0ZVN0YXRlKSBUYXNrPWAx ZDk5YTE2Ni1jYjlhLTQwMjUtODIxMS1hNDhlMjEwYjUyMzRgOjptb3ZpbmcgZnJvbSBzdGF0ZSBp bml0IC0mZ3Q7IHN0YXRlIHByZXBhcmluZzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaHJlYWQtMTk0 NzY0Mjo6SU5GTzo6MjAxNS0xMS0wMyAwODo0NzozMiw2MDM6OmxvZ1V0aWxzOjo0NDo6ZGlzcGF0 Y2hlcjo6KHdyYXBwZXIpIFJ1biBhbmQgcHJvdGVjdDogcmVwb1N0YXRzKG9wdGlvbnM9Tm9uZSk8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhyZWFkLTE5NDc2NDI6OklORk86OjIwMTUtMTEtMDMgMDg6 NDc6MzIsNjAzOjpsb2dVdGlsczo6NDc6OmRpc3BhdGNoZXI6Oih3cmFwcGVyKSBSdW4gYW5kIHBy b3RlY3Q6IHJlcG9TdGF0cywgUmV0dXJuIHJlc3BvbnNlOiB7dSdkZTllYjczNy02OTFmLTQ2MjIt OTA3MC04OTE1MzFkNTk5YTAnOiB7J2NvZGUnOiAwLCAnYWN0dWFsJzogVHJ1ZSwgJ3ZlcnNpb24n OiAwLCAnYWNxdWlyZWQnOiBUcnVlLCAnZGVsYXknOiAnMC4wMDAzNzM2MTMnLA0KICdsYXN0Q2hl Y2snOiAnMi41JywgJ3ZhbGlkJzogVHJ1ZX0sIHUnZmU0ZmQxOWEtODcxNC00NGUwLWFlNDEtNjYz YTRiNjJkYTdhJzogeydjb2RlJzogMCwgJ2FjdHVhbCc6IFRydWUsICd2ZXJzaW9uJzogMCwgJ2Fj cXVpcmVkJzogVHJ1ZSwgJ2RlbGF5JzogJzAuMDAwNDA5NDQ2JywgJ2xhc3RDaGVjayc6ICc2LjQn LCAndmFsaWQnOiBUcnVlfSwgdSc4MjUzYTg5Yi02NTFlLTRmZjQtODY1Yi01N2FkZWYwNWQzODMn OiB7J2NvZGUnOiAwLCAnYWN0dWFsJzoNCiBUcnVlLCAndmVyc2lvbic6IDMsICdhY3F1aXJlZCc6 IFRydWUsICdkZWxheSc6ICcwLjAwMDUyMDY3MScsICdsYXN0Q2hlY2snOiAnMS44JywgJ3ZhbGlk JzogVHJ1ZX0sICdiMThlYjI5ZS04YmIxLTQ1YjktYTYwZS1hOGUwNzIxMGUwNjYnOiB7J2NvZGUn OiAwLCAnYWN0dWFsJzogVHJ1ZSwgJ3ZlcnNpb24nOiAzLCAnYWNxdWlyZWQnOiBUcnVlLCAnZGVs YXknOiAnMC4wMDA0MjQ0NDUnLCAnbGFzdENoZWNrJzogJzYuNScsICd2YWxpZCc6IFRydWV9fTwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaHJlYWQtMTk0NzY0Mjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6 NDc6MzIsNjAzOjp0YXNrOjoxMTkxOjpTdG9yYWdlLlRhc2tNYW5hZ2VyLlRhc2s6OihwcmVwYXJl KSBUYXNrPWAxZDk5YTE2Ni1jYjlhLTQwMjUtODIxMS1hNDhlMjEwYjUyMzRgOjpmaW5pc2hlZDog e3UnZGU5ZWI3MzctNjkxZi00NjIyLTkwNzAtODkxNTMxZDU5OWEwJzogeydjb2RlJzogMCwgJ2Fj dHVhbCc6IFRydWUsICd2ZXJzaW9uJzogMCwgJ2FjcXVpcmVkJzoNCiBUcnVlLCAnZGVsYXknOiAn MC4wMDAzNzM2MTMnLCAnbGFzdENoZWNrJzogJzIuNScsICd2YWxpZCc6IFRydWV9LCB1J2ZlNGZk MTlhLTg3MTQtNDRlMC1hZTQxLTY2M2E0YjYyZGE3YSc6IHsnY29kZSc6IDAsICdhY3R1YWwnOiBU cnVlLCAndmVyc2lvbic6IDAsICdhY3F1aXJlZCc6IFRydWUsICdkZWxheSc6ICcwLjAwMDQwOTQ0 NicsICdsYXN0Q2hlY2snOiAnNi40JywgJ3ZhbGlkJzogVHJ1ZX0sIHUnODI1M2E4OWItNjUxZS00 ZmY0LTg2NWItNTdhZGVmMDVkMzgzJzoNCiB7J2NvZGUnOiAwLCAnYWN0dWFsJzogVHJ1ZSwgJ3Zl cnNpb24nOiAzLCAnYWNxdWlyZWQnOiBUcnVlLCAnZGVsYXknOiAnMC4wMDA1MjA2NzEnLCAnbGFz dENoZWNrJzogJzEuOCcsICd2YWxpZCc6IFRydWV9LCAnYjE4ZWIyOWUtOGJiMS00NWI5LWE2MGUt YThlMDcyMTBlMDY2Jzogeydjb2RlJzogMCwgJ2FjdHVhbCc6IFRydWUsICd2ZXJzaW9uJzogMywg J2FjcXVpcmVkJzogVHJ1ZSwgJ2RlbGF5JzogJzAuMDAwNDI0NDQ1JywgJ2xhc3RDaGVjayc6DQog JzYuNScsICd2YWxpZCc6IFRydWV9fTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaHJlYWQtMTk0NzY0 Mjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzIsNjAzOjp0YXNrOjo1OTU6OlN0b3JhZ2UuVGFz a01hbmFnZXIuVGFzazo6KF91cGRhdGVTdGF0ZSkgVGFzaz1gMWQ5OWExNjYtY2I5YS00MDI1LTgy MTEtYTQ4ZTIxMGI1MjM0YDo6bW92aW5nIGZyb20gc3RhdGUgcHJlcGFyaW5nIC0mZ3Q7IHN0YXRl IGZpbmlzaGVkPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRocmVhZC0xOTQ3NjQyOjpERUJVRzo6MjAx NS0xMS0wMyAwODo0NzozMiw2MDQ6OnJlc291cmNlTWFuYWdlcjo6OTQwOjpTdG9yYWdlLlJlc291 cmNlTWFuYWdlci5Pd25lcjo6KHJlbGVhc2VBbGwpIE93bmVyLnJlbGVhc2VBbGwgcmVxdWVzdHMg e30gcmVzb3VyY2VzIHt9PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRocmVhZC0xOTQ3NjQyOjpERUJV Rzo6MjAxNS0xMS0wMyAwODo0NzozMiw2MDQ6OnJlc291cmNlTWFuYWdlcjo6OTc3OjpTdG9yYWdl LlJlc291cmNlTWFuYWdlci5Pd25lcjo6KGNhbmNlbEFsbCkgT3duZXIuY2FuY2VsQWxsIHJlcXVl c3RzIHt9PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRocmVhZC0xOTQ3NjQyOjpERUJVRzo6MjAxNS0x MS0wMyAwODo0NzozMiw2MDQ6OnRhc2s6Ojk5Mzo6U3RvcmFnZS5UYXNrTWFuYWdlci5UYXNrOjoo X2RlY3JlZikgVGFzaz1gMWQ5OWExNjYtY2I5YS00MDI1LTgyMTEtYTQ4ZTIxMGI1MjM0YDo6cmVm IDAgYWJvcnRpbmcgRmFsc2U8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhyZWFkLTYzNDg6OkRFQlVH OjoyMDE1LTExLTAzIDA4OjQ3OjMzLDI2MTo6bGlidmlydGNvbm5lY3Rpb246OjE0Mzo6cm9vdDo6 KHdyYXBwZXIpIFVua25vd24gbGlidmlydGVycm9yOiBlY29kZTogODAgZWRvbTogMjAgbGV2ZWw6 IDIgbWVzc2FnZTogbWV0YWRhdGEgbm90IGZvdW5kOiBSZXF1ZXN0ZWQgbWV0YWRhdGEgZWxlbWVu dCBpcyBub3QgcHJlc2VudDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaHJlYWQtNzI4Njo6REVCVUc6 OjIwMTUtMTEtMDMgMDg6NDc6MzMsNDYyOjpsaWJ2aXJ0Y29ubmVjdGlvbjo6MTQzOjpyb290Ojoo d3JhcHBlcikgVW5rbm93biBsaWJ2aXJ0ZXJyb3I6IGVjb2RlOiA4MCBlZG9tOiAyMCBsZXZlbDog MiBtZXNzYWdlOiBtZXRhZGF0YSBub3QgZm91bmQ6IFJlcXVlc3RlZCBtZXRhZGF0YSBlbGVtZW50 IGlzIG5vdCBwcmVzZW50PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkR1bW15LTE4OTUyNjA6OkRFQlVH OjoyMDE1LTExLTAzIDA4OjQ3OjMzLDUxNDo6c3RvcmFnZV9tYWlsYm94Ojo3MzE6OlN0b3JhZ2Uu TWlzYy5leGNDbWQ6OihfY2hlY2tGb3JNYWlsKSBkZCBpZj0vcmhldi9kYXRhLWNlbnRlci8wMDAw MDAwMi0wMDAyLTAwMDItMDAwMi0wMDAwMDAwMDAzZDUvbWFzdGVyc2QvZG9tX21kL2luYm94IGlm bGFnPWRpcmVjdCxmdWxsYmxvY2sgY291bnQ9MSBicz0xMDI0MDAwIChjd2QgTm9uZSk8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+RHVtbXktMTg5NTI2MDo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzMs NTQwOjpzdG9yYWdlX21haWxib3g6OjczMTo6U3RvcmFnZS5NaXNjLmV4Y0NtZDo6KF9jaGVja0Zv ck1haWwpIFNVQ0NFU1M6ICZsdDtlcnImZ3Q7ID0gJzEmIzQzOzAgcmVjb3JkcyBpblxuMSYjNDM7 MCByZWNvcmRzIG91dFxuMTAyNDAwMCBieXRlcyAoMS4wIE1CKSBjb3BpZWQsIDAuMDAzODU5MDEg cywgMjY1IE1CL3Ncbic7ICZsdDtyYyZndDsgPSAwPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRocmVh ZC03NjI3OjpERUJVRzo6MjAxNS0xMS0wMyAwODo0NzozMyw5Mzg6OmxpYnZpcnRjb25uZWN0aW9u OjoxNDM6OnJvb3Q6Oih3cmFwcGVyKSBVbmtub3duIGxpYnZpcnRlcnJvcjogZWNvZGU6IDgwIGVk b206IDIwIGxldmVsOiAyIG1lc3NhZ2U6IG1ldGFkYXRhIG5vdCBmb3VuZDogUmVxdWVzdGVkIG1l dGFkYXRhIGVsZW1lbnQgaXMgbm90IHByZXNlbnQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhyZWFk LTc5NTE6OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjMzLDkzODo6bGlidmlydGNvbm5lY3Rpb246 OjE0Mzo6cm9vdDo6KHdyYXBwZXIpIFVua25vd24gbGlidmlydGVycm9yOiBlY29kZTogODAgZWRv bTogMjAgbGV2ZWw6IDIgbWVzc2FnZTogbWV0YWRhdGEgbm90IGZvdW5kOiBSZXF1ZXN0ZWQgbWV0 YWRhdGEgZWxlbWVudCBpcyBub3QgcHJlc2VudDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaHJlYWQt Mzg4Mjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzMsOTQwOjpsaWJ2aXJ0Y29ubmVjdGlvbjo6 MTQzOjpyb290Ojood3JhcHBlcikgVW5rbm93biBsaWJ2aXJ0ZXJyb3I6IGVjb2RlOiA4MCBlZG9t OiAyMCBsZXZlbDogMiBtZXNzYWdlOiBtZXRhZGF0YSBub3QgZm91bmQ6IFJlcXVlc3RlZCBtZXRh ZGF0YSBlbGVtZW50IGlzIG5vdCBwcmVzZW50PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRocmVhZC03 OTY3OjpERUJVRzo6MjAxNS0xMS0wMyAwODo0NzozMyw5NDA6OmxpYnZpcnRjb25uZWN0aW9uOjox NDM6OnJvb3Q6Oih3cmFwcGVyKSBVbmtub3duIGxpYnZpcnRlcnJvcjogZWNvZGU6IDgwIGVkb206 IDIwIGxldmVsOiAyIG1lc3NhZ2U6IG1ldGFkYXRhIG5vdCBmb3VuZDogUmVxdWVzdGVkIG1ldGFk YXRhIGVsZW1lbnQgaXMgbm90IHByZXNlbnQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhyZWFkLTc4 OTk6OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjMzLDk1MTo6bGlidmlydGNvbm5lY3Rpb246OjE0 Mzo6cm9vdDo6KHdyYXBwZXIpIFVua25vd24gbGlidmlydGVycm9yOiBlY29kZTogODAgZWRvbTog MjAgbGV2ZWw6IDIgbWVzc2FnZTogbWV0YWRhdGEgbm90IGZvdW5kOiBSZXF1ZXN0ZWQgbWV0YWRh dGEgZWxlbWVudCBpcyBub3QgcHJlc2VudDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5WTSBDaGFubmVs cyBMaXN0ZW5lcjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsMzgzOjp2bWNoYW5uZWxzOjo5 Njo6dmRzOjooX2hhbmRsZV90aW1lb3V0cykgVGltZW91dCBvbiBmaWxlbm8gMTMzLjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5WTSBDaGFubmVscyBMaXN0ZW5lcjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6 NDc6MzQsMzgzOjp2bWNoYW5uZWxzOjo5Njo6dmRzOjooX2hhbmRsZV90aW1lb3V0cykgVGltZW91 dCBvbiBmaWxlbm8gMTM1LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5WTSBDaGFubmVscyBMaXN0ZW5l cjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsMzgzOjp2bWNoYW5uZWxzOjo5Njo6dmRzOjoo X2hhbmRsZV90aW1lb3V0cykgVGltZW91dCBvbiBmaWxlbm8gMTM2LjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5WTSBDaGFubmVscyBMaXN0ZW5lcjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsMzgz Ojp2bWNoYW5uZWxzOjo5Njo6dmRzOjooX2hhbmRsZV90aW1lb3V0cykgVGltZW91dCBvbiBmaWxl bm8gMTQ2LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5WTSBDaGFubmVscyBMaXN0ZW5lcjo6REVCVUc6 OjIwMTUtMTEtMDMgMDg6NDc6MzQsMzg0Ojp2bWNoYW5uZWxzOjo5Njo6dmRzOjooX2hhbmRsZV90 aW1lb3V0cykgVGltZW91dCBvbiBmaWxlbm8gMTYwLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5WTSBD aGFubmVscyBMaXN0ZW5lcjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsMzg0Ojp2bWNoYW5u ZWxzOjo5Njo6dmRzOjooX2hhbmRsZV90aW1lb3V0cykgVGltZW91dCBvbiBmaWxlbm8gMTYxLjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5WTSBDaGFubmVscyBMaXN0ZW5lcjo6REVCVUc6OjIwMTUtMTEt MDMgMDg6NDc6MzQsMzg0Ojp2bWNoYW5uZWxzOjo5Njo6dmRzOjooX2hhbmRsZV90aW1lb3V0cykg VGltZW91dCBvbiBmaWxlbm8gMTY3LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5WTSBDaGFubmVscyBM aXN0ZW5lcjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsMzg0Ojp2bWNoYW5uZWxzOjo5Njo6 dmRzOjooX2hhbmRsZV90aW1lb3V0cykgVGltZW91dCBvbiBmaWxlbm8gMTcxLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5WTSBDaGFubmVscyBMaXN0ZW5lcjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6 MzQsMzg0Ojp2bWNoYW5uZWxzOjo5Njo6dmRzOjooX2hhbmRsZV90aW1lb3V0cykgVGltZW91dCBv biBmaWxlbm8gMTcyLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5WTSBDaGFubmVscyBMaXN0ZW5lcjo6 REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsMzg0Ojp2bWNoYW5uZWxzOjo5Njo6dmRzOjooX2hh bmRsZV90aW1lb3V0cykgVGltZW91dCBvbiBmaWxlbm8gMTU5LjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5WTSBDaGFubmVscyBMaXN0ZW5lcjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsMzg1Ojp2 bWNoYW5uZWxzOjo5Njo6dmRzOjooX2hhbmRsZV90aW1lb3V0cykgVGltZW91dCBvbiBmaWxlbm8g MTg5LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5WTSBDaGFubmVscyBMaXN0ZW5lcjo6REVCVUc6OjIw MTUtMTEtMDMgMDg6NDc6MzQsMzg1Ojp2bWNoYW5uZWxzOjo5Njo6dmRzOjooX2hhbmRsZV90aW1l b3V0cykgVGltZW91dCBvbiBmaWxlbm8gMTkwLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5WTSBDaGFu bmVscyBMaXN0ZW5lcjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsMzg1Ojp2bWNoYW5uZWxz Ojo5Njo6dmRzOjooX2hhbmRsZV90aW1lb3V0cykgVGltZW91dCBvbiBmaWxlbm8gMTk1LjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5WTSBDaGFubmVscyBMaXN0ZW5lcjo6REVCVUc6OjIwMTUtMTEtMDMg MDg6NDc6MzQsMzg1Ojp2bWNoYW5uZWxzOjo5Njo6dmRzOjooX2hhbmRsZV90aW1lb3V0cykgVGlt ZW91dCBvbiBmaWxlbm8gMTk3LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5WTSBDaGFubmVscyBMaXN0 ZW5lcjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsMzg1Ojp2bWNoYW5uZWxzOjo5Njo6dmRz OjooX2hhbmRsZV90aW1lb3V0cykgVGltZW91dCBvbiBmaWxlbm8gMTk4LjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5WTSBDaGFubmVscyBMaXN0ZW5lcjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQs Mzg1Ojp2bWNoYW5uZWxzOjo5Njo6dmRzOjooX2hhbmRsZV90aW1lb3V0cykgVGltZW91dCBvbiBm aWxlbm8gMjEzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5WTSBDaGFubmVscyBMaXN0ZW5lcjo6REVC VUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsMzg2Ojp2bWNoYW5uZWxzOjo5Njo6dmRzOjooX2hhbmRs ZV90aW1lb3V0cykgVGltZW91dCBvbiBmaWxlbm8gMjE1LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5W TSBDaGFubmVscyBMaXN0ZW5lcjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsMzg2Ojp2bWNo YW5uZWxzOjo5Njo6dmRzOjooX2hhbmRsZV90aW1lb3V0cykgVGltZW91dCBvbiBmaWxlbm8gOTgu PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlZNIENoYW5uZWxzIExpc3RlbmVyOjpERUJVRzo6MjAxNS0x MS0wMyAwODo0NzozNCwzODY6OnZtY2hhbm5lbHM6Ojk2Ojp2ZHM6OihfaGFuZGxlX3RpbWVvdXRz KSBUaW1lb3V0IG9uIGZpbGVubyAxMjUuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkpzb25ScGMgKFN0 b21wUmVhY3Rvcik6OkRFQlVHOjoyMDE1LTExLTAzIDA4OjQ3OjM0LDQxMjo6c3RvbXBSZWFjdG9y Ojo5ODo6QnJva2VyLlN0b21wQWRhcHRlcjo6KGhhbmRsZV9mcmFtZSkgSGFuZGxpbmcgbWVzc2Fn ZSAmbHQ7U3RvbXBGcmFtZSBjb21tYW5kPSdTRU5EJyZndDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ SnNvblJwY1NlcnZlcjo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsNDEzOjpfX2luaXRfXzo6 NTMwOjpqc29ucnBjLkpzb25ScGNTZXJ2ZXI6OihzZXJ2ZV9yZXF1ZXN0cykgV2FpdGluZyBmb3Ig cmVxdWVzdDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaHJlYWQtMTk0NzY0Mzo6REVCVUc6OjIwMTUt MTEtMDMgMDg6NDc6MzQsNDM3OjpzdG9tcFJlYWN0b3I6OjE2Mzo6eWFqc29ucnBjLlN0b21wU2Vy dmVyOjooc2VuZCkgU2VuZGluZyByZXNwb25zZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaHJlYWQt NzYxMzo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzQsNzEzOjpsaWJ2aXJ0Y29ubmVjdGlvbjo6 MTQzOjpyb290Ojood3JhcHBlcikgVW5rbm93biBsaWJ2aXJ0ZXJyb3I6IGVjb2RlOiA4MCBlZG9t OiAyMCBsZXZlbDogMiBtZXNzYWdlOiBtZXRhZGF0YSBub3QgZm91bmQ6IFJlcXVlc3RlZCBtZXRh ZGF0YSBlbGVtZW50IGlzIG5vdCBwcmVzZW50PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRocmVhZC02 MzkzOjpERUJVRzo6MjAxNS0xMS0wMyAwODo0NzozNCw3MTM6OmxpYnZpcnRjb25uZWN0aW9uOjox NDM6OnJvb3Q6Oih3cmFwcGVyKSBVbmtub3duIGxpYnZpcnRlcnJvcjogZWNvZGU6IDgwIGVkb206 IDIwIGxldmVsOiAyIG1lc3NhZ2U6IG1ldGFkYXRhIG5vdCBmb3VuZDogUmVxdWVzdGVkIG1ldGFk YXRhIGVsZW1lbnQgaXMgbm90IHByZXNlbnQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhyZWFkLTIy Njk0MTo6REVCVUc6OjIwMTUtMTEtMDMgMDg6NDc6MzUsNTExOjp0YXNrOjo1OTU6OlN0b3JhZ2Uu VGFza01hbmFnZXIuVGFzazo6KF91cGRhdGVTdGF0ZSkgVGFzaz1gYmRmMjY0MDEtMzI0Yy00MjIw LTkwMzQtMTljN2Q4MTZmNjQyYDo6bW92aW5nIGZyb20gc3RhdGUgaW5pdCAtJmd0OyBzdGF0ZSBw cmVwYXJpbmc8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhyZWFkLTQ3MDk6OkRFQlVHOjoyMDE1LTEx LTAzIDA4OjQ3OjM1LDUxMTo6dGFzazo6NTk1OjpTdG9yYWdlLlRhc2tNYW5hZ2VyLlRhc2s6Oihf dXBkYXRlU3RhdGUpIFRhc2s9YDBhYzJmODU0LTQxZTMtNDQyNy1hMGY0LTVlYWExODQyZTIxMmA6 Om1vdmluZyBmcm9tIHN0YXRlIGluaXQgLSZndDsgc3RhdGUgcHJlcGFyaW5nPC9kaXY+DQo8ZGl2 IGFwcGxlLWNvbnRlbnQtZWRpdGVkPSJ0cnVlIiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImxldHRl ci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsg LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPHAgc3R5 bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMHB0OyBsaW5l LWhlaWdodDogMTZweDsiIGNsYXNzPSIiPg0KPGZvbnQgY29sb3I9IiMzZDNiM2IiIGNsYXNzPSIi PjxiIGNsYXNzPSIiPi0tPC9iPjwvZm9udD48L3A+DQo8ZGl2IGNsYXNzPSIiPkNocmlzdG9waGU8 L2Rpdj4NCiZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiIHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_ABC69195C9484895AAFF1900F54BBE43unilu_--

7 11

Greetings and observations from an oVirt noob
by Kenneth Marsh 06 Dec '15

06 Dec '15

Hello all, I do development operations for a part of a software division of a large multinational. I'm an experienced user of VMWare and Amazon AWS, soon to be pushed onto Azure, and I've found a common thread among all solutions - they are all expensive enough that my budget will certainly not be approved with them. I'm deferred to the IT part of the organisation, which operates too slowly and inefficiently (in terms of both cost and time) for my requirements. This is what led me to RHEV, and ultimately to oVirt. This is a feasibility study for what may ultimately be a RHEV-based data center in a new office, and if I succeed we will be doing more on a fixed budget by using more RHEV and less Azure. I spent the weekend working with oVirt and I'm very impressed. I had no idea such a comprehensive enterprise-class solution was even available. Being a complete newcomer, I started without a clue and after a weekend had set up a nearly-working data centre including an oVirt hypervisor node, all on old Dell notebooks loaned to me temporarily by our IT group. I started with RHEV but decided to use oVirt for two reasons - one being to see what's possible with the latest and greatest, the other because RHEV required some licensing I've not yet purchased. Long term it'll have to be RHEV for enterprise support reasons I'm sure many are familiar with. There are a few things I found, from a newcomer's perspective, very unclear. - What is oVirt, vs oVirt engine, vs oVirt node, vs oVirt host. Try to find documentation on any of these and get spammed with references to the others. I think I've worked out that these are the collective suite of products, the management centre, the bare-metal hypervisor, and participating member servers, respectively. - Which versions of CentOS/Fedora/oVirt Node are compatible at which oVirt compatibility level? This would normally be addressed in the release notes. It was also confusing to discover oVirt node 3.2.1 is compatible at the 3.5 level. The answer to this remains unclear but I'm trying to use Fedora 22 across the board now with oVirt node 3.2.1 and this seems to be working, although I haven't gotten a server node into a cluster yet, only oVirt nodes. - Storage domains - much doco about them being needed and how to configure them but nothing about what they are or why they are needed. I would have expected an oVirt node to be capable of both data and ISO storage but apparently there needs to be an NFS or iSCSI filesystem there first? And there's local storage vs shared, another concept much talked about how to prepare and add it but not explained why one would want to do that or what it means. I think with further internet combing and by trial-and-error I'm very likely to figure it all out. I hope all goes well and implement this stuff in our new data centre and then I'd be keen to contribute some of my own tech writing. Meanwhile, I hope to be active on this mailing list and I thank everyone in advance for sharing their oVirt experience. For any who are looking at the doco thanks much for the plethora of stuff out there already and I hope the above bullet points help you understand where doco most needs more attention. At least from the perspective of one who has just come across oVirt. Kind Regards, Ken Marsh Brisbane, Australia

3 3

Engine upgrade error
by Frank Rothenstein 04 Dec '15

04 Dec '15

Hello, I tried several times to upgrade my ovirt-engine 3.5.5 to 3.6. Every time the setup stops at updating the DB-schema. The log revealed when this happpens: The setup ist complaining about a duplicated key - here is the part of the log. Of course there is only one network in the interface. Can anybody help me getting a solution? Thnaks, Frank Running upgrade sql script '/usr/share/ovirt- engine/dbscripts/upgrade/03_06_1670_unique_vds_id_network_name_vds_inte rface.sql'... 2542964- 2542965-2015-11-30 08:15:26 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.execute:941 execute-output: ['/usr/share/ovirt- engine/dbscripts/schema.sh', '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l', '/var/log/ovirt-engine/setup/ovirt- engine-setup-20151130073216-erdh9f.log', '-c', 'apply'] stderr: 2543300-psql:/usr/share/ovirt- engine/dbscripts/upgrade/03_06_1670_unique_vds_id_network_name_vds_inte rface.sql:1: ERROR: could not create unique index "vds_interface_vds_id_network_name_unique" 2543487:DETAIL: Key (vds_id, network_name)=(ba954f0f-6ecb-4ec8-b169- 7e0a1147b4cd, KHnetz) is duplicated. 2543585-CONTEXT: SQL statement "ALTER TABLE vds_interface ADD CONSTRAINT vds_interface_vds_id_network_name_unique unique (vds_id, network_name)" 2543723-PL/pgSQL function fn_db_create_constraint(character varying,character varying,text) line 4 at EXECUTE statement 2543835-FATAL: Cannot execute sql command: --file=/usr/share/ovirt- engine/dbscripts/upgrade/03_06_1670_unique_vds_id_network_name_vds_inte rface.sql 2543975- 2543976-2015-11-30 08:15:26 DEBUG otopi.context context._executeMethod:156 method exception 2544060-Traceback (most recent call last): 2544095- File "/usr/lib/python2.7/site-packages/otopi/context.py", line 146, in _executeMethod 2544183- method['method']() 2544206- File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt- engine-setup/ovirt-engine/db/schema.py", line 291, in _misc 2544325- oenginecons.EngineDBEnv.PGPASS_FILE 2544365- File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line 946, in execute 2544445- command=args[0], 2544466-RuntimeError: Command '/usr/share/ovirt- engine/dbscripts/schema.sh' failed to execute 2544552-2015-11-30 08:15:26 ERROR otopi.context context._executeMethod:165 Failed to execute stage 'Misc configuration': Command '/usr/share/ovirt-engine/dbscripts/schema.sh' failed to execute 2544737-2015-11-30 08:15:26 DEBUG otopi.transaction transaction.abort:134 aborting 'Yum Transaction' 2544830-2015-11-30 08:15:26 INFO otopi.plugins.otopi.packagers.yumpackager yumpackager.info:95 Yum Performing yum transaction rollback ______________________________________________________________________________ BODDEN-KLINIKEN Ribnitz-Damgarten GmbH Sandhufe 2 18311 Ribnitz-Damgarten Telefon: 03821-700-0 Fax: 03821-700-240 E-Mail: info(a)bodden-kliniken.de Internet: http://www.bodden-kliniken.de Sitz: Ribnitz-Damgarten, Amtsgericht: Stralsund, HRB 2919, Steuer-Nr.: 079/133/40188 Aufsichtsratsvorsitzende: Carmen Schröter, Geschäftsführer: Dr. Falko Milski Der Inhalt dieser E-Mail ist ausschließlich für den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorge- sehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, beachten Sie bitte, dass jede Form der Veröf- fentlichung, Vervielfältigung oder Weitergabe des Inhalts dieser E-Mail unzulässig ist. Wir bitten Sie, sofort den Absender zu informieren und die E-Mail zu löschen. Bodden-Kliniken Ribnitz-Damgarten GmbH 2015 *** Virenfrei durch Kerio Mail Server und Sophos Antivirus ***

5 11

Updated Invitation: [Deep dive] Host Network QoS - oVirt 3.6 @ Thu Nov 26, 2015 5pm - 6pm (ibarkan@redhat.com)
by ibarkan＠redhat.com 01 Dec '15

01 Dec '15

This event has been changed. Title: [Deep dive] Host Network QoS - oVirt 3.6 Hangouts on air: https://plus.google.com/events/c3la9vdse911atq991qflogtq0g you tube link: https://plus.google.com/events/c3la9vdse911atq991qflogtq0g When: Thu Nov 26, 2015 5pm - 6pm Jerusalem (changed) Calendar: ibarkan(a)redhat.com Who: * ibarkan(a)redhat.com - organizer * users(a)ovirt.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=NGZxZXU0dDRka2ZrMmd1c… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account users(a)ovirt.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding

3 2

hosted engine vm.conf missing
by Thomas Scofield 01 Dec '15

01 Dec '15

I have recently setup a ovirt hosted engine on iscsi storage and after a reboot of the system I am unable to start the hosted engine. The agent.log gives errors indicating there is a missing value in the vm.conf file, but the vm.conf file does not appear in the location indicated. There is no error indicated when the agent attempts to reload the vm.conf. Any ideas on how to get the hosted engine up and running? MainThread::INFO::2015-11-26 21:31:13,071::hosted_engine::699::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_sanlock) Ensuring lease for lockspace hosted-engine, host id 1 is acquired (file: /var/run/vdsm/storage/ddf4a26b-61ff-49a4-81db-9f82da35e44b/6ed6d868-aaf3-4b3f-bdf0-a4ad262709ae/1fe5b7fc-eae7-4f07-a2fe-5a082e14c876) MainThread::INFO::2015-11-26 21:31:13,072::upgrade::836::ovirt_hosted_engine_ha.lib.upgrade.StorageServer::(upgrade) Host configuration is already up-to-date MainThread::INFO::2015-11-26 21:31:13,072::hosted_engine::422::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring) Reloading vm.conf from the shared storage domain MainThread::ERROR::2015-11-26 21:31:13,100::agent::205::ovirt_hosted_engine_ha.agent.agent.Agent::(_run_agent) Error: ''Configuration value not found: file=/var/run/ovirt-hosted-engine-ha/vm.conf, key=memSize'' - trying to restart agent MainThread::WARNING::2015-11-26 21:31:18,105::agent::208::ovirt_hosted_engine_ha.agent.agent.Agent::(_run_agent) Restarting agent, attempt '9' MainThread::ERROR::2015-11-26 21:31:18,106::agent::210::ovirt_hosted_engine_ha.agent.agent.Agent::(_run_agent) Too many errors occurred, giving up. Please review the log and consider filing a bug. MainThread::INFO::2015-11-26 21:31:18,106::agent::143::ovirt_hosted_engine_ha.agent.agent.Agent::(run) Agent shutting down

4 11

Windows Networking Issues -
by Matt Wells 01 Dec '15

01 Dec '15

Hi all, I have a question about Windows VMs and a networking issue I'm having. Here's the setup - * oVirt - 3.5.1.1-1 * Hypervisors are CentOS 6.7 box with 2 NICs in bond0 'mode=4 miimon=100 lacp_rate=1' * On bond0 I have a few networks using vlan tagging. * Networks are 5,10,15,20 - All on an external switch Network 15 has a Windows 2012 R2 server and a CentOS 6.7 server on it. The rest of the networks have a few linux. Every linux box on every network is happy. However any and all Windows boxes I bring online are incapable of patching or hitting the web. I pointed the Windows box to the linux box next to it as a proxy (after installing squid on it) When I do that the Windows box has no issues at all; it's only when he's attempting to leave on his own. On my firewall I put in a 'permit any any' on the M$ box IP however all I see is tcp resets in PCAPs, I've been playing with for some time but can't seem to find the issue. It would be one thing if everything on the 15 was bad but the linux box on the network is fine. Here's the rub, I'm 99.999% sure this used to work. gggrrr... Any assistance anyone can offer would be amazingly appreciated. Thank you for taking the time to read this.

2 3

Re: [ovirt-users] [ANN] oVirt 3.6.1 First Release Candidate is now available for testing
by jvdwege 01 Dec '15

01 Dec '15

Sandro Bonazzola schreef op 2015-11-30 15:10: > On Mon, Nov 30, 2015 at 1:56 PM, Joop <jvdwege(a)xs4all.nl> wrote: > >> On 30-11-2015 13:06, Sandro Bonazzola wrote: >> >> On Sat, Nov 28, 2015 at 1:34 PM, Joop <jvdwege(a)xs4all.nl> wrote: >> On 25-11-2015 15:28, Sandro Bonazzola wrote: >>> The oVirt Project is pleased to announce the availability >>> of the First Release Candidate of oVirt 3.6.1 for testing, as of >>> November 25th, 2015. >>> >>> This release is available now for Fedora 22, >>> Red Hat Enterprise Linux 6.7, CentOS Linux 6.7 (or similar) and >>> Red Hat Enterprise Linux >= 7.1, CentOS Linux >= 7.1 (or similar). >>> >>> This release supports Hypervisor Hosts running >>> Red Hat Enterprise Linux >= 7.1, CentOS Linux >= 7.1 (or similar) >> and >>> Fedora 22. >>> Highly experimental support for Debian 8.1 Jessie has been added >> too. >>> >>> This release of oVirt 3.6.1 includes numerous bug fixes. >>> See the release notes [1] for an initial list of the new features >> and bugs >>> fixed. >>> >> Tried the 3.6.1 prerelease but the sanlock error 22 is still there >> and >> its not possible to activate the imported hosted-engine storage >> domain. >> Host F22, hosted-engine CentOS7.1, storage domain(s) NFS. >> >> Sanlock error 22 shows up because BZ 1269768 hasn't been fixed yet. >> >> But if you don't import the hosted engine storage everything else >> should still work fine. > Ah, but that won't work for my use case since I need to import an > existing data domain and that won't work without a working data > domain. > Will see if creating a dummy small data domain will let me import the > real one. > > it should, let me know if it didn't work. Thanks that worked :-) > Adding Simone and Roy so they have a better sight on why people are > keep trying to import the hosted engine domain despite it's not fixed > yet :-) Sorry being pushy just wanted to get on with my ovirt stuff and felt a little frustrated that such a basic feature didn't work (IMHO). Again apologies, you're all working hard to get things fixed and I shouldn't complain. Regards, Joop

6 6

Windows 10
by Koen Vanoppen 01 Dec '15

01 Dec '15

Dear all, Yes, onther question :-). This time it's about windows 10. I'm running ovirt 3.5.4 and I don't manage to install windows 10 on it. Keeps giving me a blue screen (yes, I know, it's still a windows... ;-) ) on reboot. Are there any special settings you need to enable when creating the vm? Which OS do I need to select? Or shall I just wait untile the relase of ovirt 3.6 :-) ? Kind regards, Koen

4 5

Corruped disks
by Koen Vanoppen 30 Nov '15

30 Nov '15

Dear all, lately we are experience some strange behaviour on our vms... Every now and then we have disks that went corrupt. Is there a chance that ovirt is the issue here or...? It happens (luckily) on our DEV/UAT cluster. Since the last 4 weeks, we already had 6 vm's that went totaly corrupt... Kind regards, Koen

3 3

Re: [ovirt-users] Engine upgrade error - 03_06_1670_unique_vds_id_network_name_vds_interface.sql
by Yedidyah Bar David 30 Nov '15

30 Nov '15

On Mon, Nov 30, 2015 at 3:34 PM, Frank Rothenstein <f.rothenstein(a)bodden-kliniken.de> wrote: > Hello, > > I tried several times to upgrade my ovirt-engine 3.5.5 to 3.6. Every > time the setup stops at updating the DB-schema. The log revealed when > this happpens: The setup ist complaining about a duplicated key - here > is the part of the log. Of course there is only one network in the > interface. > > Can anybody help me getting a solution? > > Thnaks, Frank > > Running upgrade sql script '/usr/share/ovirt- > engine/dbscripts/upgrade/03_06_1670_unique_vds_id_network_name_vds_inte > rface.sql'... > 2542964- > 2542965-2015-11-30 08:15:26 DEBUG > otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema > plugin.execute:941 execute-output: ['/usr/share/ovirt- > engine/dbscripts/schema.sh', '-s', 'localhost', '-p', '5432', '-u', > 'engine', '-d', 'engine', '-l', '/var/log/ovirt-engine/setup/ovirt- > engine-setup-20151130073216-erdh9f.log', '-c', 'apply'] stderr: > 2543300-psql:/usr/share/ovirt- > engine/dbscripts/upgrade/03_06_1670_unique_vds_id_network_name_vds_inte > rface.sql:1: ERROR: could not create unique index > "vds_interface_vds_id_network_name_unique" > 2543487:DETAIL: Key (vds_id, network_name)=(ba954f0f-6ecb-4ec8-b169- > 7e0a1147b4cd, KHnetz) is duplicated. > 2543585-CONTEXT: SQL statement "ALTER TABLE vds_interface ADD > CONSTRAINT vds_interface_vds_id_network_name_unique unique (vds_id, > network_name)" > 2543723-PL/pgSQL function fn_db_create_constraint(character > varying,character varying,text) line 4 at EXECUTE statement > 2543835-FATAL: Cannot execute sql command: --file=/usr/share/ovirt- > engine/dbscripts/upgrade/03_06_1670_unique_vds_id_network_name_vds_inte > rface.sql Can you post output of 'select * from vds_interface' from engine database? Adding Eli and changing subject. > 2543975- > 2543976-2015-11-30 08:15:26 DEBUG otopi.context > context._executeMethod:156 method exception > 2544060-Traceback (most recent call last): > 2544095- File "/usr/lib/python2.7/site-packages/otopi/context.py", > line 146, in _executeMethod > 2544183- method['method']() > 2544206- File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt- > engine-setup/ovirt-engine/db/schema.py", line 291, in _misc > 2544325- oenginecons.EngineDBEnv.PGPASS_FILE > 2544365- File "/usr/lib/python2.7/site-packages/otopi/plugin.py", line > 946, in execute > 2544445- command=args[0], > 2544466-RuntimeError: Command '/usr/share/ovirt- > engine/dbscripts/schema.sh' failed to execute > 2544552-2015-11-30 08:15:26 ERROR otopi.context > context._executeMethod:165 Failed to execute stage 'Misc > configuration': Command '/usr/share/ovirt-engine/dbscripts/schema.sh' > failed to execute > 2544737-2015-11-30 08:15:26 DEBUG otopi.transaction > transaction.abort:134 aborting 'Yum Transaction' > 2544830-2015-11-30 08:15:26 INFO > otopi.plugins.otopi.packagers.yumpackager yumpackager.info:95 Yum > Performing yum transaction rollback > > > > > > ______________________________________________________________________________ > BODDEN-KLINIKEN Ribnitz-Damgarten GmbH > Sandhufe 2 > 18311 Ribnitz-Damgarten > > Telefon: 03821-700-0 > Fax: 03821-700-240 > > E-Mail: info(a)bodden-kliniken.de Internet: http://www.bodden-kliniken.de > > Sitz: Ribnitz-Damgarten, Amtsgericht: Stralsund, HRB 2919, Steuer-Nr.: 079/133/40188 > Aufsichtsratsvorsitzende: Carmen Schröter, Geschäftsführer: Dr. Falko Milski > > Der Inhalt dieser E-Mail ist ausschließlich für den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorge- > sehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, beachten Sie bitte, dass jede Form der Veröf- > fentlichung, Vervielfältigung oder Weitergabe des Inhalts dieser E-Mail unzulässig ist. Wir bitten Sie, sofort den > Absender zu informieren und die E-Mail zu löschen. > > > Bodden-Kliniken Ribnitz-Damgarten GmbH 2015 > *** Virenfrei durch Kerio Mail Server und Sophos Antivirus *** > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users -- Didi

1 0

Re: [ovirt-users] [SOLVED] Re: Trying to make ovirt-hosted-engine-setup create a customized Engine-vm on 3.6 HC HE
by Giuseppe Ragusa 30 Nov '15

30 Nov '15

On Wed, Nov 25, 2015, at 12:10, Simone Tiraboschi wrote: > > > On Mon, Nov 23, 2015 at 10:17 PM, Giuseppe Ragusa > <giuseppe.ragusa(a)hotmail.com> wrote: >> On Tue, Oct 27, 2015, at 00:10, Giuseppe Ragusa wrote: >> > On Mon, Oct 26, 2015, at 09:48, Simone Tiraboschi wrote: >> > > >> > > >> > > On Mon, Oct 26, 2015 at 12:14 AM, Giuseppe Ragusa > > <giuseppe.ragusa(a)hotmail.com> wrote: >> > >> Hi all, >> > >> I'm experiencing some difficulties using oVirt 3.6 latest snapshot. >> > >> >> > >> I'm trying to trick the self-hosted-engine setup to create a custom > >> engine vm with 3 nics (with fixed MACs/UUIDs). >> > >> >> > >> The GlusterFS volume (3.7.5 hyperconverged, replica 3, for the > >> engine vm) and the network bridges (ovirtmgmt and other two > >> bridges, called nfs and lan, for the engine vm) have been > >> preconfigured on the initial fully-patched CentOS 7.1 host (plus > >> other two identical hosts which are awaiting to be added). >> > >> >> > >> I'm stuck at a point with the engine vm successfully starting but > >> with only one nic present (connected to the ovirtmgmt bridge). >> > >> >> > >> I'm trying to obtain the modified engine vm by means of a trick > >> which used to work in a previous (aborted because of lacking GlusterFS-by- > >> libgfapi support) oVirt 3.5 test setup (about a year ago, maybe > >> more): I'm substituting the standard /usr/share/ovirt-hosted-engine- > >> setup/templates/vm.conf.in with the following: >> > >> >> > >> vmId=@VM_UUID@ >> > >> memSize=@MEM_SIZE@ >> > >> display=@CONSOLE_TYPE@ >> > >> devices={index:2,iface:ide,address:{ controller:0, target:0,unit:0, > >> bus:1, type:drive},specParams:{},readonly:true,deviceId:@CDROM_UUI- > >> D@,path:@CDROM@,device:cdrom,shared:false,type:disk@BOOT_CDROM@} >> > >> devices={index:0,iface:virtio,format:raw,poolID:@SP_UUID@,volumeID- > >> :@VOL_UUID@,imageID:@IMG_UUID@,specParams:{},readonly:false,domain- > >> ID:@SD_UUID@,optional:false,deviceId:@IMG_UUID@,address:{bus:0x00, > >> slot:0x06, domain:0x0000, type:pci, function:0x0},device:disk,shar- > >> ed:exclusive,propagateErrors:off,type:disk@BOOT_DISK@} >> > >> devices={device:scsi,model:virtio-scsi,type:controller} >> > >> devices={index:4,nicModel:pv,macAddr:02:50:56:3f:c4:b0,linkActive:- > >> true,network:@BRIDGE@,filter:vdsm-no-mac- > >> spoofing,specParams:{},deviceId:@NIC_UUID@,address:{bus:0x00, > >> slot:0x03, domain:0x0000, type:pci, > >> function:0x0},device:bridge,type:interface@BOOT_PXE@} >> > >> devices={index:8,nicModel:pv,macAddr:02:50:56:3f:c4:a0,linkActive:- > >> true,network:lan,filter:vdsm-no-mac- > >> spoofing,specParams:{},deviceId:6c467650-1837-47ea-89bc- > >> 1113f4bfefee,address:{bus:0x00, slot:0x09, domain:0x0000, type:pci, > >> function:0x0},device:bridge,type:interface@BOOT_PXE@} >> > >> devices={index:16,nicModel:pv,macAddr:02:50:56:3f:c4:c0,linkActive- > >> :true,network:nfs,filter:vdsm-no-mac- > >> spoofing,specParams:{},deviceId:4d8e0705-8cb4-45b7-b960- > >> 7f98bb59858d,address:{bus:0x00, slot:0x0c, domain:0x0000, type:pci, > >> function:0x0},device:bridge,type:interface@BOOT_PXE@} >> > >> devices={device:console,specParams:{},type:console,deviceId:@CONSO- > >> LE_UUID@,alias:console0} >> > >> vmName=@NAME@ >> > >> spiceSecureChannels=smain,sdisplay,sinputs,scursor,splayback,sreco- > >> rd,ssmartcard,susbredir >> > >> smp=@VCPUS@ >> > >> cpuType=@CPU_TYPE@ >> > >> emulatedMachine=@EMULATED_MACHINE@ >> > >> >> > >> but unfortunately the vm gets created like this (output from "ps"; > >> note that I'm attaching a CentOS7.1 Netinstall ISO with an embedded > >> kickstart: the installation should proceed by HTTP on the lan > >> network but obviously fails): >> > >> >> > >> /usr/libexec/qemu-kvm -name HostedEngine -S -machine >> > >> pc-i440fx-rhel7.1.0,accel=kvm,usb=off -cpu Westmere -m 4096 - > >> realtime mlock=off >> > >> -smp 2,sockets=2,cores=1,threads=1 -uuid f49da721-8aa6-4422-8b91- > >> e91a0e38aa4a -s >> > >> mbios type=1,manufacturer=oVirt,product=oVirt Node,version=7- > >> 1.1503.el7.centos.2 >> > >> .8,serial=2a1855a9-18fb-4d7a-b8b8-6fc898a8e827,uuid=f49da721-8aa6- > >> 4422-8b91-e91a >> > >> 0e38aa4a -no-user-config -nodefaults -chardev > >> socket,id=charmonitor,path=/var/li >> > >> b/libvirt/qemu/HostedEngine.monitor,server,nowait -mon > >> chardev=charmonitor,id=mo >> > >> nitor,mode=control -rtc base=2015-10-25T11:22:22,driftfix=slew - > >> global kvm-pit.l >> > >> ost_tick_policy=discard -no-hpet -no-reboot -boot strict=on -device > >> piix3-usb-uh >> > >> ci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi- > >> pci,id=scsi0,bus=pci.0,addr >> > >> =0x4 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 > >> =-drive file= >> > >> /var/tmp/engine.iso,if=none,id=drive-ide0-1- > >> 0,readonly=on,format=raw,serial= -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1- > >> 0,bootindex=1 -drive file=/var/run/vdsm/storage/be4434bf-a5fd-44d7-8011- > >> d5e4ac9cf523/b3abc1cb-8a78-4b56-a9b0-e5f41fea0fdc/8d075a8d-730a- > >> 4925-8779-e0ca2b3dbcf4,if=none,id=drive-virtio- > >> disk0,format=raw,serial=b3abc1cb-8a78-4b56-a9b0- > >> e5f41fea0fdc,cache=none,werror=stop,rerror=stop,aio=threads -device > >> virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio- > >> disk0,id=virtio-disk0 -netdev > >> tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net- > >> pci,netdev=hostnet0,id=net0,mac=02:50:56:3f:c4:b0,bus=pci.0,addr=0- > >> x3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/chan- > >> nels/f49da721-8aa6-4422-8b91- > >> e91a0e38aa4a.com.redhat.rhevm.vdsm,server,nowait -device virtserialport,bus=virtio- > >> serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rh- > >> evm.vdsm -chardev socket,id=charchannel1,path=/var/lib/libvirt/qem- > >> u/channels/f49da721-8aa6-4422-8b91- > >> e91a0e38aa4a.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio- > >> serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.gues- > >> t_agent.0 -chardev socket,id=charchannel2,path=/var/lib/libvirt/qe- > >> mu/channels/f49da721-8aa6-4422-8b91-e91a0e38aa4a.org.ovirt.hosted- > >> engine-setup.0,server,nowait -device virtserialport,bus=virtio- > >> serial0.0,nr=3,chardev=charchannel2,id=channel2,name=org.ovirt.hos- > >> ted-engine-setup.0 -chardev socket,id=charconsole0,path=/var/run/ovirt-vmconsole- > >> console/f49da721-8aa6-4422-8b91-e91a0e38aa4a.sock,server,nowait - > >> device virtconsole,chardev=charconsole0,id=console0 -vnc > >> 0:0,password -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -msg > >> timestamp=on >> > >> >> > >> There seem to be no errors in the logs. >> > >> >> > >> I've tried reading some (limited) Python setup code but I've not > >> found any obvious reason why the trick should not work anymore. >> > >> >> > >> I know that 3.6 has different network configuration/management and > >> this could be the hot point. >> > >> >> > >> Does anyone have any further suggestion or clue (code/logs to > >> read)? >> > > >> > > The VM creation path is now a bit different cause we use just vdscli > > library instead of vdsClient. >> > > Please take a a look at mixins.py >> > >> > Many thanks for your very valuable hint: >> > >> > I've restored the original /usr/share/ovirt-hosted-engine- > setup/templates/vm.conf.in and I've managed to obtain the 3-nics- > customized vm by modifying /usr/lib/python2.7/site- > packages/ovirt_hosted_engine_setup/mixins.py like this ("diff -Naur" > output): >> >> Hi Simone, >> it seems that I spoke too soon :( >> >> A separate network issue (already reported to the list) prevented me from successfully closing up the setup in its final phase (registering the host inside the Engine), so all seemed well while being stuck there :) >> >> Now that I've solved that (for which I'm informing the list asap in a separate message) and the setup ended successfully, it seems that the last step of the HE setup (shutdown the Engine vm to place it under HA agent control) starts/creates a "different vm" and my virtual hardware customizations seem to be gone (only one NIC present, connected to ovirtmgmt). >> >> My wild guess: maybe I need BOTH the mixins.py AND the vm.conf.in customizations? ;) > > Yes, you are right: the final configuration is still generated from > the template so you need to fix both. > >> >> It seems (from /etc/ovirt-hosted-engine/hosted-engine.conf) that the Engine vm definition is now in /var/run/ovirt-hosted-engine-ha/vm.conf >> > > > the vm configuration is now read from the shared domain converting > back from the OVF_STORE, the idea is to let you edit it from the > engine without the need to write it on each host. /var/run/ovirt-hosted-engine- > ha/vm.conf is just a temporary copy. > > As you are probably still not able to import the hosted-engine storage > domain in the engine due to a well know bug, your system will fallback > to the initial vm.conf configuration still on the shared storage and > you can manually fix it: Please follow this procedure substituting > '192.168.1.115:_Virtual_ext35u36' with the mount point of hosted- > engine storage domain on your system: > > mntpoint=/rhev/data-center/mnt/192.168.1.115:_Virtual_ext35u36 > dir=`mktemp -d` && cd $dir sdUUID_line=$(grep sdUUID /etc/ovirt-hosted-engine/hosted- > engine.conf) sdUUID=${sdUUID_line:7:36} conf_volume_UUID_line=$(grep > conf_volume_UUID /etc/ovirt-hosted-engine/hosted-engine.conf) > conf_volume_UUID=${conf_volume_UUID_line:17:36} > conf_image_UUID_line=$(grep conf_image_UUID /etc/ovirt-hosted-engine/hosted- > engine.conf) conf_image_UUID=${conf_image_UUID_line:16:36} dd > if=$mntpoint/$sdUUID/images/$conf_image_UUID/$conf_volume_UUID > 2>/dev/null| tar -xvf - > # directly edit vm.conf as you need > tar -cO * | dd > of=$mntpoint/$sdUUID/images/$conf_image_UUID/$conf_volume_UUID > > When your engine will import the hosted-engine storage domain it will > generate an OVF_STORE with the configuration of the engine VM, you > will be able to edit some parameters from the engine and the agent > will read the VM configuration from there. Hi Simone, I followed your advice and modified the vm.conf inside the conf_volume tar archive. Then I put the system (still with only one physical host) in global maintenance from the host: hosted-engine --set-maintenance --mode=global Then i regularly powered off the Engine vm and confirmed it from the host: hosted-engine --vm-status Then restarted it from the host: hosted-engine --vm-start Finally, I exited maintenance from the host: hosted-engine --set-maintenance --mode=none Waited a bit and verified it: hosted-engine --vm-status It all worked as expected! Many thanks again. Regards, Giuseppe > >> >> Many thanks for your assistance (and obviously I just sent a related wishlist item on the HE setup ;) >> >> Regards, >> Giuseppe >> >> >> > *********************************************************************- > *************** >> > >> > --- mixins.py.orig 2015-10-20 16:57:40.000000000 +0200 >> > +++ mixins.py 2015-10-26 22:22:58.351223922 +0100 >> > @@ -25,6 +25,7 @@ >> >import random >> >import string >> >import time >> > +import uuid >> > >> > >> >from ovirt_hosted_engine_setup import constants as ohostedcons >> > @@ -247,6 +248,44 @@ >> >]['@BOOT_PXE@'] == ',bootOrder:1': >> >nic['bootOrder'] = '1' >> >conf['devices'].append(nic) >> > + nic2 = { >> > + 'nicModel': 'pv', >> > + 'macAddr': '02:50:56:3f:c4:a0', >> > + 'linkActive': 'true', >> > + 'network': 'lan', >> > + 'filter': 'vdsm-no-mac-spoofing', >> > + 'specParams': {}, >> > + 'deviceId': str(uuid.uuid4()), >> > + 'address': { >> > + 'bus': '0x00', >> > + 'slot': '0x09', >> > + 'domain': '0x0000', >> > + 'type': 'pci', >> > + 'function': '0x0' >> > + }, >> > + 'device': 'bridge', >> > + 'type': 'interface', >> > + } >> > + conf['devices'].append(nic2) >> > + nic3 = { >> > + 'nicModel': 'pv', >> > + 'macAddr': '02:50:56:3f:c4:c0', >> > + 'linkActive': 'true', >> > + 'network': 'nfs', >> > + 'filter': 'vdsm-no-mac-spoofing', >> > + 'specParams': {}, >> > + 'deviceId': str(uuid.uuid4()), >> > + 'address': { >> > + 'bus': '0x00', >> > + 'slot': '0x0c', >> > + 'domain': '0x0000', >> > + 'type': 'pci', >> > + 'function': '0x0' >> > + }, >> > + 'device': 'bridge', >> > + 'type': 'interface', >> > + } >> > + conf['devices'].append(nic3) >> > >> >cli = self.environment[ohostedcons.VDSMEnv.VDS_CLI] >> >status = cli.create(conf) >> > >> > *********************************************************************- > *************** >> > >> > Obviously this is a horrible ad-hoc hack that I'm not able to generalize/clean- > up now: doing so would involve (apart from a deeper understanding of > the whole setup code/workflow) some well-thought-out design decisions > and, given the effective deprecation of the aforementioned easy-to- > modify vm.conf.in template substituted by hardwired Python program > logic, it seems that such a functionality is not very high on the > development priority list atm ;) >> > >> > Many thanks again! >> > >> > Kind regards, >> > Giuseppe >> > >> > >> Many thanks in advance. >> > >> >> > >> Kind regards, >> > >> Giuseppe >> > >> >> > >> PS: please keep also my address in replying because I'm > >> experiencing some problems between Hotmail and oVirt-mailing- > >> list >> > >> >> > >> _______________________________________________ >> > >> >> > Users mailing list >> > >>Users(a)ovirt.org >> > >>http://lists.ovirt.org/mailman/listinfo/users >> > >>

1 0