[pve-devel] [PATCH v2 pve-storage 2/2] fix #6941 : lvmplugin : fix activation on secure delete

[Fiona Ebner]

Am 21.10.25 um 4:01 PM schrieb Alexandre Derumier via pve-devel:
> It was lost in the lvm qcow2 patches

This commit message is very unspecific. Should at least mention what the
issue is/that this affects raw volumes. When referring to an older
commit, please include the short commit ID and title.

> Signed-off-by: Alexandre Derumier <alexandre.derumier at groupe-cyllene.com>

I like the approach of moving activation closer to where actually needed
:) Some comments inline:

> ---
>  src/PVE/Storage/LVMPlugin.pm | 24 ++++++++++++------------
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/src/PVE/Storage/LVMPlugin.pm b/src/PVE/Storage/LVMPlugin.pm
> index 1c633a3..9716854 100644
> --- a/src/PVE/Storage/LVMPlugin.pm
> +++ b/src/PVE/Storage/LVMPlugin.pm
> @@ -375,6 +375,17 @@ my sub free_lvm_volumes {
>              my $lvmpath = "/dev/$vg/del-$name";
>              print "zero-out data on image $name ($lvmpath)\n";
>  
> +            my $cmd_activate = ['/sbin/lvchange', '-aly', $lvmpath];
> +            run_command(
> +                $cmd_activate,
> +                errmsg => "can't activate LV '$lvmpath' to zero-out its data",
> +            );
> +            $cmd_activate = ['/sbin/lvchange', '--refresh', $lvmpath];
> +            run_command(
> +                $cmd_activate,
> +                errmsg => "can't refresh LV '$lvmpath' to zero-out its data",
> +            );
> +
>              $secure_delete_cmd->($lvmpath);
>  
>              $class->cluster_lock_storage(
> @@ -755,13 +766,6 @@ my sub alloc_snap_image {
>  my sub free_snap_image {
>      my ($class, $storeid, $scfg, $volname, $snap) = @_;
>  
> -    #activate only the snapshot volume
> -    my $path = $class->path($scfg, $volname, $storeid, $snap);
> -    my $cmd = ['/sbin/lvchange', '-aly', $path];
> -    run_command($cmd, errmsg => "can't activate LV '$path' to zero-out its data");
> -    $cmd = ['/sbin/lvchange', '--refresh', $path];
> -    run_command($cmd, errmsg => "can't refresh LV '$path' to zero-out its data");
> -
>      my $snap_volname = get_snap_name($class, $volname, $snap);
>      return free_lvm_volumes($class, $scfg, $storeid, [$snap_volname]);
>  }
> @@ -777,11 +781,7 @@ sub free_image {
>          #activate volumes && snapshot volumes

This comment is misleading now. It should note that snapshots are
activated later in free_lvm_volumes() if needed for zeroing.

>          my $path = $class->path($scfg, $volname, $storeid);
>          $path = "\@pve-$name" if $format && $format eq 'qcow2';

The $path variable is not used anymore and can be dropped.

On another note, the way of using tags like "@pve-vm-105-disk-2.qcow2"
is not quite correct, because there might be multiple LVM storages with
qcow2 and volumes with the same name. And those then should not be
tagged the same, but currently are. While it's probably very rare to
come across such a setup, it's not impossible and could lead to
hard-to-debug issues down the line. But it's out of scope for the
current series.

> -        my $cmd = ['/sbin/lvchange', '-aly', $path];
> -        run_command($cmd, errmsg => "can't activate LV '$path' to zero-out its data");
> -        $cmd = ['/sbin/lvchange', '--refresh', $path];
> -        run_command($cmd, errmsg => "can't refresh LV '$path' to zero-out its data");
> -
> +        $class->activate_volume($storeid, $scfg, $volname);
>          my $snapshots = $class->volume_snapshot_info($scfg, $storeid, $volname);
>          for my $snapid (
>              sort { $snapshots->{$a}->{order} <=> $snapshots->{$b}->{order} }
> -- 
> 2.47.3
> 
>