September 2014 - Users - oVirt List Archives

Should we add 'cow' format disk in file domains in frontend UI ?
by plysan 14 Sep '14

14 Sep '14

Hello, We had experience that if we clone vm from snapshot with sprase raw disk in file domains, the process would get very slow if the disk defined virtual size is big but actual size is small, so i popose the frontend UI to be able to add caw disk in file domains. And I'm happy to implement it. I want to know if there is any problem with my theory, I'm not so experienced in storage. And I created a more detailed expanation to address this problem: https://bugzilla.redhat.com/show_bug.cgi?id=1117219 thanks.

3 2

multipath: error getting device
by Jorick Astrego 14 Sep '14

14 Sep '14

This is a multi-part message in MIME format. --------------040308090200020008010208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm seeing a continuous stream of multipath errors on my Centos 7 hosts with ovirt 3.5 rc1.1. Can't find a bug for it except https://bugzilla.redhat.com/show_bug.cgi?id=675366 Sep 8 11:34:13 host1 kernel: device-mapper: table: 253:3: multipath: error getting device Sep 8 11:34:13 host1 kernel: device-mapper: ioctl: error adding target to table Sep 8 11:34:13 host1 multipathd: dm-3: remove map (uevent) Sep 8 11:34:13 host1 multipathd: dm-3: remove map (uevent) Sep 8 11:34:23 host1 kernel: device-mapper: table: 253:3: multipath: error getting device Sep 8 11:34:23 host1 kernel: device-mapper: ioctl: error adding target to table Sep 8 11:34:23 host1 multipathd: dm-3: remove map (uevent) Sep 8 11:34:23 host1 multipathd: dm-3: remove map (uevent) Sep 8 11:34:33 host1 kernel: device-mapper: table: 253:3: multipath: error getting device Sep 8 11:34:33 host1 kernel: device-mapper: ioctl: error adding target to table We don't use multipath, but it's a bit annoying as it's filling up the console and logs..... Kind regards, Jorick Astrego Netbulae B.V. --------------040308090200020008010208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi,<br> <br> I'm seeing a continuous stream of multipath errors on my Centos 7 hosts with ovirt 3.5 rc1.1.<br> <br> Can't find a bug for it except <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=675366">https://bugzilla.redhat.com/show_bug.cgi?id=675366</a><br> <br> <blockquote>Sep  8 11:34:13 host1 kernel: device-mapper: table: 253:3: multipath: error getting device<br> Sep  8 11:34:13 host1 kernel: device-mapper: ioctl: error adding target to table<br> Sep  8 11:34:13 host1 multipathd: dm-3: remove map (uevent)<br> Sep  8 11:34:13 host1 multipathd: dm-3: remove map (uevent)<br> Sep  8 11:34:23 host1 kernel: device-mapper: table: 253:3: multipath: error getting device<br> Sep  8 11:34:23 host1 kernel: device-mapper: ioctl: error adding target to table<br> Sep  8 11:34:23 host1 multipathd: dm-3: remove map (uevent)<br> Sep  8 11:34:23 host1 multipathd: dm-3: remove map (uevent)<br> Sep  8 11:34:33 host1 kernel: device-mapper: table: 253:3: multipath: error getting device<br> Sep  8 11:34:33 host1 kernel: device-mapper: ioctl: error adding target to table<br> </blockquote> We don't use multipath, but it's a bit annoying as it's filling up the console and logs.....<br> <br> Kind regards,<br> <br> Jorick Astrego<br> Netbulae B.V.<br> </body> </html> --------------040308090200020008010208--

3 2

ODP: ovirt 3.5 rc2 and iscsi error with chap enabled during discovery
by Piotr Kliczewski 14 Sep '14

14 Sep '14

