Repository navigation
[KVM] Encrypted volume on SharedMountPoint pool is created without LUKS and attach fails with "No encryption in image header" #14663
Description
problem
StoragePoolType.SharedMountPoint is declared with EncryptionSupport.Hypervisor, the same level as NFS. In practice, a volume created on a SharedMountPoint pool from an encrypted disk offering is created as a plain qcow2 image, while the agent still builds the attach XML with an <encryption format='luks'> element (the volume has a passphrase). Attaching then fails:
unable to execute QEMU command 'blockdev-add': No encryption in image header, but options specified format 'luks'
On NFS with allocation by tag the same kind of offering works end to end (LUKS aes-256-xts, attach, detach, resize).
With DEBUG enabled on the KVM agent, no qemu-img create command is logged when the volume is created on the SharedMountPoint pool (only the INFO line "Attempting to create volume ... (SharedMountPoint)"), so creation seems to go through a different code path that never applies LUKS. The attach failure above happens with allocation by tag. With manual pool selection on this pool type the volume is created silently without encryption and attaches without error (see #14662).
versions
- Apache CloudStack 4.22.1.1
- Hypervisor: KVM, host reports
host.volume.encryption - Volume format: qcow2
- Primary storage: pool of type SharedMountPoint, backed by iSCSI LUNs
The steps to reproduce the bug
- Use a KVM host that supports volume encryption and has a SharedMountPoint pool.
- Create a disk offering with encryption enabled and a storage tag that matches the SharedMountPoint pool.
- Create a volume from that offering (allocation by tag).
volumes.passphrase_idis set. - Attach the volume to a running VM. Attach fails with the
LibvirtExceptionabove.
Agent DEBUG log for creation and attach:
INFO [kvm.storage.LibvirtStorageAdaptor] Attempting to create volume c9aaeab7-c4b2-415d-9a4c-f22a1350cda0 (SharedMountPoint) in pool 0d3db4e4-0e9a-4421-a5a4-72e9770d27c1 with size (5.00 GB) 5368709120
(no "qemu-img create" line between this line and the success response)
DEBUG [kvm.storage.KVMStorageProcessor] Attaching physical disk /mnt/<iscsi-pool>/c9aaeab7-c4b2-415d-9a4c-f22a1350cda0 with format qcow2
DEBUG [kvm.storage.KVMStorageProcessor] Attaching device: <disk device='disk' type='file'>
<driver name='qemu' type='qcow2' cache='none' />
<source file='/mnt/<iscsi-pool>/c9aaeab7-c4b2-415d-9a4c-f22a1350cda0'/>
<target dev='vde' bus='virtio'/>
<serial>c9aaeab7c4b2415d9a4c</serial>
<encryption format='luks'>
<secret type='passphrase' uuid='cf59ce59-9194-31f9-b296-476d0abdf5b1' />
</encryption>
</disk>
WARN [kvm.storage.KVMStorageProcessor] Failed to attach device to i-2-14-VM: internal error: unable to execute QEMU command 'blockdev-add': No encryption in image header, but options specified format 'luks'
DEBUG [kvm.storage.KVMStorageProcessor] Failed to attach volume [id: 65, uuid: c9aaeab7-c4b2-415d-9a4c-f22a1350cda0, name: <volume>, path: c9aaeab7-c4b2-415d-9a4c-f22a1350cda0], due to org.libvirt.LibvirtException: internal error: unable to execute QEMU command 'blockdev-add': No encryption in image header, but options specified format 'luks'
at org.libvirt.Domain.attachDevice(Unknown Source)
at com.cloud.hypervisor.kvm.storage.KVMStorageProcessor.attachOrDetachDevice(KVMStorageProcessor.java:1316)
at com.cloud.hypervisor.kvm.storage.KVMStorageProcessor.attachOrDetachDisk(KVMStorageProcessor.java:1591)
at com.cloud.hypervisor.kvm.storage.KVMStorageProcessor.attachVolume(KVMStorageProcessor.java:1644)
What to do about it?
Either implement the encrypted create path for SharedMountPoint (as done for NFS), or stop declaring EncryptionSupport.Hypervisor for this pool type and reject encrypted offerings at allocation time with a clear error. The current behavior lets the volume be created and fails only at attach.
Activity
weizhouapache commentedon Nov 10, 2026
this should has been fixed by #13537
famerico commentedon Nov 10, 2026
Thanks for the pointer. I checked it against the code and it matches what we see.
LibvirtStorageAdaptor.createPhysicalDiskonly sendsNetworkFilesystemandFilesystemtocreatePhysicalDiskByQemuImg;SharedMountPointfalls intocreatePhysicalDiskByLibVirt, which matches the missingqemu-img createline in our agent log.QEMU_IMG_MANAGED_POOL_TYPES(NFS, Filesystem, SharedMountPoint), so SharedMountPoint goes throughqemu-imgand can get the LUKS options.Two questions:
4.22, but I could not find a 4.22.2 release or the PR listed in any release notes.passphrase_idNULL) happens before the agent creates the disk, in the management server. As far as I can tell Fix for encryption and migration not working on Shared Mount Point #13537 does not touch that path. Is it covered by another change?We will retest on a version that contains #13537 and report back here.
weizhouapache commentedon Nov 10, 2026
yes, 4.22.2.0-RC1 should include the fix: https://github.com/apache/cloudstack/tree/4.22.2.0-RC20261110T1423
#14662 needs another fix like #14667
github-actions commentedon Nov 11, 2026
Warning
threat detection engine error
The threat detection engine encountered an error and could not complete analysis. This is a tooling failure, not a security finding.
What happened
The threat detection engine failed to produce results.
Review the workflow run logs for details.
🎯 Triage report
On KVM, a volume created from an encrypted offering on a SharedMountPoint pool is created with
qemu-img-less libvirt creation and no LUKS header. The attach XML still includes<encryption format='luks'>, so attach fails with "No encryption in image header". The reporter traced this tocreatePhysicalDiskrouting SharedMountPoint to the libvirt path in 4.22.1.1. A maintainer comment says #13537 fixes this, and the fix is in the 4.22.2.0 RC and in 4.23.0.0 according to the reporter's reading of the tags.📊 Assessment
🔗 Similar issues
💡 Notes and suggestions
qemu-img.Add this agentic workflow to your repo
To install this agentic workflow, run