Description of problem: Compute resources are good, but the definition of "delete" should be configurable. Many enterprise customers don't delete VM disk images when they delete the VM container. They age out the disk images after the fact. However, when you delete a VM with Satellite, and that VM is tied to a VMware compute resource, Satellite will tell VMware to delete the on disk image as well. Can we allow users to configure the compute resource to keep the disk images instead of deleting them? It's just too easy to completely delete a VM from the Satellite console. Even having a warning dialog when you delete to let people know that the VM _including_ the disk image is being deleted, and not just disassociated from the Satellite. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
You could power off the VM from Satellite and then just instead of deleting it, you can disassociate it. Once you do that, you can safely delete host in Satellite and the VM remains untouched. The power off is optional of course. Later you could associate the VM back to Satellite if you want to restore it. Would that be a good solution or you prefer to actually delete the VM and just keep the disk? In such case, would it make sense as a global setting (affecting all organizations) or configurable per compute-resource?
I think it's OK to actually delete, but there should be a dialog box that comes up to tell users that it really WILL delete the VM and storage, and if they want to continue, then should be forced to type the name of the VM into a textbox. It should also suggest that the user disassociate to remove the VM from Satellite but not delete the VM.
*** Bug 1310150 has been marked as a duplicate of this bug. ***
Let's mark as triaged and clone the issue upstream. - we don't warn users enough about disk deletion w/ VM deletion.
Created redmine issue http://projects.theforeman.org/issues/22492 from this bug
We believe this has been implemented as part of BZ 1549761, please reopen if we missed something. *** This bug has been marked as a duplicate of bug 1549761 ***