- Users - oVirt List Archives

[Users] Source code unerstanding
by aditya mamidwar 16 Mar '14

16 Mar '14

Hey, is there a simpler way to know which code is responsible for which module of the engine. is there a documentation maintained. or how can identify the files which are important for me. -- -Aditya Mamidwar

4 3

[Users] otopi.conf
by jacek burghardt 15 Mar '14

15 Mar '14

Is there example on how to create otopi.conf file * see option *OTOPI_PYTHON [/usr/bin/python] i guess I could point it to python2 I hope I can get disable the attempt at installing rpm packages by yum. I dont believe Gentoo had patched otopi to install its packages. ts between attempted installs of ncurses-base-5.7-3.20090208.el6.x86_64 and ncurses-base-5.7-3.20090208.el6.x86_64 file /usr/share/terminfo/d/dumb conflicts between attempted installs of ncurses-base-5.7-3.20090208.el6.x86_64 and ncurses-base-5.7-3.20090208.el6.x86_64 file /usr/share/terminfo/l/linux conflicts between attempted installs of ncurses-base-5.7-3.20090208.el6.x86_64 and ncurses-base-5.7-3.20090208.el6.x86_64 file /usr/share/terminfo/v/vt100 conflicts between attempted installs of ncurses-base-5.7-3.20090208.el6.x86_64 and ncurses-base-5

2 3

[Users] oVirt/RHEV Android client (Opaque) available for beta testing
by i iordanov 15 Mar '14

15 Mar '14

Hello, We invite any interested oVirt/RHEV developers and administrators to beta-test Opaque, a new Android oVirt/RHEV client application. To opt in, please reply to this message with an email address associated with a Google Account, because joining the beta-test group is based on membership to a Google Plus community. If you don't want that email address posted to the mailing list, don't include it in your reply! Itamar or I will add you to the community and let you know that you can proceed to the following two steps: 1) Please visit this page here to accept the invitation: https://plus.google.com/communities/116099119712127782216 2) Once you've become a member of the Google+ group, to opt-in, visit: https://play.google.com/apps/testing/com.undatech.opaquebeta You will be able to download Opaque from Google Play by following the link at the bottom of the opt-in page. Please share your experiences with Opaque to the mailing list! Cheers, iordan -- The conscious mind has only one thread of execution.

8 21

[Users] New Ovirt 3.3.4.1 install, initial SD cannot be used for gluster
by Steve Dainard 14 Mar '14

14 Mar '14

I just went through a full re-install and could not get the first DC to bring up a gluster SD. 'could not acquire hostid' was the error reported. I believe the default settings in engine-setup was DC type NFS. After a day of cursing I created a new DC, moved the hosts over, and was able to bring up a gluster storage domain without issue. I'm attaching the logs for today, if someone can review and let me know what was going wrong, I'd like to open a BZ. I was actually bit by this issue a month ago but didn't realize what had changed while I was testing different configurations and was able to get a gluster storage SD working in a different DC. My setup is as such, hosts: ovirt001 <-- ovirt host, gluster host, ovirt-engine ovirt002 <-- ovirt host, gluster host On another note, I noticed with the package vdsm-hook-nestedvt my hosts were listed as non-operational, and that they did not support virtualization. Removing the packages solved the issue after a reboot. Thanks, *Steve Dainard * IT Infrastructure Manager Miovision <http://miovision.com/> | *Rethink Traffic* *Blog <http://miovision.com/blog> | **LinkedIn <https://www.linkedin.com/company/miovision-technologies> | Twitter <https://twitter.com/miovision> | Facebook <https://www.facebook.com/miovision>* ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately.

1 0

[Users] adding scripts
by aditya mamidwar 14 Mar '14

14 Mar '14

I want to commit changes to the engine by adding some bash scripts. the scripts should be invoked once a button or tab is selected in the webadmin portal by the user. can someone guide on achieving this. -- -Aditya Mamidwar

3 2

[Users] [ANN] oVirt Node ISO for oVirt 3.4 RC 2
by Fabian Deutsch 14 Mar '14

14 Mar '14

--=-XfnQPOo0nEpleRZqDZq2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey, let me announce a respun oVirt Node for oVirt 3.4 RC 2. After some time this is finally available from where it belongs: http://resources.ovirt.org/releases/3.4.0_pre/iso/ovirt-node-iso-3.0.4-1.0.= 201401291204.vdsm34rc2.el6.iso There are also older releases of oVirt Node, in case that the latest version has unknown regressions. http://resources.ovirt.org/releases/3.4.0_pre/iso/ Please let us known about issues you run into. You can also let us know when Node "Just Works (TM)". Greetings fabian --=-XfnQPOo0nEpleRZqDZq2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAABAgAGBQJTIykgAAoJEC9+uOgSHVGUnX4P/2TUR2eMvhscP0KSgL9T5hmV 23+zzQVc8xIVSAY2ko+GLlaYsZ9Ui7C5fB1mDOx0zjUQ8qqwsDvBzkTDJAX3sFhD HzIjfcF97CPKdRVbpT6qrFVyHew4dR+CloJT5iuxiidO3dXlDGvUarByfeYZ97cJ /T1BDx4Gi3vxx0hVG0/rzDZvqmrYa34SlbM9B7mP1OhVwU2ZgfD0+KjrnaLbeGUJ Y2jh//Zr9g+0mzGWTdjEZ1dlR4XXf6qLG53r49cX00zkC66BOLeaBoI67ngD6ah5 9Qj2zDhgN98TvF8QWQk6clzFFDuqTwX2fKbNnjy/6khH1xg9S95Vxn8f3o3HPtS0 CSh1mg+fs3EoMWj8W2kYrmVjs6CkXa0YI+pAAGacKkInLzuMgvTYUEDNYbAKdTFu kNz+Eps6ay8wWXHgR9QOXCakBfGliWcIVcR7CbwGbB+lsWrh5/l3eGKY0KzTaDR8 q/ieq6O6F7Uik2N+J347Sh9fyobUftaa75cbfQS9bfF7n4F44PRDJeYUjEkpZEo6 mRUhdi3OWlP+kergTaDst68NsR91F1P6FsO9cc3QlejmjH7ZpmtQDsqAtRDMvoCG 25Oqj5Rq425GOx9OfMwvRpZ1N8PjiPLxP4wLLaR6bgyw4EG4VirugPRImtfCf+4d Bd+qMPHfWkLunO8mioec =DTiV -----END PGP SIGNATURE----- --=-XfnQPOo0nEpleRZqDZq2--

1 0

[Users] edit-node problems
by Simon Barrett 14 Mar '14

14 Mar '14

--_000_D86C48DF8800164BBE50B87623F7AC95481D65D3ln2wio001devtra_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm trying to use edit-node to add the ovirt-node-plugin-vdsm plugin to the= ovirt-node-iso-3.0.2-1.0.0.el6.iso that I downloaded from here: http://res= ources.ovirt.org/releases/node-base/stable/iso/ovirt-node-iso-3.0.2-1.0.0.e= l6.iso Whenever I run any edit-node commands against this iso I get the error belo= w: # ./ovirt-node/tools/edit-node -dv --print-rpm-manifest /app/iso/ovirt-node= -iso-3.0.2-1.0.0.el6.iso /app/iso/ovirt-node-iso-3.0.2-1.0.0.el6.iso Losetup add /dev/loop0 mapping to /app/iso/ovirt-node-iso-3.0.2-1.0.0.el6.i= so Mounting /dev/loop0 at /var/tmp/edit-liveos-nEP1ae/tmp-IrE34t Losetup add /dev/loop1 mapping to /var/tmp/edit-liveos-nEP1ae/tmp-IrE34t/Li= veOS/squashfs.img Mounting /dev/loop1 at /var/tmp/edit-liveos-nEP1ae/tmp-VOGtjF mount: block device /dev/loop1 is write-protected, mounting read-only Unmounting directory /var/tmp/edit-liveos-nEP1ae/tmp-VOGtjF Losetup remove /dev/loop1 Unmounting directory /var/tmp/edit-liveos-nEP1ae/tmp-IrE34t Losetup remove /dev/loop0 /usr/lib/python2.6/site-packages/imgcreate/errors.py:45: DeprecationWarning= : BaseException.message has been deprecated as of Python 2.6 return unicode(self.message) Error editing LiveOS : Failed to copy base live image to /var/tmp/edit-live= os-nEP1ae/ex/ext3fs.img for modification: [Errno 5] Input/output error If I try the same with ovirt-node-iso-3.0.1-1.0.2.el6.iso (downloaded from = the same location) all works as expected. I've tried this on CentOS 6.2 and 6.4, same results on both. Can anyone tell me where I am going wrong? Alternatively is there a newer n= ode ISO that already has the ovirt-node-plugin-vdsm plugin installed? Thanks, Simon --_000_D86C48DF8800164BBE50B87623F7AC95481D65D3ln2wio001devtra_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-GB" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> I’m trying to use edit-node to add the ovirt-n= ode-plugin-vdsm plugin to the ovirt-node-iso-3.0.2-1.0.0.el6.iso that I dow= nloaded from here: <a href=3D"http://resources.ovirt.org/releases/node-base/stable/iso/ovirt-n= ode-iso-3.0.2-1.0.0.el6.iso"> http://resources.ovirt.org/releases/node-base/stable/iso/ovirt-node-iso-3.0= .2-1.0.0.el6.iso</a><o:p></o:p> <o:p> </o:p> Whenever I run any edit-node commands against this i= so I get the error below:<o:p></o:p> <o:p> </o:p> # ./ovirt-node/tools/edit-node -dv --print-rpm-manif= est /app/iso/ovirt-node-iso-3.0.2-1.0.0.el6.iso<o:p></o:p> /app/iso/ovirt-node-iso-3.0.2-1.0.0.el6.iso<o:p></o:= p> Losetup add /dev/loop0 mapping to /app/iso/ovirt-nod= e-iso-3.0.2-1.0.0.el6.iso<o:p></o:p> Mounting /dev/loop0 at /var/tmp/edit-liveos-nEP1ae/t= mp-IrE34t<o:p></o:p> Losetup add /dev/loop1 mapping to /var/tmp/edit-live= os-nEP1ae/tmp-IrE34t/LiveOS/squashfs.img<o:p></o:p> Mounting /dev/loop1 at /var/tmp/edit-liveos-nEP1ae/t= mp-VOGtjF<o:p></o:p> mount: block device /dev/loop1 is write-protected, m= ounting read-only<o:p></o:p> Unmounting directory /var/tmp/edit-liveos-nEP1ae/tmp= -VOGtjF<o:p></o:p> Losetup remove /dev/loop1<o:p></o:p> Unmounting directory /var/tmp/edit-liveos-nEP1ae/tmp= -IrE34t<o:p></o:p> Losetup remove /dev/loop0<o:p></o:p> /usr/lib/python2.6/site-packages/imgcreate/errors.py= :45: DeprecationWarning: BaseException.message has been deprecated as of Py= thon 2.6<o:p></o:p>   return unicode(self.message)<o:p></o:p> Error editing LiveOS : Failed to copy base live imag= e to /var/tmp/edit-liveos-nEP1ae/ex/ext3fs.img for modification: [Errno 5] = Input/output error<o:p></o:p> <o:p> </o:p> <o:p> </o:p> If I try the same with ovirt-node-iso-3.0.1-1.0.2.el= 6.iso (downloaded from the same location) all works as expected.<o:p></o:p>= <o:p> </o:p> I’ve tried this on CentOS 6.2 and 6.4, same re= sults on both.<o:p></o:p> <o:p> </o:p> Can anyone tell me where I am going wrong? Alternati= vely is there a newer node ISO that already has the ovirt-node-plugin-vdsm = plugin installed?<o:p></o:p> <o:p> </o:p> Thanks,<o:p></o:p> <o:p> </o:p> Simon<o:p></o:p> </div> </body> </html> --_000_D86C48DF8800164BBE50B87623F7AC95481D65D3ln2wio001devtra_--

2 2

[Users] Can't connect to any console
by Chloride Cull 14 Mar '14

14 Mar '14

So, I've finally managed to set up an all-in-one setup on a CentOS box. Issue is, I can't connect to any running VMs, connecting to the console works. After some headaches, I've found that VNC just fails, while Spice says that there is no route to the host. Thinking it was just that it disregarded /etc/hosts, I setup dnsmasq. Still got issues. dig shows it resolves, tracepath shows a path and ping gets replies. (see <http://pastebin.com/raw.php?i=qWy8RnA6>) Have anyone here had similar issues? How did you do to fix it?

3 3

Re: [Users] SD Disk's Logical Volume not visible/activated on some nodes
by John Taylor 13 Mar '14

13 Mar '14

