May 2014 - Users - oVirt List Archives

1009100 likely be be fixed for 3.5.0?
by Paul Jansen 22 May '14

22 May '14

--1060583355-420566928-1400730682=:1403 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello.=0AThere are a few bugs that are related to live snapshots/storage mi= grations not working.=0Ahttps://bugzilla.redhat.com/show_bug.cgi?id=3D10091= 00 is one of them and is targeted for 3.5.0.=0AAccording to the bug there i= s some engine work still required.=0A=0AI understand that with EL6 based ho= sts live storage migration will still not work (due to a too old QEMU versi= on), but it should work with F20/21 hosts (and EL7 hosts when that comes on= line).=0AAm I correct in assuming that in a cluster with both EL6 hosts and= new hosts (described above) that ovirt will allow live storage migration o= n hosts that support it and prevent the option from appearing on hosts that= do not?=0A=0AThe possibility of getting a newer QEMU on EL6 appears to be = tied up in the Centos virt SIG and their proposed repository, which appears= to be moving quite slowly.=0A=0A=0AI'm looking forward to ovirt closing th= e gap to vmware vcenter in regard to live storage migrations.=0A --1060583355-420566928-1400730682=:1403 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:He= lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;fo= nt-size:12pt"><div style=3D"" class=3D"">Hello.</div><div style=3D"" class= =3D""><span style=3D"" class=3D"">There are a few bugs that are related to = live snapshots/storage migrations not working.</span></div><div class=3D"" = style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,H= elvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif; background-color: t= ransparent; font-style: normal;"><span style=3D"" class=3D"">https://bugzil= la.redhat.com/show_bug.cgi?id=3D1009100 is one of them and is targeted for = 3.5.0.</span></div><div class=3D"" style=3D"color: rgb(0, 0, 0); font-size:= 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Gra= nde,Sans-Serif; background-color: transparent; font-style: normal;">Accordi= ng to the bug there is some engine work still required.</div><div class=3D"= " style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetic= a,Arial,Lucida Grande,Sans-Serif; background-color: transparent; font-style= : normal;"><br></div><div class=3D"" style=3D"color: rgb(0, 0, 0); font-siz= e: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida G= rande,Sans-Serif; background-color: transparent; font-style: normal;">I und= erstand that with EL6 based hosts live storage migration will still not wor= k (due to a too old QEMU version), but it should work with F20/21 hosts (an= d EL7 hosts when that comes online).</div><div class=3D"" style=3D"color: r= gb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Hel= vetica,Arial,Lucida Grande,Sans-Serif; background-color: transparent; font-= style: normal;">Am I correct in assuming that in a cluster with both EL6 ho= sts and new hosts (described above) that ovirt will allow live storage migr= ation on hosts that support it and prevent the option from appearing on hosts that do not?</div><div class=3D"" style=3D"color: rgb(0, 0, 0); font= -size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Luci= da Grande,Sans-Serif; background-color: transparent; font-style: normal;"><= br></div><div class=3D"" style=3D"color: rgb(0, 0, 0); font-size: 16px; fon= t-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-S= erif; background-color: transparent; font-style: normal;">The possibility o= f getting a newer QEMU on EL6 appears to be tied up in the Centos virt SIG = and their proposed repository, which appears to be moving quite slowly.<br>= </div><div class=3D"" style=3D"color: rgb(0, 0, 0); font-size: 16px; font-f= amily: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Seri= f; background-color: transparent; font-style: normal;"><br></div><div class= =3D"" style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: Helvetica= Neue,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif; background-co= lor: transparent; font-style: normal;">I'm looking forward to ovirt closing the= gap to vmware vcenter in regard to live storage migrations.</div><div clas= s=3D"" style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: Helvetic= aNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif; background-c= olor: transparent; font-style: normal;"><br><span style=3D"" class=3D""></s= pan></div></div></body></html> --1060583355-420566928-1400730682=:1403--

1 0

Re: [ovirt-users] Ovirt WebAdmin Portal
by Karli Sjöberg 21 May '14

21 May '14

