Support VDDK imports into RBD storage#13294
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## 4.22 #13294 +/- ##
==========================================
Coverage 17.67% 17.68%
- Complexity 15792 15827 +35
==========================================
Files 5922 5923 +1
Lines 533165 533595 +430
Branches 65208 65259 +51
==========================================
+ Hits 94242 94361 +119
- Misses 428276 428583 +307
- Partials 10647 10651 +4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@blueorangutan package kvm |
|
@andrijapanicsb a [SL] Jenkins job has been kicked to build packages. It will be bundled with kvm SystemVM template(s). I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 18103 |
|
@blueorangutan help |
|
@andrijapanicsb [SL] I understand these words: "help", "hello", "thanks", "package", "test" Blessed contributors for kicking Trillian test jobs: ['rohityadavcloud', 'shwstppr', 'Damans227', 'vishesh92', 'Pearl1594', 'harikrishna-patnala', 'nvazquez', 'DaanHoogland', 'weizhouapache', 'borisstoyanov', 'vladimirpetrov', 'kiranchavala', 'andrijapanicsb', 'NuxRo', 'rajujith', 'sureshanaparti', 'abh1sar', 'sudo87', 'RosiKyu'] |
Companion main/4.23 PR: #13270
This PR is intended to keep the 4.22 and main branches aligned for the VDDK-to-RBD import feature.
Description
This PR extends the existing VMware-to-KVM VDDK import flow with Ceph RBD support, while preserving the current VDDK/QCOW2 behaviour.
The existing VDDK/QCOW2 writer remains supported in both existing modes:
forceconverttopool=true, CloudStack continues to letvirt-v2vwrite QCOW2 output directly into the selected supported primary storage pool using-o local -os <pool-path> -of qcow2.forceconverttopool=false, CloudStack continues to use the staged flow:virt-v2vwrites finalized QCOW2 disks to temporary conversion storage, and the import step then moves/copies those disks to the final destination pool.This change adds a destination-aware writer model for VDDK imports. The current file/QCOW2 writer path remains, and a new Ceph RBD/raw writer path is added. This gives the VDDK import flow a cleaner foundation for adding more destination-specific writers later.
For Ceph RBD, two modes are supported:
Direct RBD mode
When
usevddk=true,forceconverttopool=true, andconvertinstancepoolidpoints to an RBD primary storage pool, CloudStack can write the VMware disk data directly into raw RBD images.This path does not use the normal
virt-v2v -o local -of qcow2writer, because RBD is not a local filesystem target. Instead, the conversion host:nbdkitqemu-img convertvirt-v2v-in-place, orvirt-v2v --in-placewhen supportedThe in-place finalization happens only on the destination RBD images. The VMware source disks are not modified.
Staged RBD mode
When
usevddk=trueandforceconverttopool=false, RBD can still be used as the final destination through the existing staged model.In this mode:
virt-v2vcreates finalized QCOW2 disks on temporary conversion storageThis mode does not require in-place
virt-v2v, because regularvirt-v2vhas already finalized the guest while creating the temporary QCOW2 disks.Direct RBD mode requires newer conversion-host tooling. The practical recommended baseline is EL9-family KVM hosts, such as Oracle Linux 9, Rocky Linux 9, AlmaLinux 9, or RHEL 9, and Ubuntu 24.04-style hosts where
virt-v2v-in-placeorvirt-v2v --in-placeis available. EL8 and Ubuntu 22.04-style hosts should use staged RBD import unless compatible in-place tooling has been explicitly installed and detected by CloudStack.The implementation adds KVM host capability detection for:
virt-v2vsupportqemu-imgRBD supportDirect RBD mode is rejected early when the selected conversion host does not support the required in-place finalization path. Staged RBD remains available in that case.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
N/A
How Has This Been Tested?
Focused compile and unit test coverage was run for the changed API/core/server/KVM paths, including:
The tests cover direct RBD host capability checks, rejection when direct RBD support is missing, staged RBD destination handling, RBD destination pool type propagation, RBD disk metadata, and server-side validation for RBD storage pools.
How did you try to break this feature and the system with this change?
Negative tests were added for hosts without direct VDDK/RBD support, and staged RBD import is validated separately so that lack of in-place
virt-v2vblocks only direct RBD mode, not RBD import as a whole. Existing VDDK/QCOW2 direct and staged flows are kept on the existing writer path unless the selected forced conversion pool is RBD.