Repository navigation
KVM: growing a ROOT volume through a new disk offering is refused while the VM is running, though a size-only resize of the same volume works #14601
Description
ISSUE TYPE
- Bug Report
COMPONENT NAME
Volumes / resizeVolume / changeOfferingForVolume
CLOUDSTACK VERSION
4.22 (also main)
CONFIGURATION
KVM, any primary storage; seen on Ceph RBD.
SUMMARY
On KVM, a ROOT volume of a running VM can be grown in place: resizeVolume id=<root> size=<larger> goes through orchestrateResizeVolume, which explicitly handles a running KVM VM (it checks the host is Up and Enabled), and the agent grows the disk with virsh blockresize.
Growing the same volume by giving it a larger disk offering is refused, whether through resizeVolume id=<root> diskofferingid=<larger offering> or changeOfferingForVolume:
Cannot resize ROOT volume [ROOT-123] when VM is not on Stopped State. VM i-2-123-VM is in state Running
The refusal comes from VolumeApiServiceImpl.checkIfVolumeIsRootAndVmIsRunning, which runs only on the two disk-offering paths and refuses any size change of a ROOT volume unless the VM is Stopped, on every hypervisor. It dates from #4341, when ROOT volumes were first allowed to change disk offering at all; the size-only path never had this restriction on KVM.
So on KVM the same grow is accepted or refused depending on which API is used to request it. Where the ROOT volume's offering fixes its size, the size-only path is refused too (the volume "can only be resized when changing to another Service Offering"), which leaves stopping the VM as the only way to grow its root disk.
STEPS TO REPRODUCE
1. On KVM, deploy a VM; leave it Running. 2. resizeVolume id=<its ROOT volume> size=<current GiB + 10> -> succeeds; the guest sees the larger disk. 3. Create a disk offering larger than the volume, then: resizeVolume id=<its ROOT volume> diskofferingid=<that offering> (or changeOfferingForVolume id=<ROOT volume> diskofferingid=<that offering>) -> "Cannot resize ROOT volume [...] when VM is not on Stopped State"
EXPECTED RESULTS
On KVM, growing a running VM's ROOT volume through a new disk offering succeeds, as the size-only resize already does. Shrinking a ROOT volume, and any ROOT resize on other hypervisors, still needs the VM to be stopped.
ACTUAL RESULTS
InvalidParameterValueException: Cannot resize ROOT volume [...] when VM is not on Stopped State.
Activity
github-actions commented on Nov 9, 2026
Warning
threat detection engine error
What happenedThe threat detection engine encountered an error and could not complete analysis. This is a tooling failure, not a security finding.
The threat detection engine failed to produce results.
Review the workflow run logs for details.
🎯 Triage report
On KVM, a running VM's ROOT volume can be grown with a size-only resizeVolume, but growing it through a larger disk offering (resizeVolume diskofferingid or changeOfferingForVolume) is refused. The refusal comes from checkIfVolumeIsRootAndVmIsRunning, which applies to every hypervisor and to any size change on the offering paths. The reporter asks that growing (not shrinking) on KVM be allowed through the offering path too.
📊 Assessment
🔗 Similar issues
- KVM: resizing an RBD volume fails with "Storage volume not found" until libvirt refreshes the pool #14622 (related) — KVM RBD volume resize fails until libvirt refreshes the pool
- CKS: scale requests without an offering (autoscaler, size, enabling autoscaling) resize every node to an outdated cluster-wide offering #14552 (related) — CKS scale requests resize nodes to an outdated offering
💡 Notes and suggestions- Reproduction is in the report: deploy a KVM VM, grow its ROOT volume by size, then try the same grow through a larger disk offering.
- Confirm the expected behaviour for other hypervisors stays unchanged.
Add this agentic workflow to your repoTo install this agentic workflow, run