Red Hat Bugzilla – Bug 818091
[ovirt] [engine-core] force remove pool using wrong query and doesn't remove templates attached
Last modified: 2016-02-10 11:32:45 EST
cloning this to downstream since cleaning of templates in case of DC force remove or domain destroy is important enough.
+++ This bug was initially created as a clone of Bug #806886 +++
Created attachment 572748 [details]
Description of problem:
- pool with 1 domain
- 2 templates
- domain is in problematic state
Force remove data-base: templates remain, all other objects are deleted
try remove cluster: 2012-03-26 13:46:09,838 WARN [org.ovirt.engine.core.bll.RemoveVdsGroupCommand] (http--0.0.0.0-8080-2) CanDoAction of action RemoveVdsGroup failed. Reasons:VAR__TYPE__CLUSTER,VAR__ACTION__REMOVE,VMT_CANNOT_REMOVE_VDS_GROUP_VMTS_DETECTED
--- Additional comment from email@example.com on 2012-05-01 04:45:34 EDT ---
destroy of domain will also not remove the templates under the domain.
we can however remove them manually after the destroy.
*** Bug 806886 has been marked as a duplicate of this bug. ***
*** Bug 833417 has been marked as a duplicate of this bug. ***
tried to verify on SI7 - force-remove data-center doesn't remove template for data-center type local-fs.
StatusCommand] (QuartzScheduler_Worker-42) [7ca2c556] Running command: SetStoragePoolStatusCommand internal: true. Entities affected : ID: 98d1c31c-5d40-4556-
oolCommand] (ajp-/0.0.0.0:8009-8) [7afa3620] Running command: RemoveStoragePoolCommand internal: false. Entities affected : ID: 98d1c31c-5d40-4556-8e4d-9874bf
QuartzScheduler_Worker-42) [7ca2c556] Checking autorecoverable hosts
QuartzScheduler_Worker-42) [7ca2c556] Autorecovering 0 hosts
QuartzScheduler_Worker-42) [7ca2c556] Checking autorecoverable hosts done
QuartzScheduler_Worker-42) [7ca2c556] Checking autorecoverable storage domains
QuartzScheduler_Worker-42) [7ca2c556] Autorecovering 0 storage domains
QuartzScheduler_Worker-42) [7ca2c556] Checking autorecoverable storage domains done
*** Bug 814204 has been marked as a duplicate of this bug. ***
Verified on RHEVM 3.1 - SI9.1
QEMV & KVM: qemu-kvm-rhev-0.12.1.2-2.295.el6.x86_64