[pve-devel] [PATCH v2 qemu-server] Fix block_resize qmp call for block devices

[Fabian Grünbichler]

On Thu, Jan 12, 2017 at 05:09:48PM +0300, Dmitry Petuhov wrote:
> 12.01.2017 16:18, Fabian Grünbichler пишет:
> > On Thu, Jan 12, 2017 at 03:33:48PM +0300, Dmitry Petuhov wrote:
> > > Set zero size for backing block devices in qmp call. In that case qemu
> > > sets size of device in guest to current size of backing device, which
> > > was resized earlier. Otherwise, any non-zero value causes error here.
> > this is not clearly documented, but if PVE::Storage::volume_resize
> > returns 1, we assume the storage layer did not resize and qemu should do
> > the resizing
> > 
> > if it returns undef, we assume the storage resized the volume and we are
> > done.
> There's problem: even if storage has resized blockdev, this change is not
> propagated to running qemu until we send block_resize to it.
> So we need to resize BOTH in storage AND in qemu.

yes, I was describing the current code here, and proposed a change
further down ;)

> 
> > so in the latter case, instead of returning in line 3983 we could set
> > $size to 0 (based on the return code of course ;)) and continue with the
> > running check and block_resize via monitor. this should only improve the
> > situation for all storages, without any wonky checks based on block
> > device or not.
> ZFS plugins are showing interesting behaviour here: return $new_size;
> Maybe we could do that in all plugins, that support resizing and just
> $size = PVE::Storage::volume_resize($storecfg, $volid, $size, $running);
> and then continue with any defined value (includig 0)?

see my other response to your patch series, IMHO we don't gain anything
by this vs. returning undef and passing 0 to qemu?