--_000_5F9E965F5A80BC468BE5F40576769F0979FBE79Bexchange21_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMjEgbWFqIDIwMTQgMjI6MTggc2tyZXYgQ2FybG9zIENhc3RpbGxvIDxjYXJsb3MuY2Fz dGlsbG9AZ2xvYmFsci5uZXQ+Og0KPg0KPiByZWdhcmRzLA0KPg0KPiBNeSBOYW1lIGlzIENhcmxv cyBhbmQgSSdtIGEgSTpUIEFkbWluLiBJIHJlY2VudGx5IG5vdGljZWQgdGhhdCBteSBvVmlydCBX ZWIgQWRtaW4gcG9ydGFsIHNob3dzIDAlIG1lbW9yeSB1c2FnZSBmb3IgYWxsIG15IHZpcnR1YWwg bWFjaGluZXMsIGEgc2l0dWF0aW9uIHRoYXQgZG9lcyBub3Qgc2VlbSByaWdodCB0byBtZS4NCj4N Cj4gSSBoYXZlIHRyaWVkIHRvIHNlYXJjaCBmb3IgaW5mb3JtYXRpb24gYWJvdXQgd2h5IGl0IG1h eSBiZSBoYXBwZW5pbmcgdGhhdCwgYnV0IEkgaGF2ZSBub3QgZm91bmQgYW55dGhpbmcgdXNlZnVs LCBzbyBJIGdvIHRvIHRoaXMgbGlzdCBsb29raW5nIGZvciBpZGVhcz8NCg0KWW91IG5lZWQgdG8g aW5zdGFsbCB0aGUgIm92aXJ0LWd1ZXN0LWFnZW50IiBpbiBhbGwgVk0ncyBmb3IgdGhhdCB0byBz aG93LiBZb3Ugd2lsbCBhbHNvIGdldCB0aGUgVk3igJlzIElQLCBmcWRuLCBzb21lIGluc3RhbGxl ZCBwYWNrYWdlcyBhbmQgd2hv4oCZcyBjdXJyZW50bHkgbG9nZ2VkIGludG8gaXQsIGFtb25nIG90 aGVyIHRoaW5ncy4NCg0KL0sNCg0KPg0KPiBNeSBvVmlydCBFbmdpbmUgVmVyc2lvbjogMy4zLjEt Mi5lbDYsDQo+IE8uUy4gQ2VudE9TIHJlbGVhc2UgNi40IChGaW5hbCkNCj4NCj4NCj4gLS0NCj4g Q2FybG9zIEouIENhc3RpbGxvDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSW5nZW5p ZXJvIGRlIFNvbHVjaW9uZXMgZGUgVEkNCj4gKzU4IDQyNiAyNTQyMzEzDQo+IEBEcjRnMG5LbjFn aHQNCj4NCg== --_000_5F9E965F5A80BC468BE5F40576769F0979FBE79Bexchange21_ Content-Type: text/html; charset="utf-8" Content-ID: <410BBA8BDEF0134AA1B2906E41753CA1(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAyMSBtYWogMjAxNCAyMjoxOCBza3JldiBDYXJsb3MgQ2FzdGlsbG8gJmx0O2Nh cmxvcy5jYXN0aWxsb0BnbG9iYWxyLm5ldCZndDs6PGJyPg0KJmd0Ozxicj4NCiZndDsgcmVnYXJk cywmbmJzcDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBNeSBOYW1lIGlzIENhcmxvcyBhbmQgSSdtIGEg STpUIEFkbWluLiBJIHJlY2VudGx5IG5vdGljZWQgdGhhdCBteSBvVmlydCBXZWIgQWRtaW4gcG9y dGFsIHNob3dzIDAlIG1lbW9yeSB1c2FnZSBmb3IgYWxsIG15IHZpcnR1YWwgbWFjaGluZXMsIGEg c2l0dWF0aW9uIHRoYXQgZG9lcyBub3Qgc2VlbSByaWdodCB0byBtZS48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBJIGhhdmUgdHJpZWQgdG8gc2VhcmNoIGZvciBpbmZvcm1hdGlvbiBhYm91dCB3aHkgaXQg bWF5IGJlIGhhcHBlbmluZyB0aGF0LCBidXQgSSBoYXZlIG5vdCBmb3VuZCBhbnl0aGluZyB1c2Vm dWwsIHNvIEkgZ28gdG8gdGhpcyBsaXN0IGxvb2tpbmcgZm9yIGlkZWFzPzwvcD4NCjxwIGRpcj0i bHRyIj5Zb3UgbmVlZCB0byBpbnN0YWxsIHRoZSAmcXVvdDtvdmlydC1ndWVzdC1hZ2VudCZxdW90 OyBpbiBhbGwgVk0ncyBmb3IgdGhhdCB0byBzaG93LiBZb3Ugd2lsbCBhbHNvIGdldCB0aGUgVk3i gJlzIElQLCBmcWRuLCBzb21lIGluc3RhbGxlZCBwYWNrYWdlcyBhbmQgd2hv4oCZcyBjdXJyZW50 bHkgbG9nZ2VkIGludG8gaXQsIGFtb25nIG90aGVyIHRoaW5ncy48L3A+DQo8cCBkaXI9Imx0ciI+ L0s8L3A+DQo8cCBkaXI9Imx0ciI+Jmd0Ozxicj4NCiZndDsgTXkgb1ZpcnQgRW5naW5lIFZlcnNp b246IDMuMy4xLTIuZWw2LDxicj4NCiZndDsgTy5TLiBDZW50T1MgcmVsZWFzZSA2LjQgKEZpbmFs KTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IENhcmxvcyBKLiBD YXN0aWxsbzxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgSW5n ZW5pZXJvIGRlIFNvbHVjaW9uZXMgZGUgVEk8YnI+DQomZ3Q7ICYjNDM7NTggNDI2IDI1NDIzMTM8 YnI+DQomZ3Q7IEBEcjRnMG5LbjFnaHQ8YnI+DQomZ3Q7PGJyPg0KPC9wPg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_5F9E965F5A80BC468BE5F40576769F0979FBE79Bexchange21_--

2 1

Ovirt WebAdmin Portal
by Carlos Castillo 21 May '14

21 May '14

regards, My Name is Carlos and I'm a I:T Admin. I recently noticed that my oVirt Web Admin portal shows 0% memory usage for all my virtual machines, a situation that does not seem right to me. I have tried to search for information about why it may be happening that, but I have not found anything useful, so I go to this list looking for ideas? My oVirt Engine Version: 3.3.1-2.el6, O.S. CentOS release 6.4 (Final) -- Carlos J. Castillo ---------------------------------------------------------------------------------- Ingeniero de Soluciones de TI +58 426 2542313 @Dr4g0nKn1ght

2 1

Fwd: [Users] Ovirt 3.4 EqualLogic multipath Bug 953343
by Gary Lloyd 21 May '14

21 May '14

Hi I was just wondering if ISCSI Multipathing is supported yet on Direct Lun ? I have deployed 3.4.0.1 but i can only see the option for ISCSI multipathing on storage domains. We will be glad if it could be, as it saves us having to inject new code into our vdsm nodes with each new version. Thanks *Gary Lloyd* ---------------------------------- IT Services Keele University ----------------------------------- Guys, Please, pay attention that this feature currently may not work. I resolved several bugs related to this feature but some of my patches are still waiting for merge. Regards, Sergey ----- Original Message ----- > From: "Maor Lipchuk" <mlipchuk(a)redhat.com> > To: "Gary Lloyd" <g.lloyd(a)keele.ac.uk>, users(a)ovirt.org, "Sergey Gotliv" < sgotliv(a)redhat.com> > Sent: Thursday, March 27, 2014 6:50:10 PM > Subject: Re: [Users] Ovirt 3.4 EqualLogic multipath Bug 953343 > > IIRC it should also support direct luns as well. > Sergey? > > regards, > Maor > > On 03/27/2014 06:25 PM, Gary Lloyd wrote: > > Hi I have just had a look at this thanks. Whilst it seemed promising we > > are in a situation where we use Direct Lun for all our production VM's > > in order to take advantage of being able to individually replicate and > > restore vm volumes using the SAN tools. Is multipath supported for > > Direct Luns or only data domains ? > > > > Thanks > > > > /Gary Lloyd/ > > ---------------------------------- > > IT Services > > Keele University > > ----------------------------------- > > > > > > On 27 March 2014 16:02, Maor Lipchuk <mlipchuk(a)redhat.com > > <mailto:mlipchuk@redhat.com>> wrote: > > > > Hi Gary, > > > > Please take a look at > > http://www.ovirt.org/Feature/iSCSI-Multipath#User_Experience > > > > Regards, > > Maor > > > > On 03/27/2014 05:59 PM, Gary Lloyd wrote: > > > Hello > > > > > > I have just deployed Ovirt 3.4 on our test environment. Does > > anyone know > > > how the ISCSI multipath issue is resolved ? At the moment it is > > behaving > > > as before and only opening one session per lun ( we bodged vdsm > > > python > > > code in previous releases to get it to work). > > > > > > The Planning sheet shows that its fixed but I am not sure what to do > > > next: > > https://docs.google.com/spreadsheet/ccc?key=0AuAtmJW_VMCRdHJ6N1M3d1F1UTJTS1… > > > > > > > > > Thanks > > > > > > /Gary Lloyd/ > > > ---------------------------------- > > > IT Services > > > Keele University > > > ----------------------------------- > > > > > > > > > _______________________________________________ > > > Users mailing list > > > Users(a)ovirt.org <mailto:Users@ovirt.org> > > > http://lists.ovirt.org/mailman/listinfo/users > > > > > > > > > _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users -- Martin Goldstone IT Systems Administrator - Finance & IT Keele University, Keele, Staffordshire, United Kingdom, ST5 5BG Telephone: +44 1782 734457 G+: http://google.com/+MartinGoldstoneKeele

1 0

oVirt Weekly Meeting Minutes: May 21, 2014
by Brian Proffitt 21 May '14

21 May '14

Minutes: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-21-14.02.html Minutes (text): http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-21-14.02.txt Log: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-21-14.02.log.html ========================= #ovirt: oVirt Weekly Sync ========================= Meeting started by bkp at 14:02:03 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-21-14.02.log.html . Meeting summary --------------- * Agenda and Roll Call (bkp, 14:02:19) * infra updates (bkp, 14:02:42) * 3.4.z updates (bkp, 14:02:42) * 3.5 planning (bkp, 14:02:42) * conferences and workshops (bkp, 14:02:42) * other topics (bkp, 14:02:42) * infra updates (bkp, 14:03:01) * infra os1 issues solved, will add new slaves in the following days (bkp, 14:06:28) * 3.4.z updates (bkp, 14:08:05) * 3.4.z updates 3.4.2: RC scheduled for 2014-05-27 (bkp, 14:11:53) * 3.4.z updates SvenKieske sent a list of proposed blockers to be reviewed: http://lists.ovirt.org/pipermail/users/2014-May/024518.html (bkp, 14:11:53) * 3.4.z updates Bug 1037663 status: ovirt-log-collector: conflicts with file from package sos >= 3.0, sbonazzo working with sos maintainer for coordinating oVirt 3.4.2 release. Not a blocker. (bkp, 14:11:53) * 3.4.z updates Discussion is ongoing on mailing list for other bugs (bkp, 14:11:54) * 3.5 planning (bkp, 14:12:20) * 3.5 planning UX Phase one of patternfly is in, and the sorting infra (bkp, 14:14:53) * 3.5 planning UX Issues fixed as they are reported. (bkp, 14:14:53) * 3.5 planning SLA All planned 3.5 features will be ready on time, fingers crossed :) (bkp, 14:18:22) * 3.5 planning SLA NUMA feature: APIs (GUI and RESTful) still missing. (bkp, 14:18:22) * 3.5 planning SLA optaplanner: in advanced development state. (bkp, 14:18:22) * 3.5 planning SLA Limits (blkio and cpu, incluiding disk and cpu profile, including refactoring current network qos and vnic profile to suit new sla/profiles infra): we are working on them nowadays (no real issues there) (bkp, 14:18:22) * 3.5 planning SLA Scheduling RESTful API: developed now - patch this evening (bkp, 14:18:22) * LINK: http://www.ovirt.org/Features/Self_Hosted_Engine_iSCSI_Support all patches have been pushed and under review (sbonazzo, 14:20:07) * LINK: http://www.ovirt.org/Features/oVirt_Windows_Guest_Tools (sbonazzo, 14:20:55) * 3.5 planning integration ovirt 3.5.0 alpha released yesterday (bkp, 14:22:47) * 3.5 planning integration ovirt live iso uploaded this afternoon (bkp, 14:22:47) * 3.5 planning integration ovirt node iso will follow (bkp, 14:22:47) * 3.5 planning integration 3.5.0 Second Alpha scheduled for May 30 for Feature Freeze (bkp, 14:22:47) * 3.5 planning integration http://www.ovirt.org/Features/Self_Hosted_Engine_iSCSI_Support all patches have been pushed and under review (bkp, 14:22:47) * 3.5 planning integration There's an issue on additional host setup, but should be fixed easily. Patch pushed an under review. (bkp, 14:22:49) * 3.5 planning integration F20 support started for ovirt-engine, hopefully ready for alpha 2 (bkp, 14:22:52) * 3.5 planning virt Unfinished features are closer to completition... but nothing got in yet. (bkp, 14:29:06) * 3.5 planning virt Last week spent fixing major bugs. (bkp, 14:29:06) * 3.5 planning Gluster Volume capacity - vdsm dependency on libgfapi-python needs to be added (bkp, 14:34:31) * 3.5 planning Gluster Volume profile - review comments on patches incorporated and submitted, need final review and approval (bkp, 14:34:31) * 3.5 planning Gluster REST API in progress (bkp, 14:34:31) * 3.5 planning node All features are in progress. (bkp, 14:37:59) * 3.5 planning node Two features up for review (generic registration and hosted engine plugin) (bkp, 14:37:59) * 3.5 planning node Appliances can also be built, now all needs to be reviewed and tested. (bkp, 14:37:59) * 3.5 planning node ETA for a node with the bits in place by early next week. (bkp, 14:37:59) * 3.5 planning network All Neutron appliance oVirt code is merged. Feature now depends on some OpenStack repository processes that are async with oVirt releases. oVirt side completed. (bkp, 14:42:17) * 3.5 planning network The two MAC pool features are in a tough review, so they're in danger even for the new deadline of end of May. (bkp, 14:42:17) * 3.5 planning network Progress with the RHEL bug on which bridge_opts depends upon is unknown. danken adds that it is not a blocker for 3.5 (bkp, 14:42:17) * 3.5 planning network [UPDATE] Progress with the RHEL bug on which bridge_opts depends upon done (with an asterisk). (bkp, 14:43:34) * 3.5 planning storage Store OVF on any domains - merged (bkp, 14:49:12) * 3.5 planning storage Disk alias recycling in web-admin portal - merged (bkp, 14:49:13) * 3.5 planning storage [RFE] Snapshot overview in webadmin portal - merged (bkp, 14:49:13) * 3.5 planning storage import existing data domain - phase one was revised yesterday, should be reviewed today and tommorow, and hopefully be merged by end of week (bkp, 14:49:13) * 3.5 planning storage Sanlock fencing seems this will slip 3.5.0 after (infra required a late redesign) (bkp, 14:49:13) * 3.5 planning storage live merge (delete snapshot) - in progress. Three patches upstream (engine side), one is going to be merged soon (today hopefully), the other two under review. (bkp, 14:49:14) * 3.5 infra Working hard on 3.5 features, and hope everything will make it on time. (bkp, 14:49:53) * 3.5 infra The current status is in the planning wiki. (bkp, 14:49:53) * 3.5 infra If infra-related questions pop up then just email them, and ovedo will answer them this evening/tomorrow. (bkp, 14:49:53) * conferences and workshops (bkp, 14:50:22) * Conferences OpenStack Israel is still on for June 2. (bkp, 14:51:50) * Conferences FrOSCON CfP closes May 23 (bkp, 14:51:50) * Conferences OSCON Open Cloud Day CfP closes May 27 (bkp, 14:51:50) * ACTION: More conference participation is needed for 2014. See bkp for help planning/submitting presentations. (bkp, 14:51:50) * other topics (bkp, 14:53:04) Meeting ended at 14:56:14 UTC. Action Items ------------ * More conference participation is needed for 2014. See bkp for help planning/submitting presentations. Action Items, by person ----------------------- * bkp * More conference participation is needed for 2014. See bkp for help planning/submitting presentations. People Present (lines said) --------------------------- * bkp (115) * sbonazzo (32) * lvernia (14) * gchaplik (12) * nsoffer (11) * fabiand (9) * mskrivanek (8) * danken (5) * awels (4) * dcaro (3) * sahina (3) * ovirtbot (3) * jb_badpenny (1) * SvenKieske (1) * fsimonce (1) * mburns (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Brian Proffitt oVirt Community Manager Project Atomic Community Lead Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC

1 0

sanlock + gluster recovery -- RFE
by Ted Miller 21 May '14

21 May '14

--------------050904040002030300050808 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Itamar, I am addressing this to you because one of your assignments seems to be to coordinate other oVirt contributors when dealing with issues that are raised on the ovirt-users email list. As you are aware, there is an ongoing split-brain problem with running sanlock on replicated gluster storage. Personally, I believe that this is the 5th time that I have been bitten by this sanlock+gluster problem. I believe that the following are true (if not, my entire request is probably off base). * ovirt uses sanlock in such a way that when the sanlock storage is on a replicated gluster file system, very small storage disruptions can result in a gluster split-brain on the sanlock space o gluster is aware of the problem, and is working on a different way of replicating data, which will reduce these problems. * most (maybe all) of the sanlock locks have a short duration, measured in seconds * there are only a couple of things that a user can safely do from the command line when a file is in split-brain o delete the file o rename (mv) the file * x _How did I get into this mess?_ had 3 hosts running ovirt 3.3 each hosted VMs gluster replica 3 storage engine was external to cluster upgraded 3 hosts from ovirt 3.3 to 3.4 hosted-engine deploy used new gluster volume (accessed via nfs) for storage storage was accessed using localhost:engVM1 link (localhost was probably a poor choice) created new engine on VM (did not transfer any data from old engine) added 3 hosts to new engine via web-gui ran above setup for 3 days shut entire system down before I left on vacation (holiday) came back from vacation powered on hosts found that iptables did not have rules for gluster access (a continuing problem if host installation is allowed to set up firewall) added rules for gluster glusterfs now up and running added storage manually tried "hosted-engine --vm-start" vm did not start logs show sanlock errors "gluster volume heal engVM1full: "gluster volume heal engVM1 info split-brain" showed 6 files in split-brain all 5 prefixed by /rhev/data-center/mnt/localhost\:_engVM1 UUID/dom_md/ids UUID/images/UUID/UUID (VM hard disk) UUID/images/UUID/UUID.lease UUID/ha_agent/hosted-engine.lockspace UUID/ha_agent/hosted-engine.metadata I copied each of the above files off of each of the three bricks to a safe place (15 files copied) I renamed the 5 files on /rhev/.... I copied the 5 files from one of the bricks to /rhev/ files can now be read OK (e.g. cat ids) sanlock.log shows error sets like these: 2014-05-20 03:23:39-0400 36199 [2843]: s3358 lockspace 5ebb3b40-a394-405b-bbac-4c0e21ccd659:1:/rhev/data-center/mnt/localhost:_engVM1/5ebb3b40-a394-405b-bbac-4c0e21ccd659/dom_md/ids:0 2014-05-20 03:23:39-0400 36199 [18873]: open error -5 /rhev/data-center/mnt/localhost:_engVM1/5ebb3b40-a394-405b-bbac-4c0e21ccd659/dom_md/ids 2014-05-20 03:23:39-0400 36199 [18873]: s3358 open_disk /rhev/data-center/mnt/localhost:_engVM1/5ebb3b40-a394-405b-bbac-4c0e21ccd659/dom_md/ids error -5 2014-05-20 03:23:40-0400 36200 [2843]: s3358 add_lockspace fail result -19 I am now stuck What I would like to see in ovirt to help me (and others like me). Alternates listed in order from most desirable (automatic) to least desirable (set of commands to type, with lots of variables to figure out). 1. automagic recovery * When a host is not able to access sanlock, it writes a small "problem" text file into the shared storage o the host-ID as part of the name (so only one host ever accesses that file) o a status number for the error causing problems o time stamp o time stamp when last sanlock lease will expire o if sanlock is able to access the file, the "problem" file is deleted * when time passes for its last sanlock lease to be expired, highest number host does a survey o did all other hosts create "problem" files? o do all "problem" files show same (or compatible) error codes related to file access problems? o are all hosts communicating by network? o if yes to all above * delete all sanlock storage space * initialize sanlock from scratch * restart whatever may have given up because of sanlock * restart VM if necessary 2. recovery subcommand * add "hosted-engine --lock-initialize" command that would delete sanlock, start over from scratch 3. script * publish a script (in ovirt packages or available on web) which, when run, does all (or most) of the recovery process needed. 4. commands * publish on the web a "recipe" for dealing with files that commonly go split-brain o ids o *.lease o *.lockspace Any chance of any help on any of the above levels? Ted Miller Elkhart, IN, USA --------------050904040002030300050808 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body text="#000000" bgcolor="#FFFFFF"> Itamar, I am addressing this to you because one of your assignments seems to be to coordinate other oVirt contributors when dealing with issues that are raised on the ovirt-users email list.<br> <br> As you are aware, there is an ongoing split-brain problem with running sanlock on replicated gluster storage.  Personally, I believe that this is the 5th time that I have been bitten by this sanlock+gluster problem.<br> <br> I believe that the following are true (if not, my entire request is probably off base).<br> <ul> <li>ovirt uses sanlock in such a way that when the sanlock storage is on a replicated gluster file system, very small storage disruptions can result in a gluster split-brain on the sanlock space</li> <ul> <li>gluster is aware of the problem, and is working on a different way of replicating data, which will reduce these problems.</li> </ul> <li>most (maybe all) of the sanlock locks have a short duration, measured in seconds</li> <li>there are only a couple of things that a user can safely do from the command line when a file is in split-brain</li> <ul> <li>delete the file</li> <li>rename (mv) the file<br> </li> </ul> <li>x</li> </ul> <u>How did I get into this mess?</u><br> <br> had 3 hosts running ovirt 3.3<br>     each hosted VMs<br>     gluster replica 3 storage<br>     engine was external to cluster<br> upgraded 3 hosts from ovirt 3.3 to 3.4<br> hosted-engine deploy<br>     used new gluster volume (accessed via nfs) for storage<br>         storage was accessed using localhost:engVM1 link (localhost was probably a poor choice)<br>     created new engine on VM (did not transfer any data from old engine)<br> added 3 hosts to new engine via web-gui<br> ran above setup for 3 days<br> shut entire system down before I left on vacation (holiday)<br> came back from vacation<br> powered on hosts<br> found that iptables did not have rules for gluster access<br>     (a continuing problem if host installation is allowed to set up firewall)<br> added rules for gluster<br> glusterfs now up and running<br> added storage manually<br> tried "hosted-engine --vm-start"<br> vm did not start<br> logs show sanlock errors<br> "gluster volume heal engVM1full:<br> "gluster volume heal engVM1 info split-brain" showed 6 files in split-brain<br>         all 5 prefixed by /rhev/data-center/mnt/localhost\:_engVM1<br>     UUID/dom_md/ids<br>     UUID/images/UUID/UUID (VM hard disk)<br>     UUID/images/UUID/UUID.lease<br>     UUID/ha_agent/hosted-engine.lockspace<br>     UUID/ha_agent/hosted-engine.metadata<br> I copied each of the above files off of each of the three bricks to a safe place (15 files copied)<br> I renamed the 5 files on /rhev/....<br> I copied the 5 files from one of the bricks to /rhev/<br>     files can now be read OK (e.g. cat ids)<br> sanlock.log shows error sets like these:<br> <pre>2014-05-20 03:23:39-0400 36199 [2843]: s3358 lockspace 5ebb3b40-a394-405b-bbac-4c0e21ccd659:1:/rhev/data-center/mnt/localhost:_engVM1/5ebb3b40-a394-405b-bbac-4c0e21ccd659/dom_md/ids:0 2014-05-20 03:23:39-0400 36199 [18873]: open error -5 /rhev/data-center/mnt/localhost:_engVM1/5ebb3b40-a394-405b-bbac-4c0e21ccd659/dom_md/ids 2014-05-20 03:23:39-0400 36199 [18873]: s3358 open_disk /rhev/data-center/mnt/localhost:_engVM1/5ebb3b40-a394-405b-bbac-4c0e21ccd659/dom_md/ids error -5 2014-05-20 03:23:40-0400 36200 [2843]: s3358 add_lockspace fail result -19</pre> I am now stuck<br> <br> What I would like to see in ovirt to help me (and others like me).  Alternates listed in order from most desirable (automatic) to least desirable (set of commands to type, with lots of variables to figure out).<br> <br> 1. automagic recovery<br> <ul> <li> When a host is not able to access sanlock, it writes a small "problem" text file into the shared storage</li> <ul> <li>the host-ID as part of the name (so only one host ever accesses that file)</li> <li>a status number for the error causing problems</li> <li>time stamp</li> <li>time stamp when last sanlock lease will expire</li> <li>if sanlock is able to access the file, the "problem" file is deleted</li> </ul> <li>when time passes for its last sanlock lease to be expired, highest number host does a survey</li> <ul> <li>did all other hosts create "problem" files?</li> <li>do all "problem" files show same (or compatible) error codes related to file access problems?</li> <li>are all hosts communicating by network?</li> <li>if yes to all above</li> </ul> <li>delete all sanlock storage space<br> </li> <li>initialize sanlock from scratch</li> <li>restart whatever may have given up because of sanlock</li> <li>restart VM if necessary</li> </ul> <p>2. recovery subcommand<br> </p> <ul> <li>add "hosted-engine --lock-initialize" command that would delete sanlock, start over from scratch</li> </ul> <p>3. script<br> </p> <ul> <li>publish a script (in ovirt packages or available on web) which, when run, does all (or most) of the recovery process needed.</li> </ul> <p>4. commands<br> </p> <ul> <li>publish on the web a "recipe" for dealing with files that commonly go split-brain</li> <ul> <li>ids</li> <li>*.lease</li> <li>*.lockspace</li> </ul> </ul> <p>Any chance of any help on any of the above levels?<br> </p> <p>Ted Miller<br> Elkhart, IN, USA<br> <br> </p> </body> </html> --------------050904040002030300050808--

3 2

[QE][ACTION NEEDED] oVirt 3.4.2 RC status
by Sandro Bonazzola 21 May '14

21 May '14

Hi, We're going to start composing oVirt 3.4.2 RC on *2014-05-27 08:00 UTC* from 3.4 branches. The bug tracker [1] shows no blocking bugs for the release There are still 71 bugs [2] targeted to 3.4.2. Excluding node and documentation bugs we still have 39 bugs [3] targeted to 3.4.2. Maintainers / Assignee: - Please add the bugs to the tracker if you think that 3.4.2 should not be released without them fixed. - Please update the target to any next release for bugs that won't be in 3.4.2: it will ease gathering the blocking bugs for next releases. - Please fill release notes, the page has been created here [4] - If you need to rebuild packages, please build them before *2014-05-26 15:00 UTC*. Otherwise we'll take last 3.4 snapshot available. Community: - If you're going to test this release, please add yourself to the test page [5] [1] http://bugzilla.redhat.com/1095370 [2] http://red.ht/1oqLLlr [3] http://red.ht/1nIAZXO [4] http://www.ovirt.org/OVirt_3.4.2_Release_Notes [5] http://www.ovirt.org/Testing/oVirt_3.4.2_Testing Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 3

[QE][ACTION NEEDED] oVirt 3.5.0 Alpha status
by Sandro Bonazzola 21 May '14

21 May '14

Hi, We released oVirt 3.5.0 Alpha on *2014-05-20* and we're now preparing for feature freeze scheduled for 2014-05-30. We're going to compose a second Alpha on Firday *2014-05-30 08:00 UTC*. Maintainers: - Please be sure that master snapshot allow to create VMs before *2014-05-29 15:00 UTC* The bug tracker [1] shows the following proposed blockers to be reviewed: Bug ID Whiteboard Status Summary 1001100 integration NEW Add log gathering for a new ovirt module (External scheduler) 1073944 integration ASSIGNED Add log gathering for a new ovirt module (External scheduler) 1060198 integration NEW [RFE] add support for Fedora 20 1099432 virt NEW noVNC client doesn't work: Server disconnected (code: 1006) Feature freeze has been postponed to 2014-05-30 and the following features should be testable in 3.5.0 Alpha according to Features Status Table [2] Group oVirt BZ Title gluster 1096713 Monitoring (UI plugin) Dashboard (Integrated with Nagios monitoring) infra 1090530 [RFE] Please add host count and guest count columns to "Clusters" tab in webadmin infra 1054778 [RFE] Allow to perform fence operations from a host in another DC infra 1090803 [RFE] Change the "Slot" field to "Service Profile" when cisco_ucs is selected as the fencing type infra 1090511 [RFE] Improve fencing robustness by retrying failed attempts infra 1090794 [RFE] Search VMs based on MAC address from web-admin portal infra 1090793 consider the event type while printing events to engine.log infra 1090796 [RFE] Re-work engine ovirt-node host-deploy sequence infra 1090798 [RFE] Admin GUI - Add host uptime information to the "General" tab infra 1090808 [RFE] Ability to dismiss alerts and events from web-admin portal infra-api 1090797 [RFE] RESTAPI: Add /tags sub-collection for Template resource infra-dwh 1091686 prevent OutOfMemoryError after starting the dwh service. network 1078836 Add a warning when adding display network network 1079719 Display of NIC Slave/Bond fault on Event Log network 1080987 Support ethtool_opts functionality within oVirt storage 1054241 Store OVF on any domains storage 1083312 Disk alias recycling in web-admin portal ux 1064543 oVirt new look and feel [PatternFly adoption] - phase #1 virt 1058832 Allow to clone a (down) VM without snapshot/template virt 1031040 can't set different keymap for vnc via runonce option virt 1043471 oVirt guest agent for SLES virt 1083049 add progress bar for vm migration virt 1083065 EL 7 guest compatibility virt 1083059 "Instance types (new template handling) - adding flavours" virt Allow guest serial number to be configurable virt 1047624 [RFE] support BIOS boot device menu virt 1083129 allows setting netbios name, locale, language and keyboard settings for windows vm's virt 1038632 spice-html5 button to show debug console/output window virt 1080002 [RFE] Enable user defined Windows Sysprep file done Some more features may be included since they were near to be completed on last sync meeting. The table will be updated on next sync meeting scheduled for 2014-05-21. There are still 382 bugs [3] targeted to 3.5.0. Excluding node and documentation bugs we still have 319 bugs [4] targeted to 3.5.0. Maintainers / Assignee: - Please remember to rebuild your packages before *2014-05-29 15:00 UTC* if needed, otherwise nightly snapshot will be taken. - Please be sure that master snapshot allow to create VMs before *2014-05-29 15:00 UTC* - If you find a blocker bug please remember to add it to the tracker [1] - Please start filling release notes, the page has been created here [5] Community: - You're welcome to join us testing this alpha release and getting involved in oVirt Quality Assurance[6]! [1] http://bugzilla.redhat.com/1073943 [2] http://bit.ly/17qBn6F [3] http://red.ht/1pVEk7H [4] http://red.ht/1rLCJwF [5] http://www.ovirt.org/OVirt_3.5_Release_Notes [6] http://www.ovirt.org/OVirt_Quality_Assurance Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Jpackage down
by Neil 21 May '14

21 May '14

Hi guys, I'm doing an urgent ovirt upgrade from 3.2(dreyou) to 3.4 (official) but I see that www.jpackage.org is down. I've managed to install jboss-as-7.1.1-11.el6.x86_64 from another location, however I'm not sure if this will be compatible with 3.4, as per the instructions from "http://wiki.dreyou.org/dokuwiki/doku.php?id=ovirt_rpm_start33" I've tested browsing to the site on two different internet links, as well as from the remote server but I'm just getting... RepoError: Cannot retrieve repository metadata (repomd.xml) for repository: ovirt-jpackage-6.0-generic. Please verify its path and try again Can I go ahead and attempt the upgrade using 7.1.1-11? Thanks! Regards. Neil Wilson.

4 6

Power Management IBM IMM
by Milen Nikolov 21 May '14

21 May '14

--Apple-Mail=_BCCF7375-D576-4E3B-981C-2183629F8D3D Content-Type: multipart/alternative; boundary="Apple-Mail=_23F6B5A1-D355-4DA7-8EC0-D7FEE3AC1787" --Apple-Mail=_23F6B5A1-D355-4DA7-8EC0-D7FEE3AC1787 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Any advise of which Power Management driver to use with IBM=92s IMM2 = management module? There=92s only driver for the very old rsa management module. Best!, Milen. --- Milen Nikolov CTO, Daticum JSC e-mail: milen(a)sirma.bg tel: +359 2 490 1580 mobile: +359 886 409 033 www.daticum.com www.sirma.bg --- --Apple-Mail=_23F6B5A1-D355-4DA7-8EC0-D7FEE3AC1787 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space;">Hi,<div><br></div><div>Any advise  of which = Power Management driver to use with IBM=92s IMM2 management = module?</div><div>There=92s only driver for the very old rsa management = module.</div><div><br><div apple-content-edited=3D"true"><div = style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; line-height: normal; orphans: 2; text-align: = -webkit-auto; text-indent: 0px; text-transform: none; white-space: = normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; = -webkit-text-stroke-width: 0px; word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><br></div><div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; line-height: normal; orphans: 2; text-align: = -webkit-auto; text-indent: 0px; text-transform: none; white-space: = normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; = -webkit-text-stroke-width: 0px; word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = ">Best!,</div><div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; line-height: normal; orphans: 2; text-align: = -webkit-auto; text-indent: 0px; text-transform: none; white-space: = normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; = -webkit-text-stroke-width: 0px; word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = ">Milen.</div><div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; line-height: normal; orphans: 2; text-align: = -webkit-auto; text-indent: 0px; text-transform: none; white-space: = normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; = -webkit-text-stroke-width: 0px; word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><br></div><div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; line-height: normal; orphans: 2; text-align: = -webkit-auto; text-indent: 0px; text-transform: none; white-space: = normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; = -webkit-text-stroke-width: 0px; word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><br></div><div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; line-height: normal; orphans: 2; text-align: = -webkit-auto; text-indent: 0px; text-transform: none; white-space: = normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; = -webkit-text-stroke-width: 0px; word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><br></div><div style=3D"color: rgb(0, 0, 0); font-family: Helvetica; = font-style: normal; font-variant: normal; font-weight: normal; = letter-spacing: normal; line-height: normal; orphans: 2; text-align: = -webkit-auto; text-indent: 0px; text-transform: none; white-space: = normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; = -webkit-text-stroke-width: 0px; word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = ">---<br>Milen Nikolov<br>CTO, Daticum JSC<br>e-mail: <a = href=3D"mailto:milen@sirma.bg">milen(a)sirma.bg</a><br>tel: +359 2 490 = 1580<br>mobile: +359 886 409 033<br><a = href=3D"http://www.daticum.com">www.daticum.com</a> <a = href=3D"http://www.sirma.bg">www.sirma.bg</a><br>---</div> </div> <br></div></body></html>= --Apple-Mail=_23F6B5A1-D355-4DA7-8EC0-D7FEE3AC1787-- --Apple-Mail=_BCCF7375-D576-4E3B-981C-2183629F8D3D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIuTCCBBYw ggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcNMTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMSBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGj x0+LH0uRqeZCHrYQ7KN3QuahfxY8fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqD lin3HracDqMRgwrknWuFeqxhN2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQ BhcaJA2ucABbUVTHDTxi7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+ OhtnAhrgzrsd4oAyqgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7u poxvV09Fsf7hDeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUd IAAwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAfBgNV HSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7unyEtmt9Ia 7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDuvg/OZ0gILDFI a9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVUm5V1tW3XuYNg6Sbt cDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVgwb/j/kplOa13nshhc8zU LVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5uiB8TZ0s327g44Ylc6dgKgYelN n9RLYjNETX8OIJZlr0tFYpcYrDCCBJswggODoAMCAQICEGZgT+TGYtW+XJFIU8YivuQwDQYJKoZI hvcNAQEFBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNV BAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDEgQ0EgLSBHMjAeFw0xMzA4MTUxMTA1MTVaFw0x NDA4MTYxMTA1MTVaMDgxFzAVBgNVBAMMDm1pbGVuQHNpcm1hLmJnMR0wGwYJKoZIhvcNAQkBFg5t aWxlbkBzaXJtYS5iZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANTWw9EEIQEUOFfQ YW8YV3TKTxg8bxVjEzGHsT4scB/DTxLh+WBTmHbTyGNxl+O6bHuZy7PLO3O8uZHZvyiuaFONjXej C4lwWDKXrfnTlJqUkMPW/DFNe0kAXZIcE5L7l8W/rNogUCagjFstuOWzKK/np0iAA6cQV1gIy2X5 ydIS6Jh7gxx2knIRZETYkTLzxsj4eV1V5M9VTnoL3UFgTTy08TwO/CtCfxHjK3hqK3qUC9wza8b4 xtHBKSAIDCm61YM/ByFimIR3DincgiVJ6+0hyhpCX2jsvcir5MdJrxD9efSGzxqdpcQFq1cVYJC6 xvrlOX15UgFn6cNeJSf9098CAwEAAaOCAYMwggF/MA4GA1UdDwEB/wQEAwIFoDBMBgNVHSAERTBD MEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9y ZXBvc2l0b3J5LzAZBgNVHREEEjAQgQ5taWxlbkBzaXJtYS5iZzAJBgNVHRMEAjAAMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMWcyLmNybDBVBggrBgEFBQcBAQRJMEcwRQYIKwYB BQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxzaWdu MWcyLmNydDAdBgNVHQ4EFgQUtA64XK8GI+t4AjSn3IhA0qUhecIwHwYDVR0jBBgwFoAU7KyYzCdy k89WMs0jx52NRYX0IgMwDQYJKoZIhvcNAQEFBQADggEBAEF2ZM9zCwQafo0drpe40Tigr1biK8RA Vvi9fMXyqOiguNf/O5rO4OcYtnaCuSCfI8D0vRPORK6QyDA5PtJCqBgUea3DV9I19NfCq9uubbsx Cp/UJwdpByNG8w1pQJ7ZE6HrMKGUfRoK/334uZ8TXnjjDz2CbCyPeon4StHGFfo7EEPJmaW2dtfu MM3C4efYDYwaj2qPGiJxp+tNJSin/3K6Uvs95Xmmd/4pepQd9ORL7M1Iwp1limgXjNHFWLv3Q5MK VZzzmzTA9dJpkx2i2GjrOpnnsAORALGpjkoG+gf3BHB8OrMMA1nL9br+1CbCRQGq+z8hzgkQhkYq pmqGbfMxggLkMIIC4AIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52 LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzICEGZgT+TGYtW+ XJFIU8YivuQwCQYFKw4DAhoFAKCCAVEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNTE5MDkzMjI4WjAjBgkqhkiG9w0BCQQxFgQUyJ+pWOgBOgYJlnONCJaZVyxC Q2MwdwYJKwYBBAGCNxAEMWowaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBu di1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyAhBmYE/kxmLV vlyRSFPGIr7kMHkGCyqGSIb3DQEJEAILMWqgaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcy AhBmYE/kxmLVvlyRSFPGIr7kMA0GCSqGSIb3DQEBAQUABIIBAJ4zaUlZZBNV7gvGRlgVihCKcDfK x15+5/7jT50gf6tahBNJT9ulK0PMci4IM3yUyobJIQZmb6FNFsq5v2SQEybgionfOwW9iKgeako5 /3bsQSmrh048sFVdHpqbDhr72Jzknx2h77kmb09ADOb5456F1g5l6kbOgV1HLqjx5bZNZPM5jwpV MJTNAN77bALV/CHAq/Bntww/0JSz+EK1X2jL9ipptL/un0S8dChZ4mNeqd59IhwkB8VZHCuE/Mnh t+cZcACPe/bGJ04tev3qpxmGZni0uMgQRp0YrHwU5YWyj+G9T1OfZ2FnUyjJ93OWKKM4zgweFTKW uZuBhzctp/cAAAAAAAA= --Apple-Mail=_BCCF7375-D576-4E3B-981C-2183629F8D3D--

3 2

vm's not shutting down from admin portal
by Jeff Clay 21 May '14

21 May '14

When selecting to shutdown vm's from the admi portal, it often doesn't work although, sometimes it does. These machines are all stateless and in the same pool, yet sometimes they will shutdown from the portal, most of the time they don't. here's what I see in engine.log when they don't shutdown. 2014-05-19 18:17:42,477 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (org.ovirt.thread.pool-6-thread-2) [4d427221] Correlation ID: 4d427221, Job ID: ce662a5c-9474-4406-90f5-e941e130b47d, Call Stack: null, Custom Event ID: -1, Message: VM shutdown initiated by Jeff.Clay on VM USAROVRTVZ-13 (Host: USARPAOVRTHOST02). 2014-05-19 18:22:45,333 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-53) VM USAROVRTVZ-13 67a51ec0-659d-4372-b4f1-85a56e6c0992 moved from PoweringDown --> Up 2014-05-19 18:22:45,381 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-53) Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: Shutdown of VM USAROVRTVZ-13 failed.

2 1

power outage: HA vms not restarted
by Yuriy Demchenko 21 May '14

21 May '14

Hi, i'm running ovirt-3.2.2-el6 on 18 el6 hosts with FC san storage, 46 HA vms in 2 datacenters (3 hosts uses different storage with no connectivity to first storage, that's why second DC) Recently (2014-05-17) i had a double power outage: first blackout at 00:16, went back at ~00:19, second blackout at 00:26, went back at 10:06 When finally all went up (after approx. 10:16) - only 2 vms were restarted from 46. From browsing engine log i saw failed restart attemts of almost all vms after first blackout with error 'Failed with error ENGINE and code 5001', but after second blackout i saw no attempts to restart vms, and only error was 'connect timeout' (probably to srv5 - that host physically died after blackouts). And i cant figure why HA vms were not restarted? Please advice engine and (supposedly) spm host logs in attach. -- Yuriy Demchenko

