[pve-devel] [PATCH v2 qemu-server 1/2] resize_vm: request new size from storage after resizing

Fabian Ebner f.ebner at proxmox.com
Tue Jan 21 13:25:25 CET 2020

On 1/13/20 11:47 AM, Fabian Ebner wrote:
> Because of alignment and rounding in the storage backend, the effective
> size might not match the 'newsize' parameter we passed along.
> Signed-off-by: Fabian Ebner <f.ebner at proxmox.com>
> ---
> Turns out that this happens in basically every storage backend that has
> 'volume_resize': LVM and RBD round down, ZFS and DIR for '.raw' align
>   PVE/API2/Qemu.pm | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm
> index 5bae513..b83ce07 100644
> --- a/PVE/API2/Qemu.pm
> +++ b/PVE/API2/Qemu.pm
> @@ -3607,7 +3607,8 @@ __PACKAGE__->register_method({
>   	    PVE::QemuServer::qemu_block_resize($vmid, "drive-$disk", $storecfg, $volid, $newsize);
> -	    $drive->{size} = $newsize;
> +	    my $effective_size = eval { PVE::Storage::volume_size_info($storecfg, $volid, 3); };
> +	    $drive->{size} = $effective_size // $newsize;
>   	    $conf->{$disk} = PVE::QemuServer::print_drive($drive);
>   	    PVE::QemuConfig->write_config($vmid, $conf);

Please do not apply the second and third patch in this series yet. I 
thought about this some more and think it makes more sense to always 
align to a multiple of 1 KiB.
Reasons for this are:

1. For volume export/import, in 'write_common_header' we write the size 
of the file in bytes, in 'read_common_header' there is a check whether 
the size is a multiple of 1KiB.

So not all volumes exported with 'pvesm' can be imported with 'pvesm':

root at rob0 ~ # qm resize 128 scsi2 +512
Image resized.
root at rob0 ~ # pvesm export myfs:128/vm-128-disk-0.qcow2 qcow2+size 
myoddexport --with-snapshots
52816+0 records in
52816+0 records out
216334336 bytes (216 MB, 206 MiB) copied, 0.291073 s, 743 MB/s
root at rob0 ~ # pvesm import myfs:128/vm-128-disk-1.qcow2 qcow2+size 
myoddexport --with-snapshots
import: got a bad size (not a multiple of 1K), aborting.

2. Allocating volumes happens with a size in KiB, so maybe resizing 
should too? Internally we could switch the interface for 
'PVE::Storage::volume_resize' to use KiB instead of bytes and we could 
warn users which pass a non-KiB-multiple to 'qm resize', that we rounded 
up and didn't use the requested size exactly.

3. Many plugins already round the size anyways.

The same change as here in the first patch is also needed for callers of 
'vdisk_alloc', since the size the disk has after allocating might not be 
the requested size. For example in ZFSPoolPlugin size is aligned to 1M, 
LVM uses logical extents so the effective size is also often different 
from the parameter.

Related: I ran into a weird bug [0] yesterday, where a workaround would 
require the size being a multiple of 4KiB. But that could be done for 
the 'vdisk_alloc' call in 'vm_start'.

[0]: https://bugzilla.proxmox.com/show_bug.cgi?id=2562

More information about the pve-devel mailing list