[pve-devel] vm deletion succeeds even if storage deletion fails

[Thomas Lamprecht]

On 1/16/19 11:43 AM, Stefan Priebe - Profihost AG wrote:
> Hi,
> 
> Am 15.01.19 um 08:19 schrieb Stefan Priebe - Profihost AG:
>>
>> Am 15.01.19 um 08:15 schrieb Fabian Grünbichler:
>>> On Mon, Jan 14, 2019 at 11:04:29AM +0100, Stefan Priebe - Profihost AG wrote:
>>>> Hello,
>>>>
>>>> today i was wondering about some disk images while the vm was deleted.
>>>>
>>>> Inspecting the task history i found this log:
>>>>
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> Could not remove disk 'cephstoroffice:vm-202-disk-1', check manually:
>>>> error with cfs lock 'storage-cephstoroffice': got lock request timeout
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> trying to acquire cfs lock 'storage-cephstoroffice' ...
>>>> error with cfs lock 'storage-cephstoroffice': got lock request timeout
>>>> TASK OK
>>>>
>>>> so the vm was deleted but the storage was left unclean. Is this a known
>>>> bug? If not can someone point me to the code so i can provide a patch.
>>>
>>> this was changed intentionally because users complained that there is no
>>> way to delete a VM config that references an undeletable disk (e.g.,
>>> because a storage is down).
>>
>> hui - really? But this leaves you unused disks behind? What happens if
>> another user get's the same VM id? This sounds a bit weird to me.
>>
>>> if you want to improve this further, we could discuss adding a 'force'
>>> parameter to the 'destroy_vm' API call (in PVE/API2/Qemu.pm) and
>>> 'destroy_vm' in PVE/QemuServer.pm, and adapting the latter to only
>>> ignore disk removal errors in case it is set?
>>>
>>> I am not sure how many people might rely on the current behaviour, which
>>> has been like this since (the end of) 2016..
> 
> Can you point me to the commit / package where this change was
> introduced? I've searched for it but couldn't finde it.

qemu-server:

git show 31b52247
commit 31b522478dd4157ae4e30c574b01f27d3a88adde
Author: Fabian Grünbichler <f.gruenbichler at proxmox.com>
Date:   Tue Dec 20 12:30:57 2016 +0100

    destroy_vm: allow vdisk_free to fail

    otherwise we end up with undeletable VM configs in case
    vdisk_free fails (which could happen because of cluster-wide
    lock contention, storage problems, ..).

- Thomas