Hi, first of all , thanks to all the Ovirt/Rhev team for the outstanding work! we are having a small issue with Ovirt 4.0.5 after testing a full end of year infrastructure shutdown, everything came back correctly except that we get a 'Deactivating Storage Domain' under the tasks tab. another dc/cluster running 3.6.7 reported no error with same maintenance procedure.. maybe we did something wrong? would you please be so kind to point me on the right direction to fix it? I looked vdsClient -s 0 getAllTasks , but returns nothing... thanks for your time guys and merry christmas and happy new year if we dont talk again soon! JP
Hi, Did you check for running tasks in the SPM host? On Tue, Dec 20, 2016 at 5:04 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi, first of all , thanks to all the Ovirt/Rhev team for the outstanding work!
we are having a small issue with Ovirt 4.0.5 after testing a full end of year infrastructure shutdown, everything came back correctly except that we get a 'Deactivating Storage Domain' under the tasks tab. another dc/cluster running 3.6.7 reported no error with same maintenance procedure.. maybe we did something wrong?
would you please be so kind to point me on the right direction to fix it? I looked
vdsClient -s 0 getAllTasks , but returns nothing...
thanks for your time guys and merry christmas and happy new year if we dont talk again soon! JP
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Hi, thanks for your reply, I did check with vdsClient -s 0 getAllTasks , returned nothing. is this still the correct way to check? regards, JP 2016-12-20 12:32 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
Hi,
Did you check for running tasks in the SPM host?
On Tue, Dec 20, 2016 at 5:04 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi, first of all , thanks to all the Ovirt/Rhev team for the outstanding work!
we are having a small issue with Ovirt 4.0.5 after testing a full end of year infrastructure shutdown, everything came back correctly except that we get a 'Deactivating Storage Domain' under the tasks tab. another dc/cluster running 3.6.7 reported no error with same maintenance procedure.. maybe we did something wrong?
would you please be so kind to point me on the right direction to fix it? I looked
vdsClient -s 0 getAllTasks , but returns nothing...
thanks for your time guys and merry christmas and happy new year if we dont talk again soon! JP
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
It's OK, but you need to make sure you're checking it on the host which has the SPM role. So, first check on the host that it is the current SPM with the following: vdsClient -s 0 getSpmStatus `vdsClient -s 0 getConnectedStoragePoolsList` Look for the host that has " spmStatus = SPM" And after you find the SPM, check for the running tasks as you did before. On Tue, Dec 20, 2016 at 5:37 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi, thanks for your reply, I did check with vdsClient -s 0 getAllTasks , returned nothing. is this still the correct way to check?
regards, JP
2016-12-20 12:32 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
Hi,
Did you check for running tasks in the SPM host?
On Tue, Dec 20, 2016 at 5:04 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi, first of all , thanks to all the Ovirt/Rhev team for the outstanding work!
we are having a small issue with Ovirt 4.0.5 after testing a full end of year infrastructure shutdown, everything came back correctly except that we get a 'Deactivating Storage Domain' under the tasks tab. another dc/cluster running 3.6.7 reported no error with same maintenance procedure.. maybe we did something wrong?
would you please be so kind to point me on the right direction to fix it? I looked
vdsClient -s 0 getAllTasks , but returns nothing...
thanks for your time guys and merry christmas and happy new year if we dont talk again soon! JP
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Elad, I did that and running the commands on the SPM returned : [root@virt01-int ~]# vdsClient -s 0 getAllTasks [root@virt01-int ~]# vdsClient -s 0 getSpmStatus `vdsClient -s 0 getConnectedStoragePoolsList` spmId = 1 spmStatus = SPM spmLver = 8 [root@virt01-int ~]# vdsClient -s 0 getAllTasks [root@virt01-int ~]# thanks for your time, JP 2016-12-20 12:55 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
It's OK, but you need to make sure you're checking it on the host which has the SPM role. So, first check on the host that it is the current SPM with the following:
vdsClient -s 0 getSpmStatus `vdsClient -s 0 getConnectedStoragePoolsList`
Look for the host that has " spmStatus = SPM"
And after you find the SPM, check for the running tasks as you did before.
On Tue, Dec 20, 2016 at 5:37 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi, thanks for your reply, I did check with vdsClient -s 0 getAllTasks , returned nothing. is this still the correct way to check?
regards, JP
2016-12-20 12:32 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
Hi,
Did you check for running tasks in the SPM host?
On Tue, Dec 20, 2016 at 5:04 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi, first of all , thanks to all the Ovirt/Rhev team for the outstanding work!
we are having a small issue with Ovirt 4.0.5 after testing a full end of year infrastructure shutdown, everything came back correctly except that we get a 'Deactivating Storage Domain' under the tasks tab. another dc/cluster running 3.6.7 reported no error with same maintenance procedure.. maybe we did something wrong?
would you please be so kind to point me on the right direction to fix it? I looked
vdsClient -s 0 getAllTasks , but returns nothing...
thanks for your time guys and merry christmas and happy new year if we dont talk again soon! JP
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Do you have a storage domain in the DC in status 'locked'? On Tue, Dec 20, 2016 at 6:09 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Elad, I did that and running the commands on the SPM returned :
[root@virt01-int ~]# vdsClient -s 0 getAllTasks
[root@virt01-int ~]# vdsClient -s 0 getSpmStatus `vdsClient -s 0 getConnectedStoragePoolsList` spmId = 1 spmStatus = SPM spmLver = 8
[root@virt01-int ~]# vdsClient -s 0 getAllTasks
[root@virt01-int ~]#
thanks for your time, JP
2016-12-20 12:55 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
It's OK, but you need to make sure you're checking it on the host which has the SPM role. So, first check on the host that it is the current SPM with the following:
vdsClient -s 0 getSpmStatus `vdsClient -s 0 getConnectedStoragePoolsList`
Look for the host that has " spmStatus = SPM"
And after you find the SPM, check for the running tasks as you did before.
On Tue, Dec 20, 2016 at 5:37 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi, thanks for your reply, I did check with vdsClient -s 0 getAllTasks , returned nothing. is this still the correct way to check?
regards, JP
2016-12-20 12:32 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
Hi,
Did you check for running tasks in the SPM host?
On Tue, Dec 20, 2016 at 5:04 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi, first of all , thanks to all the Ovirt/Rhev team for the outstanding work!
we are having a small issue with Ovirt 4.0.5 after testing a full end of year infrastructure shutdown, everything came back correctly except that we get a 'Deactivating Storage Domain' under the tasks tab. another dc/cluster running 3.6.7 reported no error with same maintenance procedure.. maybe we did something wrong?
would you please be so kind to point me on the right direction to fix it? I looked
vdsClient -s 0 getAllTasks , but returns nothing...
thanks for your time guys and merry christmas and happy new year if we dont talk again soon! JP
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
I don't, attaching screenshot: [image: Imágenes integradas 1] also, output from getstoragedomaininfo [root@virt01-int ~]# vdsClient -s 0 getStorageDomainsList e6a85203-32e0-4200-b3d7-83f140203294 6b031086-1b42-4066-a7a0-c481ef16e15e 31910316-4978-4101-ba47-adb8362e3de1 04ceb9ff-88c5-4a91-877b-0a4f10703e3c [root@virt01-int ~]# vdsClient -s 0 getStorageDomainStats e6a85203-32e0-4200-b3d7-83f140203294 disktotal = 3757693730816 (3.0TB) diskfree = 1264330997760 (1.0TB) [root@virt01-int ~]# vdsClient -s 0 getStorageDomainInfo e6a85203-32e0-4200-b3d7-83f140203294 uuid = e6a85203-32e0-4200-b3d7-83f140203294 vguuid = fDclFZ-KLel-t36P-VAFm-hyle-RxcU-uOc7gj state = OK version = 3 role = Master type = ISCSI class = Data pool = ['58405b2d-0094-0380-0260-0000000000a5'] name = nas01 [root@virt01-int ~]# vdsClient -s 0 getStorageDomainInfo 6b031086-1b42-4066-a7a0-c481ef16e15e uuid = 6b031086-1b42-4066-a7a0-c481ef16e15e version = 3 role = Regular remotePath = 10.40.255.153:/mnt/pool00nas01/HEstorage type = NFS class = Data pool = ['58405b2d-0094-0380-0260-0000000000a5'] name = hosted_storage [root@virt01-int ~]# vdsClient -s 0 getStorageDomainInfo 31910316-4978-4101-ba47-adb8362e3de1 uuid = 31910316-4978-4101-ba47-adb8362e3de1 version = 0 role = Regular remotePath = 10.40.255.153:/mnt/pool00nas01/isos type = NFS class = Iso pool = ['58405b2d-0094-0380-0260-0000000000a5'] name = isos [root@virt01-int ~]# vdsClient -s 0 getStorageDomainInfo 04ceb9ff-88c5-4a91-877b-0a4f10703e3c uuid = 04ceb9ff-88c5-4a91-877b-0a4f10703e3c version = 0 role = Regular remotePath = 10.40.255.250:/mnt/pool02nas00/backups type = NFS class = Backup pool = ['58405b2d-0094-0380-0260-0000000000a5'] name = backups thanks again, JP 2016-12-20 13:24 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
Do you have a storage domain in the DC in status 'locked'?
On Tue, Dec 20, 2016 at 6:09 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Elad, I did that and running the commands on the SPM returned :
[root@virt01-int ~]# vdsClient -s 0 getAllTasks
[root@virt01-int ~]# vdsClient -s 0 getSpmStatus `vdsClient -s 0 getConnectedStoragePoolsList` spmId = 1 spmStatus = SPM spmLver = 8
[root@virt01-int ~]# vdsClient -s 0 getAllTasks
[root@virt01-int ~]#
thanks for your time, JP
2016-12-20 12:55 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
It's OK, but you need to make sure you're checking it on the host which has the SPM role. So, first check on the host that it is the current SPM with the following:
vdsClient -s 0 getSpmStatus `vdsClient -s 0 getConnectedStoragePoolsList`
Look for the host that has " spmStatus = SPM"
And after you find the SPM, check for the running tasks as you did before.
On Tue, Dec 20, 2016 at 5:37 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi, thanks for your reply, I did check with vdsClient -s 0 getAllTasks , returned nothing. is this still the correct way to check?
regards, JP
2016-12-20 12:32 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
Hi,
Did you check for running tasks in the SPM host?
On Tue, Dec 20, 2016 at 5:04 PM, Juan Pablo <pablo.localhost@gmail.com
wrote:
Hi, first of all , thanks to all the Ovirt/Rhev team for the outstanding work!
we are having a small issue with Ovirt 4.0.5 after testing a full end of year infrastructure shutdown, everything came back correctly except that we get a 'Deactivating Storage Domain' under the tasks tab. another dc/cluster running 3.6.7 reported no error with same maintenance procedure.. maybe we did something wrong?
would you please be so kind to point me on the right direction to fix it? I looked
vdsClient -s 0 getAllTasks , but returns nothing...
thanks for your time guys and merry christmas and happy new year if we dont talk again soon! JP
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
--_000_BN6PR14MB168311E0B3CFEE926D92AF24E9900BN6PR14MB1683namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZW1lbWJlciBmYWNpbmcgYSBzaW1pbGFyIGlzc3VlIGR1cmluZyBkZWNvbW1pc3Npb25pbmcg b2YgbXkgT3ZpcnQgMyBlbnZpcm9ubWVudC4NClNldmVyYWwgdGFza3Mgc2hvd2VkIG9uIEdVSSAo YW5kIHN0b3JhZ2Ugb3BlcmF0aW9ucyB1bmF2YWlsYWJsZSkgYnV0IG5vIHRhc2tzIG9uIGNvbW1h bmQgbGluZS4NCkV2ZW50dWFsbHkgcmVzdGFydGluZyB0aGUgZW5naW5lIFZNIGNsZWFuZWQgdXAg dGhlIHNpdHVhdGlvbiBhbmQgbWFkZSB0aGUgc3RvcmFnZSBhdmFpbCBhZ2Fpbi4NCg0KQ2hlZXJz DQpBRw0KDQpGcm9tOiB1c2Vycy1ib3VuY2VzQG92aXJ0Lm9yZyBbbWFpbHRvOnVzZXJzLWJvdW5j ZXNAb3ZpcnQub3JnXSBPbiBCZWhhbGYgT2YgRWxhZCBCZW4gQWhhcm9uDQpTZW50OiBUdWVzZGF5 LCBEZWNlbWJlciAyMCwgMjAxNiA1OjI0IFBNDQpUbzogSnVhbiBQYWJsbyA8cGFibG8ubG9jYWxo b3N0QGdtYWlsLmNvbT4NCkNjOiB1c2VycyA8VXNlcnNAb3ZpcnQub3JnPg0KU3ViamVjdDogUmU6 IFtvdmlydC11c2Vyc10gIkRlYWN0aXZhdGluZyBTdG9yYWdlIERvbWFpbiIgZXJyb3INCg0KRG8g eW91IGhhdmUgYSBzdG9yYWdlIGRvbWFpbiBpbiB0aGUgREMgaW4gc3RhdHVzICdsb2NrZWQnPw0K DQpPbiBUdWUsIERlYyAyMCwgMjAxNiBhdCA2OjA5IFBNLCBKdWFuIFBhYmxvIDxwYWJsby5sb2Nh bGhvc3RAZ21haWwuY29tPG1haWx0bzpwYWJsby5sb2NhbGhvc3RAZ21haWwuY29tPj4gd3JvdGU6 DQpFbGFkLCBJIGRpZCB0aGF0IGFuZCBydW5uaW5nIHRoZSBjb21tYW5kcyBvbiB0aGUgU1BNICBy ZXR1cm5lZCA6DQoNCltyb290QHZpcnQwMS1pbnQgfl0jIHZkc0NsaWVudCAtcyAwIGdldEFsbFRh c2tzDQoNCltyb290QHZpcnQwMS1pbnQgfl0jIHZkc0NsaWVudCAtcyAwIGdldFNwbVN0YXR1cyBg dmRzQ2xpZW50IC1zIDAgZ2V0Q29ubmVjdGVkU3RvcmFnZVBvb2xzTGlzdGANCiAgICBzcG1JZCA9 IDENCiAgICBzcG1TdGF0dXMgPSBTUE0NCiAgICBzcG1MdmVyID0gOA0KDQpbcm9vdEB2aXJ0MDEt aW50IH5dIyB2ZHNDbGllbnQgLXMgMCBnZXRBbGxUYXNrcw0KDQpbcm9vdEB2aXJ0MDEtaW50IH5d Iw0KDQp0aGFua3MgZm9yIHlvdXIgdGltZSwNCkpQDQoNCjIwMTYtMTItMjAgMTI6NTUgR01ULTAz OjAwIEVsYWQgQmVuIEFoYXJvbiA8ZWJlbmFoYXJAcmVkaGF0LmNvbTxtYWlsdG86ZWJlbmFoYXJA cmVkaGF0LmNvbT4+Og0KSXQncyBPSywgYnV0IHlvdSBuZWVkIHRvIG1ha2Ugc3VyZSB5b3UncmUg Y2hlY2tpbmcgaXQgb24gdGhlIGhvc3Qgd2hpY2ggaGFzIHRoZSBTUE0gcm9sZS4gU28sIGZpcnN0 IGNoZWNrIG9uIHRoZSBob3N0IHRoYXQgaXQgaXMgdGhlIGN1cnJlbnQgU1BNIHdpdGggdGhlIGZv bGxvd2luZzoNCg0KdmRzQ2xpZW50IC1zIDAgZ2V0U3BtU3RhdHVzIGB2ZHNDbGllbnQgLXMgMCBn ZXRDb25uZWN0ZWRTdG9yYWdlUG9vbHNMaXN0YA0KTG9vayBmb3IgdGhlIGhvc3QgdGhhdCBoYXMg IiBzcG1TdGF0dXMgPSBTUE0iDQpBbmQgYWZ0ZXIgeW91IGZpbmQgdGhlIFNQTSwgY2hlY2sgZm9y IHRoZSBydW5uaW5nIHRhc2tzIGFzIHlvdSBkaWQgYmVmb3JlLg0KDQoNCk9uIFR1ZSwgRGVjIDIw LCAyMDE2IGF0IDU6MzcgUE0sIEp1YW4gUGFibG8gPHBhYmxvLmxvY2FsaG9zdEBnbWFpbC5jb208 bWFpbHRvOnBhYmxvLmxvY2FsaG9zdEBnbWFpbC5jb20+PiB3cm90ZToNCkhpLA0KIHRoYW5rcyBm b3IgeW91ciByZXBseSwgSSBkaWQgY2hlY2sgd2l0aCB2ZHNDbGllbnQgLXMgMCBnZXRBbGxUYXNr cyAsIHJldHVybmVkIG5vdGhpbmcuIGlzIHRoaXMgc3RpbGwgdGhlIGNvcnJlY3Qgd2F5IHRvIGNo ZWNrPw0KcmVnYXJkcywNCkpQDQoNCg0KMjAxNi0xMi0yMCAxMjozMiBHTVQtMDM6MDAgRWxhZCBC ZW4gQWhhcm9uIDxlYmVuYWhhckByZWRoYXQuY29tPG1haWx0bzplYmVuYWhhckByZWRoYXQuY29t Pj46DQpIaSwNCg0KRGlkIHlvdSBjaGVjayBmb3IgcnVubmluZyB0YXNrcyBpbiB0aGUgU1BNIGhv c3Q/DQoNCg0KT24gVHVlLCBEZWMgMjAsIDIwMTYgYXQgNTowNCBQTSwgSnVhbiBQYWJsbyA8cGFi bG8ubG9jYWxob3N0QGdtYWlsLmNvbTxtYWlsdG86cGFibG8ubG9jYWxob3N0QGdtYWlsLmNvbT4+ IHdyb3RlOg0KSGksDQpmaXJzdCBvZiBhbGwgLCB0aGFua3MgdG8gYWxsIHRoZSBPdmlydC9SaGV2 IHRlYW0gZm9yIHRoZSBvdXRzdGFuZGluZyB3b3JrIQ0KDQp3ZSBhcmUgaGF2aW5nIGEgc21hbGwg aXNzdWUgd2l0aCBPdmlydCA0LjAuNSBhZnRlciB0ZXN0aW5nIGEgZnVsbCBlbmQgb2YgeWVhciBp bmZyYXN0cnVjdHVyZSBzaHV0ZG93biwgZXZlcnl0aGluZyBjYW1lIGJhY2sgY29ycmVjdGx5IGV4 Y2VwdCB0aGF0IHdlIGdldCBhICdEZWFjdGl2YXRpbmcgU3RvcmFnZSBEb21haW4nIHVuZGVyIHRo ZSB0YXNrcyB0YWIuDQphbm90aGVyIGRjL2NsdXN0ZXIgcnVubmluZyAzLjYuNyByZXBvcnRlZCBu byBlcnJvciB3aXRoIHNhbWUgbWFpbnRlbmFuY2UgcHJvY2VkdXJlLi4gbWF5YmUgd2UgZGlkIHNv bWV0aGluZyB3cm9uZz8NCndvdWxkIHlvdSBwbGVhc2UgYmUgc28ga2luZCB0byBwb2ludCBtZSBv biB0aGUgcmlnaHQgZGlyZWN0aW9uIHRvIGZpeCBpdD8gSSBsb29rZWQNCg0KdmRzQ2xpZW50IC1z IDAgZ2V0QWxsVGFza3MgLCBidXQgcmV0dXJucyBub3RoaW5nLi4uDQp0aGFua3MgZm9yIHlvdXIg dGltZSBndXlzIGFuZCBtZXJyeSBjaHJpc3RtYXMgYW5kIGhhcHB5IG5ldyB5ZWFyIGlmIHdlIGRv bnQgdGFsayBhZ2FpbiBzb29uIQ0KSlANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NClVzZXJzIG1haWxpbmcgbGlzdA0KVXNlcnNAb3ZpcnQub3JnPG1h aWx0bzpVc2Vyc0BvdmlydC5vcmc+DQpodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlz dGluZm8vdXNlcnMNCg0KDQoNCg0KDQo= --_000_BN6PR14MB168311E0B3CFEE926D92AF24E9900BN6PR14MB1683namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4ubS03ODUzODkxODgx NDA2NjMzNjUybS0xNDc4MjE1ODQyMjE5NDI2OTM0bTYwOTg2NTUyNzY2NDU1NDUwODVtNjk1NDY1 Mjg4ODk3ODE5MzAyN2hvZW56Yg0KCXttc28tc3R5bGUtbmFtZTptXy03ODUzODkxODgxNDA2NjMz NjUybV8tMTQ3ODIxNTg0MjIxOTQyNjkzNG1fNjA5ODY1NTI3NjY0NTU0NTA4NW1fNjk1NDY1Mjg4 ODk3ODE5MzAyN2hvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5JIHJlbWVtYmVyIGZhY2luZyBhIHNpbWlsYXIgaXNzdWUgZHVyaW5nIGRlY29tbWlzc2lvbmlu ZyBvZiBteSBPdmlydCAzIGVudmlyb25tZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U2V2ZXJhbCB0YXNrcyBzaG93ZWQgb24g R1VJIChhbmQgc3RvcmFnZSBvcGVyYXRpb25zIHVuYXZhaWxhYmxlKSBidXQgbm8gdGFza3Mgb24g Y29tbWFuZCBsaW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RXZlbnR1YWxseSByZXN0YXJ0aW5nIHRoZSBlbmdpbmUgVk0gY2xl YW5lZCB1cCB0aGUgc2l0dWF0aW9uIGFuZCBtYWRlIHRoZSBzdG9yYWdlIGF2YWlsIGFnYWluLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5DaGVlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFHPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiB1c2Vycy1ib3VuY2VzQG92aXJ0Lm9yZyBbbWFpbHRvOnVz ZXJzLWJvdW5jZXNAb3ZpcnQub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5FbGFkIEJlbiBBaGFy b248YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRGVjZW1iZXIgMjAsIDIwMTYgNToyNCBQTTxi cj4NCjxiPlRvOjwvYj4gSnVhbiBQYWJsbyAmbHQ7cGFibG8ubG9jYWxob3N0QGdtYWlsLmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IHVzZXJzICZsdDtVc2Vyc0BvdmlydC5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbb3ZpcnQtdXNlcnNdICZxdW90O0RlYWN0aXZhdGluZyBTdG9yYWdl IERvbWFpbiZxdW90OyBlcnJvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkRvIHlvdSBoYXZlIGEgc3RvcmFnZSBkb21haW4gaW4gdGhlIERDIGluIHN0YXR1cyAnbG9ja2Vk Jz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwg RGVjIDIwLCAyMDE2IGF0IDY6MDkgUE0sIEp1YW4gUGFibG8gJmx0OzxhIGhyZWY9Im1haWx0bzpw YWJsby5sb2NhbGhvc3RAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGFibG8ubG9jYWxob3N0 QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+RWxhZCwgSSBkaWQgdGhhdCBhbmQgcnVubmluZyB0aGUgY29tbWFuZHMgb24g dGhlIFNQTSZuYnNwOyByZXR1cm5lZCA6PGJyPg0KPGJyPg0KW3Jvb3RAdmlydDAxLWludCB+XSMg dmRzQ2xpZW50IC1zIDAgZ2V0QWxsVGFza3M8YnI+DQo8YnI+DQpbcm9vdEB2aXJ0MDEtaW50IH5d IyB2ZHNDbGllbnQgLXMgMCBnZXRTcG1TdGF0dXMgYHZkc0NsaWVudCAtcyAwIGdldENvbm5lY3Rl ZFN0b3JhZ2VQb29sc0xpc3RgPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IHNwbUlkID0gMTxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyBzcG1TdGF0dXMgPSBTUE08YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgc3BtTHZlciA9IDg8YnI+DQo8YnI+DQpbcm9vdEB2aXJ0MDEtaW50IH5dIyB2ZHNDbGllbnQg LXMgMCBnZXRBbGxUYXNrczxicj4NCjxicj4NCltyb290QHZpcnQwMS1pbnQgfl0jIDxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGFua3Mg Zm9yIHlvdXIgdGltZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SlA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+MjAxNi0xMi0yMCAxMjo1NSBHTVQtMDM6MDAgRWxhZCBCZW4gQWhhcm9uICZsdDs8 YSBocmVmPSJtYWlsdG86ZWJlbmFoYXJAcmVkaGF0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmViZW5h aGFyQHJlZGhhdC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPkl0J3MgT0ssIGJ1dCB5b3UgbmVlZCB0byBtYWtlIHN1cmUgeW91J3JlIGNoZWNr aW5nIGl0IG9uIHRoZSBob3N0IHdoaWNoIGhhcyB0aGUgU1BNIHJvbGUuIFNvLCBmaXJzdCBjaGVj ayBvbiB0aGUgaG9zdCB0aGF0IGl0IGlzIHRoZSBjdXJyZW50IFNQTSB3aXRoIHRoZSBmb2xsb3dp bmc6PGJyPg0KPGJyPg0KdmRzQ2xpZW50IC1zIDAgZ2V0U3BtU3RhdHVzIGB2ZHNDbGllbnQgLXMg MCBnZXRDb25uZWN0ZWRTdG9yYWdlUG9vbHNMaXN0YDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkxvb2sgZm9y IHRoZSBob3N0IHRoYXQgaGFzICZxdW90OyBzcG1TdGF0dXMgPSBTUE0mcXVvdDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIGFmdGVyIHlvdSBmaW5kIHRo ZSBTUE0sIGNoZWNrIGZvciB0aGUgcnVubmluZyB0YXNrcyBhcyB5b3UgZGlkIGJlZm9yZS48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIERlYyAyMCwgMjAxNiBhdCA1 OjM3IFBNLCBKdWFuIFBhYmxvICZsdDs8YSBocmVmPSJtYWlsdG86cGFibG8ubG9jYWxob3N0QGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBhYmxvLmxvY2FsaG9zdEBnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNw O3RoYW5rcyBmb3IgeW91ciByZXBseSwgSSBkaWQgY2hlY2sgd2l0aCB2ZHNDbGllbnQgLXMgMCBn ZXRBbGxUYXNrcyAsIHJldHVybmVkIG5vdGhpbmcuIGlzIHRoaXMgc3RpbGwgdGhlIGNvcnJlY3Qg d2F5IHRvIGNoZWNrPw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPnJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkpQPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2 LTEyLTIwIDEyOjMyIEdNVC0wMzowMCBFbGFkIEJlbiBBaGFyb24gJmx0OzxhIGhyZWY9Im1haWx0 bzplYmVuYWhhckByZWRoYXQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWJlbmFoYXJAcmVkaGF0LmNv bTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGksIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+RGlkIHlvdSBjaGVjayBm b3IgcnVubmluZyB0YXNrcyBpbiB0aGUgU1BNIGhvc3Q/DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVl LCBEZWMgMjAsIDIwMTYgYXQgNTowNCBQTSwgSnVhbiBQYWJsbyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnBhYmxvLmxvY2FsaG9zdEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5wYWJsby5sb2NhbGhv c3RAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSwgPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5maXJzdCBvZiBhbGwgLCB0aGFua3MgdG8gYWxs IHRoZSBPdmlydC9SaGV2IHRlYW0gZm9yIHRoZSBvdXRzdGFuZGluZyB3b3JrIQ0KPGJyPg0KJm5i c3A7IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53ZSBhcmUg aGF2aW5nIGEgc21hbGwgaXNzdWUgd2l0aCBPdmlydCA0LjAuNSBhZnRlciB0ZXN0aW5nIGEgZnVs bCBlbmQgb2YgeWVhciBpbmZyYXN0cnVjdHVyZSBzaHV0ZG93biwgZXZlcnl0aGluZyBjYW1lIGJh Y2sgY29ycmVjdGx5IGV4Y2VwdCB0aGF0IHdlIGdldCBhICdEZWFjdGl2YXRpbmcgU3RvcmFnZSBE b21haW4nIHVuZGVyIHRoZSB0YXNrcyB0YWIuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+YW5v dGhlciBkYy9jbHVzdGVyIHJ1bm5pbmcgMy42LjcgcmVwb3J0ZWQgbm8gZXJyb3Igd2l0aCBzYW1l IG1haW50ZW5hbmNlIHByb2NlZHVyZS4uIG1heWJlIHdlIGRpZCBzb21ldGhpbmcgd3Jvbmc/DQo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij53b3VsZCB5b3UgcGxlYXNlIGJlIHNvIGtpbmQgdG8gcG9pbnQgbWUg b24gdGhlIHJpZ2h0IGRpcmVjdGlvbiB0byBmaXggaXQ/IEkgbG9va2VkICZuYnNwOw0KPGJyPg0K PGJyPg0KdmRzQ2xpZW50IC1zIDAgZ2V0QWxsVGFza3MgLCBidXQgcmV0dXJucyBub3RoaW5nLi4u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYW5rcyBmb3Ig eW91ciB0aW1lIGd1eXMgYW5kIG1lcnJ5IGNocmlzdG1hcyBhbmQgaGFwcHkgbmV3IHllYXIgaWYg d2UgZG9udCB0YWxrIGFnYWluIHNvb24hDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9Im0tNzg1Mzg5MTg4MTQwNjYzMzY1Mm0tMTQ3ODIx NTg0MjIxOTQyNjkzNG02MDk4NjU1Mjc2NjQ1NTQ1MDg1bTY5NTQ2NTI4ODg5NzgxOTMwMjdob2Vu emIiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5KUDwvc3Bhbj48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpVc2VycyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VXNlcnNAb3Zp cnQub3JnIiB0YXJnZXQ9Il9ibGFuayI+VXNlcnNAb3ZpcnQub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2VycyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2VyczwvYT48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BN6PR14MB168311E0B3CFEE926D92AF24E9900BN6PR14MB1683namp_--
Andrea, thanks for your reply, I already tried that , but unfortunately, a restart of the engine VM did not solve the error. best regards, JP 2016-12-20 13:32 GMT-03:00 Andrea Ghelardi <a.ghelardi@iontrading.com>:
I remember facing a similar issue during decommissioning of my Ovirt 3 environment.
Several tasks showed on GUI (and storage operations unavailable) but no tasks on command line.
Eventually restarting the engine VM cleaned up the situation and made the storage avail again.
Cheers
AG
*From:* users-bounces@ovirt.org [mailto:users-bounces@ovirt.org] *On Behalf Of *Elad Ben Aharon *Sent:* Tuesday, December 20, 2016 5:24 PM *To:* Juan Pablo <pablo.localhost@gmail.com> *Cc:* users <Users@ovirt.org> *Subject:* Re: [ovirt-users] "Deactivating Storage Domain" error
Do you have a storage domain in the DC in status 'locked'?
On Tue, Dec 20, 2016 at 6:09 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Elad, I did that and running the commands on the SPM returned :
[root@virt01-int ~]# vdsClient -s 0 getAllTasks
[root@virt01-int ~]# vdsClient -s 0 getSpmStatus `vdsClient -s 0 getConnectedStoragePoolsList` spmId = 1 spmStatus = SPM spmLver = 8
[root@virt01-int ~]# vdsClient -s 0 getAllTasks
[root@virt01-int ~]#
thanks for your time,
JP
2016-12-20 12:55 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
It's OK, but you need to make sure you're checking it on the host which has the SPM role. So, first check on the host that it is the current SPM with the following:
vdsClient -s 0 getSpmStatus `vdsClient -s 0 getConnectedStoragePoolsList`
Look for the host that has " spmStatus = SPM"
And after you find the SPM, check for the running tasks as you did before.
On Tue, Dec 20, 2016 at 5:37 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi,
thanks for your reply, I did check with vdsClient -s 0 getAllTasks , returned nothing. is this still the correct way to check?
regards,
JP
2016-12-20 12:32 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
Hi,
Did you check for running tasks in the SPM host?
On Tue, Dec 20, 2016 at 5:04 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi,
first of all , thanks to all the Ovirt/Rhev team for the outstanding work!
we are having a small issue with Ovirt 4.0.5 after testing a full end of year infrastructure shutdown, everything came back correctly except that we get a 'Deactivating Storage Domain' under the tasks tab.
another dc/cluster running 3.6.7 reported no error with same maintenance procedure.. maybe we did something wrong?
would you please be so kind to point me on the right direction to fix it? I looked
vdsClient -s 0 getAllTasks , but returns nothing...
thanks for your time guys and merry christmas and happy new year if we dont talk again soon!
JP
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
So, what do you guys suggest? isn't there a hint or a way to fix this issue? thanks for your help, JP 2016-12-20 13:35 GMT-03:00 Juan Pablo <pablo.localhost@gmail.com>:
Andrea, thanks for your reply, I already tried that , but unfortunately, a restart of the engine VM did not solve the error.
best regards, JP
2016-12-20 13:32 GMT-03:00 Andrea Ghelardi <a.ghelardi@iontrading.com>:
I remember facing a similar issue during decommissioning of my Ovirt 3 environment.
Several tasks showed on GUI (and storage operations unavailable) but no tasks on command line.
Eventually restarting the engine VM cleaned up the situation and made the storage avail again.
Cheers
AG
*From:* users-bounces@ovirt.org [mailto:users-bounces@ovirt.org] *On Behalf Of *Elad Ben Aharon *Sent:* Tuesday, December 20, 2016 5:24 PM *To:* Juan Pablo <pablo.localhost@gmail.com> *Cc:* users <Users@ovirt.org> *Subject:* Re: [ovirt-users] "Deactivating Storage Domain" error
Do you have a storage domain in the DC in status 'locked'?
On Tue, Dec 20, 2016 at 6:09 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Elad, I did that and running the commands on the SPM returned :
[root@virt01-int ~]# vdsClient -s 0 getAllTasks
[root@virt01-int ~]# vdsClient -s 0 getSpmStatus `vdsClient -s 0 getConnectedStoragePoolsList` spmId = 1 spmStatus = SPM spmLver = 8
[root@virt01-int ~]# vdsClient -s 0 getAllTasks
[root@virt01-int ~]#
thanks for your time,
JP
2016-12-20 12:55 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
It's OK, but you need to make sure you're checking it on the host which has the SPM role. So, first check on the host that it is the current SPM with the following:
vdsClient -s 0 getSpmStatus `vdsClient -s 0 getConnectedStoragePoolsList`
Look for the host that has " spmStatus = SPM"
And after you find the SPM, check for the running tasks as you did before.
On Tue, Dec 20, 2016 at 5:37 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi,
thanks for your reply, I did check with vdsClient -s 0 getAllTasks , returned nothing. is this still the correct way to check?
regards,
JP
2016-12-20 12:32 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
Hi,
Did you check for running tasks in the SPM host?
On Tue, Dec 20, 2016 at 5:04 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi,
first of all , thanks to all the Ovirt/Rhev team for the outstanding work!
we are having a small issue with Ovirt 4.0.5 after testing a full end of year infrastructure shutdown, everything came back correctly except that we get a 'Deactivating Storage Domain' under the tasks tab.
another dc/cluster running 3.6.7 reported no error with same maintenance procedure.. maybe we did something wrong?
would you please be so kind to point me on the right direction to fix it? I looked
vdsClient -s 0 getAllTasks , but returns nothing...
thanks for your time guys and merry christmas and happy new year if we dont talk again soon!
JP
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Fri, Dec 23, 2016 at 2:32 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
So, what do you guys suggest? isn't there a hint or a way to fix this issue?
thanks for your help, JP
Hi Juan, Having a "running" task under the tasks tab doesn't mean there's a task running on vdsm - there are engine "tasks" and vdsm tasks. 1. what is the current status of the domain listed in the task? 2. do you see any print related to the operation in the engine log file currently? (you can upload it so we'll be able to help you with verifying that). After you verify the operation is indeed not running You can delete that specific job from the jobs table: a. select job_id from job where description like '%...%'; b. delete from job where.. Let me know if that worked for you, Liron.
2016-12-20 13:35 GMT-03:00 Juan Pablo <pablo.localhost@gmail.com>:
Andrea, thanks for your reply, I already tried that , but unfortunately, a restart of the engine VM did not solve the error.
best regards, JP
2016-12-20 13:32 GMT-03:00 Andrea Ghelardi <a.ghelardi@iontrading.com>:
I remember facing a similar issue during decommissioning of my Ovirt 3 environment.
Several tasks showed on GUI (and storage operations unavailable) but no tasks on command line.
Eventually restarting the engine VM cleaned up the situation and made the storage avail again.
Cheers
AG
From: users-bounces@ovirt.org [mailto:users-bounces@ovirt.org] On Behalf Of Elad Ben Aharon Sent: Tuesday, December 20, 2016 5:24 PM To: Juan Pablo <pablo.localhost@gmail.com> Cc: users <Users@ovirt.org> Subject: Re: [ovirt-users] "Deactivating Storage Domain" error
Do you have a storage domain in the DC in status 'locked'?
On Tue, Dec 20, 2016 at 6:09 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Elad, I did that and running the commands on the SPM returned :
[root@virt01-int ~]# vdsClient -s 0 getAllTasks
[root@virt01-int ~]# vdsClient -s 0 getSpmStatus `vdsClient -s 0 getConnectedStoragePoolsList` spmId = 1 spmStatus = SPM spmLver = 8
[root@virt01-int ~]# vdsClient -s 0 getAllTasks
[root@virt01-int ~]#
thanks for your time,
JP
2016-12-20 12:55 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
It's OK, but you need to make sure you're checking it on the host which has the SPM role. So, first check on the host that it is the current SPM with the following:
vdsClient -s 0 getSpmStatus `vdsClient -s 0 getConnectedStoragePoolsList`
Look for the host that has " spmStatus = SPM"
And after you find the SPM, check for the running tasks as you did before.
On Tue, Dec 20, 2016 at 5:37 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi,
thanks for your reply, I did check with vdsClient -s 0 getAllTasks , returned nothing. is this still the correct way to check?
regards,
JP
2016-12-20 12:32 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
Hi,
Did you check for running tasks in the SPM host?
On Tue, Dec 20, 2016 at 5:04 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi,
first of all , thanks to all the Ovirt/Rhev team for the outstanding work!
we are having a small issue with Ovirt 4.0.5 after testing a full end of year infrastructure shutdown, everything came back correctly except that we get a 'Deactivating Storage Domain' under the tasks tab.
another dc/cluster running 3.6.7 reported no error with same maintenance procedure.. maybe we did something wrong?
would you please be so kind to point me on the right direction to fix it? I looked
vdsClient -s 0 getAllTasks , but returns nothing...
thanks for your time guys and merry christmas and happy new year if we dont talk again soon!
JP
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Hi Liron, Marry christmas! 1- [root@virt01-int ~]# vdsClient -s 0 getStorageDomainInfo e6a85203-32e0-4200-b3d7-83f140203294 uuid = e6a85203-32e0-4200-b3d7-83f140203294 vguuid = fDclFZ-KLel-t36P-VAFm-hyle-RxcU-uOc7gj state = OK version = 3 role = Master type = ISCSI class = Data pool = ['58405b2d-0094-0380-0260-0000000000a5'] name = nas01 2- which file do you want me to share ? how do I perform task a and b you mention? is there a guide somewhere ? I appreciate your help, best regards, JP 2016-12-25 11:10 GMT-03:00 Liron Aravot <laravot@redhat.com>:
On Fri, Dec 23, 2016 at 2:32 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
So, what do you guys suggest? isn't there a hint or a way to fix this issue?
thanks for your help, JP
Hi Juan, Having a "running" task under the tasks tab doesn't mean there's a task running on vdsm - there are engine "tasks" and vdsm tasks.
1. what is the current status of the domain listed in the task? 2. do you see any print related to the operation in the engine log file currently? (you can upload it so we'll be able to help you with verifying that).
After you verify the operation is indeed not running You can delete that specific job from the jobs table: a. select job_id from job where description like '%...%'; b. delete from job where..
Let me know if that worked for you, Liron.
2016-12-20 13:35 GMT-03:00 Juan Pablo <pablo.localhost@gmail.com>:
Andrea, thanks for your reply, I already tried that , but
restart of the engine VM did not solve the error.
best regards, JP
2016-12-20 13:32 GMT-03:00 Andrea Ghelardi <a.ghelardi@iontrading.com>:
I remember facing a similar issue during decommissioning of my Ovirt 3 environment.
Several tasks showed on GUI (and storage operations unavailable) but no tasks on command line.
Eventually restarting the engine VM cleaned up the situation and made
unfortunately, a the
storage avail again.
Cheers
AG
From: users-bounces@ovirt.org [mailto:users-bounces@ovirt.org] On Behalf Of Elad Ben Aharon Sent: Tuesday, December 20, 2016 5:24 PM To: Juan Pablo <pablo.localhost@gmail.com> Cc: users <Users@ovirt.org> Subject: Re: [ovirt-users] "Deactivating Storage Domain" error
Do you have a storage domain in the DC in status 'locked'?
On Tue, Dec 20, 2016 at 6:09 PM, Juan Pablo <pablo.localhost@gmail.com
wrote:
Elad, I did that and running the commands on the SPM returned :
[root@virt01-int ~]# vdsClient -s 0 getAllTasks
[root@virt01-int ~]# vdsClient -s 0 getSpmStatus `vdsClient -s 0 getConnectedStoragePoolsList` spmId = 1 spmStatus = SPM spmLver = 8
[root@virt01-int ~]# vdsClient -s 0 getAllTasks
[root@virt01-int ~]#
thanks for your time,
JP
2016-12-20 12:55 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
It's OK, but you need to make sure you're checking it on the host which has the SPM role. So, first check on the host that it is the current SPM with the following:
vdsClient -s 0 getSpmStatus `vdsClient -s 0 getConnectedStoragePoolsList`
Look for the host that has " spmStatus = SPM"
And after you find the SPM, check for the running tasks as you did before.
On Tue, Dec 20, 2016 at 5:37 PM, Juan Pablo <pablo.localhost@gmail.com
wrote:
Hi,
thanks for your reply, I did check with vdsClient -s 0 getAllTasks , returned nothing. is this still the correct way to check?
regards,
JP
2016-12-20 12:32 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
Hi,
Did you check for running tasks in the SPM host?
On Tue, Dec 20, 2016 at 5:04 PM, Juan Pablo <pablo.localhost@gmail.com
wrote:
Hi,
first of all , thanks to all the Ovirt/Rhev team for the outstanding work!
we are having a small issue with Ovirt 4.0.5 after testing a full end of year infrastructure shutdown, everything came back correctly except that we get a 'Deactivating Storage Domain' under the tasks tab.
another dc/cluster running 3.6.7 reported no error with same maintenance procedure.. maybe we did something wrong?
would you please be so kind to point me on the right direction to fix it? I looked
vdsClient -s 0 getAllTasks , but returns nothing...
thanks for your time guys and merry christmas and happy new year if we dont talk again soon!
JP
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Hi Juan, see the reply inline On Sun, Dec 25, 2016 at 8:47 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi Liron, Marry christmas!
1- [root@virt01-int ~]# vdsClient -s 0 getStorageDomainInfo e6a85203-32e0-4200-b3d7-83f140203294 uuid = e6a85203-32e0-4200-b3d7-83f140203294 vguuid = fDclFZ-KLel-t36P-VAFm-hyle-RxcU-uOc7gj state = OK version = 3 role = Master type = ISCSI class = Data pool = ['58405b2d-0094-0380-0260-0000000000a5'] name = nas01 2- which file do you want me to share ?
I've meant to the status of the domain as appears in the web ui.
how do I perform task a and b you mention? is there a guide somewhere ?
You need to login to the engine database, IIRC the default is "engine". Please make sure to backup you db before you perform manual operation (those operations are safe, but just in case). a. psql -U engine -d engine b. select job_id, description from job where description like '%Deactivating%'; c. delete from job where job_id='JOB_ID_FROM_PREVIOUS_QUERY'; Let me know how it went, Liron
I appreciate your help, best regards, JP
2016-12-25 11:10 GMT-03:00 Liron Aravot <laravot@redhat.com>:
On Fri, Dec 23, 2016 at 2:32 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
So, what do you guys suggest? isn't there a hint or a way to fix this issue?
thanks for your help, JP
Hi Juan, Having a "running" task under the tasks tab doesn't mean there's a task running on vdsm - there are engine "tasks" and vdsm tasks.
1. what is the current status of the domain listed in the task? 2. do you see any print related to the operation in the engine log file currently? (you can upload it so we'll be able to help you with verifying that).
After you verify the operation is indeed not running You can delete that specific job from the jobs table: a. select job_id from job where description like '%...%'; b. delete from job where..
Let me know if that worked for you, Liron.
2016-12-20 13:35 GMT-03:00 Juan Pablo <pablo.localhost@gmail.com>:
Andrea, thanks for your reply, I already tried that , but unfortunately, a restart of the engine VM did not solve the error.
best regards, JP
2016-12-20 13:32 GMT-03:00 Andrea Ghelardi <a.ghelardi@iontrading.com>:
I remember facing a similar issue during decommissioning of my Ovirt 3 environment.
Several tasks showed on GUI (and storage operations unavailable) but no tasks on command line.
Eventually restarting the engine VM cleaned up the situation and made the storage avail again.
Cheers
AG
From: users-bounces@ovirt.org [mailto:users-bounces@ovirt.org] On Behalf Of Elad Ben Aharon Sent: Tuesday, December 20, 2016 5:24 PM To: Juan Pablo <pablo.localhost@gmail.com> Cc: users <Users@ovirt.org> Subject: Re: [ovirt-users] "Deactivating Storage Domain" error
Do you have a storage domain in the DC in status 'locked'?
On Tue, Dec 20, 2016 at 6:09 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Elad, I did that and running the commands on the SPM returned :
[root@virt01-int ~]# vdsClient -s 0 getAllTasks
[root@virt01-int ~]# vdsClient -s 0 getSpmStatus `vdsClient -s 0 getConnectedStoragePoolsList` spmId = 1 spmStatus = SPM spmLver = 8
[root@virt01-int ~]# vdsClient -s 0 getAllTasks
[root@virt01-int ~]#
thanks for your time,
JP
2016-12-20 12:55 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
It's OK, but you need to make sure you're checking it on the host which has the SPM role. So, first check on the host that it is the current SPM with the following:
vdsClient -s 0 getSpmStatus `vdsClient -s 0 getConnectedStoragePoolsList`
Look for the host that has " spmStatus = SPM"
And after you find the SPM, check for the running tasks as you did before.
On Tue, Dec 20, 2016 at 5:37 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi,
thanks for your reply, I did check with vdsClient -s 0 getAllTasks , returned nothing. is this still the correct way to check?
regards,
JP
2016-12-20 12:32 GMT-03:00 Elad Ben Aharon <ebenahar@redhat.com>:
Hi,
Did you check for running tasks in the SPM host?
On Tue, Dec 20, 2016 at 5:04 PM, Juan Pablo <pablo.localhost@gmail.com> wrote:
Hi,
first of all , thanks to all the Ovirt/Rhev team for the outstanding work!
we are having a small issue with Ovirt 4.0.5 after testing a full end of year infrastructure shutdown, everything came back correctly except that we get a 'Deactivating Storage Domain' under the tasks tab.
another dc/cluster running 3.6.7 reported no error with same maintenance procedure.. maybe we did something wrong?
would you please be so kind to point me on the right direction to fix it? I looked
vdsClient -s 0 getAllTasks , but returns nothing...
thanks for your time guys and merry christmas and happy new year if we dont talk again soon!
JP
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (4)
-
Andrea Ghelardi -
Elad Ben Aharon -
Juan Pablo -
Liron Aravot