- Users - oVirt List Archives

oVirt Weekly Meeting: Nov. 5, 2014
by Brian Proffitt 05 Nov '14

05 Nov '14

========================= #ovirt: oVirt Weekly Sync ========================= Meeting started by bkp at 15:01:32 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-11-05-15.01.log.html . Meeting summary --------------- * Agenda and roll Call (bkp, 15:01:47) * infra update (bkp, 15:02:07) * 3.5.z updates (bkp, 15:02:08) * 3.6.0 status (bkp, 15:02:08) * conferences and workshops (bkp, 15:02:08) * other topics (bkp, 15:02:10) * infra update (bkp, 15:03:37) * infra update: engine is failing build on master and 3.5 probably due to infra issues (bkp, 15:10:17) * infra update: a bug in F21 rpm package has been solved so failures related to fedora 19 builds on f21 slaves are solved (bkp, 15:10:21) * infra update: some build failures are expected in next days due to missing dependencies on el7 and f21 while building engine for those distributions (bkp, 15:10:24) * 3.5.z updates (bkp, 15:10:37) * 3.5.z updates: 1 blocker around, tiraboschi_ is taking care of it (bkp, 15:16:38) * 3.5.z updates: 181 bugs still outstanding. Maintainers should be taking a look at these now. (bkp, 15:16:39) * 3.5.z updates: trying to get el7 support ready for 3.5.1, we're now working on master for that (bkp, 15:16:42) * 3.6 status (bkp, 15:16:52) * 3.6 status: Release criteria definition in progress, we should reach a decision by next week's meeting according to release process (bkp, 15:24:51) * 3.6 status: Specifically, should we keep the existing 3.5 criteria for 3.6, or add these changes http://lists.ovirt.org/pipermail/devel/2014-September/008695.html? (bkp, 15:24:54) * 3.6 status: There is also an ongoing discussion to lengthen the 3.6 release cycle to 10 months and keeping all the proposed features (http://lists.ovirt.org/pipermail/users/2014-November/028875.html) or splitting features across multiple releases. (bkp, 15:24:57) * 3.6 status: Discussion is invited here: http://lists.ovirt.org/pipermail/devel/2014-September/008695.html (bkp, 15:25:01) * 3.6 status: work for fedora 21 support for 3.6 is ongoing as well as the el7 support (bkp, 15:26:47) * conferences and workshops (bkp, 15:28:29) * OpenStack Summit is going on now in Paris. Red Hat has a sharp presence there, and oVirt should be getting attention via a video demo at the Red Hat/RDO booth. (bkp, 15:28:44) * LISA'14 will be next week, and we'll have a big footprint there with oVirt at LISA Lab and at the Red Hat booth. (bkp, 15:28:47) * Planning is ongoing for FOSDEM on Jan. 31-Feb 1. Get your submittals in for the IaaS and Virt devrooms soon! (bkp, 15:28:50) * other topics (bkp, 15:30:53) * bkp will be opening a discussion on the [users] mailing list to best figure out how to position oVirt and RDO. (bkp, 15:31:29) * A reminder: this week not withstanding, the oVirt weekly syncs will be at 1400 UTC (one hour earlier than when we started this week). Please adjust your calendars accordingly. (bkp, 15:31:47) Meeting ended at 15:35:24 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * bkp (53) * sbonazzo (31) * lvernia (10) * YamakasY (4) * DougBishop (4) * awels (3) * afics_ (3) * ovirtbot (2) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Brian Proffitt Community Liaison oVirt Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC

1 0

[QE][ACTION REQUIRED] oVirt 3.6.0 status
by Sandro Bonazzola 05 Nov '14

05 Nov '14

Hi, Release criteria discussion started on 2014-10-22 and should end on 2014-11-12 as per current release process [1]. Current options are: 1) keeping the same release criteria we had for 3.5 [2] 2) review the proposed changes [3] and prepare new release criteria for 3.6 Release management for 3.6.0 has been created [4] The key milestones for this release must be scheduled: Key Milestones Release criteria discussion start: 2014-10-22 Release criteria ready: 2014-11-12 Feature freeze: 60 Days before release First Test Day: 45 days before release Release Candidate: 30 days before release Release: 6 months after oVirt 3.5.0 release Two different proposals have been meed about above scheduling [5]: 1) extend the cycle to 10 months for allowing to include a large feature set 2) reduce the cycle to less than 6 months and split features over 3.6 and 3.7 A tracker bug for 3.6.0 has been created [6] and currently shows no blockers. There are 395 bugs [7] targeted to 3.6.0. Excluding node and documentation bugs we have 375 bugs [8] targeted to 3.6.0. [1] http://www.ovirt.org/Release_process [2] http://www.ovirt.org/OVirt_3.5_release-management#Release_Criteria [3] http://lists.ovirt.org/pipermail/devel/2014-September/008695.html [4] http://www.ovirt.org/OVirt_3.6_Release_Management [5] http://lists.ovirt.org/pipermail/users/2014-November/028875.html [6] https://bugzilla.redhat.com/show_bug.cgi?id=1155425 [7] http://goo.gl/zwkF3r [8] http://goo.gl/ZbUiMc -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

Re: [ovirt-users] Import FC Storage as iSCSI
by Raul Laansoo 05 Nov '14

05 Nov '14

