Description of problem: Underlying datavolume or PVC is not removed on VM disk removal. So the data (DV and PVC) stays there How reproducible: 100 Expected results: The DV or PVC should be removed if the owner of that object is the VM.
Probably we should have an option on the UI to decide if we want to delete also the disks or only the VM. Currently to not to touch the disks is the safer option so lets leave it like this in 4.4 and re-evaluate in 4.5. FYI: Nelly
Please note remove CDROM also cannot remove the DV, need to fix for CDROM as well.
ack
we should also ask if the user wants to remove associated VirtualMachineImport resource
We should also patch DV owner references accordingly.
Should we show a table of disks so the user can select which to preserve and which to keep? This would be very useful especially for attached disks which were not cloned before and there is no ownership set (I would imagine these to be deselected by default). Or should we not care about disks which the VM doesn't own at all - but still uses - this includes also secrets. etc.
(In reply to Filip Krepinsky from comment #6) > Should we show a table of disks so the user can select which to preserve and > which to keep? certainly not as a bugfix. As a 4.5 bugfix we might add a checkbox but not a whole table. But we might consider it for 4.6 > > This would be very useful especially for attached disks which were not > cloned before and there is no ownership set (I would imagine these to be > deselected by default). > Or should we not care about disks which the VM doesn't own at all - but > still uses - this includes also secrets. etc. I don't think we should touch them at all. Those things are more often than not reused in the env so deleting one VM using them should not affect them
> As a 4.5 bugfix we might add a checkbox but not a whole table. But we might consider it for 4.6 Moving to 4.6 Notes: a - the scope of this bug is bigger then a bug fix b - in normal cases data-volumes, persistent-volumes, secrets and config maps should persist after vm is deleted. c - since the deletion of data-volumes is a dangerous operation (may cause data lost) we need some design work on this @Matt will you have the capacity to do a design for this for 4.6 ?
@Tomas hi, I un-targeted 4.5 because it looks big (not a bug) WDYT ?
@Matt hi, off line we decided to re-targer it to 4.5 , but we want you opinion on the design changes, do you think it will make UX better ?
> b - in normal cases data-volumes, persistent-volumes, secrets and config maps should persist after vm is deleted. The most usual case is that the VM will own the DV, unless you click Attach Disk (not Attach Cloned PVC). These DVs and PVCs are deleted on VM deletion (Currently without asking).
Verified that disks owned by a VM are deleted when the VM is deleted. That is - blank disks, attached cloned disks, URL disks. Attached disks (not cloned) are not removed. release-4.5, commit: 91e682e014286e243085dcb168480d54b913a010
Btw, standalone disk removal should be tested too: there are two states depending on the "delete DV/PVC" checkbox: - Disk is removed immediately while VM object is still present - Disk is not removed and lives even after VM deletion. The VM removal itself have these options for all disks.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:2409