Bug 891052 - 3.1.z Error deleting VM disk
Summary: 3.1.z Error deleting VM disk
Keywords:
Status: CLOSED DUPLICATE of bug 884635
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.1.1
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 3.2.0
Assignee: Maor
QA Contact: Dafna Ron
URL:
Whiteboard: storage
Depends On: 885489 891053 891054
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-01 12:42 UTC by Ayal Baron
Modified: 2016-02-10 18:50 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 885489
Environment:
Last Closed: 2013-01-31 15:08:50 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
logs (297.41 KB, application/x-gzip)
2013-01-28 13:23 UTC, Dafna Ron
no flags Details

Comment 2 Dafna Ron 2013-01-28 13:22:57 UTC
tested on vdsm-4.10.2-1.2.el6.x86_64 with si26.1 engine build. 

since there seemed to be a change in the remove vm behaviour in engine and vdsm (it rolled forward on delete even if the image failed to be deleted in vdsm - role reversal) I decided to reproduce this by manually removing the vm's image in vds so that it will be removed in vds but still exist in engine db. 

vdsm is returning image does not exit and engine fails the delete. 

moving back to devel.

Comment 3 Dafna Ron 2013-01-28 13:23:35 UTC
Created attachment 688974 [details]
logs

Comment 5 Maor 2013-01-30 12:11:57 UTC
It should not be a regression in the engine.
IIRC the behaviour in 3.0 was that if the first task was not able to be initiated, we fail the operation.
(BTW that might happen not only for image does not exists, but in every operation that will cause the VDSM to throw an exception on create task scenario.)

The purpose of this was to avoid leaving the VM at image lock forever.
The fix for image does not exists should be solved in BZ884635.

Comment 6 Yeela Kaplan 2013-01-30 14:25:24 UTC
There is no reason to reopen the bug.
This is a different issue.

In this case, the image is no longer available for vdsm, as expected.
The engine behavior should be decided and changed to recognize this exception and remove the vm if its image does not exist.

Comment 9 Dafna Ron 2013-01-30 14:57:05 UTC
1. no where in this bug is image locked mentioned. 
2. the issue described in this bug is that we cannot remove a vm that its image was removed from vdsm but not removed in engine (regardless of the reason). 
3. since engine changed behaviour to roll forward regardless of vdsm success or failure to remove the image (which is already discussed and agreed as a wrong behaviour) the only way to test this issue is to remove the image manually from the storage and leave it in engine.

so either this bug is blocked by engine's new behaviour or its not solved at all since if the image does not exist any more in storage but exist in db we cannot remove a vm.

Comment 10 Maor 2013-01-30 18:50:20 UTC
(In reply to comment #9)
> 1. no where in this bug is image locked mentioned. 
image locked was the mentioned since it is the reason why this behaviour occur
> 2. the issue described in this bug is that we cannot remove a vm that its
> image was removed from vdsm but not removed in engine (regardless of the
> reason). 
IMHO it is too general issue, but I guess that a new proposal for behaviour will solve that issue once and for all.
> 3. since engine changed behaviour to roll forward regardless of vdsm success
> or failure to remove the image (which is already discussed and agreed as a
> wrong behaviour) the only way to test this issue is to remove the image
> manually from the storage and leave it in engine.
Again, engine did not changed behaviour!
engine rolled forward when removing VM except when the first disk could not be deleted because engine could not initiate a task in VDSM. (see comment 5)
> 
> so either this bug is blocked by engine's new behaviour or its not solved at
> all since if the image does not exist any more in storage but exist in db we
> cannot remove a vm.
This is not new behaviour.

Comment 11 Maor 2013-01-30 19:00:08 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > 2. the issue described in this bug is that we cannot remove a vm that its
> > image was removed from vdsm but not removed in engine (regardless of the
> > reason). 
> IMHO it is too general issue, but I guess that a new proposal for behaviour
> will solve that issue once and for all.
Looking at the description again, this is not a general issue (summary confused me), sorry about that.
I still think BZ884635 will fix that specific case.

Comment 12 Ayal Baron 2013-01-31 15:08:50 UTC

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


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