Repository navigation
resizeVolume of a running system VM's volume is accepted but the VM never sees the new size #14645
Description
problem
A size-only resizeVolume of a running system VM's volume, for example a virtual router's ROOT, is accepted and resizes the volume on the storage. The running system VM is never told, so the guest keeps seeing the old size until it next starts. The API, the database and the storage all report the new size while the VM still runs on the old one.
VolumeApiServiceImpl.orchestrateResizeVolume only looks the VM up as a user VM (_userVmDao.findById). For a system VM that returns null, so the resize is sent with the instance name none and no host. On KVM the image is grown, but virsh blockresize is never run for the running domain. The per-hypervisor checks in the same method (XenServer can only resize a stopped VM's disk; on KVM the VM's host must be Up and Enabled) are skipped for the same reason.
Other paths already treat system VM volumes differently:
- volume snapshots of system VM volumes are refused;
- attach and detach accept only user VMs;
- a ROOT resize through a new disk offering is refused unless the VM is Stopped.
The size-only path has no such check.
versions
4.22, and main.
The steps to reproduce the bug
Seen on KVM with Ceph RBD primary storage:
- Take a running virtual router whose ROOT disk offering is not size-strict.
- Call
resizeVolume id=<router ROOT volume> size=<larger size in GB>. - The call succeeds.
listVolumesandrbd infoshow the new size. - On the host,
virsh domblkinfo <router> vdastill shows the old size, and so doeslsblkin the router. The new size only appears after the router is restarted.
What to do about it?
Refuse to resize the volume of a system VM that is not Stopped, with an error telling the admin to stop it first. Resizing it while it is stopped keeps working as before, and the VM sees the new size when it starts.
Doing the resize live instead would mean running the system VM's resize through the VM work queue and notifying the hypervisor, as is done for user VMs, and checking that on each hypervisor. Refusing is the smaller, safer change.
Activity
Refuse to resize the volume of a running system VM
Refuse to resize the volume of a running system VM
github-actions commentedon Nov 11, 2026
Warning
threat detection engine error
The threat detection engine encountered an error and could not complete analysis. This is a tooling failure, not a security finding.
What happened
The threat detection engine failed to produce results.
Review the workflow run logs for details.
🎯 Triage report
A size-only
resizeVolumeof a running system VM's volume succeeds, but the running VM never sees the new size.orchestrateResizeVolumelooks the VM up only as a user VM, so for a system VM it sends the resize with no instance and skips the hypervisor checks. On KVM the image grows, butvirsh blockresizeis never run for the domain. The reporter proposes refusing the resize unless the system VM is stopped, which keeps the current stopped-VM behaviour.📊 Assessment
VolumeApiServiceImpl🔗 Similar issues
💡 Notes and suggestions
virsh domblkinfoandlsblkin the router.Add this agentic workflow to your repo
To install this agentic workflow, run