bhouse-nexthop commented on PR #14602:
URL: https://github.com/apache/cloudstack/pull/14602#issuecomment-6733823839
### Test report: growing a running KVM VM's ROOT on Ceph RBD through a new
disk offering
**Environment**
- A CloudStack 24.0 (main) build with this PR applied, alongside some of my
other open PRs.
- Three KVM hosts on Ubuntu 24.04, nested virtualisation (QEMU 8.2.2); Ceph
RBD primary storage (Ceph 19.2).
- Disk offerings `root10`/`root20`/`root30`/`root40` (10 to 40 GB, on the
RBD tag).
- Compute offerings `so-r10` (1 vCPU, 1 GB, `root10`, not strict, dynamic
scaling on) and `so-r40` (2 vCPU, 2 GB, `root40`).
- VM G (Ubuntu 24.04) on `so-r10`, Running. `enable.dynamic.scale.vm=true`
was set before G started.
**A precondition I had to work around.** On this build, any resize of a
newly created RBD volume first fails in the agent, size-only resizes included:
```
org.libvirt.LibvirtException: Storage volume not found: no storage vol with
matching path 'cloudstack/<uuid>'
```
- The cause is a lookup through libvirt's pool cache in the resize wrapper.
That cache no longer gets refreshed on a miss since #14188. It is unrelated to
this PR, and affects any resize of a new RBD volume. I've opened #14623 to fix
it (issue #14622).
- On G's host, `virsh vol-list` did not list G's ROOT. After `virsh
pool-refresh`, the size-only control resize to 12 GB worked. I refreshed the
pool by hand before the steps below.
**1. `resizeVolume diskofferingid=root20`, VM running**
- It succeeds. The API reports 20 GB on `root20`, `virsh domblkinfo` and
`rbd info` report 20 GiB, and the VM stays Running.
- `lsblk` in the guest shows 20 GiB with no reboot. `growpart` + `resize2fs`
take `/` to 19G.
**2. `changeOfferingForVolume diskofferingid=root30`, VM running**
- It succeeds with the same checks: 30 GiB on the API, in libvirt, on RBD
and in the guest.
- `/` grows to 29G.
**3. `scaleVirtualMachine` to `so-r40`, with
`allow.diskoffering.change.during.scale.vm=true`**
- It succeeds. The VM is on `so-r40` with 2 vCPU and 2048 MB, and the ROOT
moves to `root40` at 40 GiB everywhere.
- `/` grows to 38G, and the guest's memory went to 1910 MB.
- The guest's `nproc` still showed 1. I did not chase that; it is about CPU
hot-plug, not the disk path this PR changes.
**4. Refusals**
- **Shrink** to `root10`, VM running: refused through `resizeVolume`,
through `changeOfferingForVolume`, and through `changeOfferingForVolume
shrinkok=true`, all with:
```
Cannot resize ROOT volume [ROOT-N] when VM is not on Stopped State. VM
i-N-VM is in state Running. Only growing the ROOT volume of a Running KVM user
VM is allowed without stopping it.
```
- **Migrating VM:** M (4 GB RAM, with 3.4 GB of it filled from
`/dev/urandom` so the migration takes a while) was live-migrated. While it was
`Migrating`, `resizeVolume diskofferingid=root20` was refused with the same
message (`... is in state Migrating`). The migration completed. Once M was
Running on the new host, the same resize succeeded.
- **Router ROOT through an offering:** refused, but by the existing
disk-offering tag check (`There are no tags on the current disk offering ...`)
before this PR's check is reached. So this run does not exercise the PR's
user-VM-only condition for a router.
**Observed, not changed by this PR:** a *size-only* `resizeVolume size=20`
on a running router's ROOT is accepted, as on stock. The size-only path never
had the running-VM check. The RBD image and the DB went to 20 GiB, but qemu was
not told (`domblkinfo` still shows the old size), because the resize
orchestration only notifies a running user VM. The router keeps running and
sees the new size at its next start.
**Without the PR** (not rerun on a stock build): steps 1-3 are refused on
stock with `Cannot resize ROOT volume [...] when VM is not on Stopped State`,
the same check without the KVM grow exception. The size-only control above was
allowed before and after.
**Result:** pass.
- Growing a running KVM VM's ROOT through a new offering works in all three
APIs, and the guest sees the new size live.
- Shrink, and grow on a Migrating VM, are refused.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