------=_Part_2362972_479624645.1415087866734 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi. I have managed to get my oVirt node running using oVirt Node Hypervisor 3.1.0_master-20140707.0. I hope this is not causing following issue, but this Is the only way for me to test 3.5. When I try to import existing FC storage domain I get errors on Engine (see attached log). Regards. Raul ----- Original Message ----- > From: "Raul Laansoo" <raul.laansoo(a)bigbank.ee> > To: "Maor Lipchuk" <mlipchuk(a)redhat.com> > Sent: Monday, 27 October, 2014 11:29:40 AM > Subject: Re: [ovirt-users] Import FC Storage as iSCSI > > I have set this to 3.4 because I still use ovirt-node-iso from oVirt 3.4. For > some reason I can't set cluster compatibility to 3.4 and with cluster 3.5 > node installation fails. I will install node from 3.5 iso and try again. > > ----- Original Message ----- > > From: "Maor Lipchuk" <mlipchuk(a)redhat.com> > > To: "Raul Laansoo" <raul.laansoo(a)bigbank.ee> > > Cc: "users" <users(a)ovirt.org> > > Sent: Monday, 27 October, 2014 10:50:21 AM > > Subject: Re: [ovirt-users] Import FC Storage as iSCSI > > > > Which Data Center version are you using to attach the Storage Domain to? > > If the storage domain meta data indicates that it is already attached to > > another Data Center (after DR for example). then you the attach of it will > > only be supported for Data Center 3.5. > > > > Regards, > > Maor > > > > ----- Original Message ----- > > > From: "Raul Laansoo" <raul.laansoo(a)bigbank.ee> > > > To: "Maor Lipchuk" <mlipchuk(a)redhat.com> > > > Cc: "users" <users(a)ovirt.org> > > > Sent: Monday, October 27, 2014 10:07:18 AM > > > Subject: Re: [ovirt-users] Import FC Storage as iSCSI > > > > > > When I try to import existing FC storage domain, which consists of two > > > NetAPP > > > LUN-s cloned from NetAPP snapshots, I get: > > > > > > Error while executing action Attach Storage Domain: The Domain is already > > > used by another Data Center. > > > In order to use it, detach it from the Data Center it is currently > > > attached > > > to. > > > > > > Does this mean, that to import existing storage domain, it must be first > > > (cleanly) detached? > > > > > > Regards. > > > > > > ----- Original Message ----- > > > > From: "Maor Lipchuk" <mlipchuk(a)redhat.com> > > > > To: "Raul Laansoo" <raul.laansoo(a)bigbank.ee> > > > > Cc: "users" <users(a)ovirt.org> > > > > Sent: Monday, 27 October, 2014 9:26:50 AM > > > > Subject: Re: [ovirt-users] Import FC Storage as iSCSI > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Raul Laansoo" <raul.laansoo(a)bigbank.ee> > > > > > To: "Maor Lipchuk" <mlipchuk(a)redhat.com> > > > > > Cc: "users" <users(a)ovirt.org> > > > > > Sent: Monday, October 27, 2014 8:43:31 AM > > > > > Subject: Re: [ovirt-users] Import FC Storage as iSCSI > > > > > > > > > > Hi. > > > > > > > > > > Thank you for looking into this. Does this only affect the import or > > > > > influences also the process of attaching storage domain to Data > > > > > Center > > > > > (you > > > > > can't attach iSCSI Storage Domain to FC DC and vice versa?) > > > > > > > > Hi Raul, > > > > > > > > for now, the fix should include the ability to "switch" storage types > > > > only > > > > through the import process,and not through the attach process. > > > > I think that the import process might be enough because you can always > > > > remove > > > > the Storage Domain and re-import it to the setup as another storage > > > > type. > > > > > > > > > If I understand > > > > > correctly, the Data Center's storage type is set at the > > > > > initialization > > > > > time, > > > > > when the first storage domain is attached and you can't change it > > > > > afterwards. In previous versions you could clearly see the DC storage > > > > > type, > > > > > now it's not visible. > > > > > > > > You are right, mixed type data center is a feature introduced in > > > > version > > > > 3.4 > > > > (see http://www.ovirt.org/Features/Mixed_Types_Data_Center) > > > > There should be only two type of Data Center local and shared. > > > > The import Storage Domain feature is supported only from version 3.5 so > > > > it > > > > can only be supported in mixed type Data Centers. > > > > > > > > > > > > > > > > > > Regards. > > > > > Raul > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Maor Lipchuk" <mlipchuk(a)redhat.com> > > > > > > To: "Itamar Heim" <iheim(a)redhat.com> > > > > > > Cc: "raul laansoo" <raul.laansoo(a)bigbank.ee>, "Vered Volansky" > > > > > > <vered(a)redhat.com>, "users" <users(a)ovirt.org> > > > > > > Sent: Monday, 27 October, 2014 2:16:14 AM > > > > > > Subject: Re: [ovirt-users] Import FC Storage as iSCSI > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > From: "Itamar Heim" <iheim(a)redhat.com> > > > > > > > To: "Maor Lipchuk" <mlipchuk(a)redhat.com>, "raul laansoo" > > > > > > > <raul.laansoo(a)bigbank.ee> > > > > > > > Cc: "Vered Volansky" <vered(a)redhat.com>, "users" > > > > > > > <users(a)ovirt.org> > > > > > > > Sent: Sunday, October 26, 2014 9:34:14 PM > > > > > > > Subject: Re: [ovirt-users] Import FC Storage as iSCSI > > > > > > > > > > > > > > On 10/26/2014 03:58 PM, Maor Lipchuk wrote: > > > > > > > > Hi Raul, > > > > > > > > > > > > > > > > The storage domain type is determined from the Storage Domain > > > > > > > > meta > > > > > > > > data. > > > > > > > > If your storage domain was previously an FC Storage Domain, the > > > > > > > > import > > > > > > > > process will read this from the meta data and import it as an > > > > > > > > FC > > > > > > > > Storage > > > > > > > > Domain. > > > > > > > > > > > > > > > > This behavior should be changed so the storage type will be > > > > > > > > determined > > > > > > > > by > > > > > > > > the user instead from the meta data, > > > > > > > > I've opened a bug on this issue for 3.5, > > > > > > > > https://bugzilla.redhat.com/1157240. > > > > > > > > > > > > > > so i guess for now the metadata can be changed as a workaround? > > > > > > > > > > > > I believe so, > > > > > > I've tried now to import an existing iSCSI Storage Domain after > > > > > > changing > > > > > > its > > > > > > meta data from ISCSI to FCP and it seems to work well, the Storage > > > > > > was > > > > > > imported as Fibre Channel. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > Maor > > > > > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Allon Mureinik" <amureini(a)redhat.com> > > > > > > > > To: "Maor Lipchuk" <mlipchuk(a)redhat.com> > > > > > > > > Cc: "Vered Volansky" <vered(a)redhat.com>, "users" > > > > > > > > <users(a)ovirt.org>, > > > > > > > > "Raul > > > > > > > > Laansoo" <raul.laansoo(a)bigbank.ee> > > > > > > > > Sent: Sunday, October 26, 2014 10:42:53 AM > > > > > > > > Subject: Re: [ovirt-users] Import FC Storage as iSCSI > > > > > > > > > > > > > > > > Maor, does this ring in bells wrt importing a storage domain? > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > >> From: "Raul Laansoo" <raul.laansoo(a)bigbank.ee> > > > > > > > >> To: "Vered Volansky" <vered(a)redhat.com> > > > > > > > >> Cc: "users" <users(a)ovirt.org> > > > > > > > >> Sent: Thursday, October 23, 2014 4:51:34 PM > > > > > > > >> Subject: Re: [ovirt-users] Import FC Storage as iSCSI > > > > > > > >> > > > > > > > >> Hi. > > > > > > > >> > > > > > > > >> I have done this because this is the only way to access iSCSI > > > > > > > >> target. > > > > > > > >> But > > > > > > > >> after import it shows up as FC (the original storage domain > > > > > > > >> type). > > > > > > > >> Where > > > > > > > >> does this information come from? I have DataCenter setup from > > > > > > > >> about > > > > > > > >> version > > > > > > > >> ovirt-engine-3.3.2. > > > > > > > >> > > > > > > > >> Thank you. > > > > > > > >> > > > > > > > >> ----- Original Message ----- > > > > > > > >>> From: "Vered Volansky" <vered(a)redhat.com> > > > > > > > >>> To: "Raul Laansoo" <raul.laansoo(a)bigbank.ee> > > > > > > > >>> Cc: "users" <users(a)ovirt.org> > > > > > > > >>> Sent: Thursday, 23 October, 2014 4:24:12 PM > > > > > > > >>> Subject: Re: [ovirt-users] Import FC Storage as iSCSI > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> ----- Original Message ----- > > > > > > > >>>> From: "Raul Laansoo" <raul.laansoo(a)bigbank.ee> > > > > > > > >>>> To: "users" <users(a)ovirt.org> > > > > > > > >>>> Sent: Thursday, October 23, 2014 10:59:30 AM > > > > > > > >>>> Subject: [ovirt-users] Import FC Storage as iSCSI > > > > > > > >>>> > > > > > > > >>>> Hello. > > > > > > > >>>> > > > > > > > >>>> I have created an FC Storage Domain and made snapshots of > > > > > > > >>>> all > > > > > > > >>>> LUNs > > > > > > > >>>> on > > > > > > > >>>> the > > > > > > > >>>> SAN. Now I want to use those snapshots on another Data > > > > > > > >>>> Center > > > > > > > >>>> over > > > > > > > >>>> iSCSI > > > > > > > >>>> connection to test recovery. I can import the domain, but > > > > > > > >>>> the > > > > > > > >>>> domains > > > > > > > >>>> Storage Type is FC and I can't attach it to host. Is it > > > > > > > >>>> possible > > > > > > > >>>> to > > > > > > > >>>> change > > > > > > > >>>> domain type to iSCSI or some other way to import storage > > > > > > > >>>> domain. > > > > > > > >>> > > > > > > > >>> Just select iSCSI as thetype when you import it. This is the > > > > > > > >>> type > > > > > > > >>> of > > > > > > > >>> the > > > > > > > >>> new > > > > > > > >>> domain. > > > > > > > >>> > > > > > > > >>> Vered > > > > > > > >>> > > > > > > > >>>> > > > > > > > >>>> Thank you. > > > > > > > >>>> > > > > > > > >>>> Raul > > > > > > > >>>> _______________________________________________ > > > > > > > >>>> Users mailing list > > > > > > > >>>> Users(a)ovirt.org > > > > > > > >>>> http://lists.ovirt.org/mailman/listinfo/users > > > > > > > >>>> > > > > > > > >>> > > > > > > > >> _______________________________________________ > > > > > > > >> Users mailing list > > > > > > > >> Users(a)ovirt.org > > > > > > > >> http://lists.ovirt.org/mailman/listinfo/users > > > > > > > >> > > > > > > > > _______________________________________________ > > > > > > > > Users mailing list > > > > > > > > Users(a)ovirt.org > > > > > > > > http://lists.ovirt.org/mailman/listinfo/users > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------=_Part_2362972_479624645.1415087866734 Content-Type: text/x-log; name=engine.log Content-Disposition: attachment; filename=engine.log Content-Transfer-Encoding: base64 MjAxNC0xMS0wNCAwOTo0NzowNywzODcgSU5GTyAgW29yZy5vdmlydC52ZHNtLmpzb25ycGMuY2xp ZW50LnJlYWN0b3JzLlJlYWN0b3JDbGllbnRdIChTU0wgU3RvbXAgUmVhY3RvcikgQ29ubmVjdGlu ZyB0byAvMTkyLjE2OC4xMDAuMjM1CjIwMTQtMTEtMDQgMDk6NDc6MTQsNDUxIElORk8gIFtvcmcu b3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5HZXREZXZpY2VMaXN0VkRTQ29t bWFuZF0gKGFqcC0tMTI3LjAuMC4xLTg3MDItMSkgU1RBUlQsIEdldERldmljZUxpc3RWRFNDb21t YW5kKEhvc3ROYW1lID0gZW5jMC1ibDYuZXhhbXBsZS5jb20sIEhvc3RJZCA9IDNjMTAyYTA1LTZl OWQtNDkwYi1hZTgwLTE3MTE2ZTlkNTIyMSwgc3RvcmFnZVR5cGU9RkNQKSwgbG9nIGlkOiA0MzM2 ODQKMjAxNC0xMS0wNCAwOTo0NzoxNiwyNjcgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS52 ZHNicm9rZXIudmRzYnJva2VyLkdldERldmljZUxpc3RWRFNDb21tYW5kXSAoYWpwLS0xMjcuMC4w LjEtODcwMi0xKSBGSU5JU0gsIEdldERldmljZUxpc3RWRFNDb21tYW5kLCByZXR1cm46IFtMVU5z IFtpZD0zNjBhOTgwMDA0MjQzNDE3NDMwMmI0MzRiNmI1NDMzNTQsIHBoeXNpY2FsVm9sdW1lSWQ9 cFNjcXFLLXJtUzAta2k2NS1xRDBNLWhkeE4ta3dXai1sc2lyOWUsIHZvbHVtZUdyb3VwSWQ9bGZn WkQzLWpmVWwtM1VyOC1sUzNpLThabjctcVBtZC1ZdlZycjksIHNlcmlhbD1TTkVUQVBQX0xVTl9C Q0F0MCtDS2tUM1QsIGx1bk1hcHBpbmc9NSwgdmVuZG9ySWQ9TkVUQVBQLCBwcm9kdWN0SWQ9TFVO LCBfbHVuQ29ubmVjdGlvbnM9W10sIGRldmljZVNpemU9NTAwLCB2ZW5kb3JOYW1lPU5FVEFQUCwg cGF0aHNEaWN0aW9uYXJ5PXtzZHg9dHJ1ZSwgc2RkPXRydWUsIHNkdD10cnVlLCBzZGg9dHJ1ZSwg c2RhYj10cnVlLCBzZGw9dHJ1ZSwgc2RhZj10cnVlLCBzZHA9dHJ1ZX0sIGx1blR5cGU9VU5LTk9X Tiwgc3RhdHVzPVVzZWQsIGRpc2tJZD1udWxsLCBkaXNrQWxpYXM9bnVsbCwgc3RvcmFnZURvbWFp bklkPW51bGwsIHN0b3JhZ2VEb21haW5OYW1lPW51bGxdLCBMVU5zIFtpZD0zNjBhOTgwMDA0MjQz NDE3NDMwMmI0MzRiNmI1NDMzNTIsIHBoeXNpY2FsVm9sdW1lSWQ9ZXNacVM4LVRiZFYtcDlIZC12 MnN1LUNqQlctc25EZS0zWnFFamYsIHZvbHVtZUdyb3VwSWQ9bGZnWkQzLWpmVWwtM1VyOC1sUzNp LThabjctcVBtZC1ZdlZycjksIHNlcmlhbD1TTkVUQVBQX0xVTl9CQ0F0MCtDS2tUM1IsIGx1bk1h cHBpbmc9NCwgdmVuZG9ySWQ9TkVUQVBQLCBwcm9kdWN0SWQ9TFVOLCBfbHVuQ29ubmVjdGlvbnM9 W10sIGRldmljZVNpemU9NTAwLCB2ZW5kb3JOYW1lPU5FVEFQUCwgcGF0aHNEaWN0aW9uYXJ5PXtz ZHc9dHJ1ZSwgc2RjPXRydWUsIHNkcz10cnVlLCBzZGc9dHJ1ZSwgc2RhYT10cnVlLCBzZGs9dHJ1 ZSwgc2RhZT10cnVlLCBzZG89dHJ1ZX0sIGx1blR5cGU9VU5LTk9XTiwgc3RhdHVzPVVzZWQsIGRp c2tJZD1udWxsLCBkaXNrQWxpYXM9bnVsbCwgc3RvcmFnZURvbWFpbklkPW51bGwsIHN0b3JhZ2VE b21haW5OYW1lPW51bGxdLCBMVU5zIFtpZD0zNjBhOTgwMDA0MjQzNDE3NDMwMmI0MzRiNmI1NDMy NzksIHBoeXNpY2FsVm9sdW1lSWQ9QzVONFBkLUJ4d28tZ0RPYi1pQ3hYLXM3R2ItWFFBNC1HeTJM alUsIHZvbHVtZUdyb3VwSWQ9NUhiRU9lLUhVWG8tVnFsNy1odnF4LW9BODYtYzdLSy1MQjNhcG4s IHNlcmlhbD1TTkVUQVBQX0xVTl9CQ0F0MCtDS2tUMnksIGx1bk1hcHBpbmc9MSwgdmVuZG9ySWQ9 TkVUQVBQLCBwcm9kdWN0SWQ9TFVOLCBfbHVuQ29ubmVjdGlvbnM9W10sIGRldmljZVNpemU9NTAs IHZlbmRvck5hbWU9TkVUQVBQLCBwYXRoc0RpY3Rpb25hcnk9e3NkYj10cnVlLCBzZHY9dHJ1ZSwg c2RmPXRydWUsIHNkcj10cnVlLCBzZGo9dHJ1ZSwgc2RuPXRydWUsIHNkYWQ9dHJ1ZSwgc2R6PXRy dWV9LCBsdW5UeXBlPVVOS05PV04sIHN0YXR1cz1Vc2VkLCBkaXNrSWQ9bnVsbCwgZGlza0FsaWFz PW51bGwsIHN0b3JhZ2VEb21haW5JZD1udWxsLCBzdG9yYWdlRG9tYWluTmFtZT1udWxsXSwgTFVO cyBbaWQ9MzYwYTk4MDAwNDI0MzQxNzQzMDJiNDM0YjZiNTQzMzM2LCBwaHlzaWNhbFZvbHVtZUlk PSwgdm9sdW1lR3JvdXBJZD0sIHNlcmlhbD1TTkVUQVBQX0xVTl9CQ0F0MCtDS2tUMzYsIGx1bk1h cHBpbmc9MCwgdmVuZG9ySWQ9TkVUQVBQLCBwcm9kdWN0SWQ9TFVOLCBfbHVuQ29ubmVjdGlvbnM9 W10sIGRldmljZVNpemU9MTAwLCB2ZW5kb3JOYW1lPU5FVEFQUCwgcGF0aHNEaWN0aW9uYXJ5PXtz ZGE9dHJ1ZSwgc2R1PXRydWUsIHNkZT10cnVlLCBzZHE9dHJ1ZSwgc2RhYz10cnVlLCBzZGk9dHJ1 ZSwgc2RtPXRydWUsIHNkeT10cnVlfSwgbHVuVHlwZT1VTktOT1dOLCBzdGF0dXM9VXNlZCwgZGlz a0lkPW51bGwsIGRpc2tBbGlhcz1udWxsLCBzdG9yYWdlRG9tYWluSWQ9bnVsbCwgc3RvcmFnZURv bWFpbk5hbWU9bnVsbF1dLCBsb2cgaWQ6IDQzMzY4NAoyMDE0LTExLTA0IDA5OjQ3OjE2LDQwNSBJ TkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuR2V0VkdJbmZv VkRTQ29tbWFuZF0gKGFqcC0tMTI3LjAuMC4xLTg3MDItMSkgU1RBUlQsIEdldFZHSW5mb1ZEU0Nv bW1hbmQoSG9zdE5hbWUgPSBlbmMwLWJsNi5leGFtcGxlLmNvbSwgSG9zdElkID0gM2MxMDJhMDUt NmU5ZC00OTBiLWFlODAtMTcxMTZlOWQ1MjIxLCBWR0lEPWxmZ1pEMy1qZlVsLTNVcjgtbFMzaS04 Wm43LXFQbWQtWXZWcnI5KSwgbG9nIGlkOiAyOTIxOTY5MQoyMDE0LTExLTA0IDA5OjQ3OjE2LDk0 NCBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIuR2V0VkdJ bmZvVkRTQ29tbWFuZF0gKGFqcC0tMTI3LjAuMC4xLTg3MDItMSkgRklOSVNILCBHZXRWR0luZm9W RFNDb21tYW5kLCByZXR1cm46IFtMVU5zIFtpZD0zNjBhOTgwMDA0MjQzNDE3NDMwMmI0MzRiNmI1 NDMzNTIsIHBoeXNpY2FsVm9sdW1lSWQ9ZXNacVM4LVRiZFYtcDlIZC12MnN1LUNqQlctc25EZS0z WnFFamYsIHZvbHVtZUdyb3VwSWQ9bGZnWkQzLWpmVWwtM1VyOC1sUzNpLThabjctcVBtZC1ZdlZy cjksIHNlcmlhbD1TTkVUQVBQX0xVTl9CQ0F0MCtDS2tUM1IsIGx1bk1hcHBpbmc9NCwgdmVuZG9y SWQ9TkVUQVBQLCBwcm9kdWN0SWQ9TFVOLCBfbHVuQ29ubmVjdGlvbnM9W10sIGRldmljZVNpemU9 NTAwLCB2ZW5kb3JOYW1lPU5FVEFQUCwgcGF0aHNEaWN0aW9uYXJ5PXtzZHc9dHJ1ZSwgc2RjPXRy dWUsIHNkcz10cnVlLCBzZGc9dHJ1ZSwgc2RhYT10cnVlLCBzZGs9dHJ1ZSwgc2RhZT10cnVlLCBz ZG89dHJ1ZX0sIGx1blR5cGU9VU5LTk9XTiwgc3RhdHVzPW51bGwsIGRpc2tJZD1udWxsLCBkaXNr QWxpYXM9bnVsbCwgc3RvcmFnZURvbWFpbklkPTQ2MjQzY2U1LWZhY2UtNDgzZS05YTQwLTdkYWVh NzdkODJhMywgc3RvcmFnZURvbWFpbk5hbWU9bnVsbF0sIExVTnMgW2lkPTM2MGE5ODAwMDQyNDM0 MTc0MzAyYjQzNGI2YjU0MzM1NCwgcGh5c2ljYWxWb2x1bWVJZD1wU2NxcUstcm1TMC1raTY1LXFE ME0taGR4Ti1rd1dqLWxzaXI5ZSwgdm9sdW1lR3JvdXBJZD1sZmdaRDMtamZVbC0zVXI4LWxTM2kt OFpuNy1xUG1kLVl2VnJyOSwgc2VyaWFsPVNORVRBUFBfTFVOX0JDQXQwK0NLa1QzVCwgbHVuTWFw cGluZz01LCB2ZW5kb3JJZD1ORVRBUFAsIHByb2R1Y3RJZD1MVU4sIF9sdW5Db25uZWN0aW9ucz1b XSwgZGV2aWNlU2l6ZT01MDAsIHZlbmRvck5hbWU9TkVUQVBQLCBwYXRoc0RpY3Rpb25hcnk9e3Nk eD10cnVlLCBzZGQ9dHJ1ZSwgc2R0PXRydWUsIHNkaD10cnVlLCBzZGFiPXRydWUsIHNkbD10cnVl LCBzZGFmPXRydWUsIHNkcD10cnVlfSwgbHVuVHlwZT1VTktOT1dOLCBzdGF0dXM9bnVsbCwgZGlz a0lkPW51bGwsIGRpc2tBbGlhcz1udWxsLCBzdG9yYWdlRG9tYWluSWQ9NDYyNDNjZTUtZmFjZS00 ODNlLTlhNDAtN2RhZWE3N2Q4MmEzLCBzdG9yYWdlRG9tYWluTmFtZT1udWxsXV0sIGxvZyBpZDog MjkyMTk2OTEKMjAxNC0xMS0wNCAwOTo0NzoxNiw5NTYgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUu Y29yZS52ZHNicm9rZXIudmRzYnJva2VyLkhTTUdldFN0b3JhZ2VEb21haW5JbmZvVkRTQ29tbWFu ZF0gKGFqcC0tMTI3LjAuMC4xLTg3MDItMSkgU1RBUlQsIEhTTUdldFN0b3JhZ2VEb21haW5JbmZv VkRTQ29tbWFuZChIb3N0TmFtZSA9IGVuYzAtYmw2LmV4YW1wbGUuY29tLCBIb3N0SWQgPSAzYzEw MmEwNS02ZTlkLTQ5MGItYWU4MC0xNzExNmU5ZDUyMjEsIHN0b3JhZ2VEb21haW5JZD00NjI0M2Nl NS1mYWNlLTQ4M2UtOWE0MC03ZGFlYTc3ZDgyYTMpLCBsb2cgaWQ6IGJkNGE3MzIKMjAxNC0xMS0w NCAwOTo0NzoxNyw2NjYgSU5GTyAgW29yZy5vdmlydC52ZHNtLmpzb25ycGMuY2xpZW50LnJlYWN0 b3JzLlJlYWN0b3JDbGllbnRdIChTU0wgU3RvbXAgUmVhY3RvcikgQ29ubmVjdGluZyB0byAvMTky LjE2OC4xMDAuMjM1CjIwMTQtMTEtMDQgMDk6NDc6MTcsOTcwIElORk8gIFtvcmcub3ZpcnQuZW5n aW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5IU01HZXRTdG9yYWdlRG9tYWluSW5mb1ZEU0Nv bW1hbmRdIChhanAtLTEyNy4wLjAuMS04NzAyLTEpIEZJTklTSCwgSFNNR2V0U3RvcmFnZURvbWFp bkluZm9WRFNDb21tYW5kLCByZXR1cm46IDxTdG9yYWdlRG9tYWluU3RhdGljW0ZDLU5ldEFQUC1X b1MsIDQ2MjQzY2U1LWZhY2UtNDgzZS05YTQwLTdkYWVhNzdkODJhM10sIDU4NDliMDMwLTYyNmUt NDdjYi1hZDkwLTNjZTc4MmQ4MzFiMz4sIGxvZyBpZDogYmQ0YTczMgoyMDE0LTExLTA0IDA5OjQ3 OjE3LDk3NCBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci52ZHNicm9rZXIu R2V0VkdJbmZvVkRTQ29tbWFuZF0gKGFqcC0tMTI3LjAuMC4xLTg3MDItMSkgU1RBUlQsIEdldFZH SW5mb1ZEU0NvbW1hbmQoSG9zdE5hbWUgPSBlbmMwLWJsNi5leGFtcGxlLmNvbSwgSG9zdElkID0g M2MxMDJhMDUtNmU5ZC00OTBiLWFlODAtMTcxMTZlOWQ1MjIxLCBWR0lEPTVIYkVPZS1IVVhvLVZx bDctaHZxeC1vQTg2LWM3S0stTEIzYXBuKSwgbG9nIGlkOiBjMzBjNWZjCjIwMTQtMTEtMDQgMDk6 NDc6MTgsMDQzIElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tl ci5HZXRWR0luZm9WRFNDb21tYW5kXSAoYWpwLS0xMjcuMC4wLjEtODcwMi0xKSBGSU5JU0gsIEdl dFZHSW5mb1ZEU0NvbW1hbmQsIHJldHVybjogW0xVTnMgW2lkPTM2MGE5ODAwMDQyNDM0MTc0MzAy YjQzNGI2YjU0MzI3OSwgcGh5c2ljYWxWb2x1bWVJZD1DNU40UGQtQnh3by1nRE9iLWlDeFgtczdH Yi1YUUE0LUd5MkxqVSwgdm9sdW1lR3JvdXBJZD01SGJFT2UtSFVYby1WcWw3LWh2cXgtb0E4Ni1j N0tLLUxCM2Fwbiwgc2VyaWFsPVNORVRBUFBfTFVOX0JDQXQwK0NLa1QyeSwgbHVuTWFwcGluZz0x LCB2ZW5kb3JJZD1ORVRBUFAsIHByb2R1Y3RJZD1MVU4sIF9sdW5Db25uZWN0aW9ucz1bXSwgZGV2 aWNlU2l6ZT01MCwgdmVuZG9yTmFtZT1ORVRBUFAsIHBhdGhzRGljdGlvbmFyeT17c2RiPXRydWUs IHNkdj10cnVlLCBzZGY9dHJ1ZSwgc2RyPXRydWUsIHNkaj10cnVlLCBzZG49dHJ1ZSwgc2RhZD10 cnVlLCBzZHo9dHJ1ZX0sIGx1blR5cGU9VU5LTk9XTiwgc3RhdHVzPW51bGwsIGRpc2tJZD1udWxs LCBkaXNrQWxpYXM9bnVsbCwgc3RvcmFnZURvbWFpbklkPTBiMjlhZjdjLTJjYzYtNGZlNS04ZGMw LTU3M2QxYTAwMThlZSwgc3RvcmFnZURvbWFpbk5hbWU9bnVsbF1dLCBsb2cgaWQ6IGMzMGM1ZmMK MjAxNC0xMS0wNCAwOTo0NzoxOCwwNDcgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNi cm9rZXIudmRzYnJva2VyLkhTTUdldFN0b3JhZ2VEb21haW5JbmZvVkRTQ29tbWFuZF0gKGFqcC0t MTI3LjAuMC4xLTg3MDItMSkgU1RBUlQsIEhTTUdldFN0b3JhZ2VEb21haW5JbmZvVkRTQ29tbWFu ZChIb3N0TmFtZSA9IGVuYzAtYmw2LmV4YW1wbGUuY29tLCBIb3N0SWQgPSAzYzEwMmEwNS02ZTlk LTQ5MGItYWU4MC0xNzExNmU5ZDUyMjEsIHN0b3JhZ2VEb21haW5JZD0wYjI5YWY3Yy0yY2M2LTRm ZTUtOGRjMC01NzNkMWEwMDE4ZWUpLCBsb2cgaWQ6IDZhMDY1MzRiCjIwMTQtMTEtMDQgMDk6NDc6 MTksMDA2IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5I U01HZXRTdG9yYWdlRG9tYWluSW5mb1ZEU0NvbW1hbmRdIChhanAtLTEyNy4wLjAuMS04NzAyLTEp IEZJTklTSCwgSFNNR2V0U3RvcmFnZURvbWFpbkluZm9WRFNDb21tYW5kLCByZXR1cm46IDxTdG9y YWdlRG9tYWluU3RhdGljW0RBVEEsIDBiMjlhZjdjLTJjYzYtNGZlNS04ZGMwLTU3M2QxYTAwMThl ZV0sIGZiOWMyMzJlLTY5NzktNDE4YS1hZDk2LTExY2U2NmIzMWEzZT4sIGxvZyBpZDogNmEwNjUz NGIKMjAxNC0xMS0wNCAwOTo0NzoyNyw5MDIgSU5GTyAgW29yZy5vdmlydC52ZHNtLmpzb25ycGMu Y2xpZW50LnJlYWN0b3JzLlJlYWN0b3JDbGllbnRdIChTU0wgU3RvbXAgUmVhY3RvcikgQ29ubmVj dGluZyB0byAvMTkyLjE2OC4xMDAuMjM1CjIwMTQtMTEtMDQgMDk6NDc6MzAsMjE1IFdBUk4gIFtv cmcub3ZpcnQuZW5naW5lLmNvcmUuZGFsLmpvYi5FeGVjdXRpb25NZXNzYWdlRGlyZWN0b3JdIChh anAtLTEyNy4wLjAuMS04NzAyLTUpIFtmYjc1NDZhXSBUaGUgbWVzc2FnZSBrZXkgQWRkRXhpc3Rp bmdCbG9ja1N0b3JhZ2VEb21haW4gaXMgbWlzc2luZyBmcm9tIGJ1bmRsZXMvRXhlY3V0aW9uTWVz c2FnZXMKMjAxNC0xMS0wNCAwOTo0NzozMCwzMjQgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29y ZS5ibGwuc3RvcmFnZS5BZGRFeGlzdGluZ0Jsb2NrU3RvcmFnZURvbWFpbkNvbW1hbmRdIChhanAt LTEyNy4wLjAuMS04NzAyLTUpIFtmYjc1NDZhXSBSdW5uaW5nIGNvbW1hbmQ6IEFkZEV4aXN0aW5n QmxvY2tTdG9yYWdlRG9tYWluQ29tbWFuZCBpbnRlcm5hbDogZmFsc2UuIEVudGl0aWVzIGFmZmVj dGVkIDogIElEOiBhYWEwMDAwMC0wMDAwLTAwMDAtMDAwMC0xMjM0NTY3ODlhYWEgVHlwZTogU3lz dGVtQWN0aW9uIGdyb3VwIENSRUFURV9TVE9SQUdFX0RPTUFJTiB3aXRoIHJvbGUgdHlwZSBBRE1J TgoyMDE0LTExLTA0IDA5OjQ3OjMwLDM5MyBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZk c2Jyb2tlci52ZHNicm9rZXIuR2V0U3RvcmFnZURvbWFpblN0YXRzVkRTQ29tbWFuZF0gKGFqcC0t MTI3LjAuMC4xLTg3MDItNSkgW2ZiNzU0NmFdIFNUQVJULCBHZXRTdG9yYWdlRG9tYWluU3RhdHNW RFNDb21tYW5kKEhvc3ROYW1lID0gZW5jMC1ibDYuZXhhbXBsZS5jb20sIEhvc3RJZCA9IDNjMTAy YTA1LTZlOWQtNDkwYi1hZTgwLTE3MTE2ZTlkNTIyMSwgc3RvcmFnZURvbWFpbklkPTQ2MjQzY2U1 LWZhY2UtNDgzZS05YTQwLTdkYWVhNzdkODJhMyksIGxvZyBpZDogNWQ4ODVlMDMKMjAxNC0xMS0w NCAwOTo0NzozMCw3MzYgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIudmRz YnJva2VyLkdldFN0b3JhZ2VEb21haW5TdGF0c1ZEU0NvbW1hbmRdIChhanAtLTEyNy4wLjAuMS04 NzAyLTUpIFtmYjc1NDZhXSBGSU5JU0gsIEdldFN0b3JhZ2VEb21haW5TdGF0c1ZEU0NvbW1hbmQs IHJldHVybjogU3RvcmFnZURvbWFpblssIDQ2MjQzY2U1LWZhY2UtNDgzZS05YTQwLTdkYWVhNzdk ODJhM10sIGxvZyBpZDogNWQ4ODVlMDMKMjAxNC0xMS0wNCAwOTo0NzozMCw3NDkgSU5GTyAgW29y Zy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIudmRzYnJva2VyLkdldFZHSW5mb1ZEU0NvbW1h bmRdIChhanAtLTEyNy4wLjAuMS04NzAyLTUpIFtmYjc1NDZhXSBTVEFSVCwgR2V0VkdJbmZvVkRT Q29tbWFuZChIb3N0TmFtZSA9IGVuYzAtYmw2LmV4YW1wbGUuY29tLCBIb3N0SWQgPSAzYzEwMmEw NS02ZTlkLTQ5MGItYWU4MC0xNzExNmU5ZDUyMjEsIFZHSUQ9bGZnWkQzLWpmVWwtM1VyOC1sUzNp LThabjctcVBtZC1ZdlZycjkpLCBsb2cgaWQ6IDM0YWQ1Yzk1CjIwMTQtMTEtMDQgMDk6NDc6MzAs ODQzIElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLnZkc2Jyb2tlci5HZXRW R0luZm9WRFNDb21tYW5kXSAoYWpwLS0xMjcuMC4wLjEtODcwMi01KSBbZmI3NTQ2YV0gRklOSVNI LCBHZXRWR0luZm9WRFNDb21tYW5kLCByZXR1cm46IFtMVU5zIFtpZD0zNjBhOTgwMDA0MjQzNDE3 NDMwMmI0MzRiNmI1NDMzNTIsIHBoeXNpY2FsVm9sdW1lSWQ9ZXNacVM4LVRiZFYtcDlIZC12MnN1 LUNqQlctc25EZS0zWnFFamYsIHZvbHVtZUdyb3VwSWQ9bGZnWkQzLWpmVWwtM1VyOC1sUzNpLTha bjctcVBtZC1ZdlZycjksIHNlcmlhbD1TTkVUQVBQX0xVTl9CQ0F0MCtDS2tUM1IsIGx1bk1hcHBp bmc9NCwgdmVuZG9ySWQ9TkVUQVBQLCBwcm9kdWN0SWQ9TFVOLCBfbHVuQ29ubmVjdGlvbnM9W10s IGRldmljZVNpemU9NTAwLCB2ZW5kb3JOYW1lPU5FVEFQUCwgcGF0aHNEaWN0aW9uYXJ5PXtzZHc9 dHJ1ZSwgc2RjPXRydWUsIHNkcz10cnVlLCBzZGc9dHJ1ZSwgc2RhYT10cnVlLCBzZGs9dHJ1ZSwg c2RhZT10cnVlLCBzZG89dHJ1ZX0sIGx1blR5cGU9VU5LTk9XTiwgc3RhdHVzPW51bGwsIGRpc2tJ ZD1udWxsLCBkaXNrQWxpYXM9bnVsbCwgc3RvcmFnZURvbWFpbklkPTQ2MjQzY2U1LWZhY2UtNDgz ZS05YTQwLTdkYWVhNzdkODJhMywgc3RvcmFnZURvbWFpbk5hbWU9bnVsbF0sIExVTnMgW2lkPTM2 MGE5ODAwMDQyNDM0MTc0MzAyYjQzNGI2YjU0MzM1NCwgcGh5c2ljYWxWb2x1bWVJZD1wU2NxcUst cm1TMC1raTY1LXFEME0taGR4Ti1rd1dqLWxzaXI5ZSwgdm9sdW1lR3JvdXBJZD1sZmdaRDMtamZV bC0zVXI4LWxTM2ktOFpuNy1xUG1kLVl2VnJyOSwgc2VyaWFsPVNORVRBUFBfTFVOX0JDQXQwK0NL a1QzVCwgbHVuTWFwcGluZz01LCB2ZW5kb3JJZD1ORVRBUFAsIHByb2R1Y3RJZD1MVU4sIF9sdW5D b25uZWN0aW9ucz1bXSwgZGV2aWNlU2l6ZT01MDAsIHZlbmRvck5hbWU9TkVUQVBQLCBwYXRoc0Rp Y3Rpb25hcnk9e3NkeD10cnVlLCBzZGQ9dHJ1ZSwgc2R0PXRydWUsIHNkaD10cnVlLCBzZGFiPXRy dWUsIHNkbD10cnVlLCBzZGFmPXRydWUsIHNkcD10cnVlfSwgbHVuVHlwZT1VTktOT1dOLCBzdGF0 dXM9bnVsbCwgZGlza0lkPW51bGwsIGRpc2tBbGlhcz1udWxsLCBzdG9yYWdlRG9tYWluSWQ9NDYy NDNjZTUtZmFjZS00ODNlLTlhNDAtN2RhZWE3N2Q4MmEzLCBzdG9yYWdlRG9tYWluTmFtZT1udWxs XV0sIGxvZyBpZDogMzRhZDVjOTUKMjAxNC0xMS0wNCAwOTo0NzozMCw5MzkgSU5GTyAgW29yZy5v dmlydC5lbmdpbmUuY29yZS5kYWwuZGJicm9rZXIuYXVkaXRsb2doYW5kbGluZy5BdWRpdExvZ0Rp cmVjdG9yXSAoYWpwLS0xMjcuMC4wLjEtODcwMi01KSBbZmI3NTQ2YV0gQ29ycmVsYXRpb24gSUQ6 IGZiNzU0NmEsIEpvYiBJRDogZDUyYjAyNWMtYzJmYy00Y2Y0LWFlYTQtNmQ2MGQ0MmVlMWIzLCBD YWxsIFN0YWNrOiBudWxsLCBDdXN0b20gRXZlbnQgSUQ6IC0xLCBNZXNzYWdlOiBTdG9yYWdlIERv bWFpbiBGQy1OZXRBUFAtV29TIHdhcyBhZGRlZCBieSBhZG1pbgoyMDE0LTExLTA0IDA5OjQ3OjMx LDExMCBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5zdG9yYWdlLkF0dGFjaFN0b3Jh Z2VEb21haW5Ub1Bvb2xDb21tYW5kXSAoYWpwLS0xMjcuMC4wLjEtODcwMi0yKSBbNjlmYmExNmNd IExvY2sgQWNxdWlyZWQgdG8gb2JqZWN0IEVuZ2luZUxvY2sgW2V4Y2x1c2l2ZUxvY2tzPSBrZXk6 IDQ2MjQzY2U1LWZhY2UtNDgzZS05YTQwLTdkYWVhNzdkODJhMyB2YWx1ZTogU1RPUkFHRQosIHNo YXJlZExvY2tzPSBdCjIwMTQtMTEtMDQgMDk6NDc6MzEsMjA3IElORk8gIFtvcmcub3ZpcnQuZW5n aW5lLmNvcmUuYmxsLnN0b3JhZ2UuQXR0YWNoU3RvcmFnZURvbWFpblRvUG9vbENvbW1hbmRdIChh anAtLTEyNy4wLjAuMS04NzAyLTIpIFs2OWZiYTE2Y10gUnVubmluZyBjb21tYW5kOiBBdHRhY2hT dG9yYWdlRG9tYWluVG9Qb29sQ29tbWFuZCBpbnRlcm5hbDogZmFsc2UuIEVudGl0aWVzIGFmZmVj dGVkIDogIElEOiA0NjI0M2NlNS1mYWNlLTQ4M2UtOWE0MC03ZGFlYTc3ZDgyYTMgVHlwZTogU3Rv cmFnZUFjdGlvbiBncm91cCBNQU5JUFVMQVRFX1NUT1JBR0VfRE9NQUlOIHdpdGggcm9sZSB0eXBl IEFETUlOCjIwMTQtMTEtMDQgMDk6NDc6MzEsMjM3IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNv cmUudmRzYnJva2VyLnZkc2Jyb2tlci5IU01HZXRTdG9yYWdlRG9tYWluSW5mb1ZEU0NvbW1hbmRd IChhanAtLTEyNy4wLjAuMS04NzAyLTIpIFs2OWZiYTE2Y10gU1RBUlQsIEhTTUdldFN0b3JhZ2VE b21haW5JbmZvVkRTQ29tbWFuZChIb3N0TmFtZSA9IGVuYzAtYmw2LmV4YW1wbGUuY29tLCBIb3N0 SWQgPSAzYzEwMmEwNS02ZTlkLTQ5MGItYWU4MC0xNzExNmU5ZDUyMjEsIHN0b3JhZ2VEb21haW5J ZD00NjI0M2NlNS1mYWNlLTQ4M2UtOWE0MC03ZGFlYTc3ZDgyYTMpLCBsb2cgaWQ6IDM2Mzk1Yjk1 CjIwMTQtMTEtMDQgMDk6NDc6MzEsOTM1IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRz YnJva2VyLnZkc2Jyb2tlci5IU01HZXRTdG9yYWdlRG9tYWluSW5mb1ZEU0NvbW1hbmRdIChhanAt LTEyNy4wLjAuMS04NzAyLTIpIFs2OWZiYTE2Y10gRklOSVNILCBIU01HZXRTdG9yYWdlRG9tYWlu SW5mb1ZEU0NvbW1hbmQsIHJldHVybjogPFN0b3JhZ2VEb21haW5TdGF0aWNbRkMtTmV0QVBQLVdv UywgNDYyNDNjZTUtZmFjZS00ODNlLTlhNDAtN2RhZWE3N2Q4MmEzXSwgNTg0OWIwMzAtNjI2ZS00 N2NiLWFkOTAtM2NlNzgyZDgzMWIzPiwgbG9nIGlkOiAzNjM5NWI5NQoyMDE0LTExLTA0IDA5OjQ3 OjMxLDk0MCBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci5pcnNicm9rZXIu RGV0YWNoU3RvcmFnZURvbWFpblZEU0NvbW1hbmRdIChhanAtLTEyNy4wLjAuMS04NzAyLTIpIFs2 OWZiYTE2Y10gU1RBUlQsIERldGFjaFN0b3JhZ2VEb21haW5WRFNDb21tYW5kKCBzdG9yYWdlUG9v bElkID0gNGUxNDU3NGQtOTQ3Mi00ZTRhLWE0NGEtMTQwYWNiYjc5MGJiLCBpZ25vcmVGYWlsb3Zl ckxpbWl0ID0gZmFsc2UsIHN0b3JhZ2VEb21haW5JZCA9IDQ2MjQzY2U1LWZhY2UtNDgzZS05YTQw LTdkYWVhNzdkODJhMywgbWFzdGVyRG9tYWluSWQgPSAwMDAwMDAwMC0wMDAwLTAwMDAtMDAwMC0w MDAwMDAwMDAwMDAsIG1hc3RlclZlcnNpb24gPSAwLCBmb3JjZSA9IHRydWUpLCBsb2cgaWQ6IDVi NGQ3ZjlhCjIwMTQtMTEtMDQgMDk6NDc6MzEsOTYzIFdBUk4gIFtvcmcub3ZpcnQuZW5naW5lLmNv cmUudmRzYnJva2VyLmlyc2Jyb2tlci5EZXRhY2hTdG9yYWdlRG9tYWluVkRTQ29tbWFuZF0gKGFq cC0tMTI3LjAuMC4xLTg3MDItMikgWzY5ZmJhMTZjXSBVbmV4cGVjdGVkIHJldHVybiB2YWx1ZTog U3RhdHVzRm9yWG1sUnBjIFttQ29kZT0tMzI2MDMsIG1NZXNzYWdlPWRldGFjaCgpIHRha2VzIGV4 YWN0bHkgNSBhcmd1bWVudHMgKDMgZ2l2ZW4pXQoyMDE0LTExLTA0IDA5OjQ3OjMxLDk2NSBFUlJP UiBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnZkc2Jyb2tlci5pcnNicm9rZXIuRGV0YWNoU3RvcmFn ZURvbWFpblZEU0NvbW1hbmRdIChhanAtLTEyNy4wLjAuMS04NzAyLTIpIFs2OWZiYTE2Y10gRmFp bGVkIGluIERldGFjaFN0b3JhZ2VEb21haW5WRFMgbWV0aG9kCjIwMTQtMTEtMDQgMDk6NDc6MzEs OTY3IElORk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUudmRzYnJva2VyLmlyc2Jyb2tlci5EZXRh Y2hTdG9yYWdlRG9tYWluVkRTQ29tbWFuZF0gKGFqcC0tMTI3LjAuMC4xLTg3MDItMikgWzY5ZmJh MTZjXSBDb21tYW5kIG9yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIuaXJzYnJva2VyLkRl dGFjaFN0b3JhZ2VEb21haW5WRFNDb21tYW5kIHJldHVybiB2YWx1ZSAKIFN0YXR1c09ubHlSZXR1 cm5Gb3JYbWxScGMgW21TdGF0dXM9U3RhdHVzRm9yWG1sUnBjIFttQ29kZT0tMzI2MDMsIG1NZXNz YWdlPWRldGFjaCgpIHRha2VzIGV4YWN0bHkgNSBhcmd1bWVudHMgKDMgZ2l2ZW4pXV0KMjAxNC0x MS0wNCAwOTo0NzozMSw5NjkgRVJST1IgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIu aXJzYnJva2VyLkRldGFjaFN0b3JhZ2VEb21haW5WRFNDb21tYW5kXSAoYWpwLS0xMjcuMC4wLjEt ODcwMi0yKSBbNjlmYmExNmNdIENvdWxkIG5vdCBmb3JjZSBkZXRhY2ggZG9tYWluIDQ2MjQzY2U1 LWZhY2UtNDgzZS05YTQwLTdkYWVhNzdkODJhMyBvbiBwb29sIDRlMTQ1NzRkLTk0NzItNGU0YS1h NDRhLTE0MGFjYmI3OTBiYi4gZXJyb3I6IG9yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNicm9rZXIu aXJzYnJva2VyLklSU0Vycm9yRXhjZXB0aW9uOiBJUlNHZW5lcmljRXhjZXB0aW9uOiBJUlNFcnJv ckV4Y2VwdGlvbjogRmFpbGVkIHRvIERldGFjaFN0b3JhZ2VEb21haW5WRFMsIGVycm9yID0gZGV0 YWNoKCkgdGFrZXMgZXhhY3RseSA1IGFyZ3VtZW50cyAoMyBnaXZlbiksIGNvZGUgPSAtMzI2MDMK MjAxNC0xMS0wNCAwOTo0NzozMSw5ODAgSU5GTyAgW29yZy5vdmlydC5lbmdpbmUuY29yZS52ZHNi cm9rZXIuaXJzYnJva2VyLkRldGFjaFN0b3JhZ2VEb21haW5WRFNDb21tYW5kXSAoYWpwLS0xMjcu MC4wLjEtODcwMi0yKSBbNjlmYmExNmNdIEZJTklTSCwgRGV0YWNoU3RvcmFnZURvbWFpblZEU0Nv bW1hbmQsIGxvZyBpZDogNWI0ZDdmOWEKMjAxNC0xMS0wNCAwOTo0NzozMSw5ODIgV0FSTiAgW29y Zy5vdmlydC5lbmdpbmUuY29yZS5ibGwuc3RvcmFnZS5BdHRhY2hTdG9yYWdlRG9tYWluVG9Qb29s Q29tbWFuZF0gKGFqcC0tMTI3LjAuMC4xLTg3MDItMikgWzY5ZmJhMTZjXSBEZXRhY2hpbmcgU3Rv cmFnZSBEb21haW4gNDYyNDNjZTUtZmFjZS00ODNlLTlhNDAtN2RhZWE3N2Q4MmEzIGZyb20gaXRz IHByZXZpb3VzIHN0b3JhZ2UgcG9vbCAwMDAwMDAwMC0wMDAwLTAwMDAtMDAwMC0wMDAwMDAwMDAw MDAgaGFzIGZhaWxlZC4gVGhlIG1ldGEgZGF0YSBvZiB0aGUgU3RvcmFnZSBEb21haW4gbWlnaHQg c3RpbGwgaW5kaWNhdGUgdGhhdCBpdCBpcyBhdHRhY2hlZCB0byBhIGRpZmZlcmVudCBTdG9yYWdl IFBvb2wuCjIwMTQtMTEtMDQgMDk6NDc6MzEsOTg1IEVSUk9SIFtvcmcub3ZpcnQuZW5naW5lLmNv cmUuYmxsLnN0b3JhZ2UuQXR0YWNoU3RvcmFnZURvbWFpblRvUG9vbENvbW1hbmRdIChhanAtLTEy Ny4wLjAuMS04NzAyLTIpIFs2OWZiYTE2Y10gQ29tbWFuZCBvcmcub3ZpcnQuZW5naW5lLmNvcmUu YmxsLnN0b3JhZ2UuQXR0YWNoU3RvcmFnZURvbWFpblRvUG9vbENvbW1hbmQgdGhyb3cgVmRjIEJs bCBleGNlcHRpb24uIFdpdGggZXJyb3IgbWVzc2FnZSBWZGNCTExFeGNlcHRpb246IG51bGwgKEZh aWxlZCB3aXRoIGVycm9yIEVOR0lORSBhbmQgY29kZSA1MDAxKQoyMDE0LTExLTA0IDA5OjQ3OjMy LDAyMiBJTkZPICBbb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5zdG9yYWdlLkF0dGFjaFN0b3Jh Z2VEb21haW5Ub1Bvb2xDb21tYW5kXSAoYWpwLS0xMjcuMC4wLjEtODcwMi0yKSBbNjlmYmExNmNd IENvbW1hbmQgW2lkPTExZmFhMzFiLWNhY2EtNGUwMy05Nzg0LTI1MDcwZDZiMjU0MV06IENvbXBl bnNhdGluZyBORVdfRU5USVRZX0lEIG9mIG9yZy5vdmlydC5lbmdpbmUuY29yZS5jb21tb24uYnVz aW5lc3NlbnRpdGllcy5TdG9yYWdlUG9vbElzb01hcDsgc25hcHNob3Q6IHN0b3JhZ2VQb29sSWQg PSA0ZTE0NTc0ZC05NDcyLTRlNGEtYTQ0YS0xNDBhY2JiNzkwYmIsIHN0b3JhZ2VJZCA9IDQ2MjQz Y2U1LWZhY2UtNDgzZS05YTQwLTdkYWVhNzdkODJhMy4KMjAxNC0xMS0wNCAwOTo0NzozMiwwNTcg RVJST1IgW29yZy5vdmlydC5lbmdpbmUuY29yZS5kYWwuZGJicm9rZXIuYXVkaXRsb2doYW5kbGlu Zy5BdWRpdExvZ0RpcmVjdG9yXSAoYWpwLS0xMjcuMC4wLjEtODcwMi0yKSBbNjlmYmExNmNdIENv cnJlbGF0aW9uIElEOiA2OWZiYTE2YywgSm9iIElEOiA0YjcwMGFjNS1hOWVhLTRlYzYtYjE1ZS1h ZTAxMTc2MmYzMDcsIENhbGwgU3RhY2s6IG51bGwsIEN1c3RvbSBFdmVudCBJRDogLTEsIE1lc3Nh Z2U6IEZhaWxlZCB0byBhdHRhY2ggU3RvcmFnZSBEb21haW4gRkMtTmV0QVBQLVdvUyB0byBEYXRh IENlbnRlciBEZWZhdWx0LiAoVXNlcjogYWRtaW4pCjIwMTQtMTEtMDQgMDk6NDc6MzIsMDY1IElO Rk8gIFtvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLnN0b3JhZ2UuQXR0YWNoU3RvcmFnZURvbWFp blRvUG9vbENvbW1hbmRdIChhanAtLTEyNy4wLjAuMS04NzAyLTIpIFs2OWZiYTE2Y10gTG9jayBm cmVlZCB0byBvYmplY3QgRW5naW5lTG9jayBbZXhjbHVzaXZlTG9ja3M9IGtleTogNDYyNDNjZTUt ZmFjZS00ODNlLTlhNDAtN2RhZWE3N2Q4MmEzIHZhbHVlOiBTVE9SQUdFCiwgc2hhcmVkTG9ja3M9 IF0KMjAxNC0xMS0wNCAwOTo0Nzo0OCwyMjIgSU5GTyAgW29yZy5vdmlydC52ZHNtLmpzb25ycGMu Y2xpZW50LnJlYWN0b3JzLlJlYWN0b3JDbGllbnRdIChTU0wgU3RvbXAgUmVhY3RvcikgQ29ubmVj dGluZyB0byAvMTkyLjE2OC4xMDAuMjM1Cg== ------=_Part_2362972_479624645.1415087866734--

