bhouse-nexthop opened a new pull request, #14112:
URL: https://github.com/apache/cloudstack/pull/14112
### Description
Lets a service offering set its own overcommit ratio, overriding whatever
its cluster is set to.
**The problem.** A cluster's overcommit ratio applies to every VM on it, and
the per-VM detail that
records it was force-synced to the cluster's value on every start, so there
was no way to exempt
anything. On a cluster overcommitted for workloads that are idle most of the
time, infrastructure
VMs are overcommitted too, whether or not that is safe for them.
**How it works.** An offering may set `cpuOvercommitRatio` or
`memoryOvercommitRatio` in its details
- the same detail keys already used at cluster and VM scope. Absent, the
cluster's ratio applies as
before, so nothing changes for existing offerings.
The value means the same thing at every scope: how far a VM's declared size
is inflated relative to
what it really holds.
| Value | Meaning |
|---|---|
| `1` | Not overcommitted. The VM is charged its full real footprint and
holds all of it |
| `4` | Oversubscribed four times |
| absent | Inherit the cluster |
Values below 1 would mean reserving *more* than the VM asked for. That is a
different feature and is
rejected, rather than being reachable by mistyping `1` as `0.1` - which
would have charged the VM
ten times its size. An offering may declare a ratio higher than its
cluster's; the value is absolute
rather than relative, so there is no contradiction in that, and it is logged.
**Memory really is held.** An offering with a memory ratio of 1 also has
free page reporting and
balloon auto-deflate turned off for its VMs, so the guest does not lend
unused memory back to the
host. Without that the exemption would hold in the books only. The balloon
device itself stays, so
memory statistics are unaffected. This applies only when the offering has
explicitly asked - an
offering that says nothing inherits its cluster, and a cluster with no
overcommit configured is the
default everywhere.
### Also fixes a latent accounting bug
Capacity is counted in cluster-overcommitted units: totals are stored raw
and multiplied by the
cluster ratio when read. The periodic recalculation in
`updateCapacityForHost` already scaled each
VM by the ratio it started under, but the incremental paths did not - they
charged the raw request.
The two agree only while every VM shares its cluster's ratio, which was true
because of the
force-sync described above. It becomes observable as soon as ratios differ,
which is what this
feature causes, so it is fixed here as the first commit. **No behaviour
change while ratios are
uniform.**
Everything that asks "does this host have room" now asks in the same units
the charge will use, so a
VM cannot pass a capacity check and then fail to start.
### Types of changes
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] Enhancement (improves an existing feature and functionality)
- [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
- [ ] Build/CI
- [ ] Test (unit or integration test code)
### Feature/Enhancement Scale or Bug Severity
#### Feature/Enhancement Scale
- [x] Major
- [ ] Minor
### How Has This Been Tested?
- `CapacityManagerScaleToClusterUnitsTest` - 7 cases on scaling a request
into capacity units: a VM
inheriting its cluster is charged as requested; one exempted from an
overcommitted cluster is
charged its full share; one left over from an earlier cluster setting is
rescaled; nonsense values
fall back.
- `VirtualMachineManagerOverCommitTest` - 15 cases on what an offering asks
for and what gets
recorded on the VM, including the two review findings below and the rule
for when memory reclaim
is turned off.
- `ConfigurationManagerOverCommitDetailTest` - 7 cases on validation,
including the floor at 1.
- `LibvirtVMDefTest` - the domain XML with reclaim disabled: no
`freePageReporting`, no
`autodeflate`, balloon device and statistics still present.
Full `mvn test` on `engine/components-api`, `engine/orchestration`, `server`
and the KVM plugin with
checkstyle and license checks enabled: 0 failures.
#### How did you try to break this feature and the system with this change?
Adversarial review found two defects that made the branch worse than what it
replaced. Both fixed:
- **The headline case was not charged.** The ratio was recorded on the VM
only when it differed from
1, so an offering asking for a ratio of 1 on an overcommitted cluster
recorded nothing and the
charge fell back to the cluster's ratio - a tenth of what the VM occupies
at a factor of 10. The
memory pinning still applied, so the host really did hold memory it was
not charged for. Ten such
VMs would fit where one should.
- **Memory reclaim was disabled on every VM of every default installation.**
The trigger was "the
resolved ratio is 1", and clusters ship with a ratio of 1, so on upgrade
every KVM guest would
have lost free page reporting at its next start on installations that
opted into nothing. Now
triggers on the offering having explicitly asked.
Also checked: rounding against `updateCapacityForHost` (brute-forced across
~140k RAM and CPU
combinations - identical whenever the detail is present); the ordering of
the capacity charge
against the detail being written; unreadable and out-of-range values on both
the offering and the VM
detail; and that the charge and the refund use the same figure.
Known remaining gaps, all self-healing at the next capacity recalculation
and worth calling out
rather than hiding: a cross-cluster migration rewrites the VM's ratio before
the source host is
refunded, so the refund can use a different ratio to the charge; and a
scale-up does not re-resolve
the ratio, so a VM keeps the ratio from its last start until it next stops
or migrates.
--
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]
