| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Codecov Report❌ Patch coverage is 72.16495% with 54 lines in your changes missing coverage. Please review. @@ Coverage Diff @@
## main #12975 +/- ##
=========================================
Coverage 18.09% 18.09%
- Complexity 16723 16732 +9
=========================================
Files 6037 6037
Lines 542580 542656 +76
Branches 66427 66436 +9
=========================================
+ Hits 98155 98191 +36
- Misses 433399 433443 +44
+ Partials 11026 11022 -4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry.
|
Sorry, something went wrong.
|
@bernardodemarco , this seems like a heavty change/fix. Do you think it makes sense to write an integration test for this? |
Sorry, something went wrong.
|
Hello, @DaanHoogland
I've checked the existing integration tests in the codebase and identified the test_17_running_vm_scaleup test in test_escalations_instances.py, which already covers the VM live scaling workflow. However, since this feature was not previously available for KVM, the test included a constraint to skip execution when the active hypervisor is KVM. I removed this constraint, so we can now observe how the test behaves. I believe that this integration test is sufficient. Most of the changes in the PR are on the Agent side and are well covered by unit tests. |
Sorry, something went wrong.
@erikbocks, thanks!
Sure, conflicts resolved! |
Sorry, something went wrong.
|
@bernardodemarco a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress. |
Sorry, something went wrong.
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 17846 |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM. Tested locally and everything worked as proposed. Below are described the test scenarios:
| Test | Behavior | Expected result |
|---|---|---|
| Disabled enable.dynamic.scale.vm and deploy a VM | The VM's XML definition was not ready for scaling. | Yes |
| Enabled the enable.dynamic.scale.vm configuration and deploy a VM | The VM's XML was ready for dynamic scaling. | Yes |
| Scaled a fixed offering VM to another offering with more CPU cores | The VM's domain XML was adjusted to the new offering's CPU amount | Yes |
| Scaled a fixed offering VM to another offering with more memory | The VM's domain XMl was adjusted to the new offering's memory amount | Yes |
| Scaled a fixed offering VM to another offering with more CPU MHz | The VM's domain XML was adjusted to the new offering's period | Yes |
| Tried to scale a VM to a offering with CPU cores above kvm.cpu.dynamic.scaling.capacity | An error was thrown. The logs informed that the offering's CPU cores was above permitted | Yes |
| Tried to scale a VM to a offering with memory above kvm.memory.dynamic.scaling.capacity | An error was thrown. The logs informed that the offering's memory was above permitted | Yes |
| Tried to scale a VM to a offering with more capacity than the current host when auto.migrate.vm.on.live.scale.insufficient.capacity was enabled | The VM was migrated to another node with sufficient capacity | Yes |
| Tried to scale a VM to a offering with more capacity than the current host when auto.migrate.vm.on.live.scale.insufficient.capacity was disabled | An error was thrown. The logs informed that the current host did not had enough capacity for the scaling | Yes |
Sorry, something went wrong.
|
@DaanHoogland @weizhouapache can we run the CI here one last time? |
Sorry, something went wrong.
|
@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
Sorry, something went wrong.
|
[SF] Trillian test result (tid-16148)
|
Sorry, something went wrong.
Add documentation and improved error messages to clarify version-specific constraints for live VM scaling: - CloudStack 4.22.1 and earlier: Live scaling only supported for custom constrained and custom unconstrained compute offerings - CloudStack 4.23.0+: Added support for live scaling with fixed service offerings on KVM hypervisors (see apache/cloudstack#12975) When scaling fails due to unsupported offering types, provide users with a helpful error message explaining the version constraints and suggesting they stop the VM if live scaling is not available.
Add documentation and improved error messages to clarify version-specific constraints for live VM scaling: - CloudStack 4.22.1 and earlier: Live scaling only supported for custom constrained and custom unconstrained compute offerings - CloudStack 4.23.0+: Added support for live scaling with fixed service offerings on KVM hypervisors (see apache/cloudstack#12975) When scaling fails due to unsupported offering types, provide users with a helpful error message explaining the version constraints and suggesting they stop the VM if live scaling is not available.
(cherry picked from commit 6b831f5)
| Back | FazBrowse Home | New Git URL |
Description
Apache CloudStack currently supports live scaling only for VMs with custom constrained and custom unconstrained compute offerings. For VMs with fixed compute offerings, users must stop the VM, change its service offering through the scaleVirtualMachine API and then start it again. Depending on the criticality of the applications running on the VM, the downtime caused by this process is highly undesirable.
Therefore, this PR introduces support for live scaling of VMs with fixed service offerings when using the KVM hypervisor in Apache CloudStack. The feature specification is available at #12908.
Fixes #12908 and fixes #6865
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Screenshots (if appropriate):
How Has This Been Tested?
Test environment setup
- Created multiple service offerings, including fixed and non-fixed offerings, with and without CPU cap enabled, with and without the dynamic scaling feature enabled:
Active service offeringsDefinition of the domain XML of the guest VMs
Verified that:
Live scaling
kvm.cpu.dynamic.scaling.capacity and kvm.memory.dynamic.scaling.capacity settings
auto.migrate.vm.on.live.scale.insufficient.capacity setting