codecov[bot]
commented
1 week ago Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 4.17%. Comparing base (
de683a5) to head (717d330).
Additional details and impacted files
```diff @@ Coverage Diff @@ ## main #9270 +/- ## ===================================== Coverage 4.17% 4.17% ===================================== Files 371 371 Lines 30407 30407 Branches 5384 5384 ===================================== Hits 1269 1269 Misses 28994 28994 Partials 144 144 ``` | [Flag](https://app.codecov.io/gh/apache/cloudstack/pull/9270/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | Coverage Δ | | |---|---|---| | [uitests](https://app.codecov.io/gh/apache/cloudstack/pull/9270/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache) | `4.17% <ø> (ø)` | | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=apache#carryforward-flags-in-the-pull-request-comment) to find out more.:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
weizhouapache
DaanHoogland
blueorangutan
alexandremattioli
JoaoJandre
github-actions[bot]
Description
This PR solves issue #8907.
Currently, when taking a volume snapshot/backup with KVM as the hypervisor, it is always a full snapshot/backup. However, always taking full snapshots of volumes is costly for both the storage network and storage systems. To solve the aforementioned issues, this PR extends the volume snapshot feature in KVM, allowing users to create incremental volume snapshots using KVM as a hypervisor.
To give operators control over which type of snapshot is being created, a new global setting
kvm.incremental.snapshothas been added, which can be changed at zone and cluster scopes; this setting is false by default. Also, thesnapshot.delta.maxconfiguration, used to control the maximum deltas when using XenServer, was extended to also limit the size of the backing chain of snapshots on primary/secondary storage.This functionality is only available in environments with Libvirt 7.6.0+ and qemu 6.1+. If the
kvm.incremental.snapshotsetting is true, and the hosts do not have the required Libvirt and qemu versions, an error will be thrown when trying to take a snapshot. Additionally, this functionality is only available when using file based storage, such as shared mount-point (iSCSI and FC that require a shared mount-point storage file system for KVM such as OCFS2 or GlusterFS), NFS, and local storage. Other storage types for KVM, such as CLVM and RBD, need different approaches to enable incremental backups; therefore, these are not currently supported.Issue #8907 has more details and flowcharts of all the mapped workflows.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Description of tests
During testing, the
kvm.incremental.snapshotsetting was changed totrueand thesnapshot.delta.maxsetting was changed to 3.Tests with snapshot.backup.to.secondary = false
For the tests in this section, a test VM was created and reused for all tests.
Snapshot creation tests
Snapshot restore tests
Snapshot removal tests
Template creation test
Tests with snapshot.backup.to.secondary = true
All tests performed in the previous sections were repeated with snapshot.backup.to.secondary = false, in addition, two additional tests were performed. For the tests in this section, a test VM was created and reused for all tests.
Snapshot creation tests