- Users - oVirt List Archives

Linux guests vs. Spice/QXL?
by Uwe Laverenz 18 May '16

18 May '16

Hi all, I'm running some tests on OVirt (3.6.5.3) on CentOS 7 and almost everything works quite well so far. CentOS 6.x, Windows 7 and 2008R2 work fine with Spice/QXL, so my setup seems to be ok. Other Linux systems don't work: Debian 8, Fedora 23/24, CentOS 7.x, Kubuntu 16.04... CentOS 7.x even kills his X server every time the user logs out. X-) They all have in common that they show a fixed display resolution of 1024x768 pixels. This can not be changed manually and of course automatic display resizing doesn't work either. All machines have spice-vdagent and ovirt-guest-agent installed and running. Is this a local problem or is this known/expected behaviour? Is there anything I can do to improve this? thank you, Uwe

2 2

Re: [ovirt-users] 100% memory usage on desktop environments
by Karli Sjöberg 18 May '16

18 May '16

--_000_d37306c3c698445a8f4a6718ef2cc97eexch24sluse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMTggbWFqIDIwMTYgNzowMyBlbSBza3JldiBOaWNvbMOhcyA8bmljb2xhc0BkZXZlbHMu ZXM+Og0KPg0KPiBIaSBLYXJsaSwNCj4NCj4gRWwgMTgvMDUvMTYgYSBsYXMgMTY6NTksIEthcmxp IFNqw7ZiZXJnIGVzY3JpYmnDszoNCj4+DQo+Pg0KPj4gRGVuIDE4IG1haiAyMDE2IDU6NDkgZW0g c2tyZXYgTmljb2zDoXMgPG5pY29sYXNAZGV2ZWxzLmVzPjoNCj4+ID4NCj4+ID4gSGksDQo+PiA+ DQo+PiA+IFByb2JhYmx5IG5vdCBhbiBvVmlydCBpc3N1ZSwgYnV0IG1heWJlIHNvbWVvbmUgY2Fu IGhlbHAuIEkndmUgZGVwbG95ZWQgYQ0KPj4gPiBwcmV0dHkgYmFzaWMgVk0gKHVidW50dSAxNC4w NCBzZXJ2ZXIsIDRHQiBSQU0sIDQgQ1BVcywgMTVHQiBzdG9yYWdlKS4NCj4+DQo+PiBKdXN0IHNw aXRiYWxsaW5nIGhlcmU6IDE0LjA0IG9ubHk/IFRyaWVkIDE2LjA0LCBvciBhbnkgb3RoZXIgT1Mg Zm9yIHRoYXQgbWF0dGVyPyBGb3Igbm93LCBpdCBzb3VuZHMgbW9yZSBndWVzdCByZWxhdGVkIHJh dGhlciB0aGFuIG9WaXJ0Lg0KPj4NCj4+IC9LDQo+DQo+DQo+IEkgdHJpZWQgYSB2YW5pbGxhIGNl bnRvcy03LjEgYXMgd2VsbCBhbmQgdGhlIHNhbWUgaGFwcGVucy4gSSdtIG9mIHRoZSBzYW1lIG9w aW5pb24gdGhhdCB0aGlzIGlzIG1vcmUgYSBndWVzdCByZWxhdGVkIGlzc3VlLCBpdCdzIGp1c3Qg SSdkIGxpa2UgdG8gZmluZCBvdXQgd2h5IHRoaXMgb25seSBoYXBwZW5zIHdpdGggUVhMIGFuZCBu b3Qgd2l0aCBDSVJSVVMuDQo+DQo+IFRoYW5rcy4NCg0KVmVyeSBpbnRlcmVzdGluZy4gQXJlIHlv dXIgaG9zdHMgYWxsIG9mIHRoZSBzYW1lIGFyY2hpdGVjdHVyZShmYW1pbHkpPw0KDQovSw0KDQo+ DQo+PiA+IEVhY2ggdGltZSBJIGluc3RhbGwgYW4gYWRkaXRpb25hbCBkZXNrdG9wIGVudmlyb25t ZW50IChHbm9tZSwgS0RFLA0KPj4gPiB3aGF0ZXZlci4uLiksIENQVSB1c2FnZSByaXNlcyB0byAx MDAlIGFsbCB0aW1lIHRvIHRoZSBleHRyZW1lIHRoYXQNCj4+ID4gaW50ZXJhY3Rpbmcgd2l0aCB0 aGUgbWFjaGluZSBiZWNvbWVzIGltcG9zc2libGUgKG1heWJlIGEgbW91c2UgbW92ZW1lbnQNCj4+ ID4gaXMgcHJvcGFnYXRlZCAzIG1pbnV0ZXMgbGF0ZXIgb3Igc28uLi4pLg0KPj4gPg0KPj4gPiBU byBkZWJ1ZyB0aGlzLCBJIGluc3RhbGxlZCBMWERFLCB3aGljaCBpcyBhIGxpZ2h0d2VpZ2h0IGRl c2t0b3ANCj4+ID4gZW52aXJvbm1lbnQgYmFzZWQgb24gWG9yZy4gSSBjb3VsZCBzZWUgdGhlcmUg aXMgYW4gWG9yZyBwcm9jZXNzDQo+PiA+IGNvbnN1bWluZyBvbmUgb2YgdGhlIENQVXMgYW5kIHRo ZSBtYWNoaW5lIHN0b3BzIHJlc3BvbmRpbmcgYXMgZmFyIGFzIHRoZQ0KPj4gPiBkZXNrdG9wIGVu dmlyb25tZW50IGdvZXMuIEkgaGF2ZSBub3QgY2hhbmdlZCBhbnl0aGluZyBpbiB0aGUNCj4+ID4g Y29uZmlndXJhdGlvbiBmaWxlLg0KPj4gPg0KPj4gPiBJIGNvdWxkIGFsc28gc2VlIHRoaXMgb25s eSBoYXBwZW5zIHdoZW4gUVhMIGlzIGNob3NlbiBhcyB0aGUgZGlzcGxheQ0KPj4gPiBkcml2ZXIu IFdoZW4gQ0lSUlVTIGlzIGNob3NlbiwgZXZlcnl0aGluZyB3b3JrcyBzbW9vdGhseSBhbmQgQ1BV IGlzDQo+PiA+IH4xMDAlIGlkbGUuIFRoZSBkb3duc2lkZSBpcyB0aGF0IHdlIHdhbnQgdG8gdXNl IFNQSUNFIGFuZCBDSVJSVVMgd29uJ3QNCj4+ID4gYWxsb3cgaXQuDQo+PiA+DQo+PiA+IFdoeSBk b2VzIHRoaXMgaGFwcGVuPyBJcyB0aGlzIGFuIE9TLXNpZGUgZHJpdmVyIGlzc3VlPyBBbnkgaGlu dCBob3cgY2FuDQo+PiA+IGl0IGJlIGZpeGVkPw0KPj4gPg0KPj4gPiBUaGFua3MuDQo+PiA+DQo+ PiA+IE5pY29sw6FzDQo+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiA+IFVzZXJzIG1haWxpbmcgbGlzdA0KPj4gPiBVc2Vyc0BvdmlydC5vcmcN Cj4+ID4gaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo+DQo+ DQo= --_000_d37306c3c698445a8f4a6718ef2cc97eexch24sluse_ Content-Type: text/html; charset="utf-8" Content-ID: <00292E3F88DC80458009E189EFB6ABC9(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAxOCBtYWogMjAxNiA3OjAzIGVtIHNrcmV2IE5pY29sw6FzICZsdDtuaWNvbGFz QGRldmVscy5lcyZndDs6PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkgS2FybGksPGJyPg0KJmd0Ozxi cj4NCiZndDsgRWwgMTgvMDUvMTYgYSBsYXMgMTY6NTksIEthcmxpIFNqw7ZiZXJnIGVzY3JpYmnD szo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRGVuIDE4IG1haiAy MDE2IDU6NDkgZW0gc2tyZXYgTmljb2zDoXMgJmx0O25pY29sYXNAZGV2ZWxzLmVzJmd0Ozo8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBIaSw8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 PGJyPg0KJmd0OyZndDsgJmd0OyBQcm9iYWJseSBub3QgYW4gb1ZpcnQgaXNzdWUsIGJ1dCBtYXli ZSBzb21lb25lIGNhbiBoZWxwLiBJJ3ZlIGRlcGxveWVkIGEgPGJyPg0KJmd0OyZndDsgJmd0OyBw cmV0dHkgYmFzaWMgVk0gKHVidW50dSAxNC4wNCBzZXJ2ZXIsIDRHQiBSQU0sIDQgQ1BVcywgMTVH QiBzdG9yYWdlKS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEp1c3Qgc3BpdGJhbGxpbmcg aGVyZTogMTQuMDQgb25seT8gVHJpZWQgMTYuMDQsIG9yIGFueSBvdGhlciBPUyBmb3IgdGhhdCBt YXR0ZXI/IEZvciBub3csIGl0IHNvdW5kcyBtb3JlIGd1ZXN0IHJlbGF0ZWQgcmF0aGVyIHRoYW4g b1ZpcnQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAvSzxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBJIHRyaWVkIGEgdmFuaWxsYSBjZW50b3MtNy4xIGFzIHdlbGwgYW5kIHRoZSBz YW1lIGhhcHBlbnMuIEknbSBvZiB0aGUgc2FtZSBvcGluaW9uIHRoYXQgdGhpcyBpcyBtb3JlIGEg Z3Vlc3QgcmVsYXRlZCBpc3N1ZSwgaXQncyBqdXN0IEknZCBsaWtlIHRvIGZpbmQgb3V0IHdoeSB0 aGlzIG9ubHkgaGFwcGVucyB3aXRoIFFYTCBhbmQgbm90IHdpdGggQ0lSUlVTLjxicj4NCiZndDs8 YnI+DQomZ3Q7IFRoYW5rcy48L3A+DQo8cCBkaXI9Imx0ciI+VmVyeSBpbnRlcmVzdGluZy4gQXJl IHlvdXIgaG9zdHMgYWxsIG9mIHRoZSBzYW1lIGFyY2hpdGVjdHVyZShmYW1pbHkpPzwvcD4NCjxw IGRpcj0ibHRyIj4vSzwvcD4NCjxwIGRpcj0ibHRyIj4mZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBF YWNoIHRpbWUgSSBpbnN0YWxsIGFuIGFkZGl0aW9uYWwgZGVza3RvcCBlbnZpcm9ubWVudCAoR25v bWUsIEtERSwgPGJyPg0KJmd0OyZndDsgJmd0OyB3aGF0ZXZlci4uLiksIENQVSB1c2FnZSByaXNl cyB0byAxMDAlIGFsbCB0aW1lIHRvIHRoZSBleHRyZW1lIHRoYXQgPGJyPg0KJmd0OyZndDsgJmd0 OyBpbnRlcmFjdGluZyB3aXRoIHRoZSBtYWNoaW5lIGJlY29tZXMgaW1wb3NzaWJsZSAobWF5YmUg YSBtb3VzZSBtb3ZlbWVudCA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGlzIHByb3BhZ2F0ZWQgMyBtaW51 dGVzIGxhdGVyIG9yIHNvLi4uKS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0 OyBUbyBkZWJ1ZyB0aGlzLCBJIGluc3RhbGxlZCBMWERFLCB3aGljaCBpcyBhIGxpZ2h0d2VpZ2h0 IGRlc2t0b3AgPGJyPg0KJmd0OyZndDsgJmd0OyBlbnZpcm9ubWVudCBiYXNlZCBvbiBYb3JnLiBJ IGNvdWxkIHNlZSB0aGVyZSBpcyBhbiBYb3JnIHByb2Nlc3MgPGJyPg0KJmd0OyZndDsgJmd0OyBj b25zdW1pbmcgb25lIG9mIHRoZSBDUFVzIGFuZCB0aGUgbWFjaGluZSBzdG9wcyByZXNwb25kaW5n IGFzIGZhciBhcyB0aGUgPGJyPg0KJmd0OyZndDsgJmd0OyBkZXNrdG9wIGVudmlyb25tZW50IGdv ZXMuIEkgaGF2ZSBub3QgY2hhbmdlZCBhbnl0aGluZyBpbiB0aGUgPGJyPg0KJmd0OyZndDsgJmd0 OyBjb25maWd1cmF0aW9uIGZpbGUuPGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZn dDsgSSBjb3VsZCBhbHNvIHNlZSB0aGlzIG9ubHkgaGFwcGVucyB3aGVuIFFYTCBpcyBjaG9zZW4g YXMgdGhlIGRpc3BsYXkgPGJyPg0KJmd0OyZndDsgJmd0OyBkcml2ZXIuIFdoZW4gQ0lSUlVTIGlz IGNob3NlbiwgZXZlcnl0aGluZyB3b3JrcyBzbW9vdGhseSBhbmQgQ1BVIGlzIDxicj4NCiZndDsm Z3Q7ICZndDsgfjEwMCUgaWRsZS4gVGhlIGRvd25zaWRlIGlzIHRoYXQgd2Ugd2FudCB0byB1c2Ug U1BJQ0UgYW5kIENJUlJVUyB3b24ndCA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGFsbG93IGl0Ljxicj4N CiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IFdoeSBkb2VzIHRoaXMgaGFwcGVuPyBJ cyB0aGlzIGFuIE9TLXNpZGUgZHJpdmVyIGlzc3VlPyBBbnkgaGludCBob3cgY2FuIDxicj4NCiZn dDsmZ3Q7ICZndDsgaXQgYmUgZml4ZWQ/PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7 ICZndDsgVGhhbmtzLjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IE5pY29s w6FzPGJyPg0KJmd0OyZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7ICZndDsgVXNlcnMgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyZndDsgJmd0OyBVc2Vyc0BvdmlydC5vcmc8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGh0dHA6Ly9s aXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vyczxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KPC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_d37306c3c698445a8f4a6718ef2cc97eexch24sluse_--

2 1

Re: [ovirt-users] 100% memory usage on desktop environments
by Karli Sjöberg 18 May '16

18 May '16

--_000_848ff670f8084d3e8c04b813ead04977exch24sluse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMTggbWFqIDIwMTYgNTo0OSBlbSBza3JldiBOaWNvbMOhcyA8bmljb2xhc0BkZXZlbHMu ZXM+Og0KPg0KPiBIaSwNCj4NCj4gUHJvYmFibHkgbm90IGFuIG9WaXJ0IGlzc3VlLCBidXQgbWF5 YmUgc29tZW9uZSBjYW4gaGVscC4gSSd2ZSBkZXBsb3llZCBhDQo+IHByZXR0eSBiYXNpYyBWTSAo dWJ1bnR1IDE0LjA0IHNlcnZlciwgNEdCIFJBTSwgNCBDUFVzLCAxNUdCIHN0b3JhZ2UpLg0KDQpK dXN0IHNwaXRiYWxsaW5nIGhlcmU6IDE0LjA0IG9ubHk/IFRyaWVkIDE2LjA0LCBvciBhbnkgb3Ro ZXIgT1MgZm9yIHRoYXQgbWF0dGVyPyBGb3Igbm93LCBpdCBzb3VuZHMgbW9yZSBndWVzdCByZWxh dGVkIHJhdGhlciB0aGFuIG9WaXJ0Lg0KDQovSw0KDQo+IEVhY2ggdGltZSBJIGluc3RhbGwgYW4g YWRkaXRpb25hbCBkZXNrdG9wIGVudmlyb25tZW50IChHbm9tZSwgS0RFLA0KPiB3aGF0ZXZlci4u LiksIENQVSB1c2FnZSByaXNlcyB0byAxMDAlIGFsbCB0aW1lIHRvIHRoZSBleHRyZW1lIHRoYXQN Cj4gaW50ZXJhY3Rpbmcgd2l0aCB0aGUgbWFjaGluZSBiZWNvbWVzIGltcG9zc2libGUgKG1heWJl IGEgbW91c2UgbW92ZW1lbnQNCj4gaXMgcHJvcGFnYXRlZCAzIG1pbnV0ZXMgbGF0ZXIgb3Igc28u Li4pLg0KPg0KPiBUbyBkZWJ1ZyB0aGlzLCBJIGluc3RhbGxlZCBMWERFLCB3aGljaCBpcyBhIGxp Z2h0d2VpZ2h0IGRlc2t0b3ANCj4gZW52aXJvbm1lbnQgYmFzZWQgb24gWG9yZy4gSSBjb3VsZCBz ZWUgdGhlcmUgaXMgYW4gWG9yZyBwcm9jZXNzDQo+IGNvbnN1bWluZyBvbmUgb2YgdGhlIENQVXMg YW5kIHRoZSBtYWNoaW5lIHN0b3BzIHJlc3BvbmRpbmcgYXMgZmFyIGFzIHRoZQ0KPiBkZXNrdG9w IGVudmlyb25tZW50IGdvZXMuIEkgaGF2ZSBub3QgY2hhbmdlZCBhbnl0aGluZyBpbiB0aGUNCj4g Y29uZmlndXJhdGlvbiBmaWxlLg0KPg0KPiBJIGNvdWxkIGFsc28gc2VlIHRoaXMgb25seSBoYXBw ZW5zIHdoZW4gUVhMIGlzIGNob3NlbiBhcyB0aGUgZGlzcGxheQ0KPiBkcml2ZXIuIFdoZW4gQ0lS UlVTIGlzIGNob3NlbiwgZXZlcnl0aGluZyB3b3JrcyBzbW9vdGhseSBhbmQgQ1BVIGlzDQo+IH4x MDAlIGlkbGUuIFRoZSBkb3duc2lkZSBpcyB0aGF0IHdlIHdhbnQgdG8gdXNlIFNQSUNFIGFuZCBD SVJSVVMgd29uJ3QNCj4gYWxsb3cgaXQuDQo+DQo+IFdoeSBkb2VzIHRoaXMgaGFwcGVuPyBJcyB0 aGlzIGFuIE9TLXNpZGUgZHJpdmVyIGlzc3VlPyBBbnkgaGludCBob3cgY2FuDQo+IGl0IGJlIGZp eGVkPw0KPg0KPiBUaGFua3MuDQo+DQo+IE5pY29sw6FzDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFVzZXJzIG1haWxpbmcgbGlzdA0KPiBVc2Vy c0BvdmlydC5vcmcNCj4gaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Vz ZXJzDQo= --_000_848ff670f8084d3e8c04b813ead04977exch24sluse_ Content-Type: text/html; charset="utf-8" Content-ID: <80D2291C8B282C4A8D7D4C59ED986272(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAxOCBtYWogMjAxNiA1OjQ5IGVtIHNrcmV2IE5pY29sw6FzICZsdDtuaWNvbGFz QGRldmVscy5lcyZndDs6PGJyPg0KJmd0Ozxicj4NCiZndDsgSGksPGJyPg0KJmd0Ozxicj4NCiZn dDsgUHJvYmFibHkgbm90IGFuIG9WaXJ0IGlzc3VlLCBidXQgbWF5YmUgc29tZW9uZSBjYW4gaGVs cC4gSSd2ZSBkZXBsb3llZCBhIDxicj4NCiZndDsgcHJldHR5IGJhc2ljIFZNICh1YnVudHUgMTQu MDQgc2VydmVyLCA0R0IgUkFNLCA0IENQVXMsIDE1R0Igc3RvcmFnZSkuIDwvcD4NCjxwIGRpcj0i bHRyIj5KdXN0IHNwaXRiYWxsaW5nIGhlcmU6IDE0LjA0IG9ubHk/IFRyaWVkIDE2LjA0LCBvciBh bnkgb3RoZXIgT1MgZm9yIHRoYXQgbWF0dGVyPyBGb3Igbm93LCBpdCBzb3VuZHMgbW9yZSBndWVz dCByZWxhdGVkIHJhdGhlciB0aGFuIG9WaXJ0LjwvcD4NCjxwIGRpcj0ibHRyIj4vSzwvcD4NCjxw IGRpcj0ibHRyIj4mZ3Q7IEVhY2ggdGltZSBJIGluc3RhbGwgYW4gYWRkaXRpb25hbCBkZXNrdG9w IGVudmlyb25tZW50IChHbm9tZSwgS0RFLA0KPGJyPg0KJmd0OyB3aGF0ZXZlci4uLiksIENQVSB1 c2FnZSByaXNlcyB0byAxMDAlIGFsbCB0aW1lIHRvIHRoZSBleHRyZW1lIHRoYXQgPGJyPg0KJmd0 OyBpbnRlcmFjdGluZyB3aXRoIHRoZSBtYWNoaW5lIGJlY29tZXMgaW1wb3NzaWJsZSAobWF5YmUg YSBtb3VzZSBtb3ZlbWVudCA8YnI+DQomZ3Q7IGlzIHByb3BhZ2F0ZWQgMyBtaW51dGVzIGxhdGVy IG9yIHNvLi4uKS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUbyBkZWJ1ZyB0aGlzLCBJIGluc3RhbGxl ZCBMWERFLCB3aGljaCBpcyBhIGxpZ2h0d2VpZ2h0IGRlc2t0b3AgPGJyPg0KJmd0OyBlbnZpcm9u bWVudCBiYXNlZCBvbiBYb3JnLiBJIGNvdWxkIHNlZSB0aGVyZSBpcyBhbiBYb3JnIHByb2Nlc3Mg PGJyPg0KJmd0OyBjb25zdW1pbmcgb25lIG9mIHRoZSBDUFVzIGFuZCB0aGUgbWFjaGluZSBzdG9w cyByZXNwb25kaW5nIGFzIGZhciBhcyB0aGUgPGJyPg0KJmd0OyBkZXNrdG9wIGVudmlyb25tZW50 IGdvZXMuIEkgaGF2ZSBub3QgY2hhbmdlZCBhbnl0aGluZyBpbiB0aGUgPGJyPg0KJmd0OyBjb25m aWd1cmF0aW9uIGZpbGUuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBjb3VsZCBhbHNvIHNlZSB0aGlz IG9ubHkgaGFwcGVucyB3aGVuIFFYTCBpcyBjaG9zZW4gYXMgdGhlIGRpc3BsYXkgPGJyPg0KJmd0 OyBkcml2ZXIuIFdoZW4gQ0lSUlVTIGlzIGNob3NlbiwgZXZlcnl0aGluZyB3b3JrcyBzbW9vdGhs eSBhbmQgQ1BVIGlzIDxicj4NCiZndDsgfjEwMCUgaWRsZS4gVGhlIGRvd25zaWRlIGlzIHRoYXQg d2Ugd2FudCB0byB1c2UgU1BJQ0UgYW5kIENJUlJVUyB3b24ndCA8YnI+DQomZ3Q7IGFsbG93IGl0 Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFdoeSBkb2VzIHRoaXMgaGFwcGVuPyBJcyB0aGlzIGFuIE9T LXNpZGUgZHJpdmVyIGlzc3VlPyBBbnkgaGludCBob3cgY2FuIDxicj4NCiZndDsgaXQgYmUgZml4 ZWQ/PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzLjxicj4NCiZndDs8YnI+DQomZ3Q7IE5pY29s w6FzPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsgVXNlcnMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBVc2Vyc0BvdmlydC5v cmc8YnI+DQomZ3Q7IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vy czxicj4NCjwvcD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_848ff670f8084d3e8c04b813ead04977exch24sluse_--

2 1

Snapshot is "Locked" - Can't do anything with the VM
by Ivo Rütsche 18 May '16

18 May '16

Hi oVirt List We have the problem, that two of our VM's have "Locked" snapshots and we can't go forward. From 10 VM's which we move from one store to another, we have problems with 5 of them to delete the snapshots. But with a lot of luck, the snapshot was always on the dedicated Swap-Disk, so we just have to remove the whole disk and create it again as new. Because we replace all the filers, we have to move the VM's arround. The move itself runns fine, but deleting the snapshots doesn't work sometimes. I found a lot about our problem, but I can't find any solution, which works an our environment. Our setup: - 3 Solaris filer with NFS exports for the hosts for the vm-images - 8 hosts (oVirt 3.6 / Centos 7.2.1511) - The engine host is located outside of the DC, connected via VPN At the moment, one of the "problem-VM" is productive, the other should become productive in the next days, so we focus us to the 2nd VM, because we can play arround with them. The other one is startet up, but i have no idea, what happens, when i shut them down... This is the status today of VM, which is not productive at the moment: - VM Status: Down - Snapshots OK: 2 - Snapshots Locked: 1 - In the snapshot tab, everything is grayed out (Create, Preview, Commit, Undo etc.) - No active tasks are displayed Error message when i try to start the VM: "Cannot run VM. The VM is performing an operation on a Snapshot. Please wait for the operation to finish, and try again." Something about the history of this VM: 1. We start the disk move from filer1 to filer3, totaly 4 drives, everything was fine 2. Deleting snapshots, i think one or two runns fine 3. Deleting the 2nd or 3rd snapshot runs two days without an end 4. Rebooting the Engine 5. No task anymore in the Tasks list 6. The status of the snapshot is "Locked", die Disk of this snapshot becoms "Illegal" and red 7. Shutdown the VM - no luck, i can't start it again --> "Cannot run VM. The VM is performing an operation on a Snapshot. Please wait for the operation to finish, and try again." 8. We move the disk back from filer3 to the filer1 9. The status of the snapshot is "Locked", die Disk of this snapshot becoms "OK" and green ...but i can't delete the snapshot or starting the VM :( Today, i copy the image files to a dedicated KVM host, which is not involved in the oVirt environment and i merge the image manualy together: qemu-img convert -p -f qcow2 804ffcc3-446f-4c56-ba99-ab90c7951a6f -O raw Merged1 I mount the image and everything fine, all the changes from the last two days are now in a base image. I try to remove the whole disk in oVirt, but i still got the error message, that i have to wait. So for me, the next step is to create a new VM and migrate everything manualy, this will work, but can't be the solution for the other VM, which is productive and it have the same problem. Some information about: ***************** [root@lin-ovirt7 images]# vdsm-tool dump-volume-chains d6e6656d-7aaf-4c5b-bb93-cd6134ed9654 Images volume chains (base volume first) image: f3cfefd2-d467-41d5-a054-5b01f81a21b4 - a018521a-bd3a-4322-ac79-52d15e95639e status: OK, voltype: INTERNAL, format: RAW, legality: LEGAL, type: SPARSE - 2e2f0b4a-b015-4b50-8d10-51726de460a9 status: OK, voltype: INTERNAL, format: COW, legality: LEGAL, type: SPARSE - 804ffcc3-446f-4c56-ba99-ab90c7951a6f status: OK, voltype: LEAF, format: COW, legality: LEGAL, type: SPARSE ***************** [root@lin-ovirt7 images]# ls -altrh f3cfefd2-d467-41d5-a054-5b01f81a21b4/ total 34G -rw-rw----+ 1 vdsm kvm 1.0M 2. Mai 21:03 a018521a-bd3a-4322-ac79-52d15e95639e.lease -rw-rw----+ 1 vdsm kvm 1.0M 2. Mai 21:03 2e2f0b4a-b015-4b50-8d10-51726de460a9.lease -rw-r--r--+ 1 vdsm kvm 260 2. Mai 21:03 804ffcc3-446f-4c56-ba99-ab90c7951a6f.meta -rw-rw----+ 1 vdsm kvm 1.0M 2. Mai 21:03 804ffcc3-446f-4c56-ba99-ab90c7951a6f.lease -rw-rw----+ 1 vdsm kvm 300G 2. Mai 22:26 a018521a-bd3a-4322-ac79-52d15e95639e -rw-rw----+ 1 vdsm kvm 77M 2. Mai 22:27 2e2f0b4a-b015-4b50-8d10-51726de460a9 -rw-rw----+ 1 vdsm kvm 3.5G 2. Mai 22:34 804ffcc3-446f-4c56-ba99-ab90c7951a6f -rw-r--r--+ 1 vdsm kvm 364 2. Mai 22:34 a018521a-bd3a-4322-ac79-52d15e95639e.meta -rw-r--r--+ 1 vdsm kvm 264 2. Mai 22:34 2e2f0b4a-b015-4b50-8d10-51726de460a9.meta drwxr-xr-x+ 2 vdsm kvm 11 2. Mai 22:34 . drwxr-xr-x+ 50 vdsm kvm 50 3. Mai 14:30 .. [root@lin-ovirt7 images]# ***************** I attach some line from the engine.log, maybe someone can help, if you need more information everything is here. gruss ivo

3 6

Re: [ovirt-users] oVirt hosted-engine setup stuck in final phase registering host to engine
by Ralf Schenk 18 May '16

18 May '16

Hello, of course. See attached File. Bye Am 18.05.2016 um 11:13 schrieb Simone Tiraboschi: > It looks, correct. > > Can you please share the whole log file? > > On Wed, May 18, 2016 at 11:03 AM, Ralf Schenk <rs(a)databay.de > <mailto:rs@databay.de>> wrote: > > Hello, > > from the last setup Log: > > 2016-05-11 18:19:31 DEBUG otopi.context > context.dumpEnvironment:510 ENV > OVEHOSTED_ENGINE/appHostName=str:'hosted_engine_1' > > > Am 18.05.2016 um 10:59 schrieb Simone Tiraboschi: >> >> >> On Wed, May 18, 2016 at 10:33 AM, Ralf Schenk <rs(a)databay.de >> <mailto:rs@databay.de>> wrote: >> >> Dear list, >> >> i'm working for days on a hosted-engine setup on glusterfs >> and 'm stuck in the last phase of hosted-engine --deploy see >> Text output (for two days now :-( ). I've only ovirtmgmt >> Bridge up and running and all DNS-Names seen in the >> screenshot are resolvable. It shouldn't be related to your >> problem regarding multiple nic's in the engine-vm. As seen >> the hosted-engine setup is already succsessfull, engine-vm >> running, but the setup fails in registering the host >> (microcloud21...) in the engine. >> >> >> [...] >> >> |- [ INFO ] Starting engine service >> |- [ INFO ] Restarting httpd >> |- [ INFO ] Restarting ovirt-vmconsole proxy service >> |- [ INFO ] Stage: Clean up >> |- Log file is located at >> /var/log/ovirt-engine/setup/ovirt-engine-setup-20160517222119-ndcyxn.log >> |- [ INFO ] Generating answer file >> '/var/lib/ovirt-engine/setup/answers/20160517223055-setup.conf' >> |- [ INFO ] Stage: Pre-termination >> |- [ INFO ] Stage: Termination >> |- [ INFO ] Execution of setup completed successfully >> |- HE_APPLIANCE_ENGINE_SETUP_SUCCESS >> [ INFO ] Engine-setup successfully completed >> [ INFO ] Engine is still unreachable >> [ INFO ] Engine is still not reachable, waiting... >> [ INFO ] Engine replied: DB Up!Welcome to Health Status! >> [ INFO ] Acquiring internal CA cert from the engine >> [ INFO ] The following CA certificate is going to be used, >> please immediately interrupt if not correct: >> [ INFO ] Issuer: C=US, O=rxmgmt.databay.de >> <http://rxmgmt.databay.de>, >> CN=engine-mcIII.rxmgmt.databay.de.77792, Subject: C=US, >> O=rxmgmt.databay.de <http://rxmgmt.databay.de>, >> CN=engine-mcIII.rxmgmt.databay.de.77792, Fingerprint (SHA-1): >> D71A5EA7C5C2C2450F1473523C3A1E022945430 >> [ INFO ] Connecting to the Engine >> [ ERROR ] Cannot automatically add the host to cluster >> Default: Host name must be formed of alphanumeric characters, >> numbers or "-_." >> >> >> Please check Engine VM configuration. >> >> Make a selection from the options below: >> (1) Continue setup - Engine VM configuration has >> been fixed >> (2) Abort setup >> >> (1, 2)[1]: 1 >> >> Checking for oVirt-Engine status at >> engine-mcIII.rxmgmt.databay.de... >> [ INFO ] Engine replied: DB Up!Welcome to Health Status! >> [ ERROR ] Cannot automatically add the host to cluster >> Default: Host name must be formed of alphanumeric characters, >> numbers or "-_." >> >> >> Please check Engine VM configuration. >> >> Make a selection from the options below: >> (1) Continue setup - Engine VM configuration has >> been fixed >> (2) Abort setup >> >> (1, 2)[1]: >> >> Additionally I can see the error in the eninge-vm in >> /var/log/ovirt-engine/engine.log: >> >> 2016-05-17 14:08:15,296 WARN >> [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand] (default >> task-13) [9277b0a] CanDoAction of action 'AddVds' failed for >> user admin@internal. Reasons: >> VAR__ACTION__ADD,VAR__TYPE__HOST,$server >> microcloud21.rxmgmt.databay.de >> <http://microcloud21.rxmgmt.databay.de>,VALIDATION_VDS_NAME_INVALID >> 2016-05-17 14:08:15,360 ERROR >> [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] >> (default task-13) [] Operation Failed: [Host name must be >> formed of alphanumeric characters, numbers or "-_."] >> >> >> 'microcloud21.rxmgmt.databay.de >> <http://microcloud21.rxmgmt.databay.de>' is the host address, in >> oVirt the host has also a name. >> Can you please look for OVEHOSTED_ENGINE/appHostName in your >> hosted-engine-setup logs? >> >> >> >> The hostname that should be registered is the correct fqdn >> for the virtualization host that runs the engine-vm, points >> to the ip of the ovirtmgmt-Bridge and also the IP is >> reverse-resolvable to the hostname. >> I checked /etc/hostname of the host for non-printable >> characters and as you can see that is a valid hostname. >> >> All is running on Centos 7 Versions: >> ovirt-engine-appliance.noarch >> 3.6-20160420.1.el7.centos @ovirt-3.6 >> ovirt-engine-sdk-python.noarch >> 3.6.5.0-1.el7.centos @ovirt-3.6 >> ovirt-host-deploy.noarch >> 1.4.1-1.el7.centos @ovirt-3.6 >> ovirt-hosted-engine-ha.noarch >> 1.3.5.3-1.1.el7 @centos-ovirt36 >> ovirt-hosted-engine-setup.noarch >> 1.3.5.0-1.1.el7 @centos-ovirt36 >> ovirt-setup-lib.noarch >> 1.0.1-1.el7.centos @ovirt-3.6 >> ovirt-vmconsole.noarch >> 1.0.0-1.el7.centos @ovirt-3.6 >> ovirt-vmconsole-host.noarch >> 1.0.0-1.el7.centos @ovirt-3.6 >> >> Since I already repeated the setup for many times now, I need >> your help. >> -- >> >> >> *Ralf Schenk* >> fon +49 (0) 24 05 / 40 83 70 >> <tel:%2B49%20%280%29%2024%2005%20%2F%2040%2083%2070> >> fax +49 (0) 24 05 / 40 83 759 >> <tel:%2B49%20%280%29%2024%2005%20%2F%2040%2083%20759> >> mail *rs(a)databay.de* <mailto:rs@databay.de> >> >> *Databay AG* >> Jens-Otto-Krag-Straße 11 >> D-52146 Würselen >> *www.databay.de* <http://www.databay.de> >> >> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202 >> Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, >> Dipl.-Kfm. Philipp Hermanns >> Aufsichtsratsvorsitzender: Klaus Scholzen (RA) >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> >> http://lists.ovirt.org/mailman/listinfo/users >> >> > > -- > > > *Ralf Schenk* > fon +49 (0) 24 05 / 40 83 70 > <tel:%2B49%20%280%29%2024%2005%20%2F%2040%2083%2070> > fax +49 (0) 24 05 / 40 83 759 > <tel:%2B49%20%280%29%2024%2005%20%2F%2040%2083%20759> > mail *rs(a)databay.de* <mailto:rs@databay.de> > > *Databay AG* > Jens-Otto-Krag-Straße 11 > D-52146 Würselen > *www.databay.de* <http://www.databay.de> > > Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202 > Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, > Dipl.-Kfm. Philipp Hermanns > Aufsichtsratsvorsitzender: Klaus Scholzen (RA) > > ------------------------------------------------------------------------ > > -- *Ralf Schenk* fon +49 (0) 24 05 / 40 83 70 fax +49 (0) 24 05 / 40 83 759 mail *rs(a)databay.de* <mailto:rs@databay.de> *Databay AG* Jens-Otto-Krag-Straße 11 D-52146 Würselen *www.databay.de* <http://www.databay.de> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202 Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns Aufsichtsratsvorsitzender: Klaus Scholzen (RA) ------------------------------------------------------------------------

2 3

AAA LDAP timeout
by Dominique Taffin 18 May '16

18 May '16

Hello! We do have a rather large LDAP which does take some time to answer. Using oVirt and AAA LDAP extension, I do run into timeouts. running "ovirt-engine-extensions-tool --log-level=FINEST --log- file=tool.log aaa login-user --profile=abc --user-name=xxx" fails with: [...] LDAPSearchException(resultCode=85 (timeout), numEntries=0, numReferences=0, errorMessage='A client-side timeout was encountered while waiting 60000ms for a response to search request with message ID 3, base DN [...] ldapsearch itself takes approx 2 minutes. Can the timeout of 60000ms be configured somewhere? I could not find anything in the documentation... thank you and best, Dominique

2 2

RemoveDiskSnapshots error's on engine log
by Ivo Rütsche 18 May '16

18 May '16

Hi List At the moment, we replace a filer and we have to move the VM's to another filer. We have a lot of problems with it. Sometime we have to restart the engine, sometime we have to move the image arround and sometimes we don't have a chance to remove the snapshots. When the VM is running, most of the time the snapshot remove never starts. Now, i found these errors every second in the engine.log since today: 2016-05-11 23:25:29,102 ERROR [org.ovirt.engine.core.bll.CommandsFactory] (DefaultQuartzScheduler_Worker-90) [] Error in invocating CTOR of command 'RemoveDiskSnapshots': null 2016-05-11 23:25:29,102 ERROR [org.ovirt.engine.core.utils.timer.SchedulerUtilQuartzImpl] (DefaultQuartzScheduler_Worker-90) [] Failed to invoke scheduled method invokeCallbackMethods: null 2016-05-11 23:25:30,104 ERROR [org.ovirt.engine.core.bll.CommandsFactory] (DefaultQuartzScheduler_Worker-66) [] Error in invocating CTOR of command 'RemoveDiskSnapshots': null 2016-05-11 23:25:30,104 ERROR [org.ovirt.engine.core.utils.timer.SchedulerUtilQuartzImpl] (DefaultQuartzScheduler_Worker-66) [] Failed to invoke scheduled method invokeCallbackMethods: null 2016-05-11 23:25:31,105 ERROR [org.ovirt.engine.core.bll.CommandsFactory] (DefaultQuartzScheduler_Worker-76) [] Error in invocating CTOR of command 'RemoveDiskSnapshots': null 2016-05-11 23:25:31,105 ERROR [org.ovirt.engine.core.utils.timer.SchedulerUtilQuartzImpl] (DefaultQuartzScheduler_Worker-76) [] Failed to invoke scheduled method invokeCallbackMethods: null I try everything, but i can't find the problem. Anyone who have an idea, where i have to search? Thank's for help. Ivo

2 2

oVirt hosted-engine setup stuck in final phase registering host to engine
by Ralf Schenk 18 May '16

18 May '16

This is a multi-part message in MIME format. --------------B5233FE7196FCCD40BA3A0F3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Dear list, i'm working for days on a hosted-engine setup on glusterfs and 'm stuck in the last phase of hosted-engine --deploy see Text output (for two days now :-( ). I've only ovirtmgmt Bridge up and running and all DNS-Names seen in the screenshot are resolvable. It shouldn't be related to your problem regarding multiple nic's in the engine-vm. As seen the hosted-engine setup is already succsessfull, engine-vm running, but the setup fails in registering the host (microcloud21...) in the engine. [...] |- [ INFO ] Starting engine service |- [ INFO ] Restarting httpd |- [ INFO ] Restarting ovirt-vmconsole proxy service |- [ INFO ] Stage: Clean up |- Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20160517222119-ndcyxn.log |- [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20160517223055-setup.conf' |- [ INFO ] Stage: Pre-termination |- [ INFO ] Stage: Termination |- [ INFO ] Execution of setup completed successfully |- HE_APPLIANCE_ENGINE_SETUP_SUCCESS [ INFO ] Engine-setup successfully completed [ INFO ] Engine is still unreachable [ INFO ] Engine is still not reachable, waiting... [ INFO ] Engine replied: DB Up!Welcome to Health Status! [ INFO ] Acquiring internal CA cert from the engine [ INFO ] The following CA certificate is going to be used, please immediately interrupt if not correct: [ INFO ] Issuer: C=US, O=rxmgmt.databay.de, CN=engine-mcIII.rxmgmt.databay.de.77792, Subject: C=US, O=rxmgmt.databay.de, CN=engine-mcIII.rxmgmt.databay.de.77792, Fingerprint (SHA-1): D71A5EA7C5C2C2450F1473523C3A1E022945430 [ INFO ] Connecting to the Engine [ ERROR ] Cannot automatically add the host to cluster Default: Host name must be formed of alphanumeric characters, numbers or "-_." Please check Engine VM configuration. Make a selection from the options below: (1) Continue setup - Engine VM configuration has been fixed (2) Abort setup (1, 2)[1]: 1 Checking for oVirt-Engine status at engine-mcIII.rxmgmt.databay.de... [ INFO ] Engine replied: DB Up!Welcome to Health Status! [ ERROR ] Cannot automatically add the host to cluster Default: Host name must be formed of alphanumeric characters, numbers or "-_." Please check Engine VM configuration. Make a selection from the options below: (1) Continue setup - Engine VM configuration has been fixed (2) Abort setup (1, 2)[1]: Additionally I can see the error in the eninge-vm in /var/log/ovirt-engine/engine.log: 2016-05-17 14:08:15,296 WARN [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand] (default task-13) [9277b0a] CanDoAction of action 'AddVds' failed for user admin@internal. Reasons: VAR__ACTION__ADD,VAR__TYPE__HOST,$server microcloud21.rxmgmt.databay.de,VALIDATION_VDS_NAME_INVALID 2016-05-17 14:08:15,360 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-13) [] Operation Failed: [Host name must be formed of alphanumeric characters, numbers or "-_."] The hostname that should be registered is the correct fqdn for the virtualization host that runs the engine-vm, points to the ip of the ovirtmgmt-Bridge and also the IP is reverse-resolvable to the hostname. I checked /etc/hostname of the host for non-printable characters and as you can see that is a valid hostname. All is running on Centos 7 Versions: ovirt-engine-appliance.noarch 3.6-20160420.1.el7.centos @ovirt-3.6 ovirt-engine-sdk-python.noarch 3.6.5.0-1.el7.centos @ovirt-3.6 ovirt-host-deploy.noarch 1.4.1-1.el7.centos @ovirt-3.6 ovirt-hosted-engine-ha.noarch 1.3.5.3-1.1.el7 @centos-ovirt36 ovirt-hosted-engine-setup.noarch 1.3.5.0-1.1.el7 @centos-ovirt36 ovirt-setup-lib.noarch 1.0.1-1.el7.centos @ovirt-3.6 ovirt-vmconsole.noarch 1.0.0-1.el7.centos @ovirt-3.6 ovirt-vmconsole-host.noarch 1.0.0-1.el7.centos @ovirt-3.6 Since I already repeated the setup for many times now, I need your help. -- *Ralf Schenk* fon +49 (0) 24 05 / 40 83 70 fax +49 (0) 24 05 / 40 83 759 mail *rs(a)databay.de* <mailto:rs@databay.de> *Databay AG* Jens-Otto-Krag-Straße 11 D-52146 Würselen *www.databay.de* <http://www.databay.de> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202 Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns Aufsichtsratsvorsitzender: Klaus Scholzen (RA) ------------------------------------------------------------------------ --------------B5233FE7196FCCD40BA3A0F3 Content-Type: multipart/related; boundary="------------612A57C905DDB6834F2B6528" --------------612A57C905DDB6834F2B6528 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Dear list, i'm working for days on a hosted-engine setup on glusterfs and 'm stuck in the last phase of hosted-engine --deploy see Text output (for two days now :-( ). I've only ovirtmgmt Bridge up and running and all DNS-Names seen in the screenshot are resolvable. It shouldn't be related to your problem regarding multiple nic's in the engine-vm. As seen the hosted-engine setup is already succsessfull, engine-vm running, but the setup fails in registering the host (microcloud21...) in the engine. <tt> </tt> <tt>[...]</tt> <tt> |- [ INFO ] Starting engine service</tt><tt> </tt><tt> |- [ INFO ] Restarting httpd</tt><tt> </tt><tt> |- [ INFO ] Restarting ovirt-vmconsole proxy service</tt><tt> </tt><tt> |- [ INFO ] Stage: Clean up</tt><tt> </tt><tt> |- Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20160517222119-ndcyxn.log</tt><tt> </tt><tt> |- [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20160517223055-setup.conf'</tt><tt> </tt><tt> |- [ INFO ] Stage: Pre-termination</tt><tt> </tt><tt> |- [ INFO ] Stage: Termination</tt><tt> </tt><tt> |- [ INFO ] Execution of setup completed successfully</tt><tt> </tt><tt> |- HE_APPLIANCE_ENGINE_SETUP_SUCCESS</tt><tt> </tt><tt>[ INFO ] Engine-setup successfully completed</tt><tt> </tt><tt>[ INFO ] Engine is still unreachable</tt><tt> </tt><tt>[ INFO ] Engine is still not reachable, waiting...</tt><tt> </tt><tt>[ INFO ] Engine replied: DB Up!Welcome to Health Status!</tt><tt> </tt><tt>[ INFO ] Acquiring internal CA cert from the engine</tt><tt> </tt><tt>[ INFO ] The following CA certificate is going to be used, please immediately interrupt if not correct:</tt><tt> </tt><tt>[ INFO ] Issuer: C=US, O=rxmgmt.databay.de, CN=engine-mcIII.rxmgmt.databay.de.77792, Subject: C=US, O=rxmgmt.databay.de, CN=engine-mcIII.rxmgmt.databay.de.77792, Fingerprint (SHA-1): D71A5EA7C5C2C2450F1473523C3A1E022945430</tt><tt> </tt><tt>[ INFO ] Connecting to the Engine</tt><tt> </tt><tt>[ ERROR ] Cannot automatically add the host to cluster Default: Host name must be formed of alphanumeric characters, numbers or "-_."</tt><tt> </tt><tt> </tt><tt> </tt><tt> Please check Engine VM configuration.</tt><tt> </tt><tt> </tt><tt> Make a selection from the options below:</tt><tt> </tt><tt> (1) Continue setup - Engine VM configuration has been fixed</tt><tt> </tt><tt> (2) Abort setup</tt><tt> </tt><tt> </tt><tt> (1, 2)[1]: 1</tt><tt> </tt><tt> </tt><tt> Checking for oVirt-Engine status at engine-mcIII.rxmgmt.databay.de...</tt><tt> </tt><tt>[ INFO ] Engine replied: DB Up!Welcome to Health Status!</tt><tt> </tt><tt>[ ERROR ] Cannot automatically add the host to cluster Default: Host name must be formed of alphanumeric characters, numbers or "-_."</tt><tt> </tt><tt> </tt><tt> </tt><tt> Please check Engine VM configuration.</tt><tt> </tt><tt> </tt><tt> Make a selection from the options below:</tt><tt> </tt><tt> (1) Continue setup - Engine VM configuration has been fixed</tt><tt> </tt><tt> (2) Abort setup</tt><tt> </tt><tt> </tt><tt> (1, 2)[1]:</tt><tt> </tt> Additionally I can see the error in the eninge-vm in /var/log/ovirt-engine/engine.log: <tt>2016-05-17 14:08:15,296 WARN [org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand] (default task-13) [9277b0a] CanDoAction of action 'AddVds' failed for user admin@internal. Reasons: VAR__ACTION__ADD,VAR__TYPE__HOST,$server microcloud21.rxmgmt.databay.de,VALIDATION_VDS_NAME_INVALID</tt><tt> </tt><tt>2016-05-17 14:08:15,360 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-13) [] Operation Failed: [Host name must be formed of alphanumeric characters, numbers or "-_."]</tt> The hostname that should be registered is the correct fqdn for the virtualization host that runs the engine-vm, points to the ip of the ovirtmgmt-Bridge and also the IP is reverse-resolvable to the hostname. I checked /etc/hostname of the host for non-printable characters and as you can see that is a valid hostname. All is running on Centos 7 Versions: <tt>ovirt-engine-appliance.noarch 3.6-20160420.1.el7.centos @ovirt-3.6</tt><tt> </tt><tt>ovirt-engine-sdk-python.noarch 3.6.5.0-1.el7.centos @ovirt-3.6</tt><tt> </tt><tt>ovirt-host-deploy.noarch 1.4.1-1.el7.centos @ovirt-3.6</tt><tt> </tt><tt>ovirt-hosted-engine-ha.noarch 1.3.5.3-1.1.el7 @centos-ovirt36</tt><tt> </tt><tt>ovirt-hosted-engine-setup.noarch 1.3.5.0-1.1.el7 @centos-ovirt36</tt><tt> </tt><tt>ovirt-setup-lib.noarch 1.0.1-1.el7.centos @ovirt-3.6</tt><tt> </tt><tt>ovirt-vmconsole.noarch 1.0.0-1.el7.centos @ovirt-3.6</tt><tt> </tt><tt>ovirt-vmconsole-host.noarch 1.0.0-1.el7.centos @ovirt-3.6</tt><tt> </tt> Since I already repeated the setup for many times now, I need your help. <div class="moz-signature">-- <table border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <td colspan="3"><img src="cid:part1.3F247D48.E0F6EE3B@databay.de" height="30" border="0" width="151"></td> </tr> <tr> <td valign="top"> Ralf Schenk fon +49 (0) 24 05 / 40 83 70 fax +49 (0) 24 05 / 40 83 759 mail <a href="mailto:rs@databay.de">rs(a)databay.de</a> </td> <td width="30"> </td> <td valign="top"> Databay AG Jens-Otto-Krag-Straße 11 D-52146 Würselen <a href="http://www.databay.de">www.databay.de</a> </td> </tr> <tr> <td colspan="3" valign="top"> Sitz/Amtsgericht Aachen • HRB:8437 • USt-IdNr.: DE 210844202 Vorstand: Ralf Schenk, Dipl.-Ing. Jens Conze, Aresch Yavari, Dipl.-Kfm. Philipp Hermanns Aufsichtsratsvorsitzender: Klaus Scholzen (RA) </td> </tr> </tbody> </table> <hr color="#000000" noshade="noshade" size="1" width="100%"> </div> </body> </html> --------------612A57C905DDB6834F2B6528 Content-Type: image/gif; name="logo_databay_email.gif" Content-Transfer-Encoding: base64 Content-ID: <part1.3F247D48.E0F6EE3B(a)databay.de> Content-Disposition: inline; filename="logo_databay_email.gif" R0lGODlhlwAeAMQAAObm5v9QVf/R0oKBgfDw8NfX105MTLi3t/r6+sfHx/+rrf98gC0sLP8L EhIQEKalpf/g4ZmYmHd2dmppaf8uNP/y8v8cIv+Ym//AwkE/P46NjRwbG11cXP8ABwUDA/// /yH5BAAAAAAALAAAAACXAB4AAAX/4CeOYnUJZKqubOu+cCzPNA0tVnfVfO//wGAKk+t0Ap+K QMFUYCDCqHRKJVUWDaPRUsFktZ1G4AKtms9o1gKsFVS+7I5ll67bpd647hPQawNld4KDMQJF bA07F35aFBiEkJEpfXEBjx8KjI0Vkp2DEIdaCySgFBShbEgrCQOtrq+uEQcALQewrQUjEbe8 rgkkD7y5KhMZB3drqSoVFQhdlHGXKQYe1dbX2BvHKwzY1RMiAN7j1xEjBeTmKeIeD3cYCxRf FigvChRxFJwkBBvk5A7cpZhAjgGCDwn+kfslgto4CSoSehh2BwEEBQvowDAUR0EKdArHZTg4 4oDCXBFC/3qj9SEluZEpHnjYQFIGgpo1KgSasYjNKBImrzF4NaFbNgIjCGRQeIyVKwneOLzS cLCAg38OWI4Y4GECgQcSOEwYcADnh6/FNjAwoGFYAQ0atI4AAFeEFwsLFLiJUQEfGH0kNGAD x8+oNQdIRQg+7NCaOhIgD8sVgYADNsPVGI5YWjRqzQTdHDDIYHRDLokaUhCglkFEJi0NKJhl 0RP2TsvXUg88KiLBVWsZrF6DmMKlNYMqglqTik1guN8OBgAgkGCpB+L9ugK4iSCBvwEfECw1 kILrBpa1jVCQIQBRvbP+rlEcQVAoSevWyv6uhpwE12uEkQAAZucpVw1xIsjkgf8B863mQVYt eQATCZYJZJ5WBfij2wfpHcEeHGG8Z+BMszVWDXkfKLhceJhBSAJ+1ThH32AfRFZNayNAtUFi wFSTSwEHJIYAAQU84IADwyjIEALU9MchG+vFgIF7W2GDI2T7HfjBgNcgKQKMHmwjgnCSpeCb ULRkdxhF1CDY40RjgmUAA/v1J5FAKW2gGSZscBFDMraNgJs1AYpAAGYP5jJoNQ4Y4Gh8jpFg HH9mgbmWo1l6oA4C3Ygp6UwEIFBfNRtkMIBlKMLnAXgAXLWhXXH85EIFqMhGGZgDEKArABGA ed0HI4bk5qgnprCYSt88B6dqS0FEEAMPJDCdCJYViur/B1BlwGMJqDTwnhqxJgUpo0ceOQ4D 0yEakpMm/jqCRMgWm2I1j824Y6vLvuuPjHnqOJkIgP6xzwp5sCFNsCFp88Gxh11lrjfDcNrc CEx64/CD3iAHlQcMUEQXvcA+qBkBB4Q2X1CusjBlJdKMYAKI6g28MbKN5hJsBAXknHOwutn4 oFYqkpqAzjnPbE0u1PxmwAQGXLWBbvhuIIEGEnRjlAHO4SvhbCNAkwoGzEBwgV9U0lfu2WiX OkDEGaCdKgl0nk2YkWdPOCDabvaGdkAftL1LlgwCM+7Tq11V71IO7LkM2XE0YAHMYMhqqK6U V165CpaHukLmiXFO8XSVzzakX+UH6TrmAajPNxfqByTQec41AeBPvSwIALkmAnuiexCsca3C BajgfsROuxcPA8kHQJX4DAIwjnsAvhsvfXHWKEwDAljg7sj03L9wwAQTxOWD2AE0YP75eCkw cPfs+xACADs= --------------612A57C905DDB6834F2B6528-- --------------B5233FE7196FCCD40BA3A0F3--

2 1

How to migrate un-migratable VMs?
by Nicolas Ecarnot 17 May '16

17 May '16

Hi, Some VMs are doing high guest-memory writes (mainly files and mail servers, but not only), so migrations are reproductively failing. I found some info here : https://bugzilla.redhat.com/show_bug.cgi?id=919201 that confirm what I was fearing. This BZ is aging from dinosaurs times, so I was wondering now we're in the 3.6.x age and 4.x coming, are there advices one may give to migrate those verbose VMs? I guess increasing the allowed page memory is not a correct answer as it will fill as before. Any thoughts? -- Nicolas ECARNOT

3 3

Do you use ovirt-engine-reports?
by Yedidyah Bar David 17 May '16

17 May '16

Hi all, We are considering dropping ovirt-engine-reports in 4.0. Some of its functionality will be added in a new feature called "Dashboards", see [1]. Do you use Reports? How important it is to your setup? [1] https://bugzilla.redhat.com/1324860 Best regards, -- Didi

2 2