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.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?
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@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
