This PR enhances the existing CLVM implementation which was based on the deprecated CLVM technology which was based on corosync/pacemaker. With RHEL 7 having reached EOL, CLVM seems to be broken. CLVM supports RAW volumes on LVM , where as CLVM_NG support QCOW2 on LVM.
Further details: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Modernized+CLVM%3A+Enhancements+and+CLVM_NG+support
NOTE: On testing - it was identified that incremental snapshots for clvm-ng do not work as expected. As of now it's been removed from scope. So, CLVM and CLVM_NG would only support full snapshots.
* add support for proper cleanup of snapshots and prevent vol snapshot of running vm
* remove snap vol restriction for sunning vms
* refactor clvm code
* add support for live migration
* add support for migrating lvm lock
* clvm deletion called explicitly
* made necessary changes to allow migration of lock and deletion of detached volumes
* fix create vol from snap and attach
* add support to revert snapshot for clvm
* add support to revert snapshot for clvm
* make zero fill configurable
* make setting non-dynamic & fix test
* fix locking at vol/vm creation
* fix revert snapshot format type and handle revert snapshot functionality for clvm
* 1. Create clvmlockmanager and move common code \n
2. handle attaching volumes to stopped VMs \n
3. Handle lock transfer when VM is started on another host
* add license
* remove command/answer classes from sonar coverage check
* add support for new gen clvm with template (qcow2) backing
* Add support for clvm_ng - which allows qcow2 on block storage , linked clones, etc
* fix test and use physical size + 50% of virtual size for backing file, while virtual size + pe for disk
* migrate clvm volumes as full clone and allow migration from clvm to nfs
* fix clvm_ng to nfs migration, and handle overhead calc
* support live migration from clvm_ng to nfs and vice-versa
* add support to migrate to and from clvm to nfs
* fix creation of volume on destination host during migration to clvm/clvm-ng
* support live vm migration between clvm -> clvm-ng (vice-versa), nfs -> clvm (vice-versa) and nfs->clvm-ng (vice-versa)
* add unit tests for clvm/clvm_ng operations
* Add support for incremental volume snapshots for clvm_ng
* prevent snapshot backup for incremental clvm_ng snaps, fix build failure, add unit tests
* fix lockhost on creation of volumes from snap and fix bitmap issue when migrating a vol with incremental snap
* restrict pre and post migration commands to only kvm hosts where vm has CLVM/CLVM-NG volumes
* evist lock tracking - use lvs command to get lock host than DB
* add test for pre/post migration
* Create a CLVM storage adaptor
* update existing clvm get stats method
* fix precommit check failure
* Apply suggestions from code review
Co-authored-by: Suresh Kumar Anaparti <sureshkumar.anaparti@gmail.com>
* Apply suggestions from code review
Co-authored-by: Suresh Kumar Anaparti <sureshkumar.anaparti@gmail.com>
* improve lock host retrieval logic and quicker retrival using db host as first check point and then fanning out
* add proper support for resizing of clvm_ng which calculated PE correctly for qcow2 metadata
* fallback to full snapshots for clvm-ng - incremental not supported in 4.23
* expunge volume detail of lock host on vm expunge
* if vmmigration with volume is done to the same clvm volume group, then dont do data transfer, just lock transfer and vm
* add clvm pools with deterministic uuid , so as to prevent adding the same pool twic
* added a small improvement to factor in a senario when lv is inactive on all hosts, could happen in storage outage issue
* address comment - extract common code for endpoint identification if clvm pool type
* Address comments - add early return guard to reduce indentation
* minor improvement - when migrating vm with volumes, if there's a failures, change the clvm vols to exclusive on source from shared, and on success, change dest vol to exclusive only for cross-pool migration
* cleanup unused code and tests for incremental snaps for clvmng and other cleanups
* allow storage browser to list lv in clvm, fix clvm shrink, overprovisioning factor isnt used for clvm pools - so set it to 1 and prevented display of provisioning type for clvm
* no need to have locktransfercommand to execute in sequence
* increase lv cmd timeouts to consider cluster load
---------
Co-authored-by: Pearl Dsilva <pearl1954@gmail.com>
Co-authored-by: Suresh Kumar Anaparti <sureshkumar.anaparti@gmail.com>
This PR introduces the initial implementation of Veeam integration support for KVM in CloudStack by adding a UHAPI-compatible server and image server components.
Veeam Backup & Replication interacts with virtualization platforms using its Universal Hypervisor API (UHAPI). To enable backup and restore workflows for CloudStack-managed KVM environments, this change introduces a UHAPI server that exposes CloudStack resources through a UHAPI-compatible interface.
In addition to the control plane APIs, an image server component is introduced to handle the data transfer operations required during backup and restore workflows.
The integration consists of two main components:
1. UHAPI Server (Control Plane) named CloudStack Veeam Control Service
A lightweight UHAPI server runs inside the CloudStack management server and exposes endpoints under:
/ovirt-engine
- /api - For APIs
- /sso - For authentication
- /services/pki-resource - For certificates
This server provides inventory discovery APIs required by Veeam and translates CloudStack resources into the structures expected by UHAPI.
The server:
- exposes infrastructure inventory
- handles authentication and session tokens
- maps CloudStack resources to UHAPI-compatible representations
2. Image Server (Data Plane) named CloudStack Image Service
A separate image server component is introduced to handle backup and restore data transfer operations.
This component:
- serves disk image data during backup
- receives image data during restore operations
- exposes endpoints used by Veeam worker components
- integrates with CloudStack storage to read and write VM disk data
The separation between both these components server ensures that:
- metadata APIs and control operations remain lightweight
- bulk image transfer operations are handled independently
Signed-off-by: Abhishek Kumar <abhishek.mrt22@gmail.com>
Co-authored-by: Abhisar Sinha <63767682+abh1sar@users.noreply.github.com>
Co-authored-by: abh1sar <abhisar.sinha@gmail.com>
Co-authored-by: Wei Zhou <weizhou@apache.org>
This PR aligns the use of terminology, renaming VM / virtual machine references to 'Instance' and also capitalising the terms Templates, Network, Snapshot, User, Account in CloudStack APIs, error and log messages, events, tooltips, etc. Many typos, grammar and spelling mistakes were fixed, also terms like IPv4, VPN, VPC, etc. were properly capitalised. Some error messages were cleaned for better readability. The test cases, expecting some exception strings were adjusted accordingly.
Here is the wiki page, describing the changes in details:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Object+Naming+and+Title+Case+Convention
---------
Co-authored-by: Manoj Kumar <manojkr.itbhu@gmail.com>
Co-authored-by: Harikrishna <harikrishna.patnala@gmail.com>
* Migrate volume improvements, to bypass secondary storage when copy volume between pools is allowed directly
* Bypass secondary storage for copy volume between zone-wide pools and
- local storage on host in the same zone
- cluser-wide pools in the same zone
* Bypass secondary storage for volumes on ceph/rdb pool when the scope permits
* Fix dest disk format while migrating volume from ceph/rbd to nfs, and some code improvements
* unit tests
* Update suitable disk offering(s) for volume(s) after migrate VM with volumes when change in pool type (shared or local)
Currently, Migrate VM with volume(s) bypasses the service and disk offerings of the volumes, as the target pools for migration are specified,
which ignores the offerings. Offering change is required when pool type (shared or local) is changed, mainly
- when volume on shared pool is migrated to local pool
- when volume on local pool is migrated to shared pool
* Update with proper message while migrate volume when target pool and offering type mismatches (both are not shared/local)
* Consider host scope first during endpoint selection while copying between primary storages
* Update disk offering count (for listDiskOfferings api) while removing offerings with tags mismatch with storage tags
This feature adds the ability to create a new instance from a VM backup for dummy, NAS and Veeam backup providers. It works even if the original instance used to create the backup was expunged or unmanaged. There are two parts to this functionality:
Saving all configuration details that the VM had at the time of taking the backup. And using them to create an instance from backup.
Enabling a user to expunge/unmanage an instance that has backups.
The Extensions Framework in Apache CloudStack is designed to provide a flexible and standardised mechanism for integrating external systems and custom workflows into CloudStack’s orchestration process. By defining structured hook points during key operations—such as virtual machine deployment, resource preparation, and lifecycle events—the framework allows administrators and developers to extend CloudStack’s behaviour without modifying its core codebase.
* Introducing Storage Access Groups to define the host and storage pool connections
In CloudStack, when a primary storage is added at the Zone or Cluster scope, it is by default connected to all hosts within that scope. This default behavior can be refined using storage access groups, which allow operators to control and limit which hosts can access specific storage pools.
Storage access groups can be assigned to hosts, clusters, pods, zones, and primary storage pools. When a storage access group is set on a cluster/pod/zone, all hosts within that scope inherit the group. Connectivity between a host and a storage pool is then governed by whether they share the same storage access group.
A storage pool with a storage access group will connect only to hosts that have the same storage access group. A storage pool without a storage access group will connect to all hosts, including those with or without a storage access group.
* KVM incremental snapshot feature
* fix log
* fix merge issues
* fix creation of folder
* fix snapshot update
* Check for hypervisor type during parent search
* fix some small bugs
* fix tests
* Address reviews
* do not remove storPool snapshots
* add support for downloading diff snaps
* Add multiple zones support
* make copied snapshots have normal names
* address reviews
* Fix in progress
* continue fix
* Fix bulk delete
* change log to trace
* Start fix on multiple secondary storages for a single zone
* Fix multiple secondary storages for a single zone
* Fix tests
* fix log
* remove bitmaps when deleting snapshots
* minor fixes
* update sql to new file
* Fix merge issues
* Create new snap chain when changing configuration
* add verification
* Fix snapshot operation selector
* fix bitmap removal
* fix chain on different storages
* address reviews
* fix small issue
* fix test
---------
Co-authored-by: João Jandre <joao@scclouds.com.br>
Wei Zhou
dahn
Vishesh
Pearl Dsilva
Bryan Lima
Abhishek Kumar
Suresh Kumar Anaparti
Daan Hoogland
Abhisar Sinha
Fabricio Duarte
Daniel Augusto Veronezi Salvador
Daniel Augusto Veronezi Salvador
Erik Böck
Nicolas Vazquez
Tonitzpp
vladimirpetrov
John Bampton
João Jandre
slavkap
Harikrishna