Bug 1464214 - Snapshot remains locked after failed live merge
Snapshot remains locked after failed live merge
Status: CLOSED DUPLICATE of bug 1464218
Product: ovirt-engine
Classification: oVirt
Component: BLL.Storage (Show other bugs)
4.1.3
Unspecified Unspecified
unspecified Severity high (vote)
: ---
: ---
Assigned To: Allon Mureinik
Raz Tamir
storage
:
: 1464213 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-22 12:34 EDT by Kevin Alon Goldblatt
Modified: 2017-06-25 07:33 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-25 07:33:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Kevin Alon Goldblatt 2017-06-22 12:34:05 EDT
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 12:36 EDT
Created attachment 1290772 [details]
server, engine, vdsm logs

Adding logs
Comment 2 Allon Mureinik 2017-06-25 04:39:55 EDT
*** Bug 1464213 has been marked as a duplicate of this bug. ***
Comment 3 Allon Mureinik 2017-06-25 04:48:30 EDT
Kevin, is there any difference between this bug and 1464218 besides the versions used?
Comment 4 Kevin Alon Goldblatt 2017-06-25 04:58:39 EDT
(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 05:00:10 EDT
(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 07:33:52 EDT
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.