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