all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: pve-devel@lists.proxmox.com, Stefan Hrdlicka <s.hrdlicka@proxmox.com>
Subject: Re: [pve-devel] [PATCH V3 qemu-server 4/6] add ignore-storage-errors for removing VM with missing storage
Date: Tue, 15 Nov 2022 13:17:09 +0100	[thread overview]
Message-ID: <94fa3244-7649-aa49-534b-0f1eebb5fab0@proxmox.com> (raw)
In-Reply-To: <20221115105526.3428334-5-s.hrdlicka@proxmox.com>

Am 15.11.22 um 11:55 schrieb Stefan Hrdlicka:
> @@ -2341,10 +2346,10 @@ sub destroy_vm {
>  
>  		my $volid = $drive->{file};
>  		return if !$volid || $volid =~ m|^/|;
> -
> -		die "base volume '$volid' is still in use by linked cloned\n"
> -		    if PVE::Storage::volume_is_base_and_used($storecfg, $volid);
> -
> +		my $result;
> +		eval { $result = PVE::Storage::volume_is_base_and_used($storecfg, $volid) };
> +		die "Couldn't remove one or more disks: $@\n" if $@ && !$ignore_storage_errors;

This error message is wrong. The check failed, not the removal. The
check should be repeated in vdisk_free anyways and you should get the
appropriate error then below :)

AFAIU base volumes should still survive if they are still referenced by
linked clones, even when ignore-storage-errors is used (IMHO good). Is
that correct?

Nothing new and not directly related:
I noticed that for containers, we don't have this heads-up check. Maybe
worth adding there too? Arguably minor issue is that I can have a
container template with a disk on lvm-thin and a second disk on
non-lvm-thin. Even if there is a linked clone, removing the template
might remove the lvm-thin disk, and then fail, because the second disk
is referenced.

> +		die "base volume '$volid' is still in use by linked cloned\n" if $result;
>  	});
>      }
>  
> @@ -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?

>  
>      for my $snap (values %{$conf->{snapshots}}) {
>  	next if !defined($snap->{vmstate});




  reply	other threads:[~2022-11-15 12:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-15 10:55 [pve-devel] [PATCH SERIES V3 pve-container/qemu-server/pve-manager 0/6] fix #3711 & adapt drive detach/remove behavior Stefan Hrdlicka
2022-11-15 10:55 ` [pve-devel] [PATCH V3 pve-container 1/6] fix #3711: optionally allow CT deletion to complete on disk volume removal errors Stefan Hrdlicka
2022-11-15 10:55 ` [pve-devel] [PATCH V3 pve-container 2/6] adapt behavior for detaching/removing a mount point Stefan Hrdlicka
2022-11-15 10:55 ` [pve-devel] [PATCH V3 pve-container 3/6] cleanup: remove spaces from empty lines Stefan Hrdlicka
2022-11-15 10:55 ` [pve-devel] [PATCH V3 qemu-server 4/6] add ignore-storage-errors for removing VM with missing storage Stefan Hrdlicka
2022-11-15 12:17   ` Fiona Ebner [this message]
2022-11-15 14:22     ` Stefan Hrdlicka
2022-11-16 10:08       ` Fiona Ebner
2022-11-15 10:55 ` [pve-devel] [PATCH V3 qemu-server 5/6] adapt behavior for detaching drives to deatching container mount points Stefan Hrdlicka
2022-11-15 10:55 ` [pve-devel] [PATCH V3 pve-manager 6/6] fix #3711: optionally allow CT deletion to complete on disk volume removal errors Stefan Hrdlicka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=94fa3244-7649-aa49-534b-0f1eebb5fab0@proxmox.com \
    --to=f.ebner@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=s.hrdlicka@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal