[pve-devel] [PATCH qemu-server] qemu_block_resize: align size to 512

[Thomas Lamprecht]

On 1/9/20 11:20 AM, Fabian Ebner wrote:
> Doing 'qm resize 111 scsi0 +0.2G' where scsi0 is a qcow2 disk
> produced the following errors:
> "VM 111 qmp command 'block_resize' failed - The new size must be a multiple of 512"
> if the VM is running and
> "qemu-img: The new size must be a multiple of 512"

has it to be 512, or is this actually related to the qcow2 cluster_size,
which by default is 512? More out of interest, as we do not alter that
currently.

> if the VM isn't running
> 
> Signed-off-by: Fabian Ebner <f.ebner at proxmox.com>
> ---
>  PVE/QemuServer.pm | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
> index 2b68d81..2c92c3b 100644
> --- a/PVE/QemuServer.pm
> +++ b/PVE/QemuServer.pm
> @@ -4668,6 +4668,10 @@ sub qemu_block_resize {
>  
>      my $running = check_running($vmid);
>  
> +    # aligning to 512 is required for qcow2 disks

but this is called for all backing image types, not only qcow2??

> +    my $padding = (512 - $size % 512) % 512;
> +    $size = $size + $padding;
> +
>      $size = 0 if !PVE::Storage::volume_resize($storecfg, $volid, $size, $running);

why not move the padding adjustment into the storage plugins volume_resize
implementation using qcow2? I.e., the base Plugin's version.

Also, is this a problem with other backing types? (RBD, ZFS?) The RBD volume_resize
seems a bit fishy, as it does a plain ($size/1024/1024) - could that result in
truncation? Why does it allows shrinkage is also a question..

>  
>      return if !$running;
>