----_com.android.email_563997694433680 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QWxsb24sCgpJdCBsb29rcyBsaWtlIHdlIHBhc3MgbW9yZSBhcmd1bWVudHMgdGhhbiByZXFpcmVk LiBXaWxsIGZpeC4gUGxlYXNlIG9wZW4gYSBidWcuCgoKVGhhbmtzLApQaW90cgoKPGRpdj4tLS0t LS0tLSBPcnlnaW5hbG5hIHdpYWRvbW/Fm8SHIC0tLS0tLS0tPC9kaXY+PGRpdj5PZDogQWxsb24g TXVyZWluaWsgPGFtdXJlaW5pQHJlZGhhdC5jb20+IDwvZGl2PjxkaXY+RGF0YToxNC4wOS4yMDE0 ICAwOToyOCAgKEdNVCswMTowMCkgPC9kaXY+PGRpdj5EbzogUGlvdHIgS2xpY3pld3NraSA8cGts aWN6ZXdAcmVkaGF0LmNvbT4gPC9kaXY+PGRpdj5EVzogdXNlcnMgPHVzZXJzQG92aXJ0Lm9yZz4s R2lhbmx1Y2EgQ2VjY2hpIDxnaWFubHVjYS5jZWNjaGlAZ21haWwuY29tPixPdmVkIE91cmZhbGkg PG92ZWRvQHJlZGhhdC5jb20+IDwvZGl2PjxkaXY+VGVtYXQ6IFJlOiBbb3ZpcnQtdXNlcnNdIG92 aXJ0IDMuNSByYzIgYW5kIGlzY3NpIGVycm9yIHdpdGggY2hhcCBlbmFibGVkCWR1cmluZyBkaXNj b3ZlcnkgPC9kaXY+PGRpdj4KPC9kaXY+UGlvdHIsIHRoaXMgbG9va3MgbGlrZSBKU09OLVJQQyBt aXNoYXAuCkNhbiB5b3UgdGFrZSBhIGxvb2sgcGxlYXNlPwoKRnJvbTogIkdpYW5sdWNhIENlY2No aSIgPGdpYW5sdWNhLmNlY2NoaUBnbWFpbC5jb20+ClRvOiAidXNlcnMiIDx1c2Vyc0BvdmlydC5v cmc+ClNlbnQ6IFNhdHVyZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTQgMToxNTo1MCBBTQpTdWJqZWN0 OiBbb3ZpcnQtdXNlcnNdIG92aXJ0IDMuNSByYzIgYW5kIGlzY3NpIGVycm9yIHdpdGggY2hhcCBl bmFibGVkICAgICAgICBkdXJpbmcgZGlzY292ZXJ5CgpIZWxsbywKdHJ5aW5nIHRvIGNvbmZpZ3Vy ZSBpU0NTSSBzdG9yYWdlIGRvbWFpbi4KCkkgaGF2ZSBjb25maWd1cmVkIGEgQ2VudE9TIDYuNSBz ZXJ2ZXIgYXMgc3cgaVNDU0kgdGFyZ2V0IHdpdGggY2hhcCBhdXRoZW50aWNhdGlvbi4KcG9ydCAz MjYwIGlzIG9wZW4gZm9yIHRjcCBjb25uZWN0aW9ucy4KSSBoYXZlIGFuIG9WaXJ0IGhvc3QgdGhh dCBpcyBDZW50T1MgNi41IGFuZCB3aGVuIHRyeWluZyB0byBkaXNjb3ZlciB0YXJnZXRzIEkgZ2V0 IGluIC92YXIvbG9nL21lc3NhZ2VzIAoKU2VwIDEyIDIzOjUwOjE5IG92bm9kZTA0IHZkc20ganNv bnJwYy5Kc29uUnBjU2VydmVyIEVSUk9SIEludGVybmFsIHNlcnZlciBlcnJvciMwMTJUcmFjZWJh Y2sgKG1vc3QgcmVjZW50IGNhbGwgbGFzdCk6IzAxMiAgRmlsZSAiL3Vzci9saWIvcHl0aG9uMi42 L3NpdGUtcGFja2FnZXMveWFqc29ucnBjL19faW5pdF9fLnB5IiwgbGluZSA0ODYsIGluIF9zZXJ2 ZVJlcXVlc3QjMDEyIHJlcyA9IG1ldGhvZCgqKnBhcmFtcykjMDEyICBGaWxlICIvdXNyL3NoYXJl L3Zkc20vcnBjL0JyaWRnZS5weSIsIGxpbmUgMjY0LCBpbiBfZHluYW1pY01ldGhvZCMwMTIgICAg cmFpc2UgSW52YWxpZENhbGwoZm4sIG1ldGhvZEFyZ3MsIGUpIzAxMkludmFsaWRDYWxsOiBBdHRl bXB0IHRvIGNhbGwgZnVuY3Rpb246IDxib3VuZCBtZXRob2QgSVNDU0lDb25uZWN0aW9uLmRpc2Nv dmVyU2VuZFRhcmdldHMgb2YgPEFQSS5JU0NTSUNvbm5lY3Rpb24gb2JqZWN0IGF0IDB4N2YwYTQ4 MTQ1MTUwPj4gd2l0aCBhcmd1bWVudHM6ICh1J2lzY3NpdXNlcicsIHUnaXNjc2lwd2QnKSBlcnJv cjogZGlzY292ZXJTZW5kVGFyZ2V0cygpIHRha2VzIGV4YWN0bHkgMSBhcmd1bWVudCAoMyBnaXZl bikKU2VwIDEyIDIzOjUwOjIyIG92bm9kZTA0IHZkc20ganNvbnJwYy5Kc29uUnBjU2VydmVyIEVS Uk9SIEludGVybmFsIHNlcnZlciBlcnJvciMwMTJUcmFjZWJhY2sgKG1vc3QgcmVjZW50IGNhbGwg bGFzdCk6IzAxMiAgRmlsZSAiL3Vzci9saWIvcHl0aG9uMi42L3NpdGUtcGFja2FnZXMveWFqc29u cnBjL19faW5pdF9fLnB5IiwgbGluZSA0ODYsIGluIF9zZXJ2ZVJlcXVlc3QjMDEyIHJlcyA9IG1l dGhvZCgqKnBhcmFtcykjMDEyICBGaWxlICIvdXNyL3NoYXJlL3Zkc20vcnBjL0JyaWRnZS5weSIs IGxpbmUgMjY0LCBpbiBfZHluYW1pY01ldGhvZCMwMTIgICAgcmFpc2UgSW52YWxpZENhbGwoZm4s IG1ldGhvZEFyZ3MsIGUpIzAxMkludmFsaWRDYWxsOiBBdHRlbXB0IHRvIGNhbGwgZnVuY3Rpb246 IDxib3VuZCBtZXRob2QgSVNDU0lDb25uZWN0aW9uLmRpc2NvdmVyU2VuZFRhcmdldHMgb2YgPEFQ SS5JU0NTSUNvbm5lY3Rpb24gb2JqZWN0IGF0IDB4N2YwYTQ4MGU1YWQwPj4gd2l0aCBhcmd1bWVu dHM6ICh1J2lzY3NpdXNlcicsIHUnaXNjc2lwd2QnKSBlcnJvcjogZGlzY292ZXJTZW5kVGFyZ2V0 cygpIHRha2VzIGV4YWN0bHkgMSBhcmd1bWVudCAoMyBnaXZlbikKCnNjcmVlbnNob3QgdGhhdCBy ZXR1cm5zIG5vIG5ldyBkZXZpY2VzIGZvdW5kIGlzIGhlcmU6Cmh0dHBzOi8vZHJpdmUuZ29vZ2xl LmNvbS9maWxlL2QvMEJ3b1BiY3JNdjhtdmJWbHljbkpDVFdKdE5YYy9lZGl0P3VzcD1zaGFyaW5n CgpCVFc6IGNoYXAgdXNlciBhbmQgcGFzc3dvcmQgaW5wdXQgZmllbGRzIGNvdWxkIGJlIHdpZGVy LCBzbyB0aGF0IHRoZSB3aG9sZSB3b3JkcyBpbnB1dCBjYW4gc2VlbiBvbiB0aGUgc2NyZWVuLiB0 aGVyZSBpcyBwbGVudHkgb2Ygc3BhY2UuLi4gQWxzbyBwYXNzd29yZCBmaWVsZCBzaG91bGQgbm90 IGJlIGluIGNsZWFyIHRleHQgYXMgaXQgaXMgbm93CgpUaGUgYXBwcm9hY2ggdG8gc3VjY2Vzc2Z1 bGx5IGNvbm5lY3QgdGhlIExVTiBzZWVtcyB0byBiZToKMSkgbWFrZSBkaXNjb3ZlcnkgYnV0IHdp dGggY2hhcCB1bmNoZWNrZWQKMikgdGhlIHRhcmdldCB0aGVuIHNob3dzIHVwIApzZWUgCmh0dHBz Oi8vZHJpdmUuZ29vZ2xlLmNvbS9maWxlL2QvMEJ3b1BiY3JNdjhtdmIxcEVUM1ZOTVdKdVJVay9l ZGl0P3VzcD1zaGFyaW5nCjMpIG5vdyBjaGVjayB0aGUgYm94IGZvciBjaGFwIGF1dGhlbnRpY2F0 aW9uIGFuZCBzZWxlY3QgbG9naW4gYWxsCnlvdSBub3cgZ2V0IHRoZSBsdW5zCmh0dHBzOi8vZHJp dmUuZ29vZ2xlLmNvbS9maWxlL2QvMEJ3b1BiY3JNdjhtdmVFeFJNek4xWjBSdFIxay9lZGl0P3Vz cD1zaGFyaW5nCjQpIHRoZW4gc2VsZWN0IHRoZSBsdW4ocykgZGVzaXJlZCBhbmQgc2VsZWN0IE9L CgppcyB0aGlzIGNvcnJlY3Q/IEluIGNhc2UgSSB0aGluayBpdCBzaG91bGQgYmUgZGlzYWJsZWQg dGhlIGNoYXAgb3B0aW9uIGR1cmluZyBkaXNjb3ZlcnkgcGhhc2UuLi4Kb3RoZXJ3aXNlIEkgaGF2 ZSBub3QgY29uZmlndXJlZCBjb3JyZWN0bHkgbXkgaXNjc2kgdGFyZ2V0IHBlcmhhcHMuCm92aXJ0 IGhvc3QgbmV0d29yayBpcCBpcyAxMC4xMC4xLjYxCgp0Z3RhZG0gLS1sbGQgaXNjc2kgLS1tb2Rl IHRhcmdldCAtLW9wIHNob3cKVGFyZ2V0IDE6IGlxbi4yMDE0LTA3LmxvY2FsLmxvY2FsZG9tYWlu OnN0b3JlMQogICAgU3lzdGVtIGluZm9ybWF0aW9uOgogICAgICAgIERyaXZlcjogaXNjc2kKICAg ICAgICBTdGF0ZTogcmVhZHkKICAgIElfVCBuZXh1cyBpbmZvcm1hdGlvbjoKICAgICAgICBJX1Qg bmV4dXM6IDEKICAgICAgICAgICAgSW5pdGlhdG9yOiBpcW4uMTk5NC0wNS5jb20ucmVkaGF0OjVk OWIzMTMxOWE4ZQogICAgICAgICAgICBDb25uZWN0aW9uOiAwCiAgICAgICAgICAgICAgICBJUCBB ZGRyZXNzOiAxMC4xMC4xLjYxCiAgICBMVU4gaW5mb3JtYXRpb246CiAgICAgICAgTFVOOiAwCiAg ICAgICAgICAgIFR5cGU6IGNvbnRyb2xsZXIKICAgICAgICAgICAgU0NTSSBJRDogSUVUICAgICAw MDAxMDAwMAogICAgICAgICAgICBTQ1NJIFNOOiBiZWFmMTAKICAgICAgICAgICAgU2l6ZTogMCBN QiwgQmxvY2sgc2l6ZTogMQogICAgICAgICAgICBPbmxpbmU6IFllcwogICAgICAgICAgICBSZW1v dmFibGUgbWVkaWE6IE5vCiAgICAgICAgICAgIFByZXZlbnQgcmVtb3ZhbDogTm8KICAgICAgICAg ICAgUmVhZG9ubHk6IE5vCiAgICAgICAgICAgIEJhY2tpbmcgc3RvcmUgdHlwZTogbnVsbAogICAg ICAgICAgICBCYWNraW5nIHN0b3JlIHBhdGg6IE5vbmUKICAgICAgICAgICAgQmFja2luZyBzdG9y ZSBmbGFnczogCiAgICAgICAgTFVOOiAxCiAgICAgICAgICAgIFR5cGU6IGRpc2sKICAgICAgICAg ICAgU0NTSSBJRDogcF9pc2NzaV9zdG9yZTFfbAogICAgICAgICAgICBTQ1NJIFNOOiA2NjY2NmE0 MQogICAgICAgICAgICBTaXplOiAyMTQ3MzggTUIsIEJsb2NrIHNpemU6IDUxMgogICAgICAgICAg ICBPbmxpbmU6IFllcwogICAgICAgICAgICBSZW1vdmFibGUgbWVkaWE6IE5vCiAgICAgICAgICAg IFByZXZlbnQgcmVtb3ZhbDogTm8KICAgICAgICAgICAgUmVhZG9ubHk6IE5vCiAgICAgICAgICAg IEJhY2tpbmcgc3RvcmUgdHlwZTogcmR3cgogICAgICAgICAgICBCYWNraW5nIHN0b3JlIHBhdGg6 IC9kZXYvZHJiZC9ieS1yZXMvaXNjc2loYQogICAgICAgICAgICBCYWNraW5nIHN0b3JlIGZsYWdz OiAKICAgIEFjY291bnQgaW5mb3JtYXRpb246CiAgICAgICAgaXNjc2l1c2VyCiAgICBBQ0wgaW5m b3JtYXRpb246CiAgICAgICAgMTAuMTAuMS42MQogICAgICAgIDEwLjEwLjEuNjIKICAgICAgICAx MC4xMC4xLjYzCgpHaWFubHVjYQoKICAKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fClVzZXJzIG1haWxpbmcgbGlzdApVc2Vyc0BvdmlydC5vcmcKaHR0cDov L2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzCgo= ----_com.android.email_563997694433680 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5BbGxvbiw8L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2Pkl0IGxvb2tzIGxpa2Ugd2UgcGFzcyBtb3JlIGFyZ3VtZW50cyB0aGFu IHJlcWlyZWQuIFdpbGwgZml4LiBQbGVhc2Ugb3BlbiBhIGJ1Zy48L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6OXB4Ij5UaGFua3MsPC9kaXY+ PGRpdiBzdHlsZT0iZm9udC1zaXplOjlweCI+UGlvdHI8L2Rpdj48YnI+PGJyPjxkaXY+LS0tLS0t LS0gT3J5Z2luYWxuYSB3aWFkb21vxZvEhyAtLS0tLS0tLTwvZGl2PjxkaXY+T2Q6IEFsbG9uIE11 cmVpbmlrIDxhbXVyZWluaUByZWRoYXQuY29tPiA8L2Rpdj48ZGl2PkRhdGE6MTQuMDkuMjAxNCAg MDk6MjggIChHTVQrMDE6MDApIDwvZGl2PjxkaXY+RG86IFBpb3RyIEtsaWN6ZXdza2kgPHBrbGlj emV3QHJlZGhhdC5jb20+IDwvZGl2PjxkaXY+RFc6IHVzZXJzIDx1c2Vyc0BvdmlydC5vcmc+LEdp YW5sdWNhIENlY2NoaSA8Z2lhbmx1Y2EuY2VjY2hpQGdtYWlsLmNvbT4sT3ZlZCBPdXJmYWxpIDxv dmVkb0ByZWRoYXQuY29tPiA8L2Rpdj48ZGl2PlRlbWF0OiBSZTogW292aXJ0LXVzZXJzXSBvdmly dCAzLjUgcmMyIGFuZCBpc2NzaSBlcnJvciB3aXRoIGNoYXAgZW5hYmxlZAlkdXJpbmcgZGlzY292 ZXJ5IDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiB0aW1lcyBu ZXcgcm9tYW4sbmV3IHlvcmssdGltZXMsc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMw MDAwMDAiPjxkaXY+UGlvdHIsIHRoaXMgbG9va3MgbGlrZSBKU09OLVJQQyBtaXNoYXAuPC9kaXY+ PGRpdj5DYW4geW91IHRha2UgYSBsb29rIHBsZWFzZT88L2Rpdj48ZGl2Pjxicj48L2Rpdj48aHIg aWQ9Inp3Y2hyIj48YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLWxlZnQ6MnB4IHNvbGlkICMxMDEw RkY7bWFyZ2luLWxlZnQ6NXB4O3BhZGRpbmctbGVmdDo1cHg7Y29sb3I6IzAwMDtmb250LXdlaWdo dDpub3JtYWw7Zm9udC1zdHlsZTpub3JtYWw7dGV4dC1kZWNvcmF0aW9uOm5vbmU7Zm9udC1mYW1p bHk6SGVsdmV0aWNhLEFyaWFsLHNhbnMtc2VyaWY7Zm9udC1zaXplOjEycHQ7Ij48Yj5Gcm9tOiA8 L2I+IkdpYW5sdWNhIENlY2NoaSIgJmx0O2dpYW5sdWNhLmNlY2NoaUBnbWFpbC5jb20mZ3Q7PGJy PjxiPlRvOiA8L2I+InVzZXJzIiAmbHQ7dXNlcnNAb3ZpcnQub3JnJmd0Ozxicj48Yj5TZW50OiA8 L2I+U2F0dXJkYXksIFNlcHRlbWJlciAxMywgMjAxNCAxOjE1OjUwIEFNPGJyPjxiPlN1YmplY3Q6 IDwvYj5bb3ZpcnQtdXNlcnNdIG92aXJ0IDMuNSByYzIgYW5kIGlzY3NpIGVycm9yIHdpdGggY2hh cCBlbmFibGVkJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ZHVyaW5nIGRpc2NvdmVyeTxicj48ZGl2Pjxicj48L2Rpdj48ZGl2IGRpcj0ibHRyIj48ZGl2Pkhl bGxvLDxicj50cnlpbmcgdG8gY29uZmlndXJlIGlTQ1NJIHN0b3JhZ2UgZG9tYWluLjxicj48ZGl2 Pjxicj48L2Rpdj48L2Rpdj48ZGl2PkkgaGF2ZSBjb25maWd1cmVkIGEgQ2VudE9TIDYuNSBzZXJ2 ZXIgYXMgc3cgaVNDU0kgdGFyZ2V0IHdpdGggY2hhcCBhdXRoZW50aWNhdGlvbi48YnI+PC9kaXY+ PGRpdj5wb3J0IDMyNjAgaXMgb3BlbiBmb3IgdGNwIGNvbm5lY3Rpb25zLjxicj48L2Rpdj48ZGl2 PkkgaGF2ZSBhbiBvVmlydCBob3N0IHRoYXQgaXMgQ2VudE9TIDYuNSBhbmQgd2hlbiB0cnlpbmcg dG8gZGlzY292ZXIgdGFyZ2V0cyBJIGdldCBpbiAvdmFyL2xvZy9tZXNzYWdlcyA8YnI+PGRpdj48 YnI+PC9kaXY+U2VwIDEyIDIzOjUwOjE5IG92bm9kZTA0IHZkc20ganNvbnJwYy5Kc29uUnBjU2Vy dmVyIEVSUk9SIEludGVybmFsIHNlcnZlciBlcnJvciMwMTJUcmFjZWJhY2sgKG1vc3QgcmVjZW50 IGNhbGwgbGFzdCk6IzAxMiZuYnNwOyBGaWxlICIvdXNyL2xpYi9weXRob24yLjYvc2l0ZS1wYWNr YWdlcy95YWpzb25ycGMvX19pbml0X18ucHkiLCBsaW5lIDQ4NiwgaW4gX3NlcnZlUmVxdWVzdCMw MTImbmJzcDsmbmJzcDsmbmJzcDsgcmVzID0gbWV0aG9kKCoqcGFyYW1zKSMwMTImbmJzcDsgRmls ZSAiL3Vzci9zaGFyZS92ZHNtL3JwYy9CcmlkZ2UucHkiLCBsaW5lIDI2NCwgaW4gX2R5bmFtaWNN ZXRob2QjMDEyJm5ic3A7Jm5ic3A7Jm5ic3A7IHJhaXNlIEludmFsaWRDYWxsKGZuLCBtZXRob2RB cmdzLCBlKSMwMTJJbnZhbGlkQ2FsbDogQXR0ZW1wdCB0byBjYWxsIGZ1bmN0aW9uOiAmbHQ7Ym91 bmQgbWV0aG9kIElTQ1NJQ29ubmVjdGlvbi5kaXNjb3ZlclNlbmRUYXJnZXRzIG9mICZsdDtBUEku SVNDU0lDb25uZWN0aW9uIG9iamVjdCBhdCAweDdmMGE0ODE0NTE1MCZndDsmZ3Q7IHdpdGggYXJn dW1lbnRzOiAodSdpc2NzaXVzZXInLCB1J2lzY3NpcHdkJykgZXJyb3I6IGRpc2NvdmVyU2VuZFRh cmdldHMoKSB0YWtlcyBleGFjdGx5IDEgYXJndW1lbnQgKDMgZ2l2ZW4pPGJyPlNlcCAxMiAyMzo1 MDoyMiBvdm5vZGUwNCB2ZHNtIGpzb25ycGMuSnNvblJwY1NlcnZlciBFUlJPUiBJbnRlcm5hbCBz ZXJ2ZXIgZXJyb3IjMDEyVHJhY2ViYWNrIChtb3N0IHJlY2VudCBjYWxsIGxhc3QpOiMwMTImbmJz cDsgRmlsZSAiL3Vzci9saWIvcHl0aG9uMi42L3NpdGUtcGFja2FnZXMveWFqc29ucnBjL19faW5p dF9fLnB5IiwgbGluZSA0ODYsIGluIF9zZXJ2ZVJlcXVlc3QjMDEyJm5ic3A7Jm5ic3A7Jm5ic3A7 IHJlcyA9IG1ldGhvZCgqKnBhcmFtcykjMDEyJm5ic3A7IEZpbGUgIi91c3Ivc2hhcmUvdmRzbS9y cGMvQnJpZGdlLnB5IiwgbGluZSAyNjQsIGluIF9keW5hbWljTWV0aG9kIzAxMiZuYnNwOyZuYnNw OyZuYnNwOyByYWlzZSBJbnZhbGlkQ2FsbChmbiwgbWV0aG9kQXJncywgZSkjMDEySW52YWxpZENh bGw6IEF0dGVtcHQgdG8gY2FsbCBmdW5jdGlvbjogJmx0O2JvdW5kIG1ldGhvZCBJU0NTSUNvbm5l Y3Rpb24uZGlzY292ZXJTZW5kVGFyZ2V0cyBvZiAmbHQ7QVBJLklTQ1NJQ29ubmVjdGlvbiBvYmpl Y3QgYXQgMHg3ZjBhNDgwZTVhZDAmZ3Q7Jmd0OyB3aXRoIGFyZ3VtZW50czogKHUnaXNjc2l1c2Vy JywgdSdpc2NzaXB3ZCcpIGVycm9yOiBkaXNjb3ZlclNlbmRUYXJnZXRzKCkgdGFrZXMgZXhhY3Rs eSAxIGFyZ3VtZW50ICgzIGdpdmVuKTxicj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48ZGl2PnNjcmVl bnNob3QgdGhhdCByZXR1cm5zIG5vIG5ldyBkZXZpY2VzIGZvdW5kIGlzIGhlcmU6PGJyPjxhIGhy ZWY9Imh0dHBzOi8vZHJpdmUuZ29vZ2xlLmNvbS9maWxlL2QvMEJ3b1BiY3JNdjhtdmJWbHljbkpD VFdKdE5YYy9lZGl0P3VzcD1zaGFyaW5nIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kcml2ZS5n b29nbGUuY29tL2ZpbGUvZC8wQndvUGJjck12OG12YlZseWNuSkNUV0p0TlhjL2VkaXQ/dXNwPXNo YXJpbmc8L2E+PGJyPjxkaXY+PGJyPjwvZGl2PjwvZGl2PjxkaXY+QlRXOiBjaGFwIHVzZXIgYW5k IHBhc3N3b3JkIGlucHV0IGZpZWxkcyBjb3VsZCBiZSB3aWRlciwgc28gdGhhdCB0aGUgd2hvbGUg d29yZHMgaW5wdXQgY2FuIHNlZW4gb24gdGhlIHNjcmVlbi4gdGhlcmUgaXMgcGxlbnR5IG9mIHNw YWNlLi4uIEFsc28gcGFzc3dvcmQgZmllbGQgc2hvdWxkIG5vdCBiZSBpbiBjbGVhciB0ZXh0IGFz IGl0IGlzIG5vdzxicj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48ZGl2PlRoZSBhcHByb2FjaCB0byBz dWNjZXNzZnVsbHkgY29ubmVjdCB0aGUgTFVOIHNlZW1zIHRvIGJlOjxicj48L2Rpdj48ZGl2PjEp IG1ha2UgZGlzY292ZXJ5IGJ1dCB3aXRoIGNoYXAgdW5jaGVja2VkPGJyPjwvZGl2PjxkaXY+Mikg dGhlIHRhcmdldCB0aGVuIHNob3dzIHVwIDxicj48L2Rpdj48ZGl2PnNlZSA8YnI+PGEgaHJlZj0i aHR0cHM6Ly9kcml2ZS5nb29nbGUuY29tL2ZpbGUvZC8wQndvUGJjck12OG12YjFwRVQzVk5NV0p1 UlVrL2VkaXQ/dXNwPXNoYXJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RyaXZlLmdvb2ds ZS5jb20vZmlsZS9kLzBCd29QYmNyTXY4bXZiMXBFVDNWTk1XSnVSVWsvZWRpdD91c3A9c2hhcmlu ZzwvYT48YnI+PC9kaXY+PGRpdj4zKSBub3cgY2hlY2sgdGhlIGJveCBmb3IgY2hhcCBhdXRoZW50 aWNhdGlvbiBhbmQgc2VsZWN0IGxvZ2luIGFsbDxicj55b3Ugbm93IGdldCB0aGUgbHVuczxicj48 YSBocmVmPSJodHRwczovL2RyaXZlLmdvb2dsZS5jb20vZmlsZS9kLzBCd29QYmNyTXY4bXZlRXhS TXpOMVowUnRSMWsvZWRpdD91c3A9c2hhcmluZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZHJp dmUuZ29vZ2xlLmNvbS9maWxlL2QvMEJ3b1BiY3JNdjhtdmVFeFJNek4xWjBSdFIxay9lZGl0P3Vz cD1zaGFyaW5nPC9hPjxicj48L2Rpdj48ZGl2PjQpIHRoZW4gc2VsZWN0IHRoZSBsdW4ocykgZGVz aXJlZCBhbmQgc2VsZWN0IE9LPGJyPjxkaXY+PGJyPjwvZGl2PjwvZGl2PjxkaXY+aXMgdGhpcyBj b3JyZWN0PyBJbiBjYXNlIEkgdGhpbmsgaXQgc2hvdWxkIGJlIGRpc2FibGVkIHRoZSBjaGFwIG9w dGlvbiBkdXJpbmcgZGlzY292ZXJ5IHBoYXNlLi4uPGJyPjwvZGl2PjxkaXY+b3RoZXJ3aXNlIEkg aGF2ZSBub3QgY29uZmlndXJlZCBjb3JyZWN0bHkgbXkgaXNjc2kgdGFyZ2V0IHBlcmhhcHMuPGJy Pm92aXJ0IGhvc3QgbmV0d29yayBpcCBpcyAxMC4xMC4xLjYxPGJyPjxkaXY+PGJyPjwvZGl2PnRn dGFkbSAtLWxsZCBpc2NzaSAtLW1vZGUgdGFyZ2V0IC0tb3Agc2hvdzxicj5UYXJnZXQgMTogaXFu LjIwMTQtMDcubG9jYWwubG9jYWxkb21haW46c3RvcmUxPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBT eXN0ZW0gaW5mb3JtYXRpb246PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBEcml2ZXI6IGlzY3NpPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBTdGF0ZTogcmVhZHk8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IElfVCBuZXh1cyBp bmZvcm1hdGlvbjo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IElfVCBuZXh1czogMTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW5pdGlhdG9yOiBpcW4uMTk5NC0wNS5jb20ucmVk aGF0OjVkOWIzMTMxOWE4ZTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29ubmVjdGlvbjogMDxicj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSVAgQWRkcmVzczogMTAuMTAuMS42MTxicj4mbmJzcDsm bmJzcDsmbmJzcDsgTFVOIGluZm9ybWF0aW9uOjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgTFVOOiAwPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUeXBlOiBjb250cm9sbGVyPGJy PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBTQ1NJIElEOiBJRVQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMDAwMTAwMDA8 YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFNDU0kgU046IGJlYWYxMDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2l6ZTogMCBNQiwgQmxv Y2sgc2l6ZTogMTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT25saW5lOiBZZXM8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlbW92YWJs ZSBtZWRpYTogTm88YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByZXZlbnQgcmVtb3ZhbDogTm88YnI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFJlYWRvbmx5OiBObzxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQmFja2luZyBzdG9yZSB0eXBlOiBudWxsPGJyPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBCYWNraW5nIHN0b3JlIHBhdGg6IE5vbmU8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJhY2tpbmcgc3Rv cmUgZmxhZ3M6IDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg TFVOOiAxPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBUeXBlOiBkaXNrPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTQ1NJIElEOiBwX2lz Y3NpX3N0b3JlMV9sPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTQ1NJIFNOOiA2NjY2NmE0MTxicj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg U2l6ZTogMjE0NzM4IE1CLCBCbG9jayBzaXplOiA1MTI8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9ubGluZTogWWVz PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBSZW1vdmFibGUgbWVkaWE6IE5vPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQcmV2ZW50IHJl bW92YWw6IE5vPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWFkb25seTogTm88YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJhY2tpbmcg c3RvcmUgdHlwZTogcmR3cjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQmFja2luZyBzdG9yZSBwYXRoOiAvZGV2L2Ry YmQvYnktcmVzL2lzY3NpaGE8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJhY2tpbmcgc3RvcmUgZmxhZ3M6IDxicj4m bmJzcDsmbmJzcDsmbmJzcDsgQWNjb3VudCBpbmZvcm1hdGlvbjo8YnI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzY3NpdXNlcjxicj4mbmJzcDsmbmJzcDsmbmJz cDsgQUNMIGluZm9ybWF0aW9uOjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgMTAuMTAuMS42MTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgMTAuMTAuMS42Mjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgMTAuMTAuMS42Mzxicj48L2Rpdj48YnI+PGRpdj5HaWFubHVjYTxicj48ZGl2Pjxi cj48L2Rpdj4mbmJzcDsgPGJyPjwvZGl2PjwvZGl2Pgo8YnI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+VXNlcnMgbWFpbGluZyBsaXN0PGJyPlVzZXJz QG92aXJ0Lm9yZzxicj5odHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNl cnM8YnI+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjwvZGl2PjwvYm9keT4= ----_com.android.email_563997694433680--

