Description of problem: Nova currently has some limited encryption support which works with LVM volumes. This is not a particularly common deployment choice. The encryption support needs to be extended to cover qcow2 files, RBD and iSCSI volumes at the very minimum. This will require QEMU to have native support for the LUKS encryption format.
Kashyap are there other dependencies for this work? The linked dependency is (theoretically) resolved?
Unfortunately the infrastructure isn't fully completed. QEMU has support for LUKS over plain files, block devices and network volumes, but doesn't have LUKS integration into qcow2 yet. Libvirt supports LUKS over plain files and block devices, but not yet for network volumes. It is enough to start working on the nova piece, but not complete it yet
(In reply to Daniel Berrange from comment #4) > Unfortunately the infrastructure isn't fully completed. QEMU has support for > LUKS over plain files, block devices and network volumes, but doesn't have > LUKS integration into qcow2 yet. Dan, I presume this in-progress upstream QEMU patch series (that adds LUKS support to QCOW2) from you, is what you're referring to (which I've been following from a distance) https://lists.nongnu.org/archive/html/qemu-devel/2017-02/msg04653.html -- [PATCH v5 00/18] Convert QCow[2] to QCryptoBlock & add LUKS support > Libvirt supports LUKS over plain files and > block devices, but not yet for network volumes. > > It is enough to start working on the nova piece, but not complete it yet
So, the v10 of the relevant QEMU patch series from DanPB: "[PATCH v10 00/20] Convert QCow[2] to QCryptoBlock & add LUKS support" -- https://lists.nongnu.org/archive/html/qemu-block/2017-06/msg00755.html) is merged in QEMU 2.10 (released on 30-Aug-2017).
Moving to rhos-15.0? given RHEL dependencies will not be available during Rocky development.
Dan, Besides the patch series pointed out in comment#6 (which is merged), do you recall if there is any other pending action on libvirt and QEMU? From a past conversation with Eric Blake, it looks like the following two bugs are also relevant here: https://bugzilla.redhat.com/show_bug.cgi?id=760547 -- [RFE] specifying the entire image chain as a qemu drive (blockdev-add) https://bugzilla.redhat.com/show_bug.cgi?id=1375855 -- LUKS encryption not supported for snapshots' backing files That was my IRC chat with Eric (from September 2017). Eric writes: You can't create snapshots on top of an encrypted image, unless you can pass the secret to use the encrypted image as a backing file. So libvirt has to use persistent backing chains (rather than recomputing it each time the domain supports), if the XML is going to track association of a secret with a member of the backing chain. That's true whether or not libvirt uses '-blockdev', but switching to '-blockdev' is natural fallout from that work. QEMU already supports associating a secret with any depth in the backing chain, but that support is easiest when using '-blockdev'. (You have to use pseudo-JSON backing file references otherwise, which gets hairy). So there's all the more incentive for libvirt to just supply '-blockdev' instructions to QEMU in the first place. Need to investigate how much of the above is still relevant. I know Peter Krempa has already been working on '-blockdev' support for a while.
(In reply to Kashyap Chamarthy from comment #9) > Dan, > > Besides the patch series pointed out in comment#6 (which is merged), do > you recall if there is any other pending action on libvirt and QEMU? > > From a past conversation with Eric Blake, it looks like the following > two bugs are also relevant here: > > https://bugzilla.redhat.com/show_bug.cgi?id=760547 -- [RFE] > specifying the entire image chain as a qemu drive (blockdev-add) > > https://bugzilla.redhat.com/show_bug.cgi?id=1375855 -- LUKS > encryption not supported for snapshots' backing files > > That was my IRC chat with Eric (from September 2017). Eric writes: > > You can't create snapshots on top of an encrypted image, unless you > can pass the secret to use the encrypted image as a backing file. > So libvirt has to use persistent backing chains (rather than > recomputing it each time the domain supports), if the XML is going > to track association of a secret with a member of the backing chain. > That's true whether or not libvirt uses '-blockdev', but switching > to '-blockdev' is natural fallout from that work. > > QEMU already supports associating a secret with any depth in the > backing chain, but that support is easiest when using '-blockdev'. > (You have to use pseudo-JSON backing file references otherwise, > which gets hairy). So there's all the more incentive for libvirt to > just supply '-blockdev' instructions to QEMU in the first place. > > Need to investigate how much of the above is still relevant. I know > Peter Krempa has already been working on '-blockdev' support for a > while. I'm adding several BZs to the "depends-on" list. The current status is that this feature primarily depends on blockdev work being done in upstream libvirt. Downstream target is RHEL-AV-8.1 (some of the BZs are still marked rhel-7.7, but that's misleading and will be fixed in the next days/weeks).
*** Bug 1631239 has been marked as a duplicate of this bug. ***
This feature request has been deferred to a future OSP release and migrated to our new Jira backlog for consideration in a future product release. Starting with the Antelope upstream release, DFG:Compute is tracking its feature backlog in Jira. This feature request has been migrated to DFG:Compute’s new Jira backlog. The Jira tracker for this feature request can be found at https://issues.redhat.com/browse/OSP-19409. At the time of this writing, only Red Hat associates have access to the Jira tracker.