I want to jump in here and say I'm seeing the same thing. ovirt 3.3.2 on f19 hosts are vdsm 4.13.3-3.fc19 I'm using storage domain iscsi (fujitsu eternus) with 4 hosts. I've known about the warning with the vg_mda_free ( I asked on lvm with no response https://www.redhat.com/archives/linux-lvm/2014-February/msg00033.html ) but until now I didn't verify the problem with not seeing the lvs. My test was create a standalone disk on the iscsi sd. The lv only shows on the spm where it was created. None of the other 3 hosts show it. multipath -r on a non-spm host causes it to show up. same lvm version # lvm version LVM version: 2.02.98(2) (2012-10-15) Library version: 1.02.77 (2012-10-15) Driver version: 4.26.0 -John >> This looks wrong - your vg_mda_free is zero - as vdsm complains. >> >> Zdenek, how can we debug this further? > > I see same issue in Fedora 19. > > Can you share with us the output of: > > cat /etc/redhat-release > uname -a > lvm version > > Nir $ cat /etc/redhat-release Fedora release 19 (Schrödinger's Cat) $ uname -a Linux blizzard.mgmt.futurice.com 3.12.6-200.fc19.x86_64.debug #1 SMP Mon Dec 23 16:24:32 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $ lvm version LVM version: 2.02.98(2) (2012-10-15) Library version: 1.02.77 (2012-10-15) Driver version: 4.26.0

2 1

[Users] Gluster volume options change, crash, vdsm reports SD does not exist
by Steve Dainard 13 Mar '14

13 Mar '14

