Conversation
The CheckVolumeCommand wrapper on the KVM agent only accepted file based pools, so importing a root disk straight from Ceph failed on the agent with "Unsupported Storage Pool" and surfaced as "Disk not found or is invalid" on the management server. Add RBD to the supported pool types, take the virtual size from the disk libvirt resolved (qemu-img cannot open a bare RBD image name), skip the QCOW2 header check for raw RBD images, and build the rbd: URI when running qemu-img info, the same way LibvirtGetVolumesOnStorageCommandWrapper already does for listVolumesForImport.
importVolume and updateImportedVolume both stamped the cluster default format for the hypervisor, so a volume imported from an RBD pool was recorded as QCOW2 while a natively deployed volume on the same pool is RAW. This affected both entry points: importVm importsource=shared for a root disk, and importVolume for a data disk. Pass the format the hypervisor reported for the existing image, from the check answer for a root disk and from the volume listed on the pool for a data disk, and fall back to the hypervisor default only when no format is reported. This also corrects a raw image imported from a file based pool.
…ted pool importKVMInstanceFromDiskImage planned with the pod and cluster unset, so the planner was free to pick any host in the zone by capacity. When it picked a host in a cluster that cannot see the pool the caller named, the volume check ran against whichever pool that cluster does have, and the import failed with "Disk not found or is invalid" although the image was fine. Take the pod and cluster from the pool the caller passed, the same way importVolume already derives its host from the pool's scope
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## 4.22 #14162 +/- ##
=========================================
Coverage 17.93% 17.94%
- Complexity 16143 16154 +11
=========================================
Files 5928 5928
Lines 535174 535223 +49
Branches 65494 65507 +13
=========================================
+ Hits 95998 96044 +46
+ Misses 428253 428246 -7
- Partials 10923 10933 +10
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
@blueorangutan package |
|
@weizhouapache a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
| return new CheckVolumeAnswer(command, false, "", 0, getVolumeDetails(pool, vol)); | ||
| final boolean isRbd = Storage.StoragePoolType.RBD.equals(storageFilerTO.getType()); | ||
|
|
||
| if (!isRbd) { |
There was a problem hiding this comment.
can we check RBD volumes too ?
There was a problem hiding this comment.
qemu can't check raw files, but I have added code to verify that getVolumeDetails is able to read the rbd volume as a check.
8f49d1a
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19235 |
|
@blueorangutan package |
|
@abh1sar a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19238 |
|
@blueorangutan test |
|
@weizhouapache a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
3 participants
Description
This PR fixes 3 issues in the
importVMworkflow:1. Root disk import doesn't work for RBD pools unlike data disk import
importVolume/listVolumesForImportalready accept RBD.LibvirtGetVolumesOnStorageCommandWrapperhas handled it all along, including building therbd:URI forqemu-img info. ButimportVm importsource=sharedrejects it, because the neighbouringLibvirtCheckVolumeCommandWrapperwas written with a file-only pool list. An operator on Ceph can import a data disk but not a root disk.The failure is also misleading. The agent answers "Unsupported Storage Pool", but the operator sees:
and the VM is rolled back.
Adds
StoragePoolType.RBDto the check wrapper's supported list, takes the virtual size from the disk libvirt already resolved (qemu-imgcannot open a bare RBD image name), skips the QCOW2 header check for raw RBD images, and builds therbd:URI via the existingKVMPhysicalDisk.RBDStringBuilder.diskpathonimportVmandpathonimportVolumeare the file name on file-based pools and the image name on RBD. Both parameter descriptions now say so.2. An imported volume records the wrong image format
importVolumeandupdateImportedVolumeboth stamped the cluster default format for the hypervisor, so a volume imported from an RBD pool was recordedQCOW2while a natively deployed volume on the same pool isRAW. Both entry points were affected: root disks viaimportVm importsource=shared, and data disks viaimportVolume.They now record the format the hypervisor reported for the image, from the check answer for a root disk and from the volume listed on the pool for a data disk, falling back to the hypervisor default when none is reported. This also corrects a raw image imported from a file-based pool, so it is a general correctness fix rather than an RBD-specific one.
3. The import is planned outside the pool's cluster
importKVMInstanceFromDiskImageplanned with pod and cluster unset, so the planner could pick any host in the zone by capacity, even one in a cluster with no access to the pool the caller named. The volume check then ran against whichever pool that cluster does have, and the import failed with "Disk not found or is invalid" although the image was fine.This is not RBD-specific. Reproduced on a two-cluster zone with plain NFS.
The plan now takes pod and cluster from the pool the caller passed. Both are null for a zone-wide pool, which every host can see, so that case plans exactly as before.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
How did you try to break this feature and the system with this change?