famerico opened a new issue, #14663:
URL: https://github.com/apache/cloudstack/issues/14663
### 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 the separate issue about manual pool selection).
### 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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
