- Users - oVirt List Archives

Re: [ovirt-users] 4.2 can not set noVnc as default console
by Karli Sjöberg 24 Jan '18

24 Jan '18

2 1

Fail to add a second network
by carl langlois 24 Jan '18

24 Jan '18

HI all, I am trying to add second network for back-end traffic. My setup is a 3 hosts running with gluster storage in 3+1 replicat. Now i am trying to add a second network with the UI and when i try to had a the host interface to the new network it is always failing and i lost communication with this host. I am not sure what are the step to add a second network with already 3 Host in the cluster. My setup us 4.2. Any inputs would be appreciated. Thanks

3 8

4.2 can not set noVnc as default console
by Vrgotic, Marko 24 Jan '18

24 Jan '18

--_000_DF8E8FEC510F451387356E6FA4EC8241activevideocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBvVmlydC4NCg0KRXhlY3V0aW5nIGVuZ2luZS1jb25maWcg4oCTcyBDbGllbnRNb2RlVm5j RGVmYXVsdD1Ob1ZuYyBkb2VzIG5vdCByZXN1bHQgYXMgZXhwZWN0ZWQuDQoNCkV2ZW4gdGhvdWdo IGNvbW1hbmQgaXMgZXhlY3V0ZWQsIEkgY2Fubm90IGZpbmQgdGhlIFZNIGNvbnNvbGUgc2V0dXAg KGR1cmluZyBjcmVhdGlvbikgd2hpY2ggc2V0cyBub1ZuYyBhcyBkZWZhdWx0LCBpdOKAmXMgYWx3 YXlzIE5hdGl2ZSBWTkMuDQoNCkFueSBhZHZpY2U/DQoNCi0tDQpNZXQgdnJpZW5kZWxpamtlIGdy b2V0IC8gQmVzdCByZWdhcmRzLA0KTWFya28gVnJnb3RpYw0KU3lzdGVtIEVuZ2luZWVyL0N1c3Rv bWVyIENhcmUNCkFjdGl2ZVZpZGVvDQo= --_000_DF8E8FEC510F451387356E6FA4EC8241activevideocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0019EDD6BEA6C641996798343AAB8FE0(a)namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4wcHQgODQyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5EZWFyIG9WaXJ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+RXhlY3V0aW5nJm5ic3A7PGk+ZW5naW5lLWNvbmZpZyDigJNzIENsaWVudE1vZGVWbmNE ZWZhdWx0PU5vVm5jJm5ic3A7PC9pPmRvZXMgbm90IHJlc3VsdCBhcyBleHBlY3RlZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkV2ZW4gdGhvdWdoIGNvbW1hbmQg aXMgZXhlY3V0ZWQsIEkgY2Fubm90IGZpbmQgdGhlIFZNIGNvbnNvbGUgc2V0dXAgKGR1cmluZyBj cmVhdGlvbikgd2hpY2ggc2V0cyBub1ZuYyBhcyBkZWZhdWx0LCBpdOKAmXMgYWx3YXlzIE5hdGl2 ZSBWTkMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9Ik5MIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+QW55IGFkdmljZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJOTCIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9Ik5MIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJOTCIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk1ldCB2 cmllbmRlbGlqa2UgZ3JvZXQgLyBCZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5NYXJrbyBWcmdvdGljPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlN5c3RlbSBFbmdpbmVlci9DdXN0b21l ciBDYXJlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJOTCIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkFjdGl2ZVZpZGVvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DF8E8FEC510F451387356E6FA4EC8241activevideocom_--

1 0

4.2 Can not set noVnc as default client console
by Vrgotic, Marko 24 Jan '18

24 Jan '18

