- Users - oVirt List Archives

Switch from Fedora 20 to CentOS 7.1
by Soeren Malchow 22 May '15

22 May '15

--_000_D565B26ABBD44294A3B34915404BCAEBmconnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCldvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIHN3aXRjaCBmcm9tIGZlZG9yYSAy MCB0byBjZW50b3MgNy4xIChhcyBmYXIgYXMgaSB1bmRlcnN0b29kIGl0IGhhcyBsaXZlIG1lcmdl IHN1cHBvcnQgbm93KSB3aXRoaW4gb25lIGNsdXN0ZXIsIG1lYW5pbmcNCg0KICAqICAgdGFrZSBv dXQgb25lIGNvbXB1dGUgaG9zdA0KICAqICAgUmVpbnN0YWxsIHRoYXQgY29tcHV0ZSBob3N0IHdp dGggQ2VudG9zIDcuMQ0KICAqICAgRG8gYSBob3N0ZWQtZW5naW5lIOKAlGRlcGxveQ0KICAqICAg TWlncmF0ZSBWTSB0byB0aGUgQ2VudE9TIDcuMSBob3N0DQogICogICBUYWtlIHRoZSBuZXh0IGZl ZG9yYSBob3N0IGFuZCByZWluc3RhbGwNCg0KQW55IGV4cGVyaWVuY2VzLCByZWNvbW1lbmRhdGlv bnMgb3IgcmVtYXJrcyBvbiB0aGF0ID8NCg0KUmVnYXJkcw0KU29lcmVuDQo= --_000_D565B26ABBD44294A3B34915404BCAEBmconnet_ Content-Type: text/html; charset="utf-8" Content-ID: <9F5C9C7C4DBD2F4986A243C438FC87E3(a)liquidcampaign.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5EZWFyIGFsbCw8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIHN3 aXRjaCBmcm9tIGZlZG9yYSAyMCB0byBjZW50b3MgNy4xIChhcyBmYXIgYXMgaSB1bmRlcnN0b29k IGl0IGhhcyBsaXZlIG1lcmdlIHN1cHBvcnQgbm93KSB3aXRoaW4gb25lIGNsdXN0ZXIsIG1lYW5p bmcmbmJzcDs8L2Rpdj4NCjx1bD4NCjxsaT50YWtlIG91dCBvbmUgY29tcHV0ZSBob3N0PC9saT48 bGk+UmVpbnN0YWxsIHRoYXQgY29tcHV0ZSBob3N0IHdpdGggQ2VudG9zIDcuMSZuYnNwOzwvbGk+ PGxpPkRvIGEgaG9zdGVkLWVuZ2luZSDigJRkZXBsb3k8L2xpPjxsaT5NaWdyYXRlIFZNIHRvIHRo ZSBDZW50T1MgNy4xIGhvc3Q8L2xpPjxsaT5UYWtlIHRoZSBuZXh0IGZlZG9yYSBob3N0IGFuZCBy ZWluc3RhbGwmbmJzcDs8L2xpPjwvdWw+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BbnkgZXhw ZXJpZW5jZXMsIHJlY29tbWVuZGF0aW9ucyBvciByZW1hcmtzIG9uIHRoYXQgPzwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVnYXJkczwvZGl2Pg0KPGRpdj5Tb2VyZW4mbmJzcDs8L2Rp dj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D565B26ABBD44294A3B34915404BCAEBmconnet_--

5 8

Adding FCP - Request for comments
by Fábio Coelho 22 May '15

22 May '15

------=_Part_221764_1599804593.1432141777491 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhvdWdodHMgYWJvdXQgQWRkaW5nIFN0b3JhZ2UgTHVucyAKCkFzIEkgYW0gbmV3IGhlcmUsIEkg d291bGQgYXBwcmVjaWF0ZSBzb21lIGFkdmljZSBhYm91dCBzb21lIGFjdGlvbnMgdGhhdCBJIGlu dGVuZCB0byBwZXJmb3JtLCBwbGVhc2UgcmVhZC4gCgpJIGhhdmUgYWRkZWQgYSBMVU4gdG8gbXkg Y2x1c3RlciBhbmQsIGZvciB0aGF0IHRhc2ssIEkgaGFkIHRvIHJlc3RhcnQgZXZlcnkgbm9kZSBv ZiBpdC4gVGhlcmUgd2FzIG5vIExVTnMgYmVmb3JlLCBtdWx0aXBhdGhkIHdhcyBzdG9wcGVkIGFu ZCBtdWx0aXBhdGguY29uZiBpbmV4aXN0ZWQuIEkgd2FzIGFibGUgdG8gbG9nIGluIGFuZCBtYW51 YWxseSBjb25maWd1cmUgbXVsdGlwYXRoLmNvbmYsIGEgc2ltcGxlIG11bHRpcGF0aGQgc3RhcnQg d2FzIG5vdCBlbm91Z2guIAoKSWYgdGhpcyB3YXNuJ3QgZW5vdWdoLCBteSBkb3VibGUgTmV0QVBQ ICggdGhyb3VnaCBhbiBIaXRhY2hpICkgcHJvdmlkZWQgbWUgd2l0aCBhIG5vdCBzbyBlbXB0eSBi cmFuZCBuZXcgTFVOLCBhbmQgdGhlIHRhc2sgdG8gYWRkIHRoZSBGQ1AgZmFpbGVkIHRvIHBvaW50 IHRoaXMuIFRydXN0aW5nIG15IGRvdWJsZSwgSSBzcGVudCBzb21lIHByZWNpb3VzIHRpbWUgc2Vh cmNoaW5nIGZvciBkaWZmZXJlbnQgcHJvYmxlbXMsIHVudGlsIHJlY2VpdmluZyBzb21lIGd1aWRh bmNlIGFuZCBkbyBhIHNpbXBsZSBkZCBpZj0vZGV2L3plcm8gdG8gdGhlIGluaXRpYWwgYmxvY2tz IG9mIHRoZSBMVU4uIAoKQ29uc3VsdGluZyB0aGUgZG9jdW1lbnRhdGlvbiAoIGh0dHA6Ly93d3cu b3ZpcnQub3JnL09WaXJ0X0FkbWluaXN0cmF0aW9uX0d1aWRlI0FkZGluZ19GQ1BfU3RvcmFnZSAp IGZvciB0aGlzIG1hdHRlcnMsIHdhcyBub3Qgb2YgYW55IGhlbHAuIAoKU28sIG15IHF1ZXN0aW9u czogCgpUaGlzIGlzIHRoZSBpbnRlbmRlZCBiZWhhdmlvcj8gU2hvdWxkIEkgb3BlbiBhIHRpY2tl dD8gCgpTaG91bGQgSSBhZGQgYSBub3RlIHRvIGRvY3VtZW50YXRpb24gdG8gcG9pbnQgc3VjaCBi ZWhhdmlvcj8gKCBpJ20gYWJvdXQgdG8gKSAKCgpDaGVlcnMsIAoKYnkgcW9lbGhlWCAKCkF2aXNv IExlZ2FsCgpBIGluZm9ybWHDp8OjbyBjb250aWRhIG5lc3RlIGUtbWFpbCBlIGVtIHNldXMgYW5l eG9zIHBvZGUgc2VyIHJlc3RyaXRhLCBzZW5kbyBvIGVtaXRlbnRlIGRlc3RlIHJlc3BvbnPDoXZl bCBwb3Igc2V1IGNvbnRlw7pkbyBlIGVuZGVyZcOnYW1lbnRvLiBTZSB2b2PDqiBuw6NvIGZvciBh IHBlc3NvYSBhdXRvcml6YWRhIGEgcmVjZWJlciBlc3RhIG1lbnNhZ2VtIGUgdGVuZG8gcmVjZWJp ZG8gYSBtZXNtYSBwb3IgZW5nYW5vLCBmYXZvciBhcGFnw6EtbGEgaW1lZGlhdGFtZW50ZS4gQSBK RlNDIGNvbnNpZGVyYSBvcGluacO1ZXMsIGNvbmNsdXPDtWVzIGUgb3V0cmFzIGluZm9ybWHDp8O1 ZXMgbsOjbyBvZmljaWFpcyBkZSByZXNwb25zYWJpbGlkYWRlIGRvIHVzdcOhcmlvIGRlc3RlIHNl cnZpw6dvLgo= ------=_Part_221764_1599804593.1432141777491 MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHk+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDAiPjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBsdWNpZGEgY29uc29sZSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9y OiAjMDAwMDAwOyIgZGF0YS1tY2Utc3R5bGU9ImZvbnQtZmFtaWx5OiBsdWNpZGEgY29uc29sZSxz YW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAwMDAwOyI+VGhvdWdodHMgYWJv dXQgQWRkaW5nIFN0b3JhZ2UgTHVucyZuYnNwOzwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBsdWNpZGEgY29uc29sZSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAw MDAwOyIgZGF0YS1tY2Utc3R5bGU9ImZvbnQtZmFtaWx5OiBsdWNpZGEgY29uc29sZSxzYW5zLXNl cmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAwMDAwOyI+PGJyIGRhdGEtbWNlLWJvZ3Vz PSIxIj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMDsiIGRhdGEtbWNlLXN0eWxlPSJm b250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBj b2xvcjogIzAwMDAwMDsiPkFzIEkgYW0gbmV3IGhlcmUsIEkgd291bGQgYXBwcmVjaWF0ZSBzb21l IGFkdmljZSBhYm91dCBzb21lIGFjdGlvbnMgdGhhdCBJIGludGVuZCB0byBwZXJmb3JtLCBwbGVh c2UgcmVhZC48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMDsiIGRhdGEtbWNlLXN0eWxl PSJmb250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0 OyBjb2xvcjogIzAwMDAwMDsiPjxiciBkYXRhLW1jZS1ib2d1cz0iMSI+PC9kaXY+PGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJw dDsgY29sb3I6ICMwMDAwMDA7IiBkYXRhLW1jZS1zdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBj b25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7Ij5JIGhh dmUgYWRkZWQgYSBMVU4gdG8gbXkgY2x1c3RlciBhbmQsIGZvciB0aGF0IHRhc2ssIEkgaGFkIHRv IHJlc3RhcnQgZXZlcnkgbm9kZSBvZiBpdC4gVGhlcmUgd2FzIG5vIExVTnMgYmVmb3JlLCBtdWx0 aXBhdGhkIHdhcyBzdG9wcGVkIGFuZCZuYnNwO211bHRpcGF0aC5jb25mIGluZXhpc3RlZC4gSSB3 YXMgYWJsZSB0byBsb2cgaW4gYW5kIG1hbnVhbGx5IGNvbmZpZ3VyZSBtdWx0aXBhdGguY29uZiwg YSBzaW1wbGUgbXVsdGlwYXRoZCBzdGFydCB3YXMgbm90IGVub3VnaC48L2Rpdj48ZGl2IHN0eWxl PSJmb250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0 OyBjb2xvcjogIzAwMDAwMDsiIGRhdGEtbWNlLXN0eWxlPSJmb250LWZhbWlseTogbHVjaWRhIGNv bnNvbGUsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMDsiPjxiciBk YXRhLW1jZS1ib2d1cz0iMSI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBj b25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7IiBkYXRh LW1jZS1zdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7Ij5JZiB0aGlzIHdhc24ndCBlbm91Z2gsIG15IGRv dWJsZSBOZXRBUFAgKCB0aHJvdWdoIGFuIEhpdGFjaGkgKSBwcm92aWRlZCBtZSB3aXRoIGEgbm90 IHNvIGVtcHR5IGJyYW5kIG5ldyBMVU4sIGFuZCB0aGUgdGFzayB0byBhZGQgdGhlIEZDUCBmYWls ZWQgdG8gcG9pbnQgdGhpcy4gVHJ1c3RpbmcgbXkgZG91YmxlLCBJIHNwZW50IHNvbWUgcHJlY2lv dXMgdGltZSBzZWFyY2hpbmcgZm9yIGRpZmZlcmVudCBwcm9ibGVtcywgdW50aWwgcmVjZWl2aW5n IHNvbWUgZ3VpZGFuY2UgYW5kIGRvJm5ic3A7YSBzaW1wbGUgZGQgaWY9L2Rldi96ZXJvIHRvIHRo ZSBpbml0aWFsIGJsb2NrcyBvZiB0aGUgTFVOLjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBsdWNpZGEgY29uc29sZSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAw MDAwOyIgZGF0YS1tY2Utc3R5bGU9ImZvbnQtZmFtaWx5OiBsdWNpZGEgY29uc29sZSxzYW5zLXNl cmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAwMDAwOyI+PGJyIGRhdGEtbWNlLWJvZ3Vz PSIxIj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1z ZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMDsiIGRhdGEtbWNlLXN0eWxlPSJm b250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBj b2xvcjogIzAwMDAwMDsiPkNvbnN1bHRpbmcgdGhlIGRvY3VtZW50YXRpb24gKCZuYnNwO2h0dHA6 Ly93d3cub3ZpcnQub3JnL09WaXJ0X0FkbWluaXN0cmF0aW9uX0d1aWRlI0FkZGluZ19GQ1BfU3Rv cmFnZSApIGZvciB0aGlzIG1hdHRlcnMsIHdhcyBub3Qgb2YgYW55IGhlbHAuPC9kaXY+PGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTJwdDsgY29sb3I6ICMwMDAwMDA7IiBkYXRhLW1jZS1zdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lk YSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7Ij48 YnIgZGF0YS1tY2UtYm9ndXM9IjEiPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBsdWNp ZGEgY29uc29sZSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAwMDAwOyIg ZGF0YS1tY2Utc3R5bGU9ImZvbnQtZmFtaWx5OiBsdWNpZGEgY29uc29sZSxzYW5zLXNlcmlmOyBm b250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAwMDAwOyI+U28sIG15IHF1ZXN0aW9uczo8L2Rpdj48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMDsiIGRhdGEtbWNlLXN0eWxlPSJmb250LWZhbWlseTog bHVjaWRhIGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAw MDsiPjxiciBkYXRhLW1jZS1ib2d1cz0iMSI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAw MDA7IiBkYXRhLW1jZS1zdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7Ij5UaGlzIGlzIHRoZSBpbnRlbmRl ZCBiZWhhdmlvcj8gU2hvdWxkIEkgb3BlbiBhIHRpY2tldD88L2Rpdj48ZGl2IHN0eWxlPSJmb250 LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xv cjogIzAwMDAwMDsiIGRhdGEtbWNlLXN0eWxlPSJmb250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUs c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMDsiPjxiciBkYXRhLW1j ZS1ib2d1cz0iMSI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xl LHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7IiBkYXRhLW1jZS1z dHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTJwdDsgY29sb3I6ICMwMDAwMDA7Ij5TaG91bGQgSSBhZGQgYSBub3RlIHRvIGRvY3VtZW50YXRp b24gdG8gcG9pbnQgc3VjaCBiZWhhdmlvcj8gKCBpJ20gYWJvdXQgdG8gKTwvZGl2PjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBsdWNpZGEgY29uc29sZSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEy cHQ7IGNvbG9yOiAjMDAwMDAwOyIgZGF0YS1tY2Utc3R5bGU9ImZvbnQtZmFtaWx5OiBsdWNpZGEg Y29uc29sZSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAwMDAwOyI+PGJy IGRhdGEtbWNlLWJvZ3VzPSIxIj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogbHVjaWRh IGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMDsiIGRh dGEtbWNlLXN0eWxlPSJmb250LWZhbWlseTogbHVjaWRhIGNvbnNvbGUsc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMDsiPjxiciBkYXRhLW1jZS1ib2d1cz0iMSI+PC9k aXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7IiBkYXRhLW1jZS1zdHlsZT0iZm9udC1mYW1p bHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMw MDAwMDA7Ij5DaGVlcnMsPC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25z b2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7IiBkYXRhLW1j ZS1zdHlsZT0iZm9udC1mYW1pbHk6IGx1Y2lkYSBjb25zb2xlLHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTJwdDsgY29sb3I6ICMwMDAwMDA7Ij48YnIgZGF0YS1tY2UtYm9ndXM9IjEiPjwvZGl2Pjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBsdWNpZGEgY29uc29sZSxzYW5zLXNlcmlmOyBmb250LXNp emU6IDEycHQ7IGNvbG9yOiAjMDAwMDAwOyIgZGF0YS1tY2Utc3R5bGU9ImZvbnQtZmFtaWx5OiBs dWNpZGEgY29uc29sZSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEycHQ7IGNvbG9yOiAjMDAwMDAw OyI+YnkgcW9lbGhlWDwvZGl2PjwvZGl2PjxwPjxicj4KQXZpc28gTGVnYWw8L3A+Cgo8cD5BIGlu Zm9ybWHDp8OjbyBjb250aWRhIG5lc3RlIGUtbWFpbCBlIGVtIHNldXMgYW5leG9zIHBvZGUgc2Vy IHJlc3RyaXRhLCBzZW5kbyBvIGVtaXRlbnRlIGRlc3RlIHJlc3BvbnPDoXZlbCBwb3Igc2V1IGNv bnRlw7pkbyBlIGVuZGVyZcOnYW1lbnRvLiBTZSB2b2PDqiBuw6NvIGZvciBhIHBlc3NvYSBhdXRv cml6YWRhIGEgcmVjZWJlciBlc3RhIG1lbnNhZ2VtIGUgdGVuZG8gcmVjZWJpZG8gYSBtZXNtYSBw b3IgZW5nYW5vLCBmYXZvciBhcGFnw6EtbGEgaW1lZGlhdGFtZW50ZS4gQSBKRlNDIGNvbnNpZGVy YSBvcGluacO1ZXMsIGNvbmNsdXPDtWVzIGUgb3V0cmFzIGluZm9ybWHDp8O1ZXMgbsOjbyBvZmlj aWFpcyBkZSByZXNwb25zYWJpbGlkYWRlIGRvIHVzdcOhcmlvIGRlc3RlIHNlcnZpw6dvLjwvcD48 L2JvZHk+PC9odG1sPg== ------=_Part_221764_1599804593.1432141777491--

3 7

Re: [ovirt-users] providing hosts with foreman
by Oved Ourfali 22 May '15

22 May '15

At this step, after the host installation was successful, which means iirc that all puppet classes were applied correctly, the plug in on the foreman side handles the bootstrapping of the new host. Attaching the production.log file on Foreman, and the engine.log from the ovirt engine is needed to understand what went wrong. A workaround is to remove the host, and add it back. Iirc we haven't allowed reinstall for the installing-OS status. Oved On May 22, 2015 7:57 PM, Nathanaël Blanchet <blanchet(a)abes.fr> wrote: > > Hello Yaniv, > > Okay for the DNS proxy, everything works now as expected. > I have a new question now about the install host workflow. > The host is in "installing OS" state, and on the host side it has been > successfully installed. But now how to complete the host vdms > installation and registration? > I found this on your wiki : > "For other OS - at first step won't do the registration by themselves, > but foreman will do that using a plugin (plugin will send REST-API call > to add or approve the host) " > After investigation, I found that this plugin was this one : > ruby193-rubygem-ovirt_provision_plugin (and with foreman 1.8 we can > activate it with foreman-installer now) > > But nothing happens once the OS is installed et the state is stuck on > "installing OS". Communication between foreman and engine is okay and > without firewall issue... I found nothing significative into the foreman > logs or somewhere else... > What is it supposed to happen at this step? > > > Le 17/05/2015 17:35, ybronhei a écrit : > > Hey Nathenael, > > > > On 05/13/2015 06:28 PM, Nathanaël Blanchet wrote: > >> Hi all, > >> > >> I've setup a foreman server, but when adding a new host by "discovered > >> hosts", I can't modify the address item which is default filled with a > >> built "mac-DNS". > > > > Not exactly, it set the address field to be the name you choose for > > the host dot (.) the domain that related to the picked host-group > > > >> In ovirt setup, I want to identify my future hosts by their IP and not > >> their unknown DNS name like it is described here: > >> http://www.ovirt.org/Features/ForemanIntegration. > > > > IP addresses can and should be dynamic based on your DHCP server > > configuration, but DNS name should stay the same. Adding the host that > > way to engine uses satellite to configure its DNS entry and other > > network configurations. That's why we lock the address field and fill > > it with the future FQDN. > > > >> How can I setup foreman to do such a thing? Is the setup of the DNS > >> proxy related? > > > > Yes, the DNS setup is related to it. We depend on it. Using IP address > > might brake the integration between engine and satellite when the DHCP > > service is configured with address ttl option and can give the host > > different IP address in next boot. So currently we don't support > > address modification with Discovered\Provisioned Hosts > > > >> > > > > If that answer is not clear feel free to ping me in irc (ybronhei > > @freenode #ovirt) or reply here > > > > Regards, > > > > -- > Nathanaël Blanchet > > Supervision réseau > Pôle Infrastrutures Informatiques > 227 avenue Professeur-Jean-Louis-Viala > 34193 MONTPELLIER CEDEX 5 > Tél. 33 (0)4 67 54 84 55 > Fax 33 (0)4 67 54 84 14 > blanchet(a)abes.fr >

