mirror of https://github.com/apache/cloudstack.git
089eb36e47
* Linstor: fix create volume from snapshot on primary storage When creating a volume from a snapshot on Linstor primary storage (with lin.backup.snapshots=false), the operation fails with: "Only the following image types are currently supported: VHD, OVA, QCOW2, RAW (for PowerFlex and FiberChannel)" Root cause: the Linstor driver does not handle SNAPSHOT -> VOLUME in its canCopy()/copyAsync() methods. This causes DataMotionServiceImpl to fall through to StorageSystemDataMotionStrategy (selected because Linstor advertises STORAGE_SYSTEM_SNAPSHOT=true). That strategy's verifyFormatWithPoolType() rejects RAW format for Linstor pools, since RAW is only allowed for PowerFlex and FiberChannel. Additionally, VolumeOrchestrator.createVolumeFromSnapshot() attempts to back up the snapshot to secondary storage when the storage plugin does not advertise CAN_CREATE_TEMPLATE_FROM_SNAPSHOT. This backup fails because the snapshot only exists on Linstor primary storage. Fix: - Add CAN_CREATE_TEMPLATE_FROM_SNAPSHOT capability so the orchestrator skips the backup-to-secondary path - Add canCopySnapshotToVolumeCond() to match SNAPSHOT -> VOLUME when both are on the same Linstor primary store - Wire it into canCopy() to intercept at DataMotionServiceImpl before strategy selection, bypassing StorageSystemDataMotionStrategy - Implement copySnapshotToVolume() which delegates to the existing createResourceFromSnapshot() for native Linstor snapshot restore This follows the same pattern used by the StorPool plugin, which handles SNAPSHOT -> VOLUME directly in its driver rather than going through StorageSystemDataMotionStrategy. Tested on CloudStack 4.22 with Linstor LVM_THIN storage, creating a volume from a 1TB CNPG Postgres database snapshot. Volume creates successfully with correct path and deletes cleanly. * Let CloudRuntimeException propagate from copySnapshotToVolume Remove try/catch in copySnapshotToVolume so that CloudRuntimeException from createResourceFromSnapshot propagates to the caller, ensuring CloudStack properly notices and reports the failure. * Fix CAN_CREATE_TEMPLATE_FROM_SNAPSHOT breaking template creation Setting CAN_CREATE_TEMPLATE_FROM_SNAPSHOT unconditionally to true caused createTemplate from snapshot to take the StorPool-specific code path in TemplateManagerImpl, which sends a CopyCommand to a system VM that Linstor cannot handle. Fix: make CAN_CREATE_TEMPLATE_FROM_SNAPSHOT conditional on the same flag as STORAGE_SYSTEM_SNAPSHOT (!BackupSnapshots). When snapshots are backed up to secondary (the default), the old template creation flow works. When snapshots stay on primary, the direct path is used. Also fix checkstyle: remove unused DataObject import in test. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| acl | ||
| affinity-group-processors | ||
| alert-handlers | ||
| api | ||
| backup | ||
| ca/root-ca | ||
| database | ||
| dedicated-resources | ||
| deployment-planners | ||
| drs/cluster | ||
| event-bus | ||
| ha-planners/skip-heurestics | ||
| host-allocators/random | ||
| hypervisors | ||
| integrations | ||
| maintenance | ||
| metrics | ||
| network-elements | ||
| outofbandmanagement-drivers | ||
| storage | ||
| storage-allocators/random | ||
| user-authenticators | ||
| user-two-factor-authenticators | ||
| pom.xml | ||