virStorageBackendCreateQemuImgCheckEncryption didn't return -1 if there were no secrets. Signed-off-by: John Ferlan <jferlan(a)redhat.com&gt; --- src/storage/storage_backend.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c index 430dccf..6aa5593 100644 --- a/src/storage/storage_backend.c +++ b/src/storage/storage_backend.c @@ -1063,6 +1063,7 @@ virStorageBackendCreateQemuImgCheckEncryption(int format, if (enc->nsecrets == 0) { virReportError(VIR_ERR_XML_ERROR, "%s", _("no secret provided for luks encryption")); + return -1; } } else { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, -- 2.5.5

Resolves a CI test integration failure with a RHEL6/Centos6 environment. In order to use a LUKS encrypted device, the design decision was to generate an encrypted secret based on the master key. However, commit id 'da86c6c' missed checking for that specifically. When qemuDomainSecretSetup was implemented, a design decision was made to "fall back" to a plain text secret setup if the specific cipher was not available (e.g. virCryptoHaveCipher(VIR_CRYPTO_CIPHER_AES256CBC)) as well as the QEMU_CAPS_OBJECT_SECRET. For the luks encryption setup there is no fall back to the plaintext secret, thus if that gets set up by qemuDomainSecretSetup, then we need to fail. Also, while the qemuxml2argvtest has set the QEMU_CAPS_OBJECT_SECRET bit, it didn't take into account the second requirement that the ability to generate the encrypted secret is possible. So modify the test to not attempt to run the luks-disk if we know we don't have the encryption algorithm. Signed-off-by: John Ferlan <jferlan(a)redhat.com&gt; --- src/qemu/qemu_domain.c | 7 +++++++ tests/qemuxml2argvtest.c | 4 ++++ 2 files changed, 11 insertions(+) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 6372080..60fa592 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -1089,6 +1089,13 @@ qemuDomainSecretDiskPrepare(virConnectPtr conn, true) < 0) goto error; + if (secinfo->type == VIR_DOMAIN_SECRET_INFO_TYPE_PLAIN) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("luks encryption requires encrypted secrets " + "to be supported")); + goto error; + } + diskPriv->encinfo = secinfo; } diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index db212ae..afa3536 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -1365,7 +1365,11 @@ mymain(void) DO_TEST("encrypted-disk", NONE); DO_TEST("encrypted-disk-usage", NONE); +# ifdef HAVE_GNUTLS_CIPHER_ENCRYPT DO_TEST("luks-disks", QEMU_CAPS_OBJECT_SECRET); +# else + DO_TEST_FAILURE("luks-disks", QEMU_CAPS_OBJECT_SECRET); +# endif DO_TEST("memtune", NONE); DO_TEST("memtune-unlimited", NONE); -- 2.5.5

Commit id '5e46d7d6' did not take into account that usage of a luks volume will require usage of the master key encrypted passphrase for a QEMU environment. So rather than allow creation of something that won't be usable, just fail the creation. Signed-off-by: John Ferlan <jferlan(a)redhat.com&gt; --- src/storage/storage_backend.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c index 6aa5593..862fb29 100644 --- a/src/storage/storage_backend.c +++ b/src/storage/storage_backend.c @@ -56,6 +56,7 @@ #include "internal.h" #include "secret_conf.h" #include "secret_util.h" +#include "vircrypto.h" #include "viruuid.h" #include "virstoragefile.h" #include "storage_backend.h" @@ -1065,6 +1066,12 @@ virStorageBackendCreateQemuImgCheckEncryption(int format, _("no secret provided for luks encryption")); return -1; } + if (!virCryptoHaveCipher(VIR_CRYPTO_CIPHER_AES256CBC)) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("luks encryption usage requires encrypted " + "secret generation to be supported")); + return -1; + } } else { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("volume encryption unsupported with format %s"), type); -- 2.5.5