[KVM] Encrypted volume on SharedMountPoint pool is created without LUKS and attach fails with "No encryption in image header"

Offen
  • Stimmt etwas nicht?
#14,663 4 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@weizhouapache arbeitet bereits daran.

Seit 10.11.2026.

  • #13537 von @abh1sar — gemerged
  • #14667 von @weizhouapache — offen

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
25/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Veraltet
Tech-Stack
java
Bereich
backend, infrastructure

Rechercherichtung

Start by tracing volume creation for SharedMountPoint pools and compare it with the NFS encrypted creation path; the report says no qemu-img create command is logged for the failing case. Then inspect how attach XML adds LUKS encryption when a volume has a passphrase. Decide whether SharedMountPoint creation should apply LUKS or encrypted offerings should be rejected at allocation, and verify that creation and attach behavior agree.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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
  1. Use a KVM host that supports volume encryption and has a SharedMountPoint pool.
  2. Create a disk offering with encryption enabled and a storage tag that matches the SharedMountPoint pool.
  3. Create a volume from that offering (allocation by tag). volumes.passphrase_id is set.
  4. Attach the volume to a running VM. Attach fails with the LibvirtException above.

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.

Vorherrschende Sprache
Java
Sterne
3.1k
Forks
1.4k
Ø Merge
7 T. 16 Std.
Gemergte PRs (30 T.)
15

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus apache/cloudstack

Alle Issues in apache/cloudstack

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.