rp- opened a new pull request, #14658:
URL: https://github.com/apache/cloudstack/pull/14658
### Description
This PR makes the LINSTOR plugin record the size of a volume's DRBD device
as the volume size in CloudStack.
LINSTOR rounds the storage of a volume up (e.g. to the LVM extent size, plus
DRBD metadata) and DRBD makes all of
it usable, so the block device a VM sees is usually a few MiB larger than
the size CloudStack requested and
records. Examples from a 3-node LVM-thin setup:
| requested / recorded by CloudStack | device seen by the guest |
|---|---|
| 536870912 (512 MiB, template clone) | 540909568 |
| 1073741824 (1 GiB data disk) | 1077665792 |
Filesystems the guest creates on the whole disk, or grows to its end (e.g.
cloud-init growpart), use that space,
but the copies CloudStack makes of the volume are cut at the recorded size:
snapshot backups to secondary storage
are shrunk to it, so the last few MiB of the disk are missing in the backup,
and a volume or template created from
such a copy then holds a filesystem that is larger than its disk.
The driver now:
- records the device size after creating a volume (new, cloned from a
template, or from a snapshot) and after a
resize, and passes the device size to the hypervisor in the resize
notification,
- corrects existing volumes before taking a snapshot and before copying a
volume to secondary storage, so
snapshot backups and volume copies cover the whole device,
- only ever grows the recorded size; if the device size can't be read from
LINSTOR the recorded size is kept,
- counts the difference against the account's primary storage resource
count, except on resize, where the
orchestrator already counts the (now recorded) size.
The device size is the smallest usable size of the top layer (DRBD, LUKS or
storage) over the diskful resources;
diskless resources only report the size of the volume definition. With
`DrbdOptions/ExactSize` set on the resource
definition the device has the size of the volume definition, which is used
as is.
Volumes created on the agent side (e.g. migrated into LINSTOR) are corrected
at their next snapshot or copy.
<!--- Describe your changes in DETAIL - And how has behaviour functionally
changed. -->
<!-- For new features, provide link to FS, dev ML discussion etc. -->
<!-- In case of bug fix, the expected and actual behaviours, steps to
reproduce. -->
<!-- When "Fixes: #<id>" is specified, the issue/PR will automatically be
closed when this PR gets merged -->
<!-- For addressing multiple issues/PRs, use multiple "Fixes: #<id>" -->
<!-- Fixes: # -->
<!---
*******************************************************************************
-->
<!--- NOTE: AUTOMATION USES THE DESCRIPTIONS TO SET LABELS AND PRODUCE
DOCUMENTATION. -->
<!--- PLEASE PUT AN 'X' in only **ONE** box -->
<!---
*******************************************************************************
-->
### Types of changes
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] New feature (non-breaking change which adds functionality)
- [x] 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
- [ ] Major
- [ ] Minor
#### Bug Severity
- [ ] BLOCKER
- [ ] Critical
- [x] Major
- [ ] Minor
- [ ] Trivial
### Screenshots (if appropriate):
### How Has This Been Tested?
Unit tests (`LinstorUtilTest`, `LinstorPrimaryDataStoreDriverImplTest`) for
the device size (smallest diskful
DRBD device, no DRBD layer, `DrbdOptions/ExactSize`, fallback to the volume
definition, missing resource
definition) and for recording it (larger device, no resource count
adjustment on resize, never shrinking, LINSTOR
API failure).
3-node KVM cluster with CloudStack 4.23 and this patch applied to the
LINSTOR plugin, LINSTOR primary storage
(LVM-thin, DRBD 9.3, LINSTOR 1.35):
- snapshot of an existing 1 GiB data volume created before the patch: the
recorded size changed from 1073741824 to
1077665792, the account's primary storage count rose by exactly the
difference, and the backed up qcow2 on
secondary storage has a virtual size of 1077665792 bytes
- new data volume, attached and resized: the recorded size equals the size
the guest sees after the resize, the
resource count matches
- new VM: the ROOT volume cloned from the template records 540909568 bytes,
the size the guest sees
#### How did you try to break this feature and the system with this change?
Covered by the unit tests:
- Resources with diskless replicas (they only report the volume definition
size and are ignored) and resource
definitions with `DrbdOptions/ExactSize`.
- LINSTOR API failures while reading the size: the recorded size is kept and
the operation continues.
- A volume whose device size is already recorded: no further size or
resource count changes.
<!-- Please read the
[CONTRIBUTING](https://github.com/apache/cloudstack/blob/main/CONTRIBUTING.md)
document -->
--
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]
