On 04/18/2018 08:17 AM, Daniel P. Berrangé wrote: > 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. > So that means Jano's series to remove help scraping completely cannot be applied since this code would need to check that the option exists before using it; otherwise, anything inclusive of QEMU 1.5 and 2.9 would fail (the option was introduced in 2.10 - I mistyped above). What could be applied would be the removal of OPTIONS and OPTIONS_COMPAT, but this new one would need to exist since AFAIK there is no other way currently to query qemu-img for what it supports. Going to make for some ugly code... John > >>>> + 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 > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
