weizhouapache commented on PR #6868: URL: https://github.com/apache/cloudstack/pull/6868#issuecomment-1308896306
> > > That is not what this PR intends. The current problem is: when a user destroys a VM, its root volume will remain in the ready state, but generally speaking, when you destroy a VM, you intend to destroy its root volume as well. > > > > > > @JoaoJandre that's not true. when destroy a vm, the vm is just marked as Destroyed. none of its resources (nics, storage, vm snapshots, etc) are removed. If you want to completely remove a vm and its resources, please use `expungeVirtualMachine`, or `destroyVirtualMachine` with `expunge=true` > > > The proposed solution is to create a global setting ( which will be disabled by default ), that when enabled, ACS will destroy the root volume of a VM when that VM is destroyed. However, because of this setting, a new use case for restoring VMs is created, to restore a VM with a destroyed root volume. Therefore, I created an exception on the volume restore process, so that when you try to restore a VM with a destroyed root volume, it will not fail. > > Yes, I know that when you destroy a VM it is only marked as "destroyed". When VMs are marked as "destroyed", they no longer count towards the users' used resources. Therefore, after destroying a VM, they can right away create another one with the "freed quota". However, the same logic is not applied to root volumes; they are maintained in "ready" state. What I am addressing here is this inconsistency; the idea is to make the root volume and VMs to have the same behavior. > > Let me give you a detailed example. Let's say a user has the following resource limits:  Therefore, the user can only have 1 VM and 1 volume. Then, if the user creates a VM, this is what its resource limit will look like:  Which is exactly as expected. Then, if the user destroys the VM, this is what the resource count will look like:  Therefore, if the user tries to create a new VM (he already destroyed the other one he had), this is what will happen:  > > That is the problem the PR is addressing. That is why I proposed this PR, to create a configuration that when enabled will also mark the root volume as destroyed to stop counting it towards users' resource quota. @JoaoJandre When vm is destroyed, it is not usable, so vm is not considered in the resource count calculation of instance and cpu/memory. But the ROOT volume is still stored on primary storage. I think it makes sense to consider it in calculation of primary storage resource count. There is a similar scenario: the volumes in Destroy state are also considered in resource count calculation. Back to your topic, I think it is a bad idea to mark the root volume as Destroyed, as the root volume will be finally destroyed by background thread and vm cannot be recovered. If you want users are able to create a new vm after they destroy a vm, please expunge the vm instead of destroy. There are two global settings : allow.user.expunge.recover.vm and allow.user.expunge.recover.volume, when they are set to 0, users can expunge vms and volumes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@cloudstack.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