2 10

[QE][ACTION NEEDED] oVirt 3.5.1 RC status
by Sandro Bonazzola 05 Nov '14

05 Nov '14

Hi, We're going to start composing oVirt 3.5.1 RC on *2014-11-25 08:00 UTC* from 3.5 branch. Maintainers: - Please be sure that 3.5 snapshot allow to create VMs before *2014-11-24 15:00 UTC* - Please be sure that no pending patches are going to block the release before *2014-11-24 15:00 UTC* - If any patch must block the RC release please raise the issue as soon as possible. A bug tracker [1] has been opened and shows 1 open blocker: Bug ID Whiteboard Status Summary 1142710 integration NEW Volume creation failed while deploying Hosted Engine on iSCSI There are still 181 bugs [2] targeted to 3.5.1. Excluding node and documentation bugs we still have 151 bugs [3] targeted to 3.5.1. Maintainers / Assignee: - Please add the bugs to the tracker if you think that 3.5.1 should not be released without them fixed. - Please update the target to 3.5.2 or later for bugs that won't be in 3.5.1: it will ease gathering the blocking bugs for next releases. - Please fill release notes, the page has been created here [4] Community: - If you're testing oVirt 3.5 nightly snapshot, please add yourself to the test page [5] [1] http://bugzilla.redhat.com/1155170 [2] http://goo.gl/7G0PDV [3] http://goo.gl/6gUbVr [4] http://www.ovirt.org/OVirt_3.5.1_Release_Notes [5] http://www.ovirt.org/Testing/oVirt_3.5.1_Testing -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Re: [ovirt-users] gluster-server 3.5.2 requies gluasterfs-3.52
by Sahina Bose 05 Nov '14