3 14

oVirt 3.5.0 Alpha postponed due to blocker
by Sandro Bonazzola 21 May '14

21 May '14

Hi, We're postponing oVirt 3.5.0 Alpha release due to the following blocker bug discovered while running basic sanity tests: Bug 1098539 - failed to create VM if no NUMA set is specified On a clean install no VM can be created. New tentative release date for 3.5.0 Alpha is 2014-05-20. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

4 9

[ANN] oVirt 3.5.0 Alpha is now available for testing
by Sandro Bonazzola 20 May '14

20 May '14

The oVirt team is pleased to announce that the 3.5.0 Alpha is now available for testing. Feel free to join us testing it! You'll find all needed info for installing it on the release notes page, already available on the wiki [1]. A new oVirt Node build will be available soon as well. Please note that mirrors will need a couple of days before being synchronized: they currently have the first build we prepared on 2014-05-16. If you want to be sure to use latest rpms and don't want to wait for the mirrors, you can edit /etc/yum.repos.d/ovirt-3.5.repo commenting the mirror line and removing the comment on baseurl line. Known Issues VDSM packages released with the first 3.5.0 alpha have version lower than the ones we had in 3.4.1 so they won't be updated. You can't add hosts to 3.5 clusters until a new VDSM build with 3.5 compatibility level will be released (All in One won't work). [1] http://www.ovirt.org/OVirt_3.5_Release_Notes -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Template creation, Network overhead?
by Daniel Helgenberger 20 May '14

20 May '14

--=-agOw3I86inzrd9sXeocZ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Greetings, I have a question concerning the template creation process. I am creating a template from a windows server with a 1TB thin prov. boot disk; about 9GB of witch is actually used. The Data Storage Domain copied from and to is a the same NFS domain. It seems to me after the initial write process the whole 1TB of zeros is read back by the SPM? I can confirm my storage appliance is running on 100% network interface speed with almost zero Disk IO.=20 Also, sampling done on the SPM with iftop reveals reading (RX) from my storage appliance on interface speed (I watched it go up to 75GB right now). Is this normal behavior? Is there a way to cancel the template creation? Thanks, --=20 Daniel Helgenberger=20 m box bewegtbild GmbH=20 P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19=20 D-10115 BERLIN=20 www.m-box.de www.monkeymen.tv=20 Gesch=C3=A4ftsf=C3=BChrer: Martin Retschitzegger / Michaela G=C3=B6llner Handeslregister: Amtsgericht Charlottenburg / HRB 112767=20 --=-agOw3I86inzrd9sXeocZ Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINtjCCBBYw ggL+oAMCAQICCwQAAAAAAS9O4S9SMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcNMTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwWtB+TXs+BJ9 3SJRaV+3uRNGJ3cUO+MTgW8+5HQXfgy19CzkDI1T1NwwICi/bo4R/mYR5FEWx91//eE0ElC/89iY 7GkL0tDasmVx4TOXnrqrsziUcxEPPqHRE8x4NhtBK7+8o0nsMIJMA1gyZ2FA5To2Ew1BBuvovvDJ +Nua3qOCNBNu+8A+eNpJlVnlu/qB7+XWaPXtUMlsIikxD+gREFVUgYE4VzBuLa2kkg0VLd09XkE2 ceRDm6YgRATuDk6ogUyX4OLxCGIJF8yi6Z37M0wemDA6Uff0EuqdwDQd5HwG/rernUjt1grLdAxq 8BwywRRg0eFHmE+ShhpyO3Fi+wIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBQ/FdJtfC/nMZ5DCgaolGwsO8XuZTBHBgNVHSAEQDA+MDwGBFUd IAAwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAfBgNV HSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAQ3N5zKTMSTED HGFAgd/gu91Kb8AxPHgjq+7dhf7mkCinMqqrLai2XOrz8CP63BPaAx7oGOUBI0MyASBGk5zej9L3 oHtiF2BL01m1sBnT8rQxT2CJd/+jqjUl0p2ew8T3HSyatrsooGvDwf00yCB2JHTNvtQxNO8t6x/+ 048A1Q+0i7uf0nTnyrJLjD04zhL89ytetZspltOpJVYbmwiFjq6PxsdUNthUDme/9pOLmKDnQU0p W/JEwLs2TYCBNKwdgSGAk8/z+s2SCltKIG0Uh5U6t6j7JPuwNP/znImwMrlHDJ1YpW0rkF2PGraV CgDBf9dOB+IIpnwHfIi+LD+eITCCBMowggOyoAMCAQICEQCWaWbA3qWpL+Qmn6I16DynMA0GCSqG SIb3DQEBBQUAMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYD VQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAyIENBIC0gRzIwHhcNMTMwODI3MTY1NzU4WhcN MTYwODI3MTY1NzU4WjBYMQswCQYDVQQGEwJERTEcMBoGA1UEAxMTRGFuaWVsIEhlbGdlbmJlcmdl cjErMCkGCSqGSIb3DQEJARYcZGFuaWVsLmhlbGdlbmJlcmdlckBtLWJveC5kZTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAM4BQ5vPknk1OGLd1qKSUIKmQLrjccjJcYj7qtAtA+fNYKF8 9p1VY4UwiFcF9jKlmA9Q8o8tYSx16LYYFoGWokNRAeKFXZiBZiHyI0ekpEfxo8N5cTMCcxKcSYWV 8sqzmBPCoMNpmiVoC8ec8Nv5SqXH34VVtDmNLfiVlsTyomBXAJkJ2/n5XqJzPLFGWWREtPLkVVS+ u426vt/hNsQi5akNoidYeXo98JcrmeApFJ3zB2KxvMziHx8LD4q1gAl9NumtX5YLbCpdWL9AkWdX Oaro3D9zj6Q6LyGwa/UQUrZdg3BXc07hjHZn6d9vet1SzpbyqQpTzM63yXiX1meEMlMCAwEAAaOC AZEwggGNMA4GA1UdDwEB/wQEAwIFoDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUF BwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAnBgNVHREEIDAegRxk YW5pZWwuaGVsZ2VuYmVyZ2VyQG0tYm94LmRlMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20v Z3MvZ3NwZXJzb25hbHNpZ24yZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0 cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24yZzIuY3J0MB0G A1UdDgQWBBS8NFA/upd+Wipw2nj8RD/Ct+R2GTAfBgNVHSMEGDAWgBQ/FdJtfC/nMZ5DCgaolGws O8XuZTANBgkqhkiG9w0BAQUFAAOCAQEAXVTpu4fhOLETAW0zdbQiIwBIMZgeVNJnWV3GsMxByycU 63P+WBQTBl9qj47vHLmVdeF7MzH0QSXZSc9Tnfr6CYIImpyIZxRAGpAsWmtZf3JieRA0+j4GQJF2 zAea1NXYXoG9+ZSSZHBSxKUdrRdVdE320nuVGTT2HjEI2LEYbOvaXyi6HhpuHUiyu4LD0+RIT3fi T8jUiKKLTsApTD+Ak8SLF0IESOSA6htirv69mDDC7Klg9dT7QBPO7dpoKIUOldV3VhahndVfsDff KD7pkUUvG5XftYEQOxlWDJzuTBeqf/4hxXMtzFU9OaI6oKJjLfr6B+XBc6xwOtc/NMWmejCCBMow ggOyoAMCAQICEQCWaWbA3qWpL+Qmn6I16DynMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFs U2lnbiAyIENBIC0gRzIwHhcNMTMwODI3MTY1NzU4WhcNMTYwODI3MTY1NzU4WjBYMQswCQYDVQQG EwJERTEcMBoGA1UEAxMTRGFuaWVsIEhlbGdlbmJlcmdlcjErMCkGCSqGSIb3DQEJARYcZGFuaWVs LmhlbGdlbmJlcmdlckBtLWJveC5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM4B Q5vPknk1OGLd1qKSUIKmQLrjccjJcYj7qtAtA+fNYKF89p1VY4UwiFcF9jKlmA9Q8o8tYSx16LYY FoGWokNRAeKFXZiBZiHyI0ekpEfxo8N5cTMCcxKcSYWV8sqzmBPCoMNpmiVoC8ec8Nv5SqXH34VV tDmNLfiVlsTyomBXAJkJ2/n5XqJzPLFGWWREtPLkVVS+u426vt/hNsQi5akNoidYeXo98JcrmeAp FJ3zB2KxvMziHx8LD4q1gAl9NumtX5YLbCpdWL9AkWdXOaro3D9zj6Q6LyGwa/UQUrZdg3BXc07h jHZn6d9vet1SzpbyqQpTzM63yXiX1meEMlMCAwEAAaOCAZEwggGNMA4GA1UdDwEB/wQEAwIFoDBM BgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxz aWduLmNvbS9yZXBvc2l0b3J5LzAnBgNVHREEIDAegRxkYW5pZWwuaGVsZ2VuYmVyZ2VyQG0tYm94 LmRlMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3NwZXJzb25hbHNpZ24yZzIuY3Js MFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNv bS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24yZzIuY3J0MB0GA1UdDgQWBBS8NFA/upd+Wipw2nj8RD/C t+R2GTAfBgNVHSMEGDAWgBQ/FdJtfC/nMZ5DCgaolGwsO8XuZTANBgkqhkiG9w0BAQUFAAOCAQEA XVTpu4fhOLETAW0zdbQiIwBIMZgeVNJnWV3GsMxByycU63P+WBQTBl9qj47vHLmVdeF7MzH0QSXZ Sc9Tnfr6CYIImpyIZxRAGpAsWmtZf3JieRA0+j4GQJF2zAea1NXYXoG9+ZSSZHBSxKUdrRdVdE32 0nuVGTT2HjEI2LEYbOvaXyi6HhpuHUiyu4LD0+RIT3fiT8jUiKKLTsApTD+Ak8SLF0IESOSA6hti rv69mDDC7Klg9dT7QBPO7dpoKIUOldV3VhahndVfsDffKD7pkUUvG5XftYEQOxlWDJzuTBeqf/4h xXMtzFU9OaI6oKJjLfr6B+XBc6xwOtc/NMWmejGCAucwggLjAgEBMGkwVDELMAkGA1UEBhMCQkUx GTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29uYWxT aWduIDIgQ0EgLSBHMgIRAJZpZsDepakv5CafojXoPKcwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNTIwMTUwOTQ0WjAjBgkqhkiG9w0B CQQxFgQUNWjXzdu5kxQA+V8TcJ7IWENcYmAweAYJKwYBBAGCNxAEMWswaTBUMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMiBDQSAtIEcyAhEAlmlmwN6lqS/kJp+iNeg8pzB6BgsqhkiG9w0BCRACCzFroGkwVDEL MAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNp Z24gUGVyc29uYWxTaWduIDIgQ0EgLSBHMgIRAJZpZsDepakv5CafojXoPKcwDQYJKoZIhvcNAQEB BQAEggEAFf/QaKOowfKPmwjHyepYzcL3LfhqGHS8h8t4LjH3fnIqFbUfD2ALKbq1kHFlN2HErsXD Rvc7Gz7BrUY2Ngiv4Nqltv6825zgtxnjz7aII8j+tw8/5hiDBM6yHMQPysAiAwVpxx1/UwrIzKrL fUBFBTTq/Y7kH0qLsdmFPb5yt1WiHNfpFAYvr9BQFqzua9to6Qjtl4yaUakXq0PZFABrzJr71wmk wzGeHH91TRdajC3JId2xwz+ys5zmpJFTmhjBQzpvJUQentHu8R3jdAsvSUALnmkeSO81alU6+ZgB fvEv/R9ARNfnqy2Nhelg/9J2XL4F9943ouj4cp+yE7divgAAAAAAAA== --=-agOw3I86inzrd9sXeocZ--

1 0

Windows 7 guest not synchronize sound on ovirt 3.5
by Felipe Herrera Martinez 20 May '14

20 May '14

Hi all, We are experiencing a problem when accessing Windows 7 guest over virt-viewer client... although I increase/decrease the volume on Windows guest speaker... it remains always at the same level... Seems that there is no synchronization with the Client. Andy clue about the problem? and if it's a known one? BRgds, F.

2 1

Migrate between 3.3.4 and 3.4.1
by Peter Harris 20 May '14

20 May '14

I am trying to migrate my VMs from my old host running ovirt 3.3.4 to a new setup running 3.4.1. My basic set up is: OLD vmhost1 - ovirt 3.3.4 - NFS storages NEW ovirtmgr - ovirt 3.4.1 (virt only setup) - gluster storage domains vmhost2 - cluster1 vmhost3 - cluster2 vmhost4 - cluster2 vmhost5 - cluster3 vmhost6 - cluster3 My gluster volumes are created via gluster command line and I have All hosts are running scientific Linux 6.5, and the intention is to migrate vmhost1 to new environment cluster1. I have an NFS export storage domain which I am using to migrate VMs from vmhost1. Volume Name: vol-vminf Type: Distributed-Replicate Volume ID: b0b456bb-76e9-42e7-bb95-3415db79d631 Status: Started Number of Bricks: 2 x 2 = 4 Transport-type: tcp Bricks: Brick1: vmhost3:/storage/inf/br-inf Brick2: vmhost4:/storage/inf/br-inf Brick3: vmhost5:/storage/inf/br-inf Brick4: vmhost6:/storage/inf/br-inf Options Reconfigured: storage.owner-gid: 36 storage.owner-uid: 36 server.allow-insecure: on Volume Name: vol-vmimages Type: Distribute Volume ID: 91e2cf8b-2662-4c26-b937-84b8f5b62e2b Status: Started Number of Bricks: 4 Transport-type: tcp Bricks: Brick1: vmhost3:/storage/vmimages/br-vmimages Brick2: vmhost3:/storage/vmimages/br-vmimages Brick3: vmhost3:/storage/vmimages/br-vmimages Brick4: vmhost3:/storage/vmimages/br-vmimages Options Reconfigured: storage.owner-gid: 36 storage.owner-uid: 36 server.allow-insecure: on I have had many varying fail results which I have tried to match up with threads here, and I am now a bit stuck and would appreciate any help. I quite regularly cannot import vms, and I now cannot create a new disk for a new VM (no import). The error always seems to boild down to the following error on engine.log (the following specifically for the create of a new disk image on a gluster storage domain): 2014-05-20 08:51:21,136 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp--127.0.0.1-8702-9) [4637af09] Correlation ID: 2b0b55ab, Job ID: 1a583643-e28a-4f09-a39d-46e4fc6d20b8, Call Stack: null, Custom Event ID: -1, Message: Add-Disk operation of rhel-7_Disk1 was initiated on VM rhel-7 by peter.harris. 2014-05-20 08:51:21,137 INFO [org.ovirt.engine.core.bll.SPMAsyncTask] (ajp--127.0.0.1-8702-9) [4637af09] BaseAsyncTask::startPollingTask: Starting to poll task 720b4d92-1425-478c-8351-4ff827b8f728. 2014-05-20 08:51:28,077 INFO [org.ovirt.engine.core.bll.AsyncTaskManager] (DefaultQuartzScheduler_Worker-19) Polling and updating Async Tasks: 1 tasks, 1 tasks to poll now 2014-05-20 08:51:28,084 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand] (DefaultQuartzScheduler_Worker-19) Failed in HSMGetAllTasksStatusesVDS method 2014-05-20 08:51:28,085 INFO [org.ovirt.engine.core.bll.SPMAsyncTask] (DefaultQuartzScheduler_Worker-19) SPMAsyncTask::PollTask: Polling task 720b4d92-1425-478c-8351-4ff827b8f728 (Parent Command AddDisk, Parameters Type org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters) returned status finished, result 'cleanSuccess'. 2014-05-20 08:51:28,104 ERROR [org.ovirt.engine.core.bll.SPMAsyncTask] (DefaultQuartzScheduler_Worker-19) BaseAsyncTask::LogEndTaskFailure: Task 720b4d92-1425-478c-8351-4ff827b8f728 (Parent Command AddDisk, Parameters Type org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters) ended with failure:^M -- Result: cleanSuccess^M -- Message: VDSGenericException: VDSErrorException: Failed to HSMGetAllTasksStatusesVDS, error = [Errno 2] No such file or directory: '/rhev/data-center/06930787-a091-49a3-8217-1418c5a9881e/967aec77-46d5-418b-8979-d0a86389a77b/images/7726b997-7e58-45f8-a5a6-9cb9a689a45a', code = 100,^M -- Exception: VDSGenericException: VDSErrorException: Failed to HSMGetAllTasksStatusesVDS, error = [Errno 2] No such file or directory: '/rhev/data-center/06930787-a091-49a3-8217-1418c5a9881e/967aec77-46d5-418b-8979-d0a86389a77b/images/7726b997-7e58-45f8-a5a6-9cb9a689a45a', code = 100 Certainly, if I check /rhev/data-center/06930787-a091-49a3-8217-1418c5a9881e/ on the SPM server, there is no 967aec77-46d5-418b-8979-d0a86389a77b subdirectory. The only elements I have are NFS mounts. There appear to be no errors in the SPM vdsm.log for this disk ============= When I tried to import the vm (the one that I then tried to create from scratch above), I had the following errors in the SPM vdsm log: Thread-2220::DEBUG::2014-05-20 08:35:05,255::task::595::TaskManager.Task::(_updateState) Task=`15bc07b5-201f-4bba-bf5f-f79eb92c6a61`::moving from state init -> state preparing Thread-2220::INFO::2014-05-20 08:35:05,255::logUtils::44::dispatcher::(wrapper) Run and protect: deleteImage(sdUUID='615647e2-1f60-47e1-8e55-be9f7ead6f15', spUUID='06930787-a091-49a3-8217-1418c5a9881e', imgUUID='80ed133c-fd72-4d35-aae5-e1313be3cf23', postZero='false', force='false') Thread-2220::DEBUG::2014-05-20 08:35:05,255::resourceManager::198::ResourceManager.Request::(__init__) ResName=`Storage.80ed133c-fd72-4d35-aae5-e1313be3cf23`ReqID=`499de454-c563-4156-a3ed-13b7eb9defa6`::Request was made in '/usr/share/vdsm/storage/hsm.py' line '1496' at 'deleteImage' Thread-2220::DEBUG::2014-05-20 08:35:05,255::resourceManager::542::ResourceManager::(registerResource) Trying to register resource 'Storage.80ed133c-fd72-4d35-aae5-e1313be3cf23' for lock type 'exclusive' Thread-2220::DEBUG::2014-05-20 08:35:05,255::resourceManager::601::ResourceManager::(registerResource) Resource 'Storage.80ed133c-fd72-4d35-aae5-e1313be3cf23' is free. Now locking as 'exclusive' (1 active user) Thread-2220::DEBUG::2014-05-20 08:35:05,256::resourceManager::238::ResourceManager.Request::(grant) ResName=`Storage.80ed133c-fd72-4d35-aae5-e1313be3cf23`ReqID=`499de454-c563-4156-a3ed-13b7eb9defa6`::Granted request Thread-2220::DEBUG::2014-05-20 08:35:05,256::task::827::TaskManager.Task::(resourceAcquired) Task=`15bc07b5-201f-4bba-bf5f-f79eb92c6a61`::_resourcesAcquired: Storage.80ed133c-fd72-4d35-aae5-e1313be3cf23 (exclusive) Thread-2220::DEBUG::2014-05-20 08:35:05,256::task::990::TaskManager.Task::(_decref) Task=`15bc07b5-201f-4bba-bf5f-f79eb92c6a61`::ref 1 aborting False Thread-2220::DEBUG::2014-05-20 08:35:05,256::resourceManager::198::ResourceManager.Request::(__init__) ResName=`Storage.615647e2-1f60-47e1-8e55-be9f7ead6f15`ReqID=`73f79517-f13a-4e5b-999a-6f1994d2818a`::Request was made in '/usr/share/vdsm/storage/hsm.py' line '1497' at 'deleteImage' Thread-2220::DEBUG::2014-05-20 08:35:05,256::resourceManager::542::ResourceManager::(registerResource) Trying to register resource 'Storage.615647e2-1f60-47e1-8e55-be9f7ead6f15' for lock type 'shared' Thread-2220::DEBUG::2014-05-20 08:35:05,257::resourceManager::601::ResourceManager::(registerResource) Resource 'Storage.615647e2-1f60-47e1-8e55-be9f7ead6f15' is free. Now locking as 'shared' (1 active user) Thread-2220::DEBUG::2014-05-20 08:35:05,257::resourceManager::238::ResourceManager.Request::(grant) ResName=`Storage.615647e2-1f60-47e1-8e55-be9f7ead6f15`ReqID=`73f79517-f13a-4e5b-999a-6f1994d2818a`::Granted request Thread-2220::DEBUG::2014-05-20 08:35:05,257::task::827::TaskManager.Task::(resourceAcquired) Task=`15bc07b5-201f-4bba-bf5f-f79eb92c6a61`::_resourcesAcquired: Storage.615647e2-1f60-47e1-8e55-be9f7ead6f15 (shared) Thread-2220::DEBUG::2014-05-20 08:35:05,257::task::990::TaskManager.Task::(_decref) Task=`15bc07b5-201f-4bba-bf5f-f79eb92c6a61`::ref 1 aborting False Thread-2220::ERROR::2014-05-20 08:35:05,266::hsm::1502::Storage.HSM::(deleteImage) Empty or not found image 80ed133c-fd72-4d35-aae5-e1313be3cf23 in SD 615647e2-1f60-47e1-8e55-be9f7ead6f15. {'1f41529a-e02e-4cd8-987c-b1ea4fcba2be': ImgsPar(imgs=('290f5cdf-b5d7-462b-958d-d41458a26bf6',), parent=None), '1748a8f0-8668-4f21-9b26-d2e3b180e35b': ImgsPar(imgs=('67fd552b-8b3d-4117-82d2-e801bb600992',), parent=None)} Thread-2220::ERROR::2014-05-20 08:35:05,266::task::866::TaskManager.Task::(_setError) Task=`15bc07b5-201f-4bba-bf5f-f79eb92c6a61`::Unexpected error When I installed/setup ovirt-engine, I did chose NFS as the file system. I am clearly doing something weird