--_000_488FA86D4D0A440C9C49CA20AC63E472activevideocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBvVmlydC4NCg0KRXhlY3V0aW5nIGVuZ2luZS1jb25maWcg4oCTcyBDbGllbnRNb2RlVm5j RGVmYXVsdD1Ob1ZuYyBkb2VzIG5vdCByZXN1bHQgYXMgZXhwZWN0ZWQuDQoNCkV2ZW4gdGhvdWdo IGNvbW1hbmQgaXMgZXhlY3V0ZWQsIEkgY2Fubm90IGZuZCB0aGUgVk0gY29uc29sZSBzZXR1cCAo ZHVyaW5nIGNyZWF0aW9uKSB3aGljaCBhY3R1YWxseSBzZXRzIG5vVm5jIGFzIGRlZmF1bHQsIGl0 cyBhbHdheXMgTmF0aXZlIFZOQy4NCg0KUGxlYXNlIGFzc2lzdC4NCg0KLS0NCk1ldCB2cmllbmRl bGlqa2UgZ3JvZXQgLyBCZXN0IHJlZ2FyZHMsDQpNYXJrbyBWcmdvdGljDQpTeXN0ZW0gRW5naW5l ZXIvQ3VzdG9tZXIgQ2FyZQ0KQWN0aXZlVmlkZW8NCg0K --_000_488FA86D4D0A440C9C49CA20AC63E472activevideocom_ Content-Type: text/html; charset="utf-8" Content-ID: <6FE443A96B431C4FBDF4AFDCC59C69D9(a)namprd08.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtY29tcG9zZTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5h bWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NTk1LjBwdCA4NDIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBsaW5rPSIj MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRlYXIgb1Zp cnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5FeGVjdXRpbmcg PGk+ZW5naW5lLWNvbmZpZyDigJNzIENsaWVudE1vZGVWbmNEZWZhdWx0PU5vVm5jDQo8L2k+ZG9l cyBub3QgcmVzdWx0IGFzIGV4cGVjdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+RXZlbiB0aG91Z2ggY29tbWFuZCBpcyBleGVjdXRlZCwgSSBjYW5ub3QgZm5k IHRoZSBWTSBjb25zb2xlIHNldHVwIChkdXJpbmcgY3JlYXRpb24pIHdoaWNoIGFjdHVhbGx5IHNl dHMgbm9WbmMgYXMgZGVmYXVsdCwgaXRzIGFsd2F5cyBOYXRpdmUgVk5DLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGxlYXNlIGFzc2lzdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iTkwiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJr aXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPi0tPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iTkwi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29s b3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPk1ldCB2cmllbmRlbGlqa2UgZ3Jv ZXQgLyBCZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5Oi13ZWJraXQtc3RhbmRhcmQ7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t R0IiPk1hcmtvIFZyZ290aWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1H QiI+U3lzdGVtIEVuZ2luZWVyL0N1c3RvbWVyIENhcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6LXdlYmtpdC1zdGFuZGFyZDtjb2xvcjpibGFjazttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1HQiI+QWN0aXZlVmlkZW88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_488FA86D4D0A440C9C49CA20AC63E472activevideocom_--

1 0

Multi OVF_STORE entries
by Stefano Danzi 24 Jan '18

24 Jan '18

Hello, I'm checking Storage -> Disks in my oVirt test site. I can find: - 4 disks for my 4 VM - 1 disk for HostedEngine - 4 OVF_STORE entries, sharables and without size. I can't manage, move or remove OVF_STORE entries. I think that they are somethig ported during some upgrade... Does anyone have any ideas?

2 1

host-passthrough or pcid enable for Westmere and SandyBridge
by Eduardo Mayoral 24 Jan '18

24 Jan '18

Hi, With the meltdown patches, now it is specially beneficial to have the pcid feature in the virtual CPUs. See: https://groups.google.com/forum/#!topic/mechanical-sympathy/L9mHTbeQLNU The PCID feature is available in physical "Westmere" (Release date circa 2010) or newer CPUs. However, in libvirt the pcid feature is only avalilable for virtual CPUs Haswell (Release date circa 2013) or newer. The recomendation is using Haswell, Broadwell or Skylake based model or host passthrough. Now, I think "host passthrough" is not an option for oVirt for good reason so this leaves Haswell, Broadwell or Skylake as options. Is it possible to edit /usr/share/libvirt/cpu_map.xml on the compute nodes to add the pcid feature to the virtual CPU models between Westmere and Haswell (that would be Westmere and SandyBridge)? Is anyone aware if something like this is being considered by the libvirt developers? Actually understanding the implications or doing so is way beyond my skill level. By now you may have guessed that my oVirt clusters use physical Westmere and SandyBridge CPUs :-/ Thanks in advance for your help! -- Eduardo Mayoral Jimeno (emayoral(a)arsys.es) Administrador de sistemas. Departamento de Plataformas. Arsys internet. +34 941 620 145 ext. 5153

2 1

Re: [ovirt-users] New post on oVirt blog: Build oVirt Reports Using Grafana
by Mikhail Krasnobaev 24 Jan '18

24 Jan '18

5 5

Apache Directory Server
by C Williams 24 Jan '18

24 Jan '18

Hello, Has anyone successfully connected the ovirt-engine to Apache Directory Server 2.0 ? I have tried the pre-set connections offered by oVirt and have been able to connect to the server on port 10389 after adding the port to a serverset.port. I can query the directory and see users but I cannot log onto the console as a user in the directory. If any one has any experience/guidance on this, please let me know. Thank You Charles Williams

2 1

How to manage virtual networks in oVirt 4.2?
by Dmitry Semenov 23 Jan '18

23 Jan '18

I use OVN with linuxbridge. Where and how I may adjust routing, NAT etc. for virtual networks? ManageIQ doesn't see them (probably it is devoted that my switch type should be OVS) :( -- Best regards,

2 1

Found some bugs with NFS.
by Sergey Kulikov 23 Jan '18

23 Jan '18