05 Nov '14

This is a multi-part message in MIME format. --------------000803040704030401050000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit It looks like you have run into this issue - https://www.mail-archive.com/gluster-devel@gluster.org/msg02310.html [Thanks, Humble for helping on this] One workaround is to install the yum-plugin-priorities and add a priority = 1 to the ovirt35-glusterfs-epel repo. Meanwhile, the problem is going to be solved by the release of glusterfs 3.6.1 in the following days. On 11/05/2014 05:48 AM, Juan Carlos YJ. Lin wrote: > Reinstall ovirt hosted engine today, and get this > > [root@node1 ~]# yum list *gluster* > Loaded plugins: fastestmirror > Loading mirror speeds from cached hostfile > * base: centos.xpg.com.br > * epel: mirror.ci.ifes.edu.br > * extras: mirror.ci.ifes.edu.br > * ovirt-3.5: www.gtlib.gatech.edu > * ovirt-3.5-epel: mirror.ci.ifes.edu.br > * ovirt-3.5-jpackage-6.0-generic: ftp.heanet.ie > * updates: mirror.ci.ifes.edu.br > Installed Packages > glusterfs.x86_64 3.6.0.29-2.el6 @updates > glusterfs-api.x86_64 3.6.0.29-2.el6 @updates > glusterfs-cli.x86_64 3.6.0.29-2.el6 @updates > glusterfs-fuse.x86_64 3.6.0.29-2.el6 @updates > glusterfs-libs.x86_64 3.6.0.29-2.el6 @updates > glusterfs-rdma.x86_64 3.6.0.29-2.el6 @updates > Available Packages > glusterfs-api-devel.x86_64 3.6.0.29-2.el6 updates > glusterfs-debuginfo.x86_64 3.5.2-1.el6 ovirt-3.5-glusterfs-epel > glusterfs-devel.x86_64 3.6.0.29-2.el6 updates > glusterfs-extra-xlators.x86_64 3.5.2-1.el6 ovirt-3.5-glusterfs-epel > glusterfs-geo-replication.x86_64 3.5.2-1.el6 ovirt-3.5-glusterfs-epel > glusterfs-regression-tests.x86_64 3.5.2-1.el6 ovirt-3.5-glusterfs-epel > glusterfs-resource-agents.noarch 3.5.2-1.el6 > ovirt-3.5-glusterfs-noarch-epel > glusterfs-server.x86_64 3.5.2-1.el6 ovirt-3.5-glusterfs-epel > puppet-gluster.noarch 0.0.3-1.el6 epel > puppet-gluster-doc.noarch 0.0.3-1.el6 epel > samba-glusterfs.x86_64 3.6.23-12.el6 base > vdsm-gluster.noarch 4.16.7-1.gitdb83943.el6 > ovirt-3.5 > > Juan Carlos Lin > Unisoft S.A. > +595-993-288330 > > ------------------------------------------------------------------------ > *De: *"Sahina Bose" <sabose(a)redhat.com> > *Para: *"Juan Carlos YJ Lin" <lin(a)unisoft.com.py> > *Enviados: *Martes, 4 de Noviembre 2014 4:55:45 > *Asunto: *Re: [ovirt-users] gluster-server 3.5.2 requies gluasterfs-3.52 > > The node would pull the latest rpms based on your repo configuration. > vdsm on the node has a requirement on glusterfs > 3.4.2. > > Which OS are you using. I wonder how you got the glusterfs 3.6 as they > are not available in the download.gluster.org repo. > > Could you tell me the output of > rpm -qa | grep gluster > > On 11/03/2014 08:39 PM, Juan Carlos YJ. Lin wrote: > > so is correct the dependecy? > I try to install glusterfs-server in the node host and got the error > > Juan Carlos Lin > Unisoft S.A. > +595-993-288330 > > ------------------------------------------------------------------------ > *De: *"Sahina Bose" <sabose(a)redhat.com> > *Para: *"Juan Carlos YJ Lin" <lin(a)unisoft.com.py>, users(a)ovirt.org > *Enviados: *Lunes, 3 de Noviembre 2014 5:17:30 > *Asunto: *Re: [ovirt-users] gluster-server 3.5.2 requies > gluasterfs-3.52 > > > On 11/03/2014 01:44 PM, Sahina Bose wrote: > > ovirt 3.5 does not have a dependency on glusterfs-3.6.0, > AFAIK. 3.6 is in beta stage still. > > > My bad. glusterfs 3.6 was released on Oct 31. > > > Are you installing hosted engine? Do you by any chance have > additional repos for glusterfs configured? > > On 11/03/2014 05:44 AM, Juan Carlos YJ. Lin wrote: > > gluster-server 3.5.2 requies gluasterfs-3.52, but ovirt3.5 > install glusterfs-3.6.0 > how to solve the dependency? > > Juan Carlos Lin > Unisoft S.A. > +595-993-288330 > > > System-wide Disclaimer > --------------------------------------------------- > "Antes de imprimir, recuérdese de su compromiso con el > Medio Ambiente" > "Aviso: Este mensaje es dirigido para su destinatario y > contiene informaciones que no pueden ser usadas por otras > personas que no sean su(s) destinatario(s). La > retransmisión del contenido no está autorizada fuera del > contexto de su envío y a quien corresponde. El uso no > autorizado de la información en este mensaje se halla > penado por las leyes vigentes en todo el mundo. Si ha > recibido este mensaje por error, por favor bórrala y > notifique al remitente en la brevedad posible. El > contenido de este mensaje no es responsabilidad de la > Empresa y debe ser atribuido siempre a su autor. Gracias." > > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > > > > > > System-wide Disclaimer > --------------------------------------------------- > "Antes de imprimir, recuérdese de su compromiso con el Medio Ambiente" > "Aviso: Este mensaje es dirigido para su destinatario y contiene > informaciones que no pueden ser usadas por otras personas que no > sean su(s) destinatario(s). La retransmisión del contenido no está > autorizada fuera del contexto de su envío y a quien corresponde. > El uso no autorizado de la información en este mensaje se halla > penado por las leyes vigentes en todo el mundo. Si ha recibido > este mensaje por error, por favor bórrala y notifique al remitente > en la brevedad posible. El contenido de este mensaje no es > responsabilidad de la Empresa y debe ser atribuido siempre a su > autor. Gracias." > > > > > System-wide Disclaimer --------------------------------------------------- > "Antes de imprimir, recuérdese de su compromiso con el Medio Ambiente" > "Aviso: Este mensaje es dirigido para su destinatario y contiene > informaciones que no pueden ser usadas por otras personas que no sean > su(s) destinatario(s). La retransmisión del contenido no está > autorizada fuera del contexto de su envío y a quien corresponde. El > uso no autorizado de la información en este mensaje se halla penado > por las leyes vigentes en todo el mundo. Si ha recibido este mensaje > por error, por favor bórrala y notifique al remitente en la brevedad > posible. El contenido de este mensaje no es responsabilidad de la > Empresa y debe ser atribuido siempre a su autor. Gracias." --------------000803040704030401050000 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> It looks like you have run into this issue - <a class="moz-txt-link-freetext" href="https://www.mail-archive.com/gluster-devel@gluster.org/msg02310.html">https://www.mail-archive.com/gluster-devel@gluster.org/msg02310.html</a><br> [Thanks, Humble for helping on this]<br> <br> One workaround is to install the yum-plugin-priorities and add a priority = 1 to the ovirt35-glusterfs-epel repo. Meanwhile, the problem is going to be solved by the release of glusterfs 3.6.1 in the following days.<br> <br> <br> <br> <div class="moz-cite-prefix">On 11/05/2014 05:48 AM, Juan Carlos YJ. Lin wrote:<br> </div> <blockquote cite="mid:29721530-c6a4-4e71-ba3d-4ab1e108b4d7@server1.monalisa.com.py" type="cite"> <style type="text/css">p { margin: 0; }</style> <div style="font-family: Arial; font-size: 10pt; color: #000000">Reinstall ovirt hosted engine today, and get this<br> <br> [root@node1 ~]# yum list *gluster*<br> Loaded plugins: fastestmirror<br> Loading mirror speeds from cached hostfile<br> * base: centos.xpg.com.br<br> * epel: mirror.ci.ifes.edu.br<br> * extras: mirror.ci.ifes.edu.br<br> * ovirt-3.5: <a class="moz-txt-link-abbreviated" href="http://www.gtlib.gatech.edu">www.gtlib.gatech.edu</a><br> * ovirt-3.5-epel: mirror.ci.ifes.edu.br<br> * ovirt-3.5-jpackage-6.0-generic: <a class="moz-txt-link-abbreviated" href="ftp://ftp.heanet.ie">ftp.heanet.ie</a><br> * updates: mirror.ci.ifes.edu.br<br> Installed Packages<br> glusterfs.x86_64 3.6.0.29-2.el6 @updates <br> glusterfs-api.x86_64 3.6.0.29-2.el6 @updates <br> glusterfs-cli.x86_64 3.6.0.29-2.el6 @updates <br> glusterfs-fuse.x86_64 3.6.0.29-2.el6 @updates <br> glusterfs-libs.x86_64 3.6.0.29-2.el6 @updates <br> glusterfs-rdma.x86_64 3.6.0.29-2.el6 @updates <br> Available Packages<br> glusterfs-api-devel.x86_64 3.6.0.29-2.el6 updates <br> glusterfs-debuginfo.x86_64 3.5.2-1.el6 ovirt-3.5-glusterfs-epel <br> glusterfs-devel.x86_64 3.6.0.29-2.el6 updates <br> glusterfs-extra-xlators.x86_64 3.5.2-1.el6 ovirt-3.5-glusterfs-epel <br> glusterfs-geo-replication.x86_64 3.5.2-1.el6 ovirt-3.5-glusterfs-epel <br> glusterfs-regression-tests.x86_64 3.5.2-1.el6 ovirt-3.5-glusterfs-epel <br> glusterfs-resource-agents.noarch 3.5.2-1.el6 ovirt-3.5-glusterfs-noarch-epel<br> glusterfs-server.x86_64 3.5.2-1.el6 ovirt-3.5-glusterfs-epel <br> puppet-gluster.noarch 0.0.3-1.el6 epel <br> puppet-gluster-doc.noarch 0.0.3-1.el6 epel <br> samba-glusterfs.x86_64 3.6.23-12.el6 base <br> vdsm-gluster.noarch 4.16.7-1.gitdb83943.el6<br> ovirt-3.5 <br> <span><br> <span name="x"></span>Juan Carlos Lin<br> Unisoft S.A.<br> +595-993-288330<span name="x"></span><br> </span><br> <hr id="zwchr"> <div style="color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>De: </b>"Sahina Bose" <a class="moz-txt-link-rfc2396E" href="mailto:sabose@redhat.com"><sabose(a)redhat.com></a><br> <b>Para: </b>"Juan Carlos YJ Lin" <a class="moz-txt-link-rfc2396E" href="mailto:lin@unisoft.com.py"><lin(a)unisoft.com.py></a><br> <b>Enviados: </b>Martes, 4 de Noviembre 2014 4:55:45<br> <b>Asunto: </b>Re: [ovirt-users] gluster-server 3.5.2 requies gluasterfs-3.52<br> <br> The node would pull the latest rpms based on your repo configuration. vdsm on the node has a requirement on glusterfs > 3.4.2.<br> <br> Which OS are you using. I wonder how you got the glusterfs 3.6 as they are not available in the download.gluster.org repo.<br> <br> Could you tell me the output of > rpm -qa | grep gluster<br> <br> <div class="moz-cite-prefix">On 11/03/2014 08:39 PM, Juan Carlos YJ. Lin wrote:<br> </div> <blockquote cite="mid:8a75feb1-79c4-4488-9a40-03b602d538ff@server1.monalisa.com.py"> <style>p { margin: 0; }</style> <div style="font-family: Arial; font-size: 10pt; color: #000000">so is correct the dependecy?<br> I try to install glusterfs-server in the node host and got the error<br> <span><br> <span></span>Juan Carlos Lin<br> Unisoft S.A.<br> +595-993-288330<span></span><br> </span><br> <hr id="zwchr"> <div style="color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>De: </b>"Sahina Bose" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:sabose@redhat.com" target="_blank"><sabose(a)redhat.com></a><br> <b>Para: </b>"Juan Carlos YJ Lin" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:lin@unisoft.com.py" target="_blank"><lin(a)unisoft.com.py></a>, <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:users@ovirt.org" target="_blank">users(a)ovirt.org</a><br> <b>Enviados: </b>Lunes, 3 de Noviembre 2014 5:17:30<br> <b>Asunto: </b>Re: [ovirt-users] gluster-server 3.5.2 requies gluasterfs-3.52<br> <br> <br> <div class="moz-cite-prefix">On 11/03/2014 01:44 PM, Sahina Bose wrote:<br> </div> <blockquote cite="mid:5457394E.70600@redhat.com"> ovirt 3.5 does not have a dependency on glusterfs-3.6.0, AFAIK. 3.6 is in beta stage still.<br> </blockquote> <br> My bad. glusterfs 3.6 was released on Oct 31.<br> <br> <blockquote cite="mid:5457394E.70600@redhat.com"> <br> Are you installing hosted engine? Do you by any chance have additional repos for glusterfs configured?<br> <br> <div class="moz-cite-prefix">On 11/03/2014 05:44 AM, Juan Carlos YJ. Lin wrote:<br> </div> <blockquote cite="mid:97ec2371-4c99-409a-9a82-aefde04ca568@server1.monalisa.com.py"> <style>p { margin: 0; }</style> <div style="font-family: Arial; font-size: 10pt; color: #000000"><span>gluster-server 3.5.2 requies gluasterfs-3.52, but ovirt3.5 install glusterfs-3.6.0<br> how to solve the dependency?<br> <br> <span></span>Juan Carlos Lin<br> Unisoft S.A.<br> +595-993-288330<span></span><br> </span><br> </div> <br> <title>System-wide Disclaimer</title> ---------------------------------------------------<br> "Antes de imprimir, recuérdese de su compromiso con el Medio Ambiente"<br> "Aviso: Este mensaje es dirigido para su destinatario y contiene informaciones que no pueden ser usadas por otras personas que no sean su(s) destinatario(s). La retransmisión del contenido no está autorizada fuera del contexto de su envío y a quien corresponde. El uso no autorizado de la información en este mensaje se halla penado por las leyes vigentes en todo el mundo. Si ha recibido este mensaje por error, por favor bórrala y notifique al remitente en la brevedad posible. El contenido de este mensaje no es responsabilidad de la Empresa y debe ser atribuido siempre a su autor. Gracias." <br> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre>_______________________________________________ Users mailing list <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Users@ovirt.org" target="_blank">Users(a)ovirt.org</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/mailman/listinfo/users</a> </pre> </blockquote> <br> </blockquote> <br> </div> <br> </div> <br> <title>System-wide Disclaimer</title> ---------------------------------------------------<br> "Antes de imprimir, recuérdese de su compromiso con el Medio Ambiente"<br> "Aviso: Este mensaje es dirigido para su destinatario y contiene informaciones que no pueden ser usadas por otras personas que no sean su(s) destinatario(s). La retransmisión del contenido no está autorizada fuera del contexto de su envío y a quien corresponde. El uso no autorizado de la información en este mensaje se halla penado por las leyes vigentes en todo el mundo. Si ha recibido este mensaje por error, por favor bórrala y notifique al remitente en la brevedad posible. El contenido de este mensaje no es responsabilidad de la Empresa y debe ser atribuido siempre a su autor. Gracias." <br> </blockquote> <br> </div> <br> </div> <br> <title>System-wide Disclaimer</title> ---------------------------------------------------<br> "Antes de imprimir, recuérdese de su compromiso con el Medio Ambiente"<br> "Aviso: Este mensaje es dirigido para su destinatario y contiene informaciones que no pueden ser usadas por otras personas que no sean su(s) destinatario(s). La retransmisión del contenido no está autorizada fuera del contexto de su envío y a quien corresponde. El uso no autorizado de la información en este mensaje se halla penado por las leyes vigentes en todo el mundo. Si ha recibido este mensaje por error, por favor bórrala y notifique al remitente en la brevedad posible. El contenido de este mensaje no es responsabilidad de la Empresa y debe ser atribuido siempre a su autor. Gracias." <br> </blockquote> <br> </body> </html> --------------000803040704030401050000--

