- Users - oVirt List Archives

[Users] Deleting Storage Connection
by Nauman Abbas 08 Jan '14

08 Jan '14

Hello all I want to delete a storage connection since I'm adding an ISO Domain and it gives me the error "Storage connection already exists.". I'm trying to go for this: http://www.ovirt.org/Features/Manage_Storage_Connections#Delete_connection_… But it just shows me some link and some script. I don't know how use it. A little guidance on it would be great. Sorry for being a noob. Regards Nauman Abbas Assistant System Administrator (LMS), Room No. A-207, SEECS, National University of Sciences & Technology, + 92 321 5359946

5 10

[Users] tuned profile for Centos hosts -- new Bugzilla or Regression
by Ted Miller 08 Jan '14

08 Jan '14

--_000_a584ee1c0d4e40a2ae295cf23111628bDM2PR05MB320namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I posted a script (a while back) to get oVirt running on Centos hosts. One of the items in it has to do with what "tuned" profile to use. At the = time I first ran into it, this was a fatal error. It is now just a warning= , so it does not prevent installing a host. But, as a warning, a lot of pe= ople are probably missing it. When using Centos 6 as the host OS, the script tries to install a "rhs-virt= ualization" profile. That profile is not included in Centos. I substitute= d the "virtual-host" profile. I believe that this may be a regression as a result of Bugzilla 987293<http= s://bugzilla.redhat.com/show_bug.cgi?id=3D987293>, where "rhs-virtualizatio= n" was substituted for "virtual-host" for RHEV + RHS. I am guessing that w= hatever is used as a switch to determine RHEV + RHS is also shoving Centos = into that same path, which is not appropriate. My suggestion would be to write the script so that it uses "rhs-virtualizat= ion" when present, and if it is not present, then it falls back to "virtual= -host". (I don't know what (if any) differences there are between the two = profiles.) Should I open a new bug, make a comment on 987293, or take some other path? Ted Miller --_000_a584ee1c0d4e40a2ae295cf23111628bDM2PR05MB320namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <style style=3D"display: none;" id=3D"owaParaStyle" type=3D"text/css"></style> </head> <body tabindex=3D"0" aria-label=3D"Message body" fpstyle=3D"1" dir=3D"ltr"> <div name=3D"divtagdefaultwrapper" id=3D"divtagdefaultwrapper" style=3D"fon= t-family: Calibri,Arial,Helvetica,sans-serif; font-size: 12pt; color: #0000= 00; margin: 0"> I posted a script (a while back) to get oVirt running on Centos hosts.<br> <br> One of the items in it has to do with what "tuned" profile to use= .  At the time I first ran into it, this was a fatal error.  It i= s now just a warning, so it does not prevent installing a host.  But, = as a warning, a lot of people are probably missing it.<br> <br> When using Centos 6 as the host OS, the script tries to install a "rhs= -virtualization" profile.  That profile is not included in Centos= .  I substituted the "virtual-host" profile.<br> <br> I believe that this may be a regression as a result of Bugzilla <a href=3D"= https://bugzilla.redhat.com/show_bug.cgi?id=3D987293"> <b>987293</b></a>, where "rhs-virtualization" was substituted for= "virtual-host" for RHEV + RHS.  I am guessing that what= ever is used as a switch to determine RHEV + RHS is also shoving Centos= into that same path, which is not appropriate.<br> <br> My suggestion would be to write the script so that it uses "rhs-virtua= lization" when present, and if it is not present, then it falls back t= o "virtual-host".  (I don't know what (if any) differences t= here are between the two profiles.)<br> <br> Should I open a new bug, make a comment on 987293, or take some other path?= <br> <br> Ted Miller<br> <br> </div> </body> </html> --_000_a584ee1c0d4e40a2ae295cf23111628bDM2PR05MB320namprd05pro_--

2 1

Re: [Users] R: tuned profile for Centos hosts -- new Bugzilla orRegression
by Doron Fediuck 08 Jan '14

08 Jan '14

----_com.android.email_973242271645170 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgZ3V5cyzCoApBcyBmYXIgYXMgSSBrbm93LCB0dW5lZCBpcyBub3QgYXZhaWxhYmxlIGluIGNl bnRvcy4gU28gd2UgZmlyc3QgbmVlZCB0byB2ZXJpZnkgdHVuZWQgZXhpc3RzLgpPbmNlIGF2YWls YWJsZSwgd2UnbGwgYmUgYWJsZSB0byBoYW5kbGUKdGhlIHJlbGV2YW50IHByb2ZpbGVzIGZvciBo eXBlcnZpc29ycy4KCkNhbiBhbnlvbmUgY29uZmlybSB0dW5lZCBhdmFpbGFiaWxpdHkgb24gY2Vu dG9zPwoKLS0tLS0tLS0g15TXldeT16LXlCDXnten15XXqNeZ16ogLS0tLS0tLS0K157XkNeqOiBB bWVkZW8gU2FsdmF0aSA8YW1lZGVvQG9zY2VydC5uZXQ+IArXqteQ16jXmdeaOjA4LzAxLzIwMTQg IDAwOjMyICAoR01UKzAyOjAwKSAK15DXnDogdXNlcnNAb3ZpcnQub3JnLHRtaWxsZXJAaGNqYi5v cmcgCteg15XXqdeQOiBbVXNlcnNdIFI6IHR1bmVkIHByb2ZpbGUgZm9yIENlbnRvcyBob3N0cyAt LSBuZXcgQnVnemlsbGEgb3JSZWdyZXNzaW9uIAoKSGkgVGVkLAoKSSdtIGludGVyZXN0ZWQgdG8g b24gdGhpcyB0dW5lZCByaHMtdmlydHVhbGl6YXRpb24gcHJvZmlsZS4uLiB3aGVyZSBJIGNhbiBm aW5kIGl0PyBBbmQgd2hhdCBtYWNybyBkaWZmZXJlbmNlcyBoYXMgYWdhaW5zdCB2aXJ0dWFsLWhv c3QgcHJvZmlsZT8KCkJlc3QgcmVnYXJkcwphCgoKRGF0ZTrCoE1vbiwgNiBKYW4gMjAxNCAyMjow OTo0NMKgKzAwMDAKRnJvbTogVGVkIE1pbGxlciA8dG1pbGxlckBoY2piLm9yZz4KVG86IG9WaXJ0 IE1haWxpbmcgTGlzdCA8dXNlcnNAb3ZpcnQub3JnPgpTdWJqZWN0OiBbVXNlcnNdIHR1bmVkIHBy b2ZpbGUgZm9yIENlbnRvcyBob3N0cyAtLSBuZXcgQnVnemlsbGEgb3IKUmVncmVzc2lvbgpNZXNz YWdlLUlEOgo8YTU4NGVlMWMwZDRlNDBhMmFlMjk1Y2YyMzExMTYyOGJARE0yUFIwNU1CMzIwLm5h bXByZDA1LnByb2Qub3V0bG9vay5jb20+CgpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJz ZXQ9InVzLWFzY2lpIgoKSSBwb3N0ZWQgYSBzY3JpcHQgKGEgd2hpbGUgYmFjaykgdG8gZ2V0IG9W aXJ0IHJ1bm5pbmcgb24gQ2VudG9zIGhvc3RzLgoKT25lIG9mIHRoZSBpdGVtcyBpbiBpdCBoYXMg dG8gZG8gd2l0aCB3aGF0ICJ0dW5lZCIgcHJvZmlsZSB0byB1c2UuwqAgQXQgdGhlIHRpbWUgSSBm aXJzdCByYW4gaW50byBpdCwgdGhpcyB3YXMgYSBmYXRhbCBlcnJvci7CoCBJdCBpcyBub3cganVz dCBhIHdhcm5pbmcsIHNvIGl0IGRvZXMgbm90IHByZXZlbnQgaW5zdGFsbGluZyBhIGhvc3QuwqAg QnV0LCBhcyBhIHdhcm5pbmcsIGEgbG90IG9mIHBlb3BsZSBhcmUgcHJvYmFibHkgbWlzc2luZyBp dC4KCldoZW4gdXNpbmcgQ2VudG9zIDYgYXMgdGhlIGhvc3QgT1MsIHRoZSBzY3JpcHQgdHJpZXMg dG8gaW5zdGFsbCBhICJyaHMtdmlydHVhbGl6YXRpb24iIHByb2ZpbGUuwqAgVGhhdCBwcm9maWxl IGlzIG5vdCBpbmNsdWRlZCBpbiBDZW50b3MuwqAgSSBzdWJzdGl0dXRlZCB0aGUgInZpcnR1YWwt aG9zdCIgcHJvZmlsZS4KCkkgYmVsaWV2ZSB0aGF0IHRoaXMgbWF5IGJlIGEgcmVncmVzc2lvbiBh cyBhIHJlc3VsdCBvZiBCdWd6aWxsYSA5ODcyOTM8aHR0cHM6Ly9idWd6aWxsYS5yZWRoYXQuY29t L3Nob3dfYnVnLmNnaT9pZD05ODcyOTM+Oywgd2hlcmUgInJocy12aXJ0dWFsaXphdGlvbiIgd2Fz IHN1YnN0aXR1dGVkIGZvciAidmlydHVhbC1ob3N0IiBmb3IgUkhFViArIFJIUy7CoCBJIGFtIGd1 ZXNzaW5nIHRoYXQgd2hhdGV2ZXIgaXMgdXNlZCBhcyBhIHN3aXRjaCB0byBkZXRlcm1pbmUgUkhF ViArIFJIUyBpcyBhbHNvIHNob3ZpbmcgQ2VudG9zIGludG8gdGhhdCBzYW1lIHBhdGgsIHdoaWNo IGlzIG5vdCBhcHByb3ByaWF0ZS4KCk15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gd3JpdGUgdGhl IHNjcmlwdCBzbyB0aGF0IGl0IHVzZXMgInJocy12aXJ0dWFsaXphdGlvbiIgd2hlbiBwcmVzZW50 LCBhbmQgaWYgaXQgaXMgbm90IHByZXNlbnQsIHRoZW4gaXQgZmFsbHMgYmFjayB0byAidmlydHVh bC1ob3N0Ii7CoCAoSSBkb24ndCBrbm93IHdoYXQgKGlmIGFueSkgZGlmZmVyZW5jZXMgdGhlcmUg YXJlIGJldHdlZW4gdGhlIHR3byBwcm9maWxlcy4pCgpTaG91bGQgSSBvcGVuIGEgbmV3IGJ1Zywg bWFrZSBhIGNvbW1lbnQgb24gOTg3MjkzLCBvciB0YWtlIHNvbWUgb3RoZXIgcGF0aD8KClRlZCBN aWxsZXIKCgoKSW52aWF0byBkYSBUYWJsZXQgU2Ftc3VuZw== ----_com.android.email_973242271645170 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5IaSBndXlzLCZuYnNwOzwv ZGl2PjxkaXY+QXMgZmFyIGFzIEkga25vdywgdHVuZWQgaXMgbm90IGF2YWlsYWJsZSBpbiBjZW50 b3MuIFNvIHdlIGZpcnN0IG5lZWQgdG8gdmVyaWZ5IHR1bmVkIGV4aXN0cy48L2Rpdj48ZGl2Pk9u Y2UgYXZhaWxhYmxlLCB3ZSdsbCBiZSBhYmxlIHRvIGhhbmRsZTwvZGl2PjxkaXY+dGhlIHJlbGV2 YW50IHByb2ZpbGVzIGZvciBoeXBlcnZpc29ycy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkNh biBhbnlvbmUgY29uZmlybSB0dW5lZCBhdmFpbGFiaWxpdHkgb24gY2VudG9zPzwvZGl2Pjxicj48 YnI+LS0tLS0tLS0g15TXldeT16LXlCDXnten15XXqNeZ16ogLS0tLS0tLS08YnI+157XkNeqOiBB bWVkZW8gU2FsdmF0aSA8YW1lZGVvQG9zY2VydC5uZXQ+IDxicj7XqteQ16jXmdeaOjA4LzAxLzIw MTQgIDAwOjMyICAoR01UKzAyOjAwKSA8YnI+15DXnDogdXNlcnNAb3ZpcnQub3JnLHRtaWxsZXJA aGNqYi5vcmcgPGJyPteg15XXqdeQOiBbVXNlcnNdIFI6IHR1bmVkIHByb2ZpbGUgZm9yIENlbnRv cyBob3N0cyAtLSBuZXcgQnVnemlsbGEgb3JSZWdyZXNzaW9uIDxicj48YnI+PGRpdj48ZGl2Pkhp IFRlZCw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkknbSBpbnRlcmVzdGVkIHRvIG9uIHRoaXMg dHVuZWQgcmhzLXZpcnR1YWxpemF0aW9uIHByb2ZpbGUuLi4gd2hlcmUgSSBjYW4gZmluZCBpdD8g QW5kIHdoYXQgbWFjcm8gZGlmZmVyZW5jZXMgaGFzIGFnYWluc3QgdmlydHVhbC1ob3N0IHByb2Zp bGU/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5CZXN0IHJlZ2FyZHM8L2Rpdj48ZGl2PmE8L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkRhdGU6Jm5ic3A7PGEgaHJlZj0i Y2FsZW5kYXI6VDc6TW9uLCA2IEphbiAyMDE0IDIyOjA5OjQ0Ij5Nb24sIDYgSmFuIDIwMTQgMjI6 MDk6NDQ8L2E+Jm5ic3A7KzAwMDA8YnI+RnJvbTogVGVkIE1pbGxlciAmbHQ7PGEgaHJlZj0ibWFp bHRvOnRtaWxsZXJAaGNqYi5vcmciPnRtaWxsZXJAaGNqYi5vcmc8L2E+Jmd0Ozxicj5Ubzogb1Zp cnQgTWFpbGluZyBMaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86dXNlcnNAb3ZpcnQub3JnIj51c2Vy c0BvdmlydC5vcmc8L2E+Jmd0Ozxicj5TdWJqZWN0OiBbVXNlcnNdIHR1bmVkIHByb2ZpbGUgZm9y IENlbnRvcyBob3N0cyAtLSBuZXcgQnVnemlsbGEgb3I8YnI+UmVncmVzc2lvbjxicj5NZXNzYWdl LUlEOjxicj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmE1ODRlZTFjMGQ0ZTQwYTJhZTI5NWNmMjMxMTE2 MjhiQERNMlBSMDVNQjMyMC5uYW1wcmQwNS5wcm9kLm91dGxvb2suY29tIj5hNTg0ZWUxYzBkNGU0 MGEyYWUyOTVjZjIzMTExNjI4YkBETTJQUjA1TUIzMjAubmFtcHJkMDUucHJvZC5vdXRsb29rLmNv bTwvYT4mZ3Q7PGJyPjxicj5Db250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InVzLWFz Y2lpIjxicj48YnI+SSBwb3N0ZWQgYSBzY3JpcHQgKGEgd2hpbGUgYmFjaykgdG8gZ2V0IG9WaXJ0 IHJ1bm5pbmcgb24gQ2VudG9zIGhvc3RzLjxicj48YnI+T25lIG9mIHRoZSBpdGVtcyBpbiBpdCBo YXMgdG8gZG8gd2l0aCB3aGF0ICJ0dW5lZCIgcHJvZmlsZSB0byB1c2UuJm5ic3A7IEF0IHRoZSB0 aW1lIEkgZmlyc3QgcmFuIGludG8gaXQsIHRoaXMgd2FzIGEgZmF0YWwgZXJyb3IuJm5ic3A7IEl0 IGlzIG5vdyBqdXN0IGEgd2FybmluZywgc28gaXQgZG9lcyBub3QgcHJldmVudCBpbnN0YWxsaW5n IGEgaG9zdC4mbmJzcDsgQnV0LCBhcyBhIHdhcm5pbmcsIGEgbG90IG9mIHBlb3BsZSBhcmUgcHJv YmFibHkgbWlzc2luZyBpdC48YnI+PGJyPldoZW4gdXNpbmcgQ2VudG9zIDYgYXMgdGhlIGhvc3Qg T1MsIHRoZSBzY3JpcHQgdHJpZXMgdG8gaW5zdGFsbCBhICJyaHMtdmlydHVhbGl6YXRpb24iIHBy b2ZpbGUuJm5ic3A7IFRoYXQgcHJvZmlsZSBpcyBub3QgaW5jbHVkZWQgaW4gQ2VudG9zLiZuYnNw OyBJIHN1YnN0aXR1dGVkIHRoZSAidmlydHVhbC1ob3N0IiBwcm9maWxlLjxicj48YnI+SSBiZWxp ZXZlIHRoYXQgdGhpcyBtYXkgYmUgYSByZWdyZXNzaW9uIGFzIGEgcmVzdWx0IG9mIEJ1Z3ppbGxh IDk4NzI5MyZsdDs8YSBocmVmPSJodHRwczovL2J1Z3ppbGxhLnJlZGhhdC5jb20vc2hvd19idWcu Y2dpP2lkPTk4NzI5MyUzRSI+aHR0cHM6Ly9idWd6aWxsYS5yZWRoYXQuY29tL3Nob3dfYnVnLmNn aT9pZD05ODcyOTMmZ3Q7PC9hPjssIHdoZXJlICJyaHMtdmlydHVhbGl6YXRpb24iIHdhcyBzdWJz dGl0dXRlZCBmb3IgInZpcnR1YWwtaG9zdCIgZm9yIFJIRVYgKyBSSFMuJm5ic3A7IEkgYW0gZ3Vl c3NpbmcgdGhhdCB3aGF0ZXZlciBpcyB1c2VkIGFzIGEgc3dpdGNoIHRvIGRldGVybWluZSBSSEVW ICsgUkhTIGlzIGFsc28gc2hvdmluZyBDZW50b3MgaW50byB0aGF0IHNhbWUgcGF0aCwgd2hpY2gg aXMgbm90IGFwcHJvcHJpYXRlLjxicj48YnI+TXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byB3cml0 ZSB0aGUgc2NyaXB0IHNvIHRoYXQgaXQgdXNlcyAicmhzLXZpcnR1YWxpemF0aW9uIiB3aGVuIHBy ZXNlbnQsIGFuZCBpZiBpdCBpcyBub3QgcHJlc2VudCwgdGhlbiBpdCBmYWxscyBiYWNrIHRvICJ2 aXJ0dWFsLWhvc3QiLiZuYnNwOyAoSSBkb24ndCBrbm93IHdoYXQgKGlmIGFueSkgZGlmZmVyZW5j ZXMgdGhlcmUgYXJlIGJldHdlZW4gdGhlIHR3byBwcm9maWxlcy4pPGJyPjxicj5TaG91bGQgSSBv cGVuIGEgbmV3IGJ1ZywgbWFrZSBhIGNvbW1lbnQgb24gOTg3MjkzLCBvciB0YWtlIHNvbWUgb3Ro ZXIgcGF0aD88YnI+PGJyPlRlZCBNaWxsZXI8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMDAlIj5JbnZp YXRvIGRhIFRhYmxldCBTYW1zdW5nPC9kaXY+PC9kaXY+PC9kaXY+IDwvYm9keT4= ----_com.android.email_973242271645170--

