This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 891052

Summary: 3.1.z Error deleting VM disk
Product: Red Hat Enterprise Virtualization Manager Reporter: Ayal Baron <abaron>
Component: ovirt-engineAssignee: Maor <mlipchuk>
Status: CLOSED DUPLICATE QA Contact: Dafna Ron <dron>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.1.1CC: abaron, acathrow, amureini, bazulay, cpelland, dron, dyasny, ewarszaw, hateya, iheim, ipilcher, lpeer, mlipchuk, Rhev-m-bugs, sgrinber, tjelinek, yeylon, ykaplan, ykaul
Target Milestone: ---Keywords: ZStream
Target Release: 3.2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: storage
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 885489 Environment:
Last Closed: 2013-01-31 10:08:50 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 885489, 891053, 891054    
Bug Blocks:    
Attachments:
Description Flags
logs none

Comment 2 Dafna Ron 2013-01-28 08:22:57 EST
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 08:23:35 EST
Created attachment 688974 [details]
logs
Comment 5 Maor 2013-01-30 07:11:57 EST
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 09:25:24 EST
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 09:57:05 EST
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 13:50:20 EST
(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 14:00:08 EST
(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 10:08:50 EST

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