This is test environment, running Centos 7.4, oVirt 4.2.0, kernel 3.10.0-693.11.6.el7.x86_64 (3.10.0-693.11.1 and 3.10.0-693 have same bugs) 1. Can't force NFS to 4.0. Some time ago, I've set my NFS version for all storage domains to V4, because there was a bug with Netapp data ontap 8.x and RHEL, using NFS 4.1(NFS mount started to hang after a while, STATEID problems) v4 on centos 7.2 and 7.3 was mounting NFS as 4.0, so there were no problems related to NFS, after some time Centos 7.4 was released, and I've noticed that mount points started to hang again, NFS was mounted with vers=4.1, and it's not possible to change to 4.0, both options "V4" and "V4.1" mounts as 4.1. Looks like V4 option is system default version for 4.X, and as I know it was changed in Centos 7.4 from 4.0 to 4.1, maybe 4.0 option should be added to force 4.0 version? because adding vers=/nfsvers= in "Additional mount options" is denied by ovirt. I know, I can turn it off on netapp side, but there may be situations where storage is out of control. And 4.0 version can't be set on ovirt side. 2. This bug isn't directly related to ovirt, but affects it. Don't really shure that this is right place to report. As I've said before there were bug with NFS 4.1, Netapp data ontap 8 and RHEL 7.x, but it was fixed in otap 9.x, Now we have 9.x ONTAP on Netapp and it brought new bugs with RHEL 7.4 :D After updating to centos 7.4 nfs domains in ovirt started to hang\lock again, This happens randomly, on random hosts, after few days of uptime, entire datacenter goes offline, hosts down, storage domains down, some vms in UP and some in unknown state, but actually VMs are working, HostedEngine also working, but I can't control the environment. There are many hanging ioprocess(>1300) and vdsm processes(>1300) on some hosts, also there are some dd commands, that are checking storage hanging: ├─vdsmd─┬─2*[dd] │ ├─1304*[ioprocess───{ioprocess}] │ ├─12*[ioprocess───4*[{ioprocess}]] │ └─1365*[{vdsmd}] vdsm 19470 0.0 0.0 4360 348 ? D< Jan21 0:00 /usr/bin/dd if=/rhev/data-center/mnt/10.xx.xx.xx:_test__nfs__sas_iso/6cd147b4-8039-4f8a-8aa7-5fd444454d81/dom_md/metadata of=/dev/null bs=4096 count=1 iflag=direct vdsm 40707 0.0 0.0 4360 348 ? D< 00:44 0:00 /usr/bin/dd if=/rhev/data-center/mnt/10.xx.xx.xx:_test__nfs__sas_export/58d9e2c2-8fef-4abc-be13-a273d6af320f/dom_md/metadata of=/dev/null bs=4096 count=1 iflag=direct vdsm is hanging at 100% cpu load If I'll try to ls this files ls will hang. I've made some dump of traffic, so looks like problem with STATID, I've found 2 issues on RedHat web site, but they aren't publically available, so i can't read the solution: https://access.redhat.com/solutions/3214331 (in my case I have STATEID test) https://access.redhat.com/solutions/3164451 (in my case there is no manager thread) But it looks' that I've another issue with stateid, According to dumps my hosts are sending: TEST_STATEID netapp reply is: Status: NFS4ERR_BAD_STATEID (10025) After this host sends: Network File System, Ops(5): SEQUENCE, PUTFH, OPEN, ACCESS, GETATTR Reply: V4 Reply (Call In 17) OPEN StateID: 0xa205 Request: V4 Call (Reply In 22) READ StateID: 0xca5f Offset: 0 Len: 4096 Reply: V4 Reply (Call In 19) READ Status: NFS4ERR_BAD_STATEID Entire conversaion looks like: No. Time Source Destination Protocol Length Info 1 0.000000 10._host_ 10._netapp_ NFS 238 V4 Call (Reply In 2) TEST_STATEID 2 0.000251 10._netapp_ 10._host_ NFS 170 V4 Reply (Call In 1) TEST_STATEID (here is Status: NFS4ERR_BAD_STATEID (10025)) 3 0.000352 10._host_ 10._netapp_ NFS 338 V4 Call (Reply In 4) OPEN DH: 0xa2c3ad28/ 4 0.000857 10._netapp_ 10._host_ NFS 394 V4 Reply (Call In 3) OPEN StateID: 0xa205 5 0.000934 10._host_ 10._netapp_ NFS 302 V4 Call (Reply In 8) READ StateID: 0xca5f Offset: 0 Len: 4096 6 0.000964 10._host_ 10._netapp_ NFS 302 V4 Call (Reply In 9) READ StateID: 0xca5f Offset: 0 Len: 4096 7 0.001133 10._netapp_ 10._host_ TCP 70 2049 → 683 [ACK] Seq=425 Ack=901 Win=10240 Len=0 TSval=225608100 TSecr=302215289 8 0.001258 10._netapp_ 10._host_ NFS 170 V4 Reply (Call In 5) READ Status: NFS4ERR_BAD_STATEID 9 0.001320 10._netapp_ 10._host_ NFS 170 V4 Reply (Call In 6) READ Status: NFS4ERR_BAD_STATEID Sometimes clearing locks on netapp(vserver locks break) and killing dd\ioprocess will help for a while. Right now I've my test setup in this state, looks like lock problem is always with metadata\disk check, but not domain itself, I can read and write other files in this mountpoint from the same host. Hosts have 3.10.0-693.11.6.el7.x86_64 kernel, ovirt 4.2.0 can't find out If it's Netapp or Centos bug. If somebody wants to look closer on dumps, I can mail them directly. --

2 3