1 0

providing hosts with foreman
by Nathanaël Blanchet 22 May '15

22 May '15

Hi all, I've setup a foreman server, but when adding a new host by "discovered hosts", I can't modify the address item which is default filled with a built "mac-DNS". In ovirt setup, I want to identify my future hosts by their IP and not their unknown DNS name like it is described here: http://www.ovirt.org/Features/ForemanIntegration. How can I setup foreman to do such a thing? Is the setup of the DNS proxy related? -- Nathanaël Blanchet Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet(a)abes.fr

3 3

Re: [ovirt-users] vdsm storage problem - maybe cache problem?
by ml＠ohnewald.net 22 May '15

22 May '15

Hello List, i really need some help here....could someone please give it a try? I already tried to get help on the irc channel but it seems that my problem here is too complicated or maybe i am providing not useful infos? DB & vdsClient: http://fpaste.org/223483/14320588/ (i think is part is very intresting) engine.log: http://paste.fedoraproject.org/223349/04494414 Node02 vdsm Log: http://paste.fedoraproject.org/223350/43204496 Node01 vdsm Log: http://paste.fedoraproject.org/223347/20448951 Why does my vdsm look for StorageDomain 036b5575-51fa-4f14-8b05-890d7807894c ? => This was a NFS Export which i deleted from the GUI yesterday (!!!). From the Database Log/Dump: ============================= USER_FORCE_REMOVE_STORAGE_DOMAIN 981 0 Storage Domain EXPORT2 was forcibly removed by admin@internal f b384b3da-02a6-44f3-a3f6-56751ce8c26d HP_Proliant_DL180G6 036b5575-51fa-4f14-8b05-890d7807894c EXPORT2 00000000-0000-0000-0000-000000000000 c1754ff 807321f6-2043-4a26-928c-0ce6b423c381 I already put one node into maintance, rebootet and activated it. Still the same problem. Some Screen Shots: -------------------- http://postimg.org/image/8zo4ujgjb/ http://postimg.org/image/le918grdr/ http://postimg.org/image/wnawwhrgh/ My GlusterFS fully works and is not the problem here i guess: ============================================================== 2015-05-19 04:09:06,292 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMClearTaskVDSCommand] (DefaultQuartzScheduler_Worker-43) [3df9132b] START, HSMClearTaskVDSCommand(HostName = ovirt-node02.stuttgart.imos.net, HostId = 6948da12-0b8a-4b6d-a9af-162e6c25dad3, taskId=2aeec039-5b95-40f0-8410-da62b44a28e8), log id: 19b18840 2015-05-19 04:09:06,337 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMClearTaskVDSCommand] (DefaultQuartzScheduler_Worker-43) [3df9132b] FINISH, HSMClearTaskVDSCommand, log id: 19b18840 I already had a chat with Maor Lipchuk and he told me to add another host to the datacenter and then re-initialize it. I will migrate back to ESXi for now to get those two nodes free. Then we can mess with it if anyone is interested to help me. Otherwise i will have to stay with ESXi :-( Has anyone else an idea until then? Why is my vdsm host all messed up with that zombie StorageDomain? Thanks for your time. I really, really appreciate it. Mario Am 19.05.15 um 14:57 schrieb ml(a)ohnewald.net: > Hello List, > > okay, i really need some help now. I stopped vdsmd for a little bit too > long, fencing stepped in and rebootet node01. > > I now can NOT start any vm because the storage is marked "Unknown". > > > Since node01 rebootet i am wondering why the hell it is still looking to > this StorageDomain: > > StorageDomainCache::(_findDomain) domain > 036b5575-51fa-4f14-8b05-890d7807894c not found > > Can anyone please please tell me where the id exactly it comes from? > > > Thanks, > Mario > > > > > > Am 18.05.15 um 14:21 schrieb Maor Lipchuk: >> Hi Mario, >> >> Can u try to mount this directly from the Host? >> Can u please attach the VDSM and engine logs >> >> Thanks, >> Maor >> >> >> ----- Original Message ----- >>> From: ml(a)ohnewald.net >>> To: "Maor Lipchuk" <mlipchuk(a)redhat.com> >>> Cc: users(a)ovirt.org >>> Sent: Monday, May 18, 2015 2:36:38 PM >>> Subject: Re: [ovirt-users] vdsm storage problem - maybe cache problem? >>> >>> Hi Maor, >>> >>> thanks for the quick reply. >>> >>> Am 18.05.15 um 13:25 schrieb Maor Lipchuk: >>> >>>>> Now my Question: Why does the vdsm node not know that i deleted the >>>>> storage? Has the vdsm cached this mount informations? Why does it >>>>> still >>>>> try to access 036b5575-51fa-4f14-8b05-890d7807894c? >>>> >>>> >>>> Yes, the vdsm use a cache for Storage Domains, you can try to >>>> restart the >>>> vdsmd service instead of rebooting the host. >>>> >>> >>> I am still getting the same error. >>> >>> >>> [root@ovirt-node01 ~]# /etc/init.d/vdsmd stop >>> Shutting down vdsm daemon: >>> vdsm watchdog stop [ OK ] >>> vdsm: Running run_final_hooks [ OK ] >>> vdsm stop [ OK ] >>> [root@ovirt-node01 ~]# >>> [root@ovirt-node01 ~]# >>> [root@ovirt-node01 ~]# >>> [root@ovirt-node01 ~]# ps aux | grep vdsmd >>> root 3198 0.0 0.0 11304 740 ? S< May07 0:00 >>> /bin/bash -e /usr/share/vdsm/respawn --minlifetime 10 --daemon >>> --masterpid /var/run/vdsm/supervdsm_respawn.pid >>> /usr/share/vdsm/supervdsmServer --sockfile /var/run/vdsm/svdsm.sock >>> --pidfile /var/run/vdsm/supervdsmd.pid >>> root 3205 0.0 0.0 922368 26724 ? S<l May07 12:10 >>> /usr/bin/python /usr/share/vdsm/supervdsmServer --sockfile >>> /var/run/vdsm/svdsm.sock --pidfile /var/run/vdsm/supervdsmd.pid >>> root 15842 0.0 0.0 103248 900 pts/0 S+ 13:35 0:00 grep >>> vdsmd >>> >>> >>> [root@ovirt-node01 ~]# /etc/init.d/vdsmd start >>> initctl: Job is already running: libvirtd >>> vdsm: Running mkdirs >>> vdsm: Running configure_coredump >>> vdsm: Running configure_vdsm_logs >>> vdsm: Running run_init_hooks >>> vdsm: Running gencerts >>> vdsm: Running check_is_configured >>> libvirt is already configured for vdsm >>> sanlock service is already configured >>> vdsm: Running validate_configuration >>> SUCCESS: ssl configured to true. No conflicts >>> vdsm: Running prepare_transient_repository >>> vdsm: Running syslog_available >>> vdsm: Running nwfilter >>> vdsm: Running dummybr >>> vdsm: Running load_needed_modules >>> vdsm: Running tune_system >>> vdsm: Running test_space >>> vdsm: Running test_lo >>> vdsm: Running restore_nets >>> vdsm: Running unified_network_persistence_upgrade >>> vdsm: Running upgrade_300_nets >>> Starting up vdsm daemon: >>> vdsm start [ OK ] >>> [root@ovirt-node01 ~]# >>> >>> [root@ovirt-node01 ~]# grep ERROR /var/log/vdsm/vdsm.log | tail -n 20 >>> Thread-13::ERROR::2015-05-18 >>> 13:35:03,631::sdc::137::Storage.StorageDomainCache::(_findDomain) >>> looking for unfetched domain abc51e26-7175-4b38-b3a8-95c6928fbc2b >>> Thread-13::ERROR::2015-05-18 >>> 13:35:03,632::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) >>> >>> looking for domain abc51e26-7175-4b38-b3a8-95c6928fbc2b >>> Thread-36::ERROR::2015-05-18 >>> 13:35:11,607::sdc::137::Storage.StorageDomainCache::(_findDomain) >>> looking for unfetched domain 036b5575-51fa-4f14-8b05-890d7807894c >>> Thread-36::ERROR::2015-05-18 >>> 13:35:11,621::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) >>> >>> looking for domain 036b5575-51fa-4f14-8b05-890d7807894c >>> Thread-36::ERROR::2015-05-18 >>> 13:35:11,960::sdc::143::Storage.StorageDomainCache::(_findDomain) domain >>> 036b5575-51fa-4f14-8b05-890d7807894c not found >>> Thread-36::ERROR::2015-05-18 >>> 13:35:11,960::domainMonitor::239::Storage.DomainMonitorThread::(_monitorDomain) >>> >>> Error while collecting domain 036b5575-51fa-4f14-8b05-890d7807894c >>> monitoring information >>> Thread-36::ERROR::2015-05-18 >>> 13:35:21,962::sdc::137::Storage.StorageDomainCache::(_findDomain) >>> looking for unfetched domain 036b5575-51fa-4f14-8b05-890d7807894c >>> Thread-36::ERROR::2015-05-18 >>> 13:35:21,965::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) >>> >>> looking for domain 036b5575-51fa-4f14-8b05-890d7807894c >>> Thread-36::ERROR::2015-05-18 >>> 13:35:22,068::sdc::143::Storage.StorageDomainCache::(_findDomain) domain >>> 036b5575-51fa-4f14-8b05-890d7807894c not found >>> Thread-36::ERROR::2015-05-18 >>> 13:35:22,072::domainMonitor::239::Storage.DomainMonitorThread::(_monitorDomain) >>> >>> Error while collecting domain 036b5575-51fa-4f14-8b05-890d7807894c >>> monitoring information >>> Thread-15::ERROR::2015-05-18 >>> 13:35:33,821::task::866::TaskManager.Task::(_setError) >>> Task=`54bdfc77-f63a-493b-b24e-e5a3bc4977bb`::Unexpected error >>> Thread-15::ERROR::2015-05-18 >>> 13:35:33,864::dispatcher::65::Storage.Dispatcher.Protect::(run) >>> {'status': {'message': "Unknown pool id, pool not connected: >>> ('b384b3da-02a6-44f3-a3f6-56751ce8c26d',)", 'code': 309}} >>> Thread-13::ERROR::2015-05-18 >>> 13:35:33,930::sdc::137::Storage.StorageDomainCache::(_findDomain) >>> looking for unfetched domain abc51e26-7175-4b38-b3a8-95c6928fbc2b >>> Thread-15::ERROR::2015-05-18 >>> 13:35:33,928::task::866::TaskManager.Task::(_setError) >>> Task=`fe9bb0fa-cf1e-4b21-af00-0698c6d1718f`::Unexpected error >>> Thread-13::ERROR::2015-05-18 >>> 13:35:33,932::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) >>> >>> looking for domain abc51e26-7175-4b38-b3a8-95c6928fbc2b >>> Thread-15::ERROR::2015-05-18 >>> 13:35:33,978::dispatcher::65::Storage.Dispatcher.Protect::(run) >>> {'status': {'message': 'Not SPM: ()', 'code': 654}} >>> Thread-36::ERROR::2015-05-18 >>> 13:35:41,117::sdc::137::Storage.StorageDomainCache::(_findDomain) >>> looking for unfetched domain 036b5575-51fa-4f14-8b05-890d7807894c >>> Thread-36::ERROR::2015-05-18 >>> 13:35:41,131::sdc::154::Storage.StorageDomainCache::(_findUnfetchedDomain) >>> >>> looking for domain 036b5575-51fa-4f14-8b05-890d7807894c >>> Thread-36::ERROR::2015-05-18 >>> 13:35:41,452::sdc::143::Storage.StorageDomainCache::(_findDomain) domain >>> 036b5575-51fa-4f14-8b05-890d7807894c not found >>> Thread-36::ERROR::2015-05-18 >>> 13:35:41,453::domainMonitor::239::Storage.DomainMonitorThread::(_monitorDomain) >>> >>> Error while collecting domain 036b5575-51fa-4f14-8b05-890d7807894c >>> monitoring information >>> >>> >>> Thanks, >>> Mario >>> >>> >

2 3

vdsmd fails to start on boot
by Chris Jones - BookIt.com Systems Administrator 21 May '15

21 May '15

Running oVirt Node - 3.5 - 0.999.201504280931.el7.centos. On first boot, vdsmd fails to load with "Dependency failed for Virtual Desktop Server Manager." When I run "systemctl start vdsmd" it loads fine. This happens on every reboot. Looks like there is an old bug for this from 3.4. https://bugzilla.redhat.com/show_bug.cgi?id=1055153 -- This email was Virus checked by UTM 9. For issues please contact the Windows Systems Admin.

1 0

how to pause a VM from rest-api?
by Ernest Beinrohr 21 May '15

21 May '15

This is a multi-part message in MIME format. --------------070900040009080707030501 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I'd like to pause a VM from rest-api. But the docs are not mentioning pause, only suspend. This works: URL/api/vms/ID/suspend and pause doesn't. Pausing from vdsClient works however, but I'd like to use rest-api: vdsClient -s host1 pause ID -- Ernest Beinrohr, AXON PRO Ing <http://www.beinrohr.sk/ing.php>, RHCE <http://www.beinrohr.sk/rhce.php>, RHCVA <http://www.beinrohr.sk/rhce.php>, LPIC <http://www.beinrohr.sk/lpic.php>, VCA <http://www.beinrohr.sk/vca.php>, +421-2-62410360 +421-903-482603 --------------070900040009080707030501 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> I'd like to pause a VM from rest-api. But the docs are not mentioning pause, only suspend. This works: URL/api/vms/ID/suspend and pause doesn't. Pausing from vdsClient works however, but I'd like to use rest-api:<br> vdsClient -s host1 pause ID<br> <br> <br> <br> <div class="moz-signature">-- <br> <div id="oernii_footer" style="color: gray;"> <span style="font-family: Lucida Console, Luxi Mono, Courier, monospace; font-size: 90%;"> Ernest Beinrohr, AXON PRO<br> <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/ing.php">Ing</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/rhce.php">RHCE</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/rhce.php">RHCVA</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/lpic.php">LPIC</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/vca.php">VCA</a>, <br> +421-2-62410360 +421-903-482603 <br> </span> </div> <img src="http://nojsstats.appspot.com/UA-44497096-1/email.beinrohr.sk" moz-do-not-send="true" border="0" width="1" height="1"> </div> </body> </html> --------------070900040009080707030501--

3 4

[ANN] oVirt 3.6.0 First Alpha Release is now available for testing
by Sandro Bonazzola 21 May '15

21 May '15

The oVirt Project is pleased to announce the availability of the first Alpha release of oVirt 3.6 for testing, as of May 20, 2015. oVirt is an open source alternative to VMware vSphere, and provides an excellent KVM management interface for multi-node virtualization. The Alpha release is available now for Fedora 20, Red Hat Enterprise Linux 6.6, CentOS 6.6 (or similar) and Red Hat Enterprise Linux 7.1, CentOS 7.1 (or similar). The Alpha release can also be deployed on Hypervisor Hosts running Fedora 21 and Fedora 22. This Alpha release of oVirt includes numerous bug fixes. See the release notes [1] for an initial list of the new features and bugs fixed. Please refer to release notes [1] for Installation / Upgrade instructions. A new oVirt Live ISO and Node ISO will be available soon[2]. Please note that mirrors[3] may need usually one day before being synchronized. Please refer to the release notes for known issues in this release. [1] http://www.ovirt.org/OVirt_3.6_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.6-pre/iso/ [3] http://www.ovirt.org/Repository_mirrors#Current_mirrors -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

disk format hang
by paf1＠email.cz 20 May '15

20 May '15

This is a multi-part message in MIME format. --------------010600070900060906080603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello, during VM instalation I needed add 300GB new disk and format as EXT3. Easy task, but .... Used striped mirror volume for that - created by: # gluster volume create 12KVM12SC4 replica 2 stripe 2 1kvm1-SAN:/p4/GFS1 1kvm2-SAN:/p4/GFS1 2kvm1-SAN /p4/GFS1 2kvm2-SAN:/p4/GFS1 force - added disk throught oVisrt GUI - VM# partprobe - VM# fdisk - make one partition, type linux - VM# mkfs.ext3 /dev/vdb1 it hangs after cca 30% of format oVirt alert: *VM has been paused due to a storage I/O error* so I tried to copy some data directly from hypervizor ( cca 80GB ) to default gluster-ovirt mountpoint ( /rhev/data-center/mnt/glusterSD/localhost:_12KVM12SC4 ) with no hangs. The same whole operation on volume distribute replica type succesfully done. Can anybody help me with it ?? Maybe continual error on /var/log/messages occure will get right view on it : May 20 15:47:00 1kvm2 virsh: All-whitespace username. May 20 15:47:00 1kvm2 journal: End of file while reading data: Input/output error May 20 15:47:00 1kvm2 virsh: All-whitespace username. May 20 15:47:00 1kvm2 journal: End of file while reading data: Input/output error May 20 15:48:00 1kvm2 virsh: All-whitespace username. May 20 15:48:00 1kvm2 journal: End of file while reading data: Input/output error May 20 15:48:00 1kvm2 virsh: All-whitespace username. May 20 15:48:00 1kvm2 journal: End of file while reading data: Input/output error regs to ALL !! URGENT !! Pavel --------------010600070900060906080603 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hello, <br> <br> during VM instalation I needed add 300GB new disk and format as EXT3. Easy task, but ....<br> Used striped mirror volume for that - created by:<br> <meta http-equiv="content-type" content="text/html; charset=utf-8"> # gluster volume create 12KVM12SC4 replica 2 stripe 2 1kvm1-SAN:/p4/GFS1 1kvm2-SAN:/p4/GFS1 2kvm1-SAN /p4/GFS1 2kvm2-SAN:/p4/GFS1 force<br> - added disk throught oVisrt GUI<br> - VM# partprobe<br> - VM# fdisk - make one partition, type linux<br> - VM# mkfs.ext3 /dev/vdb1<br> it hangs after cca 30% of format<br> <br> oVirt alert: <div> <div> <div style="display: inline;" class="gwt-Label"><b>VM has been paused due to a storage I/O error</b></div> </div> </div> <br> so I tried to copy some data directly from hypervizor ( cca 80GB ) to default gluster-ovirt mountpoint ( /rhev/data-center/mnt/glusterSD/localhost:_12KVM12SC4 ) with no hangs.<br> The same whole operation on volume distribute replica type succesfully done.<br> <br> Can anybody help me with it ??<br> <br> Maybe continual error on /var/log/messages occure will get right view on it :<br> <br> May 20 15:47:00 1kvm2 virsh: All-whitespace username.<br> May 20 15:47:00 1kvm2 journal: End of file while reading data: Input/output error<br> May 20 15:47:00 1kvm2 virsh: All-whitespace username.<br> May 20 15:47:00 1kvm2 journal: End of file while reading data: Input/output error<br> May 20 15:48:00 1kvm2 virsh: All-whitespace username.<br> May 20 15:48:00 1kvm2 journal: End of file while reading data: Input/output error<br> May 20 15:48:00 1kvm2 virsh: All-whitespace username.<br> May 20 15:48:00 1kvm2 journal: End of file while reading data: Input/output error<br> <br> regs to ALL<br> <br> !! URGENT !!<br> <br> Pavel<br> </body> </html> --------------010600070900060906080603--

