Ceph » rbd

Consider the following use-case, with the following sequence of user operations:

1. user creates an RBD image
2. user formats the image to an encrypted format (e.g. LUKS1/2)
3. user opens the encrypted image and writes data to it
4. user exports (export v1 format) the image to a file - the export file is an encrypted luks format (including LUKS header)
5. user creates a new image with the encrypted export as a migration source
6. user opens the encryption on the new image (using rbd_encryption_load) and tries to read from the new image (before even starting migration execute)

The user will actually be reading from the raw encrypted export, with no decryption going on, even though encryption was loaded.

The reason for this is that since the new image is being live-migrated, a new image dispatch layer is loaded (IMAGE_DISPATCH_LAYER_MIGRATION) which terminates read requests, not allowing their decryption down via the IMAGE_DISPATCH_LAYER_CORE->...->OBJECT_DISPATCH_LAYER_CRYPTO path.