I was playing with some gluster performance options on my storage volume and managed to crash it. On recovery (and heal) my storage domain won't come up. I'm getting these errors in vdsm.log: Thread-24::WARNING::2014-03-13 15:51:18,741::lvm::391::Storage.LVM::(_reloadvgs) lvm vgs failed: 5 [] [' Volume group "47df1e9f-6a83-46b9-a7ec-9568abd10d1a" not found', ' Skipping volume group 47df1e9f-6a83-46b9-a7ec-9568abd10d1a'] Thread-24::DEBUG::2014-03-13 15:51:18,741::lvm::428::OperationMutex::(_reloadvgs) Operation 'lvm reload operation' released the operation mutex Thread-24::ERROR::2014-03-13 15:51:18,748::sdc::143::Storage.StorageDomainCache::(_findDomain) domain 47df1e9f-6a83-46b9-a7ec-9568abd10d1a not found Traceback (most recent call last): File "/usr/share/vdsm/storage/sdc.py", line 141, in _findDomain dom = findMethod(sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 171, in _findUnfetchedDomain raise se.StorageDomainDoesNotExist(sdUUID) StorageDomainDoesNotExist: Storage domain does not exist: ('47df1e9f-6a83-46b9-a7ec-9568abd10d1a',) Thread-24::ERROR::2014-03-13 15:51:18,748::domainMonitor::231::Storage.DomainMonitorThread::(_monitorDomain) Error while collecting domain 47df1e9f-6a83-46b9-a7ec-9568abd10d1a monitoring information Traceback (most recent call last): File "/usr/share/vdsm/storage/domainMonitor.py", line 196, in _monitorDomain self.domain = sdCache.produce(self.sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 98, in produce domain.getRealDomain() File "/usr/share/vdsm/storage/sdc.py", line 52, in getRealDomain return self._cache._realProduce(self._sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 122, in _realProduce domain = self._findDomain(sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 141, in _findDomain dom = findMethod(sdUUID) File "/usr/share/vdsm/storage/sdc.py", line 171, in _findUnfetchedDomain raise se.StorageDomainDoesNotExist(sdUUID) StorageDomainDoesNotExist: Storage domain does not exist: ('47df1e9f-6a83-46b9-a7ec-9568abd10d1a',) I destroyed (UI) the storage domain (47df1e9f-6a83-46b9-a7ec-9568abd10d1a was an iso domain) but still get the same errors. I've tried re-installing the hosts without change. Is there a local cache vdsm builds that it might be referencing that I can clear out? I'm only showing one SD in the db which is my gluster SD: engine=# select * from storage_domain_static; id | storage | storage_name | storage_domain_type | storage_type | storage_domain_format_type | _create_date | _update_dat e | recoverable | last_time_used_as_master | storage_description | storage_comment --------------------------------------+--------------------------------------+--------------+---------------------+--------------+----------------------------+-------------------------------+-------------------- -----------+-------------+--------------------------+---------------------+----------------- 0de3b516-6c74-4ad8-8958-d3f571ceda8d | e329ad38-b5d8-47a3-ac01-3dfdd5193032 | rep2 | 0 | 7 | 3 | 2014-02-23 16:20:42.327492-05 | 2014-02-23 16:20:49 .094751-05 | t | 0 | | (1 row) engine=# select * from storage_domain_; storage_domain_dynamic storage_domain_file_repos storage_domain_static storage_domain_static_view engine=# select * from storage_domain_dynamic; id | available_disk_size | used_disk_size | _update_date --------------------------------------+---------------------+----------------+------------------------------- 0de3b516-6c74-4ad8-8958-d3f571ceda8d | 1887 | 160 | 2014-03-12 01:59:52.258384-04 (1 row) [root@ovirt001 vdsm]# vdsClient -s 0 getStorageDomainsList [root@ovirt001 vdsm]# engine.log contains this repeating: TaskStatusListReturnForXmlRpc [mStatus=StatusForXmlRpc [mCode=654, mMessage=Not SPM]] 2014-03-13 16:02:03,538 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand] (DefaultQuartzScheduler_Worker-21) [4f649953] HostName = ovirt001 2014-03-13 16:02:03,538 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand] (DefaultQuartzScheduler_Worker-21) [4f649953] Command HSMGetAllTasksStatusesVDS execution failed. Exception: IRSNonOperationalException: IRSGenericException: IRSErrorException: IRSNonOperationalException: Not SPM 2014-03-13 16:02:03,539 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStopVDSCommand] (DefaultQuartzScheduler_Worker-21) [4f649953] FINISH, SpmStopVDSCommand, log id: 41fe5668 2014-03-13 16:02:03,539 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (DefaultQuartzScheduler_Worker-21) [4f649953] spm stop succeeded, continuing with spm selection 2014-03-13 16:02:03,560 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (DefaultQuartzScheduler_Worker-21) [4f649953] starting spm on vds ovirt002, storage pool IT, prevId 1, LVER 7 2014-03-13 16:02:03,561 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStartVDSCommand] (DefaultQuartzScheduler_Worker-21) [4f649953] START, SpmStartVDSCommand(HostName = ovirt002, HostId = fac716fc-baff-46fe-9323-fd581a26a983, storagePoolId = 8da661c0-8125-4efb-851e-c9320d268578, prevId=1, prevLVER=7, storagePoolFormatType=V3, recoveryMode=Manual, SCSIFencing=true), log id: 53385b6b 2014-03-13 16:02:03,572 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStartVDSCommand] (DefaultQuartzScheduler_Worker-21) [4f649953] spmStart polling started: taskId = 0fb302dd-32ff-4442-aa98-5eecaf571da4 2014-03-13 16:02:05,598 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetTaskStatusVDSCommand] (DefaultQuartzScheduler_Worker-21) [4f649953] Failed in HSMGetTaskStatusVDS method 2014-03-13 16:02:05,599 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetTaskStatusVDSCommand] (DefaultQuartzScheduler_Worker-21) [4f649953] Error code AcquireHostIdFailure and error message VDSGenericException: VDSErrorException: Failed to HSMGetTaskStatusVDS, error = Cannot acquire host id 2014-03-13 16:02:05,599 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStartVDSCommand] (DefaultQuartzScheduler_Worker-21) [4f649953] spmStart polling ended: taskId = 0fb302dd-32ff-4442-aa98-5eecaf571da4 task status = finished 2014-03-13 16:02:05,600 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStartVDSCommand] (DefaultQuartzScheduler_Worker-21) [4f649953] Start SPM Task failed - result: cleanSuccess, message: VDSGenericException: VDSErrorException: Failed to HSMGetTaskStatusVDS, error = Cannot acquire host id 2014-03-13 16:02:05,606 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStartVDSCommand] (DefaultQuartzScheduler_Worker-21) [4f649953] spmStart polling ended, spm status: Free 2014-03-13 16:02:05,607 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMClearTaskVDSCommand] (DefaultQuartzScheduler_Worker-21) [4f649953] START, HSMClearTaskVDSCommand(HostName = ovirt002, HostId = fac716fc-baff-46fe-9323-fd581a26a983, taskId=0fb302dd-32ff-4442-aa98-5eecaf571da4), log id: 6e65ac77 2014-03-13 16:02:05,613 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMClearTaskVDSCommand] (DefaultQuartzScheduler_Worker-21) [4f649953] FINISH, HSMClearTaskVDSCommand, log id: 6e65ac77 2014-03-13 16:02:05,613 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.SpmStartVDSCommand] (DefaultQuartzScheduler_Worker-21) [4f649953] FINISH, SpmStartVDSCommand, return: org.ovirt.engine.core.common.businessentities.SpmStatusResult@798917ef, log id: 53385b6b 2014-03-13 16:02:05,615 INFO [org.ovirt.engine.core.bll.storage.SetStoragePoolStatusCommand] (DefaultQuartzScheduler_Worker-21) [17828a3f] Running command: SetStoragePoolStatusCommand internal: true. Entities affected : ID: 8da661c0-8125-4efb-851e-c9320d268578 Type: StoragePool 2014-03-13 16:02:05,656 ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (DefaultQuartzScheduler_Worker-21) [17828a3f] IrsBroker::Failed::GetStoragePoolInfoVDS due to: IrsSpmStartFailedException: IRSGenericException: IRSErrorException: SpmStart failed 2014-03-13 16:02:15,674 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand] (DefaultQuartzScheduler_Worker-39) [7b210b3d] Command org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand return value TaskStatusListReturnForXmlRpc [mStatus=StatusForXmlRpc [mCode=654, mMessage=Not SPM]] Any help appreciated. vdsm.log from both hosts and engine.log attached. *Steve Dainard * IT Infrastructure Manager Miovision <http://miovision.com/> | *Rethink Traffic* *Blog <http://miovision.com/blog> | **LinkedIn <https://www.linkedin.com/company/miovision-technologies> | Twitter <https://twitter.com/miovision> | Facebook <https://www.facebook.com/miovision>* ------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately.

1 0

[Users] ovirt engine source
by jacek burghardt 13 Mar '14

13 Mar '14

Is there source of ovirt engine that stable ? I was able to compile master of git source but after some changes it seems to be broken. I ge this error when it comes to compile webadmin [ERROR] Failed to execute goal org.codehaus.mojo:gwt-maven-plugin:2.5.1:compile (gwtcompile) on project webadmin: Command [[ [ERROR] /bin/sh -c /usr/lib/jvm/java-7-openjdk/jre/bin/java -javaagent:/root/.m2/repository/org/aspectj/aspectjweaver/1.6.11/aspectjweaver-1.6.11.jar -Xms1024M -Xmx4096M -XX:PermSize=512M -XX:MaxPermSize=1024M \ [ERROR] -Dgwt.jjs.permutationWorkerFactory=com.google.gwt.dev.ThreadedPermutationWorkerFactory \

5 25

[Users] Delete & Detach Logical Network
by Tejesh M 13 Mar '14

13 Mar '14

Hi, I'm able to delete the logical network but this logical network after deletion shows as unmanaged network in "Setup Host Networks" against the hostnic. I tried with this code to detach the logical network. *Code 1:* HostNIC nic = api.getHosts().get("rhevhost").getHostNics().get("eth1"); Action action = new Action(); action.setNetwork(api.getNetworks().get(nw_name)); action.setDetach(true); action.setCheckConnectivity(false); nic.detach(action); *Returns*: code : 409 reason: Conflict detail: Network Interface is not attached to Logical Network. *Code 2:* HostNIC nic = api.getHosts().get("rhevhost").getHostNics().get("eth1.1345"); Action action = new Action(); action.setNetwork(api.getNetworks().get(nw_name)); action.setDetach(true); action.setCheckConnectivity(false); nic.detach(action); *Returns*: code : 409 reason: Conflict detail: Cannot edit Network while Host is Active, change the Host to Maintenance mode and try again. -- Thanks & Regards Tejesh

2 7

[Users] oVirt 3.3.3 - Migration failures
by LANGE Thomas 13 Mar '14

13 Mar '14

--_004_4C61EFDD7F9C1646BBF252580B27F2A3DB31BEC3FFTHSONEA01CMS1_ Content-Type: multipart/alternative; boundary="_000_4C61EFDD7F9C1646BBF252580B27F2A3DB31BEC3FFTHSONEA01CMS1_" --_000_4C61EFDD7F9C1646BBF252580B27F2A3DB31BEC3FFTHSONEA01CMS1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi ! I am testing all the functionalities of oVirt for work and I have some issu= es regarding live migration. Here's my configuration: - pc001 : CentOS 6.5 minimal with VDSM (4.13.3-3.el6) - pc002 : CentOS 6.5 minimal with VDSM (4.13.3-3.el6) and ovirt-engin= e (3.3.3-2.el6) - pc003 : CentOS 6.5 with VDSM (4.13.3-3.el6) All these servers are in the same cluster and datacenter is using NFS for s= torage. Here's my problem : I have one VM (called Debian) running on a specific hos= t (pc003.lan). I try to migrate it to another host (pc001.lan) but the migr= ation fails. As a result, the VM is still running on pc003 and the number o= f running VMs on this host is still the same; but I can see one more VM run= ning on the host pc001. It does the same thing with other VMs (mavm1, mavm2= , mavm3, Debian2....). At the end, the administration portal tells me I hav= e 7VMs running on host pc001, 4 on pc002 and 3 on pc001; I have only 7 VMs = , not 14. >From now, some errors keep showing up in the log (see attachment). It says = that migrations are still running but I cannot cancel them in the administr= ation portal and they never stop/succeed/fail. This problem occurred some t= ime after I enabled quotas in the Datacenter but I don't know if it's relat= ed in any way. If I reboot pc001, the number of running VM is reset to 0, b= ut any attempt to migrate a VM to this host does the same thing again. Also= , restarting the engine did not fix this issue. Does anyone have an idea about what's happening ? I'm new with oVirt and I = don't know what to do to solve this. Thanks for your help ! Regards, Thomas LANG=C9 --_000_4C61EFDD7F9C1646BBF252580B27F2A3DB31BEC3FFTHSONEA01CMS1_ Content-Type: text/html; charset="iso-8859-1" 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=3DContent-Type content= =3D"text/html; charset=3Diso-8859-1"><meta name=3DGenerator content=3D"Micr= osoft Word 14 (filtered medium)"><style></style></head><body lang=3DFR link=3Dblue vlink= =3Dpurple><div class=3DWordSection1>Hi !<o:p></o:p>= <o:p> </o:p>I am testing all the functional= ities of oVirt for work and I have some issues regarding live migration.<o:= p></o:p>Here’s my configuration:<o:p></o:p>= <![if !supportLists]>-       </= span><![endif]>pc001 : CentOS 6.5 minimal with VDSM (4.13.3-3.el6= )<o:p></o:p><![if !supportLists]>-<spa= n style=3D'font:7.0pt "Times New Roman"'>     &nbs= p; <![endif]>pc002 : CentOS 6.5 minimal with= VDSM (4.13.3-3.el6) and ovirt-engine (3.3.3-2.el6)<o:p></o:p><p= class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 level1 l= fo1'><![if !supportLists]>-       <= ![endif]>pc003 : CentOS 6.5 with VDSM (4.13.3-3.el6)<o:p></o:p></= span>All these servers are in the same cluster and datacenter i= s using NFS for storage.<o:p></o:p><o:p> </o:p></sp= an>Here’s my problem : I have one VM (called Debian) runn= ing on a specific host (pc003.lan). I try to migrate it to another host (pc= 001.lan) but the migration fails. As a result, the VM is still running on p= c003 and the number of running VMs on this host is still the same; but I ca= n see one more VM running on the host pc001. It does the same thing with ot= her VMs (mavm1, mavm2, mavm3, Debian2….). At the end, the administrat= ion portal tells me I have 7VMs running on host pc001, 4 on pc002 and 3 on = pc001; I have only 7 VMs , not 14.<o:p></o:p><o:p> = </o:p>From now, some errors keep showing up in the log (= see attachment). It says that migrations are still running but I cannot can= cel them in the administration portal and they never stop/succeed/fail. Thi= s problem occurred some time after I enabled quotas in the Datacenter but I= don’t know if it’s related in any way. If I reboot pc001, the = number of running VM is reset to 0, but any attempt to migrate a VM to this= host does the same thing again. Also, restarting the engine did not fix th= is issue.<o:p></o:p><o:p> </o:p>= Does anyone have an idea about what’s happening ? I’m new with = oVirt and I don’t know what to do to solve this.<o:p></o:p></p= ><o:p> </o:p>Thanks for your help !<o:p></o= :p><o:p> </o:p><spa= n lang=3DEN-US style=3D'font-family:"Arial","sans-serif"'>Regards,<o:p></o:= p><o:p> </o:p><span= style=3D'font-family:"Arial","sans-serif";mso-fareast-language:FR'>Thomas = LANG=C9<o:p></o:p><o:p> </o:p></di= v></body></html>= --_000_4C61EFDD7F9C1646BBF252580B27F2A3DB31BEC3FFTHSONEA01CMS1_-- --_004_4C61EFDD7F9C1646BBF252580B27F2A3DB31BEC3FFTHSONEA01CMS1_ Content-Type: text/plain; name="log.txt" Content-Description: log.txt Content-Disposition: attachment; filename="log.txt"; size=23073; creation-date="Wed, 12 Mar 2014 13:49:33 GMT"; modification-date="Wed, 12 Mar 2014 13:47:45 GMT" Content-Transfer-Encoding: base64 MjAxNC0wMy0xMiAxMTozNDozNCw0MzAgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS5kYWwu ZGJicm9rZXIuYXVkaXRsb2doYW5kbGluZy5BdWRpdExvZ0RpcmVjdG9yXSAoRGVmYXVsdFF1YXJ0 elNjaGVkdWxlcl9Xb3JrZXItOTcpIENvcnJlbGF0aW9uIElEOiBudWxsLCBDYWxsIFN0YWNrOiBu dWxsLCBDdXN0b20gRXZlbnQgSUQ6IC0xLCBNZXNzYWdlOiBWTSBDZW50T1MgaXMgZG93bi4gRXhp dCBtZXNzYWdlOiBEb21haW4gbm90IGZvdW5kOiBubyBkb21haW4gd2l0aCBtYXRjaGluZyB1dWlk ICdmMzFlOWI0Ny1hNjc2LTQxNTEtYmNiZC1jMzljYWI3NTk4MDcnLgoyMDE0LTAzLTEyIDExOjM0 OjM0LDQzMiBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIu RGVzdHJveVZEU0NvbW1hbmRdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci05NykgU1RB UlQsIERlc3Ryb3lWRFNDb21tYW5kKEhvc3ROYW1lID0gcGMwMDEubGFuLCBIb3N0SWQgPSA1NGEw NTczNC0yYjIzLTQzYTgtYTI0Zi1mNjJmMjk3ZmE4ODQsIHZtSWQ9NGFkNGQyNjgtODQ4Ny00YWQz LWEyMWQtZWM5ZWEyODRkNWM2LCBmb3JjZT1mYWxzZSwgc2Vjb25kc1RvV2FpdD0wLCBncmFjZWZ1 bGx5PWZhbHNlKSwgbG9nIGlkOiBmMmJlZTBhCjIwMTQtMDMtMTIgMTE6MzQ6MzQsNDQxIEVSUk9S IFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29t bWFuZF0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTk3KSBGYWlsZWQgaW4gRGVzdHJv eVZEUyBtZXRob2QKMjAxNC0wMy0xMiAxMTozNDozNCw0NDIgRVJST1IgW29yZy5vdmlydC5lbmdp bmUuY29yZS52ZHNicm9rZXIudmRzYnJva2VyLkRlc3Ryb3lWRFNDb21tYW5kXSAoRGVmYXVsdFF1 YXJ0elNjaGVkdWxlcl9Xb3JrZXItOTcpIEVycm9yIGNvZGUgdW5leHBlY3RlZCBhbmQgZXJyb3Ig bWVzc2FnZSBWRFNHZW5lcmljRXhjZXB0aW9uOiBWRFNFcnJvckV4Y2VwdGlvbjogRmFpbGVkIHRv IERlc3Ryb3lWRFMsIGVycm9yID0gVW5leHBlY3RlZCBleGNlcHRpb24KMjAxNC0wMy0xMiAxMToz NDozNCw0NDMgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIudmRzYnJva2Vy LkRlc3Ryb3lWRFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItOTcpIENv bW1hbmQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVzdHJveVZE U0NvbW1hbmQgcmV0dXJuIHZhbHVlIAogU3RhdHVzT25seVJldHVybkZvclhtbFJwYyBbbVN0YXR1 cz1TdGF0dXNGb3JYbWxScGMgW21Db2RlPTE2LCBtTWVzc2FnZT1VbmV4cGVjdGVkIGV4Y2VwdGlv bl1dCjIwMTQtMDMtMTIgMTE6MzQ6MzQsNDQzIElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUu dmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZF0gKERlZmF1bHRRdWFydHpTY2hl ZHVsZXJfV29ya2VyLTk3KSBIb3N0TmFtZSA9IHBjMDAxLmxhbgoyMDE0LTAzLTEyIDExOjM0OjM0 LDQ0NCBFUlJPUiBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVz dHJveVZEU0NvbW1hbmRdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci05NykgQ29tbWFu ZCBEZXN0cm95VkRTIGV4ZWN1dGlvbiBmYWlsZWQuIEV4Y2VwdGlvbjogVkRTRXJyb3JFeGNlcHRp b246IFZEU0dlbmVyaWNFeGNlcHRpb246IFZEU0Vycm9yRXhjZXB0aW9uOiBGYWlsZWQgdG8gRGVz dHJveVZEUywgZXJyb3IgPSBVbmV4cGVjdGVkIGV4Y2VwdGlvbgoyMDE0LTAzLTEyIDExOjM0OjM0 LDQ0NSBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVz dHJveVZEU0NvbW1hbmRdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci05NykgRklOSVNI LCBEZXN0cm95VkRTQ29tbWFuZCwgbG9nIGlkOiBmMmJlZTBhCjIwMTQtMDMtMTIgMTE6MzQ6MzQs NDU1IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuZGFsLmRiYnJva2VyLmF1ZGl0bG9naGFu ZGxpbmcuQXVkaXRMb2dEaXJlY3Rvcl0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTk3 KSBDb3JyZWxhdGlvbiBJRDogbnVsbCwgQ2FsbCBTdGFjazogbnVsbCwgQ3VzdG9tIEV2ZW50IElE OiAtMSwgTWVzc2FnZTogVk0gVGVzdEltcG9ydEtWTSBpcyBkb3duLiBFeGl0IG1lc3NhZ2U6IERv bWFpbiBub3QgZm91bmQ6IG5vIGRvbWFpbiB3aXRoIG1hdGNoaW5nIHV1aWQgJzRhZDRkMjY4LTg0 ODctNGFkMy1hMjFkLWVjOWVhMjg0ZDVjNicuCjIwMTQtMDMtMTIgMTE6MzQ6MzQsNDU3IElORk8g IFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29t bWFuZF0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTk3KSBTVEFSVCwgRGVzdHJveVZE U0NvbW1hbmQoSG9zdE5hbWUgPSBwYzAwMS5sYW4sIEhvc3RJZCA9IDU0YTA1NzM0LTJiMjMtNDNh OC1hMjRmLWY2MmYyOTdmYTg4NCwgdm1JZD02MzdkNmEzYS1jMTBkLTQyNTUtYWQyZC1jY2YyOTcw ZmYyMDEsIGZvcmNlPWZhbHNlLCBzZWNvbmRzVG9XYWl0PTAsIGdyYWNlZnVsbHk9ZmFsc2UpLCBs b2cgaWQ6IDJiMjhkNDM2CjIwMTQtMDMtMTIgMTE6MzQ6MzQsNDY2IEVSUk9SIFtvcmcub3ZpcnQu ZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZF0gKERlZmF1 bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTk3KSBGYWlsZWQgaW4gRGVzdHJveVZEUyBtZXRob2QK MjAxNC0wMy0xMiAxMTozNDozNCw0NjcgRVJST1IgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNi cm9rZXIudmRzYnJva2VyLkRlc3Ryb3lWRFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxl cl9Xb3JrZXItOTcpIEVycm9yIGNvZGUgdW5leHBlY3RlZCBhbmQgZXJyb3IgbWVzc2FnZSBWRFNH ZW5lcmljRXhjZXB0aW9uOiBWRFNFcnJvckV4Y2VwdGlvbjogRmFpbGVkIHRvIERlc3Ryb3lWRFMs IGVycm9yID0gVW5leHBlY3RlZCBleGNlcHRpb24KMjAxNC0wMy0xMiAxMTozNDozNCw0NjcgSU5G TyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIudmRzYnJva2VyLkRlc3Ryb3lWRFND b21tYW5kXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItOTcpIENvbW1hbmQgb3JnLm92 aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVzdHJveVZEU0NvbW1hbmQgcmV0 dXJuIHZhbHVlIAogU3RhdHVzT25seVJldHVybkZvclhtbFJwYyBbbVN0YXR1cz1TdGF0dXNGb3JY bWxScGMgW21Db2RlPTE2LCBtTWVzc2FnZT1VbmV4cGVjdGVkIGV4Y2VwdGlvbl1dCjIwMTQtMDMt MTIgMTE6MzQ6MzQsNDY4IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZk c2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZF0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2Vy LTk3KSBIb3N0TmFtZSA9IHBjMDAxLmxhbgoyMDE0LTAzLTEyIDExOjM0OjM0LDQ2OSBFUlJPUiBb b3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVzdHJveVZEU0NvbW1h bmRdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci05NykgQ29tbWFuZCBEZXN0cm95VkRT IGV4ZWN1dGlvbiBmYWlsZWQuIEV4Y2VwdGlvbjogVkRTRXJyb3JFeGNlcHRpb246IFZEU0dlbmVy aWNFeGNlcHRpb246IFZEU0Vycm9yRXhjZXB0aW9uOiBGYWlsZWQgdG8gRGVzdHJveVZEUywgZXJy b3IgPSBVbmV4cGVjdGVkIGV4Y2VwdGlvbgoyMDE0LTAzLTEyIDExOjM0OjM0LDQ3MCBJTkZPICBb b3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVzdHJveVZEU0NvbW1h bmRdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci05NykgRklOSVNILCBEZXN0cm95VkRT Q29tbWFuZCwgbG9nIGlkOiAyYjI4ZDQzNgoyMDE0LTAzLTEyIDExOjM0OjM0LDQ4MCBJTkZPICBb b3JnLm92aXJ0LmVuZ2luZS5jb3JlLmRhbC5kYmJyb2tlci5hdWRpdGxvZ2hhbmRsaW5nLkF1ZGl0 TG9nRGlyZWN0b3JdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci05NykgQ29ycmVsYXRp b24gSUQ6IG51bGwsIENhbGwgU3RhY2s6IG51bGwsIEN1c3RvbSBFdmVudCBJRDogLTEsIE1lc3Nh Z2U6IFZNIG1hdm0yIGlzIGRvd24uIEV4aXQgbWVzc2FnZTogRG9tYWluIG5vdCBmb3VuZDogbm8g ZG9tYWluIHdpdGggbWF0Y2hpbmcgdXVpZCAnNjM3ZDZhM2EtYzEwZC00MjU1LWFkMmQtY2NmMjk3 MGZmMjAxJy4KMjAxNC0wMy0xMiAxMTozNDozNCw0ODQgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUu Y29yZS52ZHNicm9rZXIuVmRzVXBkYXRlUnVuVGltZUluZm9dIChEZWZhdWx0UXVhcnR6U2NoZWR1 bGVyX1dvcmtlci05NykgUmVmcmVzaFZtTGlzdCB2bSBpZCA3ODAyZGExMy03Y2Q0LTRjMWItOTY2 Zi04MzkwMjZmN2ExMjUgc3RhdHVzID0gRG93biBvbiB2ZHMgcGMwMDEubGFuIGlnbm9yaW5nIGl0 IGluIHRoZSByZWZyZXNoIHVudGlsIG1pZ3JhdGlvbiBpcyBkb25lCjIwMTQtMDMtMTIgMTE6MzQ6 MzQsNDg1IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLlZkc1VwZGF0ZVJ1 blRpbWVJbmZvXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItOTcpIFJlZnJlc2hWbUxp c3Qgdm0gaWQgMTdiOWRmYzItNTk1ZS00NTRiLWE1MjgtYjQzNzExMTM4NTJkIHN0YXR1cyA9IERv d24gb24gdmRzIHBjMDAxLmxhbiBpZ25vcmluZyBpdCBpbiB0aGUgcmVmcmVzaCB1bnRpbCBtaWdy YXRpb24gaXMgZG9uZQoyMDE0LTAzLTEyIDExOjM0OjM0LDQ4NiBJTkZPICBbb3JnLm92aXJ0LmVu Z2luZS5jb3JlLnZkc2Jyb2tlci5WZHNVcGRhdGVSdW5UaW1lSW5mb10gKERlZmF1bHRRdWFydHpT Y2hlZHVsZXJfV29ya2VyLTk3KSBSZWZyZXNoVm1MaXN0IHZtIGlkIGIzOWM3MDRmLTU5NDAtNDY1 ZS05ZDMxLTI2ZDJiOThjM2M1NCBzdGF0dXMgPSBEb3duIG9uIHZkcyBwYzAwMS5sYW4gaWdub3Jp bmcgaXQgaW4gdGhlIHJlZnJlc2ggdW50aWwgbWlncmF0aW9uIGlzIGRvbmUKMjAxNC0wMy0xMiAx MTozNDozNCw0ODggSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuVmRzVXBk YXRlUnVuVGltZUluZm9dIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci05NykgUmVmcmVz aFZtTGlzdCB2bSBpZCBmMzFlOWI0Ny1hNjc2LTQxNTEtYmNiZC1jMzljYWI3NTk4MDcgc3RhdHVz ID0gRG93biBvbiB2ZHMgcGMwMDEubGFuIGlnbm9yaW5nIGl0IGluIHRoZSByZWZyZXNoIHVudGls IG1pZ3JhdGlvbiBpcyBkb25lCjIwMTQtMDMtMTIgMTE6MzQ6MzQsNDg5IElORk8gIFtvcmcub3Zp cnQuZW5naW5lLmNvcmUudmRzYnJva2VyLlZkc1VwZGF0ZVJ1blRpbWVJbmZvXSAoRGVmYXVsdFF1 YXJ0elNjaGVkdWxlcl9Xb3JrZXItOTcpIFJlZnJlc2hWbUxpc3Qgdm0gaWQgNGFkNGQyNjgtODQ4 Ny00YWQzLWEyMWQtZWM5ZWEyODRkNWM2IHN0YXR1cyA9IERvd24gb24gdmRzIHBjMDAxLmxhbiBp Z25vcmluZyBpdCBpbiB0aGUgcmVmcmVzaCB1bnRpbCBtaWdyYXRpb24gaXMgZG9uZQoyMDE0LTAz LTEyIDExOjM0OjM0LDQ5MSBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci5W ZHNVcGRhdGVSdW5UaW1lSW5mb10gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTk3KSBS ZWZyZXNoVm1MaXN0IHZtIGlkIDYzN2Q2YTNhLWMxMGQtNDI1NS1hZDJkLWNjZjI5NzBmZjIwMSBz dGF0dXMgPSBEb3duIG9uIHZkcyBwYzAwMS5sYW4gaWdub3JpbmcgaXQgaW4gdGhlIHJlZnJlc2gg dW50aWwgbWlncmF0aW9uIGlzIGRvbmUKMjAxNC0wMy0xMiAxMTozNDozNCw5NzEgSU5GTyAgW29y Zy5vdmlydC5lbmdpbmUuY29yZS5kYWwuZGJicm9rZXIuUG9zdGdyZXNEYkVuZ2luZURpYWxlY3Qk UG9zdGdyZXNKZGJjVGVtcGxhdGVdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci03KSBB ZGRlZCBkZWZhdWx0IFNxbFJldHVyblJlc3VsdFNldCBwYXJhbWV0ZXIgbmFtZWQgI3Jlc3VsdC1z ZXQtMQoyMDE0LTAzLTEyIDExOjM0OjM2LDIxMyBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3Jl LmRhbC5kYmJyb2tlci5Qb3N0Z3Jlc0RiRW5naW5lRGlhbGVjdCRQb3N0Z3Jlc0pkYmNUZW1wbGF0 ZV0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTEwKSBBZGRlZCBkZWZhdWx0IFNxbFJl dHVyblJlc3VsdFNldCBwYXJhbWV0ZXIgbmFtZWQgI3Jlc3VsdC1zZXQtMQoyMDE0LTAzLTEyIDEx OjM0OjM2LDIyOSBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmRhbC5kYmJyb2tlci5Qb3N0 Z3Jlc0RiRW5naW5lRGlhbGVjdCRQb3N0Z3Jlc0pkYmNUZW1wbGF0ZV0gKERlZmF1bHRRdWFydHpT Y2hlZHVsZXJfV29ya2VyLTEwKSBBZGRlZCBkZWZhdWx0IFNxbFJldHVyblJlc3VsdFNldCBwYXJh bWV0ZXIgbmFtZWQgI3Jlc3VsdC1zZXQtMQoyMDE0LTAzLTEyIDExOjM0OjM2LDIzOCBJTkZPICBb b3JnLm92aXJ0LmVuZ2luZS5jb3JlLmRhbC5kYmJyb2tlci5Qb3N0Z3Jlc0RiRW5naW5lRGlhbGVj dCRQb3N0Z3Jlc0pkYmNUZW1wbGF0ZV0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTEw KSBBZGRlZCBkZWZhdWx0IFNxbFJldHVyblJlc3VsdFNldCBwYXJhbWV0ZXIgbmFtZWQgI3Jlc3Vs dC1zZXQtMQoyMDE0LTAzLTEyIDExOjM0OjM2LDI0NiBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5j b3JlLmRhbC5kYmJyb2tlci5Qb3N0Z3Jlc0RiRW5naW5lRGlhbGVjdCRQb3N0Z3Jlc0pkYmNUZW1w bGF0ZV0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTEwKSBBZGRlZCBkZWZhdWx0IFNx bFJldHVyblJlc3VsdFNldCBwYXJhbWV0ZXIgbmFtZWQgI3Jlc3VsdC1zZXQtMQoyMDE0LTAzLTEy IDExOjM0OjM3LDUzMyBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNi cm9rZXIuRGVzdHJveVZEU0NvbW1hbmRdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci0x MSkgU1RBUlQsIERlc3Ryb3lWRFNDb21tYW5kKEhvc3ROYW1lID0gcGMwMDEubGFuLCBIb3N0SWQg PSA1NGEwNTczNC0yYjIzLTQzYTgtYTI0Zi1mNjJmMjk3ZmE4ODQsIHZtSWQ9NzgwMmRhMTMtN2Nk NC00YzFiLTk2NmYtODM5MDI2ZjdhMTI1LCBmb3JjZT1mYWxzZSwgc2Vjb25kc1RvV2FpdD0wLCBn cmFjZWZ1bGx5PWZhbHNlKSwgbG9nIGlkOiAzM2E1ZDExNQoyMDE0LTAzLTEyIDExOjM0OjM3LDU0 NCBFUlJPUiBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVzdHJv eVZEU0NvbW1hbmRdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci0xMSkgRmFpbGVkIGlu IERlc3Ryb3lWRFMgbWV0aG9kCjIwMTQtMDMtMTIgMTE6MzQ6MzcsNTQ1IEVSUk9SIFtvcmcub3Zp cnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZF0gKERl ZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTExKSBFcnJvciBjb2RlIHVuZXhwZWN0ZWQgYW5k IGVycm9yIG1lc3NhZ2UgVkRTR2VuZXJpY0V4Y2VwdGlvbjogVkRTRXJyb3JFeGNlcHRpb246IEZh aWxlZCB0byBEZXN0cm95VkRTLCBlcnJvciA9IFVuZXhwZWN0ZWQgZXhjZXB0aW9uCjIwMTQtMDMt MTIgMTE6MzQ6MzcsNTQ2IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZk c2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZF0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2Vy LTExKSBDb21tYW5kIG9yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIudmRzYnJva2VyLkRl c3Ryb3lWRFNDb21tYW5kIHJldHVybiB2YWx1ZSAKIFN0YXR1c09ubHlSZXR1cm5Gb3JYbWxScGMg W21TdGF0dXM9U3RhdHVzRm9yWG1sUnBjIFttQ29kZT0xNiwgbU1lc3NhZ2U9VW5leHBlY3RlZCBl eGNlcHRpb25dXQoyMDE0LTAzLTEyIDExOjM0OjM3LDU0NiBJTkZPICBbb3JnLm92aXJ0LmVuZ2lu ZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVzdHJveVZEU0NvbW1hbmRdIChEZWZhdWx0UXVh cnR6U2NoZWR1bGVyX1dvcmtlci0xMSkgSG9zdE5hbWUgPSBwYzAwMS5sYW4KMjAxNC0wMy0xMiAx MTozNDozNyw1NDcgRVJST1IgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIudmRzYnJv a2VyLkRlc3Ryb3lWRFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItMTEp IENvbW1hbmQgRGVzdHJveVZEUyBleGVjdXRpb24gZmFpbGVkLiBFeGNlcHRpb246IFZEU0Vycm9y RXhjZXB0aW9uOiBWRFNHZW5lcmljRXhjZXB0aW9uOiBWRFNFcnJvckV4Y2VwdGlvbjogRmFpbGVk IHRvIERlc3Ryb3lWRFMsIGVycm9yID0gVW5leHBlY3RlZCBleGNlcHRpb24KMjAxNC0wMy0xMiAx MTozNDozNyw1NDggSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIudmRzYnJv a2VyLkRlc3Ryb3lWRFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItMTEp IEZJTklTSCwgRGVzdHJveVZEU0NvbW1hbmQsIGxvZyBpZDogMzNhNWQxMTUKMjAxNC0wMy0xMiAx MTozNDozNyw1NjIgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS5kYWwuZGJicm9rZXIuYXVk aXRsb2doYW5kbGluZy5BdWRpdExvZ0RpcmVjdG9yXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9X b3JrZXItMTEpIENvcnJlbGF0aW9uIElEOiBudWxsLCBDYWxsIFN0YWNrOiBudWxsLCBDdXN0b20g RXZlbnQgSUQ6IC0xLCBNZXNzYWdlOiBWTSBtYXZtMyBpcyBkb3duLiBFeGl0IG1lc3NhZ2U6IERv bWFpbiBub3QgZm91bmQ6IG5vIGRvbWFpbiB3aXRoIG1hdGNoaW5nIHV1aWQgJzc4MDJkYTEzLTdj ZDQtNGMxYi05NjZmLTgzOTAyNmY3YTEyNScuCjIwMTQtMDMtMTIgMTE6MzQ6MzcsNTY0IElORk8g IFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29t bWFuZF0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTExKSBTVEFSVCwgRGVzdHJveVZE U0NvbW1hbmQoSG9zdE5hbWUgPSBwYzAwMS5sYW4sIEhvc3RJZCA9IDU0YTA1NzM0LTJiMjMtNDNh OC1hMjRmLWY2MmYyOTdmYTg4NCwgdm1JZD0xN2I5ZGZjMi01OTVlLTQ1NGItYTUyOC1iNDM3MTEx Mzg1MmQsIGZvcmNlPWZhbHNlLCBzZWNvbmRzVG9XYWl0PTAsIGdyYWNlZnVsbHk9ZmFsc2UpLCBs b2cgaWQ6IDE3Yzk4YmZhCjIwMTQtMDMtMTIgMTE6MzQ6MzcsNTc1IEVSUk9SIFtvcmcub3ZpcnQu ZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZF0gKERlZmF1 bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTExKSBGYWlsZWQgaW4gRGVzdHJveVZEUyBtZXRob2QK MjAxNC0wMy0xMiAxMTozNDozNyw1NzUgRVJST1IgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNi cm9rZXIudmRzYnJva2VyLkRlc3Ryb3lWRFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxl cl9Xb3JrZXItMTEpIEVycm9yIGNvZGUgdW5leHBlY3RlZCBhbmQgZXJyb3IgbWVzc2FnZSBWRFNH ZW5lcmljRXhjZXB0aW9uOiBWRFNFcnJvckV4Y2VwdGlvbjogRmFpbGVkIHRvIERlc3Ryb3lWRFMs IGVycm9yID0gVW5leHBlY3RlZCBleGNlcHRpb24KMjAxNC0wMy0xMiAxMTozNDozNyw1NzYgSU5G TyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIudmRzYnJva2VyLkRlc3Ryb3lWRFND b21tYW5kXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItMTEpIENvbW1hbmQgb3JnLm92 aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVzdHJveVZEU0NvbW1hbmQgcmV0 dXJuIHZhbHVlIAogU3RhdHVzT25seVJldHVybkZvclhtbFJwYyBbbVN0YXR1cz1TdGF0dXNGb3JY bWxScGMgW21Db2RlPTE2LCBtTWVzc2FnZT1VbmV4cGVjdGVkIGV4Y2VwdGlvbl1dCjIwMTQtMDMt MTIgMTE6MzQ6MzcsNTc3IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZk c2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZF0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2Vy LTExKSBIb3N0TmFtZSA9IHBjMDAxLmxhbgoyMDE0LTAzLTEyIDExOjM0OjM3LDU3OCBFUlJPUiBb b3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVzdHJveVZEU0NvbW1h bmRdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci0xMSkgQ29tbWFuZCBEZXN0cm95VkRT IGV4ZWN1dGlvbiBmYWlsZWQuIEV4Y2VwdGlvbjogVkRTRXJyb3JFeGNlcHRpb246IFZEU0dlbmVy aWNFeGNlcHRpb246IFZEU0Vycm9yRXhjZXB0aW9uOiBGYWlsZWQgdG8gRGVzdHJveVZEUywgZXJy b3IgPSBVbmV4cGVjdGVkIGV4Y2VwdGlvbgoyMDE0LTAzLTEyIDExOjM0OjM3LDU3OCBJTkZPICBb b3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVzdHJveVZEU0NvbW1h bmRdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci0xMSkgRklOSVNILCBEZXN0cm95VkRT Q29tbWFuZCwgbG9nIGlkOiAxN2M5OGJmYQoyMDE0LTAzLTEyIDExOjM0OjM3LDYxMiBJTkZPICBb b3JnLm92aXJ0LmVuZ2luZS5jb3JlLmRhbC5kYmJyb2tlci5hdWRpdGxvZ2hhbmRsaW5nLkF1ZGl0 TG9nRGlyZWN0b3JdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci0xMSkgQ29ycmVsYXRp b24gSUQ6IG51bGwsIENhbGwgU3RhY2s6IG51bGwsIEN1c3RvbSBFdmVudCBJRDogLTEsIE1lc3Nh Z2U6IFZNIERlYmlhbjIgaXMgZG93bi4gRXhpdCBtZXNzYWdlOiBEb21haW4gbm90IGZvdW5kOiBu byBkb21haW4gd2l0aCBtYXRjaGluZyB1dWlkICcxN2I5ZGZjMi01OTVlLTQ1NGItYTUyOC1iNDM3 MTExMzg1MmQnLgoyMDE0LTAzLTEyIDExOjM0OjM3LDYxNCBJTkZPICBbb3JnLm92aXJ0LmVuZ2lu ZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVzdHJveVZEU0NvbW1hbmRdIChEZWZhdWx0UXVh cnR6U2NoZWR1bGVyX1dvcmtlci0xMSkgU1RBUlQsIERlc3Ryb3lWRFNDb21tYW5kKEhvc3ROYW1l ID0gcGMwMDEubGFuLCBIb3N0SWQgPSA1NGEwNTczNC0yYjIzLTQzYTgtYTI0Zi1mNjJmMjk3ZmE4 ODQsIHZtSWQ9YjM5YzcwNGYtNTk0MC00NjVlLTlkMzEtMjZkMmI5OGMzYzU0LCBmb3JjZT1mYWxz ZSwgc2Vjb25kc1RvV2FpdD0wLCBncmFjZWZ1bGx5PWZhbHNlKSwgbG9nIGlkOiA1MTgyNjlhNAoy MDE0LTAzLTEyIDExOjM0OjM3LDYyNSBFUlJPUiBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jy b2tlci52ZHNicm9rZXIuRGVzdHJveVZEU0NvbW1hbmRdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVy X1dvcmtlci0xMSkgRmFpbGVkIGluIERlc3Ryb3lWRFMgbWV0aG9kCjIwMTQtMDMtMTIgMTE6MzQ6 MzcsNjI2IEVSUk9SIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5E ZXN0cm95VkRTQ29tbWFuZF0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTExKSBFcnJv ciBjb2RlIHVuZXhwZWN0ZWQgYW5kIGVycm9yIG1lc3NhZ2UgVkRTR2VuZXJpY0V4Y2VwdGlvbjog VkRTRXJyb3JFeGNlcHRpb246IEZhaWxlZCB0byBEZXN0cm95VkRTLCBlcnJvciA9IFVuZXhwZWN0 ZWQgZXhjZXB0aW9uCjIwMTQtMDMtMTIgMTE6MzQ6MzcsNjI2IElORk8gIFtvcmcub3ZpcnQuZW5n aW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZF0gKERlZmF1bHRR dWFydHpTY2hlZHVsZXJfV29ya2VyLTExKSBDb21tYW5kIG9yZy5vdmlydC5lbmdpbmUuY29yZS52 ZHNicm9rZXIudmRzYnJva2VyLkRlc3Ryb3lWRFNDb21tYW5kIHJldHVybiB2YWx1ZSAKIFN0YXR1 c09ubHlSZXR1cm5Gb3JYbWxScGMgW21TdGF0dXM9U3RhdHVzRm9yWG1sUnBjIFttQ29kZT0xNiwg bU1lc3NhZ2U9VW5leHBlY3RlZCBleGNlcHRpb25dXQoyMDE0LTAzLTEyIDExOjM0OjM3LDYyNyBJ TkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVzdHJveVZE U0NvbW1hbmRdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci0xMSkgSG9zdE5hbWUgPSBw YzAwMS5sYW4KMjAxNC0wMy0xMiAxMTozNDozNyw2MjggRVJST1IgW29yZy5vdmlydC5lbmdpbmUu Y29yZS52ZHNicm9rZXIudmRzYnJva2VyLkRlc3Ryb3lWRFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0 elNjaGVkdWxlcl9Xb3JrZXItMTEpIENvbW1hbmQgRGVzdHJveVZEUyBleGVjdXRpb24gZmFpbGVk LiBFeGNlcHRpb246IFZEU0Vycm9yRXhjZXB0aW9uOiBWRFNHZW5lcmljRXhjZXB0aW9uOiBWRFNF cnJvckV4Y2VwdGlvbjogRmFpbGVkIHRvIERlc3Ryb3lWRFMsIGVycm9yID0gVW5leHBlY3RlZCBl eGNlcHRpb24KMjAxNC0wMy0xMiAxMTozNDozNyw2MjggSU5GTyAgW29yZy5vdmlydC5lbmdpbmUu Y29yZS52ZHNicm9rZXIudmRzYnJva2VyLkRlc3Ryb3lWRFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0 elNjaGVkdWxlcl9Xb3JrZXItMTEpIEZJTklTSCwgRGVzdHJveVZEU0NvbW1hbmQsIGxvZyBpZDog NTE4MjY5YTQKMjAxNC0wMy0xMiAxMTozNDozNyw2MzcgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUu Y29yZS5kYWwuZGJicm9rZXIuYXVkaXRsb2doYW5kbGluZy5BdWRpdExvZ0RpcmVjdG9yXSAoRGVm YXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItMTEpIENvcnJlbGF0aW9uIElEOiBudWxsLCBDYWxs IFN0YWNrOiBudWxsLCBDdXN0b20gRXZlbnQgSUQ6IC0xLCBNZXNzYWdlOiBWTSBtYXZtMSBpcyBk b3duLiBFeGl0IG1lc3NhZ2U6IERvbWFpbiBub3QgZm91bmQ6IG5vIGRvbWFpbiB3aXRoIG1hdGNo aW5nIHV1aWQgJ2IzOWM3MDRmLTU5NDAtNDY1ZS05ZDMxLTI2ZDJiOThjM2M1NCcuCjIwMTQtMDMt MTIgMTE6MzQ6MzcsNjM5IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZk c2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZF0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2Vy LTExKSBTVEFSVCwgRGVzdHJveVZEU0NvbW1hbmQoSG9zdE5hbWUgPSBwYzAwMS5sYW4sIEhvc3RJ ZCA9IDU0YTA1NzM0LTJiMjMtNDNhOC1hMjRmLWY2MmYyOTdmYTg4NCwgdm1JZD0wZGNiMGZmYS0w ODk5LTRhMTEtYjJkNC03NzE2MTk3NmNmMTcsIGZvcmNlPWZhbHNlLCBzZWNvbmRzVG9XYWl0PTAs IGdyYWNlZnVsbHk9ZmFsc2UpLCBsb2cgaWQ6IDU2MWVmYjY1CjIwMTQtMDMtMTIgMTE6MzQ6Mzcs NjUxIEVSUk9SIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0 cm95VkRTQ29tbWFuZF0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTExKSBGYWlsZWQg aW4gRGVzdHJveVZEUyBtZXRob2QKMjAxNC0wMy0xMiAxMTozNDozNyw2NTIgRVJST1IgW29yZy5v dmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIudmRzYnJva2VyLkRlc3Ryb3lWRFNDb21tYW5kXSAo RGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItMTEpIEVycm9yIGNvZGUgdW5leHBlY3RlZCBh bmQgZXJyb3IgbWVzc2FnZSBWRFNHZW5lcmljRXhjZXB0aW9uOiBWRFNFcnJvckV4Y2VwdGlvbjog RmFpbGVkIHRvIERlc3Ryb3lWRFMsIGVycm9yID0gVW5leHBlY3RlZCBleGNlcHRpb24KMjAxNC0w My0xMiAxMTozNDozNyw2NTIgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIu dmRzYnJva2VyLkRlc3Ryb3lWRFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3Jr ZXItMTEpIENvbW1hbmQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIu RGVzdHJveVZEU0NvbW1hbmQgcmV0dXJuIHZhbHVlIAogU3RhdHVzT25seVJldHVybkZvclhtbFJw YyBbbVN0YXR1cz1TdGF0dXNGb3JYbWxScGMgW21Db2RlPTE2LCBtTWVzc2FnZT1VbmV4cGVjdGVk IGV4Y2VwdGlvbl1dCjIwMTQtMDMtMTIgMTE6MzQ6MzcsNjUzIElORk8gIFtvcmcub3ZpcnQuZW5n aW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZF0gKERlZmF1bHRR dWFydHpTY2hlZHVsZXJfV29ya2VyLTExKSBIb3N0TmFtZSA9IHBjMDAxLmxhbgoyMDE0LTAzLTEy IDExOjM0OjM3LDY1NCBFUlJPUiBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNi cm9rZXIuRGVzdHJveVZEU0NvbW1hbmRdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci0x MSkgQ29tbWFuZCBEZXN0cm95VkRTIGV4ZWN1dGlvbiBmYWlsZWQuIEV4Y2VwdGlvbjogVkRTRXJy b3JFeGNlcHRpb246IFZEU0dlbmVyaWNFeGNlcHRpb246IFZEU0Vycm9yRXhjZXB0aW9uOiBGYWls ZWQgdG8gRGVzdHJveVZEUywgZXJyb3IgPSBVbmV4cGVjdGVkIGV4Y2VwdGlvbgoyMDE0LTAzLTEy IDExOjM0OjM3LDY1NCBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNi cm9rZXIuRGVzdHJveVZEU0NvbW1hbmRdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci0x MSkgRklOSVNILCBEZXN0cm95VkRTQ29tbWFuZCwgbG9nIGlkOiA1NjFlZmI2NQoyMDE0LTAzLTEy IDExOjM0OjM3LDY3MCBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmRhbC5kYmJyb2tlci5h dWRpdGxvZ2hhbmRsaW5nLkF1ZGl0TG9nRGlyZWN0b3JdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVy X1dvcmtlci0xMSkgQ29ycmVsYXRpb24gSUQ6IG51bGwsIENhbGwgU3RhY2s6IG51bGwsIEN1c3Rv bSBFdmVudCBJRDogLTEsIE1lc3NhZ2U6IFZNIERlYmlhbiBpcyBkb3duLiBFeGl0IG1lc3NhZ2U6 IGRlc3Ryb3koKSBjYWxsZWQgYmVmb3JlIFZtIHN0YXJ0ZWQuCjIwMTQtMDMtMTIgMTE6MzQ6Mzcs NjcyIElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0 cm95VkRTQ29tbWFuZF0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTExKSBTVEFSVCwg RGVzdHJveVZEU0NvbW1hbmQoSG9zdE5hbWUgPSBwYzAwMS5sYW4sIEhvc3RJZCA9IDU0YTA1NzM0 LTJiMjMtNDNhOC1hMjRmLWY2MmYyOTdmYTg4NCwgdm1JZD1mMzFlOWI0Ny1hNjc2LTQxNTEtYmNi ZC1jMzljYWI3NTk4MDcsIGZvcmNlPWZhbHNlLCBzZWNvbmRzVG9XYWl0PTAsIGdyYWNlZnVsbHk9 ZmFsc2UpLCBsb2cgaWQ6IDU1YjQxMTA5CjIwMTQtMDMtMTIgMTE6MzQ6MzcsNjgzIEVSUk9SIFtv cmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29tbWFu ZF0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTExKSBGYWlsZWQgaW4gRGVzdHJveVZE UyBtZXRob2QKMjAxNC0wMy0xMiAxMTozNDozNyw2ODQgRVJST1IgW29yZy5vdmlydC5lbmdpbmUu Y29yZS52ZHNicm9rZXIudmRzYnJva2VyLkRlc3Ryb3lWRFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0 elNjaGVkdWxlcl9Xb3JrZXItMTEpIEVycm9yIGNvZGUgdW5leHBlY3RlZCBhbmQgZXJyb3IgbWVz c2FnZSBWRFNHZW5lcmljRXhjZXB0aW9uOiBWRFNFcnJvckV4Y2VwdGlvbjogRmFpbGVkIHRvIERl c3Ryb3lWRFMsIGVycm9yID0gVW5leHBlY3RlZCBleGNlcHRpb24KMjAxNC0wMy0xMiAxMTozNDoz Nyw2ODQgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIudmRzYnJva2VyLkRl c3Ryb3lWRFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItMTEpIENvbW1h bmQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVzdHJveVZEU0Nv bW1hbmQgcmV0dXJuIHZhbHVlIAogU3RhdHVzT25seVJldHVybkZvclhtbFJwYyBbbVN0YXR1cz1T dGF0dXNGb3JYbWxScGMgW21Db2RlPTE2LCBtTWVzc2FnZT1VbmV4cGVjdGVkIGV4Y2VwdGlvbl1d CjIwMTQtMDMtMTIgMTE6MzQ6MzcsNjg1IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRz YnJva2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZF0gKERlZmF1bHRRdWFydHpTY2hlZHVs ZXJfV29ya2VyLTExKSBIb3N0TmFtZSA9IHBjMDAxLmxhbgoyMDE0LTAzLTEyIDExOjM0OjM3LDY4 NiBFUlJPUiBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVzdHJv eVZEU0NvbW1hbmRdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci0xMSkgQ29tbWFuZCBE ZXN0cm95VkRTIGV4ZWN1dGlvbiBmYWlsZWQuIEV4Y2VwdGlvbjogVkRTRXJyb3JFeGNlcHRpb246 IFZEU0dlbmVyaWNFeGNlcHRpb246IFZEU0Vycm9yRXhjZXB0aW9uOiBGYWlsZWQgdG8gRGVzdHJv eVZEUywgZXJyb3IgPSBVbmV4cGVjdGVkIGV4Y2VwdGlvbgoyMDE0LTAzLTEyIDExOjM0OjM3LDY4 NiBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVzdHJv eVZEU0NvbW1hbmRdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci0xMSkgRklOSVNILCBE ZXN0cm95VkRTQ29tbWFuZCwgbG9nIGlkOiA1NWI0MTEwOQoyMDE0LTAzLTEyIDExOjM0OjM3LDY5 NSBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmRhbC5kYmJyb2tlci5hdWRpdGxvZ2hhbmRs aW5nLkF1ZGl0TG9nRGlyZWN0b3JdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci0xMSkg Q29ycmVsYXRpb24gSUQ6IG51bGwsIENhbGwgU3RhY2s6IG51bGwsIEN1c3RvbSBFdmVudCBJRDog LTEsIE1lc3NhZ2U6IFZNIENlbnRPUyBpcyBkb3duLiBFeGl0IG1lc3NhZ2U6IERvbWFpbiBub3Qg Zm91bmQ6IG5vIGRvbWFpbiB3aXRoIG1hdGNoaW5nIHV1aWQgJ2YzMWU5YjQ3LWE2NzYtNDE1MS1i Y2JkLWMzOWNhYjc1OTgwNycuCjIwMTQtMDMtMTIgMTE6MzQ6MzcsNjk3IElORk8gIFtvcmcub3Zp cnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZF0gKERl ZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTExKSBTVEFSVCwgRGVzdHJveVZEU0NvbW1hbmQo SG9zdE5hbWUgPSBwYzAwMS5sYW4sIEhvc3RJZCA9IDU0YTA1NzM0LTJiMjMtNDNhOC1hMjRmLWY2 MmYyOTdmYTg4NCwgdm1JZD00YWQ0ZDI2OC04NDg3LTRhZDMtYTIxZC1lYzllYTI4NGQ1YzYsIGZv cmNlPWZhbHNlLCBzZWNvbmRzVG9XYWl0PTAsIGdyYWNlZnVsbHk9ZmFsc2UpLCBsb2cgaWQ6IDk1 YTBlZGMKMjAxNC0wMy0xMiAxMTozNDozNyw3MDggRVJST1IgW29yZy5vdmlydC5lbmdpbmUuY29y ZS52ZHNicm9rZXIudmRzYnJva2VyLkRlc3Ryb3lWRFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0elNj aGVkdWxlcl9Xb3JrZXItMTEpIEZhaWxlZCBpbiBEZXN0cm95VkRTIG1ldGhvZAoyMDE0LTAzLTEy IDExOjM0OjM3LDcwOSBFUlJPUiBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNi cm9rZXIuRGVzdHJveVZEU0NvbW1hbmRdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci0x MSkgRXJyb3IgY29kZSB1bmV4cGVjdGVkIGFuZCBlcnJvciBtZXNzYWdlIFZEU0dlbmVyaWNFeGNl cHRpb246IFZEU0Vycm9yRXhjZXB0aW9uOiBGYWlsZWQgdG8gRGVzdHJveVZEUywgZXJyb3IgPSBV bmV4cGVjdGVkIGV4Y2VwdGlvbgoyMDE0LTAzLTEyIDExOjM0OjM3LDcwOSBJTkZPICBbb3JnLm92 aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVzdHJveVZEU0NvbW1hbmRdIChE ZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci0xMSkgQ29tbWFuZCBvcmcub3ZpcnQuZW5naW5l LmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZCByZXR1cm4gdmFsdWUg CiBTdGF0dXNPbmx5UmV0dXJuRm9yWG1sUnBjIFttU3RhdHVzPVN0YXR1c0ZvclhtbFJwYyBbbUNv ZGU9MTYsIG1NZXNzYWdlPVVuZXhwZWN0ZWQgZXhjZXB0aW9uXV0KMjAxNC0wMy0xMiAxMTozNDoz Nyw3MTAgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIudmRzYnJva2VyLkRl c3Ryb3lWRFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItMTEpIEhvc3RO YW1lID0gcGMwMDEubGFuCjIwMTQtMDMtMTIgMTE6MzQ6MzcsNzExIEVSUk9SIFtvcmcub3ZpcnQu ZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZF0gKERlZmF1 bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTExKSBDb21tYW5kIERlc3Ryb3lWRFMgZXhlY3V0aW9u IGZhaWxlZC4gRXhjZXB0aW9uOiBWRFNFcnJvckV4Y2VwdGlvbjogVkRTR2VuZXJpY0V4Y2VwdGlv bjogVkRTRXJyb3JFeGNlcHRpb246IEZhaWxlZCB0byBEZXN0cm95VkRTLCBlcnJvciA9IFVuZXhw ZWN0ZWQgZXhjZXB0aW9uCjIwMTQtMDMtMTIgMTE6MzQ6MzcsNzEyIElORk8gIFtvcmcub3ZpcnQu ZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZF0gKERlZmF1 bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTExKSBGSU5JU0gsIERlc3Ryb3lWRFNDb21tYW5kLCBs b2cgaWQ6IDk1YTBlZGMKMjAxNC0wMy0xMiAxMTozNDozNyw3MjAgSU5GTyAgW29yZy5vdmlydC5l bmdpbmUuY29yZS5kYWwuZGJicm9rZXIuYXVkaXRsb2doYW5kbGluZy5BdWRpdExvZ0RpcmVjdG9y XSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItMTEpIENvcnJlbGF0aW9uIElEOiBudWxs LCBDYWxsIFN0YWNrOiBudWxsLCBDdXN0b20gRXZlbnQgSUQ6IC0xLCBNZXNzYWdlOiBWTSBUZXN0 SW1wb3J0S1ZNIGlzIGRvd24uIEV4aXQgbWVzc2FnZTogRG9tYWluIG5vdCBmb3VuZDogbm8gZG9t YWluIHdpdGggbWF0Y2hpbmcgdXVpZCAnNGFkNGQyNjgtODQ4Ny00YWQzLWEyMWQtZWM5ZWEyODRk NWM2Jy4KMjAxNC0wMy0xMiAxMTozNDozNyw3MjIgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29y ZS52ZHNicm9rZXIudmRzYnJva2VyLkRlc3Ryb3lWRFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0elNj aGVkdWxlcl9Xb3JrZXItMTEpIFNUQVJULCBEZXN0cm95VkRTQ29tbWFuZChIb3N0TmFtZSA9IHBj MDAxLmxhbiwgSG9zdElkID0gNTRhMDU3MzQtMmIyMy00M2E4LWEyNGYtZjYyZjI5N2ZhODg0LCB2 bUlkPTYzN2Q2YTNhLWMxMGQtNDI1NS1hZDJkLWNjZjI5NzBmZjIwMSwgZm9yY2U9ZmFsc2UsIHNl Y29uZHNUb1dhaXQ9MCwgZ3JhY2VmdWxseT1mYWxzZSksIGxvZyBpZDogNDYyNzQzMjcKMjAxNC0w My0xMiAxMTozNDozNyw3MzMgRVJST1IgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIu dmRzYnJva2VyLkRlc3Ryb3lWRFNDb21tYW5kXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3Jr ZXItMTEpIEZhaWxlZCBpbiBEZXN0cm95VkRTIG1ldGhvZAoyMDE0LTAzLTEyIDExOjM0OjM3LDcz MyBFUlJPUiBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVzdHJv eVZEU0NvbW1hbmRdIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci0xMSkgRXJyb3IgY29k ZSB1bmV4cGVjdGVkIGFuZCBlcnJvciBtZXNzYWdlIFZEU0dlbmVyaWNFeGNlcHRpb246IFZEU0Vy cm9yRXhjZXB0aW9uOiBGYWlsZWQgdG8gRGVzdHJveVZEUywgZXJyb3IgPSBVbmV4cGVjdGVkIGV4 Y2VwdGlvbgoyMDE0LTAzLTEyIDExOjM0OjM3LDczNCBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5j b3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuRGVzdHJveVZEU0NvbW1hbmRdIChEZWZhdWx0UXVhcnR6 U2NoZWR1bGVyX1dvcmtlci0xMSkgQ29tbWFuZCBvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJv a2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZCByZXR1cm4gdmFsdWUgCiBTdGF0dXNPbmx5 UmV0dXJuRm9yWG1sUnBjIFttU3RhdHVzPVN0YXR1c0ZvclhtbFJwYyBbbUNvZGU9MTYsIG1NZXNz YWdlPVVuZXhwZWN0ZWQgZXhjZXB0aW9uXV0KMjAxNC0wMy0xMiAxMTozNDozNyw3MzUgSU5GTyAg W29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIudmRzYnJva2VyLkRlc3Ryb3lWRFNDb21t YW5kXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItMTEpIEhvc3ROYW1lID0gcGMwMDEu bGFuCjIwMTQtMDMtMTIgMTE6MzQ6MzcsNzM1IEVSUk9SIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUu dmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZF0gKERlZmF1bHRRdWFydHpTY2hl ZHVsZXJfV29ya2VyLTExKSBDb21tYW5kIERlc3Ryb3lWRFMgZXhlY3V0aW9uIGZhaWxlZC4gRXhj ZXB0aW9uOiBWRFNFcnJvckV4Y2VwdGlvbjogVkRTR2VuZXJpY0V4Y2VwdGlvbjogVkRTRXJyb3JF eGNlcHRpb246IEZhaWxlZCB0byBEZXN0cm95VkRTLCBlcnJvciA9IFVuZXhwZWN0ZWQgZXhjZXB0 aW9uCjIwMTQtMDMtMTIgMTE6MzQ6MzcsNzM2IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUu dmRzYnJva2VyLnZkc2Jyb2tlci5EZXN0cm95VkRTQ29tbWFuZF0gKERlZmF1bHRRdWFydHpTY2hl ZHVsZXJfV29ya2VyLTExKSBGSU5JU0gsIERlc3Ryb3lWRFNDb21tYW5kLCBsb2cgaWQ6IDQ2Mjc0 MzI3CjIwMTQtMDMtMTIgMTE6MzQ6MzcsNzQ1IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUu ZGFsLmRiYnJva2VyLmF1ZGl0bG9naGFuZGxpbmcuQXVkaXRMb2dEaXJlY3Rvcl0gKERlZmF1bHRR dWFydHpTY2hlZHVsZXJfV29ya2VyLTExKSBDb3JyZWxhdGlvbiBJRDogbnVsbCwgQ2FsbCBTdGFj azogbnVsbCwgQ3VzdG9tIEV2ZW50IElEOiAtMSwgTWVzc2FnZTogVk0gbWF2bTIgaXMgZG93bi4g RXhpdCBtZXNzYWdlOiBEb21haW4gbm90IGZvdW5kOiBubyBkb21haW4gd2l0aCBtYXRjaGluZyB1 dWlkICc2MzdkNmEzYS1jMTBkLTQyNTUtYWQyZC1jY2YyOTcwZmYyMDEnLgoyMDE0LTAzLTEyIDEx OjM0OjM3LDc0OSBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci5WZHNVcGRh dGVSdW5UaW1lSW5mb10gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTExKSBSZWZyZXNo Vm1MaXN0IHZtIGlkIDc4MDJkYTEzLTdjZDQtNGMxYi05NjZmLTgzOTAyNmY3YTEyNSBzdGF0dXMg PSBEb3duIG9uIHZkcyBwYzAwMS5sYW4gaWdub3JpbmcgaXQgaW4gdGhlIHJlZnJlc2ggdW50aWwg bWlncmF0aW9uIGlzIGRvbmUKMjAxNC0wMy0xMiAxMTozNDozNyw3NTEgSU5GTyAgW29yZy5vdmly dC5lbmdpbmUuY29yZS52ZHNicm9rZXIuVmRzVXBkYXRlUnVuVGltZUluZm9dIChEZWZhdWx0UXVh cnR6U2NoZWR1bGVyX1dvcmtlci0xMSkgUmVmcmVzaFZtTGlzdCB2bSBpZCAxN2I5ZGZjMi01OTVl LTQ1NGItYTUyOC1iNDM3MTExMzg1MmQgc3RhdHVzID0gRG93biBvbiB2ZHMgcGMwMDEubGFuIGln bm9yaW5nIGl0IGluIHRoZSByZWZyZXNoIHVudGlsIG1pZ3JhdGlvbiBpcyBkb25lCjIwMTQtMDMt MTIgMTE6MzQ6MzcsNzUyIElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLlZk c1VwZGF0ZVJ1blRpbWVJbmZvXSAoRGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItMTEpIFJl ZnJlc2hWbUxpc3Qgdm0gaWQgYjM5YzcwNGYtNTk0MC00NjVlLTlkMzEtMjZkMmI5OGMzYzU0IHN0 YXR1cyA9IERvd24gb24gdmRzIHBjMDAxLmxhbiBpZ25vcmluZyBpdCBpbiB0aGUgcmVmcmVzaCB1 bnRpbCBtaWdyYXRpb24gaXMgZG9uZQoyMDE0LTAzLTEyIDExOjM0OjM3LDc1NCBJTkZPICBbb3Jn Lm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci5WZHNVcGRhdGVSdW5UaW1lSW5mb10gKERlZmF1 bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTExKSBSZWZyZXNoVm1MaXN0IHZtIGlkIGYzMWU5YjQ3 LWE2NzYtNDE1MS1iY2JkLWMzOWNhYjc1OTgwNyBzdGF0dXMgPSBEb3duIG9uIHZkcyBwYzAwMS5s YW4gaWdub3JpbmcgaXQgaW4gdGhlIHJlZnJlc2ggdW50aWwgbWlncmF0aW9uIGlzIGRvbmUKMjAx NC0wMy0xMiAxMTozNDozNyw3NTUgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9r ZXIuVmRzVXBkYXRlUnVuVGltZUluZm9dIChEZWZhdWx0UXVhcnR6U2NoZWR1bGVyX1dvcmtlci0x MSkgUmVmcmVzaFZtTGlzdCB2bSBpZCA0YWQ0ZDI2OC04NDg3LTRhZDMtYTIxZC1lYzllYTI4NGQ1 YzYgc3RhdHVzID0gRG93biBvbiB2ZHMgcGMwMDEubGFuIGlnbm9yaW5nIGl0IGluIHRoZSByZWZy ZXNoIHVudGlsIG1pZ3JhdGlvbiBpcyBkb25lCjIwMTQtMDMtMTIgMTE6MzQ6MzcsNzU3IElORk8g IFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLlZkc1VwZGF0ZVJ1blRpbWVJbmZvXSAo RGVmYXVsdFF1YXJ0elNjaGVkdWxlcl9Xb3JrZXItMTEpIFJlZnJlc2hWbUxpc3Qgdm0gaWQgNjM3 ZDZhM2EtYzEwZC00MjU1LWFkMmQtY2NmMjk3MGZmMjAxIHN0YXR1cyA9IERvd24gb24gdmRzIHBj MDAxLmxhbiBpZ25vcmluZyBpdCBpbiB0aGUgcmVmcmVzaCB1bnRpbCBtaWdyYXRpb24gaXMgZG9u ZQoyMDE0LTAzLTEyIDExOjM0OjM4LDg4NyBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmRh bC5kYmJyb2tlci5Qb3N0Z3Jlc0RiRW5naW5lRGlhbGVjdCRQb3N0Z3Jlc0pkYmNUZW1wbGF0ZV0g KERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTEyKSBBZGRlZCBkZWZhdWx0IFNxbFJldHVy blJlc3VsdFNldCBwYXJhbWV0ZXIgbmFtZWQgI3Jlc3VsdC1zZXQtMQoyMDE0LTAzLTEyIDExOjM0 OjM4LDg5NSBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmRhbC5kYmJyb2tlci5Qb3N0Z3Jl c0RiRW5naW5lRGlhbGVjdCRQb3N0Z3Jlc0pkYmNUZW1wbGF0ZV0gKERlZmF1bHRRdWFydHpTY2hl ZHVsZXJfV29ya2VyLTEyKSBBZGRlZCBkZWZhdWx0IFNxbFJldHVyblJlc3VsdFNldCBwYXJhbWV0 ZXIgbmFtZWQgI3Jlc3VsdC1zZXQtMQoyMDE0LTAzLTEyIDExOjM0OjM4LDk3MCBJTkZPICBbb3Jn Lm92aXJ0LmVuZ2luZS5jb3JlLmRhbC5kYmJyb2tlci5Qb3N0Z3Jlc0RiRW5naW5lRGlhbGVjdCRQ b3N0Z3Jlc0pkYmNUZW1wbGF0ZV0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTEzKSBB ZGRlZCBkZWZhdWx0IFNxbFJldHVyblJlc3VsdFNldCBwYXJhbWV0ZXIgbmFtZWQgI3Jlc3VsdC1z ZXQtMQoyMDE0LTAzLTEyIDExOjM0OjM4LDk3OCBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3Jl LmRhbC5kYmJyb2tlci5Qb3N0Z3Jlc0RiRW5naW5lRGlhbGVjdCRQb3N0Z3Jlc0pkYmNUZW1wbGF0 ZV0gKERlZmF1bHRRdWFydHpTY2hlZHVsZXJfV29ya2VyLTEzKSBBZGRlZCBkZWZhdWx0IFNxbFJl dHVyblJlc3VsdFNldCBwYXJhbWV0ZXIgbmFtZWQgI3Jlc3VsdC1zZXQtMQoK --_004_4C61EFDD7F9C1646BBF252580B27F2A3DB31BEC3FFTHSONEA01CMS1_--

3 3

[Users] Upgrade from 3.4.0-0.9 to 3.4.0-0.12
by Maurice James 12 Mar '14

12 Mar '14

------=_NextPart_000_0001_01CF396C.CAB9F730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I got the following error while trying to upgrade ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35994 psql:upgrade/03_04_0600_event_notification_methods.sql:10: ERROR: column "notification_method" contains null values 2014-03-06 18:33:46 ERROR otopi.context context._executeMethod:161 Failed to execute stage 'Misc configuration': Command '/usr/share/ovirt-engine/dbscripts/upgrade.sh' failed to execute psql:/var/lib/ovirt-engine/backups/engine-20140306183332.9FQBdD.sql:16: ERROR: language "plpgsql" already exists 2014-03-06 18:42:58 ERROR otopi.plugins.ovirt_engine_common.base.core.misc misc._terminate:150 Execution of setup failed ------=_NextPart_000_0001_01CF396C.CAB9F730 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-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META = HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 15 = (filtered medium)"><style></style></head><body lang=3DEN-US = link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1>I got the following error while trying to = upgrade<o:p></o:p><o:p> </o:p>;; ->>HEADER<<- opcode: QUERY, status: = NOERROR, id: 35994<o:p></o:p>psql:upgrade/03_04_0600_event_notification_methods.sql:= 10: ERROR:  column "notification_method" contains null = values<o:p></o:p>2014-03-06 18:33:46 ERROR = otopi.context context._executeMethod:161 Failed to execute stage 'Misc = configuration': Command '/usr/share/ovirt-engine/dbscripts/upgrade.sh' = failed to execute<o:p></o:p>psql:/var/lib/ovirt-engine/backups/engine-2014030618333= 2.9FQBdD.sql:16: ERROR:  language "plpgsql" already = exists<o:p></o:p>2014-03-06 18:42:58 ERROR = otopi.plugins.ovirt_engine_common.base.core.misc misc._terminate:150 = Execution of setup failed<o:p></o:p></div></body></html> ------=_NextPart_000_0001_01CF396C.CAB9F730--

4 5

[Users] Nodes lose storage at random
by Johan Kooijman 12 Mar '14

12 Mar '14

Hi All, We're seeing some weird issues in our ovirt setup. We have 4 nodes connected and an NFS (v3) filestore (FreeBSD/ZFS). Once in a while, it seems at random, a node loses their connection to storage, recovers it a minute later. The other nodes usually don't lose their storage at that moment. Just one, or two at a time. We've setup extra tooling to verify the storage performance at those moments and the availability for other systems. It's always online, just the nodes don't think so. The engine tells me this: 2014-02-18 11:48:03,598 WARN [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (pool-6-thread-48) domain d88764c8-ecc3-4f22-967e-2ce225ac4498:Export in problem. vds: hv5 2014-02-18 11:48:18,909 WARN [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (pool-6-thread-48) domain e9f70496-f181-4c9b-9ecb-d7f780772b04:Data in problem. vds: hv5 2014-02-18 11:48:45,021 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-18) [46683672] Failed to refresh VDS , vds = 66e6aace-e51d-4006-bb2f-d85c2f1fd8d2 : hv5, VDS Network Error, continuing. 2014-02-18 11:48:45,070 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-41) [2ef1a894] Correlation ID: 2ef1a894, Call Stack: null, Custom Event ID: -1, Message: Invalid status on Data Center GS. Setting Data Center status to Non Responsive (On host hv5, Error: Network error during communication with the Host.). The export and data domain live over NFS. There's another domain, ISO, that lives on the engine machine, also shared over NFS. That domain doesn't have any issue at all. Attached are the logfiles for the relevant time period for both the engine server and the node. The node by the way, is a deployment of the node ISO, not a full blown installation. Any clues on where to begin searching? The NFS server shows no issues nor anything in the logs. I did notice that the statd and lockd daemons were not running, but I wonder if that can have anything to do with the issue. -- Met vriendelijke groeten / With kind regards, Johan Kooijman mail(a)johankooijman.com

4 17

[Users] [GSOC][Gerrit] add potential reviewers - questions
by Tomasz Kołek 12 Mar '14

12 Mar '14

This is a multipart message in MIME format. ------=_NextPart_000_0007_01CF3CA3.354BF560 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Hi I'd like to contribute (within GSOC) in idea: Gerrit add potential reviewers. Maybe at first I'll introduce myself. I'm Tomek, student from Poland. I study Computer Science at University of Wroclaw. The next year will be last year of my first degree study, I hope. As a python programmer I'm working since one year at Nokia Solutions and Networks (don't worry I intend to change my job to another or to participation at GSOC). Every day at work and school I'm using version control system (Git and SVN). At work we were using to Gerrit as a review system but currently we're using JIRA to report review statuses. I love spend my free time in mountains (mainly polish - Tatras mountains). That's all about me. I've got a few questions about project description. Please tell me if my problem's understanding is good or not. We need to add a few flags/methods to git review module. This flags should allow to add potential reviewers in gerrit. So: Let's assume that we've got special flags for this operations. What's next? 1. In gerrit system we need to add special place for potential reviewers? 2. Potential reviewers should agree that they want to review? 3. We can have more than one accepted reviewer? I know above questions might seem chaotic but I think answers allow me to better understanding Yours needments Best regards Tomasz Kolek ------=_NextPart_000_0007_01CF3CA3.354BF560 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-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=3DContent-Type content=3D"text/html; = charset=3Diso-8859-2"><meta name=3DGenerator content=3D"Microsoft Word = 14 (filtered medium)"><style></style></head><body lang=3DPL link=3Dblue = vlink=3Dpurple><div class=3DWordSection1>Hi <o:p></o:p>I'd like to contribute (within GSOC) in idea: Gerrit add = potential reviewers. Maybe at first I’ll introduce = myself. I'm Tomek, student from Poland. I study Computer Science at = University of Wroclaw. The next year will be last year of my first = degree study, I hope. As a python programmer I'm working since one = year at Nokia Solutions and Networks (don't worry I intend to change my = job to another or to participation at GSOC). Every day at work and = school I'm using version control system (Git and SVN). At work we were = using to Gerrit as a review system but currently we're using JIRA to = report review statuses. I love spend my free time in mountains = (mainly polish - Tatras mountains). That's all about me. I've = got a few questions about project description. Please tell me if my = problem's understanding is good or not. We need to add a few = flags/methods to git review module. This flags should allow to add = potential reviewers in gerrit. So: Let's assume that we've got = special flags for this operations. What's next? 1. In gerrit system = we need to add special place for potential reviewers? 2. Potential = reviewers should agree that they want to review? 3. We can have more = than one accepted reviewer? I know above questions might seem = chaotic but I think answers allow me to better understanding Yours = needments Best regards Tomasz = Kolek<o:p></o:p></div></body></html> ------=_NextPart_000_0007_01CF3CA3.354BF560--

10 22

[Users] building engine, facing issues.
by aditya mamidwar 12 Mar '14

12 Mar '14

i installed ovirt 3.3 and i need to build the engine for my changes to backend implementation files to take place. The build engine guide on the community says that the procedure is now obsolete for my version. also git clone git://gerrit.ovirt.org/ovirt-engine doenot clone the $OVIRT_HOME/backend/manager/dbscripts. hence i cannot continue with the next steps. -- -Aditya Mamidwar

2 1

[Users] Best practice for securing oVirt's NFS mounts
by Prakash Surya 12 Mar '14

12 Mar '14

Hi, All the documentation I've seen states that the oVirt NFS storage should use the "all_squash,anonuid=36,anongid=36" options. Obviously this isn't secure, so I'm curious how others have locked down their NFS storage? Is the best option to just limit access to these NFS exports to the IP addresses of the hypervisor nodes (and maybe the engine)? Is there a better way to go about this? -- Cheers, Prakash

3 4

[Users] oVirt Weekly Meeting Minutes -- 2014-03-12
by Brian Proffitt 12 Mar '14

12 Mar '14

Minutes: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-03-12-15.00.html Minutes (text): http://ovirt.org/meetings/ovirt/2014/ovirt.2014-03-12-15.00.txt Log: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-03-12-15.00.log.html ========================= #ovirt: oVirt Weekly Sync ========================= Meeting started by bkp at 15:00:26 UTC (full logs at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-03-12-15.00.log.html) Meeting summary * Agenda and roll Call (bkp, 15:01:27) ** infra update (bkp, 15:01:27) ** 3.3 update releases (bkp, 15:01:27) ** 3.4 progress (bkp, 15:01:27) ** conferences and workshops (bkp, 15:01:27) ** other topics (bkp, 15:01:29) * infra update (bkp, 15:03:11) ** infra Space improvements on jobs performed on slaves (bkp, 15:10:11) ** infra Jobs modified to filter out infra issues from devel issues (bkp, 15:10:41) ** infra some jobs will start to verify -1 some patches when 'Unstable', meaning a devel error was found and it must be solved prior to merge (bkp, 15:11:18) * 3.3 releases update (bkp, 15:11:34) ** 3.3.4 released last week (bkp, 15:12:22) ** 3.3.5 development started (bkp, 15:12:32) ** http://www.ovirt.org/OVirt_3.3.z_release-management links to tracker, release note place holder and test page (bkp, 15:13:07) * 3.4 progress (bkp, 15:14:56) ** 3.4.0 RC2 released yesterday (bkp, 15:15:28) ** 3.4 GA postponed by one week giving people more time for testing latest bug fix introduced since test day (bkp, 15:16:10) ** 3.4 updates Networking. No blockers in GA build (fixes made it into build). (bkp, 15:21:03) ** 3.4 updates, UX. No updates. (bkp, 15:25:07) ** 3.4 updates Storage. All set for 3.4, handling incoming BZs as they come. (bkp, 15:30:35) ** 3.4 updates Storage. Considering backport of REST API for snapshots from 3.5 to 3.4, so that Single Disk Snapshots (a 3.4 RFE) would be easier to test (bkp, 15:31:30) ** 3.4 updates Storage. REST API backport for 3.4.1 presumably. It's already merged in the master branch (the upcoming 3.5), still need to verify how much of a mess a backport would be. (bkp, 15:32:04) ** 3.4 updates PPC. Some bugs, non-blockers. PPC64 is ok for 3.4, considering release notes for it (bkp, 15:37:14) ** 3.4 updates PPC. Will confirm VDSM compatability on Fedora and CentOS and will report back. (bkp, 15:40:33) ** 3.4 updates Integration. Users are reporting issues while running setup on x86_64, seeing i686 packages being installed (investigating) (bkp, 15:42:30) ** 3.4 updates Integration. Stabilizing RC for next week GA (bkp, 15:42:50) ** 3.4 updates Gluster. Ramesh has sent a WIP patch for external events actions (bkp, 15:44:46) ** 3.4 updates SLA. No team member reporting. (bkp, 15:48:03) ** 3.4 updates Infra. No team member reporting. (bkp, 15:48:10) ** 3.4 updates Virt. No team member reporting. (bkp, 15:48:16) * conferences and workshops (bkp, 15:48:52) ** Weekly conference and call-for-papers mail going out on [users] and [arch] (bkp, 15:50:14) ** Community: Building a library of content for presentations, starting with topics. Feedback welcome (bkp, 15:50:39) * other topics (bkp, 15:51:02) ** Press release and release notes are ready for 3.4. (bkp, 15:53:21) ** New Download page ready for publication at 3.4 release. Review page at http://www.ovirt.org/DraftDownload (bkp, 15:53:29) ** Web site revamp is in order. Planning meetings on IRC coming. (bkp, 15:53:46) Meeting ended at 15:54:54 UTC (full logs). Action items (none) People present (lines said) bkp (95) sbonazzo (18) lvernia (7) lbianc (6) amureini (5) shubhendu (4) dcaro (4) Psi-Jack (2) ecohen (2) ovirtbot (2) sbonazzo1 (1) rbarry (1) fabiand (1) Generated by MeetBot 0.1.4. -- Brian Proffitt - oVirt Community Manager Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 312 477 4320 / Cell: +1 574 383 9BKP IRC: bkp

1 0

[Users] Win8 on oVirt
by Michael Wagenknecht 12 Mar '14

12 Mar '14

Hi, I try to install Windows 8 32 bit on our oVirt 3.3.2 environmet. I googled that two CPU Flags (SEP and NX) have to be set. But I cannot manipulate the CPU Flags in the GUI. Is there an other way to set the SEP and NX Flags for the VM? Best Regards, Michael

6 28

[Users] ovirt engine in high availability
by Gianluca Cecchi 12 Mar '14

12 Mar '14

Hello, I have made a base testing environment putting engine in HA. I think it could complement self hosted engine. As this could be of interest for enterprise based installations, I used CentOS 6.5 as OS environment for engine. Even if in upcoming RH EL 7 it seems corosync will substitute cman, in this 6.5 test I have used cman/pacemaker with pcs commands. The engine servers are two vSphere VMs, so I tested the configuration both without stonith and with vSphere CLi sdk and fence_vmware fenging agent. Also, as this kind of environment could be suitable for DR too, I set up the filesystem resource with drbd in active/passive. There are many possible configurations; to stick with similar environment as the standalone engine, I configured the whole stack of resources in one group, also with the nfs share for the default ISO-DOMAIN. Actually in this kind of environment it would be preferable to have a dedicated nfs resource on another ip so that it doesn't influence the ovirt-engine resource that is more critical. In the same way one could choose to put the PostgreSQL resource as a separate one, optimizing and balancing nodes' utilization. At the moment I successfully tested on ovirt-engine-3.3.3-2.el6.noarch and I have not yet configured any hypervisor hosts. I will do next days. I plan to test also upgrades to 3.3.4 and 3.4.0, to see if maintenance activity would reveal too complex and be a show stopper. In the mean time what I tested to be transparent with a client session connected to webadmin portal is: - relocation of resources - power off of the passive node - power off of the master node With transparent I mean that in the same browser window the user gets the login page (the same as when it goes timeout) and after login it gets the same situation as before. Obviously the PostgreSQL rdbms has stopped (or crashed in third case) and so problems could arise as if you stopped your db or powered off your server in single server environment. If there is interest I can post my configuration steps into a wiki page on oVirt web site (after learning the formatting syntax... ;-).. the page name could be something like "clustered_engine". In the mean time if you have any scenario I can test to verify consistency you are welcome. Gianluca

2 1

[Users] [Events] Call for Papers Update: March 11, 2014
by Brian Proffitt 11 Mar '14

11 Mar '14

The following is a list of industry events that oVirt community members may want to attend and give presentations. If you are interested in speaking, or if you know of other events not on this list, please contact me at bkp(a)redhat.com. --- LinuxCon/CloudOpen Japan May 20-22 Tokyo, Japan http://events.linuxfoundation.org/events/linuxcon-japan Call for papers deadline: 3/14/2014 Call for papers URL: http://events.linuxfoundation.org/events/linuxcon-japan/program/cfp LISA Nov. 9-14 Seattle, WA https://www.usenix.org/conference/lisa14 Call for papers deadline: 4/14/2014 Call for papers URL: https://www.usenix.org/conference/lisa14/call-for-participation DockerConf June 6 London, UK http://dockerconf.com/ Call for papers: Open (deadline not known) Call for papers URL: http://bit.ly/1fnHtSA LinuxCon/CloudOpen NA Aug. 20-22 Chicago, IL http://events.linuxfoundation.org/events/linuxcon-north-america Call for papers deadline: 5/2/2014 Call for papers URL: http://events.linuxfoundation.org/events/linuxcon-north-america/program/cfp LinuxCon/CloudOpen Europe Oct. 13-15 http://events.linuxfoundation.org/events/cloudopen-europe Dusseldorf, Germany Call for papers deadline: 7/11/2014 Call for papers URL: http://events.linuxfoundation.org/events/cloudopen-europe/program/cfp KVM Forum Oct. 14-16 Dusseldorf, Germany http://events.linuxfoundation.org/events/kvm-forum Call for papers: Not Open Linux.conf.au Jan. 12-16, 2015 Auckland, NZ Call for papers: Not Open -- Brian Proffitt - oVirt Community Manager Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 312 477 4320 / Cell: +1 574 383 9BKP IRC: bkp @ OFTC

1 0

[Users] Adding a Second disk to a virtual windows 2008 R2 server
by Andy Michielsen 11 Mar '14

11 Mar '14

Hello, What is the way to go to add a second disk to my virtual windows server 2008R2 ? I'm using ovirt 3.3.3 on a centos 6.5 server. The windows server is in use so I 'm not at liberty to reïnstall a new one without loosing a lot of time. Kind regards.

2 1

[Users] Disk Migration Permissions
by Maurice James 11 Mar '14

11 Mar '14

--_f6cbe220-bf5e-4549-9a1f-326f3df52a07_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What permissions do I need to allow a user to be able to live migrate a dis= k from one storage domain to another? I have a group with the Power User an= d Super user permissions on the cluster and they get the following error wh= en attempting to migrate a disk Error while executing action: User is not authorized to perform this action= . 3.3.3-2.el6 = --_f6cbe220-bf5e-4549-9a1f-326f3df52a07_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style></head> <body class=3D'hmmessage'><div dir=3D'ltr'>What permissions do I need to al= low a user to be able to live migrate a disk from one storage domain to ano= ther? I have a group with the Power User and Super user permissions on the = cluster and they get the following error when attempting to migrate a disk<= div> </div><div>Error while executing action: User is= not authorized to perform this action.</div><div>= </div><div> </div><div>3.3.3-2.el6</div> </= div></body> </html>= --_f6cbe220-bf5e-4549-9a1f-326f3df52a07_--

2 2

[Users] Foreman and oVirt 3.4 fails
by Andrew Lau 11 Mar '14

11 Mar '14

Hi, Is anyone using Foreman with oVirt 3.4? Post upgrade, I appear to be having some issues with Foreman reporting " undefined method `text' for nil:NilClass" I'm not sure if this ends up being a Foreman issue or oVirt, or it could just be my install gone bad.. however last time it was the oVirt API had been updated which caused issues with Foreman so I thought I'd post here first. Thanks, Andrew

3 3