1 0

Re: [ovirt-users] Linux VMs get stuck after Live Migration
by Soeren Malchow 20 May '15

20 May '15

--_000_BE85E676B6644C8787ACFF9C76B9E900mconnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCnNvbWUgYWRkaXRpb25zOg0KDQogICogICBzd2l0Y2hpbmcgb2YgbWVtb3J5 IGJhbGxvb25pZyBkb2VzIG5vdCBzb2x2ZSB0aGUgcHJvYmxlbQ0KICAqICAgT25jZSB3ZSBtaWdy YXRlZCB0aGUgbWFjaGluZXMgd2UgY2FuIGJhc2ljYWxseSBub3QgdXNlIGFueXRoaW5nIGFueW1v cmUgdGhhdCBuZWVkcyBzb21lIGtpbmQgb2YgdGltaW5nIOKAkyBlLmcuIOKAnHBpbmcgMS4xLjEu MSDigJNpIDLigJ0gb3Ig4oCcd2hpbGUgdHJ1ZTsgZG8gZWNobyDigJxsYWxh4oCdOyBzbGVlcOKA nTsgZG9uZeKAnSBib3RoIGRvIHRoZSBmcmlzdCB0aGluZyAoMSBwaW5nIGFuZCBvbmUg4oCcbGFs YeKAnSBvdXRwdXQpIGJ1dCB0aGVuIHN0YWxsDQoNCkNoZWVycw0KU29lcmVuDQoNCkZyb206IDx1 c2Vycy1ib3VuY2VzQG92aXJ0Lm9yZzxtYWlsdG86dXNlcnMtYm91bmNlc0BvdmlydC5vcmc+PiBv biBiZWhhbGYgb2YgU29lcmVuIE1hbGNob3cNCkRhdGU6IFdlZG5lc2RheSAyMCBNYXkgMjAxNSAx Mzo0Mg0KVG86ICJ1c2Vyc0BvdmlydC5vcmc8bWFpbHRvOnVzZXJzQG92aXJ0Lm9yZz4iDQpTdWJq ZWN0OiBbb3ZpcnQtdXNlcnNdIExpbnV4IFZNcyBnZXQgc3R1Y2sgYWZ0ZXIgTGl2ZSBNaWdyYXRp b24NCg0KRGVhciBhbGwsDQoNCldlIGFyZSBleHBlcmllbmNpbmcgYSBwcm9ibGVtIHdpdGggTGlu dXggVm1zIHNwZWNpZmljYWxseSB0aGUgVm1zIHdlIHRlc3RlZCBhcmUgQ2VudE9TIDcuMSAoc28g ZmFyIGl0IGxvb2tzIGFzIGlmIFdpbmRvd3MgVm1zIGFyZSBub3QgYSBwcm9ibGVtKSwgYWZ0ZXIg dGhlIGxpdmUgbWlncmF0aW9uIHRoZSBtYWNoaW5lcyBkbyBub3Qgc2hvdyB0aGUgSVAgYW5kIGhv c3RuYW1lIGluIHRoZSBHVUksIHRoZSBzYW1lIHdheSBhcyBpZiB0aGUgZ3Vlc3QgdG9vbHMgYXJl IG5vdCBpbnN0YWxsZWQsIGJ1dCB0aGUgbWFjaGluZXMgYXJlIHN0aWxsIHJ1bm5pbmcuDQoNClRo ZW4gd2UgaGF2ZSAyIGRpZmZlcmVudCBzY2VuYXJpb3MNCg0KUmVib290L3NodXRkb3duOg0KV2hl biBpIHJlYm9vdC9zaHV0ZG93biBvbmUgb2YgdGhlc2UgVk1TIGZyb20gaW5zaWRlIHRoZSBWTSB0 aGUgT1Mgc2VlbXMgdG8gc2h1dGRvd24sIGhvd2V2ZXIsIHRoZSBxZW11IHByb2Nlc3MgaXMgc3Rp bGwgcnVubmluZyBhbmQgZm9yIG92aXJ0IHRoZSBtYWNoaW5lIGlzIHN0aWxsIHVwLCBhIOKAnHNo dXRkb3du4oCdIGluIHRoZSBmcm9udGVuZCBkb2VzIG5vdCBkbyBhbnl0aGluZywgYSDigJxwb3dl ciBvZmbigJ0gc2h1dHMgZG93biB0aGUgbWFjaGluZQ0KDQpKdXN0IHdhaXQ6DQpBZnRlciBhIHdo aWxlIHRoZSBtYWNoaW5lcyBqdXN0IHNlZW0gdG8gc2h1dGRvd24gYW5kIHRoZW4gYmFzaWNhbGx5 IHRoZW4gc2FtZSBoYXBwZXNuIGFzIHdpdGggcmVib290L3NodXRkb3duDQoNClRoZSBlbnZpcm9u bWVudCBpczoNCg0KSG9zdGVkIEVuZ2luZSBvbiBDZW50T1MgNi42IHdpdGggb3ZpcnQgMy41LjIu MQ0KQ29tcHV0ZSBob3N0cyBvbiBGZWRvcmEgMjAgd2l0aCB2ZHNtIDQuMTYuMTQgYW5kIGxpYnZp cnQgMS4yLjkuMSBmcm9tIHRoZSBsaWJ2aXJ0LXByZXZpZXcgcmVwbyAoZm9yIGxpdmUgbWVyZ2Up DQpTdG9yYWdlIC0+IENlbnRPUyA3LjEgd2l0aCBnbHVzdGVyIDMuNi4zDQoNCkNhbiBhbnlvbmUg cG9pbnQgdXMgdG93YXJkcyB0aGUgcmlnaHQgZGlyZWN0aW9uDQoNClJlZ2FyZHMNClNvZXJlbg0K --_000_BE85E676B6644C8787ACFF9C76B9E900mconnet_ Content-Type: text/html; charset="utf-8" Content-ID: <E72DBA6120393545B26397A309AE61D7(a)liquidcampaign.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkRlYXIgYWxsLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+c29tZSBhZGRpdGlv bnM6Jm5ic3A7PC9kaXY+DQo8dWw+DQo8bGk+c3dpdGNoaW5nIG9mIG1lbW9yeSBiYWxsb29uaWcg ZG9lcyBub3Qgc29sdmUgdGhlIHByb2JsZW08L2xpPjxsaT5PbmNlIHdlIG1pZ3JhdGVkIHRoZSBt YWNoaW5lcyB3ZSBjYW4gYmFzaWNhbGx5IG5vdCB1c2UgYW55dGhpbmcgYW55bW9yZSB0aGF0IG5l ZWRzIHNvbWUga2luZCBvZiB0aW1pbmcg4oCTIGUuZy4g4oCccGluZyAxLjEuMS4xIOKAk2kgMuKA nSBvciDigJx3aGlsZSB0cnVlOyBkbyBlY2hvIOKAnGxhbGHigJ07IHNsZWVw4oCdOyBkb25l4oCd IGJvdGggZG8gdGhlIGZyaXN0IHRoaW5nICgxIHBpbmcgYW5kIG9uZSDigJxsYWxh4oCdIG91dHB1 dCkgYnV0IHRoZW4gc3RhbGw8L2xpPjwvdWw+DQo8ZGl2PkNoZWVyczwvZGl2Pg0KPGRpdj5Tb2Vy ZW4mbmJzcDs8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlk PSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp OyBmb250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJP VFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RU T006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRP UDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkct VE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4m bHQ7PGEgaHJlZj0ibWFpbHRvOnVzZXJzLWJvdW5jZXNAb3ZpcnQub3JnIj51c2Vycy1ib3VuY2Vz QG92aXJ0Lm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBTb2VyZW4gTWFsY2hvdzxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5IDIwIE1heSAy MDE1IDEzOjQyPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+ JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnVzZXJzQG92aXJ0Lm9yZyI+dXNlcnNAb3ZpcnQub3JnPC9h PiZxdW90Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3Nw YW4+W292aXJ0LXVzZXJzXSBMaW51eCBWTXMgZ2V0IHN0dWNrIGFmdGVyIExpdmUgTWlncmF0aW9u PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQt d3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUt YnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6 IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2PkRlYXIgYWxs LDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2UgYXJlIGV4cGVyaWVuY2luZyBhIHBy b2JsZW0gd2l0aCBMaW51eCBWbXMgc3BlY2lmaWNhbGx5IHRoZSBWbXMgd2UgdGVzdGVkIGFyZSBD ZW50T1MgNy4xIChzbyBmYXIgaXQgbG9va3MgYXMgaWYgV2luZG93cyBWbXMgYXJlIG5vdCBhIHBy b2JsZW0pLCBhZnRlciB0aGUgbGl2ZSBtaWdyYXRpb24gdGhlIG1hY2hpbmVzIGRvIG5vdCBzaG93 IHRoZSBJUCBhbmQgaG9zdG5hbWUgaW4gdGhlIEdVSSwgdGhlIHNhbWUgd2F5IGFzIGlmIHRoZSBn dWVzdA0KIHRvb2xzIGFyZSBub3QgaW5zdGFsbGVkLCBidXQgdGhlIG1hY2hpbmVzIGFyZSBzdGls bCBydW5uaW5nLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlbiB3ZSBoYXZlIDIg ZGlmZmVyZW50IHNjZW5hcmlvczwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UmVib290 L3NodXRkb3duOjwvZGl2Pg0KPGRpdj5XaGVuIGkgcmVib290L3NodXRkb3duIG9uZSBvZiB0aGVz ZSBWTVMgZnJvbSBpbnNpZGUgdGhlIFZNIHRoZSBPUyBzZWVtcyB0byBzaHV0ZG93biwgaG93ZXZl ciwgdGhlIHFlbXUgcHJvY2VzcyBpcyBzdGlsbCBydW5uaW5nIGFuZCBmb3Igb3ZpcnQgdGhlIG1h Y2hpbmUgaXMgc3RpbGwgdXAsIGEg4oCcc2h1dGRvd27igJ0gaW4gdGhlIGZyb250ZW5kIGRvZXMg bm90IGRvIGFueXRoaW5nLCBhIOKAnHBvd2VyIG9mZuKAnSBzaHV0cyBkb3duIHRoZSBtYWNoaW5l PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5KdXN0IHdhaXQ6PC9kaXY+DQo8ZGl2PkFm dGVyIGEgd2hpbGUgdGhlIG1hY2hpbmVzIGp1c3Qgc2VlbSB0byBzaHV0ZG93biBhbmQgdGhlbiBi YXNpY2FsbHkgdGhlbiBzYW1lIGhhcHBlc24gYXMgd2l0aCByZWJvb3Qvc2h1dGRvd248L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBlbnZpcm9ubWVudCBpczo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pkhvc3RlZCBFbmdpbmUgb24gQ2VudE9TIDYuNiB3aXRoIG92aXJ0 IDMuNS4yLjE8L2Rpdj4NCjxkaXY+Q29tcHV0ZSBob3N0cyBvbiBGZWRvcmEgMjAgd2l0aCB2ZHNt IDQuMTYuMTQgYW5kIGxpYnZpcnQgMS4yLjkuMSBmcm9tIHRoZSBsaWJ2aXJ0LXByZXZpZXcgcmVw byAoZm9yIGxpdmUgbWVyZ2UpPC9kaXY+DQo8ZGl2PlN0b3JhZ2UgLSZndDsgQ2VudE9TIDcuMSB3 aXRoIGdsdXN0ZXIgMy42LjM8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNhbiBhbnlv bmUgcG9pbnQgdXMgdG93YXJkcyB0aGUgcmlnaHQgZGlyZWN0aW9uPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5SZWdhcmRzPC9kaXY+DQo8ZGl2PlNvZXJlbiZuYnNwOzwvZGl2Pg0KPGRp dj4NCjxkaXYgaWQ9IiI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_BE85E676B6644C8787ACFF9C76B9E900mconnet_--

1 0

NFS export domain still remain in "Preparing for maintenance"
by NUNIN Roberto 20 May '15

20 May '15

--_000_8C2CD99696B62B409EBEBFDF87C83FBF59B64FEB81DENU1XMAIL02p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all We are using oVirt engine 3.5.1-0.0 on Centos 6.6 We have two DC. One with hosts using vdsm-4.16.10-8.gitc937927.el7.x86_64, = the other vdsm-4.16.12-7.gita30da75.el6.x86_64 on Centos6.6 No hosted-engine, it run on a dedicates VM, outside oVirt. Behavior: When try to put the NFS export currently active and attached to t= he 6.6 cluster, used to move VM from one DC to the other, this remain indef= initely in "Preparing for maintenance phase". No DNS resolution issue in place. All parties involved are solved directly = and via reverse resolution. I've read about the issue on el7 and IPv6 bug, but here we have the problem= on Centos 6.6 hosts. Any idea/suggestion/further investigation ? Can we reinitialize the NFS export in some way ? Only erasing content ? Thanks in advance for any suggestion. Roberto Nunin Italy ________________________________ Questo messaggio e' indirizzato esclusivamente al destinatario indicato e p= otrebbe contenere informazioni confidenziali, riservate o proprietarie. Qua= lora la presente venisse ricevuta per errore, si prega di segnalarlo immedi= atamente al mittente, cancellando l'originale e ogni sua copia e distruggen= do eventuali copie cartacee. Ogni altro uso e' strettamente proibito e potr= ebbe essere fonte di violazione di legge. This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise private information. If you have received it i= n error, please notify the sender immediately, deleting the original and al= l copies and destroying any hard copies. Any other use is strictly prohibit= ed and may be unlawful. --_000_8C2CD99696B62B409EBEBFDF87C83FBF59B64FEB81DENU1XMAIL02p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"IT" link=3D"blue" vlink=3D"purple"> <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"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">We are using oVirt engine 3.5.1= -0.0 on Centos 6.6<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">We have two DC. One with hosts = using vdsm-4.16.10-8.gitc937927.el7.x86_64, the other vdsm-4.16.12-7.gita30= da75.el6.x86_64 on Centos6.6<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">No hosted-engine, it run on a d= edicates VM, outside oVirt.<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">Behavior: When try to put the N= FS export currently active and attached to the 6.6 cluster, used to move VM= from one DC to the other, this remain indefinitely in “Preparing for= maintenance phase”.<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">No DNS resolution issue in plac= e. All parties involved are solved directly and via reverse resolution.<o:p= ></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">I’ve read about the issue= on el7 and IPv6 bug, but here we have the problem on Centos 6.6 hosts.<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">Any idea/suggestion/further inv= estigation ?<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">Can we reinitialize the NFS exp= ort in some way ? Only erasing content ?<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">Thanks in advance for any sugge= stion.<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"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si= ze:10.0pt;font-family:Consolas;mso-fareast-language:IT">Roberto Nunin<o:p><= /o:p></span></p> <p class=3D"MsoNormal" style=3D"text-autospace:none"><span style=3D"font-si= ze:10.0pt;font-family:Consolas;mso-fareast-language:IT">Italy<o:p></o:p></s= pan></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <br> <hr> <font face=3D"Courier New" color=3D"Black" size=3D"2">Questo messaggio e' i= ndirizzato esclusivamente al destinatario indicato e potrebbe contenere inf= ormazioni confidenziali, riservate o proprietarie. Qualora la presente veni= sse ricevuta per errore, si prega di segnalarlo immediatamente al mittente, cancellando l'originale e ogni sua copia e dis= truggendo eventuali copie cartacee. Ogni altro uso e' strettamente proibito= e potrebbe essere fonte di violazione di legge.<br> <br> This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise private information. If you have received it i= n error, please notify the sender immediately, deleting the original and al= l copies and destroying any hard copies. Any other use is strictly prohibited and may be unlawful.<br> </font> </body> </html> --_000_8C2CD99696B62B409EBEBFDF87C83FBF59B64FEB81DENU1XMAIL02p_--

2 5

Linux VMs get stuck after Live Migration
by Soeren Malchow 20 May '15

20 May '15

