[pve-devel] [PATCH qemu-server] Revert "resize_vm: request new size from storage after resizing"

[Fabian Ebner]

Any update on this? I feel like it's better to have the requested size 
in the config, even if it might be only approximately right in some 
cases (e.g. LVM rounds up to extents). At least that size will never be 
the old size (which might be vastly different and is sure to make users 
believe that the resize operation failed). For allocations we also only 
write the requested size to the config.

When we really need the exact size (e.g. online migration) we need to do 
a rescan/get it from the storage anyways. Also it's much more unlikely 
to hit the (I hope very brief) time window spanning from "after the QMP 
command finished" to "GlusterFS returns the new size" from a different 
operation, because of locks.

On 09.03.20 12:30, Fabian Ebner wrote:
> On 3/6/20 7:55 PM, Thomas Lamprecht wrote:
>> 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.ebner at 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?
> 
> AFAIU the QMP command has been fully issued, i.e. we already got a 
> response from the QMP socket. So the operation is blocking from a 
> QMP-interaction perspective, but not from the backing storage's 
> perspective.
> I can see that my commit message is not clear about that. With a local 
> filesystem I couldn't trigger the issue, but with a GluserFS storage it 
> happens consistently on my setup.
> 
>> Or let the storage backend tell us
>> anyway what aligned/rounded-up size it requested from qemu-img, zfs, ...?
>>
> 
> But for GlusterFS that can be the old size.
> Do you mean let volume_resize return the new size it used? It already 
> returns something else (see the following) and changing that would be a 
> breaking change.
> 
> Message for commit c1175c9264b57302d64fb697af589578d537d1e6 in qemu-server:
> 
>      add qemu_block_resize
> 
>      this call storage plugin resize first.
>      storage plugin will
>        return undef if we don't need to call qmp block_resize
>      or
>       return 1 if we need to call qmp block_resize
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel at pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>