Bug 1464214 - Snapshot remains locked after failed live merge
Summary: Snapshot remains locked after failed live merge
Keywords:
Status: CLOSED DUPLICATE of bug 1464218
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Storage
Version: 4.1.3
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: Allon Mureinik
QA Contact: Raz Tamir
URL:
Whiteboard: storage
: 1464213 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-22 16:34 UTC by Kevin Alon Goldblatt
Modified: 2019-04-28 13:26 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-25 11:33:52 UTC
oVirt Team: Storage
Embargoed:


Attachments (Terms of Use)
server, engine, vdsm logs (582.87 KB, application/x-gzip)
2017-06-22 16:36 UTC, Kevin Alon Goldblatt
no flags Details

Description Kevin Alon Goldblatt 2017-06-22 16:34:05 UTC
Description of problem:
Snapshot remains locked after failed live merge due to restart of vdsm

Version-Release number of selected component (if applicable):

Verified with the following code:
-------------------------------------------------------------
ovirt-engine-4.1.3.4-0.1.el7.noarch
rhevm-4.1.3.4-0.1.el7.noarch
vdsm-4.19.19-1.el7ev.x86_64


How reproducible:
Every time

Verified with the the following scenario:
------------------------------------------------------------
1. Create VM_14 with 5 disks , thin and preallocated, block and nfs
2. Create 3 snapshots, sna1, sna2, sna3
3. Start the snapshot vm22
4. Delete sna2 and a few seconds later restart the vdsm on the host . The delete fails of the snapshot fails and the snapshot sna2 remains in a locked state



Actual results:
The delete fails of the snapshot fails and the snapshot sna2 remains in a locked state


Expected results:
When the vdsm comes up again the snapshot should be in a normal state and allow a retry of the delete


Additional info:

Comment 1 Kevin Alon Goldblatt 2017-06-22 16:36:37 UTC
Created attachment 1290772 [details]
server, engine, vdsm logs

Adding logs

Comment 2 Allon Mureinik 2017-06-25 08:39:55 UTC
*** Bug 1464213 has been marked as a duplicate of this bug. ***

Comment 3 Allon Mureinik 2017-06-25 08:48:30 UTC
Kevin, is there any difference between this bug and 1464218 besides the versions used?

Comment 4 Kevin Alon Goldblatt 2017-06-25 08:58:39 UTC
(In reply to Kevin Alon Goldblatt from comment #0)
> Description of problem:
> Snapshot remains locked after failed live merge due to restart of vdsm
> 
> Version-Release number of selected component (if applicable):
> 
> Verified with the following code:
> -------------------------------------------------------------
> ovirt-engine-4.1.3.4-0.1.el7.noarch
> rhevm-4.1.3.4-0.1.el7.noarch
> vdsm-4.19.19-1.el7ev.x86_64
> 
> 
> How reproducible:
> Every time
> 
> Verified with the the following scenario:
> ------------------------------------------------------------
> 1. Create VM_14 with 5 disks , thin and preallocated, block and nfs
> 2. Create 3 snapshots, sna1, sna2, sna3
> 3. Start VM vm22
> 4. Delete sna2 and a few seconds later restart the vdsm on the host . The
> delete of the snapshot fails and the snapshot sna2 remains in a locked
> state
> 
> 
> 
> Actual results:
> The of the snapshot fails and snapshot sna2 remains in a
> locked state
> 
> 
> Expected results:
> When the vdsm comes up again the snapshot should be in a normal state and
> allow a retry of the delete
> 
> 
> Additional info:

Comment 5 Kevin Alon Goldblatt 2017-06-25 09:00:10 UTC
(In reply to Allon Mureinik from comment #3)
> Kevin, is there any difference between this bug and 1464218 besides the
> versions used?

The same problem happens on both version 4.1.3 and 4.2.
I tested both versions

Comment 6 Tal Nisan 2017-06-25 11:33:52 UTC
In that case I'm targeting the other bug to 4.1.3 and closing this one as a duplicate, when we have a zstream bug we fix it for master as well anyway

*** This bug has been marked as a duplicate of bug 1464218 ***


Note You need to log in before you can comment on or make changes to this bug.