1 0

vdsm and selinux
by Kapetanakis Giannis 05 Nov '14

05 Nov '14

Hi, Can someone post status on this one? https://bugzilla.redhat.com/show_bug.cgi?id=1157185 I got into this one in one of my hosts after upgrading to Centos 6.6 and vdsm-4.16.7-1.gitdb83943.el6.x86_64 thanks G

2 2

Re: [ovirt-users] Host remains in contending for storage pool manager
by Gianluca Cecchi 05 Nov '14

05 Nov '14

On Tue, Nov 4, 2014 at 11:39 AM, Itamar Heim <iheim(a)redhat.com> wrote: > On 10/27/2014 06:48 PM, Gianluca Cecchi wrote: > >> Hello, >> an iSCSI SD went down and it seems it is not able to come up again. >> >> From an iSCSI point of view all seems ok.. >> >> [root@ovnode04 vdsm]# iscsiadm -m session -P 1 >> Target: iqn.2014-07.local.localdomain:store1 >> Current Portal: 10.10.1.71:3260 <http://10.10.1.71:3260>,1 >> Persistent Portal: 10.10.1.71:3260 <http://10.10.1.71:3260>,1 >> >> ********** >> Interface: >> ********** >> Iface Name: default >> Iface Transport: tcp >> Iface Initiatorname: iqn.1994-05.com.redhat:5d9b31319a8e >> Iface IPaddress: 10.10.1.61 >> Iface HWaddress: <empty> >> Iface Netdev: <empty> >> SID: 1 >> iSCSI Connection State: LOGGED IN >> iSCSI Session State: LOGGED_IN >> Internal iscsid Session State: NO CHANGE >> >> >> [root@ovnode04 vdsm]# multipath -l >> 1p_iscsi_store1_l dm-2 IET,VIRTUAL-DISK >> size=200G features='0' hwhandler='0' wp=rw >> `-+- policy='round-robin 0' prio=0 status=active >> `- 1:0:0:1 sdb 8:16 active undef running >> >> Access to the lun seems ok: >> [root@ovnode04 ~]# time dd if=/dev/mapper/1p_iscsi_store1_l of=/dev/null >> bs=1024k count=1024 >> 1024+0 records in >> 1024+0 records out >> 1073741824 bytes (1.1 GB) copied, 9.24202 s, 116 MB/s >> >> real0m9.247s >> user0m0.002s >> sys0m0.463s >> >> >> But it continues to remain in contending and never comes to master. >> >> >> Failed to activate Storage Domain istore1 (Data Center iscsidc) by ovadmin >> >> I only have this host in this cluster. >> What to do? >> Already tried to restart both engine service on engine host and vdsmd >> service on the host. >> >> Any other commands to check anything? >> >> Gianluca >> >> >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> >> > resolved? > yes, thanks. I had to restart also host itself to regain access to SD.... One note about the SD: it is iSCSI configured as sw iscsi target in HA with Pacemaker and drbd. I had a problem on one node and apparently this was not so transparent to oVirt host. I didn't have time to check more deeply.... Gianluca