--_000_421460FF6BCD498AB3700C5139BC6AD5mconnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCldlIGFyZSBleHBlcmllbmNpbmcgYSBwcm9ibGVtIHdpdGggTGludXggVm1z IHNwZWNpZmljYWxseSB0aGUgVm1zIHdlIHRlc3RlZCBhcmUgQ2VudE9TIDcuMSAoc28gZmFyIGl0 IGxvb2tzIGFzIGlmIFdpbmRvd3MgVm1zIGFyZSBub3QgYSBwcm9ibGVtKSwgYWZ0ZXIgdGhlIGxp dmUgbWlncmF0aW9uIHRoZSBtYWNoaW5lcyBkbyBub3Qgc2hvdyB0aGUgSVAgYW5kIGhvc3RuYW1l IGluIHRoZSBHVUksIHRoZSBzYW1lIHdheSBhcyBpZiB0aGUgZ3Vlc3QgdG9vbHMgYXJlIG5vdCBp bnN0YWxsZWQsIGJ1dCB0aGUgbWFjaGluZXMgYXJlIHN0aWxsIHJ1bm5pbmcuDQoNClRoZW4gd2Ug aGF2ZSAyIGRpZmZlcmVudCBzY2VuYXJpb3MNCg0KUmVib290L3NodXRkb3duOg0KV2hlbiBpIHJl Ym9vdC9zaHV0ZG93biBvbmUgb2YgdGhlc2UgVk1TIGZyb20gaW5zaWRlIHRoZSBWTSB0aGUgT1Mg c2VlbXMgdG8gc2h1dGRvd24sIGhvd2V2ZXIsIHRoZSBxZW11IHByb2Nlc3MgaXMgc3RpbGwgcnVu bmluZyBhbmQgZm9yIG92aXJ0IHRoZSBtYWNoaW5lIGlzIHN0aWxsIHVwLCBhIOKAnHNodXRkb3du 4oCdIGluIHRoZSBmcm9udGVuZCBkb2VzIG5vdCBkbyBhbnl0aGluZywgYSDigJxwb3dlciBvZmbi gJ0gc2h1dHMgZG93biB0aGUgbWFjaGluZQ0KDQpKdXN0IHdhaXQ6DQpBZnRlciBhIHdoaWxlIHRo ZSBtYWNoaW5lcyBqdXN0IHNlZW0gdG8gc2h1dGRvd24gYW5kIHRoZW4gYmFzaWNhbGx5IHRoZW4g c2FtZSBoYXBwZXNuIGFzIHdpdGggcmVib290L3NodXRkb3duDQoNClRoZSBlbnZpcm9ubWVudCBp czoNCg0KSG9zdGVkIEVuZ2luZSBvbiBDZW50T1MgNi42IHdpdGggb3ZpcnQgMy41LjIuMQ0KQ29t cHV0ZSBob3N0cyBvbiBGZWRvcmEgMjAgd2l0aCB2ZHNtIDQuMTYuMTQgYW5kIGxpYnZpcnQgMS4y LjkuMSBmcm9tIHRoZSBsaWJ2aXJ0LXByZXZpZXcgcmVwbyAoZm9yIGxpdmUgbWVyZ2UpDQpTdG9y YWdlIC0+IENlbnRPUyA3LjEgd2l0aCBnbHVzdGVyIDMuNi4zDQoNCkNhbiBhbnlvbmUgcG9pbnQg dXMgdG93YXJkcyB0aGUgcmlnaHQgZGlyZWN0aW9uDQoNClJlZ2FyZHMNClNvZXJlbg0K --_000_421460FF6BCD498AB3700C5139BC6AD5mconnet_ Content-Type: text/html; charset="utf-8" Content-ID: <FCD76AD0F70A3F428467305A213B2D3F(a)liquidcampaign.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5EZWFyIGFsbCw8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldlIGFyZSBleHBlcmllbmNpbmcgYSBwcm9i bGVtIHdpdGggTGludXggVm1zIHNwZWNpZmljYWxseSB0aGUgVm1zIHdlIHRlc3RlZCBhcmUgQ2Vu dE9TIDcuMSAoc28gZmFyIGl0IGxvb2tzIGFzIGlmIFdpbmRvd3MgVm1zIGFyZSBub3QgYSBwcm9i bGVtKSwgYWZ0ZXIgdGhlIGxpdmUgbWlncmF0aW9uIHRoZSBtYWNoaW5lcyBkbyBub3Qgc2hvdyB0 aGUgSVAgYW5kIGhvc3RuYW1lIGluIHRoZSBHVUksIHRoZSBzYW1lIHdheSBhcyBpZiB0aGUgZ3Vl c3QNCiB0b29scyBhcmUgbm90IGluc3RhbGxlZCwgYnV0IHRoZSBtYWNoaW5lcyBhcmUgc3RpbGwg cnVubmluZy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZW4gd2UgaGF2ZSAyIGRp ZmZlcmVudCBzY2VuYXJpb3M8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlYm9vdC9z aHV0ZG93bjo8L2Rpdj4NCjxkaXY+V2hlbiBpIHJlYm9vdC9zaHV0ZG93biBvbmUgb2YgdGhlc2Ug Vk1TIGZyb20gaW5zaWRlIHRoZSBWTSB0aGUgT1Mgc2VlbXMgdG8gc2h1dGRvd24sIGhvd2V2ZXIs IHRoZSBxZW11IHByb2Nlc3MgaXMgc3RpbGwgcnVubmluZyBhbmQgZm9yIG92aXJ0IHRoZSBtYWNo aW5lIGlzIHN0aWxsIHVwLCBhIOKAnHNodXRkb3du4oCdIGluIHRoZSBmcm9udGVuZCBkb2VzIG5v dCBkbyBhbnl0aGluZywgYSDigJxwb3dlciBvZmbigJ0gc2h1dHMgZG93biB0aGUgbWFjaGluZTwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SnVzdCB3YWl0OjwvZGl2Pg0KPGRpdj5BZnRl ciBhIHdoaWxlIHRoZSBtYWNoaW5lcyBqdXN0IHNlZW0gdG8gc2h1dGRvd24gYW5kIHRoZW4gYmFz aWNhbGx5IHRoZW4gc2FtZSBoYXBwZXNuIGFzIHdpdGggcmVib290L3NodXRkb3duPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgZW52aXJvbm1lbnQgaXM6PC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5Ib3N0ZWQgRW5naW5lIG9uIENlbnRPUyA2LjYgd2l0aCBvdmlydCAz LjUuMi4xPC9kaXY+DQo8ZGl2PkNvbXB1dGUgaG9zdHMgb24gRmVkb3JhIDIwIHdpdGggdmRzbSA0 LjE2LjE0IGFuZCBsaWJ2aXJ0IDEuMi45LjEgZnJvbSB0aGUgbGlidmlydC1wcmV2aWV3IHJlcG8g KGZvciBsaXZlIG1lcmdlKTwvZGl2Pg0KPGRpdj5TdG9yYWdlIC0mZ3Q7IENlbnRPUyA3LjEgd2l0 aCBnbHVzdGVyIDMuNi4zPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5DYW4gYW55b25l IHBvaW50IHVzIHRvd2FyZHMgdGhlIHJpZ2h0IGRpcmVjdGlvbjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+UmVnYXJkczwvZGl2Pg0KPGRpdj5Tb2VyZW4mbmJzcDs8L2Rpdj4NCjxkaXY+ DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_421460FF6BCD498AB3700C5139BC6AD5mconnet_--

1 0

Missing CPU features
by Bloemen, Jurriën 20 May '15

20 May '15

--_000_D180F3484A93jurrienbloemendmcamcnetworkscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, I try to add a new host to a new cluster but I get this message: Host <hostname> moved to Non-Operational state as host does not meet the cl= uster's minimum CPU level. Missing CPU features : model_Haswell The engine.log shows: 2015-05-19 13:54:09,843 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (ajp--127.0.0.1-8702-2) [a4e6c90] Lock Acquired to object EngineLock [exc= lusiveLocks=3D key: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 value: VDS , sharedLocks=3D ] 2015-05-19 13:54:09,868 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Running command: ActivateVd= sCommand internal: false. Entities affected : ID: 1ac98a04-41ed-40b7-8f02-= e1b9cbbc5480 Type: VDSAction group MANIPULATE_HOST with role type ADMIN 2015-05-19 13:54:09,869 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Before acquiring lock in or= der to prevent monitoring for host <hostname> from data-center DMC 2015-05-19 13:54:09,870 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Lock acquired, from now a m= onitoring of host will be skipped for host <hostname> from data-center DMC 2015-05-19 13:54:09,885 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatus= VDSCommand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] START, SetVdsStat= usVDSCommand(HostName =3D <hostname>, HostId =3D 1ac98a04-41ed-40b7-8f02-e1= b9cbbc5480, status=3DUnassigned, nonOperationalReason=3DNONE, stopSpmFailur= eLogged=3Dfalse), log id: 3ec2e03a 2015-05-19 13:54:09,890 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatus= VDSCommand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] FINISH, SetVdsSta= tusVDSCommand, log id: 3ec2e03a 2015-05-19 13:54:09,920 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Activate finished. Lock rel= eased. Monitoring can run now for host <hostname> from data-center DMC 2015-05-19 13:54:09,923 INFO [org.ovirt.engine.core.dal.dbbroker.auditlogh= andling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Cor= relation ID: a4e6c90, Job ID: 2bb9b203-0d51-4532-9b83-d261d805a19d, Call St= ack: null, Custom Event ID: -1, Message: Host <hostname> was activated by a= dmin@internal. 2015-05-19 13:54:09,926 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand= ] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Lock freed to object Engine= Lock [exclusiveLocks=3D key: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 value: VD= S , sharedLocks=3D ] 2015-05-19 13:54:11,706 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.Ge= tHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-94) [3f613a08] STAR= T, GetHardwareInfoVDSCommand(HostName =3D <hostname>, HostId =3D 1ac98a04-4= 1ed-40b7-8f02-e1b9cbbc5480, vds=3DHost[<hostname>,1ac98a04-41ed-40b7-8f02-e= 1b9cbbc5480]), log id: 32ca13a8 2015-05-19 13:54:11,712 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.Ge= tHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-94) [3f613a08] FINI= SH, GetHardwareInfoVDSCommand, log id: 32ca13a8 2015-05-19 13:54:11,726 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] = (DefaultQuartzScheduler_Worker-94) [3f613a08] Host <hostname> is running wi= th disabled SELinux. 2015-05-19 13:54:11,748 INFO [org.ovirt.engine.core.bll.HandleVdsCpuFlagsO= rClusterChangedCommand] (DefaultQuartzScheduler_Worker-94) [1f024fdb] Runni= ng command: HandleVdsCpuFlagsOrClusterChangedCommand internal: true. Entiti= es affected : ID: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS 2015-05-19 13:54:11,772 INFO [org.ovirt.engine.core.bll.SetNonOperationalV= dsCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] Running command: S= etNonOperationalVdsCommand internal: true. Entities affected : ID: 1ac98a0= 4-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS 2015-05-19 13:54:11,786 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatus= VDSCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] START, SetVdsStat= usVDSCommand(HostName =3D <hostname> HostId =3D 1ac98a04-41ed-40b7-8f02-e1= b9cbbc5480, status=3DNonOperational, nonOperationalReason=3DCPU_TYPE_INCOMP= ATIBLE_WITH_CLUSTER, stopSpmFailureLogged=3Dfalse), log id: 24054dd4 2015-05-19 13:54:11,789 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatus= VDSCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] FINISH, SetVdsSta= tusVDSCommand, log id: 24054dd4 2015-05-19 13:54:11,796 WARN [org.ovirt.engine.core.dal.dbbroker.auditlogh= andling.AuditLogDirector] (DefaultQuartzScheduler_Worker-94) [3ccdb219] Cor= relation ID: 1f024fdb, Call Stack: null, Custom Event ID: -1, Message: Host= <hostname> moved to Non-Operational state as host does not meet the cluste= r's minimum CPU level. Missing CPU features : model_Haswell 2015-05-19 13:54:11,813 INFO [org.ovirt.engine.core.dal.dbbroker.auditlogh= andling.AuditLogDirector] (DefaultQuartzScheduler_Worker-94) [3ccdb219] Cor= relation ID: null, Call Stack: null, Custom Event ID: -1, Message: Status o= f host <hostname> was set to NonOperational. 2015-05-19 13:54:11,839 INFO [org.ovirt.engine.core.bll.HandleVdsVersionCo= mmand] (DefaultQuartzScheduler_Worker-94) [4bb0a00] Running command: Handle= VdsVersionCommand internal: true. Entities affected : ID: 1ac98a04-41ed-40= b7-8f02-e1b9cbbc5480 Type: VDS 2015-05-19 13:54:11,841 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRun= TimeInfo] (DefaultQuartzScheduler_Worker-94) [4bb0a00] Host 1ac98a04-41ed-4= 0b7-8f02-e1b9cbbc5480 : <hostname> is already in NonOperational status for = reason CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER. SetNonOperationalVds command is = skipped. It says that the host has not meet the minimum CPU level. =93lscpu" has the= following output: # lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 56 On-line CPU(s) list: 0-55 Thread(s) per core: 2 Core(s) per socket: 14 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 63 Model name: Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz Stepping: 2 CPU MHz: 1957.007 BogoMIPS: 5206.30 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 35840K NUMA node0 CPU(s): 0-13,28-41 NUMA node1 CPU(s): 14-27,42-55 This model is a haswell: http://ark.intel.com/products/81059/Intel-Xeon-Pro= cessor-E5-2697-v3-35M-Cache-2_60-Ghz<http://ark.intel.com/products/81059/In= tel-Xeon-Processor-E5-2697-v3-35M-Cache-2_60-GHz> and http://ark.intel.com/= products/codename/42174/Haswell#@All Is this a bug? Should I make a bug report at bugzilla for this? Or am I mis= sing something? Kind regards, Jurri=EBn Bloemen This message (including any attachments) may contain information that is pr= ivileged or confidential. If you are not the intended recipient, please not= ify the sender and delete this email immediately from your systems and dest= roy all copies of it. You may not, directly or indirectly, use, disclose, d= istribute, print or copy this email or any part of it if you are not the in= tended recipient --_000_D180F3484A93jurrienbloemendmcamcnetworkscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <42B749253886BC48BF746A5ED0F34094(a)chellomedia.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif;"> <div>Hi all,</div> <div><br> </div> <div>I try to add a new host to a new cluster but I get this message:</div> <div><br> </div> <div>Host <hostname> moved to Non-Operational state as host does not = meet the cluster's minimum CPU level. Missing CPU features : model_Haswell<= /div> <div><br> </div> <div>The engine.log shows:</div> <div><br> </div> <div> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,843 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (ajp--127.0.0.1-8702-2) [a4e6c90] Lock Acquired to object EngineLock= [exclusiveLocks=3D key: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 value: VDS</p= > <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> , sharedLocks=3D ]</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,868 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Running command: Activ= ateVdsCommand internal: false. Entities affected :  ID: 1ac98a04-41ed-= 40b7-8f02-e1b9cbbc5480 Type: VDSAction group MANIPULATE_HOST with role type ADMIN</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,869 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Before acquiring lock = in order to prevent monitoring for host <hostname> from data-center D= MC</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,870 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Lock acquired, from no= w a monitoring of host will be skipped for host <hostname> = from data-center DMC</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,885 INFO  [org.ovirt.engine.core.vdsbroker.SetVdsS= tatusVDSCommand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] START, SetVd= sStatusVDSCommand(HostName =3D <hostname>, HostId =3D 1ac98a04-41ed-4= 0b7-8f02-e1b9cbbc5480, status=3DUnassigned, nonOperationalReason=3DNONE, stopSpmFailureLogged=3Dfalse), log id: 3ec2e03a</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,890 INFO  [org.ovirt.engine.core.vdsbroker.SetVdsS= tatusVDSCommand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] FINISH, SetV= dsStatusVDSCommand, log id: 3ec2e03a</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,920 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Activate finished. Loc= k released. Monitoring can run now for host <hostname> from data-cent= er DMC</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,923 INFO  [org.ovirt.engine.core.dal.dbbroker.audi= tloghandling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-14) [a4e6c90= ] Correlation ID: a4e6c90, Job ID: 2bb9b203-0d51-4532-9b83-d261d805a19d, Ca= ll Stack: null, Custom Event ID: -1, Message: Host <hostname> was activated by admin@internal.</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:09,926 INFO  [org.ovirt.engine.core.bll.ActivateVdsCo= mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Lock freed to object E= ngineLock [exclusiveLocks=3D key: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 valu= e: VDS</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> , sharedLocks=3D ]</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,706 INFO  [org.ovirt.engine.core.vdsbroker.vdsbrok= er.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-94) [3f613a08]= START, GetHardwareInfoVDSCommand(HostName =3D <hostname>, HostI= d =3D 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480, vds=3DHost[<hostname>,1ac= 98a04-41ed-40b7-8f02-e1b9cbbc5480]), log id: 32ca13a8</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,712 INFO  [org.ovirt.engine.core.vdsbroker.vdsbrok= er.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-94) [3f613a08]= FINISH, GetHardwareInfoVDSCommand, log id: 32ca13a8</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,726 WARN  [org.ovirt.engine.core.vdsbroker.VdsMana= ger] (DefaultQuartzScheduler_Worker-94) [3f613a08] Host <hostname> is= running with disabled SELinux.</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,748 INFO  [org.ovirt.engine.core.bll.HandleVdsCpuF= lagsOrClusterChangedCommand] (DefaultQuartzScheduler_Worker-94) [1f024fdb] = Running command: HandleVdsCpuFlagsOrClusterChangedCommand internal: true. E= ntities affected :  ID: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,772 INFO  [org.ovirt.engine.core.bll.SetNonOperati= onalVdsCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] Running comma= nd: SetNonOperationalVdsCommand internal: true. Entities affected :  I= D: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,786 INFO  [org.ovirt.engine.core.vdsbroker.SetVdsS= tatusVDSCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] START, SetVd= sStatusVDSCommand(HostName =3D <hostname>  HostId =3D 1ac98= a04-41ed-40b7-8f02-e1b9cbbc5480, status=3DNonOperational, nonOperationalRea= son=3DCPU_TYPE_INCOMPATIBLE_WITH_CLUSTER, stopSpmFailureLogged=3Dfalse), log id: 24054dd4</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,789 INFO  [org.ovirt.engine.core.vdsbroker.SetVdsS= tatusVDSCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] FINISH, SetV= dsStatusVDSCommand, log id: 24054dd4</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,796 WARN  [org.ovirt.engine.core.dal.dbbroker.audi= tloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-94) [3ccdb219= ] Correlation ID: 1f024fdb, Call Stack: null, Custom Event ID: -1, Message:= Host <hostname> moved to Non-Operational state as host does not meet the cluster's minimum CPU level. Missing CPU f= eatures : model_Haswell</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,813 INFO  [org.ovirt.engine.core.dal.dbbroker.audi= tloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-94) [3ccdb219= ] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: Sta= tus of host <hostname> was set to NonOperational.</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,839 INFO  [org.ovirt.engine.core.bll.HandleVdsVers= ionCommand] (DefaultQuartzScheduler_Worker-94) [4bb0a00] Running command: H= andleVdsVersionCommand internal: true. Entities affected :  ID: 1ac98a= 04-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> 2015-05-19 13:54:11,841 INFO  [org.ovirt.engine.core.vdsbroker.VdsUpda= teRunTimeInfo] (DefaultQuartzScheduler_Worker-94) [4bb0a00] Host 1ac98a04-4= 1ed-40b7-8f02-e1b9cbbc5480 : <hostname> is already in NonOp= erational status for reason CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER. SetNonOperationalVds command is skipped.</p> </div> <div><br> </div> <div>It says that the host has not meet the minimum CPU level. =93lscpu&quo= t; has the following output:</div> <div><br> </div> <div> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> # lscpu</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Architecture:          x86_64</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> CPU op-mode(s):        32-bit, 64-bit</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Byte Order:            Little Endian</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> CPU(s):                56</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> On-line CPU(s) list:   0-55</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Thread(s) per core:    2</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Core(s) per socket:    14</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Socket(s):             2</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> NUMA node(s):          2</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Vendor ID:             GenuineIntel</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> CPU family:            6</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Model:                 63</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Model name:            Intel(R) Xeon(R) CPU E= 5-2697 v3 @ 2.60GHz</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Stepping:              2</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> CPU MHz:               1957.007</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> BogoMIPS:              5206.30</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> Virtualization:        VT-x</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> L1d cache:             32K</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> L1i cache:             32K</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> L2 cache:              256K</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> L3 cache:              35840K</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> NUMA node0 CPU(s):     0-13,28-41</p> <p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color= : rgb(245, 245, 245); background-color: rgb(0, 0, 0);"> NUMA node1 CPU(s):     14-27,42-55</p> </div> <div><br> </div> <div>This model is a haswell: <a href=3D"http://ark.intel.com/products= /81059/Intel-Xeon-Processor-E5-2697-v3-35M-Cache-2_60-GHz">http://ark.intel= .com/products/81059/Intel-Xeon-Processor-E5-2697-v3-35M-Cache-2_60-Ghz</a>&= nbsp;and <a href=3D"http://ark.intel.com/products/codename/42174/Haswe= ll#@All">http://ark.intel.com/products/codename/42174/Haswell#@All</a></div= > <div><br> </div> <div>Is this a bug? Should I make a bug report at bugzilla for this? Or am = I missing something?</div> <div><br> </div> <div>Kind regards,</div> <div><br> </div> <div>Jurri=EBn Bloemen</div> This message (including any attachments) may contain information that is pr= ivileged or confidential. If you are not the intended recipient, please not= ify the sender and delete this email immediately from your systems and dest= roy all copies of it. You may not, directly or indirectly, use, disclose, distribute, print or copy this emai= l or any part of it if you are not the intended recipient </body> </html> --_000_D180F3484A93jurrienbloemendmcamcnetworkscom_--

2 2

Re: [ovirt-users] missing disk after storage domain expansion [SOLVED]
by Andrea Ghelardi 20 May '15

20 May '15

