- Users - oVirt List Archives

Short SSL key sizes, and TLS 1.2 on vdsm
by Chris H 15 Aug '16

15 Aug '16

Hello, My RHEVM hypervisors (Red Hat Enterprise Virtualization Hypervisor release 7.2 (20160627.3.el7ev)) are failing corporate Nessus TCP/IP vulnerability scans spectacularly with the following. 1) "SSL Certificate Chain Contains RSA Keys Less Than 2048 bits": many ports in the 5900 range are presenting certificates signed by a key of 1024 bits. I can certainly see 1024-bit keys on the management server and the hypervisors: management ovirt-engine]# openssl x509 -in ca.pem -noout -text | grep Public-Key Public-Key: (1024 bit) hypervisor admin]# openssl x509 -in /etc/pki/vdsm/certs/cacert.pem -noout -text | grep Public-Key Public-Key: (1024 bit) Can anyone point me at directions on how to regenerate the key(s) with 2048 bits, and all certificates, preferably without breaking anything? The management server is running RHEL 6.8, rhevm-3.6.7.5. 2) "TLS Version 1.2 Protocol Detection": Port 54321 is failing because it doesn't support TLS v1.2 (and also because its certificate's key is less than 2048 bits). This port is used by "/usr/bin/python /usr/share/vdsm/vdsm". Can I enable TLS v1.2 in vdsm? It doesn't have to accept TLSv1.2 exclusively, it just has to have v1.2 available (and NOT SSLv2 or 3). If I firewall off these ports, I can't connect to VMs' consoles anymore, so hiding from the scanner isn't feasible for long. Please help point me in the right direction. Thanks, Chris -- *The Starflyer is real!*

1 0

LDAP-based domain not working after upgrade?
by Nicolás 15 Aug '16

15 Aug '16

Hi, We're running oVirt 4.0.1.1, and we're trying to grant a permission to a user on a VM. Thing is when we open the 'Permissions' subtab on that VM, we click on Add, the LDAP backend shows up but any value entered into the search box returns nothing, even when I know the values exist. This has been working on oVirt 3.x, we actually migrated to 4.x last week and didn't notice this issue. Additionally, there's no combobox to choose the permission to grant? All this is done with the admin@internal user, so I guess this is not a self-permission issue. Interesting thing is that I can successfully log-in to the user portal with a LDAP based user and manage all the VMs assigned to them. Just to see if there's been any configuration change, we also run the ovirt-engine-extension-aaa-ldap-setup tool, the configuration it returns is pretty similar to ours, and even the test commands (Login, Search) work successfully (I can see search returning user's data like name, surname, ...). We even applied this configuration to engine to see if it makes a difference but the result is the same, the search dialog returns nothing and neither I can see the permission to grant. Any hint about this? Thanks

4 14

xml config file being used in ovirt different from virsh?
by Bill Bill 15 Aug '16

15 Aug '16

