Description of problem: Bug 1203543 - "bdrv_make_zero() passes a too large nb_sectors value to bdrv_write_zeroes()" describes a regression that prevents oVirt from creating a template from a preallocated disc on block storage with some storage servers (the issue was noticed on XtremeIO, we do not currently have data on other storage vendors/drivers that present this problem). Once it is fixed (presumably in qemu-kvm-rhev-2.1.2-23.el7_1_1.2, according to bug 1203543), we need to respin the -ev packages so this fix can be consumed by oVirt on EL. Version-Release number of selected component (if applicable): oVirt 3.5.0 and above How reproducible: 100% consistent on storage servers known to have this issue (currently, only XtremeIO).
Sandro, as discussed on bug 1209034, once bug 1203543 is fixed, we need this fix repackaged asap, even as an async release. I'm not sure what component and target release this should be flagged for, so feel free to change it. Thanks!
moving to 3.5.4 due to capacity planning for 3.5.3. if you believe this should remain in 3.5.3, please sync with pm/dev/qe and a full triple ack for it. also - ensure priority is set accordingly to the bug status.
Re-targeting to 3.5.2 as this must be released async.
Dan, this requires a backport of https://gerrit.ovirt.org/40648, causing an async release of vdsm for 3.5.2 too. Please ack for delivering this in 3.5.2 instead of 3.5.3
Published in ovirt-master-snapshot repo, pending needinfo for backporting to ovirt-3.5-snapshot and ovirt-3.5 repositories.
(In reply to Sandro Bonazzola from comment #4) > Dan, this requires a backport of https://gerrit.ovirt.org/40648, causing an > async release of vdsm for 3.5.2 too. > Please ack for delivering this in 3.5.2 instead of 3.5.3 Why is this required? Because you don't want to include this fix in qemu-kvm-rhev? In any case, I do not mind creating an ovirt-3.5.2 branch and including that caps.py change to it. I've created https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=shortlog;h=refs%2Fheads%2Fovirt-3.5.2 on top of a fairly-important fix to a memory leak in el6.
In 3.5.2 we're delivering qemu-img-rhev-1.5.3-86.el7.1. The request here is to bump to qemu-kvm-common-ev-2.1.2-23.el7_1.2 We don't have a -rhev package for 2.*, only -ev ones.
(In reply to Dan Kenigsberg from comment #6) > (In reply to Sandro Bonazzola from comment #4) > > Dan, this requires a backport of https://gerrit.ovirt.org/40648, causing an > > async release of vdsm for 3.5.2 too. > > Please ack for delivering this in 3.5.2 instead of 3.5.3 > > Why is this required? Because you don't want to include this fix in > qemu-kvm-rhev? Because we don't want to have upstream EL builds relying on Red Hat (-RHev) branded rpms. > > In any case, I do not mind creating an ovirt-3.5.2 branch and including that > caps.py change to it. I've created > https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=shortlog;h=refs%2Fheads%2Fovirt- > 3.5.2 on top of a fairly-important fix to a memory leak in el6. Nice one, thanks!
Re-targeted to 3.5.3.
Verified on vt15.1 qemu version: qemu-kvm-rhev-2.1.2-23.el7_1.3.x86_64 includes the fix. for more info: bz #1220333 bz #1221192
This is an automated message. oVirt 3.5.3 has been released on June 15th 2015 and should include the fix for this BZ. Moving to closed current release.