Thanks for all your information. I created a linux script as per details below. Attached to this email (some info purged) Gentlemen, we have a disk now! I'm marking the post as solved ... even though we do not know where the disk gone in these weeks yet. Probably unexpected vacation @Cuba? This disk won't reclaim expenses though I will create a test VM and perform some tests in the future with the expansion feature Thank you for all your support More cats: https://www.youtube.com/watch?v=cWKmorjUzF0 AG -----Original Message----- From: Juan Hernández [mailto:jhernand@redhat.com] Sent: Wednesday, May 20, 2015 10:37 AM To: Maor Lipchuk; Andrea Ghelardi Cc: users(a)ovirt.org Subject: Re: [ovirt-users] missing disk after storage domain expansion On 05/19/2015 06:23 PM, Maor Lipchuk wrote: > Hi Andrea, > > I'm using "postman" chrome-extension to execute my REST requests. > > For firefox the rest-client add-on you can use is > https://addons.mozilla.org/de/firefox/addon/restclient/ > > Juan, do we have a wiki for step by step instructions of REST > > Regards, > Maor > I'd suggest to try a command line client, as it is easier to share the results and check what is going wrong. You can use the "curl" command, for example. Assuming that you already know the identifiers of the storage domain and of the disk to register it should be something like this: ---8<--- #!/bin/sh -ex url="https://yourengine/ovirt-engine/api" user="your user" password="your password" storage_domain_id="the storage domain id" disk_id="the disk id" curl \ --verbose \ --insecure \ --user "${user}:${password}" \ --request POST \ --header "Content-Type: application/xml" \ --header "Accept: application/xml" \ --data " <disk id=\"${disk_id}\"/> " \ "${url}/storagedomains/${storage_domain_id}/disks;unregistered" --->8--- > > ----- Original Message ----- >> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> >> To: "Maor Lipchuk" <mlipchuk(a)redhat.com> >> Cc: users(a)ovirt.org >> Sent: Tuesday, May 19, 2015 4:46:09 PM >> Subject: RE: [ovirt-users] missing disk after storage domain >> expansion >> >> I got an error but I'm not 100% sure I did everything correctly Error >> below: >> <html><head><title>JBoss Web/7.0.13.Final - Error >> report</title><style></style> </head><body><h1>HTTP Status 415 - Cannot >> consume content type</h1><HR size="1" >> noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> >> <u>Cannot consume content type</u></p><p><b>description</b> <u>The >> server refused this request because the request entity is in a format >> not supported by the requested resource for the requested method >> (Cannot consume content type).</u></p><HR size="1" >> noshade="noshade"><h3>JBoss Web/7.0.13.Final</h3></body></html> >> >> Actions: >> Used RESTclient 2.3.0 for Firefox to POST this body <disk >> id='16736ce0-a9df-410f-9f29-3a28364cdd41'></disk> >> >> I think I need a step by step guide about how to use the REST client >> to POST commands to ovirt service remotely >> >> Cheers >> AG >> >> -----Original Message----- >> From: Maor Lipchuk [mailto:mlipchuk@redhat.com] >> Sent: Monday, May 18, 2015 4:50 PM >> To: Andrea Ghelardi >> Subject: Re: [ovirt-users] missing disk after storage domain >> expansion >> >> I've went through the logs, though I didn't noticed any special >> information. >> Please let me know how the registration of the disk went. >> >> Regards, >> Maor >> >> >> >> ----- Original Message ----- >>> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> >>> To: "Maor Lipchuk" <mlipchuk(a)redhat.com> >>> Sent: Monday, May 18, 2015 4:35:30 PM >>> Subject: RE: [ovirt-users] missing disk after storage domain >>> expansion >>> >>> Here the full set of logs as promised. >>> >>> Unfortunately, I do not think I have vdsm logs pointing to that date >>> (logs rotated already). >>> I tried to search for >>> xzgrep 16736ce0-a9df-410f-9f29-3a28364cdd41 /var/log/vdsm/* but >>> nothing found >>> >>> cheers >>> AG >>> >>> -----Original Message----- >>> From: Andrea Ghelardi [mailto:a.ghelardi@iontrading.com] >>> Sent: Monday, May 18, 2015 3:30 PM >>> To: 'Maor Lipchuk' >>> Cc: 'users(a)ovirt.org' >>> Subject: RE: [ovirt-users] missing disk after storage domain >>> expansion >>> >>> Hi Maor, >>> >>> 1) disk creation: ok >>> 2) no free space at the moment of creation: this is very strange! >>> Are you sure? I assure you the disk was working, exported to VM >>> which formatted and wrote data on it >>> 3) no disk removal mention: this is the very issue I'm facing. In >>> fact disk disappeared with no notification, no logs, nothing. I'm >>> forwarding you full set of engine.log separately. If you need >>> vdsm.logs just tell me from which server you need it as I have >>> several cluster. >>> 4) I have not yet tried to register using the procedure you provided >>> me earlier. I'll try tomorrow. >>> >>> Thanks >>> AG >>> >>> >>> -----Original Message----- >>> From: Maor Lipchuk [mailto:mlipchuk@redhat.com] >>> Sent: Monday, May 18, 2015 1:15 PM >>> To: Andrea Ghelardi >>> Cc: users(a)ovirt.org >>> Subject: Re: [ovirt-users] missing disk after storage domain >>> expansion >>> >>> Hi Andrea, >>> >>> I guessed I missed those logs, I found it now, thanks. >>> >>> I do see the disk creation in the log from 20150501, I can also see >>> that the Storage Domain hertz-dstore2 has 0 GB of free space at the >>> moment of >>> creation: >>> 2015-05-01 03:30:05,801 ERROR >>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirecto >>> r] >>> (DefaultQuartzScheduler_Worker-92) Correlation ID: null, Call Stack: >>> null, Custom Event ID: -1, Message: Critical, Low disk space. >>> hertz-dstore2 domain has 0 GB of free space >>> >>> though, I don't see any indication of the removed disks from the engine. >>> I have also noticed a gap from the first log which finished at >>> 2015-05-01 >>> 03:30:05 and the other log which starts at 2015-05-04 03:22:19,879. >>> >>> Did you try to register the disk as described in the wiki? >>> >>> Regards, >>> Maor >>> >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> >>>> To: "Maor Lipchuk" <mlipchuk(a)redhat.com> >>>> Cc: users(a)ovirt.org >>>> Sent: Monday, May 18, 2015 12:10:55 PM >>>> Subject: RE: [ovirt-users] missing disk after storage domain >>>> expansion >>>> >>>> Hi Maor, >>>> I already added logs in my previous email, did you received them? >>>> I'm sending them again, but only privately to you not to burden the >>>> mailing list (or let me know if you prefer otherwise). >>>> >>>> Cheers >>>> AG >>>> >>>> >>>> -----Original Message----- >>>> From: Maor Lipchuk [mailto:mlipchuk@redhat.com] >>>> Sent: Saturday, May 16, 2015 10:03 AM >>>> To: Andrea Ghelardi >>>> Cc: users(a)ovirt.org >>>> Subject: Re: [ovirt-users] missing disk after storage domain >>>> expansion >>>> >>>> Hi Andrea, >>>> >>>> The OVF_STORE disks are disks which mainly being used internally in >>>> the engine to store VMs' and Templates' OVFs, you can disregard >>>> them for now. >>>> >>>> The behavior you mentioned, that suddenly the disk has disappeared >>>> from the setup, sounds very weird and I would like to investigate >>>> this a bit more. >>>> if you can please add the engine and vdsm logs, I can know what >>>> made the disk get removed from the setup, at the first place. >>>> Could it be that some one accessed the data base by any chance? >>>> >>>> Regarding the disk registration, basically it should not create any >>>> problems unless, if your disk was deleted manually form the DB, and >>>> there are still leftovers related to the disk in some of the tables. >>>> Once the disk is registered to the setup, you can try to attach it >>>> to the VM, and try to run it. >>>> >>>> >>>> Regards, >>>> Maor >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> >>>>> To: "Maor Lipchuk" <mlipchuk(a)redhat.com> >>>>> Cc: users(a)ovirt.org >>>>> Sent: Friday, May 15, 2015 4:54:25 PM >>>>> Subject: RE: [ovirt-users] missing disk after storage domain >>>>> expansion >>>>> >>>>> After querying the hosted engine with the suggested command >>>>> https://pisa-ion-ovirtm-01/ovirt-engine/api/storagedomains/7a48fe4 >>>>> 6- >>>>> 21 12-40a4-814f-24d74c760b2d/disks;unregistered >>>>> >>>>> Indeed shows a (unregistered?) disk >>>>> >>>>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <disks> >>>>> <disk >>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41" >>>>> id="16736ce0-a9df-410f-9f29-3a28364cdd41"> >>>>> <actions> >>>>> <link >>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/export" >>>>> rel="export"/> >>>>> </actions> >>>>> <name>hertz_disk5</name> >>>>> <description>disk for SYBASE installation, on SAN shared >>>>> storage</description> <link >>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/permissions" >>>>> rel="permissions"/> >>>>> <link >>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/statistics" >>>>> rel="statistics"/> >>>>> <alias>hertz_disk5</alias> >>>>> <image_id>4ab070c0-fb16-452d-8521-4ff0b004aef3</image_id> >>>>> <storage_domain >>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d" >>>>> id="7a48fe46-2112-40a4-814f-24d74c760b2d"/> >>>>> <storage_domains> >>>>> <storage_domain id="7a48fe46-2112-40a4-814f-24d74c760b2d"/> >>>>> </storage_domains> >>>>> <size>225485783040</size> >>>>> <provisioned_size>225485783040</provisioned_size> >>>>> <actual_size>225485783040</actual_size> >>>>> <status> >>>>> <state>ok</state> >>>>> </status> >>>>> <interface>ide</interface> >>>>> <format>raw</format> >>>>> <sparse>false</sparse> >>>>> <bootable>false</bootable> >>>>> <shareable>false</shareable> >>>>> <wipe_after_delete>false</wipe_after_delete> >>>>> <propagate_errors>false</propagate_errors> >>>>> </disk> >>>>> </disks> >>>>> >>>>> I'm waiting for any comments on the two OVF disk or any advice >>>>> before proceeding with the registering command (test in production >>>>> environment hmmmmm) >>>>> >>>>> Cheers >>>>> AG >>>>> >>>>> -----Original Message----- >>>>> From: Andrea Ghelardi [mailto:a.ghelardi@iontrading.com] >>>>> Sent: Friday, May 15, 2015 12:30 PM >>>>> To: Maor Lipchuk >>>>> Cc: users(a)ovirt.org >>>>> Subject: RE: [ovirt-users] missing disk after storage domain >>>>> expansion >>>>> >>>>> Thank you for your reply! >>>>> I'm unsure if the disk contained any snapshots. I do not think so. >>>>> Is the register action a safe one to do in production system? I >>>>> wouldn't mess any of my existing running servers. >>>>> >>>>> Here the relevant logs from the date >>>>> ./engine.log-20150501.gz:2015-04-29 16:10:40,868 : disk creation >>>>> ("hertz_disk5" newImageId = 4ab070c0-fb16-452d-8521-4ff0b004aef3) >>>>> ./engine.log-20150512.gz:2015-05-04 17:22:42,691 : last >>>>> occurrence of the imageid >>>>> >>>>> Please note from >>>>> ./engine.log-20150512.gz 2015-05-11 12:07:16,719 : creation of >>>>> two disk OVF store (??) on the same storage domain >>>>> 7a48fe46-2112-40a4-814f-24d74c760b2d >>>>> right after the volume expansion >>>>> >>>>> In the instructions.txt what I did to enlarge the volume (and >>>>> lose the >>>>> disk) (the guides is informational only, I followed the steps on a >>>>> different >>>>> server) >>>>> >>>>> Here some cats to thank you in advance >>>>> https://www.youtube.com/watch?v=nfTY41-zC7Y >>>> >>>> >>>> lol :) >>>> Nice cats >>>> >>>>> AG >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Maor Lipchuk [mailto:mlipchuk@redhat.com] >>>>> Sent: Wednesday, May 13, 2015 11:02 PM >>>>> To: Andrea Ghelardi >>>>> Cc: users(a)ovirt.org >>>>> Subject: Re: [ovirt-users] missing disk after storage domain >>>>> expansion >>>>> >>>>> Hi Andrea, >>>>> >>>>> First of all, the issue sounds quite severe, can u please attach >>>>> the engine logs so we can try to figure out how that happened. >>>>> second, does this disk contained any snapshots? >>>>> If not, can you try to register it back (see >>>>> http://www.ovirt.org/Features/ImportStorageDomain#Register_an_unre >>>>> gi >>>>> st >>>>> ered_disk) >>>>> >>>>> >>>>> Regards, >>>>> Maor >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> >>>>>> To: users(a)ovirt.org >>>>>> Sent: Monday, May 11, 2015 12:01:17 AM >>>>>> Subject: Re: [ovirt-users] missing disk after storage domain >>>>>> expansion >>>>>> >>>>>> >>>>>> >>>>>> Ok, so, >>>>>> >>>>>> After _ a lot _ of unsuccessful approach, I finally connected to >>>>>> postegre DB directly. >>>>>> >>>>>> Browsing the tables I found “unregistered_ovf_of_entities” where >>>>>> there is a reference of the missing disk >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> @ovf:diskId:4ab070c0-fb16-452d-8521-4ff0b004aef3 >>>>>> >>>>>> @ovf:size:210 >>>>>> >>>>>> @ovf:actual_size:210 >>>>>> >>>>>> @ovf:vm_snapshot_id:2e24b255-bb84-4284-8785-e2a042045882 >>>>>> >>>>>> @ovf:fileRef:16736ce0-a9df-410f-9f29-3a28364cdd41/4ab070c0-fb16- >>>>>> 45 >>>>>> 2d >>>>>> -8 >>>>>> 521-4ff0b004aef3 >>>>>> >>>>>> @ovf:format: >>>>>> http://www.vmware.com/specifications/vmdk.html#sparse >>>>>> >>>>>> @ovf:volume-format:RAW >>>>>> >>>>>> @ovf:volume-type:Preallocated >>>>>> >>>>>> @ovf:disk-interface:VirtIO >>>>>> >>>>>> @ovf:boot:false >>>>>> >>>>>> @ovf:disk-alias:hertz_disk5 >>>>>> >>>>>> @ovf:disk-description:disk for SYBASE installation, on SAN shared >>>>>> storage >>>>>> >>>>>> @ovf:wipe-after-delete:false >>>>>> >>>>>> >>>>>> >>>>>> However, I’ve been unable to find any other helpful details. >>>>>> >>>>>> I guess the disk is not recoverable at this point? >>>>>> >>>>>> Any guru who has a good ovirt DB kwnoledge willing to give me >>>>>> some advice? >>>>>> >>>>>> >>>>>> >>>>>> Thanks as usual >>>>>> >>>>>> AG >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> From: Andrea Ghelardi [mailto: a.ghelardi(a)iontrading.com ] >>>>>> Sent: Thursday, May 07, 2015 6:08 PM >>>>>> To: ' users(a)ovirt.org ' >>>>>> Subject: missing disk after storage domain expansion >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Hi gentlemen, >>>>>> >>>>>> >>>>>> >>>>>> I recently found an error on 1 of my storages: it was complaining >>>>>> about no free space but the VM was running and disk operational. >>>>>> >>>>>> Since I needed to perform some maintenance on the VM, I shut it >>>>>> down and at restart VM couldn’t boot up properly. >>>>>> >>>>>> Checked VM via console and a disk was missing. Edited fstab >>>>>> (luckily this disk was not root but heck! It had a Sybase DB on >>>>>> it!) and restarted VM this time ok. >>>>>> >>>>>> >>>>>> >>>>>> Since the disk resides on the dstore with no space, I expanded >>>>>> the iSCSI LUN, then refreshed multipath on hosts, then resized >>>>>> PVs and now ovirt is showing the correct size (logs do not >>>>>> complain anymore on no free space). >>>>>> >>>>>> >>>>>> >>>>>> BUUUT >>>>>> >>>>>> >>>>>> >>>>>> Now disk is missing. It is not shown anymore on Disks tab nor >>>>>> anywhere else. >>>>>> >>>>>> Problem is that storage shows 214GB occupancy (size of the >>>>>> missing >>>>>> disk) so data is there but cannot find it anymore. >>>>>> >>>>>> >>>>>> >>>>>> Logs show original disk creation, errors from the lack of space, >>>>>> refresh of the storage size and then.... no more references on >>>>>> the disk. >>>>>> >>>>>> >>>>>> >>>>>> What can I do to find those missing ~210GBs? >>>>>> >>>>>> >>>>>> >>>>>> Cheers >>>>>> >>>>>> Andrea Ghelardi >>>>>> -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.

1 0

Huge, unrotated /var/log/glusterfs/cli.log
by Ernest Beinrohr 20 May '15

20 May '15

This is a multi-part message in MIME format. --------------050503090908010601040603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Does anyone else has these on their HVs? I just dropped a new logrotate config, but I think ovirt need to lower the loglevel for gluster. -- Ernest Beinrohr, AXON PRO Ing <http://www.beinrohr.sk/ing.php>, RHCE <http://www.beinrohr.sk/rhce.php>, RHCVA <http://www.beinrohr.sk/rhce.php>, LPIC <http://www.beinrohr.sk/lpic.php>, VCA <http://www.beinrohr.sk/vca.php>, +421-2-62410360 +421-903-482603 --------------050503090908010601040603 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Does anyone else has these on their HVs?<br> <br> I just dropped a new logrotate config, but I think ovirt need to lower the loglevel for gluster.<br> <br> <br> <div class="moz-signature">-- <br> <div id="oernii_footer" style="color: gray;"> <span style="font-family: Lucida Console, Luxi Mono, Courier, monospace; font-size: 90%;"> Ernest Beinrohr, AXON PRO<br> <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/ing.php">Ing</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/rhce.php">RHCE</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/rhce.php">RHCVA</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/lpic.php">LPIC</a>, <a style="text-decoration: none; color: gray;" href="http://www.beinrohr.sk/vca.php">VCA</a>, <br> +421-2-62410360 +421-903-482603 <br> </span> </div> <img src="http://nojsstats.appspot.com/UA-44497096-1/email.beinrohr.sk" moz-do-not-send="true" border="0" width="1" height="1"> </div> </body> </html> --------------050503090908010601040603--

2 1

Re: [ovirt-users] missing disk after storage domain expansion
by Andrea Ghelardi 20 May '15

20 May '15

