public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "Max Carrara" <m.carrara@proxmox.com>
To: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH storage] volume import: assume target API version is at least 9
Date: Tue, 02 Jul 2024 19:14:34 +0200	[thread overview]
Message-ID: <D2F80HY0Q15L.2BNN7L0AK0UI@proxmox.com> (raw)
In-Reply-To: <20240610090415.13057-1-f.ebner@proxmox.com>

On Mon Jun 10, 2024 at 11:04 AM CEST, Fiona Ebner wrote:
> The storage API version has been bumped to at least 9 since
> libpve-storage = 7.0-4. If the source node is on Proxmox VE 8, where
> this change will come in, then the target node can be assumed to be
> running either Proxmox VE 8 or, during upgrade, the latest version of
> Proxmox VE 7.4, so it's safe to assume a storage API version of at
> least 9 in all cases.
>
> As reported by Maximiliano, the fact that the 'apiinfo' call was
> guarded with a quiet eval could lead to strange errors for replication
> on a customer system where an SSH connection could not always be
> established, because the target's API version would fall back to 1.
> Because of that, the '-base' argument would be missing for the import
> call on the target which would in turn lead to an error about the
> target ZFS volume already existing (rather than doing an incremental
> sync).
>
> Reported-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>

Wasn't able to test this at the moment yet (please holler at me if you
need me to), but these changes are pretty straightforward anyway.

I completely agree with all of these changes; LGTM.

Reviewed-by: Max Carrara <m.carrara@proxmox.com>

> ---
>  src/PVE/Storage.pm | 18 ++++++------------
>  1 file changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/src/PVE/Storage.pm b/src/PVE/Storage.pm
> index f19a115..bee2361 100755
> --- a/src/PVE/Storage.pm
> +++ b/src/PVE/Storage.pm
> @@ -709,7 +709,7 @@ sub storage_migrate_snapshot {
>  }
>  
>  my $volume_import_prepare = sub {
> -    my ($volid, $format, $path, $apiver, $opts) = @_;
> +    my ($volid, $format, $path, $opts) = @_;
>  
>      my $base_snapshot = $opts->{base_snapshot};
>      my $snapshot = $opts->{snapshot};
> @@ -724,11 +724,11 @@ my $volume_import_prepare = sub {
>      if ($migration_snapshot) {
>  	push @$recv, '-delete-snapshot', $snapshot;
>      }
> -    push @$recv, '-allow-rename', $allow_rename if $apiver >= 5;
> +    push @$recv, '-allow-rename', $allow_rename;
>  
>      if (defined($base_snapshot)) {
>  	# Check if the snapshot exists on the remote side:
> -	push @$recv, '-base', $base_snapshot if $apiver >= 9;
> +	push @$recv, '-base', $base_snapshot;
>      }
>  
>      return $recv;
> @@ -814,12 +814,7 @@ sub storage_migrate {
>  	$import_fn = "tcp://$net";
>      }
>  
> -    my $target_apiver = 1; # if there is no apiinfo call, assume 1
> -    my $get_api_version = [@$ssh, 'pvesm', 'apiinfo'];
> -    my $match_api_version = sub { $target_apiver = $1 if $_[0] =~ m!^APIVER (\d+)$!; };
> -    eval { run_command($get_api_version, logfunc => $match_api_version); };
> -
> -    my $recv = [ @$ssh, '--', $volume_import_prepare->($target_volid, $format, $import_fn, $target_apiver, $opts)->@* ];
> +    my $recv = [ @$ssh, '--', $volume_import_prepare->($target_volid, $format, $import_fn, $opts)->@* ];
>  
>      my $new_volid;
>      my $pattern = volume_imported_message(undef, 1);
> @@ -911,8 +906,7 @@ sub storage_migrate {
>  	    run_command($cmds, logfunc => $match_volid_and_log);
>  	}
>  
> -	die "unable to get ID of the migrated volume\n"
> -	    if !defined($new_volid) && $target_apiver >= 5;
> +	die "unable to get ID of the migrated volume\n" if !defined($new_volid);
>      };
>      my $err = $@;
>      if ($opts->{migration_snapshot}) {
> @@ -1961,7 +1955,7 @@ sub volume_import_start {
>      my $info = IO::File->new();
>  
>      my $unix = $opts->{unix} // "/run/pve/storage-migrate-$vmid.$$.unix";
> -    my $import = $volume_import_prepare->($volid, $format, "unix://$unix", APIVER, $opts);
> +    my $import = $volume_import_prepare->($volid, $format, "unix://$unix", $opts);
>  
>      unlink $unix;
>      my $cpid = open3($input, $info, $info, @$import)



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel


  reply	other threads:[~2024-07-02 17:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-10  9:04 Fiona Ebner
2024-07-02 17:14 ` Max Carrara [this message]
2024-07-03 12:26 ` [pve-devel] applied: " Fiona Ebner
2024-07-04  9:52 ` [pve-devel] " Thomas Lamprecht
2024-07-04 10:28   ` Fiona Ebner
2024-07-04 11:51     ` Thomas Lamprecht
2024-07-04 12:11       ` Fiona Ebner
2024-07-04 17:45         ` Thomas Lamprecht
2024-07-05  8:22           ` Fiona Ebner
2024-07-25 12:38             ` Thomas Lamprecht
2024-07-05  7:45         ` Thomas Lamprecht

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=D2F80HY0Q15L.2BNN7L0AK0UI@proxmox.com \
    --to=m.carrara@proxmox.com \
    --cc=pve-devel@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal