Red Hat Bugzilla – Bug 891052
3.1.z Error deleting VM disk
Last modified: 2016-02-10 13:50:06 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.
Created attachment 688974 [details] logs
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.
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.
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.
(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.
(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.
*** This bug has been marked as a duplicate of bug 884635 ***