- Users - oVirt List Archives

oVirt AD integration problems
by cmc 17 Oct '16

17 Oct '16

Hi, I'm trying to use the directory services provided by the ovirt-engine-extension-aaa-ldap, and I can get it to successfully login when I run the tests in the setup script, but when I login via the GUI, it gives me: unexpected error was encountered during validation processing: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated' and fails login. It looks a bit like it is expecting to already be joined to the domain, so I tried doing that manually via realmd and sssd. It involved installing a lot of packages, such as kerberos and samba, which I am nervous about on an engine host. Anyway, once I was joined, it still gives me the same 'peer not authenticated' message. Does it need to be separately bound to the domain, i.e., do you need all the other stuff installed and running for it to work, or is the ovirt-engine-extension-aaa-ldap package all that is needed? Anyway, I ran the ovirt-engine-extensions-tool --log-level=FINEST --log-file=/tmp/aaa.log aaa search --extension-name=domain-authz command suggested in an earlier post, and it only gave me one exception, which was: 2016-09-28 16:08:15 SEVERE Extension domain-authz could not be found 2016-09-28 16:08:15 FINE Exception: org.ovirt.engine.core.extensions.mgr.ConfigurationException: Extension domain-authz could not be found Thanks for any help, Cam

2 9

Re: [ovirt-users] oVirt AD integration problems
by Karli Sjöberg 14 Oct '16

14 Oct '16

--_000_ae004950fd40475d99b4ac034352c4b2exch24sluse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMTQgb2t0LiAyMDE2IDQ6MzAgZW0gc2tyZXYgY21jIDxpdWNvdW51QGdtYWlsLmNvbT46 DQo+DQo+IEhpIE9uZHJhLA0KPg0KPiBJdCBtYW5hZ2VzIHRvIGF1dGhlbnRpY2F0ZSwgYnV0IGFw cGVuZHMgdGhlIGRvbWFpbiBhZ2FpbiBvbmNlIEknbSBsb2dnZWQgaW4sIGZvciBpbnN0YW5jZSwg aWYgSSBsb2cgaW4gYXMgdXNlciAnY2FtJywgaXQgd2lsbCBsb2cgbWUgaW4sDQo+IGFuZCBkaXNw bGF5IHRoZSBsb2dpbiBuYW1lIGluIHRoZSB0b3AgcmlnaHQgY29ybmVyIGFzICdjYW1AZG9tYWlu LmNvbUBkb21haW4uY29tJyAodGhpcyBzaG93cyB1cCBpbiB0aGUgbG9nIGFzIHdlbGw6IGl0IHNo b3dzIG1lDQo+IGxvZ2dpbmcgaW4gYXMgY2FtQGRvbWFpbi5jb20sIGJ1dCB0aGVuIHJldHVybnMg YW4gZXJyb3IgYXMgdXNlciAgY2FtQGRvbWFpbi5jb21AZG9tYWluLmNvbSBpcyBub3QgYXV0aG9y aXplZCkuIE15IHRob3VnaHQgd2FzDQo+IHRoYXQgc29tZXRoaW5nIGRvbmUgZWFybGllciB3aGVu IEkgd2FzIHBsYXlpbmcgYXJvdW5kIHdpdGggc3NzZCwga2VyYmVyb3MgYW5kIEFEIGlzIGRvaW5n IHRoaXMsIHRob3VnaCBJIGhhdmUgcmVtb3ZlZCB0aGVzZSBwYWNrYWdlcw0KPiBhbmQgcnVuIGF1 dGhjb25maWcgdG8gcmVtb3ZlIHNzc2QuIEFueSBpZGVhcz8NCg0KQ2FuJ3Qgc2F5IHdoeSwgYnV0 IGl0J3MgdGhlIHNhbWUgZm9yIHVzLiBJdCdzIHVuc2lnaHRseSwga2luZGx5IHB1dC4NCg0KL0sN Cg0KPg0KPiBDaGVlcnMsDQo+DQo+IENhbQ0KPg0KPiBPbiBUaHUsIE9jdCAxMywgMjAxNiBhdCAy OjA0IFBNLCBjbWMgPGl1Y291bnVAZ21haWwuY29tPiB3cm90ZToNCj4+DQo+PiBIaSBPbmRyYSwN Cj4+DQo+PiBUaGF0IGlzIGdvb2QgdG8ga25vdyB0aGF0IHdlIGRvbid0IG5lZWQgS2VyYmVyb3Mg LSBpdCBjb21wbGljYXRlcyB0aGluZ3MgYSBsb3QuDQo+Pg0KPj4gSSB0aGluayB0aGUgZXJyb3Jz IG1pZ2h0IGJlIHRoZSBvcHRpb25zIEknZCBzZWxlY3RlZCBkdXJpbmcgdGhlIHNldHVwLiBJIHdh cyB0aHJvd24gYSBiaXQgdGhhdA0KPj4gaXQgcGFzc2VkIGFsbCB0aGUgaW50ZXJuYWwgdGVzdHMg cHJvdmlkZWQgYnkgdGhlIHNldHVwIHNjcmlwdCwgYnV0IGZhaWxlZCBvbiB0aGUgd2ViIEdVSS4g V2hlbg0KPj4gSSd2ZSBzZWVuICd1bnNwZWNpZmllZCBHU1MgZmFpbHVyZScgYW5kICdwZWVyIG5v dCBhdXRoZW50aWNhdGVkJyBpdCdzIHVzdWFsbHkgYmVlbiBkdWUgdG8NCj4+IEtlcmJlcm9zICh0 aG91Z2ggYWRtaXR0ZWRseSB0aGVzZSBhcmUganVzdCBnZW5lcmljIGVycm9ycykuIFNvIEkgdHJp ZWQgdGhlIFJlZGhhdCBndWlkZSBmb3IgU1NPIGF0Og0KPj4NCj4+IGh0dHBzOi8vYWNjZXNzLnJl ZGhhdC5jb20vZG9jdW1lbnRhdGlvbi9lbi1VUy9SZWRfSGF0X0VudGVycHJpc2VfVmlydHVhbGl6 YXRpb24vMy42L2h0bWwvQWRtaW5pc3RyYXRpb25fR3VpZGUvQ29uZmlndXJpbmdfTERBUF9hbmRf S2VyYmVyb3NfZm9yX1NpbmdsZV9TaWduLW9uLmh0bWwNCj4+DQo+PiB3aGljaCB1c2VzIEtlcmJl cm9zIChpbiBvdmlydC1zc28uY29uZikgSSBoYWQgdG8gcmVtb3ZlIHRoZSBzeW1saW5rIHRvIHRo ZSBBcGFjaGUNCj4+IGNvbmZpZyBpdCBzYXlzIHRvIGNyZWF0ZSwgYXMgaXQgcmVzdWx0cyBpbiBp bnRlcm5hbCBzZXJ2ZXIgZXJyb3JzIGluIEFwYWNoZS4gSXQgdXNlcyBhbiBTUE4gZm9yDQo+PiBB cGFjaGUgaW4gdGhlIGtleXRhYi4NCj4+DQo+PiBOb3cgdGhhdCB5b3UndmUgY29uZmlybWVkIHRo YXQgaXQgY2FuIGFjdHVhbGx5IHdvcmsgd2l0aG91dCBhbnkgbmVlZCBmb3IgdGhlIEtlcmJlcm9z IHN0dWZmLA0KPj4gSSB3aWxsIHN0YXJ0IGFmcmVzaCBmcm9tIGEgY2xlYW4gc2V0dXAgYW5kIGFw cGx5IHdoYXQgSSd2ZSBsZWFybnQgZHVyaW5nIHRoaXMgcHJvY2Vzcy4NCj4+DQo+PiBJJ2xsIHRy eSBpdCBvdXQgYW5kIGxldCB5b3Uga25vdyBlaXRoZXIgd2F5Lg0KPj4NCj4+IE1hbnkgdGhhbmtz IGZvciBhbGwgdGhlIGhlbHAhDQo+Pg0KPj4gS2luZCByZWdhcmRzLA0KPj4NCj4+IENhbQ0KPj4N Cj4+DQo+Pj4NCj4+PiBZZXMsIHlvdSByZWFsbHkgZG8gbm90IG5lZWQgYW55dGhpbmcga2VyYmVy b3MgcmVsYXRlZCB0byBzZWN1cmVseSBiaW5kDQo+Pj4gdG8gQUQgdmlhIExEQVAgc2ltcGxlIGJp bmQgb3ZlciBUTFMvU1NMLiBUaGlzIGlzIHJlYWxseSBzdHJhbmdlIHRvIG1lDQo+Pj4gd2hhdCBl cnJvcnMgeW91IGFyZSBnZXR0aW5nLCBidXQgeW91IHByb2JhYmx5IGNvbmZpZ3VyZWQgYXBhY2hl IChvcg0KPj4+IHNvbWV0aGluZyBlbHNlPykgdG8gcmVxdWlyZSBrZXl0YWIsIGJ1dCB5b3UgZG9u J3QgaGF2ZSB0bywgYW5kIHlvdSBjYW4NCj4+PiByZW1vdmUgdGhhdCBjb25maWd1cmF0aW9uLg0K Pj4+DQo+Pj4+DQo+Pj4+IFRoYW5rcywNCj4+Pj4NCj4+Pj4gQ2FtDQo+Pj4+DQo+Pj4+DQo+Pj4+ DQo+Pj4+DQo+Pj4+ICAgICAgICAgVGhhbmtzLA0KPj4+Pg0KPj4+PiAgICAgICAgIENhbQ0KPj4+ Pg0KPj4+PiAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4+DQo+Pj4+ICAgICAgICAgICAgICAgICBVc2VycyBtYWlsaW5nIGxpc3QNCj4+ Pj4gICAgICAgICAgICAgICAgIFVzZXJzQG92aXJ0Lm9yZyA8bWFpbHRvOlVzZXJzQG92aXJ0Lm9y Zz4NCj4+Pj4gICAgICAgICA8bWFpbHRvOlVzZXJzQG92aXJ0Lm9yZyA8bWFpbHRvOlVzZXJzQG92 aXJ0Lm9yZz4+DQo+Pj4+ICAgICAgICAgICAgICAgICBodHRwOi8vbGlzdHMub3ZpcnQub3JnL21h aWxtYW4vbGlzdGluZm8vdXNlcnMNCj4+Pj4gICAgICAgICA8aHR0cDovL2xpc3RzLm92aXJ0Lm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzPg0KPj4+PiAgICAgICAgICAgICAgICAgPGh0dHA6Ly9s aXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vycw0KPj4+PiAgICAgICAgIDxodHRw Oi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnM+Pg0KPj4+Pg0KPj4+Pg0K Pj4+Pg0KPj4NCj4NCg== --_000_ae004950fd40475d99b4ac034352c4b2exch24sluse_ Content-Type: text/html; charset="utf-8" Content-ID: <C9AD4240A2DFAF4C92BCD8DA27CCC9CD(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAxNCBva3QuIDIwMTYgNDozMCBlbSBza3JldiBjbWMgJmx0O2l1Y291bnVAZ21h aWwuY29tJmd0Ozo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSBPbmRyYSw8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBJdCBtYW5hZ2VzIHRvIGF1dGhlbnRpY2F0ZSwgYnV0IGFwcGVuZHMgdGhlIGRvbWFpbiBh Z2FpbiBvbmNlIEknbSBsb2dnZWQgaW4sIGZvciBpbnN0YW5jZSwgaWYgSSBsb2cgaW4gYXMgdXNl ciAnY2FtJywgaXQgd2lsbCBsb2cgbWUgaW4sPGJyPg0KJmd0OyBhbmQgZGlzcGxheSB0aGUgbG9n aW4gbmFtZSBpbiB0aGUgdG9wIHJpZ2h0IGNvcm5lciBhcyAnY2FtQGRvbWFpbi5jb21AZG9tYWlu LmNvbScgKHRoaXMgc2hvd3MgdXAgaW4gdGhlIGxvZyBhcyB3ZWxsOiBpdCBzaG93cyBtZTxicj4N CiZndDsgbG9nZ2luZyBpbiBhcyBjYW1AZG9tYWluLmNvbSwgYnV0IHRoZW4gcmV0dXJucyBhbiBl cnJvciBhcyB1c2VyJm5ic3A7IGNhbUBkb21haW4uY29tQGRvbWFpbi5jb20gaXMgbm90IGF1dGhv cml6ZWQpLiBNeSB0aG91Z2h0IHdhczxicj4NCiZndDsgdGhhdCBzb21ldGhpbmcgZG9uZSBlYXJs aWVyIHdoZW4gSSB3YXMgcGxheWluZyBhcm91bmQgd2l0aCBzc3NkLCBrZXJiZXJvcyBhbmQgQUQg aXMgZG9pbmcgdGhpcywgdGhvdWdoIEkgaGF2ZSByZW1vdmVkIHRoZXNlIHBhY2thZ2VzPGJyPg0K Jmd0OyBhbmQgcnVuIGF1dGhjb25maWcgdG8gcmVtb3ZlIHNzc2QuIEFueSBpZGVhcz88L3A+DQo8 cCBkaXI9Imx0ciI+Q2FuJ3Qgc2F5IHdoeSwgYnV0IGl0J3MgdGhlIHNhbWUgZm9yIHVzLiBJdCdz IHVuc2lnaHRseSwga2luZGx5IHB1dC48L3A+DQo8cCBkaXI9Imx0ciI+L0s8L3A+DQo8cCBkaXI9 Imx0ciI+Jmd0Ozxicj4NCiZndDsgQ2hlZXJzLDxicj4NCiZndDs8YnI+DQomZ3Q7IENhbTxicj4N CiZndDs8YnI+DQomZ3Q7IE9uIFRodSwgT2N0IDEzLCAyMDE2IGF0IDI6MDQgUE0sIGNtYyAmbHQ7 aXVjb3VudUBnbWFpbC5jb20mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg SGkgT25kcmEsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGF0IGlzIGdvb2QgdG8ga25v dyB0aGF0IHdlIGRvbid0IG5lZWQgS2VyYmVyb3MgLSBpdCBjb21wbGljYXRlcyB0aGluZ3MgYSBs b3QuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJIHRoaW5rIHRoZSBlcnJvcnMgbWlnaHQg YmUgdGhlIG9wdGlvbnMgSSdkIHNlbGVjdGVkIGR1cmluZyB0aGUgc2V0dXAuIEkgd2FzIHRocm93 biBhIGJpdCB0aGF0PGJyPg0KJmd0OyZndDsgaXQgcGFzc2VkIGFsbCB0aGUgaW50ZXJuYWwgdGVz dHMgcHJvdmlkZWQgYnkgdGhlIHNldHVwIHNjcmlwdCwgYnV0IGZhaWxlZCBvbiB0aGUgd2ViIEdV SS4gV2hlbg0KPGJyPg0KJmd0OyZndDsgSSd2ZSBzZWVuICd1bnNwZWNpZmllZCBHU1MgZmFpbHVy ZScgYW5kICdwZWVyIG5vdCBhdXRoZW50aWNhdGVkJyBpdCdzIHVzdWFsbHkgYmVlbiBkdWUgdG8N Cjxicj4NCiZndDsmZ3Q7IEtlcmJlcm9zICh0aG91Z2ggYWRtaXR0ZWRseSB0aGVzZSBhcmUganVz dCBnZW5lcmljIGVycm9ycykuIFNvIEkgdHJpZWQgdGhlIFJlZGhhdCBndWlkZSBmb3IgU1NPIGF0 Ojxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgaHR0cHM6Ly9hY2Nlc3MucmVkaGF0LmNvbS9k b2N1bWVudGF0aW9uL2VuLVVTL1JlZF9IYXRfRW50ZXJwcmlzZV9WaXJ0dWFsaXphdGlvbi8zLjYv aHRtbC9BZG1pbmlzdHJhdGlvbl9HdWlkZS9Db25maWd1cmluZ19MREFQX2FuZF9LZXJiZXJvc19m b3JfU2luZ2xlX1NpZ24tb24uaHRtbDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgd2hpY2gg dXNlcyBLZXJiZXJvcyAoaW4gb3ZpcnQtc3NvLmNvbmYpIEkgaGFkIHRvIHJlbW92ZSB0aGUgc3lt bGluayB0byB0aGUgQXBhY2hlPGJyPg0KJmd0OyZndDsgY29uZmlnIGl0IHNheXMgdG8gY3JlYXRl LCBhcyBpdCByZXN1bHRzIGluIGludGVybmFsIHNlcnZlciBlcnJvcnMgaW4gQXBhY2hlLiBJdCB1 c2VzIGFuIFNQTiBmb3I8YnI+DQomZ3Q7Jmd0OyBBcGFjaGUgaW4gdGhlIGtleXRhYi48YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE5vdyB0aGF0IHlvdSd2ZSBjb25maXJtZWQgdGhhdCBpdCBj YW4gYWN0dWFsbHkgd29yayB3aXRob3V0IGFueSBuZWVkIGZvciB0aGUgS2VyYmVyb3Mgc3R1ZmYs DQo8YnI+DQomZ3Q7Jmd0OyBJIHdpbGwgc3RhcnQgYWZyZXNoIGZyb20gYSBjbGVhbiBzZXR1cCBh bmQgYXBwbHkgd2hhdCBJJ3ZlIGxlYXJudCBkdXJpbmcgdGhpcyBwcm9jZXNzLjxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDsgSSdsbCB0cnkgaXQgb3V0IGFuZCBsZXQgeW91IGtub3cgZWl0aGVy IHdheS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE1hbnkgdGhhbmtzIGZvciBhbGwgdGhl IGhlbHAhPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBLaW5kIHJlZ2FyZHMsPGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyBDYW08YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFllcywgeW91IHJlYWxseSBkbyBub3QgbmVl ZCBhbnl0aGluZyBrZXJiZXJvcyByZWxhdGVkIHRvIHNlY3VyZWx5IGJpbmQ8YnI+DQomZ3Q7Jmd0 OyZndDsgdG8gQUQgdmlhIExEQVAgc2ltcGxlIGJpbmQgb3ZlciBUTFMvU1NMLiBUaGlzIGlzIHJl YWxseSBzdHJhbmdlIHRvIG1lPGJyPg0KJmd0OyZndDsmZ3Q7IHdoYXQgZXJyb3JzIHlvdSBhcmUg Z2V0dGluZywgYnV0IHlvdSBwcm9iYWJseSBjb25maWd1cmVkIGFwYWNoZSAob3I8YnI+DQomZ3Q7 Jmd0OyZndDsgc29tZXRoaW5nIGVsc2U/KSB0byByZXF1aXJlIGtleXRhYiwgYnV0IHlvdSBkb24n dCBoYXZlIHRvLCBhbmQgeW91IGNhbjxicj4NCiZndDsmZ3Q7Jmd0OyByZW1vdmUgdGhhdCBjb25m aWd1cmF0aW9uLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyBDYW08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhhbmtzLDxicj4NCiZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBDYW08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFVzZXJzIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBVc2Vyc0BvdmlydC5vcmcg Jmx0O21haWx0bzpVc2Vyc0BvdmlydC5vcmcmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O21haWx0bzpVc2Vyc0BvdmlydC5vcmcgJmx0O21h aWx0bzpVc2Vyc0BvdmlydC5vcmcmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBodHRwOi8v bGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnM8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7aHR0cDovL2xpc3RzLm92aXJ0Lm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzJmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7aHR0 cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2h0dHA6Ly9saXN0cy5vdmly dC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2VycyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7PGJyPg0KPC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_ae004950fd40475d99b4ac034352c4b2exch24sluse_--

1 0

Could not associate brick
by Davide Ferrari 14 Oct '16

14 Oct '16

Hello I'm seeing several ot these warnings: 2016-10-14 10:49:23,721 WARN [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListReturnForXmlRpc] (DefaultQuartzScheduler7) [] Could not associate brick 'vm04.storage.billy:/gluster/ssd/data/brick' of volume '23f8f1ae-a3ac-47bf-8223-5b5f7c29e508' with correct network as no gluster network found in cluster '00000002-0002-0002-0002-000000000345' I was reading this May thread http://lists.ovirt.org/pipermail/users/2016-May/040069.html but there is no final answer about how to solve this warning. As the other poster, I created the gluster network before installing ovirt (it's an hosted-engine installation) and I used DNS names to point to the bricks. DNS resolution is working correctly (every host has everthing in /etc/hosts). I also created a non-VM network and assigned it to every host's bond1 (the gluster network) How can I fix this? TIA -- Davide Ferrari Senior Systems Engineer

