Re: [PATCH qemu-server 4/4] clone disk: bump timeout for querying target volume size to 1 minute

["Elias Huhsovitz" <e.huhsovitz@proxmox.com>]

On Thu Oct 22, 2026 at 11:38 AM CEST, Fiona Ebner wrote:
> Since commit "fix #8209: clone disk: do not ignore failure to query
> size of target", failure to query the size of the target volume after
> clone is no longer quietly ignored. Bump the timeout to reduce the
> likelyhood of harmless timeouts causing a warning. Print a message to
> communicate that the query is happening to the user.
>
> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
> ---
>  src/PVE/QemuServer.pm | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/PVE/QemuServer.pm b/src/PVE/QemuServer.pm
> index 4b7351b3..0f8aef6f 100644
> --- a/src/PVE/QemuServer.pm
> +++ b/src/PVE/QemuServer.pm
> @@ -7931,7 +7931,8 @@ sub clone_disk {
>      }
>  
>      my $result = {};
> -    my $size = eval { PVE::Storage::volume_size_info($storecfg, $newvolid, 10) };
> +    print "querying size of target volume '$newvolid' after copy..\n";

nit: IMO the message should say: 'after clone...', since we are calling 
PVE::Storage::vdisk_clone.

super nit: i think it should be three dots (...), instead of 2 (..) ;)

> +    my $size = eval { PVE::Storage::volume_size_info($storecfg, $newvolid, 60) };

nit: The timeout is inconsistent with the volume_size_info() call on
line 7897. There it is still 10 seconds. I am not sure if we can
gurantee that querying the source volume is always faster than querying
the target volume.

general: Tbh I am not sure that a generic timeout is the optimal
long-term solution here. I feel like the timeout should be storage
specific. E.g., an incrased timeout of 60 seconds for a NFS, but keep
the 10 seconds for a local ZFS.

But for now, the incrased timeout is fine.

>      my $err = $@;
>      $err = "no size in result" if !$err && !$size;
>      if ($err) {