--_000_CO2PR0801MB07431E23EE4A4AFFE56128E0A61F0CO2PR0801MB0743_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIGEgVk0gd2l0aCBuZXR3b3JrIGZpbHRlcmluZyBlbmFibGVkLCBzcGVjaWZpY2FsbHkg dGhlIGNsZWFuLXRyYWZmaWMgZmlsdGVyLg0KDQpUaHJvdWdoIHZpcnNoLCBJIG1vZGlmeSB0aGUg Y29uZmlndXJhdGlvbiB0byByZWZsZWN0IGNoYW5nZXMgbGlrZSB0aGlzOg0KDQogICAgIDxmaWx0 ZXJyZWYgZmlsdGVyPSdjbGVhbi10cmFmZmljJz4NCiAgICAgICAgPHBhcmFtZXRlciBuYW1lPSdJ UCcgdmFsdWU9JzE5Mi4xNjguMTAuMTAuJy8+DQogICAgICAgIDxwYXJhbWV0ZXIgbmFtZT0nSVAn IHZhbHVlPScxOTIuMTY4LjEwLjExJy8+DQogICAgICA8L2ZpbHRlcnJlZj4NCg0KVGhpcyBvbmx5 IGFsbG93cyB0aG9zZSB0d28gc3BlY2lmaWVkIElQ4oCZcyB0byBjb21tdW5pY2F0ZSBvbiB0aGUg Vk0uIEnigJl2ZSBkZWZpbmVkIHRoZSB4bWwgdGhyb3VnaCB2aXJzaC4NCg0KTm93LCBpZiBJIHN0 YXJ0IHRoZSBWTSBkaXJlY3RseSB0aHJvdWdoIHZpcnNoLCB0aG9zZSBydWxlcyBhcHBseSBhbmQg d29yayBjb3JyZWN0bHkuIEkgY2FuIGFkZCBhbnkgb3RoZXIgcmFuZG9tIElQIGZyb20gdGhlIHNh bWUgc3VibmV0IGFuZCBpdCBkb2VzIG5vdCB3b3JrLCBhcyBleHBlY3RlZC4gT25seSB0aGUgdHdv IElw4oCZcyBzcGVjaWZpZWQgYWJvdmUgd2lsbCByZXNwb25kLg0KDQpUaGlzIHVuZm9ydHVuYXRl bHksIG1ha2VzIHRoZSBWTSBhcHBlYXIgdG8gYmUgZG93biBmcm9tIHdpdGggdGhlIG92aXJ0IGRh c2hib2FyZCBpZiBpdOKAmXMgc3RhcnRlZCBtYW51YWxseSB0aHJvdWdoIHZpcnNoLg0KDQpJZiBJ IGVkaXQgdGhlIG1hY2hpbmUgdGhyb3VnaCB2aXJzaCBidXQgZG8gbm90IHN0YXJ0IGl0IGFuZCB0 aGVuIGdvIG9udG8gb1ZpcnQgdG8gc3RhcnQgdGhlIFZNLCBpdCBzZWVtcyB0aGUgY29uZmlndXJh dGlvbiBpcyBub3QgbG9hZGVkIOKAkyBkb2VzIG9WaXJ0IGxvYWQgYSBkaWZmZXJlbnQgY29uZmln dXJhdGlvbiBmaWxlIG90aGVyIHRoYW4gL2V0Yy9saWJ2aXJ0L3FlbXUvbWFjaGluZS54bWw/DQo= --_000_CO2PR0801MB07431E23EE4A4AFFE56128E0A61F0CO2PR0801MB0743_ Content-Type: text/html; charset="utf-8" Content-ID: <4B0D61C4EF4E6348BF40DF4B18975372(a)sct-15-1-485-2-msonline-outlook-1173a.templateTenant> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0iIzk1NEY3 MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBo YXZlIGEgVk0gd2l0aCBuZXR3b3JrIGZpbHRlcmluZyBlbmFibGVkLCBzcGVjaWZpY2FsbHkgdGhl IGNsZWFuLXRyYWZmaWMgZmlsdGVyLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhyb3VnaCB2aXJzaCwgSSBtb2Rp ZnkgdGhlIGNvbmZpZ3VyYXRpb24gdG8gcmVmbGVjdCBjaGFuZ2VzIGxpa2UgdGhpczo8L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7ZmlsdGVycmVmIGZpbHRlcj0nY2xl YW4tdHJhZmZpYycmZ3Q7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtwYXJhbWV0ZXIgbmFtZT0nSVAnIHZhbHVl PScxOTIuMTY4LjEwLjEwLicvJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7cGFyYW1ldGVyIG5hbWU9J0lQ JyB2YWx1ZT0nMTkyLjE2OC4xMC4xMScvJmd0OzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L2ZpbHRlcnJlZiZndDs8L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+VGhpcyBv bmx5IGFsbG93cyB0aG9zZSB0d28gc3BlY2lmaWVkIElQ4oCZcyB0byBjb21tdW5pY2F0ZSBvbiB0 aGUgVk0uIEnigJl2ZSBkZWZpbmVkIHRoZSB4bWwgdGhyb3VnaCB2aXJzaC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyxzZXJpZiI+Tm93LCBpZiBJIHN0YXJ0IHRoZSBWTSBkaXJlY3RseSB0aHJvdWdoIHZpcnNoLCB0 aG9zZSBydWxlcyBhcHBseSBhbmQgd29yayBjb3JyZWN0bHkuIEkgY2FuIGFkZCBhbnkgb3RoZXIg cmFuZG9tIElQIGZyb20gdGhlIHNhbWUgc3VibmV0IGFuZCBpdCBkb2VzIG5vdCB3b3JrLCBhcyBl eHBlY3RlZC4NCiBPbmx5IHRoZSB0d28gSXDigJlzIHNwZWNpZmllZCBhYm92ZSB3aWxsIHJlc3Bv bmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPlRoaXMgdW5mb3J0dW5hdGVseSwgbWFrZXMgdGhlIFZN IGFwcGVhciB0byBiZSBkb3duIGZyb20gd2l0aCB0aGUgb3ZpcnQgZGFzaGJvYXJkIGlmIGl04oCZ cyBzdGFydGVkIG1hbnVhbGx5IHRocm91Z2ggdmlyc2guPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPklm IEkgZWRpdCB0aGUgbWFjaGluZSB0aHJvdWdoIHZpcnNoIGJ1dCBkbyBub3Qgc3RhcnQgaXQgYW5k IHRoZW4gZ28gb250byBvVmlydCB0byBzdGFydCB0aGUgVk0sIGl0IHNlZW1zIHRoZSBjb25maWd1 cmF0aW9uIGlzIG5vdCBsb2FkZWQg4oCTIGRvZXMgb1ZpcnQgbG9hZCBhIGRpZmZlcmVudCBjb25m aWd1cmF0aW9uDQogZmlsZSBvdGhlciB0aGFuIC9ldGMvbGlidmlydC9xZW11L21hY2hpbmUueG1s PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CO2PR0801MB07431E23EE4A4AFFE56128E0A61F0CO2PR0801MB0743_--