4 3

Re: [Users] R: tuned profile for Centos hosts -- new Bugzilla orRegression
by Doron Fediuck 08 Jan '14

08 Jan '14

----_com.android.email_981017113614690 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 WWVzIEthcmxpLApUaGVzZSBhcmUgZGlmZmVyZW50IGRhZW1vbnMuwqAKCgoKLS0tLS0tLS0g15TX ldeT16LXlCDXnten15XXqNeZ16ogLS0tLS0tLS0K157XkNeqOiBLYXJsaSBTasO2YmVyZyA8S2Fy bGkuU2pvYmVyZ0BzbHUuc2U+IArXqteQ16jXmdeaOjA4LzAxLzIwMTQgIDA4OjQ0ICAoR01UKzAy OjAwKSAK15DXnDogZGZlZGl1Y2tAcmVkaGF0LmNvbSAK16LXldeq16c6IGFtZWRlb0Bvc2NlcnQu bmV0LHVzZXJzQG92aXJ0Lm9yZyx0bWlsbGVyQGhjamIub3JnIArXoNeV16nXkDogUmU6IFtVc2Vy c10gUjogdHVuZWQgcHJvZmlsZSBmb3IgQ2VudG9zIGhvc3RzIC0tIG5ldyBCdWd6aWxsYSBvclJl Z3Jlc3Npb24gCgpvbnMgMjAxNC0wMS0wOCBrbG9ja2FuIDAxOjM1IC0wNTAwIHNrcmV2IERvcm9u IEZlZGl1Y2s6Cj4gSGkgZ3V5cywgCj4gQXMgZmFyIGFzIEkga25vdywgdHVuZWQgaXMgbm90IGF2 YWlsYWJsZSBpbiBjZW50b3MuIFNvIHdlIGZpcnN0IG5lZWQKPiB0byB2ZXJpZnkgdHVuZWQgZXhp c3RzLgoKQXJlICJrc210dW5lZCIgYW5kICJ0dW5lZCIgZGlmZmVyZW50PwojIGNhdCAvZXRjL3Jl ZGhhdC1yZWxlYXNlIApDZW50T1MgcmVsZWFzZSA2LjUgKEZpbmFsKQojIHNlcnZpY2UgLS1zdGF0 dXMtYWxsIHwgZ3JlcCB0dW5lZAprc210dW5lZCAocGlkwqAgMTA0MzgpIGlzIHJ1bm5pbmcuLi4K IyBjaGtjb25maWcgfCBncmVwIHR1bmVkCmtzbXR1bmVkwqDCoMKgwqDCoMKgIDA6b2ZmCTE6b2Zm CTI6b2ZmCTM6b24JNDpvbgk1Om9uCTY6b2ZmCgovSwoKPiBPbmNlIGF2YWlsYWJsZSwgd2UnbGwg YmUgYWJsZSB0byBoYW5kbGUKPiB0aGUgcmVsZXZhbnQgcHJvZmlsZXMgZm9yIGh5cGVydmlzb3Jz Lgo+IAo+IAo+IENhbiBhbnlvbmUgY29uZmlybSB0dW5lZCBhdmFpbGFiaWxpdHkgb24gY2VudG9z Pwo+IAo+IAo8LS0tLS0tLS0g15TXldeT16LXlCDXnten15XXqNeZ16ogLS0tLS0tLS0KPNee15DX qjogQW1lZGVvIFNhbHZhdGkgCjzXqteQ16jXmdeaOjA4LzAxLzIwMTQgMDA6MzIgKEdNVCswMjow MCkgCjzXkNecOiB1c2Vyc0BvdmlydC5vcmcsdG1pbGxlckBoY2piLm9yZyAKPNeg15XXqdeQOiBb VXNlcnNdIFI6IHR1bmVkIHByb2ZpbGUgZm9yIENlbnRvcyBob3N0cyAtLSBuZXcgQnVnemlsbGEK PG9yUmVncmVzc2lvbiAKPiAKPiBIaSBUZWQsCj4gCj4gCj4gSSdtIGludGVyZXN0ZWQgdG8gb24g dGhpcyB0dW5lZCByaHMtdmlydHVhbGl6YXRpb24gcHJvZmlsZS4uLiB3aGVyZSBJCj4gY2FuIGZp bmQgaXQ/IEFuZCB3aGF0IG1hY3JvIGRpZmZlcmVuY2VzIGhhcyBhZ2FpbnN0IHZpcnR1YWwtaG9z dAo+IHByb2ZpbGU/Cj4gCj4gCj4gQmVzdCByZWdhcmRzCj4gYQo+IAo+IAo+IAo+IAo+IERhdGU6 IE1vbiwgNiBKYW4gMjAxNCAyMjowOTo0NCArMDAwMAo+IEZyb206IFRlZCBNaWxsZXIgPHRtaWxs ZXJAaGNqYi5vcmc+Cj4gVG86IG9WaXJ0IE1haWxpbmcgTGlzdCA8dXNlcnNAb3ZpcnQub3JnPgo+ IFN1YmplY3Q6IFtVc2Vyc10gdHVuZWQgcHJvZmlsZSBmb3IgQ2VudG9zIGhvc3RzIC0tIG5ldyBC dWd6aWxsYSBvcgo+IFJlZ3Jlc3Npb24KPiBNZXNzYWdlLUlEOgo+IDxhNTg0ZWUxYzBkNGU0MGEy YWUyOTVjZjIzMTExNjI4YkBETTJQUjA1TUIzMjAubmFtcHJkMDUucHJvZC5vdXRsb29rLmNvbT4K PiAKPiBDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InVzLWFzY2lpIgo+IAo+IEkg cG9zdGVkIGEgc2NyaXB0IChhIHdoaWxlIGJhY2spIHRvIGdldCBvVmlydCBydW5uaW5nIG9uIENl bnRvcyBob3N0cy4KPiAKPiBPbmUgb2YgdGhlIGl0ZW1zIGluIGl0IGhhcyB0byBkbyB3aXRoIHdo YXQgInR1bmVkIiBwcm9maWxlIHRvIHVzZS7CoCBBdAo+IHRoZSB0aW1lIEkgZmlyc3QgcmFuIGlu dG8gaXQsIHRoaXMgd2FzIGEgZmF0YWwgZXJyb3IuwqAgSXQgaXMgbm93IGp1c3QKPiBhIHdhcm5p bmcsIHNvIGl0IGRvZXMgbm90IHByZXZlbnQgaW5zdGFsbGluZyBhIGhvc3QuwqAgQnV0LCBhcyBh Cj4gd2FybmluZywgYSBsb3Qgb2YgcGVvcGxlIGFyZSBwcm9iYWJseSBtaXNzaW5nIGl0Lgo+IAo+ IFdoZW4gdXNpbmcgQ2VudG9zIDYgYXMgdGhlIGhvc3QgT1MsIHRoZSBzY3JpcHQgdHJpZXMgdG8g aW5zdGFsbCBhCj4gInJocy12aXJ0dWFsaXphdGlvbiIgcHJvZmlsZS7CoCBUaGF0IHByb2ZpbGUg aXMgbm90IGluY2x1ZGVkIGluIENlbnRvcy4KPiBJIHN1YnN0aXR1dGVkIHRoZSAidmlydHVhbC1o b3N0IiBwcm9maWxlLgo+IAo+IEkgYmVsaWV2ZSB0aGF0IHRoaXMgbWF5IGJlIGEgcmVncmVzc2lv biBhcyBhIHJlc3VsdCBvZiBCdWd6aWxsYQo+IDk4NzI5MzxodHRwczovL2J1Z3ppbGxhLnJlZGhh dC5jb20vc2hvd19idWcuY2dpP2lkPTk4NzI5Mz47LCB3aGVyZQo+ICJyaHMtdmlydHVhbGl6YXRp b24iIHdhcyBzdWJzdGl0dXRlZCBmb3IgInZpcnR1YWwtaG9zdCIgZm9yIFJIRVYgKwo+IFJIUy7C oCBJIGFtIGd1ZXNzaW5nIHRoYXQgd2hhdGV2ZXIgaXMgdXNlZCBhcyBhIHN3aXRjaCB0byBkZXRl cm1pbmUKPiBSSEVWICsgUkhTIGlzIGFsc28gc2hvdmluZyBDZW50b3MgaW50byB0aGF0IHNhbWUg cGF0aCwgd2hpY2ggaXMgbm90Cj4gYXBwcm9wcmlhdGUuCj4gCj4gTXkgc3VnZ2VzdGlvbiB3b3Vs ZCBiZSB0byB3cml0ZSB0aGUgc2NyaXB0IHNvIHRoYXQgaXQgdXNlcwo+ICJyaHMtdmlydHVhbGl6 YXRpb24iIHdoZW4gcHJlc2VudCwgYW5kIGlmIGl0IGlzIG5vdCBwcmVzZW50LCB0aGVuIGl0Cj4g ZmFsbHMgYmFjayB0byAidmlydHVhbC1ob3N0Ii7CoCAoSSBkb24ndCBrbm93IHdoYXQgKGlmIGFu eSkgZGlmZmVyZW5jZXMKPiB0aGVyZSBhcmUgYmV0d2VlbiB0aGUgdHdvIHByb2ZpbGVzLikKPiAK PiBTaG91bGQgSSBvcGVuIGEgbmV3IGJ1ZywgbWFrZSBhIGNvbW1lbnQgb24gOTg3MjkzLCBvciB0 YWtlIHNvbWUgb3RoZXIKPiBwYXRoPwo+IAo+IFRlZCBNaWxsZXIKPiAKPiAKPiAKPiAKPiAKPiAK PiBJbnZpYXRvIGRhIFRhYmxldCBTYW1zdW5nCgotLSAKCk1lZCBWw6RubGlnYSBIw6Rsc25pbmdh cgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpLYXJsaSBTasO2YmVyZwpTd2VkaXNoIFVuaXZlcnNp dHkgb2YgQWdyaWN1bHR1cmFsIFNjaWVuY2VzIEJveCA3MDc5IChWaXNpdGluZyBBZGRyZXNzCkty b27DpXN2w6RnZW4gOCkKUy03NTAgMDcgVXBwc2FsYSwgU3dlZGVuClBob25lOsKgICs0Ni0oMCkx OC02NyAxNSA2NgprYXJsaS5zam9iZXJnQHNsdS5zZQoK ----_com.android.email_981017113614690 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj48ZGl2PlllcyBLYXJsaSw8 L2Rpdj48ZGl2PlRoZXNlIGFyZSBkaWZmZXJlbnQgZGFlbW9ucy4mbmJzcDs8L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2PjwvZGl2PjwvZGl2Pjxicj48YnI+LS0tLS0tLS0g15TXldeT16LXlCDXnten 15XXqNeZ16ogLS0tLS0tLS08YnI+157XkNeqOiBLYXJsaSBTasO2YmVyZyA8S2FybGkuU2pvYmVy Z0BzbHUuc2U+IDxicj7XqteQ16jXmdeaOjA4LzAxLzIwMTQgIDA4OjQ0ICAoR01UKzAyOjAwKSA8 YnI+15DXnDogZGZlZGl1Y2tAcmVkaGF0LmNvbSA8YnI+16LXldeq16c6IGFtZWRlb0Bvc2NlcnQu bmV0LHVzZXJzQG92aXJ0Lm9yZyx0bWlsbGVyQGhjamIub3JnIDxicj7XoNeV16nXkDogUmU6IFtV c2Vyc10gUjogdHVuZWQgcHJvZmlsZSBmb3IgQ2VudG9zIGhvc3RzIC0tIG5ldyBCdWd6aWxsYSBv clJlZ3Jlc3Npb24gPGJyPjxicj5vbnMgMjAxNC0wMS0wOCBrbG9ja2FuIDAxOjM1IC0wNTAwIHNr cmV2IERvcm9uIEZlZGl1Y2s6PGJyPiZndDsgSGkgZ3V5cywgPGJyPiZndDsgQXMgZmFyIGFzIEkg a25vdywgdHVuZWQgaXMgbm90IGF2YWlsYWJsZSBpbiBjZW50b3MuIFNvIHdlIGZpcnN0IG5lZWQ8 YnI+Jmd0OyB0byB2ZXJpZnkgdHVuZWQgZXhpc3RzLjxicj48YnI+QXJlICJrc210dW5lZCIgYW5k ICJ0dW5lZCIgZGlmZmVyZW50Pzxicj4jIGNhdCAvZXRjL3JlZGhhdC1yZWxlYXNlIDxicj5DZW50 T1MgcmVsZWFzZSA2LjUgKEZpbmFsKTxicj4jIHNlcnZpY2UgLS1zdGF0dXMtYWxsIHwgZ3JlcCB0 dW5lZDxicj5rc210dW5lZCAocGlkJm5ic3A7IDEwNDM4KSBpcyBydW5uaW5nLi4uPGJyPiMgY2hr Y29uZmlnIHwgZ3JlcCB0dW5lZDxicj5rc210dW5lZCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAJMDpvZmYJMTpvZmYJMjpvZmYJMzpvbgk0Om9uCTU6b24JNjpvZmY8YnI+PGJy Pi9LPGJyPjxicj4mZ3Q7IE9uY2UgYXZhaWxhYmxlLCB3ZSdsbCBiZSBhYmxlIHRvIGhhbmRsZTxi cj4mZ3Q7IHRoZSByZWxldmFudCBwcm9maWxlcyBmb3IgaHlwZXJ2aXNvcnMuPGJyPiZndDsgPGJy PiZndDsgPGJyPiZndDsgQ2FuIGFueW9uZSBjb25maXJtIHR1bmVkIGF2YWlsYWJpbGl0eSBvbiBj ZW50b3M/PGJyPiZndDsgPGJyPiZndDsgPGJyPiAmbHQ7LS0tLS0tLS0g15TXldeT16LXlCDXnten 15XXqNeZ16ogLS0tLS0tLS08YnI+ICZsdDvXnteQ16o6IEFtZWRlbyBTYWx2YXRpIDxicj4gJmx0 O9eq15DXqNeZ15o6MDgvMDEvMjAxNCAwMDozMiAoR01UKzAyOjAwKSA8YnI+ICZsdDvXkNecOiB1 c2Vyc0BvdmlydC5vcmcsdG1pbGxlckBoY2piLm9yZyA8YnI+ICZsdDvXoNeV16nXkDogW1VzZXJz XSBSOiB0dW5lZCBwcm9maWxlIGZvciBDZW50b3MgaG9zdHMgLS0gbmV3IEJ1Z3ppbGxhPGJyPiAm bHQ7b3JSZWdyZXNzaW9uIDxicj4mZ3Q7IDxicj4mZ3Q7IEhpIFRlZCw8YnI+Jmd0OyA8YnI+Jmd0 OyA8YnI+Jmd0OyBJJ20gaW50ZXJlc3RlZCB0byBvbiB0aGlzIHR1bmVkIHJocy12aXJ0dWFsaXph dGlvbiBwcm9maWxlLi4uIHdoZXJlIEk8YnI+Jmd0OyBjYW4gZmluZCBpdD8gQW5kIHdoYXQgbWFj cm8gZGlmZmVyZW5jZXMgaGFzIGFnYWluc3QgdmlydHVhbC1ob3N0PGJyPiZndDsgcHJvZmlsZT88 YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyBCZXN0IHJlZ2FyZHM8YnI+Jmd0OyBhPGJyPiZndDsg PGJyPiZndDsgPGJyPiZndDsgPGJyPiZndDsgPGJyPiZndDsgRGF0ZTogTW9uLCA2IEphbiAyMDE0 IDIyOjA5OjQ0ICswMDAwPGJyPiZndDsgRnJvbTogVGVkIE1pbGxlciAmbHQ7dG1pbGxlckBoY2pi Lm9yZyZndDs8YnI+Jmd0OyBUbzogb1ZpcnQgTWFpbGluZyBMaXN0ICZsdDt1c2Vyc0BvdmlydC5v cmcmZ3Q7PGJyPiZndDsgU3ViamVjdDogW1VzZXJzXSB0dW5lZCBwcm9maWxlIGZvciBDZW50b3Mg aG9zdHMgLS0gbmV3IEJ1Z3ppbGxhIG9yPGJyPiZndDsgUmVncmVzc2lvbjxicj4mZ3Q7IE1lc3Nh Z2UtSUQ6PGJyPiZndDsgJmx0O2E1ODRlZTFjMGQ0ZTQwYTJhZTI5NWNmMjMxMTE2MjhiQERNMlBS MDVNQjMyMC5uYW1wcmQwNS5wcm9kLm91dGxvb2suY29tJmd0Ozxicj4mZ3Q7IDxicj4mZ3Q7IENv bnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNjaWkiPGJyPiZndDsgPGJyPiZn dDsgSSBwb3N0ZWQgYSBzY3JpcHQgKGEgd2hpbGUgYmFjaykgdG8gZ2V0IG9WaXJ0IHJ1bm5pbmcg b24gQ2VudG9zIGhvc3RzLjxicj4mZ3Q7IDxicj4mZ3Q7IE9uZSBvZiB0aGUgaXRlbXMgaW4gaXQg aGFzIHRvIGRvIHdpdGggd2hhdCAidHVuZWQiIHByb2ZpbGUgdG8gdXNlLiZuYnNwOyBBdDxicj4m Z3Q7IHRoZSB0aW1lIEkgZmlyc3QgcmFuIGludG8gaXQsIHRoaXMgd2FzIGEgZmF0YWwgZXJyb3Iu Jm5ic3A7IEl0IGlzIG5vdyBqdXN0PGJyPiZndDsgYSB3YXJuaW5nLCBzbyBpdCBkb2VzIG5vdCBw cmV2ZW50IGluc3RhbGxpbmcgYSBob3N0LiZuYnNwOyBCdXQsIGFzIGE8YnI+Jmd0OyB3YXJuaW5n LCBhIGxvdCBvZiBwZW9wbGUgYXJlIHByb2JhYmx5IG1pc3NpbmcgaXQuPGJyPiZndDsgPGJyPiZn dDsgV2hlbiB1c2luZyBDZW50b3MgNiBhcyB0aGUgaG9zdCBPUywgdGhlIHNjcmlwdCB0cmllcyB0 byBpbnN0YWxsIGE8YnI+Jmd0OyAicmhzLXZpcnR1YWxpemF0aW9uIiBwcm9maWxlLiZuYnNwOyBU aGF0IHByb2ZpbGUgaXMgbm90IGluY2x1ZGVkIGluIENlbnRvcy48YnI+Jmd0OyBJIHN1YnN0aXR1 dGVkIHRoZSAidmlydHVhbC1ob3N0IiBwcm9maWxlLjxicj4mZ3Q7IDxicj4mZ3Q7IEkgYmVsaWV2 ZSB0aGF0IHRoaXMgbWF5IGJlIGEgcmVncmVzc2lvbiBhcyBhIHJlc3VsdCBvZiBCdWd6aWxsYTxi cj4mZ3Q7IDk4NzI5MyZsdDtodHRwczovL2J1Z3ppbGxhLnJlZGhhdC5jb20vc2hvd19idWcuY2dp P2lkPTk4NzI5MyZndDs7LCB3aGVyZTxicj4mZ3Q7ICJyaHMtdmlydHVhbGl6YXRpb24iIHdhcyBz dWJzdGl0dXRlZCBmb3IgInZpcnR1YWwtaG9zdCIgZm9yIFJIRVYgKzxicj4mZ3Q7IFJIUy4mbmJz cDsgSSBhbSBndWVzc2luZyB0aGF0IHdoYXRldmVyIGlzIHVzZWQgYXMgYSBzd2l0Y2ggdG8gZGV0 ZXJtaW5lPGJyPiZndDsgUkhFViArIFJIUyBpcyBhbHNvIHNob3ZpbmcgQ2VudG9zIGludG8gdGhh dCBzYW1lIHBhdGgsIHdoaWNoIGlzIG5vdDxicj4mZ3Q7IGFwcHJvcHJpYXRlLjxicj4mZ3Q7IDxi cj4mZ3Q7IE15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gd3JpdGUgdGhlIHNjcmlwdCBzbyB0aGF0 IGl0IHVzZXM8YnI+Jmd0OyAicmhzLXZpcnR1YWxpemF0aW9uIiB3aGVuIHByZXNlbnQsIGFuZCBp ZiBpdCBpcyBub3QgcHJlc2VudCwgdGhlbiBpdDxicj4mZ3Q7IGZhbGxzIGJhY2sgdG8gInZpcnR1 YWwtaG9zdCIuJm5ic3A7IChJIGRvbid0IGtub3cgd2hhdCAoaWYgYW55KSBkaWZmZXJlbmNlczxi cj4mZ3Q7IHRoZXJlIGFyZSBiZXR3ZWVuIHRoZSB0d28gcHJvZmlsZXMuKTxicj4mZ3Q7IDxicj4m Z3Q7IFNob3VsZCBJIG9wZW4gYSBuZXcgYnVnLCBtYWtlIGEgY29tbWVudCBvbiA5ODcyOTMsIG9y IHRha2Ugc29tZSBvdGhlcjxicj4mZ3Q7IHBhdGg/PGJyPiZndDsgPGJyPiZndDsgVGVkIE1pbGxl cjxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7IDxi cj4mZ3Q7IEludmlhdG8gZGEgVGFibGV0IFNhbXN1bmc8YnI+PGJyPi0tIDxicj48YnI+TWVkIFbD pG5saWdhIEjDpGxzbmluZ2FyPGJyPjxicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPkthcmxp IFNqw7ZiZXJnPGJyPlN3ZWRpc2ggVW5pdmVyc2l0eSBvZiBBZ3JpY3VsdHVyYWwgU2NpZW5jZXMg Qm94IDcwNzkgKFZpc2l0aW5nIEFkZHJlc3M8YnI+S3JvbsOlc3bDpGdlbiA4KTxicj5TLTc1MCAw NyBVcHBzYWxhLCBTd2VkZW48YnI+UGhvbmU6Jm5ic3A7ICs0Ni0oMCkxOC02NyAxNSA2Njxicj5r YXJsaS5zam9iZXJnQHNsdS5zZTxkaXY+PGJyPjwvZGl2PjwvYm9keT4= ----_com.android.email_981017113614690--

