Bug 1298223

Summary: removing automatic VM pool with running vms fails constantly
Product: [oVirt] ovirt-engine Reporter: Barak Korren <bkorren>
Component: BLL.VirtAssignee: Shahar Havivi <shavivi>
Status: CLOSED WORKSFORME QA Contact: meital avital <mavital>
Severity: high Docs Contact:
Priority: low    
Version: 3.6.1.3CC: bkorren, bugs, gklein, masayag, mgoldboi, tjelinek
Target Milestone: ovirt-4.2.0Flags: tjelinek: ovirt-4.2?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-04-03 10:43:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Barak Korren 2016-01-13 14:21:13 UTC
Description of problem:
When removing an automatic pool with running VMs, the command will fail for the 1st time and succeed for the 2nd.

Version-Release number of selected component (if applicable):
oVirt Engine Version: 3.6.1.3-1.el7.centos

How reproducible:
Always

Steps to Reproduce:
1. Create a VM pool from a template with a disk, set the pool size to at least 2 and set it to per-start at least 2 vms
2. wait for the vms to start up
3. try to remove the pool
   -> the VMs will be shut down but the removal task will fail and the pool
      will remain
4. try to remove the pool again
   -> this time the VMs and pool will be erased


Actual results:
Pool removal task fails

Expected results:
Pool removal task should succeed the first time

Comment 1 Michal Skrivanek 2016-01-29 13:59:08 UTC
logs?

Comment 2 Barak Korren 2016-02-08 12:07:25 UTC
I don't have the test system any more, so cannot provide logs at this time. Please follow steps to reproduce.

Comment 3 Tomas Jelinek 2016-02-11 11:50:07 UTC
does not seem as something dangerous, only an annoyance - targeting 4.0 for consideration.

Comment 4 Moran Goldboim 2016-03-24 08:34:23 UTC
deferred to next version due to capacity.

Comment 5 Yaniv Kaul 2016-11-29 21:09:12 UTC
(In reply to Tomas Jelinek from comment #3)
> does not seem as something dangerous, only an annoyance - targeting 4.0 for
> consideration.

And now? fix or defer?

Comment 6 Tomas Jelinek 2016-11-30 07:32:59 UTC
defer.

Comment 7 Shahar Havivi 2017-03-16 10:29:50 UTC
Cannot reproduce,
Try with 2-5 VMs with and without disks.
Barak can you reproduce it?

Comment 8 Shahar Havivi 2017-04-03 10:43:49 UTC
If you can reproduce it with engine logs please reopen the bug.

Comment 9 Barak Korren 2022-07-07 05:06:24 UTC
Removing needinfo