Other than errors, anything that doesn't work on your environment? On Jul 21, 2016 09:48, "Yaniv Kaul" <ykaul(a)redhat.com&gt; wrote:

--_000_6af1dd4ac72f4d1cad9b0c3edda672b9EX10grfcrf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2hlY2sgdGltZS9udHAgc2V0dGluZ3Mgb24gbm9kZXMgYW5kIGVuZ2luZS4NCg0KLS0NCmEuc2h2 eWdpbkBncmZjLnJ1DQoNCkZyb206IHVzZXJzLWJvdW5jZXNAb3ZpcnQub3JnIFttYWlsdG86dXNl cnMtYm91bmNlc0BvdmlydC5vcmddIE9uIEJlaGFsZiBPZiBDLiBIYW5kZWwNClNlbnQ6IFRodXJz ZGF5LCBKdWx5IDIxLCAyMDE2IDEwOjAzIEFNDQpUbzogT3ZlZCBPdXJmYWxpDQpDYzogdXNlcnMN ClN1YmplY3Q6IFJlOiBbb3ZpcnQtdXNlcnNdIHZkc20gc3NsIGVycm9ycw0KDQphcyBmYXIgYXMg aSBjYW4gdGVsbCwgZXZlcnl0aGluZyBpcyBmaW5lLg0KDQpWTXMgYXJlIHJ1bm5pbmcsIGkgY2Fu IG1pZ3JhdGUgdGhlbSwgdGhleSBhcmUgcmVzdGFydGVkIG9uIGNyYXNoLCBldGMuDQoNCk5vIGV2 ZW50cyBpbiB0aGUgZGFzaGJvYXJkLCBwZXJmb3JtYW5jZSBkYXRhIGlzIGF2YWlsYWJsZS4NCg0K R3JlZXRpbmdzDQogICBDaHJpc3RvcGgNCg0KT24gVGh1LCBKdWwgMjEsIDIwMTYgYXQgODo1OSBB TSwgT3ZlZCBPdXJmYWxpIDxvb3VyZmFsaUByZWRoYXQuY29tPG1haWx0bzpvb3VyZmFsaUByZWRo YXQuY29tPj4gd3JvdGU6DQoNCk90aGVyIHRoYW4gZXJyb3JzLCBhbnl0aGluZyB0aGF0IGRvZXNu J3Qgd29yayBvbiB5b3VyIGVudmlyb25tZW50Pw0KT24gSnVsIDIxLCAyMDE2IDA5OjQ4LCAiWWFu aXYgS2F1bCIgPHlrYXVsQHJlZGhhdC5jb208bWFpbHRvOnlrYXVsQHJlZGhhdC5jb20+PiB3cm90 ZToNCkNhbiB5b3Ugc2hhcmUgZW5naW5lIGFuZCBWRFNNIGxvZ3MgcGxlYXNlPw0KVElBLA0KWS4N Cg0KT24gVGh1LCBKdWwgMjEsIDIwMTYgYXQgOToyMiBBTSwgQy4gSGFuZGVsIDxvdmlydEBtYWNo dC1ibGF1Lm9yZzxtYWlsdG86b3ZpcnRAbWFjaHQtYmxhdS5vcmc+PiB3cm90ZToNCmkgaGF2ZSBh biBvdmlydCA0LjAuMSBpbnN0YWxsYXRpb24gb24gdHdvIG5vZGVzLiBIb3N0ZWQgRW5naW5lLiBT YW4gc3RvcmFnZSBiYWNrZW5kLg0KDQpGb3Igc29tZSByZWFzb24gdGhlIHZkc21kIG9uIHRoZSBu b2RlcyBpcyBsb2dnaW5nIGFuIGVycm9yIGV2ZXJ5IGZldyBzZWNvbmRzOg0KDQoNCnZkc20gdmRz LmRpc3BhdGNoZXIgRVJST1IgU1NMIGVycm9yIGR1cmluZyByZWFkaW5nIGRhdGE6IHVuZXhwZWN0 ZWQgZW9mDQoNCg0KUnVubmluZyB0Y3BkdW1wIGl0IGlzIGEgY29ubmVjdCBmcm9tIHRoZSBub2Rl IHRvIGl0c2VsZi4gSSBjYW4ndCBmaWd1cmUgb3V0IHdoYXQgaXMgd3JvbmcuIENhbiBzb21lb25l IGdpdmUgbWUgYSBoaW50Pw0KDQpHcmVldGluZ3MNCiAgIENocmlzdG9waA0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVXNlcnMgbWFpbGluZyBsaXN0 DQpVc2Vyc0BvdmlydC5vcmc8bWFpbHRvOlVzZXJzQG92aXJ0Lm9yZz4NCmh0dHA6Ly9saXN0cy5v dmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vycw0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpVc2VycyBtYWlsaW5nIGxpc3QNClVzZXJzQG92 aXJ0Lm9yZzxtYWlsdG86VXNlcnNAb3ZpcnQub3JnPg0KaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9t YWlsbWFuL2xpc3RpbmZvL3VzZXJzDQoNCg== --_000_6af1dd4ac72f4d1cad9b0c3edda672b9EX10grfcrf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46Mi4wY20gNDIuNXB0IDIu MGNtIDMuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iUlUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hlY2sgdGltZS9u dHAgc2V0dGluZ3Mgb24gbm9kZXMgYW5kIGVuZ2luZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj4t LTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+YTwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+Ljwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPnNodnlnaW48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPkA8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj5ncmZj PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAyMDYwIj4uPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+ cnU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdXNlcnMtYm91bmNlc0Bvdmly dC5vcmcgW21haWx0bzp1c2Vycy1ib3VuY2VzQG92aXJ0Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+Qy4gSGFuZGVsPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDIxLCAyMDE2IDEw OjAzIEFNPGJyPg0KPGI+VG86PC9iPiBPdmVkIE91cmZhbGk8YnI+DQo8Yj5DYzo8L2I+IHVzZXJz PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbb3ZpcnQtdXNlcnNdIHZkc20gc3NsIGVycm9yczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFzIGZhciBhcyBpIGNhbiB0ZWxs LCBldmVyeXRoaW5nIGlzIGZpbmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5WTXMgYXJlIHJ1bm5pbmcsIGkgY2FuIG1pZ3JhdGUgdGhlbSwgdGhl eSBhcmUgcmVzdGFydGVkIG9uIGNyYXNoLCBldGMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vIGV2ZW50cyBpbiB0aGUgZGFzaGJv YXJkLCBwZXJmb3JtYW5jZSBkYXRhIGlzIGF2YWlsYWJsZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R3JlZXRpbmdzPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 Q2hyaXN0b3BoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIFRodSwgSnVsIDIxLCAyMDE2IGF0IDg6NTkgQU0sIE92ZWQgT3VyZmFsaSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm9vdXJmYWxpQHJlZGhhdC5jb20iIHRhcmdldD0iX2JsYW5rIj5vb3Vy ZmFsaUByZWRoYXQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cD5PdGhlciB0 aGFuIGVycm9ycywgYW55dGhpbmcgdGhhdCBkb2Vzbid0IHdvcmsgb24geW91ciBlbnZpcm9ubWVu dD88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIEp1bCAyMSwgMjAxNiAwOTo0OCwgJnF1b3Q7WWFuaXYgS2F1bCZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnlrYXVsQHJlZGhhdC5jb20iIHRhcmdldD0iX2JsYW5rIj55a2F1bEByZWRo YXQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Q2FuIHlvdSBzaGFyZSBlbmdpbmUgYW5kIFZEU00gbG9ncyBwbGVhc2U/PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VElBLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKdWwgMjEsIDIw MTYgYXQgOToyMiBBTSwgQy4gSGFuZGVsICZsdDs8YSBocmVmPSJtYWlsdG86b3ZpcnRAbWFjaHQt YmxhdS5vcmciIHRhcmdldD0iX2JsYW5rIj5vdmlydEBtYWNodC1ibGF1Lm9yZzwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmkgaGF2ZSBh biBvdmlydCA0LjAuMSBpbnN0YWxsYXRpb24gb24gdHdvIG5vZGVzLiBIb3N0ZWQgRW5naW5lLiBT YW4gc3RvcmFnZSBiYWNrZW5kLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Rm9yIHNvbWUgcmVhc29uIHRoZSB2ZHNtZCBvbiB0aGUgbm9kZXMgaXMgbG9nZ2lu ZyBhbiBlcnJvciBldmVyeSBmZXcgc2Vjb25kczo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+dmRzbSB2ZHMuZGlzcGF0Y2hlciBFUlJPUiBTU0wgZXJyb3Ig ZHVyaW5nIHJlYWRpbmcgZGF0YTogdW5leHBlY3RlZCBlb2Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SdW5uaW5nIHRjcGR1bXAgaXQgaXMg YSBjb25uZWN0IGZyb20gdGhlIG5vZGUgdG8gaXRzZWxmLiBJIGNhbid0IGZpZ3VyZSBvdXQgd2hh dCBpcyB3cm9uZy4gQ2FuIHNvbWVvbmUgZ2l2ZSBtZSBhIGhpbnQ/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdyZWV0aW5nczxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO0No cmlzdG9waDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClVzZXJzIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpVc2Vyc0BvdmlydC5vcmciIHRhcmdldD0iX2JsYW5r Ij5Vc2Vyc0BvdmlydC5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cDovL2xpc3RzLm92aXJ0Lm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2xpc3RzLm92 aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClVzZXJzIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpVc2Vyc0BvdmlydC5vcmciIHRhcmdldD0i X2JsYW5rIj5Vc2Vyc0BvdmlydC5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cDovL2xpc3RzLm92 aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2xp c3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6af1dd4ac72f4d1cad9b0c3edda672b9EX10grfcrf_--

