+++ This bug was initially created as a clone of Bug #1243102 +++ Description of problem: Creating a snapshot, then deleting a snapshot, on a domain with multiple disks fails to delete internal snapshots on all disks but the first. Version-Release number of selected component (if applicable): qemu-kvm-ev 2.1.2-23.el7_1.3 (and also checked newer version in oVirt 3.6 How reproducible: On domain with multiple qcow2 disks: 1. virsh snapshot-create <domain> 2 .virsh snapshot-delete <domain> <snapshotname> 3. do 'qemu-img info' on all disk files attached to domain, and note that disks still contain qcow2 snapshots. This further causes problems for subsequent snapshot-create Actual results: some qcow2 disks have snapshot Expected results: all qcow2 disks have no snapshot Additional info: This is already fixed in qemu-kvm upstream. Just need to backport the patch and include it. I have backported the patch for my own use, but I'd like to see this fixed upstream so we don't have to maintain it. commit af957387547b05ed6dc4d84c10cca42700a7aeda Author: Zhang Haoyu <zhanghy> Date: Mon Sep 29 16:38:02 2014 +0800 snapshot: fix referencing wrong variable in while loop in do_delvm The while loop variabal is "bs1", but "bs" is always passed to bdrv_snapshot_delete_by_id_or_name. Broken in commit a89d89d, v1.7.0. Signed-off-by: Zhang Haoyu <zhanghy> Reviewed-by: Markus Armbruster <armbru> Signed-off-by: Stefan Hajnoczi <stefanha> --- Additional comment from Fabian Deutsch on 2015-07-15 13:01:00 IDT --- This bug needs to be filed in the qemu or centos tracker, Node is just reusing this build. --- Additional comment from Jan Kurik on 2015-07-15 16:16:31 IDT --- This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23 --- Additional comment from Marcus Sorensen on 2015-07-15 19:05:37 IDT --- Thanks for moving it. Ideally we'd like to see it end up in qemu-kvm-ev-2.1.2-23.el7_1.5 or similar, as built by http://cbs.centos.org/koji/packageinfo?packageID=539. I must say it's a bit confusing trying to find who is responsible for the "ev" packages, I was going to try to submit a patch myself, but the CentOS qemu-kvm(1.5.3) isn't what we're after. --- Additional comment from Sandro Bonazzola on 2015-07-16 10:07:00 IDT --- Hi, I'm the one rebuilding qemu-kvm-ev from qemu-kvm-rhev for CentOS Virt SIG. Moving to qemu-kvm-rhev to let the maintainer know about this issue. --- Additional comment from RHEL Product and Program Management on 2015-07-17 14:37:52 IDT --- Since this bug report was entered in bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release. =============================================================================== Bug #1243102 describes a problem with qemu failing to delete a snapshot. This is solved in upstream qemu and backported to qemu-kvm-rhev in EL. Action items for oVirt: EL: 1. Once qemu-kvm-rhev-2.3.0-13.el7 is released, a new qemu-kvm-ev version should be rebased from it. 2. VDSM should require it Fedora: 1. F23 already rebased its qemu package on top of 2.4.0, which includes the relevant fix - need to wait for its release 2. Once that happens, VDSM should depend on it.
*** Bug 1248391 has been marked as a duplicate of this bug. ***
(In reply to Allon Mureinik from comment #0) > Action items for oVirt: > EL: > 1. Once qemu-kvm-rhev-2.3.0-13.el7 is released, a new qemu-kvm-ev version > should be rebased from it. Sandro - do we need a new BZ for tracking this, or will this one be enough?
Allon this should be enough, keeping the needinfo on me so I'll remember about this. Current available version is qemu-kvm-rhev-2.1.2-23.el7_1.6.src.rpm Have you a schedule for 2.3.0-13 to be released?
(In reply to Sandro Bonazzola from comment #3) > Allon this should be enough, keeping the needinfo on me so I'll remember > about this. Current available version is > qemu-kvm-rhev-2.1.2-23.el7_1.6.src.rpm Have you a schedule for 2.3.0-13 to > be released? It's currently on_qa, I assume it won't be too far away, although I don't have a definite date, unfortunately.
Allon, looks like we won't have 2.3.0-13 before RHEL 7.2 or RHEV 3.6 will be out. I suggest to either move to upstream latest qemu-kvm or workaround the issue in another way or re-target this bug to something like 3.6.4.
(In reply to Sandro Bonazzola from comment #5) > Allon, looks like we won't have 2.3.0-13 before RHEL 7.2 or RHEV 3.6 will be > out. > I suggest to either move to upstream latest qemu-kvm or workaround the issue > in another way or re-target this bug to something like 3.6.4. Moving to qemu-kvm is not an option (we need the -ev bits for live operations). As it seems oVirt 3.6.0 will continue to be based on EL7.1 we should be OK, pushing out. Bronce - we need 3.6.z oVirt target releases in bugzilla for this bug (and probably a bunch of upcoming bugs).
(In reply to Allon Mureinik from comment #6) > (In reply to Sandro Bonazzola from comment #5) > > Allon, looks like we won't have 2.3.0-13 before RHEL 7.2 or RHEV 3.6 will be > > out. > > I suggest to either move to upstream latest qemu-kvm or workaround the issue > > in another way or re-target this bug to something like 3.6.4. > > Moving to qemu-kvm is not an option (we need the -ev bits for live > operations). As it seems oVirt 3.6.0 will continue to be based on EL7.1 we > should be OK, pushing out. > > Bronce - we need 3.6.z oVirt target releases in bugzilla for this bug (and > probably a bunch of upcoming bugs). Would this item need to be moved to the oVirt classification for vdsm? I made sure there was a target release there for 3.6 & 3.6.1. I can request that the bz team also create that 3.6.1 TR here as well, just in case.
(In reply to Bronce McClain from comment #7) > (In reply to Allon Mureinik from comment #6) > > (In reply to Sandro Bonazzola from comment #5) > > > Allon, looks like we won't have 2.3.0-13 before RHEL 7.2 or RHEV 3.6 will be > > > out. > > > I suggest to either move to upstream latest qemu-kvm or workaround the issue > > > in another way or re-target this bug to something like 3.6.4. > > > > Moving to qemu-kvm is not an option (we need the -ev bits for live > > operations). As it seems oVirt 3.6.0 will continue to be based on EL7.1 we > > should be OK, pushing out. > > > > Bronce - we need 3.6.z oVirt target releases in bugzilla for this bug (and > > probably a bunch of upcoming bugs). > > Would this item need to be moved to the oVirt classification for vdsm? I > made sure there was a target release there for 3.6 & 3.6.1. > > I can request that the bz team also create that 3.6.1 TR here as well, just > in case. No need in having it in two places, IMHO. Can you assist with moving it? I don't seem to have this option.
qemu-kvm-2.3.0 is now in -snapshot-static for all ovirt releases
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
In oVirt testing is done on single release by default. Therefore I'm removing the 4.0 flag. If you think this bug must be tested in 4.0 as well, please re-add the flag. Please note we might not have testing resources to handle the 4.0 clone.
oVirt 3.6.2 RC1 has been released for testing, moving to ON_QA
Versions required in the spec (both for RHEL and Centos, no change for RHEL): qemu-kvm-rhev >= 10:2.3.0-13.el7 qemu-img-rhev >= 10:2.3.0-13.el7
[root@green-vdsc ~]# rpm -q --requires vdsm-4.17.14-0.el7ev.noarch |grep qemu libvirt-daemon-driver-qemu qemu-img-rhev >= 10:2.3.0-31.el7_2.4 qemu-kvm-rhev >= 10:2.3.0-31.el7_2.4