3 3

Call for Papers Deadline in 1 week: OSCON Open Cloud Day
by Brian Proffitt 20 May '14

20 May '14

Conference: OSCON Open Cloud Day Information: The Open Cloud Day at OSCON is a look at the “state of cloud” in 2014, gathering industry practitioners to give their take on the state of public and private cloud, IaaS, and PaaS platforms, and where the industry is going in 2014 and beyond. Date: July 21, 2014 Location: Portland, OR Call for Papers Deadline: May 27, 2014 Call for Papers URL: http://www.oscon.com/oscon2014/public/cfp/337 -- Brian Proffitt oVirt Community Manager Project Atomic Community Lead Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC

1 0

Call for Papers Deadline in 10 days: PostgresOpen 2014
by Brian Proffitt 20 May '14

20 May '14

Conference: PostgresOpen 2014 Information: PostgresOpen 2014 will be held on September 17 - 19th in Chicago at the Hotel Sax. It will cover topics for PostgreSQL users, developers and contributors, as well as decision and policy makers. Date: Sept 17-19, 2014 Location: Chicago, IL Website: https://postgresopen.org/2014/ Call for Papers Deadline: May 30, 2014 Call for Papers URL: https://postgresopen.org/2014/callforpapers/ -- Brian Proffitt oVirt Community Manager Project Atomic Community Lead Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC

1 0

Call for Papers Deadline on Sunday: DevOps Enterprise Summit
by Brian Proffitt 20 May '14

20 May '14

Conference: DevOps Enterprise Summit Information: DevOps Enterprise will assemble some of the best practitioners and leaders in the DevOps space, who are transforming how software and services are delivered in large, complex organizations Date: Oct 21-23, 2014 Location: San Francisco Bay Area, CA Website: http://devopsenterprisesummit.com/ Call for Papers Deadline: May 25, 2014 Call for Papers URL: https://docs.google.com/a/proffitt.org/forms/d/13-4lAYwcUmNeIS5tLRK0hshHVh5… -- Brian Proffitt oVirt Community Manager Project Atomic Community Lead Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC

1 0

[Users] ovirt reports
by Alessandro Bianchi 20 May '14

20 May '14

3 6

Migrate to Hosted Engine - problem with doc/web page
by Bob Doolittle 20 May '14

20 May '14

Hi, I'm trying to follow the instructions here: http://www.ovirt.org/Migrate_to_Hosted_Engine I've shut down my original engine and completed engine-backup. I've completed hosted-engine --deploy to the point where my new engine VM is up and running, and I've installed the 3.4-stable version of engine-install on it. Now I want to restore the backup on my new engine. However, at this point the instructions/how-to suddenly introduces a new host name "didi-lap" which was not mentioned previously: > engine-backup --mode=restore --file=backup1 --log=backup1-restore.log --change-db-credentials --db-host=didi-lap --db-user=engine --db-password --db-name=engine The only entities introduced in this How-To are: ovirttest.home.local The DNS CNAME record of the Engine (before and after migration) my-engine.home.local The underlying hostname of the original engine didi-box1.home.local The new machine which will run self-hosted engine I am not sure what (if anything) I should supply for db-host. In my original setup, my engine had the db locally (I presume - whatever the default was). In my new setup, my engine will have the same name as it did in the old setup (it was a VM previously, I took it down). Do I even need to specify the db-host or change-db-credentials arguments? Do these instructions require that the database was originally stored on an external entity (didi-lap) and that the database still resides there? Or does it backup/restore the database entirely? Thanks, Bob