Based on the pieces of the logs that you provided it is hard to tell what was the reason of a connection being closed. This message is logged when python ssl library we use was reading the data from the connection and it was closed by the other side (engine). It is expected message in those situations. Please provide more complete engine logs so we know why the connection was closed. On Thu, Jul 21, 2016 at 9:31 AM, C. Handel <ovirt(a)macht-blau.org&gt; wrote:

On Thu, Jul 21, 2016 at 10:00 AM, C. Handel <ovirt(a)macht-blau.org&gt; wrote: This log is not very useful as is, we must show the relevant remote address. Should be improved in https://gerrit.ovirt.org/61303 Can you try this patch and share the log?

On Mon, Jul 25, 2016 at 4:45 PM, C. Handel <ovirt(a)macht-blau.org&gt; wrote: Thanks for testing. Is this hosted engine setup? Hosted engine ha agent is using jsonrpc, and it creates a new connection for every request, maybe what we see is the side effect of closing the old connection uncleanly. I guess that logging all tcp connections to localhost:54321 (netstat? lsof?) and the applications using them, and you will find the process causing the unexpected eof. Nir

two nodes (x.x.138.208, x.x.138.210), hosted-engine on x.x.139.240. the vdsm logs are from x.x.138.208 and the connection is from the node itself. out what is wrong. Can someone ?> give me a hint? so i know they are coming from the node itself. The process connecting is terminating too fast. the moment i see it in tcpdump, it is gone from the process table. Greetings Christoph On Mon, Jul 25, 2016 at 4:53 PM, Piotr Kliczewski < piotr.kliczewski(a)gmail.com&gt; wrote:

On Mon, Jul 25, 2016 at 6:18 PM, Nir Soffer <nsoffer(a)redhat.com&gt; wrote: I stated above there are 2 verbs that were called each time: Host.getStats and Host.getHardwareInfo

On Mon, Jul 25, 2016 at 12:07 PM, Nir Soffer <nsoffer(a)redhat.com&gt; wrote: Hello, I take on this as I have the same problem. I'm in 4.0.3 and it seems that the gerrit above was not inside. So I applied and restarted vdsmd. Now I have Oct 07 19:54:10 ovirt01.lutwyn.org vdsm[11306]: vdsm vds.dispatcher ERROR SSL error receiving from <yajsonrpc.betterAsyncore.Dispatcher connected 192.168.1.211:36296 at 0x359c5f0>: unexpected eof In my case single host environment with Self Hosted Engine Ip of host is 192.168.1.211 Ip of engine is 192.168.1.212 Let me know if you need full logs and which ones. in the mean time 1000 line around in vdsm.log here: https://drive.google.com/file/d/0BwoPbcrMv8mvTk9SYTF0UDZUMUU/view?usp=sha... Thanks, Gianluca

On Fri, Oct 7, 2016 at 10:14 PM, Piotr Kliczewski <pkliczew(a)redhat.com&gt; wrote: here it is https://drive.google.com/file/d/0BwoPbcrMv8mvQlVwVDlGTVEtR00/view?usp=sha... Gianluca

