bhouse-nexthop commented on PR #14623:
URL: https://github.com/apache/cloudstack/pull/14623#issuecomment-6737449000
### Test report: resizing RBD volumes that libvirt has not cached, with no
manual pool refresh
**Environment**
- A CloudStack 24.0 (main) build with this PR applied, alongside some of my
other open PRs, including #14188 (merged) and #14602.
- Why the result carries over to 4.22: the resize wrapper and the RBD lookup
in `getPhysicalDisk()` (#14188) are the same on 4.22 and main.
- Three KVM hosts on Ubuntu 24.04 (libvirt 10.0.0, QEMU 8.2.2), nested
virtualisation. Ceph RBD primary storage (squid 19.2.3).
- Ubuntu 24.04 guests on `so-r10` (1 vCPU, 1 GB, ROOT on `root10`, 10 GB),
on a fresh deploy each time.
- I did **not** run `virsh pool-refresh` at any point. Before each resize, I
checked whether the image was in libvirt's view of the pool with `virsh
vol-list <pool>` on the VM's host.
**1. Size-only resize of a fresh VM's ROOT, VM running**
- Before: the ROOT image was **not** in `virsh vol-list` on the host.
- `resizeVolume size=12` succeeded in 4 s. The API, `virsh domblkinfo`, `rbd
info` and the guest's `lsblk` all showed 12 GiB, with no reboot. The VM stayed
Running.
- The agent logged the refresh once:
```
INFO [resource.wrapper.LibvirtResizeVolumeCommandWrapper] Volume
cloudstack/<uuid> is not in libvirt's cache of RBD pool <pool>
(Storage volume not found: no storage vol with matching path
'cloudstack/<uuid>'). Refreshing the pool and looking the volume up again.
```
- After: the image was in `virsh vol-list`.
- A second resize of the same volume (`size=14`) succeeded with no refresh
line, because the lookup hit the cache. So the refresh happens only on a miss.
All four views showed 14 GiB.
On the build without this PR, the same first resize failed with `Storage
volume not found: no storage vol with matching path 'cloudstack/<uuid>'` (see
#14622). That is the failure this PR fixes.
**2. Data volume, created, attached and resized while attached to the
running VM**
- A 5 GB volume on the `Custom` offering, attached to the VM from step 1.
The guest saw it as `vdb`.
- `resizeVolume size=8` succeeded in 5 s. API, libvirt, RBD and the guest's
`lsblk /dev/vdb` all showed 8 GiB.
- On this host the image was already in libvirt's cache before the resize,
so the resize found it on the first lookup and logged no refresh. The pool
refresh from step 1 ran before this volume existed, so the attach must have put
it in the cache. This step shows the normal path still works, and that the
retry stays out of the way when it isn't needed.
**3. `resizeVolume diskofferingid=root20` on a fresh running VM (the #14602
path)**
- A second fresh VM, on another host. Its ROOT was not in `virsh vol-list`
there.
- `resizeVolume diskofferingid=root20` succeeded in 5 s, and the volume is
now on `root20` at 20 GiB in all four views. The VM stayed Running.
- The agent logged the same single refresh-and-retry line.
- In the guest, `growpart` and `resize2fs` grew `/` to 19G.
**Result:** pass.
- A resize of an RBD volume that is not in libvirt's pool cache now
refreshes the pool once and succeeds, for a size-only ROOT resize, a data
volume, and a resize through a new disk offering.
- No manual `virsh pool-refresh` was needed. When the volume is already
cached, the resize doesn't refresh.
**Not covered**
- A refresh that fails (the warning path), and a volume that is still
missing after the refresh. Both are covered by the unit tests.
- Encrypted RBD volumes, and non-RBD pools. Neither goes through the retry.
--
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]
