On Wed, Apr 18, 2018 at 08:08:41AM -0400, John Ferlan wrote: > > > 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? Sure, the exact same syntax as with luks volumes - you just specify "qcow" instead of "luks" as the type. > 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? QEMU is likely to support the qcow2 enc format indefinitely, but only in the qemu-img tool for the sake of data liberation. I don't think libvirt should arbitrarily decide to drop it from our qemu-img usage. > >> + 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. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
