Description of problem: This is really important, some times we get scenario where some content hosts were removed from vCenter after the customer just remove the CH from Satellite webUI. We already know the warning, however, the customer believes that will be related only to Satellite webUI. This feature is really interesting, however, should be disabled by default and once the customer is aware of how this work, they could switch easily. Version-Release number of selected component (if applicable): 6.7 How reproducible: 100% Steps to Reproduce: 1. Configure the Compute Resource 2. Create a new VM 3. Delete the CH via Satellite webUI Actual results: The machine will be removed from vCenter (or external virtualization resource) Expected results: Remove only from Satellite side (db, webUI) Additional info:
Waldirio, this is what was discussed and agreed on in BZ 1549761, I think it works as expected. I'm closing as NOTABUG, please reopen if I misunderstood.
Yea, indeed. Thank you my friend. Waldirio
Created redmine issue https://projects.theforeman.org/issues/30247 from this bug
Upstream bug assigned to mhulan
Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/30247 has been resolved.
Verified with 6.9.0 snap 13.0. By default there is NO in Settings -> Provisioning -> Destroy associated VM on host delete In UI, when user is asked if he understands the action of not deleting machine from the virtualization resource. When there is YES in settings -> user is also asked in UI if he understand the action and the machine together with disk will be removed.
This was verified on Satellite 6.9; therefore, moving the bugzilla to CLOSED:CURRENTRELEASE.
Note that there are two relevant settings for subscription-manager unregister to result in VM deletion: destroy_vm_on_host_delete (on the 'Provisioning' tab in settings, the one referenced in this BZ) and also unregister_delete_host (on the 'Content' tab in settings, and defaults to 'false') So in order for 'unregister' to delete a VM, both settings must be set true so that: sub-man unregister -> delete 'host' entry on satellite (due to unregister_delete_host true) -> destroy VM on compute resource (due to destroy_vm_on_host_delete true) I still agree with setting destroy_vm_on_host_delete default to false as this BZ has done (because there are other ways to trigger accidental VM deletion without using sub-man unregister, and false is a much safer default), but making an additional note that any customers affected by this issue who saw this behavior specifically due to a subscription-manager unregister, should also check why unregister_default_host got changed from its default value of false and if that is what they really desire