[KVM] Encrypted disk offering: volume created on a manually selected primary storage pool (NFS and SharedMountPoint) is not encrypted (no LUKS, no error) #14662

problem

When a volume is created from a disk offering with encrypt=true and the primary storage pool is passed explicitly (storageid), the volume is not encrypted. There is no error: the volume is created and attached normally, but it is a plain qcow2 image with no LUKS header and volumes.passphrase_id is NULL. The same disk offering used with allocation by storage tag produces a LUKS volume.

The silent behavior is the main concern: an operator who picks the pool manually believes the data is encrypted at rest and it is not.

The same happens on a SharedMountPoint (iSCSI-backed) pool: manual selection produces a plain image with no error, while allocation by tag on that pool fails at attach (see #14663).

versions

• Apache CloudStack 4.22.1.1
• Hypervisor: KVM, host reports host.volume.encryption
• Volume format: qcow2
• Primary storage: NFS pool (NetworkFilesystem) and SharedMountPoint pool (iSCSI-backed)

The steps to reproduce the bug

1. Use a KVM host that supports volume encryption.
2. Create a disk offering with encryption enabled and a storage tag that matches an NFS pool.
3. Create a volume from that offering with allocation by tag. Result: LUKS volume (works as expected).
4. Create a second volume from the same kind of encrypted offering (no storage tag), passing the NFS pool explicitly:
   createVolume diskofferingid=<encrypted offering> storageid=<nfs pool id> ...
5. Attach it to a VM. No error is returned.
6. Check the result: volumes.passphrase_id is NULL, and the agent log shows no encryption option in the create command and no <encryption> element in the disk XML (excerpts below).
7. Repeating steps 4 to 6 on a SharedMountPoint (iSCSI-backed) pool gives the same result: passphrase_id NULL, plain qcow2, no error. We ran the manual-selection test 11 times with two disk offerings on both pool types, with the same result every time. In one earlier unplanned run (outside our test protocol) a manual selection on the SharedMountPoint pool produced a volume with a passphrase and a visible attach failure; we could not reproduce it in 3 deliberate repeats.

Allocation by tag (works), agent DEBUG log:

DEBUG [utils.script.Script] Executing command [qemu-img create --object secret,file=<keyfile>,id=sec0 -o encrypt.format=luks,preallocation=off,encrypt.key-secret=sec0 -f qcow2 /mnt/50e883ef-d010-3cb7-95fa-30dc5faeae7d/a4dcb52d-6bbc-4edb-afe8-f6a9f8ef902f 5368709120 ].
DEBUG [kvm.storage.KVMStorageProcessor] Attaching device: <disk  device='disk' type='file'>
<driver name='qemu' type='qcow2' cache='none' />
<source file='/mnt/50e883ef-d010-3cb7-95fa-30dc5faeae7d/a4dcb52d-6bbc-4edb-afe8-f6a9f8ef902f'/>
<target dev='vde' bus='virtio'/>
<serial>a4dcb52d6bbc4edbafe8</serial>
<encryption format='luks'>
<secret type='passphrase' uuid='2b94d58b-0848-3559-b193-f1d5846dadfc' />
</encryption>
</disk>

Manual pool selection (silent failure), agent DEBUG log:

DEBUG [utils.script.Script] Executing command [qemu-img create -o preallocation=off -f qcow2 /mnt/50e883ef-d010-3cb7-95fa-30dc5faeae7d/aeb9b9fa-3b24-4a65-9664-ff51cf2f7753 5368709120 ].
DEBUG [kvm.storage.KVMStorageProcessor] Attaching device: <disk  device='disk' type='file'>
<driver name='qemu' type='qcow2' cache='none' />
<source file='/mnt/50e883ef-d010-3cb7-95fa-30dc5faeae7d/aeb9b9fa-3b24-4a65-9664-ff51cf2f7753'/>
<target dev='vde' bus='virtio'/>
<serial>aeb9b9fa3b244a659664</serial>
</disk>
DEBUG [cloud.agent.Agent] Seq 1-1174595077813569846: [...] "org.apache.cloudstack.storage.command.AttachAnswer":{ [...] "result":"true" [...] }

Manual pool selection on the SharedMountPoint (iSCSI-backed) pool, agent DEBUG log: volume created through libvirt (no qemu-img create, no encryption option), attached without <encryption>, and the attach succeeds. The database shows passphrase_id NULL and encrypt_format NULL for the volume.

INFO  [kvm.storage.LibvirtStorageAdaptor] Attempting to create volume f279db6b-d6fd-4339-943c-ad01455af989 (SharedMountPoint) in pool 0d3db4e4-0e9a-4421-a5a4-72e9770d27c1 with size (5.00 GB) 5368709120
DEBUG [kvm.storage.LibvirtStorageAdaptor] <volume>
<name>f279db6b-d6fd-4339-943c-ad01455af989</name>
<capacity>5368709120</capacity>
<target>
<format type='qcow2'/>
<permissions><mode>0744</mode></permissions></target>
</volume>
DEBUG [cloud.agent.Agent] Seq 1-1174595077813576597: [...] "org.apache.cloudstack.storage.command.CreateObjectAnswer": [...] "result":"true" [...]
DEBUG [kvm.storage.KVMStorageProcessor] Attaching physical disk /mnt/<iscsi-pool>/f279db6b-d6fd-4339-943c-ad01455af989 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>/f279db6b-d6fd-4339-943c-ad01455af989'/>
<target dev='vdc' bus='virtio'/>
<serial>f279db6bd6fd4339943c</serial>
</disk>
DEBUG [cloud.agent.Agent] Seq 1-1174595077813576599: [...] "org.apache.cloudstack.storage.command.AttachAnswer": [...] "poolType":"SharedMountPoint", [...] "result":"true" [...]

What to do about it?

The decision to encrypt should not depend on how the pool was chosen. Either apply LUKS (and store the passphrase) on the manual-pool path, or fail the request with a clear error.

Note: PR #13228 changes several getPassphraseId() != null checks to isEncrypted() (which also considers encryptFormat). We have not verified that it affects this scenario, so it may or may not be related.