Fixed in "Bug 1371515 - Exception on GetUserProfileQuery (unknown cause) : "The column name user_portal_vm_auto_login was not found in this ResultSet". Please upgrade to latest 4.0. On Sun, Oct 9, 2016 at 10:47 AM, Piotr Kliczewski < piotr.kliczewski(a)gmail.com&gt; wrote:

Gianluca, Please share engine log as well. Thanks, Piotr On Wed, Oct 12, 2016 at 12:33 AM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com

It would be great if you could provide vdsm and engine from the same time. I see that engine logs end at 2016-10-12 10:51:36,336 and vdsm logs start at 2016-10-12 11:01:02,558 Thanks, Piotr On Wed, Oct 12, 2016 at 11:15 AM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com > > On Wed, Oct 12, 2016 at 8:55 AM, Piotr Kliczewski <pkliczew(a)redhat.com&gt; > >> Gianluca, >> >> Please share engine log as well. >> >> Thanks, >> Piotr >> >> > Hello, I have not access right now to that server, but I have another > quite similar environment (here the server is a Dell M910) with same > behavior. It is at 4.0.4 too. > And also this environment was created in 3.6.x and then updated to various > 4.0.x up to 4.0.4 now > vdsm version is now vdsm-4.18.13-1.el7.centos.x86_64 > > here vdsm.log in gzip format > https://drive.google.com/file/d/0BwoPbcrMv8mvUThnOEVqM21JSTg/ > view?usp=sharing > > and here engine.log in gzip format > https://drive.google.com/file/d/0BwoPbcrMv8mvUUVnZnQ5cGN0NHM/ > view?usp=sharing > > [root@ractor ~]# systemctl status vdsmd > . vdsmd.service - Virtual Desktop Server Manager > Loaded: loaded (/etc/systemd/system/vdsmd.service; enabled; vendor > preset: enabled) > Active: active (running) since Mon 2016-10-03 22:56:11 CEST; 1 weeks 1 > days ago > Process: 30970 ExecStopPost=/usr/libexec/vdsm/vdsmd_init_common.sh > --post-stop (code=exited, status=0/SUCCESS) > Process: 30974 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh > --pre-start (code=exited, status=0/SUCCESS) > Main PID: 31166 (vdsm) > CGroup: /system.slice/vdsmd.service > ├─31166 /usr/bin/python /usr/share/vdsm/vdsm > ├─31265 /usr/libexec/ioprocess --read-pipe-fd 61 > --write-pipe-fd 59 --max-threads 10 --max-queued-req... > ├─31280 /usr/libexec/ioprocess --read-pipe-fd 77 > --write-pipe-fd 76 --max-threads 10 --max-queued-req... > ├─31371 /usr/libexec/ioprocess --read-pipe-fd 105 > --write-pipe-fd 103 --max-threads 10 --max-queued-r... > ├─33870 /usr/libexec/ioprocess --read-pipe-fd 40 > --write-pipe-fd 39 --max-threads 10 --max-queued-req... > ├─33889 /usr/libexec/ioprocess --read-pipe-fd 48 > --write-pipe-fd 47 --max-threads 10 --max-queued-req... > ├─33896 /usr/libexec/ioprocess --read-pipe-fd 58 > --write-pipe-fd 55 --max-threads 10 --max-queued-req... > ├─33904 /usr/libexec/ioprocess --read-pipe-fd 73 > --write-pipe-fd 72 --max-threads 10 --max-queued-req... > └─33911 /usr/libexec/ioprocess --read-pipe-fd 98 > --write-pipe-fd 96 --max-threads 10 --max-queued-req... > > Oct 12 11:11:49 mynewdomain vdsm[31166]: vdsm vds.dispatcher ERROR SSL > error during reading d...eof > Oct 12 11:11:50 mynewdomain vdsm[31166]: vdsm vds.dispatcher ERROR SSL > error during reading d...eof > Oct 12 11:11:56 mynewdomain vdsm[31166]: vdsm vds.dispatcher ERROR SSL > error during reading d...eof > Oct 12 11:12:01 mynewdomain vdsm[31166]: vdsm vds.dispatcher ERROR SSL > error during reading d...eof > Oct 12 11:12:07 mynewdomain vdsm[31166]: vdsm vds.dispatcher ERROR SSL > error during reading d...eof > Oct 12 11:12:22 mynewdomain vdsm[31166]: vdsm vds.dispatcher ERROR SSL > error during reading d...eof > Oct 12 11:12:33 mynewdomain vdsm[31166]: vdsm vds.dispatcher ERROR SSL > error during reading d...eof > Oct 12 11:12:34 mynewdomain vdsm[31166]: vdsm vds.dispatcher ERROR SSL > error during reading d...eof > Oct 12 11:12:39 mynewdomain vdsm[31166]: vdsm vds.dispatcher ERROR SSL > error during reading d...eof > Oct 12 11:12:45 mynewdomain vdsm[31166]: vdsm vds.dispatcher ERROR SSL > error during reading d...eof > Hint: Some lines were ellipsized, use -l to show in full. > [root@ractor ~]# >

