Hi, I wanted to get your advice on a patch I'm preparing for libvirt. It touches the code-path that allows using LUKS encryption on top of an RBD image. We recently added LUKS and LUKS2 encryption support in Ceph's librbd. We exposed this in qemu in a recent patch by adding new optional "encrypt" member to BlockdevOptionsRbd. This patch was included in the recent release of qemu 6.1. To enable libvirt users to use librbd encryption, we need libvirt to use this new "encrypt" when it builds the blockdev options for RBD. The interesting question is how to define the libvirt XML syntax that will trigger the use of librbd encryption. My thought was to use the already existing <encryption> tag. In that case, we just need to add a new format VIR_STORAGE_ENCRYPTION_FORMAT_LUKS2 to the enum virStorageEncryptionFormatType. This type will be checked in qemuBlockStorageSourceGetRBDProps. The problem with this approach is that it only works for LUKS2. librbd encryption also supports LUKS1. We want to allow the user to choose between the qemu LUKS implementation and the librbd one. One reason to keep support both is that on the one hand librbd only supports XTS mode. On the other hand, qemu implementation will not support a chain of uniquely encrypted RBD images (each serving as a backing store for the previous one). So we need a way in the XML API to support both implementations. Our current thought is to add a new "engine" attribute to the encryption tag. By default, encryption will use the QEMU LUKS implementation, unless <encryption engine='rbd' ...> is specified. To make this more general, we can have engine='backend' instead of engine='rbd' to denote that the encryption is to be delegated to the backend storage properties (instead of the format properties). This way, the encryption tag will only be parsed in the flow of qemuBlockStorageSourceGetBackendProps, instead of in qemuBlockStorageSourceGetBlockdevProps We'll appreciate any feedback you have on this. Thanks, Or