2 1

An error occurring in the OVirt_Engine_Development_Environment
by Xie, Chao 14 Sep '14

14 Sep '14

--_004_EE4D679B9474414187D2E27D8B6890F6932C8AG08CNEXMBPEKD03g0_ Content-Type: multipart/alternative; boundary="_000_EE4D679B9474414187D2E27D8B6890F6932C8AG08CNEXMBPEKD03g0_" --_000_EE4D679B9474414187D2E27D8B6890F6932C8AG08CNEXMBPEKD03g0_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksYWxsDQogICAgICAgICBJIHRyaWVkIHRvIGJ1bGlkIGEgT1ZpcnRfRW5naW5lX0RldmVsb3Bt ZW50X0Vudmlyb25tZW50IGZvbGxvd2luZyB0aGUgaHR0cDovL3dpa2kub3ZpcnQub3JnL09WaXJ0 X0VuZ2luZV9EZXZlbG9wbWVudF9FbnZpcm9ubWVudC4NCiAgICAgICAgIFdoZW4gSSBwcmVwYXJl ZCB0aGUgc291cmNlIGNvZGUgYW5kIGVudmlyb25tZW50ICwgSSBleGVjdXRlIKGwbWFrZSBpbnN0 YWxsLWRldiBQUkVGSVg9IiRIT01FL292aXJ0LWVuZ2luZSIgYW5kIGFuIGVycm9yIHdhcyBwcm9t cHRlZCBhcyBiZWxvdy4NCg0KPT09PT09PT09PT09PT09PQ0KaWYgWyAiMSIgIT0gMCBdOyB0aGVu IFwNCiAgICAgICAgICAgICAgICAgICBidWlsZC9zaGVsbC1jaGVjay5zaCAmJiBcDQogICAgICAg ICAgICAgICAgICAgYnVpbGQvcHl0aG9uLWNoZWNrLnNoICYmIFwNCiAgICAgICAgICAgICAgICAg ICBidWlsZC9kYnNjcmlwdHMtZHVwbGljYXRlX3VwZ3JhZGVfc2NyaXB0cy5zaDsgXA0KICAgICAg ICAgZmkNCnBhY2thZ2luZy9iaW4vcGtpLWNvbW1vbi5zaDogMzM6IFN5bnRheCBlcnJvcjogZW5k IG9mIGZpbGUgdW5leHBlY3RlZCAoZXhwZWN0aW5nICJ0aGVuIikNCjogTm8gc3VjaCBmaWxlIG9y IGRpcmVjdG9yeTU3OiAvYmluL3NoDQpwYWNrYWdpbmcvYmluL2VuZ2luZS1wcm9sb2cuc2g6IDE5 OiBTeW50YXggZXJyb3I6IHdvcmQgdW5leHBlY3RlZCAoZXhwZWN0aW5nICJkbyIpDQo6IE5vIHN1 Y2ggZmlsZSBvciBkaXJlY3Rvcnk1NzogL2Jpbi9zaA0KOiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0 b3J5NTc6IC9iaW4vc2gNCjogTm8gc3VjaCBmaWxlIG9yIGRpcmVjdG9yeTU3OiAvYmluL3NoDQo6 IE5vIHN1Y2ggZmlsZSBvciBkaXJlY3Rvcnk1NzogL2Jpbi9zaA0KOiBObyBzdWNoIGZpbGUgb3Ig ZGlyZWN0b3J5NTc6IC9iaW4vc2gNCm1ha2VbMV06ICoqKiBbdmFsaWRhdGlvbnNdIEVycm9yIDEN Cm1ha2VbMV06IExlYXZpbmcgZGlyZWN0b3J5IGAvaG9tZS9vbmx5ZWxsb3cvb3ZpcnQtZW5naW5l Jw0KbWFrZTogKioqIFthbGwtZGV2XSBFcnJvciAyDQoNCj09PT09PT09PT09PT09PT09PT09PT0N Cg0KSSBjaGVjayB0aGUgobBwYWNrYWdpbmcvYmluL3BraS1jb21tb24uc2ihsSBhbmQgZmluZCBp dCBzZWVtcyB3ZWxsICh0aGUgYXR0ZW5kbWVudCkuIERvZXMgYW55Ym9keSBoYXZlIHRoZSBzYW1l IHByb2JsZW0/DQo= --_000_EE4D679B9474414187D2E27D8B6890F6932C8AG08CNEXMBPEKD03g0_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312"> <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple" style=3D"text-justify-t= rim:punctuation"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US">Hi,all<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">     &= nbsp;   I tried to bulid a OVirt_Engine_Development_Environment f= ollowing the <a href=3D"http://wiki.ovirt.org/OVirt_Engine_Development_Environment">http= ://wiki.ovirt.org/OVirt_Engine_Development_Environment</a>.<o:p></o:p></spa= n></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">     &= nbsp;   When I prepared the source code and environment , I execu= te =A1=B0make install-dev PREFIX=3D"$HOME/ovirt-engine" and an er= ror was prompted as below.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">if [ "1" !=3D 0 ]; th= en \<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">     &= nbsp;           &nbs= p; build/shell-check.sh && \<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">     &= nbsp;           &nbs= p; build/python-check.sh && \<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">     &= nbsp;           &nbs= p; build/dbscripts-duplicate_upgrade_scripts.sh; \<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">     &= nbsp;   fi<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">packaging/bin/pki-common.sh: 33= : Syntax error: end of file unexpected (expecting "then")<o:p></o= :p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">: No such file or directory57: = /bin/sh<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">packaging/bin/engine-prolog.sh:= 19: Syntax error: word unexpected (expecting "do")<o:p></o:p></s= pan></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">: No such file or directory57: = /bin/sh<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">: No such file or directory57: = /bin/sh<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">: No such file or directory57: = /bin/sh<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">: No such file or directory57: = /bin/sh<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">: No such file or directory57: = /bin/sh<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">make[1]: *** [validations] Erro= r 1<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">make[1]: Leaving directory `/ho= me/onlyellow/ovirt-engine'<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">make: *** [all-dev] Error 2<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">I check the =A1=B0packaging/bin= /pki-common.sh=A1=B1 and find it seems well (the attendment). Does anybody = have the same problem?<o:p></o:p></span></p> </div> </body> </html> --_000_EE4D679B9474414187D2E27D8B6890F6932C8AG08CNEXMBPEKD03g0_-- --_004_EE4D679B9474414187D2E27D8B6890F6932C8AG08CNEXMBPEKD03g0_ Content-Type: application/octet-stream; name="pki-common.sh" Content-Description: pki-common.sh Content-Disposition: attachment; filename="pki-common.sh"; size=683; creation-date="Sun, 14 Sep 2014 07:32:28 GMT"; modification-date="Sun, 14 Sep 2014 10:39:59 GMT" Content-Transfer-Encoding: base64 DQpQS0lESVI9Ii9ob21lL29ubHllbGxvdy9vdmlydC1lbmdpbmUvZXRjL3BraS9vdmlydC1lbmdp bmUiDQpVU1JESVI9Ii9ob21lL29ubHllbGxvdy9vdmlydC1lbmdpbmUvc2hhcmUvb3ZpcnQtZW5n aW5lIg0KQklORElSPSIke1VTUkRJUn0vYmluIg0KDQpkaWUoKSB7DQoJbG9jYWwgbT0iJDEiDQoJ ZWNobyAiJG0iID4mMg0KCWV4aXQgMQ0KfQ0KDQpjb21tb25fYmFja3VwKCkgew0KCWxvY2FsIHRp bWU9IiQoZGF0ZSArIiVZJW0lZCVIJU0lUyIpIg0KDQoJd2hpbGUgWyAtbiAiJDEiIF07IGRvDQoJ CWxvY2FsIGY9IiQxIg0KCQlzaGlmdA0KCQlpZiBbIC1mICIke2Z9IiBdOyB0aGVuDQoJCQljcCAt YSAiJHtmfSIgIiR7Zn0uJHt0aW1lfSIgfHwgXA0KCQkJCWRpZSAiRmFpbGVkIHRvIGJhY2t1cCAk e2Z9Ig0KCQlmaQ0KCWRvbmUNCn0NCg0KY29tbW9uX3Jlc3RvcmVfcGVybXMoKSB7DQoJbG9jYWwg cGtpZGlyPSIkMSINCg0KCSMgb3BlbnNzbCBhbHdheXMgcmVzZXQgb3duZXJzaGlwDQoJIyBvZiB0 aGVzZSBmaWxlcywgc28gd2UgaGF2ZSB0byByZXNldA0KCSMgb3VyIGRlZmF1bHRzDQoJY2hvd24g LS1yZWZlcmVuY2U9IiR7cGtpZGlyfSIgIiR7cGtpZGlyfSIvc2VyaWFsLnR4dCogIiR7cGtpZGly fSIvZGF0YWJhc2UudHh0KiAiJHtwa2lkaXJ9Ii8ucm5kKiA+IC9kZXYvbnVsbCAyPiYxDQp9DQo= --_004_EE4D679B9474414187D2E27D8B6890F6932C8AG08CNEXMBPEKD03g0_--