Is it possible to login to the system and take a look at the logs. If so please send me details offline. On Wed, Oct 12, 2016 at 1:07 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com&gt; wrote:

What I meant is that you sent logs created at different times so I was unable to match both ends (engine and vdsm. It would be great if you could sent the logs from the same time. On Wed, Oct 12, 2016 at 1:22 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com&gt; wrote:

As you listed engine logs end 14 minutes before vdsm logs start. It should be enough if you sent older vdsm log which covers engine logs time frame. Thanks, Piotr On Wed, Oct 12, 2016 at 2:46 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com&gt; wrote:

This log did not help me either because during this specific time there was no logs in the engine. 2016-10-12 09:51:35,296 INFO [org.ovirt.engine.core.bll.storage.domain.IsoDomainListSyncronizer] (org.ovirt.thread.pool-8-thread-13) [141b5168] Finished automatic refresh process for 'ISO' file type with success, for storage domain id 'fd5754f1-bd00-4337-ad64-1abde35438ae'. 2016-10-12 10:42:49,188 INFO [org.ovirt.engine.core.bll.EngineBackupAwarenessManager] (DefaultQuartzScheduler8) [63f92190] Backup check started. This means that it is not the engine attempting to connect. @Simone can you please check whether this is hosted engine? Looking more in to the logs I see that after hostdeploy there are no more attempts to connect from the engine: 2016-10-03 23:28:47,891 INFO [org.ovirt.engine.core.uutils.ssh.SSHDialog] (DefaultQuartzScheduler8) [4afdc494] SSH execute &#39;root(a)ractor.mynewdomain&#39; 'umask 0077; MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t ovirt-XXXXXXXXXX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; tar --warning=no-timestamp -C "${MYTMP}" -x && "${MYTMP}"/ovirt-host-mgmt DIALOG/dialect=str:machine DIALOG/customization=bool:True' Later in the logs I can see bunch of redeploys but no sign of attempt to connect. Can you please share one of the host deploy logs? According to the logs this is the last one: /var/log/ovirt-engine/host-deploy/ovirt-host-mgmt-20161011233340-ractor.mynewdomain-23718eb3.log Thanks, Piotr On Wed, Oct 12, 2016 at 4:23 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com&gt; wrote:

Gianluca, Checking the log it seems that we do not configure firewall: NETWORK/firewalldEnable=bool:'False' NETWORK/iptablesEnable=bool:'False' Please make sure that you reconfigure your firewall to open 54321 port or let host deploy to do it for you. Thanks, Piotr On Wed, Oct 12, 2016 at 7:14 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com&gt; wrote:

On Thu, Oct 13, 2016 at 11:13 AM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com Actually it is already... root@ovirt01 ~]# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:67 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 ACCEPT all -- 192.168.1.212 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:54321 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:111 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:111 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:161 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:16514 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 2223 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 5900:6923 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 multiport dports 49152:49216 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 192.168.122.0/24 ctstate RELATED,ESTABLISHED ACCEPT all -- 192.168.122.0/24 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable REJECT all -- 0.0.0.0/0 0.0.0.0/0 PHYSDEV match ! --physdev-is-bridged reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:68 [root@ovirt01 ~]#

