On Thu, May 24, 2018 at 19:50:09 -0400, John Ferlan wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1560946
Following the model of the Logical backend, use qemu-img on
the created device to set up for LUKS encryption.
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
works much better with the settle patch applied from:
https://www.redhat.com/archives/libvir-list/2018-May/msg01847.html
src/storage/storage_backend_disk.c | 43 ++++++++++++++++++++++++--------------
1 file changed, 27 insertions(+), 16 deletions(-)
diff --git a/src/storage/storage_backend_disk.c b/src/storage/storage_backend_disk.c
index 7b4549c34d..a3003fd0b5 100644
--- a/src/storage/storage_backend_disk.c
+++ b/src/storage/storage_backend_disk.c
I must say that I'm not a fan of adding features to the 'disk' backend.
Using the disk backend is borderline insane for managing disk
partitions.
[...]
@@ -893,6 +887,12 @@
virStorageBackendDiskCreateVol(virStoragePoolObjPtr pool,
goto cleanup;
}
+ /* If we're going to encrypt using LUKS, then we could need up to
+ * an extra 2MB for the LUKS header - so account for that now */
+ if (vol->target.encryption &&
+ vol->target.encryption->format == VIR_STORAGE_ENCRYPTION_FORMAT_LUKS)
+ endOffset += 2 * 1024 * 1024;
I don't think it's a good idea to change 'endOffset' after calling
virStorageBackendDiskPartBoundaries as the function is looking up space
in the existing partition table. With this if the size is just right and
you increase it afterwards the partition will not fit in the place found
by that function.
+
virCommandAddArgFormat(cmd, "%lluB", startOffset);
virCommandAddArgFormat(cmd, "%lluB", endOffset);