2 2

using ovirt-scheduler-proxy
by Amedeo Salvati 05 Nov '14

05 Nov '14

--_=__=_XaM3_.1415114544.2A.578889.42.26172.52.42.007.1756584802 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A hello guys,=0A I'm triyng to use ovirt-scheduler-proxy, and for t= his, now, I'm starting with examples available on:=0A https://github.co= m/oVirt/ovirt-scheduler-proxy/tree/master/doc/plugin_samples=0A so, on = ovirt 3.5 fresh installation I've installed ovirt-scheduler-proxy package= (by yum), then I've downloaded from above link host_memory_balance.py fi= le under /usr/share/ovirt-scheduler-proxy/plugins directory, I've changed= the connection string due to reflect my ovirt engine hostname/port/user/= password, and finally I've started the service:=0A service ovirt-schedu= ler-proxy start=0A on log ovirt-scheduler-proxy.log I got:=0A [root@e= ngine ovirt-scheduler-proxy]# cat /var/log/ovirt-scheduler-proxy/ovirt-sc= heduler-proxy.log=0A Tue, 04 Nov 2014 16:01:17 INFO [process:MainPr= ocess, thread:MainThread] Setting up server=0A Tue, 04 Nov 2014 16:01:1= 7 INFO [process:MainProcess, thread:MainThread] Loading modules from = /usr/share/ovirt-scheduler-proxy/plugins=0A Tue, 04 Nov 2014 16:01:17 I= NFO [process:MainProcess, thread:MainThread] Loading analyzer from /u= sr/lib/python2.6/site-packages/ovirtscheduler=0A Tue, 04 Nov 2014 16:01= :17 INFO [process:MainProcess, thread:MainThread] [Request:Main][Meth= od:loadModules] - Trying to load the following files: ['host_memory_balan= ce']=0A Tue, 04 Nov 2014 16:01:17 DEBUG [process:MainProcess, thread= :Thread-1] [Request:Main][Method:PythonMethodRunner] - running ['python',= '-c', "import loader; loader.loader().analyze('/usr/share/ovirt-schedule= r-proxy/plugins', 'host_memory_balance')"] in /usr/lib/python2.6/site-pac= kages/ovirtscheduler=0A Tue, 04 Nov 2014 16:01:18 DEBUG [process:Mai= nProcess, thread:MainThread] [Request:Main][Method:loadModules] - script:= ['python', '-c', "import loader; loader.loader().analyze('/usr/share/ovi= rt-scheduler-proxy/plugins', 'host_memory_balance')"]=0A Tue, 04 Nov 20= 14 16:01:18 INFO [process:MainProcess, thread:MainThread] [Request:Ma= in][Method:loadModules] - registering: ('host_memory_balance', ('host_mem= ory_balance', 'do_balance', 'selects a vm from the most over utilized vm = to migrate.\n if safe_selection is true selects the smallest vm fr= om the host\n if safe_selection is false try and take a vm larger = then the amount of memory the host is missing', 'minimum_host_memoryMB=3D= [0-9]*;safe_selection=3DTrue|False'))=0A Tue, 04 Nov 2014 16:01:18 INFO= [process:MainProcess, thread:MainThread] [Request:Main][Method:loadM= odules] - registering::loaded- filters:{} scores:{} balancers:{'hos= t_memory_balance': ('selects a vm from the most over utilized vm to migra= te.\n if safe_selection is true selects the smallest vm from the h= ost\n if safe_selection is false try and take a vm larger then the= amount of memory the host is missing', 'minimum_host_memoryMB=3D[0-9]*;s= afe_selection=3DTrue|False')}=0A Tue, 04 Nov 2014 16:01:18 INFO [pr= ocess:MainProcess, thread:MainThread] Publishing API=0A [root@engine ov= irt-scheduler-proxy]#=0A but after that on web ui I can't see any chang= e under cluster policy and under Configure -> Cluster Policies (host_memo= ry_balance balancers is not displayed)=0A what did I miss?=0A Best re= gards=0A Amedeo Salvati=0A --_=__=_XaM3_.1415114544.2A.578889.42.26172.52.42.007.1756584802 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A<div class=3D"xam_msg_class">=0A<font size=3D"2">hello guys,<br /><br = />I'm triyng to use ovirt-scheduler-proxy, and for this, now, I'm startin= g with examples available on:<br /><br />https://github.com/oVirt/ovirt-s= cheduler-proxy/tree/master/doc/plugin_samples<br /><br />so, on ovirt 3.5= fresh installation I've installed ovirt-scheduler-proxy package (by yum)= , then I've downloaded from above link host_memory_balance.py file under = /usr/share/ovirt-scheduler-proxy/plugins directory, I've changed the conn= ection string due to reflect my ovirt engine hostname/port/user/password,= and finally I've started the service:<br /><br />service ovirt-scheduler= -proxy start<br /><br />on log ovirt-scheduler-proxy.log I got:<br /><br = /><br />[root@engine ovirt-scheduler-proxy]# cat /var/log/ovirt-scheduler= -proxy/ovirt-scheduler-proxy.log <br />Tue, 04 Nov 2014 16:01:17 INFO=C2=A0= =C2=A0=C2=A0=C2=A0 [process:MainProcess, thread:MainThread] Setting up se= rver<br />Tue, 04 Nov 2014 16:01:17 INFO=C2=A0=C2=A0=C2=A0=C2=A0 [process= :MainProcess, thread:MainThread] Loading modules from /usr/share/ovirt-sc= heduler-proxy/plugins<br />Tue, 04 Nov 2014 16:01:17 INFO=C2=A0=C2=A0=C2=A0= =C2=A0 [process:MainProcess, thread:MainThread] Loading analyzer from /us= r/lib/python2.6/site-packages/ovirtscheduler<br />Tue, 04 Nov 2014 16:01:= 17 INFO=C2=A0=C2=A0=C2=A0=C2=A0 [process:MainProcess, thread:MainThread] = [Request:Main][Method:loadModules] - Trying to load the following files: = ['host_memory_balance']<br />Tue, 04 Nov 2014 16:01:17 DEBUG=C2=A0=C2=A0=C2= =A0 [process:MainProcess, thread:Thread-1] [Request:Main][Method:PythonMe= thodRunner] - running ['python', '-c', "import loader; loader.loader= ().analyze('/usr/share/ovirt-scheduler-proxy/plugins', 'host_memory_balan= ce')"] in /usr/lib/python2.6/site-packages/ovirtscheduler<br />Tue, = 04 Nov 2014 16:01:18 DEBUG=C2=A0=C2=A0=C2=A0 [process:MainProcess, thread= :MainThread] [Request:Main][Method:loadModules] - script: ['python', '-c'= , "import loader; loader.loader().analyze('/usr/share/ovirt-schedule= r-proxy/plugins', 'host_memory_balance')"]<br />Tue, 04 Nov 2014 16:= 01:18 INFO=C2=A0=C2=A0=C2=A0=C2=A0 [process:MainProcess, thread:MainThrea= d] [Request:Main][Method:loadModules] - registering: ('host_memory_balanc= e', ('host_memory_balance', 'do_balance', 'selects a vm from the most ove= r utilized vm to migrate.\n=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if = safe_selection is true selects the smallest vm from the host\n=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if safe_selection is false try and take a = vm larger then the amount of memory the host is missing', 'minimum_host_m= emoryMB=3D[0-9]*;safe_selection=3DTrue|False'))<br />Tue, 04 Nov 2014 16:= 01:18 INFO=C2=A0=C2=A0=C2=A0=C2=A0 [process:MainProcess, thread:MainThrea= d] [Request:Main][Method:loadModules] - registering::loaded- filters:{}=C2= =A0=C2=A0=C2=A0 scores:{}=C2=A0=C2=A0=C2=A0 balancers:{'host_memory_balan= ce': ('selects a vm from the most over utilized vm to migrate.\n=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if safe_selection is true selects the s= mallest vm from the host\n=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if s= afe_selection is false try and take a vm larger then the amount of memory= the host is missing', 'minimum_host_memoryMB=3D[0-9]*;safe_selection=3DT= rue|False')}<br />Tue, 04 Nov 2014 16:01:18 INFO=C2=A0=C2=A0=C2=A0=C2=A0 = [process:MainProcess, thread:MainThread] Publishing API<br />[root@engine= ovirt-scheduler-proxy]#<br /><br />but after that on web ui I can't see = any change under cluster policy and under Configure -> Cluster Policie= s (host_memory_balance balancers is not displayed)<br /><br />what did I = miss?<br /><br />Best regards<br />Amedeo Salvati</font>=0A</div>=0A --_=__=_XaM3_.1415114544.2A.578889.42.26172.52.42.007.1756584802--