1 1

ovirt 3.5 rc2 and iscsi error with chap enabled during discovery
by Gianluca Cecchi 14 Sep '14

14 Sep '14

Hello, trying to configure iSCSI storage domain. I have configured a CentOS 6.5 server as sw iSCSI target with chap authentication. port 3260 is open for tcp connections. I have an oVirt host that is CentOS 6.5 and when trying to discover targets I get in /var/log/messages Sep 12 23:50:19 ovnode04 vdsm jsonrpc.JsonRpcServer ERROR Internal server error#012Traceback (most recent call last):#012 File "/usr/lib/python2.6/site-packages/yajsonrpc/__init__.py", line 486, in _serveRequest#012 res = method(**params)#012 File "/usr/share/vdsm/rpc/Bridge.py", line 264, in _dynamicMethod#012 raise InvalidCall(fn, methodArgs, e)#012InvalidCall: Attempt to call function: <bound method ISCSIConnection.discoverSendTargets of <API.ISCSIConnection object at 0x7f0a48145150>> with arguments: (u'iscsiuser', u'iscsipwd') error: discoverSendTargets() takes exactly 1 argument (3 given) Sep 12 23:50:22 ovnode04 vdsm jsonrpc.JsonRpcServer ERROR Internal server error#012Traceback (most recent call last):#012 File "/usr/lib/python2.6/site-packages/yajsonrpc/__init__.py", line 486, in _serveRequest#012 res = method(**params)#012 File "/usr/share/vdsm/rpc/Bridge.py", line 264, in _dynamicMethod#012 raise InvalidCall(fn, methodArgs, e)#012InvalidCall: Attempt to call function: <bound method ISCSIConnection.discoverSendTargets of <API.ISCSIConnection object at 0x7f0a480e5ad0>> with arguments: (u'iscsiuser', u'iscsipwd') error: discoverSendTargets() takes exactly 1 argument (3 given) screenshot that returns no new devices found is here: https://drive.google.com/file/d/0BwoPbcrMv8mvbVlycnJCTWJtNXc/edit?usp=shari… BTW: chap user and password input fields could be wider, so that the whole words input can seen on the screen. there is plenty of space... Also password field should not be in clear text as it is now The approach to successfully connect the LUN seems to be: 1) make discovery but with chap unchecked 2) the target then shows up see https://drive.google.com/file/d/0BwoPbcrMv8mvb1pET3VNMWJuRUk/edit?usp=shari… 3) now check the box for chap authentication and select login all you now get the luns https://drive.google.com/file/d/0BwoPbcrMv8mveExRMzN1Z0RtR1k/edit?usp=shari… 4) then select the lun(s) desired and select OK is this correct? In case I think it should be disabled the chap option during discovery phase... otherwise I have not configured correctly my iscsi target perhaps. ovirt host network ip is 10.10.1.61 tgtadm --lld iscsi --mode target --op show Target 1: iqn.2014-07.local.localdomain:store1 System information: Driver: iscsi State: ready I_T nexus information: I_T nexus: 1 Initiator: iqn.1994-05.com.redhat:5d9b31319a8e Connection: 0 IP Address: 10.10.1.61 LUN information: LUN: 0 Type: controller SCSI ID: IET 00010000 SCSI SN: beaf10 Size: 0 MB, Block size: 1 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: null Backing store path: None Backing store flags: LUN: 1 Type: disk SCSI ID: p_iscsi_store1_l SCSI SN: 66666a41 Size: 214738 MB, Block size: 512 Online: Yes Removable media: No Prevent removal: No Readonly: No Backing store type: rdwr Backing store path: /dev/drbd/by-res/iscsiha Backing store flags: Account information: iscsiuser ACL information: 10.10.1.61 10.10.1.62 10.10.1.63 Gianluca