2 2

Problem with backing-file, how to fix the backing-chain ?
by Claudio Soprano 14 Oct '16

14 Oct '16

Hi all, We run an ovirt environment before with engine v3.6.5 (if remember good) and now with v4.0.4 (we upgraded because we read the bug with backing-file was resolved with v4). We upgraded some of the hosts machines (but not all still) at v4.0.4 too to see if this would fix the problem, but nothing. The problem is that we have several VMs with snapshots, we do daily, weekly and monthly snapshots, keep some of them (usually the fresh ones) and remove the olds (that in the case they are weekly snapshots, they are in the middle of a series of snapshots), this in the time has produced the famous Backing file too long bug. So we upgraded the engine from 3.6.5 to 4.0.4 (latest available). We discovered this bug, when we tried to upgrade an host to v4.0.4, doing so a VM in the host didn't migrate, so we shutdown it and tried to run on another host, but never succeded for the bug. We don't know if we have more VMs in this situation because we upgraded only 2 hosts on 10. Investigating the problem we discovered that the backing file indicated in each of LVM snapshots report a path very long with /dev/storage-domain-id/../image-group-id/ with ../image-group-id/ repeated a lot of times and at the end /parentid. So to understand which was the right path that it would contain, we cloned a VM in the v4.0.4 and then we did 4 snapshots, now the backing file path is /dev/storage-domain-id/parentid Is there a way to modify the path in the backing-file or a way to recover the VM from this state ? Where do reside the informations about the backing-file path ? I attach here all the commands we run On the ovirt manager (host with the engine only) we run ovirt-shell [oVirt shell (connected)]# list disks --parent-vm-name vm1 id : 2df25a13-6958-40a8-832f-9a26ce65de0f name : vm1_Disk2 id : 8cda0aa6-9e25-4b50-ba00-b877232a1983 name : vm1_Disk1 [oVirt shell (connected)]# show disk 8cda0aa6-9e25-4b50-ba00-b877232a1983 id : 8cda0aa6-9e25-4b50-ba00-b877232a1983 name : vm1_Disk1 actual_size : 1073741824 alias : vm1_Disk1 disk_profile-id : 1731f79a-5034-4270-9a87-94d93025deac format : cow image_id : 7b354e2a-2099-4f2a-80b7-fba7d1fd13ee propagate_errors : False provisioned_size : 17179869184 shareable : False size : 17179869184 sparse : True status-state : ok storage_domains-storage_domain-id: 384f9059-ef2f-4d43-a54f-de71c5d589c8 storage_type : image wipe_after_delete : False [root@ovc1mgr ~]# su - postgres Last login: Fri Oct 14 01:02:14 CEST 2016 -bash-4.2$ psql -d engine -U postgres psql (9.2.15) Type "help" for help. engine=#\x on engine=# select * from images where image_group_id = '8cda0aa6-9e25-4b50-ba00-b877232a1983' order by creation_date; -[ RECORD 1 ]---------+------------------------------------- image_guid | 60ba7acf-58cb-475b-b9ee-15b1be99fee6 creation_date | 2016-03-29 15:12:34+02 size | 17179869184 it_guid | 00000000-0000-0000-0000-000000000000 parentid | 00000000-0000-0000-0000-000000000000 imagestatus | 4 lastmodified | 2016-04-21 11:25:59.972+02 vm_snapshot_id | 27c187cd-989f-4f7a-ac05-49c4410de6c2 volume_type | 1 volume_format | 5 image_group_id | 8cda0aa6-9e25-4b50-ba00-b877232a1983 _create_date | 2016-03-29 15:12:31.994065+02 _update_date | 2016-09-04 01:10:08.773649+02 active | f volume_classification | 1 -[ RECORD 2 ]---------+------------------------------------- image_guid | 68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e creation_date | 2016-07-03 01:01:30+02 size | 17179869184 it_guid | 00000000-0000-0000-0000-000000000000 parentid | 60ba7acf-58cb-475b-b9ee-15b1be99fee6 imagestatus | 1 lastmodified | 2016-07-04 01:03:33.732+02 vm_snapshot_id | 175c2071-a06b-4b0e-a069-5cc4bb236a34 volume_type | 2 volume_format | 4 image_group_id | 8cda0aa6-9e25-4b50-ba00-b877232a1983 _create_date | 2016-07-03 01:01:15.069585+02 _update_date | 2016-09-11 02:06:04.420965+02 active | f volume_classification | 1 -[ RECORD 3 ]---------+------------------------------------- image_guid | 37ca6494-e990-44e5-8597-28845a0a19b5 creation_date | 2016-08-07 01:06:15+02 size | 17179869184 it_guid | 00000000-0000-0000-0000-000000000000 parentid | 68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e imagestatus | 1 lastmodified | 2016-08-08 01:00:03.778+02 vm_snapshot_id | 4c0e5ac0-2ef3-4996-b3e9-7fd566d97b1a volume_type | 2 volume_format | 4 image_group_id | 8cda0aa6-9e25-4b50-ba00-b877232a1983 _create_date | 2016-08-07 01:06:01.777156+02 _update_date | 2016-09-25 01:55:54.090026+02 active | f volume_classification | 1 I removed other 10 snapshot infos from the list to easily read all On a host running v4.0.4 we run root@ovc2n06 ~]# lvchange -aey -pr 384f9059-ef2f-4d43-a54f-de71c5d589c8/60ba7acf-58cb-475b-b9ee-15b1be99fee6 Logical volume "60ba7acf-58cb-475b-b9ee-15b1be99fee6" changed. This is the base image infact it doesn't contain a backing-file [root@ovc2n06 ~]# qemu-img info --backing-chain /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/60ba7acf-58cb-475b-b9ee-15b1be99fee6 image: /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/60ba7acf-58cb-475b-b9ee-15b1be99fee6 file format: raw virtual size: 16G (17179869184 bytes) disk size: 0 [root@ovc2n06 ~]# lvchange -aey -pr 384f9059-ef2f-4d43-a54f-de71c5d589c8/68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e Logical volume "68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e" changed. [root@ovc2n06 ~]# qemu-img info --backing-chain /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e qemu-img: Could not open '/dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/60ba7acf-58cb-475b-b9ee-15b1be99fee6': Could not open '/dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/60ba7acf-58cb-475b-b9ee-15b1be99fee6': No such file or directory To fix this problem we made a link [root@ovc2n06 ~]# lvchange -aey -pr 384f9059-ef2f-4d43-a54f-de71c5d589c8/68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e Logical volume "68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e" changed. [root@ovc2n06 ~]# qemu-img info --backing-chain /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e qemu-img: Could not open '/dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/60ba7acf-58cb-475b-b9ee-15b1be99fee6': Could not open '/dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/60ba7acf-58cb-475b-b9ee-15b1be99fee6': No such file or directory [root@ovc2n06 ~]# ln -s /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8 /dev/8cda0aa6-9e25-4b50-ba00-b877232a1983 [root@ovc2n06 ~]# qemu-img info --backing-chain /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e image: /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/68d764ec-bc2e-4e1d-b8f2-b44afd9fcb2e file format: qcow2 virtual size: 16G (17179869184 bytes) disk size: 0 cluster_size: 65536 backing file: ../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/60ba7acf-58cb-475b-b9ee-15b1be99fee6 (actual path: /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/60ba7acf-58cb-475b-b9ee-15b1be99fee6) backing file format: raw Format specific information: compat: 0.10 refcount bits: 16 image: /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/../8cda0aa6-9e25-4b50-ba00-b877232a1983/60ba7acf-58cb-475b-b9ee-15b1be99fee6 file format: raw virtual size: 16G (17179869184 bytes) disk size: 0 We moved to the next snapshot [root@ovc2n06 ~]# lvchange -aey -pr 384f9059-ef2f-4d43-a54f-de71c5d589c8/37ca6494-e990-44e5-8597-28845a0a19b5 Logical volume "37ca6494-e990-44e5-8597-28845a0a19b5" changed. And now the error from the bug qemu-img info --backing-chain /dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/37ca6494-e990-44e5-8597-28845a0a19b5 qemu-img: Could not open '/dev/384f9059-ef2f-4d43-a54f-de71c5d589c8/37ca6494-e990-44e5-8597-28845a0a19b5': Backing file name too long Any snapshot starting from this snapshot is not usable, the VM was running ok up to we did shutdown it, it never starts again. How you can see the path of the backing-file is wrong and too long already in the previous snapshots, is there a way to fix it or to edit it manually ? Obviously we tried to clone, export, create a qcow2 image, from all the snapshot later 07-august but the operation didn't complete, we can recover only from the snapshot of 7-august that is missing 2 months of new data. Please if you have a workaround or a solution, can you write the commands we need to run with examples, we searched a lot about backing-file but only the manual of the qemu-img command was found with no examples on how to recover or change it. Thanks again Claudio Soprano -- / | / _____/ / | / _____/ | / / / | / / / / | / / / | / / / | / ___/ _____/ / / | / ___/ / | / / / | / / / / | / / / | / ______/ _/ __/ _/ _/ _/ __/ _/ _/ __/ Claudio Soprano phone: (+39)-06-9403.2349/2355 Computing Service fax: (+39)-06-9403.2649 LNF-INFN e-mail: Claudio.Soprano(a)lnf.infn.it Via Enrico Fermi, 40 www: http://www.lnf.infn.it/ I-00044 Frascati, Italy