3 4

new internal SSO
by Fabrice Bacchella 15 Aug '16

15 Aug '16

--Apple-Mail=_138C94D8-E499-4C85-8D42-96B668C52119 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm currently fighting with the new mandatory SSO system introduced in = 4.0. It's also used internally as ovirt-engine is calling himself, as shown = in the apache log, to identity himself to himself: [2016-08-12 11:30:24] 10.83.16.34 "ovirt.prod.exalead.com" "POST = /ovirt-engine/sso/status HTTP/1.1" 256 401 + 163 "-" "Java/1.8.0_92" [2016-08-12 10:55:49] 10.83.16.34 "ovirt.prod.exalead.com" "POST = /ovirt-engine/sso/oauth/token HTTP/1.1" 237 401 + 163 "-" = "Java/1.8.0_92" But the sso will be acceded by human too: [2016-08-12 11:29:27] 192.168.205.59 "ovirt.prod.exalead.com" "GET = /ovirt-engine/sso/interactive-redirect-to-module HTTP/1.1" 5097 302 + - = "https://ovirt.prod.exalead.com/ovirt-engine/" "Mozilla/5.0 (Macintosh; = Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Firefox/47.0" I'm using a custom apache configuration, as I need that to better = integrate ovirt in our running SSO and PKI setup. So under SSO I wonder which part needs to be protected using our own = SSO, and what part can be open to any access, and the internal security = of ovirt will manage it ? In https://bugzilla.redhat.com/show_bug.cgi?id=3D1342192, it seems for = me that = ^/ovirt-engine/sso/(interactive-login-negotiate|oauth/token-http-auth) = needs to be protected. Am i right ? In my log, I've seen access to: /ovirt-engine/sso/status /ovirt-engine/sso/oauth/token-info /ovirt-engine/webadmin/sso/oauth2-callback /ovirt-engine/webadmin/sso/login /ovirt-engine/sso/oauth/token /ovirt-engine/sso/oauth/authorize /ovirt-engine/sso/interactive-redirect-to-module /ovirt-engine/sso/interactive-login-next-auth /ovirt-engine/sso/interactive-login-negotiate/ovirt-auth= --Apple-Mail=_138C94D8-E499-4C85-8D42-96B668C52119 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D"">I'm currently fighting with the new mandatory SSO system = introduced in 4.0.<div class=3D""><br class=3D""></div><div = class=3D"">It's also used internally as ovirt-engine is calling himself, = as shown in the apache log, to identity himself to himself:</div><div = class=3D""><br class=3D""></div><div class=3D""><div style=3D"margin: = 0px; font-size: 11px; line-height: normal; font-family: Menlo;" = class=3D""><span style=3D"font-variant-ligatures: no-common-ligatures" = class=3D"">[2016-08-12 11:30:24] 10.83.16.34 "<a = href=3D"http://ovirt.prod.exalead.com" = class=3D"">ovirt.prod.exalead.com</a>" "POST /ovirt-engine/sso/status = HTTP/1.1" 256 401 + 163 "-" "Java/1.8.0_92"</span></div></div><div = class=3D""><span style=3D"font-variant-ligatures: no-common-ligatures" = class=3D""><div style=3D"margin: 0px; font-size: 11px; line-height: = normal; font-family: Menlo;" class=3D""><span = style=3D"font-variant-ligatures: no-common-ligatures" = class=3D"">[2016-08-12 10:55:49] 10.83.16.34 "<a = href=3D"http://ovirt.prod.exalead.com" = class=3D"">ovirt.prod.exalead.com</a>" "POST = /ovirt-engine/sso/oauth/token HTTP/1.1" 237 401 + 163 "-" = "Java/1.8.0_92"</span></div><div class=3D""><span = style=3D"font-variant-ligatures: no-common-ligatures" class=3D""><br = class=3D""></span></div></span></div><div class=3D"">But the sso will be = acceded by human too:</div><div class=3D""><br class=3D""></div><div = class=3D""><div style=3D"margin: 0px; font-size: 11px; line-height: = normal; font-family: Menlo;" class=3D""><span = style=3D"font-variant-ligatures: no-common-ligatures" = class=3D"">[2016-08-12 11:29:27] 192.168.205.59 "<a = href=3D"http://ovirt.prod.exalead.com" = class=3D"">ovirt.prod.exalead.com</a>" "GET = /ovirt-engine/sso/interactive-redirect-to-module HTTP/1.1" 5097 302 + - = "<a href=3D"https://ovirt.prod.exalead.com/ovirt-engine/" = class=3D"">https://ovirt.prod.exalead.com/ovirt-engine/</a>" = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 = Firefox/47.0"</span></div></div><div class=3D""><span = style=3D"font-variant-ligatures: no-common-ligatures" class=3D""><br = class=3D""></span></div><div class=3D""><br class=3D""></div><div = class=3D"">I'm using a custom apache configuration, as I need that to = better integrate ovirt in our running SSO and PKI setup.</div><div = class=3D""><br class=3D""></div><div class=3D"">So under SSO I wonder = which part needs to be protected using our own SSO, and what part can be = open to any access, and the internal security of ovirt will manage it = ?</div><div class=3D""><br class=3D""></div><div class=3D"">In <a = href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1342192" = class=3D"">https://bugzilla.redhat.com/show_bug.cgi?id=3D1342192</a>, it = seems for me that <span style=3D"white-space: pre-wrap;" = class=3D"">^/ovirt-engine/sso/(interactive-login-negotiate|oauth/token-htt= p-auth) needs to be protected. Am i right ?</span></div><div = class=3D""><br class=3D""></div><div class=3D"">In my log, I've seen = access to:</div><div class=3D""><br class=3D"">/ovirt-engine/sso/status<br= class=3D"">/ovirt-engine/sso/oauth/token-info<br = class=3D"">/ovirt-engine/webadmin/sso/oauth2-callback<br = class=3D"">/ovirt-engine/webadmin/sso/login<br = class=3D"">/ovirt-engine/sso/oauth/token<br = class=3D"">/ovirt-engine/sso/oauth/authorize<br = class=3D"">/ovirt-engine/sso/interactive-redirect-to-module<br = class=3D"">/ovirt-engine/sso/interactive-login-next-auth<br = class=3D"">/ovirt-engine/sso/interactive-login-negotiate/ovirt-auth</div><= /body></html>= --Apple-Mail=_138C94D8-E499-4C85-8D42-96B668C52119--