2 1

lost connectivty to the ovirt-engine after adding host
by Ramon Ramirez-Linan 14 Sep '14

14 Sep '14

Hi, I am working on a proof of concept using using oVirt and ManageIQ. I have a CentOS6.5 where I deployed libvirt, I create a VM where I deployed oVirt 3.4. I was trying to add the host where the VM with oVirt resides. After much troubleshooting I was able to add the host but now the oVirt VM is owned by a user vdsm which I dont know the password for, so I can't start the VM with oVirt. This is the result of running virsh list ==================== $virsh list Please enter your authentication name: vdsm@ovirt Please enter your password: error: Failed to reconnect to the hypervisor error: no valid connection error: authentication failed: authentication failed ======================== I added another user with the command ------------ saslpasswd2 -a libvirt [username] ------------ I used that username and password to connect and to do ------------ virsh list -all ------------ That shows the VM but If i try to start it it gives me an error like follows error: Failed to start domain Cent6.5 error: internal error Process exited while reading console log output: char device redirected to /dev/pts/1 qemu-kvm: -drive file=/ovirt/test/virtlive01/miq_demo/cent01.img,if=none,id=drive-virtio-disk0,format=raw,cache=none: could not open disk image /ovirt/test/virtlive01/miq_demo/cent01.img: Permission denied Any ideas how can start that VM? is there a default password for the user vdsm