1 0

[Users] oVirt Node 3.0.3-1 for oVirt 3.3 release
by Nauman Abbas 08 Jan '14

08 Jan '14

Hello there Did you find a solution to this problem you mentioned on oVirt list few days ago since I'm facing the same now. http://lists.ovirt.org/pipermail/users/2013-December/018323.html Regards Nauman Abbas Assistant System Administrator (LMS), Room No. A-207, SEECS, National University of Sciences & Technology, + 92 321 5359946

2 2

[Users] R: tuned profile for Centos hosts -- new Bugzilla orRegression
by Amedeo Salvati 07 Jan '14

07 Jan '14

----_com.android.email_110597815659370 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgVGVkLAoKSSdtIGludGVyZXN0ZWQgdG8gb24gdGhpcyB0dW5lZCByaHMtdmlydHVhbGl6YXRp b24gcHJvZmlsZS4uLiB3aGVyZSBJIGNhbiBmaW5kIGl0PyBBbmQgd2hhdCBtYWNybyBkaWZmZXJl bmNlcyBoYXMgYWdhaW5zdCB2aXJ0dWFsLWhvc3QgcHJvZmlsZT8KCkJlc3QgcmVnYXJkcwphCgoK RGF0ZTrCoE1vbiwgNiBKYW4gMjAxNCAyMjowOTo0NMKgKzAwMDAKRnJvbTogVGVkIE1pbGxlciA8 dG1pbGxlckBoY2piLm9yZz4KVG86IG9WaXJ0IE1haWxpbmcgTGlzdCA8dXNlcnNAb3ZpcnQub3Jn PgpTdWJqZWN0OiBbVXNlcnNdIHR1bmVkIHByb2ZpbGUgZm9yIENlbnRvcyBob3N0cyAtLSBuZXcg QnVnemlsbGEgb3IKUmVncmVzc2lvbgpNZXNzYWdlLUlEOgo8YTU4NGVlMWMwZDRlNDBhMmFlMjk1 Y2YyMzExMTYyOGJARE0yUFIwNU1CMzIwLm5hbXByZDA1LnByb2Qub3V0bG9vay5jb20+CgpDb250 ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InVzLWFzY2lpIgoKSSBwb3N0ZWQgYSBzY3Jp cHQgKGEgd2hpbGUgYmFjaykgdG8gZ2V0IG9WaXJ0IHJ1bm5pbmcgb24gQ2VudG9zIGhvc3RzLgoK T25lIG9mIHRoZSBpdGVtcyBpbiBpdCBoYXMgdG8gZG8gd2l0aCB3aGF0ICJ0dW5lZCIgcHJvZmls ZSB0byB1c2UuwqAgQXQgdGhlIHRpbWUgSSBmaXJzdCByYW4gaW50byBpdCwgdGhpcyB3YXMgYSBm YXRhbCBlcnJvci7CoCBJdCBpcyBub3cganVzdCBhIHdhcm5pbmcsIHNvIGl0IGRvZXMgbm90IHBy ZXZlbnQgaW5zdGFsbGluZyBhIGhvc3QuwqAgQnV0LCBhcyBhIHdhcm5pbmcsIGEgbG90IG9mIHBl b3BsZSBhcmUgcHJvYmFibHkgbWlzc2luZyBpdC4KCldoZW4gdXNpbmcgQ2VudG9zIDYgYXMgdGhl IGhvc3QgT1MsIHRoZSBzY3JpcHQgdHJpZXMgdG8gaW5zdGFsbCBhICJyaHMtdmlydHVhbGl6YXRp b24iIHByb2ZpbGUuwqAgVGhhdCBwcm9maWxlIGlzIG5vdCBpbmNsdWRlZCBpbiBDZW50b3MuwqAg SSBzdWJzdGl0dXRlZCB0aGUgInZpcnR1YWwtaG9zdCIgcHJvZmlsZS4KCkkgYmVsaWV2ZSB0aGF0 IHRoaXMgbWF5IGJlIGEgcmVncmVzc2lvbiBhcyBhIHJlc3VsdCBvZiBCdWd6aWxsYSA5ODcyOTM8 aHR0cHM6Ly9idWd6aWxsYS5yZWRoYXQuY29tL3Nob3dfYnVnLmNnaT9pZD05ODcyOTM+Oywgd2hl cmUgInJocy12aXJ0dWFsaXphdGlvbiIgd2FzIHN1YnN0aXR1dGVkIGZvciAidmlydHVhbC1ob3N0 IiBmb3IgUkhFViArIFJIUy7CoCBJIGFtIGd1ZXNzaW5nIHRoYXQgd2hhdGV2ZXIgaXMgdXNlZCBh cyBhIHN3aXRjaCB0byBkZXRlcm1pbmUgUkhFViArIFJIUyBpcyBhbHNvIHNob3ZpbmcgQ2VudG9z IGludG8gdGhhdCBzYW1lIHBhdGgsIHdoaWNoIGlzIG5vdCBhcHByb3ByaWF0ZS4KCk15IHN1Z2dl c3Rpb24gd291bGQgYmUgdG8gd3JpdGUgdGhlIHNjcmlwdCBzbyB0aGF0IGl0IHVzZXMgInJocy12 aXJ0dWFsaXphdGlvbiIgd2hlbiBwcmVzZW50LCBhbmQgaWYgaXQgaXMgbm90IHByZXNlbnQsIHRo ZW4gaXQgZmFsbHMgYmFjayB0byAidmlydHVhbC1ob3N0Ii7CoCAoSSBkb24ndCBrbm93IHdoYXQg KGlmIGFueSkgZGlmZmVyZW5jZXMgdGhlcmUgYXJlIGJldHdlZW4gdGhlIHR3byBwcm9maWxlcy4p CgpTaG91bGQgSSBvcGVuIGEgbmV3IGJ1ZywgbWFrZSBhIGNvbW1lbnQgb24gOTg3MjkzLCBvciB0 YWtlIHNvbWUgb3RoZXIgcGF0aD8KClRlZCBNaWxsZXIKCgoKSW52aWF0byBkYSBUYWJsZXQgU2Ft c3VuZw== ----_com.android.email_110597815659370 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5IaSBUZWQsPC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5JJ20gaW50ZXJlc3RlZCB0byBvbiB0aGlzIHR1bmVkIHJocy12aXJ0 dWFsaXphdGlvbiBwcm9maWxlLi4uIHdoZXJlIEkgY2FuIGZpbmQgaXQ/IEFuZCB3aGF0IG1hY3Jv IGRpZmZlcmVuY2VzIGhhcyBhZ2FpbnN0IHZpcnR1YWwtaG9zdCBwcm9maWxlPzwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+QmVzdCByZWdhcmRzPC9kaXY+PGRpdj5hPC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj5EYXRlOiZuYnNwOzxhIGhyZWY9ImNhbGVuZGFyOlQ3Ok1v biwgNiBKYW4gMjAxNCAyMjowOTo0NCI+TW9uLCA2IEphbiAyMDE0IDIyOjA5OjQ0PC9hPiZuYnNw OyswMDAwPGJyPkZyb206IFRlZCBNaWxsZXIgJmx0OzxhIGhyZWY9Im1haWx0bzp0bWlsbGVyQGhj amIub3JnIj50bWlsbGVyQGhjamIub3JnPC9hPiZndDs8YnI+VG86IG9WaXJ0IE1haWxpbmcgTGlz dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnVzZXJzQG92aXJ0Lm9yZyI+dXNlcnNAb3ZpcnQub3JnPC9h PiZndDs8YnI+U3ViamVjdDogW1VzZXJzXSB0dW5lZCBwcm9maWxlIGZvciBDZW50b3MgaG9zdHMg LS0gbmV3IEJ1Z3ppbGxhIG9yPGJyPlJlZ3Jlc3Npb248YnI+TWVzc2FnZS1JRDo8YnI+Jmx0Ozxh IGhyZWY9Im1haWx0bzphNTg0ZWUxYzBkNGU0MGEyYWUyOTVjZjIzMTExNjI4YkBETTJQUjA1TUIz MjAubmFtcHJkMDUucHJvZC5vdXRsb29rLmNvbSI+YTU4NGVlMWMwZDRlNDBhMmFlMjk1Y2YyMzEx MTYyOGJARE0yUFIwNU1CMzIwLm5hbXByZDA1LnByb2Qub3V0bG9vay5jb208L2E+Jmd0Ozxicj48 YnI+Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSI8YnI+PGJyPkkg cG9zdGVkIGEgc2NyaXB0IChhIHdoaWxlIGJhY2spIHRvIGdldCBvVmlydCBydW5uaW5nIG9uIENl bnRvcyBob3N0cy48YnI+PGJyPk9uZSBvZiB0aGUgaXRlbXMgaW4gaXQgaGFzIHRvIGRvIHdpdGgg d2hhdCAidHVuZWQiIHByb2ZpbGUgdG8gdXNlLiZuYnNwOyBBdCB0aGUgdGltZSBJIGZpcnN0IHJh biBpbnRvIGl0LCB0aGlzIHdhcyBhIGZhdGFsIGVycm9yLiZuYnNwOyBJdCBpcyBub3cganVzdCBh IHdhcm5pbmcsIHNvIGl0IGRvZXMgbm90IHByZXZlbnQgaW5zdGFsbGluZyBhIGhvc3QuJm5ic3A7 IEJ1dCwgYXMgYSB3YXJuaW5nLCBhIGxvdCBvZiBwZW9wbGUgYXJlIHByb2JhYmx5IG1pc3Npbmcg aXQuPGJyPjxicj5XaGVuIHVzaW5nIENlbnRvcyA2IGFzIHRoZSBob3N0IE9TLCB0aGUgc2NyaXB0 IHRyaWVzIHRvIGluc3RhbGwgYSAicmhzLXZpcnR1YWxpemF0aW9uIiBwcm9maWxlLiZuYnNwOyBU aGF0IHByb2ZpbGUgaXMgbm90IGluY2x1ZGVkIGluIENlbnRvcy4mbmJzcDsgSSBzdWJzdGl0dXRl ZCB0aGUgInZpcnR1YWwtaG9zdCIgcHJvZmlsZS48YnI+PGJyPkkgYmVsaWV2ZSB0aGF0IHRoaXMg bWF5IGJlIGEgcmVncmVzc2lvbiBhcyBhIHJlc3VsdCBvZiBCdWd6aWxsYSA5ODcyOTMmbHQ7PGEg aHJlZj0iaHR0cHM6Ly9idWd6aWxsYS5yZWRoYXQuY29tL3Nob3dfYnVnLmNnaT9pZD05ODcyOTMl M0UiPmh0dHBzOi8vYnVnemlsbGEucmVkaGF0LmNvbS9zaG93X2J1Zy5jZ2k/aWQ9OTg3MjkzJmd0 OzwvYT47LCB3aGVyZSAicmhzLXZpcnR1YWxpemF0aW9uIiB3YXMgc3Vic3RpdHV0ZWQgZm9yICJ2 aXJ0dWFsLWhvc3QiIGZvciBSSEVWICsgUkhTLiZuYnNwOyBJIGFtIGd1ZXNzaW5nIHRoYXQgd2hh dGV2ZXIgaXMgdXNlZCBhcyBhIHN3aXRjaCB0byBkZXRlcm1pbmUgUkhFViArIFJIUyBpcyBhbHNv IHNob3ZpbmcgQ2VudG9zIGludG8gdGhhdCBzYW1lIHBhdGgsIHdoaWNoIGlzIG5vdCBhcHByb3By aWF0ZS48YnI+PGJyPk15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gd3JpdGUgdGhlIHNjcmlwdCBz byB0aGF0IGl0IHVzZXMgInJocy12aXJ0dWFsaXphdGlvbiIgd2hlbiBwcmVzZW50LCBhbmQgaWYg aXQgaXMgbm90IHByZXNlbnQsIHRoZW4gaXQgZmFsbHMgYmFjayB0byAidmlydHVhbC1ob3N0Ii4m bmJzcDsgKEkgZG9uJ3Qga25vdyB3aGF0IChpZiBhbnkpIGRpZmZlcmVuY2VzIHRoZXJlIGFyZSBi ZXR3ZWVuIHRoZSB0d28gcHJvZmlsZXMuKTxicj48YnI+U2hvdWxkIEkgb3BlbiBhIG5ldyBidWcs IG1ha2UgYSBjb21tZW50IG9uIDk4NzI5Mywgb3IgdGFrZSBzb21lIG90aGVyIHBhdGg/PGJyPjxi cj5UZWQgTWlsbGVyPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJSI+SW52aWF0byBkYSBUYWJsZXQg U2Ftc3VuZzwvZGl2PjwvZGl2PiA8L2JvZHk+PC9odG1sPg== ----_com.android.email_110597815659370--