3 3

Ovirt Reports
by MohyedeenN 20 May '14

20 May '14

Guys, Is there as specific email list for Ovirt Reports ? Thanks,

4 3

Fedora 20 and virt-preview
by Markus Stockhausen 20 May '14

20 May '14

------=_NextPartTM-000-e525b375-0565-47a3-961e-7b2ef4e0245f Content-Type: multipart/alternative; boundary="_000_12EF8D94C6F8734FB2FF37B9FBEDD173586237C3EXCHANGEcollogi_" --_000_12EF8D94C6F8734FB2FF37B9FBEDD173586237C3EXCHANGEcollogi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, just wanted to know if enabling virt-preview repo on a FC20 hypervisor node may break Ovirt 3.4.1. Especially the incompatible changes mentioned here: http://wiki.qemu.org/ChangeLog/2.0#Incompatible_changes FC20 stock: qemu 1.6.2 FC20 virt-previe: qemu 2.0.0 Best regards. Markus --_000_12EF8D94C6F8734FB2FF37B9FBEDD173586237C3EXCHANGEcollogi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" id=3D"owaParaStyle"></style> </head> <body fpstyle=3D"1" ocsi=3D"0"> <div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: = 10pt;">Hello, <div><br> </div> <div>just wanted to know if enabling virt-preview repo on a </div> <div><span style=3D"font-size: 10pt;">FC20 </span><span style=3D"font-= size: 10pt;">hypervisor node may break Ovirt 3.4.1. Especially </span>= </div> <div><span style=3D"font-size: 10pt;">the </span><span style=3D"font-s= ize: 10pt;">incompatible changes mentioned here:</span></div> <div><br> </div> <div>http://wiki.qemu.org/ChangeLog/2.0#Incompatible_changes</div> <div><span style=3D"font-size: 10pt;"><br> </span></div> <div><span style=3D"font-size: 10pt;">FC20 stock: qemu 1.6.2</span></div> <div><span style=3D"font-size: 10pt;">FC20 virt-previe: qemu 2.0.0</span></= div> <div><span style=3D"font-size: 10pt;"><br> </span></div> <div><span style=3D"font-size: 10pt;">Best regards.</span></div> <div><span style=3D"font-size: 10pt;"><br> </span></div> <div><span style=3D"font-size: 10pt;">Markus</span></div> <div><span style=3D"font-size: 10pt;"><br> </span></div> </div> </body> </html> --_000_12EF8D94C6F8734FB2FF37B9FBEDD173586237C3EXCHANGEcollogi_-- ------=_NextPartTM-000-e525b375-0565-47a3-961e-7b2ef4e0245f Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" **************************************************************************** Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Über das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 **************************************************************************** ------=_NextPartTM-000-e525b375-0565-47a3-961e-7b2ef4e0245f--