1 0

[RFI] oVirt 3.6 Planning
by Paul Jansen 14 Sep '14

14 Sep '14

---1212189890-1261065207-1410659964=:78009 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable My vote is for storage load balancing/scheduler.=0AVmware's Vcenter has the= concept of a 'storage cluster'. It's essentially a logical storage devic= e.=0AWhen you configure hosts/vms to use this device vcenter then works out= which of the actual storage devices underneath this logical device is will= send the storage requests to.=0AThis works out as a basic form of load bal= acing by alternating where the storage for new vms are created.=0AThis isn'= t particularly amazing, but what it does allow - with the highest end vcent= er licensing anyway - is what Vmware calls 'storage distributed resource sc= heduling'.=0AMuch like we already have the ability to have a scheduler that= moves the execution of vms around on hosts based on load, this does the sa= me thing for the storage component of VM.=0AImagine having two configured s= torage locations under a 'storage cluster' and then having the ability to p= ut one of the storage locations into 'maintenance mode'. The storage sched= uler would then 'live storage migrate' all the storage for vms over to the = other storage location. This would then allow the first storage location t= o be taken down for maintenance.=0AThis approach also allows storage to sca= le over time as more is added. The 'storage scheduler' can take inputs suc= h as latency etc into account and manage the load across the 'storage clust= er' to balance things out and make smart decisions so that the avaialble st= orage is utilized as best as it can be (ie: not overloading one storage loc= ation while the other location is mainly idle).=0A=0A=0AI've done a bit a s= earching to see where Ovirt might be up to in this regard and what I've fou= nd seems to indicate that we are not anywhere near this capability just yet= .=0AAn important prerequisite is having the hosts able to actually do a liv= e storage migration. EL7 based hosts under ovirt 3.5 have this, as have Fe= dora 19 and 20 hosts.=0AIf the decision is made to use qemu-kvm-rhev on EL6= hosts - as has been talked about recently - then the host requirement for = supporting live storage migration will be met. This then allows the idea o= f a storage scheduler to be futher considered.=0A=0AI think this is an impo= rtant step in reaching feature parity with Vmware's vcenter product, and re= moves a key reason ovirt/rhev can't be considered in some instances.=0A ---1212189890-1261065207-1410659964=:78009 Content-Type: text/html; charset=utf-8 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"><div>My vote is for storage load balancing/scheduler.</div><d= iv>Vmware's Vcenter has the concept of a 'storage cluster'.   It'= s essentially a logical storage device.</div><div>When you configure hosts/= vms to use this device vcenter then works out which of the actual storage d= evices underneath this logical device is will send the storage requests to.= </div><div>This works out as a basic form of load balacing by alternating w= here the storage for new vms are created.</div><div>This isn't particularly= amazing, but what it does allow - with the highest end vcenter licensing a= nyway - is what Vmware calls 'storage distributed resource scheduling'.</di= v><div>Much like we already have the ability to have a scheduler that moves= the execution of vms around on hosts based on load, this does the same thing for the storage component of VM.</div><div>Imagine having two c= onfigured storage locations under a 'storage cluster' and then having the a= bility to put one of the storage locations into 'maintenance mode'.  T= he storage scheduler would then 'live storage migrate' all the storage for = vms over to the other storage location.  This would then allow the fir= st storage location to be taken down for maintenance.</div><div>This approa= ch also allows storage to scale over time as more is added.  The 'stor= age scheduler' can take inputs such as latency etc into account and manage = the load across the 'storage cluster' to balance things out and make smart = decisions so that the avaialble storage is utilized as best as it can be (i= e: not overloading one storage location while the other location is mainly = idle).<br></div><div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-fa= mily: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><br= ><span></span></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;"><span>I've done a= bit a searching to see where Ovirt might be up to in this regard and what = I've found seems to indicate that we are not anywhere near this capability = just yet.</span></div><div style=3D"color: rgb(0, 0, 0); font-size: 16px; f= ont-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans= -serif; background-color: transparent; font-style: normal;"><span>An import= ant prerequisite is having the hosts able to actually do a live storage mig= ration.  EL7 based hosts under ovirt 3.5 have this, as have Fedora 19 = and 20 hosts.</span></div><div style=3D"color: rgb(0, 0, 0); font-size: 16p= x; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><sp= an>If the decision is made to use qemu-kvm-rhev on EL6 hosts - as has been = talked about recently - then the host requirement for supporting live stora= ge migration will be met.  This then allows the idea of a storage sche= duler to be futher considered.</span></div><div style=3D"color: rgb(0, 0, 0= ); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Ari= al,Lucida Grande,sans-serif; background-color: transparent; font-style: nor= mal;"><br><span></span></div><div style=3D"color: rgb(0, 0, 0); font-size: = 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Gran= de,sans-serif; background-color: transparent; font-style: normal;"><span>I = think this is an important step in reaching feature parity with Vmware's vc= enter product, and removes a key reason ovirt/rhev can't be considered in s= ome instances.</span></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;"><span><= br></span></div></div></body></html> ---1212189890-1261065207-1410659964=:78009--

