Bug 1254925

Summary: Snapshot merge leaves a forever running task
Product: [Retired] oVirt Reporter: Dima Kuznetsov <dkuznets>
Component: ovirt-engine-coreAssignee: Greg Padgett <gpadgett>
Status: CLOSED CURRENTRELEASE QA Contact: Aharon Canan <acanan>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.6CC: amureini, bugs, ecohen, gklein, gpadgett, lsurette, miersma, oourfali, rbalakri, yeylon, ylavi
Target Milestone: m1   
Target Release: 3.6.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: storage
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-09-07 15:09:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Logs from a setup exhibiting the problem
none
Engine.log
none
output of virsh -r, corresponding to the above engine log. none

Description Dima Kuznetsov 2015-08-19 09:09:51 UTC
Created attachment 1064692 [details]
Logs from a setup exhibiting the problem

Description of problem:
Removing a snapshot of a VM succeeds, but after everything is done, there is still a task in the task list 

Version-Release number of selected component (if applicable):
nightly master engine, nightly master vdsm, from 18.08.15


How reproducible:
100%


Steps to Reproduce:
1. Create VM from template (on NFS)
2. Start VM
3. Create 2 snapshots
4. Delete the first one

Actual results:
Snapshot is deleted, all disks active, task running forever


Expected results:
No task after snapshot is done

Additional info:

Comment 1 Allon Mureinik 2015-08-19 09:18:52 UTC
Greg, this looks awfully familiar... Can you take a look please?

Comment 2 Christopher Miersma 2015-08-21 13:49:20 UTC
I had the same problem in the same version, but with iSCSI storage and a VM that I created from scratch, with only one snapshot. Looking at the libvirt xml with virsh -r revealed that the snapshot was created correctly. When deleting, a block-pull job would run properly and the snapshot would merge. However, after the merge was complete in the libvirt xml, the snapshot disk would be left behind in /dev/<uuid>/, and the task would appear to run forever. In one case, the disk space was freed up, and the snapshot data removed, but the task still ran forever.

Comment 3 Christopher Miersma 2015-08-24 20:39:17 UTC
This does indeed appear to be the same issue that happened in 3.5. I tracked down the files and the code that was added in https://github.com/oVirt/ovirt-engine/commit/209ec823a03dd5838eed3d711fd821d2a1aba9dd is missing from 3.6. The symptoms are the same as bug https://bugzilla.redhat.com/1127464, which is now impacting 3.6.

Comment 4 Christopher Miersma 2015-08-25 14:58:55 UTC
My previous comment was incorrect. The code referenced was a deletion, and this carries through. Please disregard.

Comment 5 Christopher Miersma 2015-08-26 14:34:18 UTC
Created attachment 1067279 [details]
Engine.log

I've uploaded a copy of the engine log where this is happening. In this case, a cleanly rebuilt the cluster. I'm using iSCSI storage.
I was able to take snapshots and delete them with the VM off successfully.
I was also able to live move a disk from one domain to another.
The task only had problems when I tried deleting a snapshot with the VM running. In this case, the snapshot was actually deleted, but the interface task ran on. I will attached output from virsh -r showing the libvirt xml before and after, as well as the log.

Comment 6 Christopher Miersma 2015-08-26 14:36:21 UTC
Created attachment 1067280 [details]
output of virsh -r, corresponding to the above engine log.

Comment 7 Christopher Miersma 2015-08-26 14:47:34 UTC
Note. In the most recent case, rebooting the ovirt-engine server cleared the message in the interface. After having this clear once, I was able to create and delete a snapshot successfully with the VM running.

Comment 9 Yaniv Lavi 2015-09-07 15:09:04 UTC
Based on comment #7