I got an error but I'm not 100% sure I did everything correctly Error below: <html><head><title>JBoss Web/7.0.13.Final - Error report</title><style></style> </head><body><h1>HTTP Status 415 - Cannot consume content type</h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u>Cannot consume content type</u></p><p><b>description</b> <u>The server refused this request because the request entity is in a format not supported by the requested resource for the requested method (Cannot consume content type).</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/7.0.13.Final</h3></body></html> Actions: Used RESTclient 2.3.0 for Firefox to POST this body <disk id='16736ce0-a9df-410f-9f29-3a28364cdd41'></disk> I think I need a step by step guide about how to use the REST client to POST commands to ovirt service remotely Cheers AG -----Original Message----- From: Maor Lipchuk [mailto:mlipchuk@redhat.com] Sent: Monday, May 18, 2015 4:50 PM To: Andrea Ghelardi Subject: Re: [ovirt-users] missing disk after storage domain expansion I've went through the logs, though I didn't noticed any special information. Please let me know how the registration of the disk went. Regards, Maor ----- Original Message ----- > From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> > To: "Maor Lipchuk" <mlipchuk(a)redhat.com> > Sent: Monday, May 18, 2015 4:35:30 PM > Subject: RE: [ovirt-users] missing disk after storage domain expansion > > Here the full set of logs as promised. > > Unfortunately, I do not think I have vdsm logs pointing to that date > (logs rotated already). > I tried to search for > xzgrep 16736ce0-a9df-410f-9f29-3a28364cdd41 /var/log/vdsm/* but > nothing found > > cheers > AG > > -----Original Message----- > From: Andrea Ghelardi [mailto:a.ghelardi@iontrading.com] > Sent: Monday, May 18, 2015 3:30 PM > To: 'Maor Lipchuk' > Cc: 'users(a)ovirt.org' > Subject: RE: [ovirt-users] missing disk after storage domain expansion > > Hi Maor, > > 1) disk creation: ok > 2) no free space at the moment of creation: this is very strange! Are > you sure? I assure you the disk was working, exported to VM which > formatted and wrote data on it > 3) no disk removal mention: this is the very issue I'm facing. In fact > disk disappeared with no notification, no logs, nothing. I'm > forwarding you full set of engine.log separately. If you need > vdsm.logs just tell me from which server you need it as I have several > cluster. > 4) I have not yet tried to register using the procedure you provided > me earlier. I'll try tomorrow. > > Thanks > AG > > > -----Original Message----- > From: Maor Lipchuk [mailto:mlipchuk@redhat.com] > Sent: Monday, May 18, 2015 1:15 PM > To: Andrea Ghelardi > Cc: users(a)ovirt.org > Subject: Re: [ovirt-users] missing disk after storage domain expansion > > Hi Andrea, > > I guessed I missed those logs, I found it now, thanks. > > I do see the disk creation in the log from 20150501, I can also see > that the Storage Domain hertz-dstore2 has 0 GB of free space at the > moment of > creation: > 2015-05-01 03:30:05,801 ERROR > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > (DefaultQuartzScheduler_Worker-92) Correlation ID: null, Call Stack: > null, Custom Event ID: -1, Message: Critical, Low disk space. > hertz-dstore2 domain has 0 GB of free space > > though, I don't see any indication of the removed disks from the engine. > I have also noticed a gap from the first log which finished at > 2015-05-01 > 03:30:05 and the other log which starts at 2015-05-04 03:22:19,879. > > Did you try to register the disk as described in the wiki? > > Regards, > Maor > > > > > ----- Original Message ----- > > From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> > > To: "Maor Lipchuk" <mlipchuk(a)redhat.com> > > Cc: users(a)ovirt.org > > Sent: Monday, May 18, 2015 12:10:55 PM > > Subject: RE: [ovirt-users] missing disk after storage domain > > expansion > > > > Hi Maor, > > I already added logs in my previous email, did you received them? > > I'm sending them again, but only privately to you not to burden the > > mailing list (or let me know if you prefer otherwise). > > > > Cheers > > AG > > > > > > -----Original Message----- > > From: Maor Lipchuk [mailto:mlipchuk@redhat.com] > > Sent: Saturday, May 16, 2015 10:03 AM > > To: Andrea Ghelardi > > Cc: users(a)ovirt.org > > Subject: Re: [ovirt-users] missing disk after storage domain > > expansion > > > > Hi Andrea, > > > > The OVF_STORE disks are disks which mainly being used internally in > > the engine to store VMs' and Templates' OVFs, you can disregard them > > for now. > > > > The behavior you mentioned, that suddenly the disk has disappeared > > from the setup, sounds very weird and I would like to investigate > > this a bit more. > > if you can please add the engine and vdsm logs, I can know what made > > the disk get removed from the setup, at the first place. > > Could it be that some one accessed the data base by any chance? > > > > Regarding the disk registration, basically it should not create any > > problems unless, if your disk was deleted manually form the DB, and > > there are still leftovers related to the disk in some of the tables. > > Once the disk is registered to the setup, you can try to attach it > > to the VM, and try to run it. > > > > > > Regards, > > Maor > > > > > > > > ----- Original Message ----- > > > From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> > > > To: "Maor Lipchuk" <mlipchuk(a)redhat.com> > > > Cc: users(a)ovirt.org > > > Sent: Friday, May 15, 2015 4:54:25 PM > > > Subject: RE: [ovirt-users] missing disk after storage domain > > > expansion > > > > > > After querying the hosted engine with the suggested command > > > https://pisa-ion-ovirtm-01/ovirt-engine/api/storagedomains/7a48fe4 > > > 6- > > > 21 12-40a4-814f-24d74c760b2d/disks;unregistered > > > > > > Indeed shows a (unregistered?) disk > > > > > > <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <disks> > > > <disk > > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41" > > > id="16736ce0-a9df-410f-9f29-3a28364cdd41"> > > > <actions> > > > <link > > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/export" > > > rel="export"/> > > > </actions> > > > <name>hertz_disk5</name> > > > <description>disk for SYBASE installation, on SAN shared > > > storage</description> <link > > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/permissions" > > > rel="permissions"/> > > > <link > > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/statistics" > > > rel="statistics"/> > > > <alias>hertz_disk5</alias> > > > <image_id>4ab070c0-fb16-452d-8521-4ff0b004aef3</image_id> > > > <storage_domain > > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d" > > > id="7a48fe46-2112-40a4-814f-24d74c760b2d"/> > > > <storage_domains> > > > <storage_domain id="7a48fe46-2112-40a4-814f-24d74c760b2d"/> > > > </storage_domains> > > > <size>225485783040</size> > > > <provisioned_size>225485783040</provisioned_size> > > > <actual_size>225485783040</actual_size> > > > <status> > > > <state>ok</state> > > > </status> > > > <interface>ide</interface> > > > <format>raw</format> > > > <sparse>false</sparse> > > > <bootable>false</bootable> > > > <shareable>false</shareable> > > > <wipe_after_delete>false</wipe_after_delete> > > > <propagate_errors>false</propagate_errors> > > > </disk> > > > </disks> > > > > > > I'm waiting for any comments on the two OVF disk or any advice > > > before proceeding with the registering command (test in production > > > environment hmmmmm) > > > > > > Cheers > > > AG > > > > > > -----Original Message----- > > > From: Andrea Ghelardi [mailto:a.ghelardi@iontrading.com] > > > Sent: Friday, May 15, 2015 12:30 PM > > > To: Maor Lipchuk > > > Cc: users(a)ovirt.org > > > Subject: RE: [ovirt-users] missing disk after storage domain > > > expansion > > > > > > Thank you for your reply! > > > I'm unsure if the disk contained any snapshots. I do not think so. > > > Is the register action a safe one to do in production system? I > > > wouldn't mess any of my existing running servers. > > > > > > Here the relevant logs from the date > > > ./engine.log-20150501.gz:2015-04-29 16:10:40,868 : disk creation > > > ("hertz_disk5" newImageId = 4ab070c0-fb16-452d-8521-4ff0b004aef3) > > > ./engine.log-20150512.gz:2015-05-04 17:22:42,691 : last > > > occurrence of the imageid > > > > > > Please note from > > > ./engine.log-20150512.gz 2015-05-11 12:07:16,719 : creation of > > > two disk OVF store (??) on the same storage domain > > > 7a48fe46-2112-40a4-814f-24d74c760b2d > > > right after the volume expansion > > > > > > In the instructions.txt what I did to enlarge the volume (and > > > lose the > > > disk) (the guides is informational only, I followed the steps on a > > > different > > > server) > > > > > > Here some cats to thank you in advance > > > https://www.youtube.com/watch?v=nfTY41-zC7Y > > > > > > lol :) > > Nice cats > > > > > AG > > > > > > > > > -----Original Message----- > > > From: Maor Lipchuk [mailto:mlipchuk@redhat.com] > > > Sent: Wednesday, May 13, 2015 11:02 PM > > > To: Andrea Ghelardi > > > Cc: users(a)ovirt.org > > > Subject: Re: [ovirt-users] missing disk after storage domain > > > expansion > > > > > > Hi Andrea, > > > > > > First of all, the issue sounds quite severe, can u please attach > > > the engine logs so we can try to figure out how that happened. > > > second, does this disk contained any snapshots? > > > If not, can you try to register it back (see > > > http://www.ovirt.org/Features/ImportStorageDomain#Register_an_unre > > > gi > > > st > > > ered_disk) > > > > > > > > > Regards, > > > Maor > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com> > > > > To: users(a)ovirt.org > > > > Sent: Monday, May 11, 2015 12:01:17 AM > > > > Subject: Re: [ovirt-users] missing disk after storage domain > > > > expansion > > > > > > > > > > > > > > > > Ok, so, > > > > > > > > After _ a lot _ of unsuccessful approach, I finally connected to > > > > postegre DB directly. > > > > > > > > Browsing the tables I found “unregistered_ovf_of_entities” where > > > > there is a reference of the missing disk > > > > > > > > > > > > > > > > > > > > > > > > @ovf:diskId:4ab070c0-fb16-452d-8521-4ff0b004aef3 > > > > > > > > @ovf:size:210 > > > > > > > > @ovf:actual_size:210 > > > > > > > > @ovf:vm_snapshot_id:2e24b255-bb84-4284-8785-e2a042045882 > > > > > > > > @ovf:fileRef:16736ce0-a9df-410f-9f29-3a28364cdd41/4ab070c0-fb16- > > > > 45 > > > > 2d > > > > -8 > > > > 521-4ff0b004aef3 > > > > > > > > @ovf:format: > > > > http://www.vmware.com/specifications/vmdk.html#sparse > > > > > > > > @ovf:volume-format:RAW > > > > > > > > @ovf:volume-type:Preallocated > > > > > > > > @ovf:disk-interface:VirtIO > > > > > > > > @ovf:boot:false > > > > > > > > @ovf:disk-alias:hertz_disk5 > > > > > > > > @ovf:disk-description:disk for SYBASE installation, on SAN > > > > shared storage > > > > > > > > @ovf:wipe-after-delete:false > > > > > > > > > > > > > > > > However, I’ve been unable to find any other helpful details. > > > > > > > > I guess the disk is not recoverable at this point? > > > > > > > > Any guru who has a good ovirt DB kwnoledge willing to give me > > > > some advice? > > > > > > > > > > > > > > > > Thanks as usual > > > > > > > > AG > > > > > > > > > > > > > > > > > > > > From: Andrea Ghelardi [mailto: a.ghelardi(a)iontrading.com ] > > > > Sent: Thursday, May 07, 2015 6:08 PM > > > > To: ' users(a)ovirt.org ' > > > > Subject: missing disk after storage domain expansion > > > > > > > > > > > > > > > > > > > > Hi gentlemen, > > > > > > > > > > > > > > > > I recently found an error on 1 of my storages: it was > > > > complaining about no free space but the VM was running and disk > > > > operational. > > > > > > > > Since I needed to perform some maintenance on the VM, I shut it > > > > down and at restart VM couldn’t boot up properly. > > > > > > > > Checked VM via console and a disk was missing. Edited fstab > > > > (luckily this disk was not root but heck! It had a Sybase DB on > > > > it!) and restarted VM this time ok. > > > > > > > > > > > > > > > > Since the disk resides on the dstore with no space, I expanded > > > > the iSCSI LUN, then refreshed multipath on hosts, then resized > > > > PVs and now ovirt is showing the correct size (logs do not > > > > complain anymore on no free space). > > > > > > > > > > > > > > > > BUUUT > > > > > > > > > > > > > > > > Now disk is missing. It is not shown anymore on Disks tab nor > > > > anywhere else. > > > > > > > > Problem is that storage shows 214GB occupancy (size of the > > > > missing > > > > disk) so data is there but cannot find it anymore. > > > > > > > > > > > > > > > > Logs show original disk creation, errors from the lack of space, > > > > refresh of the storage size and then.... no more references on > > > > the disk. > > > > > > > > > > > > > > > > What can I do to find those missing ~210GBs? > > > > > > > > > > > > > > > > Cheers > > > > > > > > Andrea Ghelardi > > > > > > > > > > > > > > > > _______________________________________________ > > > > Users mailing list > > > > Users(a)ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/users > > > > > > > > > >

3 2

Gluster and Export Storage
by ml＠ohnewald.net 20 May '15

20 May '15

