Re: [libvirt] [PATCH 2/2] storage: Check qemu-img encryption type capability

On 04/18/2018 04:29 AM, Daniel P. Berrangé wrote: > On Tue, Apr 17, 2018 at 03:23:33PM -0400, John Ferlan wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=1526382 >> >> As of QEMU 2.9, qemu-img has enforced using the "key-secret" for >> creation of encrypted volumes. That is, LUKS encryption is now >> required and the old (awful) qcow[2] encryption methodolgy is >> no longer supported. > > Not quite right actually. The 'key-secret' approach can be used to > create both LUKS and the old qcow[2] encryption. > > We only forbid qcow[2] encryption with the system emulators, still > have full support in qemu-img for sake of interoperability. The only > break there was the command line syntax > Oh, OK - well I didn't find that to be obvious... So there is a way using secret objects to create a qcow[2] encrypted volume?

Still Jano has NACK'd using help scraping (and posted a separate series removing it completely). So then the question becomes does this change "convert" into a disallow this type of creation going forward? Do we just cause failure in storageBackendCreateQemuImgCheckEncryption when not using LUKS or do we let the qemu-img just be the bad guy and do nothing in our code?

>> + if (imgformat >= QEMU_IMG_BACKING_FORMAT_OPTIONS_KEY_SECRET) { >> + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", >> + _("qemu-img no longer supports qcow encryption, " >> + "use LUKS encryption instead")); >> + return -1; >> + } > > Why is imgformat being compared against QEMU_IMG_BACKING_FORMAT_OPTIONS_KEY_SECRET ? > > Aren't those two sides of the expression from completely different > enum types. > Although perhaps not well named, @imgformat is fetched via virStorageBackendQEMUImgBackingFormat which returns QEMU_IMG_BACKING_FORMAT_OPTIONS* type enum's.