1 0

: password authentication failed for user "engine"
by Ramon Ramirez-Linan 13 Sep '14

13 Sep '14

Hello, New to the list and relatively new to oVirt I am trying to deploy the "all in one" for ovirt3.4. But the engine-setup script is stuck in the process of creating the db schema reating PostgreSQL 'engine' database [ INFO ] Configuring PostgreSQL [ INFO ] Creating Engine database schema [ ERROR ] Failed to execute stage 'Misc configuration': Command '/usr/share/ovirt-engine/dbscripts/create_schema.sh' failed to execute [ INFO ] Yum Performing yum transaction rollback [ INFO ] Rolling back database schema - OperationalError: FATAL: password authentication failed for user "engine" .FATAL: password authentication failed for user "engine" Any suggestions would be greatly appreciate Thanks Rezuma

2 2

feature review - ReportGuestDisksLogicalDeviceName
by Liron Aravot 13 Sep '14

13 Sep '14

Feel free to review the the following feature. http://www.ovirt.org/Features/ReportGuestDisksLogicalDeviceName

5 7

VDSM and iSCSI issue due to ulimits
by Trey Dockendorf 12 Sep '14

12 Sep '14

Today I got an alert from monitoring systems that my EL7 MariaDB VM was down. I looked in oVirt and it showed the VM as "paused due to storage I/O problem". That VM is the only one currently attached to disks that are on an iSCSI storage domain. That iSCSI storage domain uses iSER (over DDR Infiniband). My instance is made up of two ovirt nodes, both with CentOS 6.5 running oVirt 3.4.3. The host that was running this VM has 16 running VMs total. I looked at the vdsm logs for the hypervisor and found log entries with "No free file handlers in pool". Below are logs. I quick "google" showed old posts about it being a ulimit problem. Right now after resuming the paused VM I see this on the VDSM server # lsof -u vdsm | wc -l 2377 # sudo -H -u vdsm -s ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 1032295 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 12288 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 4096 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited If the issue was due to number of open files, is it the case that if the only VM using the iSCSI storage domain was paused, the file descriptors were flushed? How do I go about finding out the cause of this, so I can prevent future issues? Is the fix to just increase the "nofile" ulimit for vdsm in /etc/security/limits.d/99-vdsm.conf? Thanks, - Trey LOGS: Sep 12 12:10:49 ovirtnode01 vdsm TaskManager.Task ERROR Task=`f467714c-8948-4cc3-94af-efba6b67701c`::Unexpected error#012Traceback (most recent call last):#012 File "/usr/share/vdsm/storage/task.py", line 873, in _run#012 return fn(*args, **kargs)#012 File "/usr/share/vdsm/logUtils.py", line 45, in wrapper#012 res = f(*args, **kwargs)#012 File "/usr/share/vdsm/storage/hsm.py", line 3055, in getVolumeSize#012 apparentsize = str(dom.getVSize(imgUUID, volUUID))#012 File "/usr/share/vdsm/storage/fileSD.py", line 314, in getVSize#012 return self.oop.os.stat(volPath).st_size#012 File "/usr/share/vdsm/storage/remoteFileHandler.py", line 312, in callCrabRPCFunction#012 raise Exception("No free file handlers in pool")#012Exception: No free file handlers in pool Sep 12 12:10:49 ovirtnode01 vdsm vm.Vm ERROR vmId=`967dce86-63c2-412a-97c5-d7c6f1af8dfb`::Unable to update the volume 92c6cfd0-c236-44ab-894d-cb80421dd865 (domain: 6da59b00-0de7-4219-960b-d581b27052b5 image: 06060f34-12c5-4396-bfe3-ad0f1d4b03fc) for the drive vda Sep 12 12:10:54 ovirtnode01 sanlock[3379]: 2014-09-12 12:10:54-0500 1773913 [5185]: s1 delta_renew read rv -202 offset 0 /rhev/data-center/mnt/192.168.211.245:_tank_ovirt_data/6da59b00-0de7-4219-960b-d581b27052b5/dom_md/ids Sep 12 12:10:54 ovirtnode01 sanlock[3379]: 2014-09-12 12:10:54-0500 1773913 [5185]: s1 renewal error -202 delta_length 10 last_success 1773883 <repeats a few times> Sep 12 12:10:58 ovirtnode01 vdsm vm.Vm ERROR vmId=`151972dc-0025-470e-bdfe-38d3b085a63c`::Unable to update the volume 1b589b1b-aeb8-4a7a-a005-d5042de47f36 (domain: 6da59b00-0de7-4219-960b-d581b27052b5 image: 5d9456a3-12e1-4e50-b899-b12430a4fdb9) for the drive vda Sep 12 12:10:58 ovirtnode01 vdsm vm.Vm ERROR vmId=`b15f90ff-f359-447a-b309-2cf64d01d0ce`::Unable to update the volume 70a0fee4-2dd3-4460-94da-9ddbfb66845b (domain: 6da59b00-0de7-4219-960b-d581b27052b5 image: 4e133730-f549-4b49-a8e9-baedaca4c1f1) for the drive vda <snip> Then lines like this: Sep 12 12:11:49 ovirtnode01 sanlock[3379]: 2014-09-12 12:11:49-0500 1773968 [5185]: s1 delta_renew read rv -2 offset 0 /rhev/data-center/mnt/192.168.211.245:_tank_ovirt_data/6da59b00-0de7-4219-960b-d581b27052b5/dom_md/ids Sep 12 12:11:49 ovirtnode01 sanlock[3379]: 2014-09-12 12:11:49-0500 1773968 [5185]: s1 renewal error -2 delta_length 10 last_success 1773883 Sep 12 12:11:49 ovirtnode01 vdsm TaskManager.Task ERROR Task=`b39a6636-451e-409c-9a81-7392000206d3`::Unexpected error#012Traceback (most recent call last):#012 File "/usr/share/vdsm/storage/task.py", line 873, in _run#012 return fn(*args, **kargs)#012 File "/usr/share/vdsm/logUtils.py", line 45, in wrapper#012 res = f(*args, **kwargs)#012 File "/usr/share/vdsm/storage/hsm.py", line 3055, in getVolumeSize#012 apparentsize = str(dom.getVSize(imgUUID, volUUID))#012 File "/usr/share/vdsm/storage/fileSD.py", line 314, in getVSize#012 return self.oop.os.stat(volPath).st_size#012 File "/usr/share/vdsm/storage/remoteFileHandler.py", line 297, in callCrabRPCFunction#012 *args, **kwargs)#012 File "/usr/share/vdsm/storage/remoteFileHandler.py", line 184, in callCrabRPCFunction#012 rawLength = self._recvAll(LENGTH_STRUCT_LENGTH, timeout)#012 File "/usr/share/vdsm/storage/remoteFileHandler.py", line 150, in _recvAll#012 raise Timeout()#012Timeout Sep 12 12:11:49 ovirtnode01 vdsm vm.Vm ERROR vmId=`ca242da9-b7ad-41e2-a26a-db2fea2e49d7`::Unable to update the volume 03baf076-ef59-41f6-9cab-8cd64cd89307 (domain: 6da59b00-0de7-4219-960b-d581b27052b5 image: d1960266-0a06-4b2a-a15d-141612aff740) for the drive vda Sep 12 12:11:59 ovirtnode01 sanlock[3379]: 2014-09-12 12:11:59-0500 1773978 [5185]: 6da59b00 close_task_aio 0 0x7f3dfc0008c0 busy Sep 12 12:11:59 ovirtnode01 sanlock[3379]: 2014-09-12 12:11:59-0500 1773978 [5185]: 6da59b00 close_task_aio 1 0x7f3dfc000910 busy Sep 12 12:11:59 ovirtnode01 sanlock[3379]: 2014-09-12 12:11:59-0500 1773978 [5185]: 6da59b00 close_task_aio 2 0x7f3dfc000960 busy

1 0