bhouse-nexthop commented on PR #14112:
URL: https://github.com/apache/cloudstack/pull/14112#issuecomment-6740298369
### Test report: per-offering overcommit ratios
**Environment**
- A CloudStack 24.0 (main) build with this PR applied, alongside some of my
other open PRs, including #14109.
- In that build the PR is combined with my other open PRs, which needed some
conflicts resolved. So this covers the same code as merged alongside them, not
the exact PR head.
- Three KVM hosts on Ubuntu 24.04 (libvirt 10.0.0, QEMU 8.2.2), nested
virtualisation; Ceph RBD primary storage; one management server.
- Cluster overcommit set for the test: `cpu.overprovisioning.factor=4`,
`mem.overprovisioning.factor=2` (cluster scope).
- Offerings:
- `exempt`: 1 vCPU, 1000 MHz, 1024 MB, with `cpuOvercommitRatio=1` and
`memoryOvercommitRatio=1` as service offering details;
- `normal`: the same size, no details.
- Test VMs are CirrOS, deployed with `hostid=` to one host. Capacity figures
are from `op_host_capacity` for that host.
**1. Capacity charged at start**
| | memory used | CPU used |
|---|---|---|
| before | 10752 MiB | 6000 MHz |
| + `exempt` VM | **+2048 MiB** | **+4000 MHz** |
| + `normal` VM | +1024 MiB | +1000 MHz |
Capacity is counted in cluster-overcommitted units. So the exempt VM is
charged its full size at the cluster's ratios (1024 × 2 and 1000 × 4), and the
normal VM at its nominal size.
**2. The periodic and incremental paths agree**
- Across one periodic capacity recalculation
(`capacity.check.period=300000`; `Executing cpu/ram capacity update` at
12:13:24), used memory and CPU were unchanged.
- Stop, then start on the same host:
- `exempt` stopped: used −2048 MiB / −4000 MHz, reserved +2048 MiB / +4000
MHz. Started: back to exactly the earlier figures.
- `normal` stopped: used −1024 / −1000, reserved +1024 / +1000. Started:
back exactly.
- One more periodic recalculation: still no change. No drift.
**3. VM details**
- `exempt`: `cpuOvercommitRatio=1.0, memoryOvercommitRatio=1.0,
memoryReclaimDisabled=true`
- `normal`: `cpuOvercommitRatio=4.0, memoryOvercommitRatio=2.0`. No
`memoryReclaimDisabled`.
**4. libvirt**
```
exempt: <memballoon model='virtio'>
balloon.current=1048576 balloon.maximum=1048576
balloon.available=971668 balloon.rss=260484
normal: <memballoon model='virtio' autodeflate='on' freePageReporting='on'>
balloon.current=524288 balloon.maximum=524288
balloon.available=390036 balloon.rss=279240
```
- The exempt VM keeps its balloon device, so balloon statistics are still
reported, but it has no auto-deflate and no free-page reporting.
- It also gets its full 1 GiB as current memory. The normal VM gets 512 MiB,
which is the existing behaviour of an overcommitted cluster.
**5. Validation**
- `memoryOvercommitRatio=0.5`: refused, `Service offering detail
memoryOvercommitRatio must be at least 1, got [0.5]. 1 means the offering is
not overcommitted; ...`
- `=abc`: refused, `... must be a number, got [abc].`
- `=0`: refused, `... must be at least 1, got [0].`
- `=8` (above the cluster's 2) was accepted. A VM started on it logged:
```
Service offering 23 declares memoryOvercommitRatio of 8.0, more than its
cluster's 2.0, so its VMs are oversubscribed further than the cluster default.
```
**6. Placement uses the same units**
- I filled the host with exempt VMs using `hostid=`: 4096 MB exempt VMs
until refused, then 1024 MB ones.
- Memory used went 13824 → 22016 → … → 54784 MiB, +8192 per 4 GB VM. The 6th
4 GB VM was refused. One 1 GB VM fitted (56832 MiB), and the next was refused.
- Both refusals happened at planning. No `StartCommand` was sent, and the
VMs ended in `Error` with no host. The planner asked in charge units:
```
Checking if host: Host {..."host1"...} has enough capacity for requested
CPU: 4000 and requested RAM: (2.00 GB) 2147483648 , cpuOverprovisioningFactor:
4.0
Free RAM: (1.23 GB) 1322369024 , Requested RAM: (2.00 GB) 2147483648
Host does not have enough RAM available, cannot allocate to this host.
```
That was a 1 GB exempt VM, asked for as 2 GB.
- The 6 VMs that did start used little real memory: the host still had about
17 GB available.
**7. A cluster with no overcommit is unaffected**
- With the cluster back at 1 / 1, a `normal` VM had `<memballoon
model='virtio' autodeflate='on' freePageReporting='on'>`.
- It had no overcommit or reclaim details. This was the review regression.
**8. The offering form**
- I did not drive the browser. The deployed UI bundle does contain the new
fields.
- I sent the API calls exactly as the updated add and clone views build them:
- **Add**, with ImplicitDedicationPlanner (mode Strict) plus both ratios
at running indexes 0, 1 and 2: all three details were stored
(`ImplicitDedicationMode=Strict, cpuOvercommitRatio=1,
memoryOvercommitRatio=1`). The same request with two details both at index 0,
which is what the old hard-coded index produced, kept only one.
- **Clone**, with the ratios lifted out of the details map into
`serviceofferingdetails`: the clone has the same three details and no
`External:` keys. For comparison, the old view's request, with the whole
details map in `externaldetails`, stored `External:cpuOvercommitRatio=1,
External:memoryOvercommitRatio=1, External:ImplicitDedicationMode=Strict`.
**Result:** pass.
- Exempt VMs are charged and placed in the same units: the periodic,
start/stop and planning paths agree.
- Their memory is not lent back to the host.
- Invalid ratios are refused.
- A default install keeps free-page reporting.
**Not covered**
- The UI forms in a browser.
- Non-KVM hypervisors, and changing a cluster's ratio while exempt VMs are
running.
- Scaling an exempt VM.
--
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]
