Re: [pve-devel] [PATCH V3 qemu-server 4/6] add ignore-storage-errors for removing VM with missing storage

[Fiona Ebner <f.ebner@proxmox.com>]

Am 15.11.22 um 15:22 schrieb Stefan Hrdlicka:
> On 11/15/22 13:17, Fiona Ebner wrote:
>> Am 15.11.22 um 11:55 schrieb Stefan Hrdlicka:
>>>   @@ -2370,7 +2375,8 @@ sub destroy_vm {
>>>       include_unused => 1,
>>>       extra_keys => ['vmstate'],
>>>       };
>>> -    PVE::QemuConfig->foreach_volume_full($conf, $include_opts,
>>> $remove_owned_drive);
>>> +    eval { PVE::QemuConfig->foreach_volume_full($conf,
>>> $include_opts, $remove_owned_drive); };
>>> +    die "Couldn't remove one or more disks: $@\n" if $@ &&
>>> !$ignore_storage_errors;
>>
>> So, $removed_owned_drive already ignores all storage errors beside if
>> PVE::Storage::path() fails right? Can't we just add an eval around that
>> and be done? No need for a new ignore-storage-errors parameter. Most
>> storage errors are already ignored even without that parameter right
>> now! I don't think it's a big issue to start ignoring the few missing
>> ones as well?
> 
> Well I wasn't sure. Safe option was to tell the user that there is a
> problem and then the user decides if something should be forced deleted.
> But if you think this is fine without user input lets pretend this never
> existed :).
> 
When there are storage errors, the VM config is removed and the user is
warned about failed volume removal, *except* when the storage errors are
in path() (which can only happen if the storage is gone from the config
or in very few plugins like RBD), where it leads to the VM config
removal failing.

But I don't see why errors in path() should be fundamentally different
here and feel like we should just align the behavior for those too.
After all, that was the intention behind the eval block + warning around
vdisk_free() in commit 31b52247 ("destroy_vm: allow vdisk_free to fail")

To make the warnings more visible, we can switch to log_warn() instead
of plain warn.

For containers, all storage errors just propagate right now (or?), so
the new parameter can be fine there. We could also align the behavior
with what we do for VMs instead (if we do that, it should be done for a
point release), but we don't have to of course.