andrijapanicsb opened a new pull request, #13365:
URL: https://github.com/apache/cloudstack/pull/13365
### Description
This PR allows `importVm` (`importsource=shared`, KVM) to adopt an existing
**ROOT** volume that lives on an **RBD (Ceph)** primary storage pool.
Previously such an import failed with `Disk not found or is invalid`
(jobresultcode 530).
Two things were blocking it:
1. **Agent side** — `LibvirtCheckVolumeCommandWrapper` (which backs the
`CheckVolumeCommand` issued during the import) only whitelisted file-based
pools (`Filesystem`, `NetworkFilesystem`, `SharedMountPoint`) and inspected the
volume with direct file reads (`checkQcow2File` / `getVirtualSizeFromFile`).
Those do not work on RBD, so the command returned `Unsupported Storage Pool`,
the server-side `instanceof CheckVolumeAnswer` cast failed, and the import was
rolled back with `Disk not found or is invalid`.
RBD is now supported by inspecting the volume through the RBD URI via
`qemu-img` — the same approach already used by
`LibvirtGetVolumesOnStorageCommandWrapper`, which backs `listVolumesForImport`
and already works on RBD. For raw RBD images the QCOW2 validation is skipped,
the virtual size comes from the pool-reported disk, and the encrypted /
backing-file / locked details are still collected so the existing server-side
import validations keep working.
2. **Server / engine side** — `VolumeOrchestrator.importVolume()` and
`updateImportedVolume()` hardcoded the KVM volume format to `QCOW2`. RBD-backed
volumes are `RAW`. The format is now derived from the storage pool type (RBD →
RAW) via a single shared helper, applied at both import call sites.
No new server-side guardrails were required: `importKVMSharedDisk` is
already pool-type agnostic and passes the pool type through.
### 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
- [x] Minor
#### Bug Severity
- [ ] BLOCKER
- [ ] Critical
- [x] Major
- [ ] Minor
- [ ] Trivial
### Screenshots (if appropriate):
N/A
### How Has This Been Tested?
Unit tests (new + extended), all passing locally on the `4.22` branch (JDK
17, Maven 3.9.9):
- `LibvirtCheckVolumeCommandWrapperTest` (new, 5 tests) — RBD success path
(virtual size + collected details), verification that `qemu-img` is pointed at
the RBD URI, locked-volume detail propagation, invalid/missing volume, and
unsupported pool type.
- `VolumeOrchestratorTest` (3 added) — KVM+RBD → RAW, KVM+non-RBD → QCOW2,
non-KVM ignores the pool type.
```
mvn -pl plugins/hypervisors/kvm test
-Dtest='LibvirtCheckVolumeCommandWrapperTest'
mvn -pl engine/orchestration test -Dtest='VolumeOrchestratorTest'
```
To be verified on a KVM + Ceph/RBD environment: `importVm` with
`importsource=shared`, adopting an existing ROOT volume on an RBD primary
storage pool, should now succeed and the resulting volume should be recorded
with format `RAW`.
#### How did you try to break this feature and the system with this change?
- Non-RBD pools (Filesystem / NetworkFilesystem / SharedMountPoint) keep
their existing behaviour (QCOW2 validation and QCOW2 format unchanged).
- Unsupported pool types still return `Unsupported Storage Pool`.
- Locked / encrypted / volumes with a backing file on RBD are still rejected
by the existing server-side `checkVolume` validations (details are collected
via the force-share `qemu-img -U` probe).
--
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]