2 2

unable to find valid certification path to requested target
by Bill Bill 15 Aug '16

15 Aug '16

--_000_CO2PR0801MB0743DBC3AD940D3496CE9880A6100CO2PR0801MB0743_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVjZW50bHkgdXBncmFkZWQgb3ZpcnQtZW5naW5lIGFuZCBub3cgY2Fubm90IGxvZyBpbi4gR2V0 dGluZyB0aGUgZXJyb3IgYmVsb3c6DQoNCg0Kc3VuLnNlY3VyaXR5LnZhbGlkYXRvci5WYWxpZGF0 b3JFeGNlcHRpb246IFBLSVggcGF0aCBidWlsZGluZyBmYWlsZWQ6IHN1bi5zZWN1cml0eS5wcm92 aWRlci5jZXJ0cGF0aC5TdW5DZXJ0UGF0aEJ1aWxkZXJFeGNlcHRpb246IHVuYWJsZSB0byBmaW5k IHZhbGlkIGNlcnRpZmljYXRpb24gcGF0aCB0byByZXF1ZXN0ZWQgdGFyZ2V0DQoNCg== --_000_CO2PR0801MB0743DBC3AD940D3496CE9880A6100CO2PR0801MB0743_ Content-Type: text/html; charset="utf-8" Content-ID: <87541A889A1A18439B925049574FD1FF(a)sct-15-1-485-2-msonline-outlook-1173a.templateTenant> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LndlbGNvbWUtdGl0bGUNCgl7bXNvLXN0eWxlLW5hbWU6d2VsY29tZS10aXRsZTt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0iIzk1NEY3MiI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVjZW50 bHkgdXBncmFkZWQgb3ZpcnQtZW5naW5lIGFuZCBub3cgY2Fubm90IGxvZyBpbi4gR2V0dGluZyB0 aGUgZXJyb3IgYmVsb3c6PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJ3ZWxjb21lLXRpdGxlIj5zdW4uc2VjdXJpdHku dmFsaWRhdG9yLlZhbGlkYXRvckV4Y2VwdGlvbjogUEtJWCBwYXRoIGJ1aWxkaW5nIGZhaWxlZDog c3VuLnNlY3VyaXR5LnByb3ZpZGVyLmNlcnRwYXRoLlN1bkNlcnRQYXRoQnVpbGRlckV4Y2VwdGlv bjogdW5hYmxlIHRvIGZpbmQgdmFsaWQgY2VydGlmaWNhdGlvbiBwYXRoIHRvIHJlcXVlc3RlZCB0 YXJnZXQ8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_CO2PR0801MB0743DBC3AD940D3496CE9880A6100CO2PR0801MB0743_--

2 1

Move VM disks from gluster storage to local storage
by Siavash Safi 14 Aug '16

14 Aug '16

Hi, An unknown bug broke our gluster storage (dom_md/ids is corrupted) and oVirt no longer activates the storage(I tried to recover it using the similar issues reported in mailing list but it didn't work). As I checked VM disk images are still accessible when I mount the gluster storage manually. How can we manually move the VM disk images to local storage? (oVirt complains about gluster storage being inactive when using the web interface for move/copy) Thanks, Siavash

2 4

How to open vm console by API ?
by Wang Evan 14 Aug '16

14 Aug '16

--_000_HK2PR0401MB13322CE62E444F628CF2E3F5D71F0HK2PR0401MB1332_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi : I want to integrate oVirt-engine into our system platform. In reference to = ovirt rest API , I have finished added host and create virtual machine. But= I can't find the way to open vm console by API or CLI ,so what should I do= ? Thanks ! Evan --_000_HK2PR0401MB13322CE62E444F628CF2E3F5D71F0HK2PR0401MB1332_ Content-Type: text/html; charset="us-ascii" Content-ID: <959C49C01EEEAB4B9F2C281FC1C76AB6(a)sct-15-1-485-9-msonline-outlook-33ea8.templateTenant> Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"ZH-CN" link=3D"#0563C1" vlink=3D"#954F72" style=3D"text-justi= fy-trim:punctuation"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US">Hi :<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">I want to integrate oVirt-engin= e into our system platform. In reference to ovirt rest API , I have finishe= d added host and create virtual machine. But I can't find the way to open v= m console by API or CLI ,so what should I do ?<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Thanks !<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Evan<o:p></o:p></span></p> </div> </body> </html> --_000_HK2PR0401MB13322CE62E444F628CF2E3F5D71F0HK2PR0401MB1332_--

3 2

LVM2 Thinprovisioned
by Fernando Frediani 14 Aug '16

14 Aug '16

Hello all. When you use oVirt with a Block Storage the only option available to store de VMs is LVM. Does LVM in oVirt use Thinprovisoned (supported in LVM2) instead of having to use the SAN Thinprovisioned features ? Fernando

5 8

General system updates policy
by David Gossage 14 Aug '16

14 Aug '16

Is it considered safe from an ovirt stability standpoint to apply yum updates to the hosts and engine as centos/redhat release them? For example the recent https://rhn.redhat.com/errata/RHSA-2016-1606.html update for qemu. If I run yum update and update that is their any worry for me that it has not been tested with oVirt and so versions will break something. Same with kernels, libraries etc.. *David Gossage* *Carousel Checks Inc. | System Administrator* *Office* 708.613.2284

3 3

Storage for my Environment
by Michael Cooper 14 Aug '16

14 Aug '16

This is a multi-part message in MIME format. --------------F4353BC018BCA8D035BFD678 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hello Guys, I am sorry ask a stupid question again, however I am not sure how to add storage to the environment that I have at the moment. I have 4 Servers 3 of them are AMD and one Intel Core i7, on my servers I have 2 Dell SC1435's and one HP DL385 G5 I have the Engine Running and I have added a node as well, Both of them are Physical servers they both have 1 tb drives, I would like to add the drive in the node as storage how would I accomplish that? Thank you very much in advance, -- *Michael Cooper* http://www.coopfire.com Linux/VMWare Certified Professional --------------F4353BC018BCA8D035BFD678 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hello Guys,<br> <br> I am sorry ask a stupid question again, however I am not sure how to add storage to the environment that I have at the moment. I have 4 Servers 3 of them are AMD and one Intel Core i7, on my servers I have 2 Dell SC1435's and one HP DL385 G5<br> <br> I have the Engine Running and I have added a node as well, Both of them are Physical servers they both have 1 tb drives, I would like to add the drive in the node as storage how would I accomplish that?<br> <br> Thank you very much in advance, <br> <div class="moz-signature">-- <br> <b><font color="#008080">Michael Cooper</font></b><br> <a class="moz-txt-link-freetext" href="http://www.coopfire.com">http://www.coopfire.com</a><br> Linux/VMWare Certified Professional<br> </div> </body> </html> --------------F4353BC018BCA8D035BFD678--

3 3