On Thu, Oct 13, 2016 at 11:23 AM, Piotr Kliczewski <pkliczew(a)redhat.com&gt; wrote: OK, I'm on it.

On Thu, Oct 13, 2016 at 2:59 PM, Simone Tiraboschi <stirabos(a)redhat.com&gt; wrote: ss log for host: https://drive.google.com/file/d/0BwoPbcrMv8mvczVOeG1iUWZxS1U/view?usp=sha... ss log for engine https://drive.google.com/file/d/0BwoPbcrMv8mvWGx0QWstWG1TSWc/view?usp=sha... agent.log https://drive.google.com/file/d/0BwoPbcrMv8mvMFBrQ2lneFVwaGc/view?usp=sha... broker.log https://drive.google.com/file/d/0BwoPbcrMv8mva2Jsc3BkNkpNZFE/view?usp=sha... hih clarify

On Thu, Oct 13, 2016 at 2:45 PM, Simone Tiraboschi <stirabos(a)redhat.com&gt; wrote: In the mean time I confirmed that even without ipv6 the situation doesn't change global maintenance stop ovirt-engine service create no-ipv6.conf under /etc/sysctl.d of engine systemctl restart network no more ipv6 shutdown engine exit from maintenance and after a while engine is powered on on host vdsm 6767 vdsm 24u IPv4 15528247 0t0 TCP *:54321 (LISTEN) vdsm 6767 vdsm 82u IPv4 15528876 0t0 TCP ovirt01.mydomain:54321->ovirt.mydomain:52980 (ESTABLISHED) vdsm 6767 vdsm 110u IPv4 15534849 0t0 TCP ovirt01.mydomain:54321->ovirt.mydomain:52984 (ESTABLISHED) on engine now [root@ovirt host-deploy]# netstat -an|grep 54321 tcp 0 0 192.168.1.212:52984 192.168.1.211:54321 ESTABLISHED tcp 0 0 192.168.1.212:52980 192.168.1.211:54321 ESTABLISHED [root@ovirt host-deploy]# but vdsmd has the same errors. Also restarting vdsmd Oct 13 14:49:20 ovirt01.mydomain vdsm[6767]: vdsm vds.dispatcher ERROR SSL error during reading data: unexpected eof how can I force the creation of the ovirt-host-mgtmt file? I just see that has been generated this one file ovirt-host-mgmt-20161013124548-ovirt01.mydomain-null.log here: https://drive.google.com/file/d/0BwoPbcrMv8mvbXI3cndGcEtXbWs/view?usp=sha...