Repository navigation
Destroy VM should detach the volumes from VM and recover VM should not try to attach the volumes again #4902
Description
This is an improvement ticket in which volumes of a VM which are not intended to be deleted (when VM is tried to destroy) are going to be detached from VM during destroy VM operation.
CloudStack volumes are first-class citizens, they do not belong to a VM. Therefore data disks must be detached from the destroyed VM and either be expunged (if that is what the user requested) or be left detached and available for any volume actions - attach, expunge, extract, etc.
The existing behaviour is upon on destroy of VM (having datadisks) and data disks are not selected to delete, then during VM destroy these disks are still marked as attached to VM. Only during VM expunge of VM these volumes are detached from the VM.
ISSUE TYPE
- Improvement Request
COMPONENT NAME
CLOUDSTACK VERSION
CONFIGURATION
OS / ENVIRONMENT
SUMMARY
EXPECTED RESULTS
- When destroy VM with expunge or without expunge and no data disk is selected for deletion
Data disks will be detached from VM during destroy VM itself
ACTUAL RESULTS
- When destroy VM without expunge and when no data disk is selected for deletion
VM is stopped and data disks will still shown as attached to original VM
When tried to recover the VM, the VM is made ready along with its data disks as before.
- When destroy VM without expunge and when one or more data disks are selected for deletion
VM is stopped and data disks which are selected for deletion will be deleted and other data disks will still remain attached
When tried to recover the VM, the VM is made ready along with remaining data disks which are not deleted
- When destroy VM with expunge and when no data disk is selected for deletion
All data disks are detached from VM
VM will be destroyed and expunged completely
- When destroy VM with expunge and few data disks are selected for deletion
Data disks marked for deletion are deleted and the remaining disks are detached from VM
VM will be destroyed and expunged completely.
Activity
wido commentedon Apr 11, 2021
I agree 100% with this as @PaulAngus also mentioned in other threads.
Datadisks are not part of a VM, they are just attached to it. Upon destruction they should be detached and left alone.
DaanHoogland commentedon Apr 13, 2021
I agree with you and @PaulAngus, @wido. From a conceptual/cloudstack paradigm point of view.
Some users of appliances might disagree though, and argue that a data disk installed by an appliance is an integral part of it. It seems to me we should think about that use-case as well. I'm not sure how common it is though and whether it matters to any ACS users.
just a heads-up. I agree with implementing as @harikrishna-patnala describes unless ...
yadvr commentedon Apr 15, 2021
+1 let's fix in the next major release. For consistency sake with other hypervisors, #4493 can be merged to retain backward compatibility.
nvazquez commentedon Jul 27, 2021
@weizhouapache can you explore a fix for this please?
weizhouapache commentedon Jul 27, 2021
@rhtyd @harikrishna-patnala
your opinions ?
nvazquez commentedon Aug 2, 2021
@rhtyd @harikrishna-patnala can you please advise if this is still valid?
harikrishna-patnala commentedon Aug 2, 2021
This is valid based on the earlier discussions on PR #4462 and on this ticket, this is an improvement that we can take it up. We need a volunteer to work on this.
nvazquez commentedon Aug 2, 2021
Thanks @harikrishna-patnala
weizhouapache commentedon Aug 18, 2021
@harikrishna-patnala @DaanHoogland @nvazquez
I am looking at this issue.
here are my opinions (based on previous discussions)
(1) destroy vm, selected data disks will be destroyed (and cleaned by cloudstack after some days), other data disks will be detached.
(2) destroy vm with expunge, selected data disks will be deleted, other data disks will be detached.
(3) expunge vm. all data disks will be detached
(4) recover vm, data disks will not be re-attached.
please correct me if I miss something.
PaulAngus commentedon Aug 18, 2021
As mentioned by Wido and myself, data disks are considered first-class citizens. Therefore the first step when destroying a VM which has data disks attached, is to detach them. Obviously it is perfectly valid for the user to destroy them as well, either via an argument in the initial API command, as a separate API command, or via an option in the UI which calls the appropriate API(s).
Therefore, scenarios (1) and (2) should start 'detach data disks, destroy VM ... '. Scenario (3) is then simply 'Expunge VM'.
There then are four more actions:
As Daan notes, 'As Is' VMs are a special case, where the data disk will often be considered a part of the VM. One could argue either way. One way of 'solving it' is to make it the operator's problem and add a global or even account setting to choose whether data disks are automatically destroyed for an 'As Is' VM or not.
weizhouapache commentedon Aug 18, 2021
@PaulAngus great, thanks for your comment. agree with you.
we already support destroy/recover data disks (#3688), so the change will be simple.
@DaanHoogland could you please advice on how to proceed with volumes on vmware ?
nvazquez commentedon Aug 19, 2021
Agree with @PaulAngus
@weizhouapache @PaulAngus @DaanHoogland I think Vmware 'as-is' VMs are not a problem, as the volumes cloned from the template are marked as ROOT volumes. Then all the additional data disks added by the user can be treated the same as regular (non-as-is) VM data disks
DaanHoogland commentedon Aug 20, 2021
Agree with everybody, or at least @PaulAngus , @weizhouapache and @nvazquez in their discussion above. @nvazquez you trigger a bit of a 'bear on the road'; if multiple
ROOTdisks are defined for a VM , will delete and recover work as expected for such a VM? (let alone if this isdeployAsIsor not, because we will have that discussion as well, later.weizhouapache commentedon Sep 21, 2021
fixed via #5356