Am 19.04.2018 um 17:25 hat Peter Krempa geschrieben:
> When using blockdev-add and friends, libvirt will need to create also
> properties for the qcow2/raw/... format handler in qemu. This patch adds
> the infrastructure and implements all formats known to libvirt including
> all properties which are expressed at the format level in qemu.
>
> Signed-off-by: Peter Krempa <pkrempa@xxxxxxxxxx>
> ---
> src/qemu/qemu_block.c | 296 ++++++++++++++++++++++++++++++++++++++++++++++++++
> src/qemu/qemu_block.h | 3 +
> 2 files changed, 299 insertions(+)
>
> diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c
> index 0357d93384..87f3cf9cbe 100644
> --- a/src/qemu/qemu_block.c
> +++ b/src/qemu/qemu_block.c
> @@ -1168,3 +1168,299 @@ qemuBlockStorageSourceGetBackendProps(virStorageSourcePtr src,
> virJSONValueFree(fileprops);
> return ret;
> }
> +
> +
> +static int
> +qemuBlockStorageSourceGetFormatRawProps(virStorageSourcePtr src,
> + virJSONValuePtr props)
> +{
> + qemuDomainStorageSourcePrivatePtr srcPriv = QEMU_DOMAIN_STORAGE_SOURCE_PRIVATE(src);
> + const char *driver = "raw";
> + const char *secretalias = NULL;
> +
> + if (src->encryption &&
> + src->encryption->format == VIR_STORAGE_ENCRYPTION_FORMAT_LUKS &&
> + srcPriv &&
> + srcPriv->encinfo) {
> + driver = "luks";
> + secretalias = srcPriv->encinfo->s.aes.alias;
> + }
Hm, so libvirt treats luks images as "encrypted raw" (which is a
contradiction in itself)? I suppose it's too late to change this, but
it's a bit unfortunate, because...
> + /* currently unhandled properties for the 'raw' driver:
> + * 'offset'
> + * 'size'
> + */
...if you ever want to implement these features, the luks driver won't
be offering them and you'll need to create two layers at once in this
function (raw over luks, or luks over raw - and it's not clear which
one).
Kevin
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