1 0

[Users] how to temporarily solve low disk space problem preventing start of VM
by Gianluca Cecchi 07 Jan '14

07 Jan '14

Hello, test cluster with two nodes and GlusterFS DC on f19 and 3.3.2, using gluster version 3.4.2 from f19 updates-testing repo. Unfortunately I have only small local disk quite occupied by existing VMs. About 4Gb free. I had VMs started and then I shutdown them. Trying to power on any VM I get: Error while executing action: c6s: Cannot run VM. Low disk space on target Storage Domain gvdata. On SPM node (node02) that is the only one active I have: /dev/mapper/fedora-DATA_GLUSTER 30G 23G 7.8G 75% /gluster/DATA_GLUSTER node01.mydomain:gvdata 30G 26G 4.6G 85% /rhev/data-center/mnt/glusterSD/node01.mydomain:gvdata Can I tweak this low disk warning in any way? How does engine make this kind of check? Thanks in advance Gianluca

2 2

[Users] How delete image in ovirt ?
by Kevin Tibi 07 Jan '14

07 Jan '14

Hi all, i have not found how to delete an image. I uploaded my image with engine-iso-upload. Thx for answer ;) Kevin.

2 2

[Users] Almost there... I can't bring up a VM
by William Kwan 06 Jan '14

06 Jan '14

