On 3/4/20 10:51 AM, Fabian Ebner wrote:
> This reverts commit b5490d8a98e5e7328eb4cebb0ae0b60e6d406c38.
>
> When resizing a volume of a running VM, a qmp block_resize command
> is issued. This is non-blocking, so the size on the storage immediately
> after issuing the command might still be the old one.
>
> This is part of the issue reported in bug #2621.
>
> Signed-off-by: Fabian Ebner <f.eb...@proxmox.com>
> ---
> PVE/API2/Qemu.pm | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
> index caca430..d0dd2dc 100644
> --- a/PVE/API2/Qemu.pm
> +++ b/PVE/API2/Qemu.pm
> @@ -3586,8 +3586,7 @@ __PACKAGE__->register_method({
>
> PVE::QemuServer::qemu_block_resize($vmid, "drive-$disk", $storecfg,
> $volid, $newsize);
>
> - my $effective_size = eval {
> PVE::Storage::volume_size_info($storecfg, $volid, 3); };
> - $drive->{size} = $effective_size // $newsize;
> + $drive->{size} = $newsize;
> $conf->{$disk} = PVE::QemuServer::print_drive($drive);
>
> PVE::QemuConfig->write_config($vmid, $conf);
>
don't we want to await that operation to be finished? Or let the storage
backend tell us
anyway what aligned/rounded-up size it requested from qemu-img, zfs, ...?
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