1 0

Replication between storage domains
by Anantha Raghava 13 Oct '16

13 Oct '16

This is a multi-part message in MIME format. --------------8A5BBB261C1AC062725312E9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello... I am trying to setup a DC & DR with oVirt with two sets of rack servers and two Storage Boxes. In DC, I have FC storage and in DR I have iSCSI storage. Now the question is can I replicate the VM disks and data between these dissimilar storage domains at say 15 min interval? -- Thanks & Regards, Anantha Raghava eXza Technology Consulting & Services --------------8A5BBB261C1AC062725312E9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hello... I am trying to setup a DC & DR with oVirt with two sets of rack servers and two Storage Boxes. In DC, I have FC storage and in DR I have iSCSI storage. Now the question is can I replicate the VM disks and data between these dissimilar storage domains at say 15 min interval? <div class="moz-signature">-- Thanks & Regards, <address style="line-height: 100%">Anantha Raghava</address> <address style="line-height: 100%">eXza Technology Consulting & Services</address> </div> </body> </html> --------------8A5BBB261C1AC062725312E9--

1 0

unable to get hosted-engine to start
by Francois Brochu 13 Oct '16

13 Oct '16

Thanks in advance for your enlightenment - somehow i may have missed a step when I try to backup - and that's when it stopped working the current situation is ALL my VM are up and running EXCEPT hostedengine - oVirt is running on a single node - ovirt-release40-4.0.4-1.noarch - Centos 7.2 hosted-engine --vm-start - did not generate error message at the console - log were complaining of lock and out of space (but now it's gone) - got rid off VM DOWN - got rid of sanlock without a process ID vdsClient does not show HostedEngine as UP (use to show DOWN - but I used poweroff) root@vmhost2 ~]# vdsClient -s 0 list table 01d78c9b-01e9-4dc3-b047-c809f82ae327 141203 GitRepo Up 5b4be6a8-2d94-440b-a221-7396f400ebf7 83717 jetbrains Up 393e28ed-6d11-4651-b367-dd0718ee40c7 126065 turing2 Up 5481665c-9a93-49c6-b7e7-b81495d00a9f 193259 vmcentosdebut Up 439c18db-9f5d-4983-9cd4-38a5ec9f57a6 79098 ecemail Up 844cfa3c-dcff-41a7-b96a-c680a83e4901 146694 vmwinchoco Up dd15556f-a290-4cc8-87d1-d311d1298caf 35974 newWds1 Up 9596a5cf-73ae-4c32-9f35-afbc4dd3cb39 5702 ipmi5 Up [root@vmhost2 ~]# sanlock client status (used to show "s hosted-engine:1:/var/run/vdsm/storage/fd533c44-09f0..." - but I used --reinitialize-lockspace [--force] ) daemon d29562f4-46e1-4838-ad70-666cbcaf1ce3.vmhost2.ec p -1 helper p -1 listener p -1 status p 141203 GitRepo p 126065 turing2 p 146694 vmwinchoco p 193259 vmcentosdebut p 5702 ipmi5 p 79098 ecemail p 35974 newWds1 p 83717 jetbrains AND when I look inside at my backup db is empty [root@vmhost2 ~]# tar -tvf /backup/oVirt.20161012/ovirtBackup drwxr-xr-x root/root 0 2016-10-11 14:52 ./ drwxr-xr-x root/root 0 2016-10-11 14:52 ./db/ -rw-r--r-- root/root 3160 2016-10-11 14:52 ./files -rw-r--r-- root/root 8 2016-10-11 14:52 ./version -rw-r--r-- root/root 8 2016-10-11 14:52 ./os_version -rw-r--r-- root/root 150 2016-10-11 14:52 ./config -rw-r--r-- root/root 168 2016-10-11 14:52 ./md5sum I also try hosted-engine --vm-start --vm-conf=/etc/ovirt-hosted-engine/hosted-engine.conf all I get is a console message "Unexpected exception" cannot find anything else What can I do to get the hosted-engine started? - and not loose any of my currently running VM -- *Francois Brochu* System Administrator/ IT Team Leader Electrical & Computer Engineering University of Alberta francois.brochu(a)ualberta.ca Tel: (780) 492-2010

1 0

VM pauses/hangs after migration
by Davide Ferrari 13 Oct '16

13 Oct '16

Hello trying to migrate a VM from one host to another, a big VM with 96GB of RAM, I found that when the migration completes, the VM goes to a paused satte and cannot be resumed. The libvirt/qemu log it gives is this: 2016-09-28T12:18:15.679176Z qemu-kvm: error while loading state section id 2(ram) 2016-09-28T12:18:15.680010Z qemu-kvm: load of migration failed: Input/output error 2016-09-28 12:18:15.872+0000: shutting down 2016-09-28 12:22:21.467+0000: starting up libvirt version: 1.2.17, package: 13.el7_2.5 (CentOS BuildSystem <http://bugs.centos.org>, 2016-06-23-14:23:27, worker1.bsys.centos.org) qemu version: 2.3.0 (qemu-kvm-ev-2.3.0-31.el7.16.1) LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name front04.billydomain.com -S -machine pc-i440fx-rhel7.2.0,accel=kvm,usb=off -cpu Haswell-noTSX -m size=100663296k,slots=16,maxmem=4294967296k -realtime mlock=off -smp 32,sockets=16,cores=1,threads=2 -numa node,nodeid=0,cpus=0-31,mem=98304 -uuid 4511d1c0-6607-418f-ae75-34f605b2ad68 -smbios type=1,manufacturer=oVirt,product=oVirt Node,version=7-2.1511.el7.centos.2.10,serial=4C4C4544-004A-3310-8054-B2C04F474432,uuid=4511d1c0-6607-418f-ae75-34f605b2ad68 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/ domain-front04.billydomain.com/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2016-09-28T14:22:21,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x7 -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x4 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/rhev/data-center/00000001-0001-0001-0001-0000000003e3/ba2bd397-9222-424d-aecc-eb652c0169d9/images/b5b49d5c-2378-4639-9469-362e37ae7473/24fd0d3c-309b-458d-9818-4321023afacf,if=none,id=drive-virtio-disk0,format=qcow2,serial=b5b49d5c-2378-4639-9469-362e37ae7473,cache=none,werror=stop,rerror=stop,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/rhev/data-center/00000001-0001-0001-0001-0000000003e3/ba2bd397-9222-424d-aecc-eb652c0169d9/images/f02ac1ce-52cd-4b81-8b29-f8006d0469e0/ff4e49c6-3084-4234-80a1-18a67615c527,if=none,id=drive-virtio-disk1,format=raw,serial=f02ac1ce-52cd-4b81-8b29-f8006d0469e0,cache=none,werror=stop,rerror=stop,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x8,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:16:01:56,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/4511d1c0-6607-418f-ae75-34f605b2ad68.com.redhat.rhevm.vdsm,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/channels/4511d1c0-6607-418f-ae75-34f605b2ad68.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel2,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=com.redhat.spice.0 -vnc 192.168.10.225:1,password -k es -spice tls-port=5902,addr=192.168.10.225,x509-dir=/etc/pki/vdsm/libvirt-spice,tls-channel=default,tls-channel=main,tls-channel=display,tls-channel=inputs,tls-channel=cursor,tls-channel=playback,tls-channel=record,tls-channel=smartcard,tls-channel=usbredir,seamless-migration=on -k es -device qxl-vga,id=video0,ram_size=67108864,vram_size=8388608,vgamem_mb=16,bus=pci.0,addr=0x2 -incoming tcp:0.0.0.0:49156 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -msg timestamp=on Domain id=5 is tainted: hook-script red_dispatcher_loadvm_commands: KVM: entry failed, hardware error 0x8 RAX=00000000ffffffed RBX=ffff8817ba00c000 RCX=0100000000000000 RDX=0000000000000000 RSI=0000000000000000 RDI=0000000000000046 RBP=ffff8817ba00fe98 RSP=ffff8817ba00fe98 R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000 R12=0000000000000006 R13=ffff8817ba00c000 R14=ffff8817ba00c000 R15=0000000000000000 RIP=ffffffff81058e96 RFL=00010286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 0000000000000000 ffffffff 00000000 CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] DS =0000 0000000000000000 ffffffff 00000000 FS =0000 0000000000000000 ffffffff 00000000 GS =0000 ffff8817def80000 ffffffff 00000000 LDT=0000 0000000000000000 ffffffff 00000000 TR =0040 ffff8817def93b80 00002087 00008b00 DPL=0 TSS64-busy GDT= ffff8817def89000 0000007f IDT= ffffffffff529000 00000fff CR0=80050033 CR2=00000000ffffffff CR3=00000017b725b000 CR4=001406e0 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000d01 Code=89 e5 fb 5d c3 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 fb f4 <5d> c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 f4 5d c3 66 0f 1f 84 00 00 00 00 00 55 49 89 ca KVM: entry failed, hardware error 0x8 RAX=00000000ffffffed RBX=ffff8817ba008000 RCX=0100000000000000 RDX=0000000000000000 RSI=0000000000000000 RDI=0000000000000046 RBP=ffff8817ba00be98 RSP=ffff8817ba00be98 R8 =0000000000000000 R9 =0000000000000000 R10=0000000000000000 R11=0000000000000000 R12=0000000000000005 R13=ffff8817ba008000 R14=ffff8817ba008000 R15=0000000000000000 RIP=ffffffff81058e96 RFL=00010286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 0000000000000000 ffffffff 00000000 CS =0010 0000000000000000 ffffffff 00a09b00 DPL=0 CS64 [-RA] SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA] DS =0000 0000000000000000 ffffffff 00000000 FS =0000 0000000000000000 ffffffff 00000000 GS =0000 ffff8817def40000 ffffffff 00000000 LDT=0000 0000000000000000 ffffffff 00000000 TR =0040 ffff8817def53b80 00002087 00008b00 DPL=0 TSS64-busy GDT= ffff8817def49000 0000007f IDT= ffffffffff529000 00000fff CR0=80050033 CR2=00000000ffffffff CR3=00000017b3c9a000 CR4=001406e0 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000d01 Code=89 e5 fb 5d c3 66 0f 1f 84 00 00 00 00 00 55 48 89 e5 fb f4 <5d> c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 f4 5d c3 66 0f 1f 84 00 00 00 00 00 55 49 89 ca KVM: entry failed, hardware error 0x80000021 If you're running a guest on an Intel machine without unrestricted mode support, the failure can be most likely due to the guest entering an invalid state for Intel VT. For example, the guest maybe running in big real mode which is not supported on less recent Intel processors. EAX=ffffffed EBX=ba020000 ECX=00000000 EDX=00000000 ESI=00000000 EDI=00000046 EBP=ba023e98 ESP=ba023e98 EIP=81058e96 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 00000000 0000ffff 00009300 DPL=0 DS [-WA] CS =f000 ffff0000 0000ffff 00009b00 DPL=0 CS16 [-RA] SS =0000 00000000 0000ffff 00009300 DPL=0 DS [-WA] DS =0000 00000000 0000ffff 00009300 DPL=0 DS [-WA] FS =0000 00000000 0000ffff 00009300 DPL=0 DS [-WA] GS =0000 00000000 0000ffff 00009300 DPL=0 DS [-WA] LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS64-busy GDT= 0000000000000000 0000ffff IDT= 0000000000000000 0000ffff CR0=80050033 CR2=00007fd826ac20a0 CR3=000000003516c000 CR4=00140060 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000d01 Code=?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? <??> ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? Searching for errors like this I found some bug report about kernel issues but I don't think it's the case, other VMs spawned from the same image migrate without any issue. I have toi say that the original host running the VM has some RAM problem (ECC multibit fault in one DIMM). Maybe that's the problem? How can I properly read this error log? Thanks -- Davide Ferrari Senior Systems Engineer

3 8

Multi cluster question with regards to storage
by David Gossage 13 Oct '16

13 Oct '16

I've not yet found a clean concise answer and so I wanted to ask before I start trying to play with things in my test setup and waste a bunch of time maybe. If I have 2 clusters in one data center each running different cpu types (amd/intel) can they both access the same shared storage domain(gluster in my case)? I'm not interested in live migration between the clusters really, though stopping and starting on another would be nice. I've tried looking at various threads and list emails and I've found some mentions of it, but usually as an aside while discussing other matters so I could never quite say for certain it was working or not. *David Gossage* *Carousel Checks Inc. | System Administrator* *Office* 708.613.2284

2 2

unsupported configuration: Unable to find security driver for model selinux
by Николаев Алексей 13 Oct '16

13 Oct '16

4 7

vdsm ssl errors
by C. Handel 13 Oct '16

13 Oct '16

i have an ovirt 4.0.1 installation on two nodes. Hosted Engine. San storage backend. For some reason the vdsmd on the nodes is logging an error every few seconds: vdsm vds.dispatcher ERROR SSL error during reading data: unexpected eof Running tcpdump it is a connect from the node to itself. I can't figure out what is wrong. Can someone give me a hint? Greetings Christoph

9 42

[ANN] oVirt 4.0.5 Second Release Candidate is now available
by Sandro Bonazzola 13 Oct '16

13 Oct '16

The oVirt Project is pleased to announce the availability of oVirt 4.0.5 second release candidate for testing, as of October 13th, 2016. This release is available now for: * Fedora 23 (tech preview) * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later * Fedora 23 (tech preview) * oVirt Next Generation Node 4.0 This is pre-release software. Please take a look at our community page[1] to know how to ask questions and interact with developers and users. All issues or bugs should be reported via oVirt Bugzilla[2]. This pre-release should not to be used in production. This update is the second release candidate of the fifth in a series of stabilization updates to the 4.0 series. 4.0.5 brings 9 enhancements and 49 bugfixes, including 24 high or urgent severity fixes, on top of oVirt 4.0 series See the release notes [3] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: * A new oVirt Live ISO is available. [4] * A new oVirt Next Generation Node is available [4] * A new oVirt Engine Appliance is available for Red Hat Enterprise Linux and CentOS Linux (or similar) * Mirrors[5] might need up to one day to synchronize. Additional Resources: * Read more about the oVirt 4.0.5 release highlights: http://www.ovirt.org/release/4.0.5/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] https://www.ovirt.org/community/ [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt [3] http://www.ovirt.org/release/4.0.5/ [4] http://resources.ovirt.org/pub/ovirt-4.0-pre/iso/ [5] http://www.ovirt.org/Repository_mirrors#Current_mirrors -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Failed to read hardware information
by David Pinkerton 13 Oct '16

13 Oct '16

I've spent the weekend trying to get to the bottom of this issue. Adding a Host fails: >From RHVM VDSM rhv1 command failed: Connection reset by peer Could not get hardware information for host rhv1 VDSM rhv1 command failed: Failed to read hardware information Host rhv1 installed Network changes were saved on host rhv1 Installing Host rhv1. Stage: Termination. Installing Host rhv1. Retrieving installation logs to: '/var/log/ovirt-engine/host-deploy/ovirt-host-deploy-20161010115606-192.168.21.71-24d39274.log'. Installing Host rhv1. Stage: Pre-termination. Installing Host rhv1. Starting ovirt-vmconsole-host-sshd. Installing Host rhv1. Starting vdsm. Installing Host rhv1. Stopping libvirtd. Installing Host rhv1. Stage: Closing up. Installing Host rhv1. Setting kernel arguments. Installing Host rhv1. Stage: Transaction commit. Installing Host rhv1. Enrolling serial console certificate. Installing Host rhv1. Enrolling certificate. Installing Host rhv1. Stage: Misc configuration. This was in the /var/log/vdsm/vdsm.log on the host trying to be added: jsonrpc.Executor/2::ERROR::2016-10-10 11:57:10,276::API::1340::vds::(getHardwareInfo) failed to retrieve hardware info Traceback (most recent call last): File "/usr/share/vdsm/API.py", line 1337, in getHardwareInfo hw = supervdsm.getProxy().getHardwareInfo() File "/usr/lib/python2.7/site-packages/vdsm/supervdsm.py", line 53, in __call__ return callMethod() File "/usr/lib/python2.7/site-packages/vdsm/supervdsm.py", line 51, in <lambda> **kwargs) File "<string>", line 2, in getHardwareInfo File "/usr/lib64/python2.7/multiprocessing/managers.py", line 759, in _callmethod kind, result = conn.recv() EOFError and then VDSM fails to start. Looking at the source code... def getHardwareInfoStructure(): dmiInfo = getAllDmidecodeInfo() sysStruct = {} for k1, k2 in (('system', 'Manufacturer'), ('system', 'Product Name'), ('system', 'Version'), ('system', 'Serial Number'), ('system', 'UUID'), ('system', 'Family')): val = dmiInfo.get(k1, {}).get(k2, None) if val not in [None, 'Not Specified']: sysStruct[(k1 + k2).replace(' ', '')] = val return sysStruct Running dmidecode from command line I get.. System Information Manufacturer: Supermicro Product Name: H8DM8-2 Version: 1234567890 Serial Number: 1234567890 UUID: 00020003-0004-0005-0006-000700080009 Wake-up Type: Power Switch SKU Number: To Be Filled By O.E.M. Family: To Be Filled By O.E.M. Q: Is the string in Family the source of my problems?? Q: Any work arounds?? -- David Pinkerton Consultant Red Hat Asia Pacific Pty. Ltd. Level 11, Canberra House 40 Marcus Clarke Street Canberra 2600 ACT Mobile: +61-488-904-232 Email: david.pinkerton(a)redhat.com Web: http://apac.redhat.com/ <http://apac.redhat.com/>

5 11

Cannot start VM because of hanging migration task
by Matt . 13 Oct '16

13 Oct '16

HI Guys, I did a live migration of a VM it's disk on 4.0.3 where i saw some failures but at the end it finished well. It looked like the migration just tried again after those failures as it should. I have a hanging task tho and when I want to start my VM I get the following: Cannot run VM. Related operation is currently in progress. Please try again later. Can I remove some lock in the database or is there a different way ? Thanks! Matt

1 0

Dashboard Never Loads
by Clint Boggio 12 Oct '16

12 Oct '16

Greetings ovirt community; I have an oVirt environment with a dedicated engine, and 4 compute nodes all running CentOS 7, and oVirt 4.0.1.1. On the management interface, the "Dashboard" tab displays "Loading" and the spinning applet is working hard, but nothing ever materializes on the screen. I aplogize if this has apready been addressed, and i searched deeply before I decided to ask the forum. Is there a document on troubleshooting this problem ?

3 3

VM incremental backup
by vasily.lamykin＠MegaFon.ru 12 Oct '16

12 Oct '16

--_004_85ae1b983ef94e13ad645e5fb7f6b048vlgums05Megafonru_ Content-Type: multipart/alternative; boundary="_000_85ae1b983ef94e13ad645e5fb7f6b048vlgums05Megafonru_" --_000_85ae1b983ef94e13ad645e5fb7f6b048vlgums05Megafonru_ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hello! I would like to understand the existence of the possibility of incremental = VM backups. And if it is, the means by which it is achieved. While I was only able to achieve a complete backup of the virtual machine (= but it is a very large amount of information and time) by cloning a snapsho= t of the VM and export to data domain. =EC=C1=CD=D9=CB=C9=CE =F7=C1=D3=C9=CC=C9=CA =F3=D4=C1=D2=DB=C9=CA =C9=CE=D6=C5=CE=C5=D2 =D0=CF =DC=CB=D3=D0=CC=D5=C1=D4= =C1=C3=C9=C9 =D3=C5=D2=D7=C9=D3=CE=D9=C8 =D0=CC=C1=D4=C6=CF=D2=CD =F3=D4=CF=CC=C9=DE=CE=D9=CA =C6-=C1=CC =F0=E1=EF "=ED=C5=C7=C1=E6=CF=CE +7 (926) 500-3308 [=ED=C5=C7=C1=E6=CF=CE =CC=CF=C7=CF+=DA=CE=C1=CB =F2=F5=F3 B2C] ________________________________ =E9=CE=C6=CF=D2=CD=C1=C3=C9=D1 =D7 =DC=D4=CF=CD =D3=CF=CF=C2=DD=C5=CE=C9=C9= =D0=D2=C5=C4=CE=C1=DA=CE=C1=DE=C5=CE=C1 =C9=D3=CB=CC=C0=DE=C9=D4=C5=CC=D8= =CE=CF =C4=CC=D1 =CB=CF=CE=CB=D2=C5=D4=CE=D9=C8 =CC=C9=C3, =CB=CF=D4=CF=D2= =D9=CD =CF=CE=C1 =C1=C4=D2=C5=D3=CF=D7=C1=CE=C1. =F7 =D3=CF=CF=C2=DD=C5=CE= =C9=C9 =CD=CF=D6=C5=D4 =D3=CF=C4=C5=D2=D6=C1=D4=D8=D3=D1 =CB=CF=CE=C6=C9=C4= =C5=CE=C3=C9=C1=CC=D8=CE=C1=D1 =C9=CE=C6=CF=D2=CD=C1=C3=C9=D1, =CB=CF=D4=CF= =D2=C1=D1 =CE=C5 =CD=CF=D6=C5=D4 =C2=D9=D4=D8 =D2=C1=D3=CB=D2=D9=D4=C1 =C9= =CC=C9 =C9=D3=D0=CF=CC=D8=DA=CF=D7=C1=CE=C1 =CB=C5=CD-=CC=C9=C2=CF, =CB=D2= =CF=CD=C5 =C1=C4=D2=C5=D3=C1=D4=CF=D7. =E5=D3=CC=C9 =D7=D9 =CE=C5 =C1=C4=D2= =C5=D3=C1=D4 =DC=D4=CF=C7=CF =D3=CF=CF=C2=DD=C5=CE=C9=D1, =D4=CF =C9=D3=D0= =CF=CC=D8=DA=CF=D7=C1=CE=C9=C5, =D0=C5=D2=C5=C1=C4=D2=C5=D3=C1=C3=C9=D1, = =CB=CF=D0=C9=D2=CF=D7=C1=CE=C9=C5 =C9=CC=C9 =D2=C1=D3=D0=D2=CF=D3=D4=D2=C1= =CE=C5=CE=C9=C5 =D3=CF=C4=C5=D2=D6=C1=CE=C9=D1 =D3=CF=CF=C2=DD=C5=CE=C9=D1 = =C9=CC=C9 =C5=C7=CF =DE=C1=D3=D4=C9 =CE=C5=DA=C1=CB=CF=CE=CE=CF =C9 =DA=C1= =D0=D2=C5=DD=C5=CE=CF. =E5=D3=CC=C9 =F7=D9 =D0=CF=CC=D5=DE=C9=CC=C9 =DC=D4= =CF =D3=CF=CF=C2=DD=C5=CE=C9=C5 =CF=DB=C9=C2=CF=DE=CE=CF, =D0=CF=D6=C1=CC= =D5=CA=D3=D4=C1, =CE=C5=DA=C1=CD=C5=C4=CC=C9=D4=C5=CC=D8=CE=CF =D3=CF=CF=C2= =DD=C9=D4=C5 =CF=D4=D0=D2=C1=D7=C9=D4=C5=CC=C0 =CF=C2 =DC=D4=CF=CD =C9 =D5= =C4=C1=CC=C9=D4=C5 =D3=CF =D7=D3=C5=CD =D3=CF=C4=C5=D2=D6=C9=CD=D9=CD =D3= =C1=CD=CF =D3=CF=CF=C2=DD=C5=CE=C9=C5 =C9 =CC=C0=C2=D9=C5 =D7=CF=DA=CD=CF= =D6=CE=D9=C5 =C5=C7=CF =CB=CF=D0=C9=C9 =C9 =D0=D2=C9=CC=CF=D6=C5=CE=C9=D1. The information contained in this communication is intended solely for the = use of the individual or entity to whom it is addressed and others authoriz= ed to receive it. It may contain confidential or legally privileged informa= tion. The contents may not be disclosed or used by anyone other than the ad= dressee. If you are not the intended recipient(s), any use, disclosure, cop= ying, distribution or any action taken or omitted to be taken in reliance o= n it is prohibited and may be unlawful. If you have received this communica= tion in error please notify us immediately by responding to this email and = then delete the e-mail and all attachments and any copies thereof. (c)20mf50 --_000_85ae1b983ef94e13ad645e5fb7f6b048vlgums05Megafonru_ Content-Type: text/html; charset="koi8-r" 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=3Dkoi8-r"> <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"RU" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Hello!<o:p></o:p> I would like to understand the = existence of the possibility of incremental VM backups.<o:p></o:p></= p> And if it is, the means by whic= h it is achieved.<o:p></o:p> While I was only able to achiev= e a complete backup of the virtual machine (but it is a very large amount o= f information and time) by cloning a snapshot of the VM and export to data = domain.<o:p></o:p> <o:p> </o:p> =EC=C1=CD=D9=CB=C9=CE =F7=C1=D3=C9=CC=C9=CA<o:p></o:p> =F3=D4=C1=D2=DB=C9=CA =C9=CE=D6=C5=CE=C5=D2 =D0=CF =DC= =CB=D3=D0=CC=D5=C1=D4=C1=C3=C9=C9 =D3=C5=D2=D7=C9=D3=CE=D9=C8 =D0=CC=C1=D4= =C6=CF=D2=CD<o= :p></o:p> =F3=D4=CF=CC=C9=DE=CE=D9=CA =C6-=C1=CC =F0=E1=EF "= =ED=C5=C7=C1=E6=CF=CE<o:p></= o:p> <o:p> </o:p> +7 (926) 500-3308<o:p></o:p></sp= an> <img width= =3D"285" height=3D"54" style=3D"width:2.9687in;height:.5625in" id=3D"=F2=C9= =D3=D5=CE=CF=CB_x0020_1" src=3D"cid:image001.png@01D214CD.17015460" alt=3D"= =ED=C5=C7=C1=E6=CF=CE =CC=CF=C7=CF+=DA=CE=C1=CB =F2=F5=F3 B2C"><o:p></o= :p> <o:p> </o:p> </div> <hr> =E9=CE=C6=CF=D2=CD=C1=C3=C9=D1 =D7 =DC=D4=CF=CD =D3=CF=CF=C2=DD=C5=CE=C9=C9= =D0=D2=C5=C4=CE=C1=DA=CE=C1=DE=C5=CE=C1 =C9=D3=CB=CC=C0=DE=C9=D4=C5=CC=D8= =CE=CF =C4=CC=D1 =CB=CF=CE=CB=D2=C5=D4=CE=D9=C8 =CC=C9=C3, =CB=CF=D4=CF=D2= =D9=CD =CF=CE=C1 =C1=C4=D2=C5=D3=CF=D7=C1=CE=C1. =F7 =D3=CF=CF=C2=DD=C5=CE= =C9=C9 =CD=CF=D6=C5=D4 =D3=CF=C4=C5=D2=D6=C1=D4=D8=D3=D1 =CB=CF=CE=C6=C9=C4= =C5=CE=C3=C9=C1=CC=D8=CE=C1=D1 =C9=CE=C6=CF=D2=CD=C1=C3=C9=D1, =CB=CF=D4=CF= =D2=C1=D1 =CE=C5 =CD=CF=D6=C5=D4 =C2=D9=D4=D8 =D2=C1=D3=CB=D2=D9=D4=C1 =C9= =CC=C9 =C9=D3=D0=CF=CC=D8=DA=CF=D7=C1=CE=C1 =CB=C5=CD-=CC=C9=C2=CF, =CB=D2= =CF=CD=C5 =C1=C4=D2=C5=D3=C1=D4=CF=D7. =E5=D3=CC=C9 =D7=D9 =CE=C5 =C1=C4=D2= =C5=D3=C1=D4 =DC=D4=CF=C7=CF =D3=CF=CF=C2=DD=C5=CE=C9=D1, =D4=CF =C9=D3=D0=CF=CC=D8=DA=CF=D7=C1=CE=C9= =C5, =D0=C5=D2=C5=C1=C4=D2=C5=D3=C1=C3=C9=D1, =CB=CF=D0=C9=D2=CF=D7=C1=CE= =C9=C5 =C9=CC=C9 =D2=C1=D3=D0=D2=CF=D3=D4=D2=C1=CE=C5=CE=C9=C5 =D3=CF=C4=C5= =D2=D6=C1=CE=C9=D1 =D3=CF=CF=C2=DD=C5=CE=C9=D1 =C9=CC=C9 =C5=C7=CF =DE=C1= =D3=D4=C9 =CE=C5=DA=C1=CB=CF=CE=CE=CF =C9 =DA=C1=D0=D2=C5=DD=C5=CE=CF. =E5= =D3=CC=C9 =F7=D9 =D0=CF=CC=D5=DE=C9=CC=C9 =DC=D4=CF =D3=CF=CF=C2=DD=C5=CE= =C9=C5 =CF=DB=C9=C2=CF=DE=CE=CF, =D0=CF=D6=C1=CC=D5=CA=D3=D4=C1, =CE=C5=DA= =C1=CD=C5=C4=CC=C9=D4=C5=CC=D8=CE=CF =D3=CF=CF=C2=DD=C9=D4=C5 =CF=D4=D0=D2= =C1=D7=C9=D4=C5=CC=C0 =CF=C2 =DC=D4=CF=CD =C9 =D5=C4=C1=CC=C9=D4=C5 =D3=CF = =D7=D3=C5=CD =D3=CF=C4=C5=D2=D6=C9=CD=D9=CD =D3=C1=CD=CF =D3=CF=CF=C2=DD=C5=CE=C9=C5 =C9 =CC=C0=C2=D9=C5 =D7=CF=DA=CD= =CF=D6=CE=D9=C5 =C5=C7=CF =CB=CF=D0=C9=C9 =C9 =D0=D2=C9=CC=CF=D6=C5=CE=C9= =D1. The information contained in this communication is intended solely for the = use of the individual or entity to whom it is addressed and others authoriz= ed to receive it. It may contain confidential or legally privileged informa= tion. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended re= cipient(s), any use, disclosure, copying, distribution or any action taken = or omitted to be taken in reliance on it is prohibited and may be unlawful.= If you have received this communication in error please notify us immediately by responding to this email and then= delete the e-mail and all attachments and any copies thereof. (c)20mf50 </body> </html> --_000_85ae1b983ef94e13ad645e5fb7f6b048vlgums05Megafonru_-- --_004_85ae1b983ef94e13ad645e5fb7f6b048vlgums05Megafonru_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=2130; creation-date="Thu, 22 Sep 2016 09:30:28 GMT"; modification-date="Thu, 22 Sep 2016 09:30:28 GMT" Content-ID: <image001.png(a)01D214CD.17015460> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAASkAAAA4CAYAAAChZA4IAAAACXBIWXMAAA9hAAAPYQGoP6dpAAAA GXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAB99JREFUeNrsnd114joUhZUs3q87 GE8FcSoIVDCkAsjbvJlUAKmA8Ja3QAVhKsCpYJgKxrcD3wq4liUTIx/LkiwyMOxvLc0k/PhX2trn SFbYTtBnAABwQnBd4uJU/hDgkgAATkykAhgoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAM1c 4RIAAEheRsP837u8RLLwx+cS9n01yN+byffSvLznZZ2/nh3jMHq4EwCAijBxIZrkZZSXsOXTffn/ OC/z/Lvr/P+nXKxSn4d0jbsCAJACxcXpd16mBgKlEkix+p1vZy7FDiIFAPDknl5Gb4UbEmLTFS52 m3ybEUQKAOAjvNvkZeh5y5EvoYJIAQCBio60h8CHUPWIgxYb/L5KPFwAP9sCAByDtyMKlCpUX11H /3oVUZnLWLL8nW/wMd/w0kGgqG095NtaX0DvVB22tSVlRx7OBUDWU94++5+0Ny5Ur3m5d/nylTzg sdwIxb2VuKgCdchX38OTJyZO/NxDD1vjAsWHcp/RmsAR6iqvoz+ZW5K8Ok9qavndgUtUVTqpWPOZ edGzm5/8RPOJuHBnh99xUfPtgdOohpY2UBdMCPad/O3dyEnqRd615+HDuDf5/h8Mr3ukuQZJ7ZrV t9GvuTpdh0Jdc4T158LUUqAST67rtTAqjiKla+Bh0QjNwr42ZY2UhrVxdB4DeeG6CsSV0vA2ys0Y 56/FsgfINAIxP1Jl4vtfNTZ+ce6xgUBP5efLyXZb4jMb5fenvMxa7uVGez3BKbooLk6mI3m8zt8W nZVIfm867j0sOkPLzsx0dG/k+eTLhuMjNJp7unmzht4ianGHVK+UyND2al9Eo1dtc/V93sMsjc/v ZfQqxdnGQQ4Lmy/EDVwmQwsXtdi7adGx+XDKI9svNImUavP7BmHZhDj5VKuq/kIjH8Ta95pn0FJh 0sA698Y/L0K7dU0khVtTBbWL0Lw6htng/Lmz+OzNEdqsdb1renZvLRtBoChgYqGQieWJZYVym6ET AH7svyxdlHqumSKA5ZT/Z8I9hkSY1IUnwpGG+3MW+4wb8gY/GM89HfKNuJelA0zQZi8OG5EYSse+ qqQVutaZsOh0LTrxJpH6T4YeEyU/Qj88KBp5WLOKeneiwhO7Mw83YeGQwJ0Sx54poVZcEyk61Np2 Onpuq19GVMVKNHZ9qUmwJ8V9q0/a69tWFvBXYOuGxh1de9MxGNe7a21jpw/YxEWlZzMnSkwdUG/c sxTpTOkB2m8WnZS2ZWthwbPWEUCR9H8k3onQZi8INW1wJkLZ0+ZIXkZLRZi4m5gpJx4RFtIl5Ink 6JqJ2xh4vGAx4UoyeW5r5fynjE5ufyZRQ1jdds0SwqFFrHl6yTT//BQt+6Jd1EkcR9vo3kr5PSDc RFzr2U3nVanbFmJnUnz1LNT2FhqxDVsTzn6e/I5qzrQZm/xbgnYKHHisjEQPPnvn1629b71iTysN MiBCwMUZPdIR18Ksargm8jXN50/nvro9TS7CT2YhUgCY4T7Zdrvv1EWZMLt8c6fO0mRlzpXiNqoT sqj5Q67hUMa6Jp3t4/Nh7RjE8L56XFX6yoS0reJ84iJMdMlNCdGfW1auf87Q7oPzZPMndtouUnym uchNhIoDSRidz3Ht9befbCWpfItpOFmdjrFSRIoLzU+Zz3uvuKAvROjcr3znjtFTBZYtrmrI6KQ4 JcqhhUN70o62imPfoN2eHQn7vAeLvTg60xnnq1rDEI4jaPncaSIa7LjDFsb7kRLxEPCW/IyYEb6R Rd1fVHnvjdGTYcWDxof8qrkjOkRUmTfaeHBJvHvazpaoq6nBa9Yhp+kfYniWrinQOJGk4wOmgcUs 6G3HvNfYw03i518O/T9IofEZTvHzo2aurwnBeZNzoepOViTyp0Rom3qaLgHOizWzX71Add+3RfsT neObFKyBfK3snNdMLM+UKSsm/LDdoZmTEoLQNmLX1UVVnUVbcR9Bo2dsLw+eo6NKPewa7x+VEY39 VrqezIM4LWVF2BL3ImV03o9XAr4I/u6giCU5hmQ4By4PUae6dE6rvUEQcyETmRrI9ukhsf1F5bWZ Jn3hzUmVlXrcqK72i+P9qRHAiWOYuiDOn29rVhHyWVGEewkVMb1TcgGpst9UXkcTN/rI9EuztLF0 WswQ/C0smPvKIV9q6YbqfLuPR8VCJb1S1jvrdm8uUmJy5wNxcnynLivurZj/xd9NoGbHJwbnzx9X SRSh4SN5z7UL/9FbrSs3alYTKdfHgISFHkj3NLHsGLCYHtwUHwwbMbcEOo8g/pX1O5ZiNJUThbfs Y1WQeWXycCzr3qPL4fYarH+iOblMNvRA9v4LTW6DC9G74hbY3iqKhuZyoVJN2JJqQr2QcE2JxX6f WD3xGBi6wsT4OM1D8EeZi+Jif6NxVu9M5PHWLedmc11ShIxnzQNzX51zavBaoBiae9c8MhYpA+BS MV8wciAfq9p1SC88uB4m/qQVAJcc9n2MUB+LTgIFkQIAQnVMoeosUBApAEApVHwKTeppi+WfsPMi fhApAIDPuX5C8DxOcenh7gAApFCJuX58Wo2YE8hH8U3m4nEHxkeOF8dY6RWjewCAZj6eqqBWCBHz AbEENQAAAAAAAAAAAAAAAAAAAAAAAAAAAAB0Y7fb9fMS4EoAAE5MmwKuT/yHXfEDAACcnoHa/S/A ANCM57qVhzX7AAAAAElFTkSuQmCC --_004_85ae1b983ef94e13ad645e5fb7f6b048vlgums05Megafonru_--

7 10

Hung Snapshot
by C Williams 12 Oct '16

12 Oct '16

Hello, I am using the oVirtBackup utility and one of the snapshot jobs has hung. I am on 3.6.6.2-1.el7.centos. How can I stop this hung snapshot ? This is filling my engine logs. Thanks

1 2

Outreachy Hopeful
by JonathanPosada 11 Oct '16

11 Oct '16

This is a multi-part message in MIME format. --b1_3b1df74a2a83f7448181eb2877ab80db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgYWxsLAoKTXkgbmFtZSBpcyBKb25hdGhhbiBQb3NhZGEgYW5kIEkgYW0gYSBzZW5pb3IgQ1Mg c3R1ZGVudCBhdCBDb3JuZWxsIFVuaXZlcnNpdHkuIEZvciBtb3JlIGFib3V0IG15IGJhY2tncm91 bmQgc2VlIG15IExpbmtlZGluIGhlcmUgKGh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9qb25h dGhhbi1wb3NhZGEtMTY2YWJhOTYpLgoKSSdtIGludGVyZXN0ZWQgaW4gbGVhcm5pbmcgbW9yZSBh Ym91dCB0aGUgY2xvdWQgYW5kIHRvcGljcyBzdWNoIGFzIGNvbnRhaW5lcnMgYW5kIFZNcyB3aGlj aCBicm91Z2h0IG1lIHRvIG9WaXJ0LiBJbiBwYXJ0aWN1bGFyIEknZCBsaWtlIHRvIHRha2Ugb24g dGhlIFB5dGhvbiB0ZXN0aW5nIHByb2plY3QgZm91bmQgaGVyZSAoaHR0cHM6Ly93d3cub3ZpcnQu b3JnL2NvbW11bml0eS9hY3Rpdml0aWVzL291dHJlYWNoeS8pIHVuZGVyICdTb21lIElkZWFzJy4g V2l0aCB0aGUgZGVhZGxpbmUgdG8gYXBwbHkgZmFzdCBhcHByb2FjaGluZywgSSdkIGxpa2UgdG8g Z2V0IHN0YXJ0ZWQgd2l0aCBteSBmaXJzdCBjb250cmlidXRpb24gdG8gdGhlIHByb2plY3QuIEhv dyBzaG91bGQgSSBnZXQgc3RhcnRlZD8KCgoKSm9uYXRoYW4KU2VudCB3aXRoIFtQcm90b25NYWls XShodHRwczovL3Byb3Rvbm1haWwuY29tKSBTZWN1cmUgRW1haWwu --b1_3b1df74a2a83f7448181eb2877ab80db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5IaSBhbGwsPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+TXkgbmFtZSBpcyBKb25h dGhhbiBQb3NhZGEgYW5kIEkgYW0gYSBzZW5pb3IgQ1Mgc3R1ZGVudCBhdCBDb3JuZWxsIFVuaXZl cnNpdHkuIEZvciBtb3JlIGFib3V0IG15IGJhY2tncm91bmQgc2VlIG15IExpbmtlZGluIGhlcmUg KDxhIGhyZWY9Imh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9qb25hdGhhbi1wb3NhZGEtMTY2 YWJhOTYiPmh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9pbi9qb25hdGhhbi1wb3NhZGEtMTY2YWJh OTY8L2E+KS48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JJ20gaW50ZXJlc3RlZCBpbiBs ZWFybmluZyBtb3JlIGFib3V0IHRoZSBjbG91ZCBhbmQgdG9waWNzIHN1Y2ggYXMgY29udGFpbmVy cyBhbmQgVk1zIHdoaWNoIGJyb3VnaHQgbWUgdG8gb1ZpcnQuIEluIHBhcnRpY3VsYXIgSSdkIGxp a2UgdG8gdGFrZSBvbiB0aGUgUHl0aG9uIHRlc3RpbmcgcHJvamVjdCBmb3VuZCBoZXJlICg8YSBo cmVmPSJodHRwczovL3d3dy5vdmlydC5vcmcvY29tbXVuaXR5L2FjdGl2aXRpZXMvb3V0cmVhY2h5 LyI+aHR0cHM6Ly93d3cub3ZpcnQub3JnL2NvbW11bml0eS9hY3Rpdml0aWVzL291dHJlYWNoeS88 L2E+KSB1bmRlciAnU29tZSBJZGVhcycuIFdpdGggdGhlIGRlYWRsaW5lIHRvIGFwcGx5IGZhc3Qg YXBwcm9hY2hpbmcsIEknZCBsaWtlIHRvIGdldCBzdGFydGVkIHdpdGggbXkgZmlyc3QgY29udHJp YnV0aW9uIHRvIHRoZSBwcm9qZWN0LiBIb3cgc2hvdWxkIEkgZ2V0IHN0YXJ0ZWQ/PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2sgIj48ZGl2 IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay11c2VyICI+PGRpdj5Kb25hdGhhbjxi cj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay1wcm90 b24gIj5TZW50IHdpdGggPGEgaHJlZj0iaHR0cHM6Ly9wcm90b25tYWlsLmNvbSI+UHJvdG9uTWFp bDwvYT4gU2VjdXJlIEVtYWlsLjxicj48L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj4= --b1_3b1df74a2a83f7448181eb2877ab80db--

2 1

ovirt-shell show vm doesn't show all vm properties
by Nathanaël Blanchet 11 Oct '16

11 Oct '16

Hi all, I'd like to find any vms with some defined properties like (console-enabled or serial_number-policy for example) with ovirt-shell -E "show vm name", but I can't find all information that I can get with edit vm popupin the UI. I belevied these kind of properties were unvailable because the flag was by default to false, but after updating the flag to true, it is still not visible. Does it exist an extended way to get those feature with ovirt-shell? Thank you. -- Nathanaël Blanchet Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet(a)abes.fr

2 5

Replace Engine Self-Signed Certificate
by Alan Griffiths 11 Oct '16

11 Oct '16

Hi, I'm trying to replace the self-signed certificate in the engine. I updated the four files listed here http://www.ovirt.org/develop/release-management/features/infra/pki/ But on restarting Apache and logging in I get the following error, "sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target" What am I missing? Thanks, Alan

2 2

HA not working when killing one node
by Felip Moll 11 Oct '16

11 Oct '16

Hello, I have latest version of ovirt 4 installed on a Centos 7, 2 hypervisor nodes (rdkvm[1-2]) and 1 ovirt-engine node (rdhead1). GlusterFS is setup with 2 bricks on both rdkvm1 and rdkvm2. I have some vm's running on the infraestructure. I have HA enabled and ipmi is working. I manually poweroff force one node. Then I expect that VM's running on that node are started in the remaining node because of the HA setting. What happens is that ovirt starts the powered off node but not the vm's that remain shutted down. Is it the correct behaviour? How can I make that vm's are auto-started if they were running before hypervisor kill? Regards, Felip M -- Felip Moll Marquès Computer Science Engineer E-Mail - lipixx(a)gmail.com WebPage - http://lipix.ciutadella.es

2 2

Migrating Hosted Engine Storage
by Maton, Brett 11 Oct '16

11 Oct '16

Hi, I was wondering how to move the Hosted Engine 'disk' to another storage domain? Live migration doesn't appear to be working, just left the disk in a 'locked' state, the engine is currently up and running. Any suggestions ?

2 1

cbs.centos.org
by Bruckner, Simone 10 Oct '16

10 Oct '16

--_000_2CB4E8C8E00E594EA06D4AC427E429920F5FF372fabamailserverf_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I'm trying to update my oVirt installation but cbs.centos.org (referenced= by ovirt-4.0-dependencies.repo) seems to be down. Any ideas when it will b= e up again? All the best, Simone Bruckner --_000_2CB4E8C8E00E594EA06D4AC427E429920F5FF372fabamailserverf_ Content-Type: text/html; charset="us-ascii" 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"DE" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Hi all,<o:p></o:p> <o:p> </o:p>   I’m trying to upda= te my oVirt installation but cbs.centos.org (referenced by ovirt-4.0-depend= encies.repo) seems to be down. Any ideas when it will be up again?<o:p></o:= p> <o:p> </o:p> All the best,<o:p></o:p> Simone Bruckner<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_2CB4E8C8E00E594EA06D4AC427E429920F5FF372fabamailserverf_--

2 1

Mantenance mode error
by nicola.gentile.to 10 Oct '16

10 Oct '16

Hi, I have a problem. I try to put in maintenance mode the host, but the message that is displayed is this "Error while executing action: Cannot switch Host to Maintenance mode. Host has asynchronous running tasks, wait for operation to complete and retry." I checked the log file engine.log: "2016-10-10 14:32:53,841 INFO [org.ovirt.engine.core.bll.MaintenanceNumberOfVdssCommand] (default task-15) [697e9736] Lock Acquired to object 'EngineLock:{exclusiveLocks='null', sharedLocks='[00000001-0001-0001-0001-00000000016a=<POOL, ACTION_TYPE_FAILED_OBJECT_LOCKED>]'}' 2016-10-10 14:32:53,843 WARN [org.ovirt.engine.core.bll.MaintenanceNumberOfVdssCommand] (default task-15) [697e9736] Validation of action 'MaintenanceNumberOfVdss' failed for user admin@internal-authz. Reasons: VAR__TYPE__HOST,VAR__ACTION__MAINTENANCE,VDS_CANNOT_MAINTENANCE_SPM_WITH_RUNNING_TASKS 2016-10-10 14:32:53,843 INFO [org.ovirt.engine.core.bll.MaintenanceNumberOfVdssCommand] (default task-15) [697e9736] Lock freed to object 'EngineLock:{exclusiveLocks='null', sharedLocks='[00000001-0001-0001-0001-00000000016a=<POOL, ACTION_TYPE_FAILED_OBJECT_LOCKED>]'}' 2016-10-10 14:32:53,851 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-15) [] Operation Failed: [Cannot switch Host to Maintenance mode. Host has asynchronous running tasks," How can I revolve? Regards Nicola

2 1

Error while executing action RefreshLunsSize: REFRESH_LUN_ERROR
by vasily.lamykin＠MegaFon.ru 10 Oct '16

10 Oct '16

--_000_15bc846ff2aa4fb0945833691675231fvlgums05Megafonru_ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable I want to add some space on my LUN. Previously I added the place simply by pressing the "plus" button in domain= management. Today I have some error with this. I touch "plus" button and get next error= s: In web: "Error while executing action RefreshLunsSize: REFRESH_LUN_ERROR " In engine.log: 2016-10-06 05:30:09,974 ERROR [org.ovirt.engine.core.bll.storage.domain.Ref= reshLunsSizeCommand] (default task-1) [784d8d11] Failed to refresh device 3= 600c0ff0001b7485f7aeea5701000000 Not all VDS are seeing the same size VDS := [Host[node10,37d1a1a7-4d40-45bb-8351-0b4f8b3d349c], Host[node1,5a978ba9-331= 4-4f4d-bfc2-59aaefc5a33c], Host[node3,d03c5b81-fdc3-4407-a444-feaa3d2e9d96]= , Host[node2,a44c06e1-379d-4e73-8a8f-60210a99141e]] 2016-10-06 05:30:09,974 ERROR [org.ovirt.engine.core.bll.storage.domain.Ref= reshLunsSizeCommand] (default task-1) [784d8d11] Command 'org.ovirt.engine.= core.bll.storage.domain.RefreshLunsSizeCommand' failed: EngineException: Fa= iled to refresh LUNs. Not all VDS are seeing the same size: [LUN : 3600c0ff= 0001b7485f7aeea5701000000VDS: node10, node1, node3, node2] (Failed with err= or REFRESH_LUN_ERROR and code 5060) 2016-10-06 05:30:09,975 INFO [org.ovirt.engine.core.bll.storage.domain.Ref= reshLunsSizeCommand] (default task-1) [784d8d11] Command [id=3D44f94cb2-3ef= f-49b5-85c6-d2cb79801277]: Compensating CHANGED_STATUS_ONLY of org.ovirt.en= gine.core.common.businessentities.StoragePoolIsoMap; snapshot: EntityStatus= Snapshot:{id=3D'StoragePoolIsoMapId:{storagePoolId=3D'00000001-0001-0001-00= 01-00000000034e', storageId=3D'f5309743-d46b-4365-951a-571d2d9fbc87'}', sta= tus=3D'Active'}. 2016-10-06 05:30:15,683 ERROR [org.ovirt.engine.core.dal.dbbroker.auditlogh= andling.AuditLogDirector] (default task-1) [784d8d11] Correlation ID: 784d8= d11, Job ID: b47afe3a-6052-4c67-a5b6-7f7303aa18b6, Call Stack: null, Custom= Event ID: -1, Message: Failed to resize LUNs. Not all the hosts are seeing the same LUN size. But on all node's I see same LUN size in `multipath -ll` How can i repair this problem, and expand lun size in ovirt? ________________________________ =E9=CE=C6=CF=D2=CD=C1=C3=C9=D1 =D7 =DC=D4=CF=CD =D3=CF=CF=C2=DD=C5=CE=C9=C9= =D0=D2=C5=C4=CE=C1=DA=CE=C1=DE=C5=CE=C1 =C9=D3=CB=CC=C0=DE=C9=D4=C5=CC=D8= =CE=CF =C4=CC=D1 =CB=CF=CE=CB=D2=C5=D4=CE=D9=C8 =CC=C9=C3, =CB=CF=D4=CF=D2= =D9=CD =CF=CE=C1 =C1=C4=D2=C5=D3=CF=D7=C1=CE=C1. =F7 =D3=CF=CF=C2=DD=C5=CE= =C9=C9 =CD=CF=D6=C5=D4 =D3=CF=C4=C5=D2=D6=C1=D4=D8=D3=D1 =CB=CF=CE=C6=C9=C4= =C5=CE=C3=C9=C1=CC=D8=CE=C1=D1 =C9=CE=C6=CF=D2=CD=C1=C3=C9=D1, =CB=CF=D4=CF= =D2=C1=D1 =CE=C5 =CD=CF=D6=C5=D4 =C2=D9=D4=D8 =D2=C1=D3=CB=D2=D9=D4=C1 =C9= =CC=C9 =C9=D3=D0=CF=CC=D8=DA=CF=D7=C1=CE=C1 =CB=C5=CD-=CC=C9=C2=CF, =CB=D2= =CF=CD=C5 =C1=C4=D2=C5=D3=C1=D4=CF=D7. =E5=D3=CC=C9 =D7=D9 =CE=C5 =C1=C4=D2= =C5=D3=C1=D4 =DC=D4=CF=C7=CF =D3=CF=CF=C2=DD=C5=CE=C9=D1, =D4=CF =C9=D3=D0= =CF=CC=D8=DA=CF=D7=C1=CE=C9=C5, =D0=C5=D2=C5=C1=C4=D2=C5=D3=C1=C3=C9=D1, = =CB=CF=D0=C9=D2=CF=D7=C1=CE=C9=C5 =C9=CC=C9 =D2=C1=D3=D0=D2=CF=D3=D4=D2=C1= =CE=C5=CE=C9=C5 =D3=CF=C4=C5=D2=D6=C1=CE=C9=D1 =D3=CF=CF=C2=DD=C5=CE=C9=D1 = =C9=CC=C9 =C5=C7=CF =DE=C1=D3=D4=C9 =CE=C5=DA=C1=CB=CF=CE=CE=CF =C9 =DA=C1= =D0=D2=C5=DD=C5=CE=CF. =E5=D3=CC=C9 =F7=D9 =D0=CF=CC=D5=DE=C9=CC=C9 =DC=D4= =CF =D3=CF=CF=C2=DD=C5=CE=C9=C5 =CF=DB=C9=C2=CF=DE=CE=CF, =D0=CF=D6=C1=CC= =D5=CA=D3=D4=C1, =CE=C5=DA=C1=CD=C5=C4=CC=C9=D4=C5=CC=D8=CE=CF =D3=CF=CF=C2= =DD=C9=D4=C5 =CF=D4=D0=D2=C1=D7=C9=D4=C5=CC=C0 =CF=C2 =DC=D4=CF=CD =C9 =D5= =C4=C1=CC=C9=D4=C5 =D3=CF =D7=D3=C5=CD =D3=CF=C4=C5=D2=D6=C9=CD=D9=CD =D3= =C1=CD=CF =D3=CF=CF=C2=DD=C5=CE=C9=C5 =C9 =CC=C0=C2=D9=C5 =D7=CF=DA=CD=CF= =D6=CE=D9=C5 =C5=C7=CF =CB=CF=D0=C9=C9 =C9 =D0=D2=C9=CC=CF=D6=C5=CE=C9=D1. The information contained in this communication is intended solely for the = use of the individual or entity to whom it is addressed and others authoriz= ed to receive it. It may contain confidential or legally privileged informa= tion. The contents may not be disclosed or used by anyone other than the ad= dressee. If you are not the intended recipient(s), any use, disclosure, cop= ying, distribution or any action taken or omitted to be taken in reliance o= n it is prohibited and may be unlawful. If you have received this communica= tion in error please notify us immediately by responding to this email and = then delete the e-mail and all attachments and any copies thereof. (c)20mf50 --_000_15bc846ff2aa4fb0945833691675231fvlgums05Megafonru_ Content-Type: text/html; charset="koi8-r" 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=3Dkoi8-r"> <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"RU" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> I want to= add some space on my LUN.<o:p></o:p></s= pan> Previousl= y I added the place simply by pressing the “plus” button in dom= ain management.<o:p></o:p> Today I h= ave some error with this. I touch “plus” button and get next er= rors:<o:p></o:p> In web:</= span> “Error while executing action Refres= hLunsSize: REFRESH_LUN_ERROR ”<o:p></o:p> In engine= .log:<o:p></o:p> 2016-10-06 05:30:09,974 ER= ROR [org.ovirt.engine.core.bll.storage.domain.RefreshLunsSizeCommand] (defa= ult task-1) [784d8d11] Failed to refresh device 3600c0ff0001b7485f7aeea5701000000 Not all VDS are seeing the same size VDS= :[Host[node10,37d1a1a7-4d40-45bb-8351-0b4f8b3d349c], Host[node1,5a978ba9-3= 314-4f4d-bfc2-59aaefc5a33c], Host[node3,d03c5b81-fdc3-4407-a444-feaa3d2e9d9= 6], Host[node2,a44c06e1-379d-4e73-8a8f-60210a99141e]]<o:p></o:p> 2016-10-06 05:30:09,974 ER= ROR [org.ovirt.engine.core.bll.storage.domain.RefreshLunsSizeCommand] (defa= ult task-1) [784d8d11] Command 'org.ovirt.engine.core.bll.storage.domain.Re= freshLunsSizeCommand' failed: EngineException: Failed to refresh LUNs. Not all VDS are seeing th= e same size: [LUN : 3600c0ff0001b7485f7aeea5701000000VDS: node10, node1, no= de3, node2] (Failed with error REFRESH_LUN_ERROR and code 5060)<o:p></o:p><= /span> 2016-10-06 05:30:09,975 IN= FO  [org.ovirt.engine.core.bll.storage.domain.RefreshLunsSizeCommand] = (default task-1) [784d8d11] Command [id=3D44f94cb2-3eff-49b5-85c6-d2cb79801= 277]: Compensating CHANGED_STATUS_ONLY of org.ovirt.engine.core.common.businesse= ntities.StoragePoolIsoMap; snapshot: EntityStatusSnapshot:{id=3D'StoragePoo= lIsoMapId:{storagePoolId=3D'00000001-0001-0001-0001-00000000034e', storageI= d=3D'f5309743-d46b-4365-951a-571d2d9fbc87'}', status=3D'Active'}.<o:p></o:p> 2016-10-06 05:30:15,683 ER= ROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] = (default task-1) [784d8d11] Correlation ID: 784d8d11, Job ID: b47afe3a-6052-4c67-a5b6-7f7303aa18b6, Call Stack: null, Custom Eve= nt ID: -1, Message: Failed to resize LUNs.<o:p></o:p> Not all the hosts are seei= ng the same LUN size.<o:p></o:p> <o:p>&nbs= p;</o:p> But on= all node’s I see same LUN size in `multipath –ll`<o:p></o:p></= span> How ca= n i repair this problem, and expand lun size in ovirt?<o:p></o:p></b= > <o:p>&= nbsp;</o:p> </div> <hr> =E9=CE=C6=CF=D2=CD=C1=C3=C9=D1 =D7 =DC=D4=CF=CD =D3=CF=CF=C2=DD=C5=CE=C9=C9= =D0=D2=C5=C4=CE=C1=DA=CE=C1=DE=C5=CE=C1 =C9=D3=CB=CC=C0=DE=C9=D4=C5=CC=D8= =CE=CF =C4=CC=D1 =CB=CF=CE=CB=D2=C5=D4=CE=D9=C8 =CC=C9=C3, =CB=CF=D4=CF=D2= =D9=CD =CF=CE=C1 =C1=C4=D2=C5=D3=CF=D7=C1=CE=C1. =F7 =D3=CF=CF=C2=DD=C5=CE= =C9=C9 =CD=CF=D6=C5=D4 =D3=CF=C4=C5=D2=D6=C1=D4=D8=D3=D1 =CB=CF=CE=C6=C9=C4= =C5=CE=C3=C9=C1=CC=D8=CE=C1=D1 =C9=CE=C6=CF=D2=CD=C1=C3=C9=D1, =CB=CF=D4=CF= =D2=C1=D1 =CE=C5 =CD=CF=D6=C5=D4 =C2=D9=D4=D8 =D2=C1=D3=CB=D2=D9=D4=C1 =C9= =CC=C9 =C9=D3=D0=CF=CC=D8=DA=CF=D7=C1=CE=C1 =CB=C5=CD-=CC=C9=C2=CF, =CB=D2= =CF=CD=C5 =C1=C4=D2=C5=D3=C1=D4=CF=D7. =E5=D3=CC=C9 =D7=D9 =CE=C5 =C1=C4=D2= =C5=D3=C1=D4 =DC=D4=CF=C7=CF =D3=CF=CF=C2=DD=C5=CE=C9=D1, =D4=CF =C9=D3=D0=CF=CC=D8=DA=CF=D7=C1=CE=C9= =C5, =D0=C5=D2=C5=C1=C4=D2=C5=D3=C1=C3=C9=D1, =CB=CF=D0=C9=D2=CF=D7=C1=CE= =C9=C5 =C9=CC=C9 =D2=C1=D3=D0=D2=CF=D3=D4=D2=C1=CE=C5=CE=C9=C5 =D3=CF=C4=C5= =D2=D6=C1=CE=C9=D1 =D3=CF=CF=C2=DD=C5=CE=C9=D1 =C9=CC=C9 =C5=C7=CF =DE=C1= =D3=D4=C9 =CE=C5=DA=C1=CB=CF=CE=CE=CF =C9 =DA=C1=D0=D2=C5=DD=C5=CE=CF. =E5= =D3=CC=C9 =F7=D9 =D0=CF=CC=D5=DE=C9=CC=C9 =DC=D4=CF =D3=CF=CF=C2=DD=C5=CE= =C9=C5 =CF=DB=C9=C2=CF=DE=CE=CF, =D0=CF=D6=C1=CC=D5=CA=D3=D4=C1, =CE=C5=DA= =C1=CD=C5=C4=CC=C9=D4=C5=CC=D8=CE=CF =D3=CF=CF=C2=DD=C9=D4=C5 =CF=D4=D0=D2= =C1=D7=C9=D4=C5=CC=C0 =CF=C2 =DC=D4=CF=CD =C9 =D5=C4=C1=CC=C9=D4=C5 =D3=CF = =D7=D3=C5=CD =D3=CF=C4=C5=D2=D6=C9=CD=D9=CD =D3=C1=CD=CF =D3=CF=CF=C2=DD=C5=CE=C9=C5 =C9 =CC=C0=C2=D9=C5 =D7=CF=DA=CD= =CF=D6=CE=D9=C5 =C5=C7=CF =CB=CF=D0=C9=C9 =C9 =D0=D2=C9=CC=CF=D6=C5=CE=C9= =D1. The information contained in this communication is intended solely for the = use of the individual or entity to whom it is addressed and others authoriz= ed to receive it. It may contain confidential or legally privileged informa= tion. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended re= cipient(s), any use, disclosure, copying, distribution or any action taken = or omitted to be taken in reliance on it is prohibited and may be unlawful.= If you have received this communication in error please notify us immediately by responding to this email and then= delete the e-mail and all attachments and any copies thereof. (c)20mf50 </body> </html> --_000_15bc846ff2aa4fb0945833691675231fvlgums05Megafonru_--

2 2

nagios for ovirt 4
by Kapetanakis Giannis 10 Oct '16

10 Oct '16

Hi, Is there any usable nagios plugin what works with ovirt engine 4? regards, Giannis

3 3