--1100272424-1777021096-1388684553=:44937 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=0A=0ARunning oVirt 3.3.2-1.el6 on CentOS 6.5=0A=0A=0AI have oVirt insta= lled on a test host (ovirt1) and two test visualization hosts (onode1, onod= e2) using GlusterFS.=A0 I have GlusterFS available on both onode1 and 2.=A0= Storage domain, networks are defined, ISO is uploaded to the ISO domain.= =A0 I have been trying to create VM but all I get is a black spice console = I'm not able to tell what's going on.=A0 I turned off all iptables also.=0A= I looked at /var/log/libvirt/qemu/testvm04.log.=A0 I got only the starting = up line and a few lines for Spice.=A0 I also looked at engine.log for "ERRO= R"=0A=0A=0Acan anyone shed some light on this?=A0 I feel like I'm almost th= ere to use oVirt instead of VMware for the next project.=0A=0A=0AERROR line= s in engine.log:=0A--------------------------------------=0A=0A2014-01-02 1= 2:31:40,893 ERROR [org.ovirt.engine.core.vdsbroker.gluster.GlusterTasksList= VDSCommand] (DefaultQuartzScheduler_Worker-76) Command GlusterTasksListVDS = execution failed. Exception: VDSNetworkException: org.apache.xmlrpc.XmlRpcE= xception: <type 'exceptions.Exception'>:method "glusterTasksList" is not su= pported=0A=A0 [org.ovirt.engine.core.vdsbroker.gluster.GlusterTasksListVDSC= ommand] (DefaultQuartzScheduler_Worker-76) FINISH, GlusterTasksListVDSComma= nd, log id: 3fa83c4f=0A2014-01-02 12:31:40,894 ERROR [org.ovirt.engine.core= .utils.timer.SchedulerUtilQuartzImpl] (DefaultQuartzScheduler_Worker-76) Fa= iled to invoke scheduled method gluster_async_task_poll_event: java.lang.re= flect.InvocationTargetException=0A=A0=A0=A0=A0=A0=A0=A0 at sun.reflect.Gene= ratedMethodAccessor80.invoke(Unknown Source) [:1.7.0_45]=0A=A0=A0=A0=A0=A0= =A0=A0 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodA= ccessorImpl.java:43) [rt.jar:1.7.0_45]=0A=A0=A0=A0=A0=A0=A0=A0 at java.lang= .reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_45]=0A=A0=A0=A0=A0=A0= =A0=A0 at org.ovirt.engine.core.utils.timer.JobWrapper.execute(JobWrapper.j= ava:60) [scheduler.jar:]=0A=A0=A0=A0=A0=A0=A0=A0 at org.quartz.core.JobRunS= hell.run(JobRunShell.java:213) [quartz.jar:]=0A=A0=A0=A0=A0=A0=A0=A0 at org= .quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557) = [quartz.jar:]=0ACaused by: org.ovirt.engine.core.common.errors.VdcBLLExcept= ion: VdcBLLException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkE= xception: org.apache.xmlrpc.XmlRpcException: <type 'exceptions.Exception'>:= method "glusterTasksList" is not supported (Failed with error VDS_NETWORK_E= RROR and code 5022)=0A=A0=A0=A0=A0=A0=A0=A0 at org.ovirt.engine.core.bll.Vd= sHandler.handleVdsResult(VdsHandler.java:122) [bll.jar:]=0A=A0=A0=A0=A0=A0= =A0=A0 at org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.RunVdsCommand(VDS= BrokerFrontendImpl.java:33) [bll.jar:]=0A=A0=A0=A0=A0=A0=A0=A0 at org.ovirt= .engine.core.bll.gluster.tasks.GlusterTasksService.runVdsCommand(GlusterTas= ksService.java:60) [bll.jar:]=0A=A0=A0=A0=A0=A0=A0=A0 at org.ovirt.engine.c= ore.bll.gluster.tasks.GlusterTasksService.getTaskListForCluster(GlusterTask= sService.java:28) [bll.jar:]=0A=A0=A0=A0=A0=A0=A0=A0 at org.ovirt.engine.co= re.bll.gluster.GlusterTasksSyncJob.updateTasksInCluster(GlusterTasksSyncJob= .java:67) [bll.jar:]=0A=A0=A0=A0=A0=A0=A0=A0 at org.ovirt.engine.core.bll.g= luster.GlusterTasksSyncJob.updateGlusterAsyncTasks(GlusterTasksSyncJob.java= :56) [bll.jar:]=0A=A0=A0=A0=A0=A0=A0=A0 ... 6 more=0A=0A=A0 [org.ovirt.engi= ne.core.bll.SetVmTicketCommand] (ajp--127.0.0.1-8702-8) [1d0c71de] Running = command: SetVmTicketCommand internal: false. Entities affected :=A0 ID: b48= 67838-561e-491e-bb00-5c2ce3828b83 Type: VM=0A=A0 [org.ovirt.engine.core.vds= broker.vdsbroker.SetVmTicketVDSCommand] (ajp--127.0.0.1-8702-8) [1d0c71de] = START, SetVmTicketVDSCommand(HostName =3D onode1., HostId =3D 5145362f-0f97= -4edf-a23f-592ff2c74d3f, vmId=3Db4867838-561e-491e-bb00-5c2ce3828b83, ticke= t=3DIpVcENDWEgVN, validTime=3D120,m userName=3Dadmin@internal, userId=3Dfdf= c627c-d875-11e0-90f0-83df133b58cc), log id: 36bcf5a3=0A=A0 [org.ovirt.engin= e.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] (ajp--127.0.0.1-8702-8) [= 1d0c71de] FINISH, SetVmTicketVDSCommand, log id: 36bcf5a3=0A=A0 [org.ovirt.= engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp--127.0.0.1= -8702-8) [1d0c71de] Correlation ID: 1d0c71de, Call Stack: null, Custom Even= t ID: -1, Message: user admin@internal initiated console session for VM tes= tvm04=0A=0A=0Aqemu log:=0A------------=0A=0ALC_ALL=3DC PATH=3D/usr/local/sb= in:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=3Dspice /usr= /libexec/qemu-kvm -name testvm04 -S -M rhel6.4.0 -cpu Westmere -enable-kvm = -m 4096 -realtime mlock=3Doff -smp 2,sockets=3D2,cores=3D1,threads=3D1 -uui= d b4867838-561e-491e-bb00-5c2ce3828b83 -smbios type=3D1,manufacturer=3DoVir= t,product=3DoVirt Node,version=3D6-5.el6.centos.11.2,serial=3D42294BD4-962B= -0F5E-9F28-0A96F491CB56,uuid=3Db4867838-561e-491e-bb00-5c2ce3828b83 -nodefc= onfig -nodefaults -chardev socket,id=3Dcharmonitor,path=3D/var/lib/libvirt/= qemu/testvm04.monitor,server,nowait -mon chardev=3Dcharmonitor,id=3Dmonitor= ,mode=3Dcontrol -rtc base=3D2014-01-02T17:11:07,driftfix=3Dslew -no-shutdow= n -device piix3-usb-uhci,id=3Dusb,bus=3Dpci.0,addr=3D0x1.0x2 -device virtio= -scsi-pci,id=3Dscsi0,bus=3Dpci.0,addr=3D0x4 -device virtio-serial-pci,id=3D= virtio-serial0,bus=3Dpci.0,addr=3D0x5 -drive file=3D/rhev/data-center/mnt/ovirt1:_data_iso/347d8614-f509-4887-b4ae-4dc4= bbc30604/images/11111111-1111-1111-1111-111111111111/CentOS-6.5-x86_64-bin-= DVD1.iso,if=3Dnone,media=3Dcdrom,id=3Ddrive-ide0-1-0,readonly=3Don,format= =3Draw,serial=3D -device ide-drive,bus=3Dide.1,unit=3D0,drive=3Ddrive-ide0-= 1-0,id=3Dide0-1-0,bootindex=3D2 -drive file=3D/rhev/data-center/mnt/gluster= SD/onode1:kvm1/83e1f2f9-40ab-4a01-bba5-87ac52ef791e/images/d652b29d-4030-42= 84-a7c9-2ec9442dda5c/84122d99-fe4e-45a3-94fa-28cdb23a4e0d,if=3Dnone,id=3Ddr= ive-virtio-disk0,format=3Draw,serial=3Dd652b29d-4030-4284-a7c9-2ec9442dda5c= ,cache=3Dnone,werror=3Dstop,rerror=3Dstop,aio=3Dthreads -device virtio-blk-= pci,scsi=3Doff,bus=3Dpci.0,addr=3D0x6,drive=3Ddrive-virtio-disk0,id=3Dvirti= o-disk0 -netdev tap,fd=3D26,id=3Dhostnet0,vhost=3Don,vhostfd=3D27 -device v= irtio-net-pci,netdev=3Dhostnet0,id=3Dnet0,mac=3D00:1a:4a:43:a1:4d,bus=3Dpci= .0,addr=3D0x3,bootindex=3D1 -chardev socket,id=3Dcharchannel0,path=3D/var/lib/libvirt/qemu/channels/b4867838-56= 1e-491e-bb00-5c2ce3828b83.com.redhat.rhevm.vdsm,server,nowait -device virts= erialport,bus=3Dvirtio-serial0.0,nr=3D1,chardev=3Dcharchannel0,id=3Dchannel= 0,name=3Dcom.redhat.rhevm.vdsm -chardev socket,id=3Dcharchannel1,path=3D/va= r/lib/libvirt/qemu/channels/b4867838-561e-491e-bb00-5c2ce3828b83.org.qemu.g= uest_agent.0,server,nowait -device virtserialport,bus=3Dvirtio-serial0.0,nr= =3D2,chardev=3Dcharchannel1,id=3Dchannel1,name=3Dorg.qemu.guest_agent.0 -ch= ardev spicevmc,id=3Dcharchannel2,name=3Dvdagent -device virtserialport,bus= =3Dvirtio-serial0.0,nr=3D3,chardev=3Dcharchannel2,id=3Dchannel2,name=3Dcom.= redhat.spice.0 -chardev pty,id=3Dcharconsole0 -device virtconsole,chardev= =3Dcharconsole0,id=3Dconsole0 -spice port=3D5900,tls-port=3D5901,addr=3D0,x509-dir=3D/etc/pki/vdsm/libvirt-spic= e,tls-channel=3Dmain,tls-channel=3Ddisplay,tls-channel=3Dinputs,tls-channel= =3Dcursor,tls-channel=3Dplayback,tls-channel=3Drecord,tls-channel=3Dsmartca= rd,tls-channel=3Dusbredir,seamless-migration=3Don -k en-us -vga qxl -global= qxl-vga.ram_size=3D67108864 -global qxl-vga.vram_size=3D33554432 -device v= irtio-balloon-pci,id=3Dballoon0,bus=3Dpci.0,addr=3D0x7=0Achar device redire= cted to /dev/pts/2=0A=0A((null):20150): Spice-Warning **: reds.c:2718:reds_= handle_read_link_done: spice channels 1 should be encrypted=0Amain_channel_= link: add main channel client=0Amain_channel_handle_parsed: net test: laten= cy 2.683000 ms, bitrate 31799267 bps (30.326144 Mbps)=0A((null):20150): Spi= ce-Warning **: reds.c:2718:reds_handle_read_link_done: spice channels 2 sho= uld be encrypted=0A((null):20150): Spice-Warning **: reds.c:2718:reds_handl= e_read_link_done: spice channels 3 should be encrypted=0A((null):20150): Sp= ice-Warning **: reds.c:2718:reds_handle_read_link_done: spice channels 4 sh= ould be encrypted=0Ainputs_connect: inputs channel client create=0Ared_disp= atcher_set_cursor_peer: --1100272424-1777021096-1388684553=:44937 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:He= lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;fo= nt-size:12pt">Hi,<br><br>Running oVirt 3.3.2-1.el6 on CentOS 6.5<br><br><di= v style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue= ,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color:= transparent; font-style: normal;">I have oVirt installed on a test host (o= virt1) and two test visualization hosts (onode1, onode2) using GlusterFS.&n= bsp; I have GlusterFS available on both onode1 and 2.  Storage domain,= networks are defined, ISO is uploaded to the ISO domain.  I have been= trying to create VM but all I get is a black spice console I'm not able to= tell what's going on.  I turned off all iptables also.</div><div styl= e=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helve= tica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><br></div>I looked at /var/log/libvirt/q= emu/testvm04.log.  I got only the starting up line and a few lines for= Spice.  I also looked at engine.log for "ERROR"<br><div style=3D"colo= r: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue= ,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; f= ont-style: normal;"><br></div><div style=3D"color: rgb(0, 0, 0); font-size:= 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Gra= nde,sans-serif; background-color: transparent; font-style: normal;">can any= one shed some light on this?  I feel like I'm almost there to use oVir= t instead of VMware for the next project.<br></div><div style=3D"color: rgb= (0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helve= tica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-st= yle: normal;"><br></div><div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sa= ns-serif; background-color: transparent; font-style: normal;">ERROR lines i= n engine.log:</div><div style=3D"color: rgb(0, 0, 0); font-size: 16px; font= -family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-se= rif; background-color: transparent; font-style: normal;">------------------= --------------------<br></div><div style=3D"color: rgb(0, 0, 0); font-size:= 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Gra= nde,sans-serif; background-color: transparent; font-style: normal;">2014-01= -02 12:31:40,893 ERROR [org.ovirt.engine.core.vdsbroker.gluster.GlusterTask= sListVDSCommand] (DefaultQuartzScheduler_Worker-76) Command GlusterTasksLis= tVDS execution failed. Exception: VDSNetworkException: org.apache.xmlrpc.Xm= lRpcException: <type 'exceptions.Exception'>:method "glusterTasksList= " is not supported<br>  [org.ovirt.engine.core.vdsbroker.gluster.GlusterTasksListVDSCommand] (Defa= ultQuartzScheduler_Worker-76) FINISH, GlusterTasksListVDSCommand, log id: 3= fa83c4f<br>2014-01-02 12:31:40,894 ERROR [org.ovirt.engine.core.utils.timer= .SchedulerUtilQuartzImpl] (DefaultQuartzScheduler_Worker-76) Failed to invo= ke scheduled method gluster_async_task_poll_event: java.lang.reflect.Invoca= tionTargetException<br>        at sun.re= flect.GeneratedMethodAccessor80.invoke(Unknown Source) [:1.7.0_45]<br>&nbsp= ;       at sun.reflect.DelegatingMethodAccess= orImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_45]<br>&n= bsp;       at java.lang.reflect.Method.invoke= (Method.java:606) [rt.jar:1.7.0_45]<br>      =   at org.ovirt.engine.core.utils.timer.JobWrapper.execute(JobWrapper.j= ava:60) [scheduler.jar:]<br>        at org.quar= tz.core.JobRunShell.run(JobRunShell.java:213) [quartz.jar:]<br>  =       at org.quartz.simpl.SimpleThreadPool$WorkerT= hread.run(SimpleThreadPool.java:557) [quartz.jar:]<br>Caused by: org.ovirt.= engine.core.common.errors.VdcBLLException: VdcBLLException: org.ovirt.engin= e.core.vdsbroker.vdsbroker.VDSNetworkException: org.apache.xmlrpc.XmlRpcExc= eption: <type 'exceptions.Exception'>:method "glusterTasksList" is no= t supported (Failed with error VDS_NETWORK_ERROR and code 5022)<br> &n= bsp;      at org.ovirt.engine.core.bll.VdsHandler.= handleVdsResult(VdsHandler.java:122) [bll.jar:]<br>    =     at org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.RunVd= sCommand(VDSBrokerFrontendImpl.java:33) [bll.jar:]<br>   &nb= sp;    at org.ovirt.engine.core.bll.gluster.tasks.GlusterTasksService.runVdsCommand(= GlusterTasksService.java:60) [bll.jar:]<br>     &n= bsp;  at org.ovirt.engine.core.bll.gluster.tasks.GlusterTasksService.g= etTaskListForCluster(GlusterTasksService.java:28) [bll.jar:]<br> &nbsp= ;      at org.ovirt.engine.core.bll.gluster.Gluste= rTasksSyncJob.updateTasksInCluster(GlusterTasksSyncJob.java:67) [bll.jar:]<= br>        at org.ovirt.engine.core.bll.= gluster.GlusterTasksSyncJob.updateGlusterAsyncTasks(GlusterTasksSyncJob.jav= a:56) [bll.jar:]<br>        ... 6 more<b= r><br>  [org.ovirt.engine.core.bll.SetVmTicketCommand] (ajp--127.0.0.1= -8702-8) [1d0c71de] Running command: SetVmTicketCommand internal: false. En= tities affected :  ID: b4867838-561e-491e-bb00-5c2ce3828b83 Type: VM<b= r>  [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] (ajp--12= 7.0.0.1-8702-8) [1d0c71de] START, SetVmTicketVDSCommand(HostName =3D onode1= ., HostId =3D 5145362f-0f97-4edf-a23f-592ff2c74d3f, vmId=3Db4867838-561e-49= 1e-bb00-5c2ce3828b83, ticket=3DIpVcENDWEgVN, validTime=3D120,m userName=3Da= dmin@internal, userId=3Dfdfc627c-d875-11e0-90f0-83df133b58cc), log id: 36bc= f5a3<br>  [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCom= mand] (ajp--127.0.0.1-8702-8) [1d0c71de] FINISH, SetVmTicketVDSCommand, log= id: 36bcf5a3<br>  [org.ovirt.engine.core.dal.dbbroker.auditloghandlin= g.AuditLogDirector] (ajp--127.0.0.1-8702-8) [1d0c71de] Correlation ID: 1d0c= 71de, Call Stack: null, Custom Event ID: -1, Message: user admin@internal i= nitiated console session for VM testvm04<br></div><div style=3D"color: rgb(= 0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvet= ica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-sty= le: normal;"><br></div><div style=3D"color: rgb(0, 0, 0); font-size: 16px; fon= t-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-s= erif; background-color: transparent; font-style: normal;">qemu log:</div><d= iv style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeu= e,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color= : transparent; font-style: normal;">------------<br></div><div style=3D"col= or: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neu= e,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; = font-style: normal;">LC_ALL=3DC PATH=3D/usr/local/sbin:/usr/local/bin:/usr/= bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=3Dspice /usr/libexec/qemu-kvm -name= testvm04 -S -M rhel6.4.0 -cpu Westmere -enable-kvm -m 4096 -realtime mlock= =3Doff -smp 2,sockets=3D2,cores=3D1,threads=3D1 -uuid b4867838-561e-491e-bb= 00-5c2ce3828b83 -smbios type=3D1,manufacturer=3DoVirt,product=3DoVirt Node,version=3D6-5.el6.centos.11.2,serial=3D42294BD4-962B-0F5E-9F28-0A96F4= 91CB56,uuid=3Db4867838-561e-491e-bb00-5c2ce3828b83 -nodefconfig -nodefaults= -chardev socket,id=3Dcharmonitor,path=3D/var/lib/libvirt/qemu/testvm04.mon= itor,server,nowait -mon chardev=3Dcharmonitor,id=3Dmonitor,mode=3Dcontrol -= rtc base=3D2014-01-02T17:11:07,driftfix=3Dslew -no-shutdown -device piix3-u= sb-uhci,id=3Dusb,bus=3Dpci.0,addr=3D0x1.0x2 -device virtio-scsi-pci,id=3Dsc= si0,bus=3Dpci.0,addr=3D0x4 -device virtio-serial-pci,id=3Dvirtio-serial0,bu= s=3Dpci.0,addr=3D0x5 -drive file=3D/rhev/data-center/mnt/ovirt1:_data_iso/3= 47d8614-f509-4887-b4ae-4dc4bbc30604/images/11111111-1111-1111-1111-11111111= 1111/CentOS-6.5-x86_64-bin-DVD1.iso,if=3Dnone,media=3Dcdrom,id=3Ddrive-ide0= -1-0,readonly=3Don,format=3Draw,serial=3D -device ide-drive,bus=3Dide.1,uni= t=3D0,drive=3Ddrive-ide0-1-0,id=3Dide0-1-0,bootindex=3D2 -drive file=3D/rhev/data-center/mnt/glusterSD/onode1:kvm1/83e1f2f9-40ab-4a01-bba5= -87ac52ef791e/images/d652b29d-4030-4284-a7c9-2ec9442dda5c/84122d99-fe4e-45a= 3-94fa-28cdb23a4e0d,if=3Dnone,id=3Ddrive-virtio-disk0,format=3Draw,serial= =3Dd652b29d-4030-4284-a7c9-2ec9442dda5c,cache=3Dnone,werror=3Dstop,rerror= =3Dstop,aio=3Dthreads -device virtio-blk-pci,scsi=3Doff,bus=3Dpci.0,addr=3D= 0x6,drive=3Ddrive-virtio-disk0,id=3Dvirtio-disk0 -netdev tap,fd=3D26,id=3Dh= ostnet0,vhost=3Don,vhostfd=3D27 -device virtio-net-pci,netdev=3Dhostnet0,id= =3Dnet0,mac=3D00:1a:4a:43:a1:4d,bus=3Dpci.0,addr=3D0x3,bootindex=3D1 -chard= ev socket,id=3Dcharchannel0,path=3D/var/lib/libvirt/qemu/channels/b4867838-= 561e-491e-bb00-5c2ce3828b83.com.redhat.rhevm.vdsm,server,nowait -device vir= tserialport,bus=3Dvirtio-serial0.0,nr=3D1,chardev=3Dcharchannel0,id=3Dchann= el0,name=3Dcom.redhat.rhevm.vdsm -chardev socket,id=3Dcharchannel1,path=3D/= var/lib/libvirt/qemu/channels/b4867838-561e-491e-bb00-5c2ce3828b83.org.qemu= .guest_agent.0,server,nowait -device virtserialport,bus=3Dvirtio-serial0.0,nr=3D2,chardev=3Dcharchannel1,id=3Dc= hannel1,name=3Dorg.qemu.guest_agent.0 -chardev spicevmc,id=3Dcharchannel2,n= ame=3Dvdagent -device virtserialport,bus=3Dvirtio-serial0.0,nr=3D3,chardev= =3Dcharchannel2,id=3Dchannel2,name=3Dcom.redhat.spice.0 -chardev pty,id=3Dc= harconsole0 -device virtconsole,chardev=3Dcharconsole0,id=3Dconsole0 -spice= port=3D5900,tls-port=3D5901,addr=3D0,x509-dir=3D/etc/pki/vdsm/libvirt-spic= e,tls-channel=3Dmain,tls-channel=3Ddisplay,tls-channel=3Dinputs,tls-channel= =3Dcursor,tls-channel=3Dplayback,tls-channel=3Drecord,tls-channel=3Dsmartca= rd,tls-channel=3Dusbredir,seamless-migration=3Don -k en-us -vga qxl -global= qxl-vga.ram_size=3D67108864 -global qxl-vga.vram_size=3D33554432 -device v= irtio-balloon-pci,id=3Dballoon0,bus=3Dpci.0,addr=3D0x7<br>char device redir= ected to /dev/pts/2</div><div style=3D"color: rgb(0, 0, 0); font-size: 16px= ; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,s= ans-serif; background-color: transparent; font-style: normal;"><br></div><div style=3D"color: rgb(0, 0, 0); font-size: 16px; fon= t-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-s= erif; background-color: transparent; font-style: normal;">((null):20150): S= pice-Warning **: reds.c:2718:reds_handle_read_link_done: spice channels 1 s= hould be encrypted<br>main_channel_link: add main channel client<br>main_ch= annel_handle_parsed: net test: latency 2.683000 ms, bitrate 31799267 bps (3= 0.326144 Mbps)<br>((null):20150): Spice-Warning **: reds.c:2718:reds_handle= _read_link_done: spice channels 2 should be encrypted<br>((null):20150): Sp= ice-Warning **: reds.c:2718:reds_handle_read_link_done: spice channels 3 sh= ould be encrypted<br>((null):20150): Spice-Warning **: reds.c:2718:reds_han= dle_read_link_done: spice channels 4 should be encrypted<br>inputs_connect:= inputs channel client create<br>red_dispatcher_set_cursor_peer:<br><br></d= iv></div></body></html> --1100272424-1777021096-1388684553=:44937--

3 7

[Users] EL6 Repo error
by Ling Ho 06 Jan '14

06 Jan '14

Hi, I am trying to install the newly put out el6 release and ran into this problem: # yum install http://resources.ovirt.org/releases/ovirt-release-el6-10-1.noarch.rpm Loaded plugins: product-id, refresh-packagekit, rhnplugin, security, : subscription-manager This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. This system is receiving updates from RHN Classic or RHN Satellite. http://ovirt.org/releases/stable/rpm/EL/6Server/repodata/4cd21f91c27c01e374…: [Errno 14] PYCURL ERROR 22 - "The requested URL returned error: 404 Not Found" Trying other mirror. Setting up Install Process ovirt-release-el6-10-1.noarch.rpm | 7.9 kB 00:00 Examining /var/tmp/yum-root-pxJdcB/ovirt-release-el6-10-1.noarch.rpm: ovirt-release-el6-10-1.noarch /var/tmp/yum-root-pxJdcB/ovirt-release-el6-10-1.noarch.rpm: does not update installed package. Error: Nothing to do Can the repodata be rebuilt? Thanks, ... ling

2 4

[Users] Bug? ovirt-guest-agent / Ubuntu
by Sven Kieske 06 Jan '14

06 Jan '14

Hi, I just stumbled upon the following in my guest-agent log on ubuntu 12.04.3 lts server: MainThread::INFO::2014-01-06 14:29:29,106::ovirt-guest-agent::37::root::Starting oVirt guest agent MainThread::ERROR::2014-01-06 14:29:29,107::ovirt-guest-agent::117::root::Unhandled exception in oVirt guest agent! Traceback (most recent call last): File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 111, in <module> agent.run(daemon, pidfile) File "/usr/share/ovirt-guest-agent/ovirt-guest-agent.py", line 42, in run self.agent = LinuxVdsAgent(config) File "/usr/share/ovirt-guest-agent/GuestAgentLinux2.py", line 324, in __init__ AgentLogicBase.__init__(self, config) File "/usr/share/ovirt-guest-agent/OVirtAgentLogic.py", line 90, in __init__ self.vio = VirtIoChannel(config.get("virtio", "device")) File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 150, in __init__ self._stream = VirtIoStream(vport_name) File "/usr/share/ovirt-guest-agent/VirtIoChannel.py", line 131, in __init__ self._vport = os.open(vport_name, os.O_RDWR) OSError: [Errno 24] Too many open files: '/dev/virtio-ports/com.redhat.rhevm.vdsm' Guest agent version is: 1.0.8.201309301944.gitb7f8f2-1p Another question: How to disable the logging from the agent? I just tried to set the following in /etc/ovirt-guest-agent.conf: [handler_logfile] class=handlers.RotatingFileHandler #args=('/var/log/ovirt-guest-agent/ovirt-guest-agent.log', 'a', 100*1024, 5) args=('/dev/null', 'a', 100*1024, 5) and then restarted the service -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

2 3

[Users] python SDK remove VM once the storage is formatted/detached.
by karthik S 06 Jan '14

06 Jan '14

Is there a way to remove VMs entries from rhev manager using python ovirt-sdk "once the storage becomes unavailble" . - Something equivalent to "Remove from Inventory" in Vmware vsphere. ? Currently I get into the postgres db and delete the entries, manually. -Karthik

2 4

[Users] Missing 3.3.2 announcement on ovirt.org
by Sven Kieske 06 Jan '14

06 Jan '14

Hi, On: http://www.ovirt.org/Home there's still 3.3.1. mentioned as the newest version. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

2 1

[Users] Stopping glusterfsd service shut down data center
by Amedeo Salvati 06 Jan '14

06 Jan '14

Hi all, I'm testing ovirt+glusterfs with only two node for all (engine, glusterfs, hypervisors), on centos 6.5 hosts following guide at: http://community.redhat.com/blog/2013/09/up-and-running-with-ovirt-3-3/ http://www.gluster.org/2013/09/ovirt-3-3-glusterized/ but with some change like setting on glusterfs, parameter cluster.server-quorum-ratio to 50% (due to prevent glusterfs to go down if one node goes done) and option on /etc/glusterfs/glusterd.vol "option base-port 50152" (due to libvirt port conflict). So, with the above parameter I was able to stop/reboot node not used to directly mount glusterfs (eg lovhm002), but when I stop/reboot node, that is used to mount glusterfs (eg node lovhm001), all data center goes done, especially when I stop service glusterfsd (not glusterd service!!!), but the glusterfs still alive and is reachable on node lovhm002 that survives but ovirt/libvirt marks DC/storage in error. Do you have any ideas to configure DC/Cluster on ovirt that remains aware if node used to mount glusterfs goes down? This is a sample vdsmd.log on node that remains on-line (lovhm002) when I stopped services glusterd and glusterfsd node lovhm001: Thread-294::DEBUG::2014-01-05 19:12:32,475::task::1168::TaskManager.Task::(prepare) Task=`a003cde0-a11a-489e-94c2-611f3d096a81`::finished: {'info': {'spm_id': 2, 'master_uuid': '85ad5f7d-3b67-4618-a871-f9ec886020a4', 'name': 'PROD', 'version': '3', 'domains': '85ad5f7d-3b67-4618-a871-f9ec886020a4:Active,6a9b4fa6-f393-4036-bd4e-0bc9dccb1594:Active', 'pool_status': 'connected', 'isoprefix': '/rhev/data-center/mnt/lovhm001.fabber.it:_var_lib_exports_iso/6a9b4fa6-f393-4036-bd4e-0bc9dccb1594/images/11111111-1111-1111-1111-111111111111', 'type': 'GLUSTERFS', 'master_ver': 2, 'lver': 3}, 'dominfo': {'85ad5f7d-3b67-4618-a871-f9ec886020a4': {'status': 'Active', 'diskfree': '374350675968', 'alerts': [], 'version': 3, 'disktotal': '375626137600'}, '6a9b4fa6-f393-4036-bd4e-0bc9dccb1594': {'status': 'Active', 'diskfree': '45249200128', 'alerts': [], 'version': 0, 'disktotal': '51604619264'}}} Thread-294::DEBUG::2014-01-05 19:12:32,476::task::579::TaskManager.Task::(_updateState) Task=`a003cde0-a11a-489e-94c2-611f3d096a81`::moving from state preparing -> state finished Thread-294::DEBUG::2014-01-05 19:12:32,476::resourceManager::939::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {'Storage.2eceb484-73e0-464a-965b-69f067918080': < ResourceRef 'Storage.2eceb484-73e0-464a-965b-69f067918080', isValid: 'True' obj: 'None'>} Thread-294::DEBUG::2014-01-05 19:12:32,476::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-294::DEBUG::2014-01-05 19:12:32,476::resourceManager::615::ResourceManager::(releaseResource) Trying to release resource 'Storage.2eceb484-73e0-464a-965b-69f067918080' Thread-294::DEBUG::2014-01-05 19:12:32,476::resourceManager::634::ResourceManager::(releaseResource) Released resource 'Storage.2eceb484-73e0-464a-965b-69f067918080' (0 active users) Thread-294::DEBUG::2014-01-05 19:12:32,476::resourceManager::640::ResourceManager::(releaseResource) Resource 'Storage.2eceb484-73e0-464a-965b-69f067918080' is free, finding out if anyone is waiting for it. Thread-294::DEBUG::2014-01-05 19:12:32,476::resourceManager::648::ResourceManager::(releaseResource) No one is waiting for resource 'Storage.2eceb484-73e0-464a-965b-69f067918080', Clearing records. Thread-294::DEBUG::2014-01-05 19:12:32,476::task::974::TaskManager.Task::(_decref) Task=`a003cde0-a11a-489e-94c2-611f3d096a81`::ref 0 aborting False Thread-296::DEBUG::2014-01-05 19:12:36,070::BindingXMLRPC::974::vds::(wrapper) client [5.39.66.85]::call volumesList with () {} flowID [76f294ea] Thread-296::DEBUG::2014-01-05 19:12:36,079::BindingXMLRPC::981::vds::(wrapper) return volumesList with {'status': {'message': 'Done', 'code': 0}, 'volumes': {'vmdata': {'transportType': ['TCP'], 'uuid': 'e9b05f7a-f392-44f3-9d44-04761c36437d', 'bricks': ['lovhm001.fabber.it:/vmdata', 'lovhm002.fabber.it:/vmdata'], 'volumeName': 'vmdata', 'volumeType': 'REPLICATE', 'replicaCount': '2', 'brickCount': '2', 'distCount': '2', 'volumeStatus': 'ONLINE', 'stripeCount': '1', 'options': {'cluster.server-quorum-type': 'server', 'cluster.eager-lock': 'enable', 'performance.stat-prefetch': 'off', 'auth.allow': '*', 'cluster.quorum-type': 'auto', 'performance.quick-read': 'off', 'network.remote-dio': 'enable', 'nfs.disable': 'on', 'performance.io-cache': 'off', 'server.allow-insecure': 'on', 'storage.owner-uid': '36', 'user.cifs': 'disable', 'performance.read-ahead': 'off', 'storage.owner-gid': '36', 'cluster.server-quorum-ratio': '50%'}}}} libvirtEventLoop::INFO::2014-01-05 19:12:38,856::vm::4266::vm.Vm::(_onAbnormalStop) vmId=`88997598-1db3-478a-bbe2-a7d234cfdc77`::abnormal vm stop device virtio-disk0 error eother libvirtEventLoop::DEBUG::2014-01-05 19:12:38,856::vm::4840::vm.Vm::(_onLibvirtLifecycleEvent) vmId=`88997598-1db3-478a-bbe2-a7d234cfdc77`::event Suspended detail 2 opaque None Thread-28::DEBUG::2014-01-05 19:12:40,996::fileSD::239::Storage.Misc.excCmd::(getReadDelay) '/bin/dd iflag=direct if=/rhev/data-center/mnt/lovhm001.fabber.it:_var_lib_exports_iso/6a9b4fa6-f393-4036-bd4e-0bc9dccb1594/dom_md/metadata bs=4096 count=1' (cwd None) Thread-28::DEBUG::2014-01-05 19:12:41,001::fileSD::239::Storage.Misc.excCmd::(getReadDelay) SUCCESS: <err> = '0+1 records in\n0+1 records out\n361 bytes (361 B) copied, 0.00017524 s, 2.1 MB/s\n'; <rc> = 0 Thread-298::DEBUG::2014-01-05 19:12:41,088::BindingXMLRPC::974::vds::(wrapper) client [5.39.66.85]::call volumesList with () {} Thread-298::DEBUG::2014-01-05 19:12:41,097::BindingXMLRPC::981::vds::(wrapper) return volumesList with {'status': {'message': 'Done', 'code': 0}, 'volumes': {'vmdata': {'transportType': ['TCP'], 'uuid': 'e9b05f7a-f392-44f3-9d44-04761c36437d', 'bricks': ['lovhm001.fabber.it:/vmdata', 'lovhm002.fabber.it:/vmdata'], 'volumeName': 'vmdata', 'volumeType': 'REPLICATE', 'replicaCount': '2', 'brickCount': '2', 'distCount': '2', 'volumeStatus': 'ONLINE', 'stripeCount': '1', 'options': {'cluster.server-quorum-type': 'server', 'cluster.eager-lock': 'enable', 'performance.stat-prefetch': 'off', 'auth.allow': '*', 'cluster.quorum-type': 'auto', 'performance.quick-read': 'off', 'network.remote-dio': 'enable', 'nfs.disable': 'on', 'performance.io-cache': 'off', 'server.allow-insecure': 'on', 'storage.owner-uid': '36', 'user.cifs': 'disable', 'performance.read-ahead': 'off', 'storage.owner-gid': '36', 'cluster.server-quorum-ratio': '50%'}}}} Thread-300::DEBUG::2014-01-05 19:12:41,345::task::579::TaskManager.Task::(_updateState) Task=`d049a71c-70a4-4dc2-9d69-99f1561ab405`::moving from state init -> state preparing Thread-300::INFO::2014-01-05 19:12:41,345::logUtils::44::dispatcher::(wrapper) Run and protect: repoStats(options=None) Thread-300::INFO::2014-01-05 19:12:41,345::logUtils::47::dispatcher::(wrapper) Run and protect: repoStats, Return response: {'85ad5f7d-3b67-4618-a871-f9ec886020a4': {'delay': '0.000370968', 'lastCheck': '8.9', 'code': 0, 'valid': True, 'version': 3}, '6a9b4fa6-f393-4036-bd4e-0bc9dccb1594': {'delay': '0.00017524', 'lastCheck': '0.3', 'code': 0, 'valid': True, 'version': 0}} Thread-300::DEBUG::2014-01-05 19:12:41,346::task::1168::TaskManager.Task::(prepare) Task=`d049a71c-70a4-4dc2-9d69-99f1561ab405`::finished: {'85ad5f7d-3b67-4618-a871-f9ec886020a4': {'delay': '0.000370968', 'lastCheck': '8.9', 'code': 0, 'valid': True, 'version': 3}, '6a9b4fa6-f393-4036-bd4e-0bc9dccb1594': {'delay': '0.00017524', 'lastCheck': '0.3', 'code': 0, 'valid': True, 'version': 0}} Thread-300::DEBUG::2014-01-05 19:12:41,346::task::579::TaskManager.Task::(_updateState) Task=`d049a71c-70a4-4dc2-9d69-99f1561ab405`::moving from state preparing -> state finished Thread-300::DEBUG::2014-01-05 19:12:41,346::resourceManager::939::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {} Thread-300::DEBUG::2014-01-05 19:12:41,346::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-300::DEBUG::2014-01-05 19:12:41,346::task::974::TaskManager.Task::(_decref) Task=`d049a71c-70a4-4dc2-9d69-99f1561ab405`::ref 0 aborting False Thread-27::DEBUG::2014-01-05 19:12:42,459::fileSD::239::Storage.Misc.excCmd::(getReadDelay) '/bin/dd iflag=direct if=/rhev/data-center/mnt/glusterSD/lovhm001:_vmdata/85ad5f7d-3b67-4618-a871-f9ec886020a4/dom_md/metadata bs=4096 count=1' (cwd None) Thread-27::DEBUG::2014-01-05 19:12:42,464::fileSD::239::Storage.Misc.excCmd::(getReadDelay) SUCCESS: <err> = '0+1 records in\n0+1 records out\n495 bytes (495 B) copied, 0.000345681 s, 1.4 MB/s\n'; <rc> = 0 Thread-302::DEBUG::2014-01-05 19:12:42,484::BindingXMLRPC::177::vds::(wrapper) client [5.39.66.85] Thread-302::DEBUG::2014-01-05 19:12:42,485::task::579::TaskManager.Task::(_updateState) Task=`acd727ae-dcbf-4662-bd97-fbdbadf6968a`::moving from state init -> state preparing Thread-302::INFO::2014-01-05 19:12:42,485::logUtils::44::dispatcher::(wrapper) Run and protect: getSpmStatus(spUUID='2eceb484-73e0-464a-965b-69f067918080', options=None) Thread-302::INFO::2014-01-05 19:12:42,485::logUtils::47::dispatcher::(wrapper) Run and protect: getSpmStatus, Return response: {'spm_st': {'spmId': 2, 'spmStatus': 'SPM', 'spmLver': 3}} thanks in advance a -- Amedeo Salvati RHC{DS,E,VA} - LPIC-3 - UCP - NCLA 11 m. +39 333 1264484 email: amedeo(a)oscert.net email: amedeo(a)linux.com http://plugcomputing.it/redhatcert.php http://plugcomputing.it/lpicert.php

2 2

[Users] Cannot add Host. Host with the same address already exists.
by Matt . 06 Jan '14

06 Jan '14

Hi All, Ovirt 3.3.3 I have removed a host from the gui and want to re-add it, there was something wrong with the installation of this host. When adding the host I get: "Error while executing action: Cannot add Host. Host with the same address already exists." It seems that the host is still in the DB somewhere and it is, I see some NULL columns for that host because it's actually not really "there" anymore and stuff like statics are not updated. I need to clean this one out, how can I accomplish this without getting a "dirty" DB ? Thanks! Cheers, Matt

3 3

[Users] Fwd: Your stand proposal for oVirt has been accepted
by Dave Neary 06 Jan '14

06 Jan '14

Hi everyone, Great news! We will have an oVirt stand at FOSDEM in Brussels this year! Brian and I will be looking for volunteers to man the stand and spread the love about oVirt over the next few weeks - please let us know if you plan to attend FOSDEM, we would love to see you there! Also, I would love to have an oVirt community meet-up for beers on Saturday evening - if we did, would you be interested in attending? Let us know! Thanks, Dave. -------- Original Message -------- Subject: Your stand proposal for oVirt has been accepted Date: Mon, 16 Dec 2013 22:28:20 +0100 (CET) From: FOSDEM Stands Team <stands(a)fosdem.org> To: Dave Neary <dneary(a)redhat.com> Hi Dave, The FOSDEM stands team is glad to be able to inform you that your request for a stand for oVirt has been accepted. There will be one table reserved for you. You will receive further information about what's expected of you closer to the event date. Looking forward to seeing you at FOSDEM 2014! Kind regards, Wynke Stulemeijer FOSDEM stands team

5 7

[Users] Another issue - VM Networking
by Dan Ferris 05 Jan '14

05 Jan '14

I've run into another issue with Ovirt 3.3.2. We have a 2 node VM cluster with Fibre Channel storage. After upgrade everything to FC 19 and installing Ovirt 3.3 from scratch one of the nodes has network issues. The issue is that when we start a VM on the node, the VM cannot access the network. No ping, no ssh, nothing. However, if I try to ping the VM, I can see the ICMP traffic on the ethernet VLAN interface and the bridge interface. I cannot see any traffic on the VM tap interface. If we migrate the VM from the faulty node to the other node that works, and then back, the network will start to work. However, if the VM is shut down the network will fail again when it's booted on the faulty node. Does anyone have any ideas about this particular problem? Thanks, Dan

3 2

[Users] Stopping glusterfsd service shut down data center
by Amedeo Salvati 05 Jan '14

05 Jan '14

Hi all, I'm testing ovirt+glusterfs with only two node for all (engine, glusterfs, hypervisors), on centos 6.5 hosts following guide at: http://community.redhat.com/blog/2013/09/up-and-running-with-ovirt-3-3/ http://www.gluster.org/2013/09/ovirt-3-3-glusterized/ but with some change like setting on glusterfs, parameter cluster.server-quorum-ratio to 50% (due to prevent glusterfs to go down if one node goes done) and option on /etc/glusterfs/glusterd.vol "option base-port 50152" (due to libvirt port conflict). So, with the above parameter I was able to stop/reboot node not used to directly mount glusterfs (eg lovhm002), but when I stop/reboot node, that is used to mount glusterfs (eg node lovhm001), all data center goes done, especially when I stop service glusterfsd (not glusterd service!!!), but the glusterfs still alive and is reachable on node lovhm002 that survives but ovirt/libvirt marks DC/storage in error. Do you have any ideas to configure DC/Cluster on ovirt that remains aware if node used to mount glusterfs goes down? This is a sample vdsmd.log on node that remains on-line (lovhm002) when I stopped services glusterd and glusterfsd node lovhm001: Thread-294::DEBUG::2014-01-05 19:12:32,475::task::1168::TaskManager.Task::(prepare) Task=`a003cde0-a11a-489e-94c2-611f3d096a81`::finished: {'info': {'spm_id': 2, 'master_uuid': '85ad5f7d-3b67-4618-a871-f9ec886020a4', 'name': 'PROD', 'version': '3', 'domains': '85ad5f7d-3b67-4618-a871-f9ec886020a4:Active,6a9b4fa6-f393-4036-bd4e-0bc9dccb1594:Active', 'pool_status': 'connected', 'isoprefix': '/rhev/data-center/mnt/lovhm001.fabber.it:_var_lib_exports_iso/6a9b4fa6-f393-4036-bd4e-0bc9dccb1594/images/11111111-1111-1111-1111-111111111111', 'type': 'GLUSTERFS', 'master_ver': 2, 'lver': 3}, 'dominfo': {'85ad5f7d-3b67-4618-a871-f9ec886020a4': {'status': 'Active', 'diskfree': '374350675968', 'alerts': [], 'version': 3, 'disktotal': '375626137600'}, '6a9b4fa6-f393-4036-bd4e-0bc9dccb1594': {'status': 'Active', 'diskfree': '45249200128', 'alerts': [], 'version': 0, 'disktotal': '51604619264'}}} Thread-294::DEBUG::2014-01-05 19:12:32,476::task::579::TaskManager.Task::(_updateState) Task=`a003cde0-a11a-489e-94c2-611f3d096a81`::moving from state preparing -> state finished Thread-294::DEBUG::2014-01-05 19:12:32,476::resourceManager::939::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {'Storage.2eceb484-73e0-464a-965b-69f067918080': < ResourceRef 'Storage.2eceb484-73e0-464a-965b-69f067918080', isValid: 'True' obj: 'None'>} Thread-294::DEBUG::2014-01-05 19:12:32,476::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-294::DEBUG::2014-01-05 19:12:32,476::resourceManager::615::ResourceManager::(releaseResource) Trying to release resource 'Storage.2eceb484-73e0-464a-965b-69f067918080' Thread-294::DEBUG::2014-01-05 19:12:32,476::resourceManager::634::ResourceManager::(releaseResource) Released resource 'Storage.2eceb484-73e0-464a-965b-69f067918080' (0 active users) Thread-294::DEBUG::2014-01-05 19:12:32,476::resourceManager::640::ResourceManager::(releaseResource) Resource 'Storage.2eceb484-73e0-464a-965b-69f067918080' is free, finding out if anyone is waiting for it. Thread-294::DEBUG::2014-01-05 19:12:32,476::resourceManager::648::ResourceManager::(releaseResource) No one is waiting for resource 'Storage.2eceb484-73e0-464a-965b-69f067918080', Clearing records. Thread-294::DEBUG::2014-01-05 19:12:32,476::task::974::TaskManager.Task::(_decref) Task=`a003cde0-a11a-489e-94c2-611f3d096a81`::ref 0 aborting False Thread-296::DEBUG::2014-01-05 19:12:36,070::BindingXMLRPC::974::vds::(wrapper) client [5.39.66.85]::call volumesList with () {} flowID [76f294ea] Thread-296::DEBUG::2014-01-05 19:12:36,079::BindingXMLRPC::981::vds::(wrapper) return volumesList with {'status': {'message': 'Done', 'code': 0}, 'volumes': {'vmdata': {'transportType': ['TCP'], 'uuid': 'e9b05f7a-f392-44f3-9d44-04761c36437d', 'bricks': ['lovhm001.fabber.it:/vmdata', 'lovhm002.fabber.it:/vmdata'], 'volumeName': 'vmdata', 'volumeType': 'REPLICATE', 'replicaCount': '2', 'brickCount': '2', 'distCount': '2', 'volumeStatus': 'ONLINE', 'stripeCount': '1', 'options': {'cluster.server-quorum-type': 'server', 'cluster.eager-lock': 'enable', 'performance.stat-prefetch': 'off', 'auth.allow': '*', 'cluster.quorum-type': 'auto', 'performance.quick-read': 'off', 'network.remote-dio': 'enable', 'nfs.disable': 'on', 'performance.io-cache': 'off', 'server.allow-insecure': 'on', 'storage.owner-uid': '36', 'user.cifs': 'disable', 'performance.read-ahead': 'off', 'storage.owner-gid': '36', 'cluster.server-quorum-ratio': '50%'}}}} libvirtEventLoop::INFO::2014-01-05 19:12:38,856::vm::4266::vm.Vm::(_onAbnormalStop) vmId=`88997598-1db3-478a-bbe2-a7d234cfdc77`::abnormal vm stop device virtio-disk0 error eother libvirtEventLoop::DEBUG::2014-01-05 19:12:38,856::vm::4840::vm.Vm::(_onLibvirtLifecycleEvent) vmId=`88997598-1db3-478a-bbe2-a7d234cfdc77`::event Suspended detail 2 opaque None Thread-28::DEBUG::2014-01-05 19:12:40,996::fileSD::239::Storage.Misc.excCmd::(getReadDelay) '/bin/dd iflag=direct if=/rhev/data-center/mnt/lovhm001.fabber.it:_var_lib_exports_iso/6a9b4fa6-f393-4036-bd4e-0bc9dccb1594/dom_md/metadata bs=4096 count=1' (cwd None) Thread-28::DEBUG::2014-01-05 19:12:41,001::fileSD::239::Storage.Misc.excCmd::(getReadDelay) SUCCESS: <err> = '0+1 records in\n0+1 records out\n361 bytes (361 B) copied, 0.00017524 s, 2.1 MB/s\n'; <rc> = 0 Thread-298::DEBUG::2014-01-05 19:12:41,088::BindingXMLRPC::974::vds::(wrapper) client [5.39.66.85]::call volumesList with () {} Thread-298::DEBUG::2014-01-05 19:12:41,097::BindingXMLRPC::981::vds::(wrapper) return volumesList with {'status': {'message': 'Done', 'code': 0}, 'volumes': {'vmdata': {'transportType': ['TCP'], 'uuid': 'e9b05f7a-f392-44f3-9d44-04761c36437d', 'bricks': ['lovhm001.fabber.it:/vmdata', 'lovhm002.fabber.it:/vmdata'], 'volumeName': 'vmdata', 'volumeType': 'REPLICATE', 'replicaCount': '2', 'brickCount': '2', 'distCount': '2', 'volumeStatus': 'ONLINE', 'stripeCount': '1', 'options': {'cluster.server-quorum-type': 'server', 'cluster.eager-lock': 'enable', 'performance.stat-prefetch': 'off', 'auth.allow': '*', 'cluster.quorum-type': 'auto', 'performance.quick-read': 'off', 'network.remote-dio': 'enable', 'nfs.disable': 'on', 'performance.io-cache': 'off', 'server.allow-insecure': 'on', 'storage.owner-uid': '36', 'user.cifs': 'disable', 'performance.read-ahead': 'off', 'storage.owner-gid': '36', 'cluster.server-quorum-ratio': '50%'}}}} Thread-300::DEBUG::2014-01-05 19:12:41,345::task::579::TaskManager.Task::(_updateState) Task=`d049a71c-70a4-4dc2-9d69-99f1561ab405`::moving from state init -> state preparing Thread-300::INFO::2014-01-05 19:12:41,345::logUtils::44::dispatcher::(wrapper) Run and protect: repoStats(options=None) Thread-300::INFO::2014-01-05 19:12:41,345::logUtils::47::dispatcher::(wrapper) Run and protect: repoStats, Return response: {'85ad5f7d-3b67-4618-a871-f9ec886020a4': {'delay': '0.000370968', 'lastCheck': '8.9', 'code': 0, 'valid': True, 'version': 3}, '6a9b4fa6-f393-4036-bd4e-0bc9dccb1594': {'delay': '0.00017524', 'lastCheck': '0.3', 'code': 0, 'valid': True, 'version': 0}} Thread-300::DEBUG::2014-01-05 19:12:41,346::task::1168::TaskManager.Task::(prepare) Task=`d049a71c-70a4-4dc2-9d69-99f1561ab405`::finished: {'85ad5f7d-3b67-4618-a871-f9ec886020a4': {'delay': '0.000370968', 'lastCheck': '8.9', 'code': 0, 'valid': True, 'version': 3}, '6a9b4fa6-f393-4036-bd4e-0bc9dccb1594': {'delay': '0.00017524', 'lastCheck': '0.3', 'code': 0, 'valid': True, 'version': 0}} Thread-300::DEBUG::2014-01-05 19:12:41,346::task::579::TaskManager.Task::(_updateState) Task=`d049a71c-70a4-4dc2-9d69-99f1561ab405`::moving from state preparing -> state finished Thread-300::DEBUG::2014-01-05 19:12:41,346::resourceManager::939::ResourceManager.Owner::(releaseAll) Owner.releaseAll requests {} resources {} Thread-300::DEBUG::2014-01-05 19:12:41,346::resourceManager::976::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {} Thread-300::DEBUG::2014-01-05 19:12:41,346::task::974::TaskManager.Task::(_decref) Task=`d049a71c-70a4-4dc2-9d69-99f1561ab405`::ref 0 aborting False Thread-27::DEBUG::2014-01-05 19:12:42,459::fileSD::239::Storage.Misc.excCmd::(getReadDelay) '/bin/dd iflag=direct if=/rhev/data-center/mnt/glusterSD/lovhm001:_vmdata/85ad5f7d-3b67-4618-a871-f9ec886020a4/dom_md/metadata bs=4096 count=1' (cwd None) Thread-27::DEBUG::2014-01-05 19:12:42,464::fileSD::239::Storage.Misc.excCmd::(getReadDelay) SUCCESS: <err> = '0+1 records in\n0+1 records out\n495 bytes (495 B) copied, 0.000345681 s, 1.4 MB/s\n'; <rc> = 0 Thread-302::DEBUG::2014-01-05 19:12:42,484::BindingXMLRPC::177::vds::(wrapper) client [5.39.66.85] Thread-302::DEBUG::2014-01-05 19:12:42,485::task::579::TaskManager.Task::(_updateState) Task=`acd727ae-dcbf-4662-bd97-fbdbadf6968a`::moving from state init -> state preparing Thread-302::INFO::2014-01-05 19:12:42,485::logUtils::44::dispatcher::(wrapper) Run and protect: getSpmStatus(spUUID='2eceb484-73e0-464a-965b-69f067918080', options=None) Thread-302::INFO::2014-01-05 19:12:42,485::logUtils::47::dispatcher::(wrapper) Run and protect: getSpmStatus, Return response: {'spm_st': {'spmId': 2, 'spmStatus': 'SPM', 'spmLver': 3}} thanks in advance a -- Amedeo Salvati RHC{DS,E,VA} - LPIC-3 - UCP - NCLA 11 m. +39 333 1264484 email: amedeo(a)oscert.net email: amedeo(a)linux.com http://plugcomputing.it/redhatcert.php http://plugcomputing.it/lpicert.php

1 0

[Users] Centos 6.5 host configuration script -- a tale begun
by Ted Miller 05 Jan '14

05 Jan '14

--_000_22f073c8f28e423a8959bb2687b19cb9DM2PR05MB320namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been working since Monday to get a Centos 6.5 host node added to ovi= rt. Since 6.5 is just out, I figured I might as well use the latest and gr= eatest to build my host. Today I succeeded (I think). I have not actually= added a VM to the host, but at least ovirt is willing to accept that the h= ost is part of the default cluster. My next task will be bringing up glust= er on that same node. Since I will be doing at least three more hosts, I wrote a shell script to = do a the setup that is needed to make the ovirt process succeed. No, I do not have a similar script for the engine. I got that running unde= r Centos 6.4 in a VM, without too much problem. That VM is temporarily run= ning on a KVM host (but that host is not under ovirt). Feel welcome to stare at or run my script and make any comments or observat= ions. * The script is run after a clean install of Centos 6.5 from the "minim= al" ISO. * I will try to remember what each element was there for, if anything i= s not clear. * There are probably a few (not many) things there that are not needed * Mostly they result in doing something ahead of time that ovirt was= going to do later anyway. * Feel free to point out a better way to do whatever needs to be done. * Bits and pieces of the script were stolen from googleing here and the= re. * Parts of the script were cooked up by stewing logs over low heat unti= l something useful bubbled to the top. * The number of clean reinstalls to test the script is beyond count. * I almost broke down and learned how to write a kickstart file (but= didn't). * No guarantees or representations. * So far this script has been tested on exactly one set of bare-meta= l hardware * That hardware is not server-grade. (ovirt keeps complaining bec= ause I have not configured Power Management :) * There are a few things that are personal preferences (things I instal= l on all my Linux machines) * I believe those preferences are clearly marked. * I am leaving them in because they may (incidentally) be installing= some dependencies that influence the outcome of the process. I hope to see a day when a similar script is either not needed, or is avail= able and maintained as part of the Centos distro, or as part of ovirt. Mea= nwhile we try to muddle through. I will copy my script into this webmail interface (OWA) (since I am writing= at home and this is all I have to work with) and see how bad it mangles it= . You'll probably need a wide window so that lines don't wrap, as Microsof= t thinks this OWA interface doesn't ever need to let me specify text as "pr= eformat". I called my script ov_host-start.sh # script to prepare Centos 6.5 for ovirt host install process echo "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ted's personal p= references--early =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D" yum -y install nano deltarpm yum-plugin-priorities yum-presto mlocate echo "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D end of Ted'= s personal preferences--early =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D" yum -y upgrade echo "....................install some repos (if not already done).........= ........." cd /etc/yum.repos.d if [ ! -f glusterfs-epel.repo ] ; then echo "..............installing gluster repo......................." yum -y install wget wget http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo/g= lusterfs-epel.repo echo "..............done installing gluster repo.................." fi if [ ! -f el6-ovirt.repo ] ; then echo "..............installing ovirt repo......................." yum -y localinstall http://ovirt.org/releases/ovirt-release-el.noarch.rpm echo "..............done installing ovirt repo.................." fi if [ ! -f epel.repo ] ; then echo "..............installing epel repo......................." yum -y localinstall http://mirror.us.leaseweb.net/epel/6/i386/epel-releas= e-6-8.noarch.rpm echo "..............done installing epel repo.................." fi echo "........install libvirt............................" yum -y install libvirt qemu-kvm tuned echo "........install virt-manager" # with unlisted dependencies yum -y install virt-manager xorg-x11-xauth dejavu-lgc-sans-mono-fonts # create the ovirtmgmt bridge if [ ! -f /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt ]; then echo "........................creating ovirtmgmt bridge.................= ....." service libvirtd start service libvirtd status virsh net-destroy default virsh net-undefine default virsh iface-bridge eth0 ovirtmgmt service network restart service libvirtd stop service libvirtd status fi echo ".........copy tuned profile..............." # copy virtual-host --> rhs-virtualization so ovirt is happy cp -r /etc/tune-profiles/virtual-host /etc/tune-profiles/rhs-virtualization yum -y install vdsm echo "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Ted's personal p= references--late =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D" #add lines to send messages to TTY12 cat /etc/rsyslog.conf | grep tty12 if [ ! $? -eq 0 ] ; then echo ".......................Adding for tty12...................." echo " " >> /etc/rsyslog.conf echo "# Log everything to tty12" >> /etc/rsyslog.conf echo "*.* /dev/tty12" >> /etc/rsyslog.conf service rsyslog restart fi echo "...........install gkrellm.............." yum -y install gkrellm #add poll=3D0 to kill noveau messages cat /boot/grub/grub.conf | grep poll=3D0 if [ ! $? -eq 0 ] ; then echo "............................Adding poll=3D0.......................= ..." sed -i '/^[ \t]kernel*/ s/$/ drm-kms-helper.poll=3D0/g' /boot/grub/grub.= conf fi --_000_22f073c8f28e423a8959bb2687b19cb9DM2PR05MB320namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > </head> <body id=3D"" tabindex=3D"0" dir=3D"ltr"> <div name=3D"divtagdefaultwrapper" id=3D"divtagdefaultwrapper" style=3D"fon= t-family: Calibri,Arial,Helvetica,sans-serif; font-size: 12pt; color: #0000= 00; margin: 0"> I have been working since Monday to get a Centos 6.5 host node added to ovi= rt.  Since 6.5 is just out, I figured I might as well use the latest a= nd greatest to build my host.  Today I succeeded (I think).  I ha= ve not actually added a VM to the host, but at least ovirt is willing to accept that the host is part of the default clus= ter.  My next task will be bringing up gluster on that same node.<br> <br> Since I will be doing at least three more hosts, I wrote a shell script to = do a the setup that is needed to make the ovirt process succeed.<br> <br> No, I do not have a similar script for the engine.  I got that running= under Centos 6.4 in a VM, without too much problem.  That VM is tempo= rarily running on a KVM host (but that host is not under ovirt).<br> <br> Feel welcome to stare at or run my script and make any comments or observat= ions.<br> <ul style=3D"font-family: serif; font-size: 12pt; margin-top: 0px; margin-b= ottom: 0px;"> <li>The script is run after a clean install of Centos 6.5 from the "mi= nimal" ISO.<br> </li><li>I will try to remember what each element was there for, if anythin= g is not clear.</li><li>There are probably a few (not many) things there th= at are not needed <ul> <li>Mostly they result in doing something ahead of time that ovirt was goin= g to do later anyway.<br> </li></ul> </li><li>Feel free to point out a better way to do whatever needs to be don= e.</li><li>Bits and pieces of the script were stolen from googleing here an= d there.</li><li>Parts of the script were cooked up by stewing logs over lo= w heat until something useful bubbled to the top.</li><li>The number of cle= an reinstalls to test the script is beyond count. <ul> <li>I almost broke down and learned how to write a kickstart file (but didn= 't).<br> </li></ul> </li><li>No guarantees or representations. <ul> <li>So far this script has been tested on <b>exactly one</b> set of bare-me= tal hardware <ul> <li>That hardware is not server-grade. (ovirt keeps complaining because I h= ave not configured Power Management :)</li></ul> </li></ul> </li><li>There are a few things that are personal preferences (things I ins= tall on all my Linux machines) <ul> <li>I believe those preferences are clearly marked.</li><li>I am leaving th= em in because they may (incidentally) be installing some dependencies that = influence the outcome of the process.<br> </li></ul> </li></ul> <br> I hope to see a day when a similar script is either not needed, or is avail= able and maintained as part of the Centos distro, or as part of ovirt.&nbsp= ; Meanwhile we try to muddle through.<br> <br> I will copy my script into this webmail interface (OWA) (since I am writing= at home and this is all I have to work with) and see how bad it mangles it= .  You'll probably need a wide window so that lines don't wrap, as Mic= rosoft thinks this OWA interface doesn't ever need to let me specify text as "preformat".  I called = my script ov_host-start.sh<br> <br> <br> <font face=3D"'Courier New',monospace"># script to prepare Centos 6.5 for o= virt host install process<br> <br> echo "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D  Ted's = personal preferences--early =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D"<br> <br> yum -y install nano deltarpm yum-plugin-priorities yum-presto mlocate<br> <br> echo "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D end of= Ted's personal preferences--early =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D"<br> <br> yum -y upgrade<br> <br> echo "....................install some repos (if not already done)....= .............."<br> cd /etc/yum.repos.d<br> if [ ! -f glusterfs-epel.repo ] ; then<br>   echo "..............installing gluster repo....................= ..."<br>   yum -y install wget<br>   wget http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.r= epo/glusterfs-epel.repo<br>   echo "..............done installing gluster repo...............= ..."<br> fi<br> <br> if [ ! -f el6-ovirt.repo ] ; then<br>   echo "..............installing ovirt repo......................= ."<br>   yum -y localinstall http://ovirt.org/releases/ovirt-release-el.noarc= h.rpm<br>   echo "..............done installing ovirt repo.................= ."<br> fi<br> <br> if [ ! -f epel.repo ] ; then<br>   echo "..............installing epel repo.......................= "<br>   yum -y localinstall http://mirror.us.leaseweb.net/epel/6/i386/epel-r= elease-6-8.noarch.rpm<br>   echo "..............done installing epel repo..................= "<br> fi<br> <br> <br> echo "........install libvirt............................"<br>     yum -y install libvirt qemu-kvm tuned<br> echo "........install virt-manager" # with unlisted dependencies<= br> yum -y install virt-manager xorg-x11-xauth dejavu-lgc-sans-mono-fonts<br> <br> # create the ovirtmgmt bridge<br> if [ ! -f /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt ]; then<br>    echo "........................creating ovirtmgmt bridge..= ...................."<br>    service libvirtd start<br>    service libvirtd status<br>    virsh net-destroy default<br>    virsh net-undefine default<br>    virsh iface-bridge eth0 ovirtmgmt<br>    service network restart<br>    service libvirtd stop<br>    service libvirtd status<br> fi<br> <br> echo ".........copy tuned profile..............."<br> # copy virtual-host --> rhs-virtualization so ovirt is happy<br> cp -r /etc/tune-profiles/virtual-host /etc/tune-profiles/rhs-virtualization= <br> <br> yum -y install vdsm<br> <br> echo "=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D  Ted's = personal preferences--late =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D"<br> <br> #add lines to send messages to TTY12<br> cat /etc/rsyslog.conf | grep tty12<br> if [ ! $? -eq 0 ] ; then<br>    echo ".......................Adding for tty12............= ........"<br>    echo " " >> /etc/rsyslog.conf<br>    echo "# Log everything to tty12"  >> /etc= /rsyslog.conf<br>    echo "*.*          &nb= sp;               &n= bsp;  /dev/tty12" >> /etc/rsyslog.conf<br>    service rsyslog restart<br> fi<br> <br> echo "...........install gkrellm.............."<br> yum -y install gkrellm<br> <br> #add poll=3D0 to kill noveau messages<br> cat /boot/grub/grub.conf | grep poll=3D0<br> if [ ! $? -eq 0 ] ; then<br>    echo "............................Adding poll=3D0........= .................."<br>    sed -i '/^[ \t]kernel*/ s/$/ drm-kms-helper.poll=3D0/g' /boot/= grub/grub.conf<br> fi<br> </font><br> </div> </body> </html> --_000_22f073c8f28e423a8959bb2687b19cb9DM2PR05MB320namprd05pro_--

4 4

[Users] Virtual networks
by Maurice James 05 Jan '14

05 Jan '14

------=_NextPart_000_000E_01CF0937.3442D480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Can ovirt provide DHCP addressing to VMs the way libvirt does on its own? ------=_NextPart_000_000E_01CF0937.3442D480 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-microsoft-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=3DGenerator content=3D"Microsoft Word 15 = (filtered medium)"><style></style></head><body lang=3DEN-US = link=3D"#0563C1" vlink=3D"#954F72"><div class=3DWordSection1><p = class=3DMsoNormal>Can ovirt provide DHCP addressing to VMs the way = libvirt does on its own?<o:p></o:p></p></div></body></html> ------=_NextPart_000_000E_01CF0937.3442D480--

2 1

[Users] all hosts are Non responsive
by Zach Underwood 03 Jan '14

03 Jan '14

When I try to activate a host to the engine I get the error non responsive. I can ping the hosts but I cant connect with ssh. oVirt Engine Version: 3.3.2-1.el6 ovirt-node-iso-3.0.3-1.1.vdsm.fc19 -- Zach Underwood (RHCE,RHCSA,RHCT,UACA) My website <http://zachunderwood.me> My photos <http://zunder1990.openphoto.me>

3 12

[Users] qemu-img-rhev can't handle "-s" parameter
by Nux! 03 Jan '14

03 Jan '14

Hello, I used qemu-img-rhev-0.12.1.2-2.355.el6 successfully with -s parameter, but now qemu-img-rhev-0.12.1.2-2.415.el6 (latest atm) errors out with: convert: invalid option -- 's' What am I missing? Do I need any special rpmbuild switches or something? I see the spec already says "rhev 1" which should be enough. Regards, Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro

3 7

[Users] PPC64 Updates
by Leonardo Bianconi 02 Jan '14

02 Jan '14

--_000_50EB20226B72D6419356FC320AB62B876E004078SERV070corpeldo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sandro! Im writing this e-mail to update the PPC64 status, because we don't work on= Christmas, so we will not be in the meeting tomorrow. We have updated the spreadsheet. Three features that were in design are und= er review now. No new features done. We have some patches merged and we are planning to start tests in January w= ith the master revision. Best regards Leonardo Bianconi. --_000_50EB20226B72D6419356FC320AB62B876E004078SERV070corpeldo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" id=3D"owaParaStyle"></style> </head> <body fpstyle=3D"1" ocsi=3D"0"> <div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: = 10pt;"> <div>Hi Sandro!</div> <div><br> </div> <div>Im writing this e-mail to update the PPC64 status, because we don't wo= rk on Christmas, so we will not be in the meeting tomorrow.</div> <div><br> </div> <div>We have updated the spreadsheet. Three features that were in design ar= e under review now. No new features done.</div> <div>We have some patches merged and we are planning to start tests in Janu= ary with the master revision.</div> <div><br> </div> <div>Best regards</div> <div>Leonardo Bianconi.</div> </div> </body> </html> --_000_50EB20226B72D6419356FC320AB62B876E004078SERV070corpeldo_--

3 5

[Users] oVirt@FOSDEM 2014 sync
by Doron Fediuck 02 Jan '14

02 Jan '14

Hi all, keeping our FOSDEM tradition (from last year ;) we will be using a pad [1] to synchronize our activities which works very well. I'll make sure to print it, so we'll have a hard copy available in place. If you're coming and wish to help, feel free to register inside. Thanks and see you there! Doron [1] http://etherpad.ovirt.org/p/ovirt-fosdem-14 <http://etherpad.ovirt.org/p/ovirt-fosdem-14>

1 0

Re: [Users] Broken Snapshots
by Dafna Ron 02 Jan '14

02 Jan '14

It would be good to understand why this happened in the first place and what is the current situation below. do you know why the snapshots were broken? can you please attach engine and vdsm logs? can you also run tree on /rhev on the host and put results in a file? finally, if you could run a query in the db to get the current snapshots in db and also run lvs (for iscsi) or ls on the image dir in the domain (for nfs)? I am adding Liron, Eduardo and Federico to help investigate this issue and help you remove the snapshots Thakns, Dafna On 01/02/2014 10:53 AM, Maurice James wrote: > I only want to get rid of the snapshots > > -----Original Message----- > From: Dafna Ron [mailto:dron@redhat.com] > Sent: Thursday, January 02, 2014 4:59 AM > To: Maurice James > Cc: users(a)ovirt.org; eduardo Warszawski > Subject: Re: [Users] Broken Snapshots > > do you want to get rid of the snapshot or the entire disk? adding Eduardo. > > > On 01/01/2014 11:16 PM, Maurice James wrote: >> How do I get rid of broken snapshots? I cannot delete them from the >> web gui or the shell >> >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users > > -- > Dafna Ron -- Dafna Ron

4 7