1 0

Fedora 20 as hypervisor
by Markus Stockhausen 19 May '14

19 May '14

------=_NextPartTM-000-8b54e83c-61bf-42dc-b36f-f03b61cda223 Content-Type: multipart/alternative; boundary="_000_12EF8D94C6F8734FB2FF37B9FBEDD1735861E5DAEXCHANGEcollogi_" --_000_12EF8D94C6F8734FB2FF37B9FBEDD1735861E5DAEXCHANGEcollogi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, did not find any discussion thread about this topic. Is Fedora 20 already fully "supported" as hypervisor host for OVirt 3.4 environments? Thanks. Markus --_000_12EF8D94C6F8734FB2FF37B9FBEDD1735861E5DAEXCHANGEcollogi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style id=3D"owaParaStyle" type=3D"text/css">P {margin-top:0;margin-bottom:= 0;}</style> </head> <body ocsi=3D"0" fpstyle=3D"1"> <div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: = 10pt;">Hello,<br> <br> did not find any discussion thread about this topic. <br> Is Fedora 20 already fully "supported" as hypervisor<br> host for OVirt 3.4 environments?<br> <br> Thanks.<br> <br> Markus<br> </div> </body> </html> --_000_12EF8D94C6F8734FB2FF37B9FBEDD1735861E5DAEXCHANGEcollogi_-- ------=_NextPartTM-000-8b54e83c-61bf-42dc-b36f-f03b61cda223 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" **************************************************************************** Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Über das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 **************************************************************************** ------=_NextPartTM-000-8b54e83c-61bf-42dc-b36f-f03b61cda223--

6 9