[PATCH 1/1] qemu: refresh disk->src->capacity after block_resize
qemuDomainBlockResize() issues block_resize via QMP, which updates the qcow2 header on disk and bs->total_sectors in qemu, but the cached disk->src->capacity in libvirt is left at its pre-resize value. All current readers re-read capacity from either QMP or the file itself before returning to the user, so the staleness is not externally observable today. Still, the cached field should reflect what we just asked qemu to write; keeping the two in sync avoids surprises for any future consumer that trusts the cached value. Signed-off-by: Denis V. Lunev <den@openvz.org> CC: Peter Krempa <pkrempa@redhat.com> CC: Michal Privoznik <mprivozn@redhat.com> --- src/qemu/qemu_driver.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 2d31d4aa31..a419c5cc95 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -9598,6 +9598,9 @@ qemuDomainBlockResize(virDomainPtr dom, } qemuDomainObjExitMonitor(vm); + /* Keep the cached capacity in sync with qemu representation. */ + disk->src->capacity = size; + if (persistDisk) { g_clear_pointer(&persistDisk->src->sliceStorage, virStorageSourceSliceFree); qemuDomainSaveConfig(vm); -- 2.51.0
On Mon, May 11, 2026 at 22:21:35 +0200, Denis V. Lunev wrote:
qemuDomainBlockResize() issues block_resize via QMP, which updates the qcow2 header on disk and bs->total_sectors in qemu, but the cached disk->src->capacity in libvirt is left at its pre-resize value.
All current readers re-read capacity from either QMP or the file itself before returning to the user, so the staleness is not externally observable today. Still, the cached field should reflect what we just asked qemu to write; keeping the two in sync avoids surprises for any future consumer that trusts the cached value.
None of those values are stored in the status XML so they will be missing in certain situations. Each caller who wants to read the 'capacity', 'allocation' or 'physical' field *must* update it before any read. The commit message doesn't IMO provide enough justification to do this since each caller will update it.
On 5/11/26 22:37, Peter Krempa wrote:
On Mon, May 11, 2026 at 22:21:35 +0200, Denis V. Lunev wrote:
qemuDomainBlockResize() issues block_resize via QMP, which updates the qcow2 header on disk and bs->total_sectors in qemu, but the cached disk->src->capacity in libvirt is left at its pre-resize value.
All current readers re-read capacity from either QMP or the file itself before returning to the user, so the staleness is not externally observable today. Still, the cached field should reflect what we just asked qemu to write; keeping the two in sync avoids surprises for any future consumer that trusts the cached value. None of those values are stored in the status XML so they will be missing in certain situations. Each caller who wants to read the 'capacity', 'allocation' or 'physical' field *must* update it before any read.
The commit message doesn't IMO provide enough justification to do this since each caller will update it.
we have faced problem in downstream with a surprise that this value is stale but that could be not a very good reason to make this in. Would it worth to make a comment in the header instead that this value is unreliable and should be re-read? Den
On Mon, May 11, 2026 at 22:46:01 +0200, Denis V. Lunev wrote:
On 5/11/26 22:37, Peter Krempa wrote:
On Mon, May 11, 2026 at 22:21:35 +0200, Denis V. Lunev wrote:
qemuDomainBlockResize() issues block_resize via QMP, which updates the qcow2 header on disk and bs->total_sectors in qemu, but the cached disk->src->capacity in libvirt is left at its pre-resize value.
All current readers re-read capacity from either QMP or the file itself before returning to the user, so the staleness is not externally observable today. Still, the cached field should reflect what we just asked qemu to write; keeping the two in sync avoids surprises for any future consumer that trusts the cached value. None of those values are stored in the status XML so they will be missing in certain situations. Each caller who wants to read the 'capacity', 'allocation' or 'physical' field *must* update it before any read.
The commit message doesn't IMO provide enough justification to do this since each caller will update it.
we have faced problem in downstream with a surprise that this value is stale but that could be not a very good reason to make this in.
No. Well unless the "downstream" code you have will be upstreamed. But then still it's not a good idea to in any way rely on that value, so really no.
Would it worth to make a comment in the header instead that this value is unreliable and should be re-read?
Yes, you can add a comment to the virStorageSource struct stating that unless updated the values don't represent reality. In addition you can state that 'allocation' is ultra-unreliable because any guest write to a previously unallocated part of the sparse image invalidates that value even if the value is not 0/seems updated.
participants (1)
-
Denis V. Lunev -
Denis V. Lunev -
Peter Krempa