2 1

importing a qcow2 disk into ovirt 3.5?
by Paul Jansen 05 Nov '14

05 Nov '14

---360795340-60103579-1413869259=:71234 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I've just been doing some searching to try and work out how to get a vmware= windows VM into ovirt.=0AIt seems that the newest virtv2v has dropped supp= ort for importing from an ESXi standalone machine - and now only works with= vcenter. I didn't have any success with using the current virt-v2v attach= ing to an ESXi host.=0A=0A=0AI've prepared the VM by first removing the vmw= are tools and have installled the various virtio drivers, as well as runnin= g the 'mergeide' registry file to enable IDE. I've used 'qemu-img' to conv= irt this VMDK file to QCOW2. It does not appear that there is a straightfo= rward way for me to import this new qcow2 disk into ovirt.=0A=0AIt seems my= best option at the moment is to export the VMware VM as an OVA and then tr= y and use a newer virt-v2v to import this into ovirt.=0AAlternatively I cou= ld construct a VM in virt-manager and attach the converted qcow2 disk to it= , and then use virt-v2v to import this into ovirt.=0A=0ACan someone suggest= an alternative course of action? It seems strange that I can't just impor= t a disk into ovirt, construct a VM and attach the disk.=0A=0AIs there any= thing int he works to make this process easier?=0A=0AThanks,=0APaul=0A ---360795340-60103579-1413869259=:71234 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:He= lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;fo= nt-size:12px"><div>I've just been doing some searching to try and work out = how to get a vmware windows VM into ovirt.</div><div>It seems that the newe= st virtv2v has dropped support for importing from an ESXi standalone machin= e - and now only works with vcenter.  I didn't have any success with u= sing the current virt-v2v attaching to an ESXi host.<br></div><div><br></di= v><div style=3D"color: rgb(0, 0, 0); font-size: 12px; font-family: Helvetic= aNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-c= olor: transparent; font-style: normal;">I've prepared the VM by first remov= ing the vmware tools and have installled the various virtio drivers, as wel= l as running the 'mergeide' registry file to enable IDE.  I've used 'q= emu-img' to convirt this VMDK file to QCOW2.  It does not appear that there is a straightforward way for me to import this new qcow2 disk i= nto ovirt.</div><div style=3D"color: rgb(0, 0, 0); font-size: 12px; font-fa= mily: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif= ; background-color: transparent; font-style: normal;"><br></div><div style= =3D"color: rgb(0, 0, 0); font-size: 12px; font-family: HelveticaNeue,Helvet= ica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transp= arent; font-style: normal;">It seems my best option at the moment is to exp= ort the VMware VM as an OVA and then try and use a newer virt-v2v to import= this into ovirt.</div><div style=3D"color: rgb(0, 0, 0); font-size: 12px; = font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,san= s-serif; background-color: transparent; font-style: normal;">Alternatively = I could construct a VM in virt-manager and attach the converted qcow2 disk = to it, and then use virt-v2v to import this into ovirt.</div><div style=3D"color: rgb(0, 0, 0); font-size: 12px; font-family: HelveticaNeue,= Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: = transparent; font-style: normal;"><br></div><div style=3D"color: rgb(0, 0, = 0); font-size: 12px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Ar= ial,Lucida Grande,sans-serif; background-color: transparent; font-style: no= rmal;">Can someone suggest an alternative course of action?  It seems = strange that I can't just import a disk into ovirt,  construct a VM an= d attach the disk.</div><div style=3D"color: rgb(0, 0, 0); font-size: 12px;= font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sa= ns-serif; background-color: transparent; font-style: normal;"><br></div><di= v style=3D"color: rgb(0, 0, 0); font-size: 12px; font-family: HelveticaNeue= ,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color:= transparent; font-style: normal;">Is there anything int he works to make this process easier?</div><div style=3D"color: rgb(0, 0, 0); font-size: 12= px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande= ,sans-serif; background-color: transparent; font-style: normal;"><br></div>= <div style=3D"color: rgb(0, 0, 0); font-size: 12px; font-family: HelveticaN= eue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-col= or: transparent; font-style: normal;">Thanks,</div><div style=3D"color: rgb= (0, 0, 0); font-size: 12px; font-family: HelveticaNeue,Helvetica Neue,Helve= tica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-st= yle: normal;">Paul</div><div style=3D"color: rgb(0, 0, 0); font-size: 12px;= font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sa= ns-serif; background-color: transparent; font-style: normal;"><br></div></d= iv></body></html> ---360795340-60103579-1413869259=:71234--

8 10

Slow resync with GlusterFS Replication
by ml ml 05 Nov '14

05 Nov '14

Hello List, i have a 2 Node Cluster with GlusterFS. After putting one machine in Maintance and turning it off and on again the glustefs starts its resync. However, this process seems to be very slow. iotop and iftop only show me a few hundred K/s. Is this normal? Thanks, Mario

2 1