Hello List, i have a GlusterFS Data (Master) Storage and a NFS Export Storage. Now my NFS Export Storage is broken. Does this also put my GlusterFS Data Storage into Unknown status? I think my GlusterFS Storage is totally fine, but it wont come up. :-( ° No Split Brain ° Peers are there ° everything is online Its related to this: http://lists.ovirt.org/pipermail/users/2015-May/032889.html It would be cool to get my GlusterFS Up and Running again in order to migrate the vms onto one host and then reboot my empty one. Here is some more gluster info: http://fpaste.org/223283/03230114/ Any ideas? Does the NFS Export Problem really block my GlusterData Domain?! Thanks, Mario

2 1

Half Upgraded ovirt packages - to 3.5.2.1
by Soeren Malchow 20 May '15

20 May '15

--_000_826AB8E6591441BFAAE82DEB951200D3mconnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkkgZ290IGEgcGFydGlhbGx5IHVwZ3JhZGVkIGhvc3RlZCBlbmdpbmUsIHNv bWUgb2YgdGhlIHBhY2thZ2VzIGFyZSB1cGdyYWRlZCB0byAzLjUuMi4xIGFuZCBzb21lIGFyZSBu b3QsIGkgY2FuIG5vdCBldmVuIHVwZ3JhZGUgYWZ0ZXJ3YXJkcw0KDQpQYWNrYWdlIGxpc3Q6DQoN Cm92aXJ0LWVuZ2luZS1zZGstcHl0aG9uLTMuNS4yLjEtMS5lbDYubm9hcmNoDQpvdmlydC1lbmdp bmUtbGliLTMuNS4yLjEtMS5lbDYubm9hcmNoDQpvdmlydC1lbmdpbmUtc2V0dXAtcGx1Z2luLW92 aXJ0LWVuZ2luZS0zLjUuMi4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLXdlYnNvY2tldC1w cm94eS0zLjUuMi4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtaW1hZ2UtdXBsb2FkZXItMy41LjEtMS5l bDYubm9hcmNoDQpvdmlydC1lbmdpbmUtamJvc3MtYXMtNy4xLjEtMS5lbDYueDg2XzY0DQpvdmly dC1ob3N0LWRlcGxveS1qYXZhLTEuMy4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLTMuNS4x LjEtMS5lbDYubm9hcmNoDQpvdmlydC1lbmdpbmUtZHdoLTMuNS4xLTEuZWw2Lm5vYXJjaA0Kb3Zp cnQtaG9zdC1kZXBsb3ktMS4zLjEtMS5lbDYubm9hcmNoDQpvdmlydC1lbmdpbmUtc2V0dXAtYmFz ZS0zLjUuMi4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLXNldHVwLXBsdWdpbi13ZWJzb2Nr ZXQtcHJveHktMy41LjIuMS0xLmVsNi5ub2FyY2gNCm92aXJ0LXJlbGVhc2UzNS0wMDQtMS5ub2Fy Y2gNCm92aXJ0LWVuZ2luZS1jbGktMy41LjAuNS0xLmVsNi5ub2FyY2gNCm92aXJ0LWVuZ2luZS1i YWNrZW5kLTMuNS4xLjEtMS5lbDYubm9hcmNoDQpvdmlydC1lbmdpbmUtdXNlcnBvcnRhbC0zLjUu MS4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLWRic2NyaXB0cy0zLjUuMS4xLTEuZWw2Lm5v YXJjaA0Kb3ZpcnQtZW5naW5lLXRvb2xzLTMuNS4xLjEtMS5lbDYubm9hcmNoDQpvdmlydC1pc28t dXBsb2FkZXItMy41LjItMS5lbDYubm9hcmNoDQpvdmlydC1lbmdpbmUtcmVwb3J0cy1zZXR1cC0z LjUuMi0wLjMuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLWR3aC1zZXR1cC0zLjUuMi0wLjEuZWw2 Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLXNldHVwLTMuNS4yLjEtMS5lbDYubm9hcmNoDQpvdmlydC1l bmdpbmUtZXh0ZW5zaW9ucy1hcGktaW1wbC0zLjUuMi4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5n aW5lLXJlcG9ydHMtMy41LjEtMS5lbDYubm9hcmNoDQpvdmlydC1ndWVzdC10b29scy0zLjUuMC0w LjUubWFzdGVyLm5vYXJjaA0Kb3ZpcnQtZW5naW5lLWV4dGVuc2lvbi1hYWEtbGRhcC0xLjAuMi0x LmVsNi5ub2FyY2gNCm92aXJ0LWVuZ2luZS1zZXR1cC1wbHVnaW4tb3ZpcnQtZW5naW5lLWNvbW1v bi0zLjUuMi4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLXdlYmFkbWluLXBvcnRhbC0zLjUu MS4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLXJlc3RhcGktMy41LjEuMS0xLmVsNi5ub2Fy Y2gNCm92aXJ0LWd1ZXN0LWFnZW50LTEuMC4xMC4yLTEuZWw2Lm5vYXJjaA0KDQpJZiBpIHF1ZXJ5 IHRoZSByZXBvIHdpdGggInJlcG9xdWVyeSAtLXNob3ctZHVwZXMgb3ZpcnQtZW5naW5l4oCdIGkg Z2V0IGEgY29tcGxldGUgbGlzdCBpbmNsdWRpbmcgdGhlIDMuNS4yLjEgcGFja2FnZXMgYnV0IHdp dGggeXVtIGkgZ2V0IG5vdGhpbmcNCg0Kb3ZpcnQtZW5naW5lLTA6My41LjAuMS0xLmVsNi5ub2Fy Y2gNCm92aXJ0LWVuZ2luZS0wOjMuNS4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLTA6My41 LjEuMS0xLmVsNi5ub2FyY2gNCm92aXJ0LWVuZ2luZS0wOjMuNS4yLTEuZWw2Lm5vYXJjaA0Kb3Zp cnQtZW5naW5lLTA6My41LjIuMS0xLmVsNi5ub2FyY2gNCg0KVW5mb3J0dW5hdGVseSBpIGhhdmUg bmV2ZXIgc2VlbiBzdWNoIGEgYmVoYXZpb3VyIGJlZm9yZSBhbmQgaSBhbSBsaXN0Lg0KDQpEb2Vz IGFueWJvZHkgaGF2ZSBhbiBpZGVhID8NCg0KUmVnYXJkcw0KU29lcmVuDQoNCg== --_000_826AB8E6591441BFAAE82DEB951200D3mconnet_ Content-Type: text/html; charset="utf-8" Content-ID: <AFA5AB1434BE0E4F8A5E360150369FCE(a)liquidcampaign.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkRlYXIgYWxsLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBnb3QgYSBwYXJ0 aWFsbHkgdXBncmFkZWQgaG9zdGVkIGVuZ2luZSwgc29tZSBvZiB0aGUgcGFja2FnZXMgYXJlIHVw Z3JhZGVkIHRvIDMuNS4yLjEgYW5kIHNvbWUgYXJlIG5vdCwgaSBjYW4gbm90IGV2ZW4gdXBncmFk ZSBhZnRlcndhcmRzPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5QYWNrYWdlIGxpc3Q6 PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+b3ZpcnQtZW5naW5lLXNkay1w eXRob24tMy41LjIuMS0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQtZW5naW5lLWxpYi0z LjUuMi4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtc2V0dXAtcGx1Z2lu LW92aXJ0LWVuZ2luZS0zLjUuMi4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdp bmUtd2Vic29ja2V0LXByb3h5LTMuNS4yLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0 LWltYWdlLXVwbG9hZGVyLTMuNS4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdp bmUtamJvc3MtYXMtNy4xLjEtMS5lbDYueDg2XzY0PC9kaXY+DQo8ZGl2Pm92aXJ0LWhvc3QtZGVw bG95LWphdmEtMS4zLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWVuZ2luZS0zLjUu MS4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtZHdoLTMuNS4xLTEuZWw2 Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1ob3N0LWRlcGxveS0xLjMuMS0xLmVsNi5ub2FyY2g8 L2Rpdj4NCjxkaXY+b3ZpcnQtZW5naW5lLXNldHVwLWJhc2UtMy41LjIuMS0xLmVsNi5ub2FyY2g8 L2Rpdj4NCjxkaXY+b3ZpcnQtZW5naW5lLXNldHVwLXBsdWdpbi13ZWJzb2NrZXQtcHJveHktMy41 LjIuMS0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQtcmVsZWFzZTM1LTAwNC0xLm5vYXJj aDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtY2xpLTMuNS4wLjUtMS5lbDYubm9hcmNoPC9kaXY+ DQo8ZGl2Pm92aXJ0LWVuZ2luZS1iYWNrZW5kLTMuNS4xLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8 ZGl2Pm92aXJ0LWVuZ2luZS11c2VycG9ydGFsLTMuNS4xLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8 ZGl2Pm92aXJ0LWVuZ2luZS1kYnNjcmlwdHMtMy41LjEuMS0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxk aXY+b3ZpcnQtZW5naW5lLXRvb2xzLTMuNS4xLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92 aXJ0LWlzby11cGxvYWRlci0zLjUuMi0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQtZW5n aW5lLXJlcG9ydHMtc2V0dXAtMy41LjItMC4zLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQt ZW5naW5lLWR3aC1zZXR1cC0zLjUuMi0wLjEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1l bmdpbmUtc2V0dXAtMy41LjIuMS0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQtZW5naW5l LWV4dGVuc2lvbnMtYXBpLWltcGwtMy41LjIuMS0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3Zp cnQtZW5naW5lLXJlcG9ydHMtMy41LjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWd1 ZXN0LXRvb2xzLTMuNS4wLTAuNS5tYXN0ZXIubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWVuZ2lu ZS1leHRlbnNpb24tYWFhLWxkYXAtMS4wLjItMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0 LWVuZ2luZS1zZXR1cC1wbHVnaW4tb3ZpcnQtZW5naW5lLWNvbW1vbi0zLjUuMi4xLTEuZWw2Lm5v YXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtd2ViYWRtaW4tcG9ydGFsLTMuNS4xLjEtMS5l bDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWVuZ2luZS1yZXN0YXBpLTMuNS4xLjEtMS5lbDYu bm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWd1ZXN0LWFnZW50LTEuMC4xMC4yLTEuZWw2Lm5vYXJj aDwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JZiBpIHF1ZXJ5IHRoZSBy ZXBvIHdpdGggJnF1b3Q7cmVwb3F1ZXJ5IC0tc2hvdy1kdXBlcyBvdmlydC1lbmdpbmXigJ0gaSBn ZXQgYSBjb21wbGV0ZSBsaXN0IGluY2x1ZGluZyB0aGUgMy41LjIuMSBwYWNrYWdlcyBidXQgd2l0 aCB5dW0gaSBnZXQgbm90aGluZzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pm92aXJ0LWVuZ2luZS0wOjMuNS4wLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWVu Z2luZS0wOjMuNS4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtMDozLjUu MS4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtMDozLjUuMi0xLmVsNi5u b2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQtZW5naW5lLTA6My41LjIuMS0xLmVsNi5ub2FyY2g8L2Rp dj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VW5mb3J0dW5hdGVseSBpIGhhdmUg bmV2ZXIgc2VlbiBzdWNoIGEgYmVoYXZpb3VyIGJlZm9yZSBhbmQgaSBhbSBsaXN0LiZuYnNwOzwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RG9lcyBhbnlib2R5IGhhdmUgYW4gaWRlYSA/ PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzPC9kaXY+DQo8ZGl2PlNvZXJl biZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VU TE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_826AB8E6591441BFAAE82DEB951200D3mconnet_--

3 3

Re: [ovirt-users] Backup through export and clone
by Soeren Malchow 20 May '15

20 May '15

--_000_A13FAAA7E886416B80CF7ECF7FB53B4Amconnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIHNtYWxsIGFkZGl0aW9uOiBpZiBzb21lb25lIGhhcyBhbiBpZGVhIGhvdyB0byBrZWVwIHRo ZSBsb2FkIGRvd24gZXZlbiB3aGVuIGNsb25lIHdpdGhpbiB0aGUgZ2x1c3RlciBzdG9yYWdlIGRv bWFpbiwgYW55IHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lIGFuZCB3ZSB3b3VsZCB0ZXN0IHRoYXQN Cg0KRnJvbTogPHVzZXJzLWJvdW5jZXNAb3ZpcnQub3JnPG1haWx0bzp1c2Vycy1ib3VuY2VzQG92 aXJ0Lm9yZz4+IG9uIGJlaGFsZiBvZiBTb2VyZW4gTWFsY2hvdw0KRGF0ZTogV2VkbmVzZGF5IDIw IE1heSAyMDE1IDAwOjE5DQpUbzogInVzZXJzQG92aXJ0Lm9yZzxtYWlsdG86dXNlcnNAb3ZpcnQu b3JnPiINClN1YmplY3Q6IFtvdmlydC11c2Vyc10gQmFja3VwIHRocm91Z2ggZXhwb3J0IGFuZCBj bG9uZQ0KDQpEZWFyIGFsbCwNCg0KSSBhbSBubyBweXRob24gZGV2ZWxvcGVyIChiYXNpY2FsbHkg bm8gZGV2ZWxvcGVyIGF0IGFsbCkgYnV0IGkgc3RydWdnbGVkIHdpdGggdGhlIGJhY2t1cCBmb3Ig YSB3aGlsZSBidXQgZmluYWxseSBpIGhhdmUgYSBzY3JpcHQgYWxtb3N0IE9LIGZvciB0aGUgYmFj a3VwLg0KDQpEdWUgdG8gdGhlIGZhY3QgdGhhdCB0aGUg4oCcc25hcHNob3QgLT4gZXhwb3J04oCd IGZlYXR1cmUgaXMgY29taW5nIGFzIGl0IHNlZW1zIGluIDMuNiB3ZSBzdGlsbCBuZWVkIHRvIGNs b25lIGFuZCB0aGVuIGV4cG9ydC4NCg0KVGhpcyBzY3JpcHQgaXMgdGhyZWFkZWQgdG8gZG8gYmFj a3VwcyBvZiAzIFZtcyBjb25jdXJyZW50bHksIGhvd2V2ZXIsIGluIG91ciBzZXR1cCAoIGNvbXB1 dGUgc2VydmVyIHdpdGggMyBzZXBhcmF0ZSBnbHVzdGVyIG1hY2hpbmVzKSBwYXJhbGxlbCBiYWNr dXBzIG9mIDMgVk1TIGNyZWF0ZSB2ZXJ5IGhlYXZ5IGxvYWQgb24gdGhlIGdsdXN0ZXIgc3RvcmFn ZSBzZXJ2ZXJzLCBhbmQgaSB3b3VsZCBsaWtlIHRvIGRvIHRoZSDigJxjbG9uZSBzbmFwc2hvdOKA nSB0byBhIHNlcGFyYXRlIGludGVybWVkaWF0ZSBzdG9yYWdlIGFscmVhZHksIGNhbiBhbnlib2R5 IGhlbHAgbWUgd2l0aCB0aGF0ID8gKHNvbWV3aGVyZSBhcm91bmQgbGluZSA3MCkNClRoZSBjbG9u aW5nIGNhbiBob3BlZnVsbHkgZ28gYXdheSBpbiBTZXB0ZW1iZXIgd2l0aCAzLjYgYnV0IHVudGls IHRoZW4gd2Ugc3RpbGwgbmVlZCB0aGF0Lg0KDQpBbnkgb3RoZXIgaW1wcm92ZW1lbnRzIGFyZSBt b3JlIHRoYW4gd2VsY29tZSDigJMgcGxlYXNlIGtlZXAgaW4gbWluZCBpIGFtIG5vdCBhIGRldmVs b3BlciBhbmQgSSBvbmx5IHRyaWVkIG15IHZlcnkgYmVzdCB0byB3cml0ZSBhIGRlY2VudCBzY3Jp cHQuDQoNCkFsc286IGRvIHdlIGhhdmUgYSBwbGFjZSAoZ2l0IHJlcG8gb3Igc28pIHdoZXJlIHdl IGNhbiBwdXQgdGhpcyBzY3JpcHQgZm9yIGV2ZXJ5Ym9keSA/DQoNCkkgYW0gcHJldHR5IHN1cmUg dGhlcmUgaXMgbW9yZSB0aGFuIG9uZSBwZXJzb24gb3V0IHRoZXJlIGxvb2tpbmcgZm9yIHNvbWV0 aGluZyBsaWtlIHRoYXQgKGF0IGxlYXN0IGkgaG9wZSA6LSkgKQ0KDQpSZWdhcmRzDQpTb2VyZW4N Cg0K --_000_A13FAAA7E886416B80CF7ECF7FB53B4Amconnet_ Content-Type: text/html; charset="utf-8" Content-ID: <FD072BC5D8B01A458711015AE4BE1137(a)liquidcampaign.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+T25l IHNtYWxsIGFkZGl0aW9uOiBpZiBzb21lb25lIGhhcyBhbiBpZGVhIGhvdyB0byBrZWVwIHRoZSBs b2FkIGRvd24gZXZlbiB3aGVuIGNsb25lIHdpdGhpbiB0aGUgZ2x1c3RlciBzdG9yYWdlIGRvbWFp biwgYW55IHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lIGFuZCB3ZSB3b3VsZCB0ZXN0IHRoYXQmbmJz cDs8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZ X1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEy cHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBu b25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJ TkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0 IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+Jmx0OzxhIGhyZWY9Im1h aWx0bzp1c2Vycy1ib3VuY2VzQG92aXJ0Lm9yZyI+dXNlcnMtYm91bmNlc0BvdmlydC5vcmc8L2E+ Jmd0OyBvbiBiZWhhbGYgb2YgU29lcmVuIE1hbGNob3c8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPldlZG5lc2RheSAyMCBNYXkgMjAxNSAwMDoxOTxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9 Im1haWx0bzp1c2Vyc0BvdmlydC5vcmciPnVzZXJzQG92aXJ0Lm9yZzwvYT4mcXVvdDs8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPltvdmlydC11c2Vy c10gQmFja3VwIHRocm91Z2ggZXhwb3J0IGFuZCBjbG9uZTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5EZWFyIGFsbCw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PkkgYW0gbm8gcHl0aG9uIGRldmVsb3BlciAoYmFzaWNhbGx5IG5vIGRldmVsb3Bl ciBhdCBhbGwpIGJ1dCBpIHN0cnVnZ2xlZCB3aXRoIHRoZSBiYWNrdXAgZm9yIGEgd2hpbGUgYnV0 IGZpbmFsbHkgaSBoYXZlIGEgc2NyaXB0IGFsbW9zdCBPSyBmb3IgdGhlIGJhY2t1cC48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkR1ZSB0byB0aGUgZmFjdCB0aGF0IHRoZSDigJxzbmFw c2hvdCAtJmd0OyBleHBvcnTigJ0gZmVhdHVyZSBpcyBjb21pbmcgYXMgaXQgc2VlbXMgaW4gMy42 IHdlIHN0aWxsIG5lZWQgdG8gY2xvbmUgYW5kIHRoZW4gZXhwb3J0LjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+VGhpcyBzY3JpcHQgaXMgdGhyZWFkZWQgdG8gZG8gYmFja3VwcyBvZiAz IFZtcyBjb25jdXJyZW50bHksIGhvd2V2ZXIsIGluIG91ciBzZXR1cCAoIGNvbXB1dGUgc2VydmVy IHdpdGggMyBzZXBhcmF0ZSBnbHVzdGVyIG1hY2hpbmVzKSBwYXJhbGxlbCBiYWNrdXBzIG9mIDMg Vk1TIGNyZWF0ZSB2ZXJ5IGhlYXZ5IGxvYWQgb24gdGhlIGdsdXN0ZXIgc3RvcmFnZSBzZXJ2ZXJz LCBhbmQgaSB3b3VsZCBsaWtlIHRvIGRvIHRoZSDigJxjbG9uZSBzbmFwc2hvdOKAnQ0KIHRvIGEg c2VwYXJhdGUgaW50ZXJtZWRpYXRlIHN0b3JhZ2UgYWxyZWFkeSwgY2FuIGFueWJvZHkgaGVscCBt ZSB3aXRoIHRoYXQgPyAoc29tZXdoZXJlIGFyb3VuZCBsaW5lIDcwKTwvZGl2Pg0KPGRpdj5UaGUg Y2xvbmluZyBjYW4gaG9wZWZ1bGx5IGdvIGF3YXkgaW4gU2VwdGVtYmVyIHdpdGggMy42IGJ1dCB1 bnRpbCB0aGVuIHdlIHN0aWxsIG5lZWQgdGhhdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2PkFueSBvdGhlciBpbXByb3ZlbWVudHMgYXJlIG1vcmUgdGhhbiB3ZWxjb21lIOKAkyBwbGVh c2Uga2VlcCBpbiBtaW5kIGkgYW0gbm90IGEgZGV2ZWxvcGVyIGFuZCBJIG9ubHkgdHJpZWQgbXkg dmVyeSBiZXN0IHRvIHdyaXRlIGEgZGVjZW50IHNjcmlwdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PkFsc286IGRvIHdlIGhhdmUgYSBwbGFjZSAoZ2l0IHJlcG8gb3Igc28pIHdoZXJl IHdlIGNhbiBwdXQgdGhpcyBzY3JpcHQgZm9yIGV2ZXJ5Ym9keSA/PC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5JIGFtIHByZXR0eSBzdXJlIHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUgcGVy c29uIG91dCB0aGVyZSBsb29raW5nIGZvciBzb21ldGhpbmcgbGlrZSB0aGF0IChhdCBsZWFzdCBp IGhvcGUgOi0pICk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHM8L2Rpdj4N CjxkaXY+U29lcmVuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9IiI+ PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_A13FAAA7E886416B80CF7ECF7FB53B4Amconnet_--

1 0

Backup through export and clone
by Soeren Malchow 20 May '15

20 May '15

--_004_2BD21C61C0C14E8DACCCC9752B029867mconnet_ Content-Type: multipart/alternative; boundary="_000_2BD21C61C0C14E8DACCCC9752B029867mconnet_" --_000_2BD21C61C0C14E8DACCCC9752B029867mconnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCkkgYW0gbm8gcHl0aG9uIGRldmVsb3BlciAoYmFzaWNhbGx5IG5vIGRldmVs b3BlciBhdCBhbGwpIGJ1dCBpIHN0cnVnZ2xlZCB3aXRoIHRoZSBiYWNrdXAgZm9yIGEgd2hpbGUg YnV0IGZpbmFsbHkgaSBoYXZlIGEgc2NyaXB0IGFsbW9zdCBPSyBmb3IgdGhlIGJhY2t1cC4NCg0K RHVlIHRvIHRoZSBmYWN0IHRoYXQgdGhlIOKAnHNuYXBzaG90IC0+IGV4cG9ydOKAnSBmZWF0dXJl IGlzIGNvbWluZyBhcyBpdCBzZWVtcyBpbiAzLjYgd2Ugc3RpbGwgbmVlZCB0byBjbG9uZSBhbmQg dGhlbiBleHBvcnQuDQoNClRoaXMgc2NyaXB0IGlzIHRocmVhZGVkIHRvIGRvIGJhY2t1cHMgb2Yg MyBWbXMgY29uY3VycmVudGx5LCBob3dldmVyLCBpbiBvdXIgc2V0dXAgKCBjb21wdXRlIHNlcnZl ciB3aXRoIDMgc2VwYXJhdGUgZ2x1c3RlciBtYWNoaW5lcykgcGFyYWxsZWwgYmFja3VwcyBvZiAz IFZNUyBjcmVhdGUgdmVyeSBoZWF2eSBsb2FkIG9uIHRoZSBnbHVzdGVyIHN0b3JhZ2Ugc2VydmVy cywgYW5kIGkgd291bGQgbGlrZSB0byBkbyB0aGUg4oCcY2xvbmUgc25hcHNob3TigJ0gdG8gYSBz ZXBhcmF0ZSBpbnRlcm1lZGlhdGUgc3RvcmFnZSBhbHJlYWR5LCBjYW4gYW55Ym9keSBoZWxwIG1l IHdpdGggdGhhdCA/IChzb21ld2hlcmUgYXJvdW5kIGxpbmUgNzApDQpUaGUgY2xvbmluZyBjYW4g aG9wZWZ1bGx5IGdvIGF3YXkgaW4gU2VwdGVtYmVyIHdpdGggMy42IGJ1dCB1bnRpbCB0aGVuIHdl IHN0aWxsIG5lZWQgdGhhdC4NCg0KQW55IG90aGVyIGltcHJvdmVtZW50cyBhcmUgbW9yZSB0aGFu IHdlbGNvbWUg4oCTIHBsZWFzZSBrZWVwIGluIG1pbmQgaSBhbSBub3QgYSBkZXZlbG9wZXIgYW5k IEkgb25seSB0cmllZCBteSB2ZXJ5IGJlc3QgdG8gd3JpdGUgYSBkZWNlbnQgc2NyaXB0Lg0KDQpB bHNvOiBkbyB3ZSBoYXZlIGEgcGxhY2UgKGdpdCByZXBvIG9yIHNvKSB3aGVyZSB3ZSBjYW4gcHV0 IHRoaXMgc2NyaXB0IGZvciBldmVyeWJvZHkgPw0KDQpJIGFtIHByZXR0eSBzdXJlIHRoZXJlIGlz IG1vcmUgdGhhbiBvbmUgcGVyc29uIG91dCB0aGVyZSBsb29raW5nIGZvciBzb21ldGhpbmcgbGlr ZSB0aGF0IChhdCBsZWFzdCBpIGhvcGUgOi0pICkNCg0KUmVnYXJkcw0KU29lcmVuDQoNCg== --_000_2BD21C61C0C14E8DACCCC9752B029867mconnet_ Content-Type: text/html; charset="utf-8" Content-ID: <B23104407061FD47B920E44171210E96(a)liquidcampaign.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5EZWFyIGFsbCw8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgYW0gbm8gcHl0aG9uIGRldmVsb3BlciAo YmFzaWNhbGx5IG5vIGRldmVsb3BlciBhdCBhbGwpIGJ1dCBpIHN0cnVnZ2xlZCB3aXRoIHRoZSBi YWNrdXAgZm9yIGEgd2hpbGUgYnV0IGZpbmFsbHkgaSBoYXZlIGEgc2NyaXB0IGFsbW9zdCBPSyBm b3IgdGhlIGJhY2t1cC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkR1ZSB0byB0aGUg ZmFjdCB0aGF0IHRoZSDigJxzbmFwc2hvdCAtJmd0OyBleHBvcnTigJ0gZmVhdHVyZSBpcyBjb21p bmcgYXMgaXQgc2VlbXMgaW4gMy42IHdlIHN0aWxsIG5lZWQgdG8gY2xvbmUgYW5kIHRoZW4gZXhw b3J0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBzY3JpcHQgaXMgdGhyZWFk ZWQgdG8gZG8gYmFja3VwcyBvZiAzIFZtcyBjb25jdXJyZW50bHksIGhvd2V2ZXIsIGluIG91ciBz ZXR1cCAoIGNvbXB1dGUgc2VydmVyIHdpdGggMyBzZXBhcmF0ZSBnbHVzdGVyIG1hY2hpbmVzKSBw YXJhbGxlbCBiYWNrdXBzIG9mIDMgVk1TIGNyZWF0ZSB2ZXJ5IGhlYXZ5IGxvYWQgb24gdGhlIGds dXN0ZXIgc3RvcmFnZSBzZXJ2ZXJzLCBhbmQgaSB3b3VsZCBsaWtlIHRvIGRvIHRoZSDigJxjbG9u ZSBzbmFwc2hvdOKAnQ0KIHRvIGEgc2VwYXJhdGUgaW50ZXJtZWRpYXRlIHN0b3JhZ2UgYWxyZWFk eSwgY2FuIGFueWJvZHkgaGVscCBtZSB3aXRoIHRoYXQgPyAoc29tZXdoZXJlIGFyb3VuZCBsaW5l IDcwKTwvZGl2Pg0KPGRpdj5UaGUgY2xvbmluZyBjYW4gaG9wZWZ1bGx5IGdvIGF3YXkgaW4gU2Vw dGVtYmVyIHdpdGggMy42IGJ1dCB1bnRpbCB0aGVuIHdlIHN0aWxsIG5lZWQgdGhhdC48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFueSBvdGhlciBpbXByb3ZlbWVudHMgYXJlIG1vcmUg dGhhbiB3ZWxjb21lIOKAkyBwbGVhc2Uga2VlcCBpbiBtaW5kIGkgYW0gbm90IGEgZGV2ZWxvcGVy IGFuZCBJIG9ubHkgdHJpZWQgbXkgdmVyeSBiZXN0IHRvIHdyaXRlIGEgZGVjZW50IHNjcmlwdC48 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFsc286IGRvIHdlIGhhdmUgYSBwbGFjZSAo Z2l0IHJlcG8gb3Igc28pIHdoZXJlIHdlIGNhbiBwdXQgdGhpcyBzY3JpcHQgZm9yIGV2ZXJ5Ym9k eSA/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGFtIHByZXR0eSBzdXJlIHRoZXJl IGlzIG1vcmUgdGhhbiBvbmUgcGVyc29uIG91dCB0aGVyZSBsb29raW5nIGZvciBzb21ldGhpbmcg bGlrZSB0aGF0IChhdCBsZWFzdCBpIGhvcGUgOi0pICk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PlJlZ2FyZHM8L2Rpdj4NCjxkaXY+U29lcmVuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2BD21C61C0C14E8DACCCC9752B029867mconnet_-- --_004_2BD21C61C0C14E8DACCCC9752B029867mconnet_ Content-Type: text/x-python-script; name="backup-queue.py" Content-Description: backup-queue.py Content-Disposition: attachment; filename="backup-queue.py"; size=5249; creation-date="Tue, 19 May 2015 22:19:10 GMT"; modification-date="Tue, 19 May 2015 22:19:10 GMT" Content-ID: <786F63264519A449B193A37F1DC80C77(a)liquidcampaign.com> Content-Transfer-Encoding: base64 IyEvdXNyL2Jpbi9weXRob24KCmltcG9ydCBRdWV1ZQppbXBvcnQgdGhyZWFkaW5nCmltcG9ydCB0 aW1lCmZyb20gb3ZpcnRzZGsuYXBpIGltcG9ydCBBUEkKZnJvbSBvdmlydHNkay54bWwgaW1wb3J0 IHBhcmFtcwppbXBvcnQgc3lzCmltcG9ydCBkYXRldGltZQppbXBvcnQgc210cGxpYgpmcm9tIGVt YWlsLm1pbWUudGV4dCBpbXBvcnQgTUlNRVRleHQKCgpnbG9iYWwgU05BUFNIT1RfTkFNRQoKVkVS U0lPTiAgICAgICAgICAgICA9IHBhcmFtcy5WZXJzaW9uKG1ham9yPSczJywgbWlub3I9JzAnKQpF TkdJTkVfU0VSVkVSICAgICAgID0gJycKRU5HSU5FX1VTRVIgICAgICAgICA9ICdhZG1pbkBpbnRl cm5hbCcKRU5HSU5FX1BBU1NXT1JEICAgICA9ICcnCkVOR0lORV9DRVJUICAgICAgICAgPSAnJwpO T1cgICAgICAgICAgICAgICAgID0gZGF0ZXRpbWUuZGF0ZXRpbWUubm93KCkKU05BUFNIT1RfTkFN RSAgICAgICA9ICdCQUNLVVBfJyArIE5PVy5zdHJmdGltZSgiJVktJW0tJWQtJUglTSIpCkRBWV9P Rl9XRUVLICAgICAgICAgPSBOT1cuc3RyZnRpbWUoIiV3IikKQkFDS1VQICAgICAgICAgICAgICA9 ICJGVUxMIgoKZXhpdEZsYWcgPSAwCgpjbGFzcyBteVRocmVhZCAodGhyZWFkaW5nLlRocmVhZCk6 CiAgICBkZWYgX19pbml0X18oc2VsZiwgdGhyZWFkSUQsIG5hbWUsIHEpOgogICAgICAgIHRocmVh ZGluZy5UaHJlYWQuX19pbml0X18oc2VsZikKICAgICAgICBzZWxmLnRocmVhZElEID0gdGhyZWFk SUQKICAgICAgICBzZWxmLm5hbWUgPSBuYW1lCiAgICAgICAgc2VsZi5xID0gcQogICAgICAgIHNl bGYuYXBpID0gYXBpCiAgICAgICAgZ2xvYmFsIG1lc3NhZ2UKICAgIGRlZiBydW4oc2VsZik6CiAg ICAgICAgcHJpbnQgIlN0YXJ0aW5nICIgKyBzZWxmLm5hbWUKICAgICAgICBwcm9jZXNzX2RhdGEo c2VsZi5uYW1lLCBzZWxmLnEpCiAgICAgICAgcHJpbnQgIkV4aXRpbmcgIiArIHNlbGYubmFtZQoK ZGVmIHByb2Nlc3NfZGF0YSh0aHJlYWROYW1lLCBxKToKICAgIHdoaWxlIG5vdCBleGl0RmxhZzoK ICAgICAgICBxdWV1ZUxvY2suYWNxdWlyZSgpCiAgICAgICAgaWYgbm90IHdvcmtRdWV1ZS5lbXB0 eSgpOgogICAgICAgICAgICBkYXRhID0gcS5nZXQoKQogICAgICAgICAgICBxdWV1ZUxvY2sucmVs ZWFzZSgpCiAgICAgICAgICAgIHByaW50ICIlcyBwcm9jZXNzaW5nICVzIiAlICh0aHJlYWROYW1l LCBkYXRhLm5hbWUpCiAgICAgICAgICAgIHZtID0gYXBpLnZtcy5nZXQobmFtZT1kYXRhLm5hbWUp CiAgICAgICAgICAgIHZtbmFtZSA9IGRhdGEubmFtZSArIl8iCiAgICAgICAgICAgIG5ld3ZtbmFt ZSA9IHZtbmFtZSArIFNOQVBTSE9UX05BTUUKICAgICAgICAgICAgY2x1c3RlciA9IGFwaS5jbHVz dGVycy5nZXQoaWQ9dm0uY2x1c3Rlci5pZCkKICAgICAgICAgICAgZGMgPSBhcGkuZGF0YWNlbnRl cnMuZ2V0KGlkPWNsdXN0ZXIuZGF0YV9jZW50ZXIuaWQpCiAgICAgICAgICAgIGV4cG9ydCA9IE5v bmUKICAgICAgICAgICAgZm9yIHNkIGluIGRjLnN0b3JhZ2Vkb21haW5zLmxpc3QoKToKICAgICAg ICAgICAgICAgIGlmIHNkLnR5cGVfID09ICJleHBvcnQiOgogICAgICAgICAgICAgICAgICAgIGV4 cG9ydCA9IHNkCiAgICAgICAgICAgIGlmIG5vdCBleHBvcnQ6CiAgICAgICAgICAgICAgICBwcmlu dCgiRXhwb3J0IGRvbWFpbiByZXF1aXJlZCwgYW5kIG5vbmUgZm91bmQsIGV4aXR0aW5nLi4uXG4i KQogICAgICAgICAgICAgICAgc3lzLmV4aXQoMSkKCiAgICAgICAgICAgIGlmIHZtLm5hbWUgIT0g Ikhvc3RlZEVuZ2luZSI6CiAgICAgICAgICAgICAgICB2bS5zbmFwc2hvdHMuYWRkKHBhcmFtcy5T bmFwc2hvdChkZXNjcmlwdGlvbj1TTkFQU0hPVF9OQU1FLCB2bT12bSApKQogICAgICAgICAgICAg ICAgc25hcCA9IHZtLnNuYXBzaG90cy5saXN0KGRlc2NyaXB0aW9uPVNOQVBTSE9UX05BTUUpWzBd CiAgICAgICAgICAgICAgICB3aGlsZSB2bS5zbmFwc2hvdHMuZ2V0KGlkPXNuYXAuaWQpLnNuYXBz aG90X3N0YXR1cyA9PSAibG9ja2VkIjoKICAgICAgICAgICAgICAgICAgICBwcmludCgiJXMgV2Fp dGluZyBmb3Igc25hcHNob3Qgb2YgJXMgdG8gZmluaXNoIikgJSAodGhyZWFkTmFtZSwgdm0ubmFt ZSkKICAgICAgICAgICAgICAgICAgICB0aW1lLnNsZWVwKDEwKQogICAgICAgICAgICAgICAgcHJp bnQoIiVzIFNuYXBzaG90dGluZyAlcyBpcyBkb25lIikgJSAodGhyZWFkTmFtZSx2bS5uYW1lKQog ICAgICAgICAgICAgICAgdHJ5OgogICAgICAgICAgICAgICAgICAgIHNuYXBzaG90cyA9IHBhcmFt cy5TbmFwc2hvdHMoc25hcHNob3Q9W3BhcmFtcy5TbmFwc2hvdChpZD1zbmFwLmlkKV0pCiAgICAg ICAgICAgICAgICAgICAgYXBpLnZtcy5hZGQocGFyYW1zLlZNKG5hbWU9bmV3dm1uYW1lLCBzbmFw c2hvdHM9c25hcHNob3RzLCBjbHVzdGVyPWNsdXN0ZXIsIHRlbXBsYXRlPWFwaS50ZW1wbGF0ZXMu Z2V0KG5hbWU9IkJsYW5rIikpKQogICAgICAgICAgICAgICAgICAgIHdoaWxlIGFwaS52bXMuZ2V0 KG5hbWU9bmV3dm1uYW1lKS5zdGF0dXMuc3RhdGUgPT0gImltYWdlX2xvY2tlZCI6CiAgICAgICAg ICAgICAgICAgICAgICAgIHByaW50KCIlcyBXYWl0aW5nIGZvciBjbG9uZSBvZiAlcyB0byBmaW5p c2giKSAlICh0aHJlYWROYW1lLCB2bS5uYW1lKQogICAgICAgICAgICAgICAgICAgICAgICB0aW1l LnNsZWVwKDYwKQogICAgICAgICAgICAgICAgICAgIHByaW50KCIlcyBDbG9uaW5nIG9mICVzICBk b25lIikgJSAodGhyZWFkTmFtZSwgdm0ubmFtZSkKICAgICAgICAgICAgICAgICAgICBhcGkudm1z LmdldChuYW1lPW5ld3ZtbmFtZSkuZXhwb3J0KHBhcmFtcy5BY3Rpb24oc3RvcmFnZV9kb21haW49 ZXhwb3J0KSkKICAgICAgICAgICAgICAgICAgICB3aGlsZSBhcGkudm1zLmdldChuYW1lPW5ld3Zt bmFtZSkuc3RhdHVzLnN0YXRlID09ICJpbWFnZV9sb2NrZWQiOgogICAgICAgICAgICAgICAgICAg ICAgICBwcmludCgiJXMgV2FpdGluZyBmb3IgZXhwb3J0IG9mICVzIGZpbmlzaCIpICUgKHRocmVh ZE5hbWUsIHZtLm5hbWUpCiAgICAgICAgICAgICAgICAgICAgICAgIHRpbWUuc2xlZXAoNjApCiAg ICAgICAgICAgICAgICAgICAgcHJpbnQoIiVzIEV4cG9ydGluZyAlcyBkb25lIikgJSAodGhyZWFk TmFtZSwgdm0ubmFtZSkKICAgICAgICAgICAgICAgICAgICBhcGkudm1zLmdldChuYW1lPW5ld3Zt bmFtZSkuZGVsZXRlKCkKICAgICAgICAgICAgICAgIGV4Y2VwdCBFeGNlcHRpb24gYXMgZToKICAg ICAgICAgICAgICAgICAgICBwcmludCAoIlNvbWV0aGluZyB3ZW50IHdyb25nIHdpdGggdGhlIGNv bGluZyBvciBleHBvcnRpbmdcbiVzIikgJSBzdHIoZSkKICAgICAgICAgICAgICAgIHNuYXBzaG90 bGlzdCA9IHZtLnNuYXBzaG90cy5saXN0KCkKICAgICAgICAgICAgICAgIGZvciBzbmFwc2hvdCBp biBzbmFwc2hvdGxpc3Q6CiAgICAgICAgICAgICAgICAgICAgaWYgc25hcHNob3QuZGVzY3JpcHRp b24gIT0gIkFjdGl2ZSBWTSI6CiAgICAgICAgICAgICAgICAgICAgICAgIHNuYXBzaG90LmRlbGV0 ZSgpCiAgICAgICAgICAgICAgICAgICAgICAgIHRpbWUuc2xlZXAoMykKICAgICAgICAgICAgICAg ICAgICAgICAgdHJ5OgogICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hpbGUgYXBpLnZtcy5n ZXQobmFtZT12bS5uYW1lKS5zbmFwc2hvdHMuZ2V0KGlkPXNuYXBzaG90LmlkKS5zbmFwc2hvdF9z dGF0dXMgPT0gImxvY2tlZCI6CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJpbnQo IiVzIFdhaXRpbmcgZm9yIHNuYXBzaG90ICVzIG9uICVzIGRlbGV0aW9uIHRvIGZpbmlzaCIpICUg KHRocmVhZE5hbWUsIHNuYXBzaG90Lm5hbWUsIHZtLm5hbWUpCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdGltZS5zbGVlcCgxMCkKICAgICAgICAgICAgICAgICAgICAgICAgZXhjZXB0 IEV4Y2VwdGlvbiBhcyBlOgogICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJpbnQgKCIlcyBT bmFwc2hvdCBzdGF0dXMgcmVxdWVzdCBtaWdodCBoYXZlIGZhaWxlZCwgdGhpcyB1c3VhbGx5IG1l YW5zIHRoYXQgdGhlIHNucGFzaG90IHdhcyBkZWxldGVkIHByb3Blcmx5IikgJSB0aHJlYWROYW1l CiAgICAgICAgICAgICAgICAgICAgICAgIHByaW50KCIlcyBEZWxldGluZyBzbmFwc2hvdCAlcyBv biAlcyBkb25lIikgJSAodGhyZWFkTmFtZSwgc25hcHNob3QubmFtZSwgdm0ubmFtZSkKCiAgICAg ICAgZWxzZToKICAgICAgICAgICAgcXVldWVMb2NrLnJlbGVhc2UoKQogICAgICAgIHRpbWUuc2xl ZXAoMSkKCnRocmVhZExpc3QgPSBbIkJhY2t1cC1UaHJlYWQtMSIsICJCYWNrdXAtVGhyZWFkLTIi LCAiQmFja3VwLVRocmVhZC0zIl0KCmRlZiBDb25uZWN0KCk6CiAgICBnbG9iYWwgYXBpCiAgICBh cGkgPSBBUEkodXJsPUVOR0lORV9TRVJWRVIsIHVzZXJuYW1lPUVOR0lORV9VU0VSLCBwYXNzd29y ZD1FTkdJTkVfUEFTU1dPUkQsIGNhX2ZpbGU9RU5HSU5FX0NFUlQpCgpkZWYgRGlzY29ubmVjdChl eGl0Y29kZSk6CiAgICBhcGkuZGlzY29ubmVjdCgpCiAgICBzeXMuZXhpdChleGl0Y29kZSkKCnRy eToKICAgIENvbm5lY3QoKQogICAgdm1zID0gYXBpLnZtcy5saXN0KCkKCmV4Y2VwdCBFeGNlcHRp b24gYXMgZToKICAgIHByaW50ICdGYWlsZWQ6XG4lcycgJSBzdHIoZSkKCm5hbWVMaXN0ID0gdm1z IApxdWV1ZUxvY2sgPSB0aHJlYWRpbmcuTG9jaygpCndvcmtRdWV1ZSA9IFF1ZXVlLlF1ZXVlKDAp CnRocmVhZHMgPSBbXQp0aHJlYWRJRCA9IDEKCiMgQ3JlYXRlIG5ldyB0aHJlYWRzCmZvciB0TmFt ZSBpbiB0aHJlYWRMaXN0OgogICAgdGhyZWFkID0gbXlUaHJlYWQodGhyZWFkSUQsIHROYW1lLCB3 b3JrUXVldWUpCiAgICB0aHJlYWQuc3RhcnQoKQogICAgdGhyZWFkcy5hcHBlbmQodGhyZWFkKQog ICAgdGhyZWFkSUQgKz0gMQoKIyBGaWxsIHRoZSBxdWV1ZQpxdWV1ZUxvY2suYWNxdWlyZSgpCmZv ciB3b3JkIGluIG5hbWVMaXN0OgogICAgd29ya1F1ZXVlLnB1dCh3b3JkKQpxdWV1ZUxvY2sucmVs ZWFzZSgpCgojIFdhaXQgZm9yIHF1ZXVlIHRvIGVtcHR5CndoaWxlIG5vdCB3b3JrUXVldWUuZW1w dHkoKToKICAgIHBhc3MKCiMgTm90aWZ5IHRocmVhZHMgaXQncyB0aW1lIHRvIGV4aXQKZXhpdEZs YWcgPSAxCgojIFdhaXQgZm9yIGFsbCB0aHJlYWRzIHRvIGNvbXBsZXRlCmZvciB0IGluIHRocmVh ZHM6CiAgICB0LmpvaW4oKQpwcmludCAiRXhpdGluZyBNYWluIFRocmVhZCIKYXBpLmRpc2Nvbm5l Y3QoKQo= --_004_2BD21C61C0C14E8DACCCC9752B029867mconnet_--

1 0

ReferenceError: WebUtil is not defined => novnc console broken after yum update (on centos 6.6?)
by ml＠ohnewald.net 19 May '15

19 May '15

Hello, i think i ran into this bug: https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1202356 I can not use my novnc console anymore. Does anyone have a fix for this (on centos 6.6?) Thanks, Mario

3 2

Postponing oVirt 3.6.0 alpha to tomorrow
by Sandro Bonazzola 19 May '15

19 May '15

Hi, due to outage on the copr repository not providing patternfly rpms, we need to postpone the alpha to tomorrow in order to properly test it before releasing. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

oVirt user permissions for fence_rhevm
by Rik Theys 19 May '15

19 May '15

Hi, I've created a user in AD that should only be able to power off/on a specific VM in oVirt. I've granted this user UserRole permission on this specific VM. If I log into the user portal with these credentials I can see the VM and power it off/on. When I use the fence_rhevm agent it fails to find the correct "plug". I fixed this by adding the "Filter: true" header to the fence_rhevm script. When running manually, fence_rhevm can show me the status of the plug and can power it on/off. When I try to integrate this into a pacemaker cluster (on Debian 7) using the fence_rhevm resource agent it reboots the VM on every monitor action. Has anyone succeeded in using fence_rhevm with oVirt on pacemaker 1.1? Are there any additional oVirt permissions the user needs to make this work? I don't want to make this fence user an admin for my entire ovirt datacenter. The stonith primitive is configured: primitive p_fence_vm1 stonith:fence_rhevm \ params port="vm1" login="fence-vm1(a)mydomain.ad" ipaddr="ovirt-engine.mydomain" ipport="443" ssl="1" passwd="secret" verbose="1" pcmk_host_list="vm1" pcmk_host_check="static-list" \ op monitor interval="15m" Regards, Rik -- Rik Theys System Engineer KU Leuven - Dept. Elektrotechniek (ESAT) Kasteelpark Arenberg 10 bus 2440 - B-3001 Leuven-Heverlee +32(0)16/32.11.07 ---------------------------------------------------------------- <<Any errors in spelling, tact or fact are transmission errors>>

2 1

VM-Affinity [keeping 2 servers from running om the same hosts]
by Stein van Broekhoven 19 May '15

19 May '15

------=_Part_53616_1768657351.1432037377799 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Dear List, We have a few virtual machines that we want to keep separated as much as possible. I've created negative hard enforcing affinity groups with multiple servers in it. Some of them are on the same Hyper-visor but the aren't migrating to other machines. Do I need to trigger a scheduler? Is this functionality possible? Kind Regards, Stein van Broekhoven cloud.nl ------=_Part_53616_1768657351.1432037377799 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>Dear List,</div><div><br data-mce-bogus="1"></div><div>We have a few virtual machines that we want to keep separated as much as possible.</div><div>I've created negative hard enforcing affinity groups with multiple servers in it.</div><div>Some of them are on the same Hyper-visor but the aren't migrating to other machines.</div><div>Do I need to trigger a scheduler?</div><div>Is this functionality possible?</div><div><br data-mce-bogus="1"></div><div>Kind Regards,</div><div><br data-mce-bogus="1"></div><div>Stein van Broekhoven</div><div>cloud.nl</div></div></body></html> ------=_Part_53616_1768657351.1432037377799--

2 1

Ovirt node or Linux standard
by Kevin C 19 May '15

19 May '15

Hi all, There is any reason to choose to install a CentOS 6/7 and add it to oVirt Manager instead of an oVirt Node ? It's just for managability or there is other technical reasons ? Thanks -- Kevin

4 4