From fd64ddfee0602e72f72c1828a7904bdc04ab56dc Mon Sep 17 00:00:00 2001 From: Laszlo Ersek Date: Wed, 18 May 2022 10:30:14 +0200 Subject: [PATCH] guestfs.pod: document encrypted RBD disk limitation Under "REMOTE STORAGE", the "NETWORK BLOCK DEVICE" section already documents some limitations. Turns out we need to describe a quirky exception for accessing encrypted RBD disks, too. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2033247 Signed-off-by: Laszlo Ersek Message-Id: <20220518083014.9890-1-lersek@redhat.com> Acked-by: Richard W.M. Jones (cherry picked from commit 544bb0ff507958b44cc7a3fa69421ffae821ec3a) --- lib/guestfs.pod | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/lib/guestfs.pod b/lib/guestfs.pod index b04c28d62..1ad44e7c2 100644 --- a/lib/guestfs.pod +++ b/lib/guestfs.pod @@ -679,6 +679,39 @@ servers. The server string is documented in L. The C and C parameters are also optional, and if not given, then no authentication will be used. +An encrypted RBD disk -- I opening which would require the +C and C parameters -- cannot be accessed if the +following conditions all hold: + +=over 4 + +=item * + +the L is libvirt, + +=item * + +the image specified by the C parameter is different from the +encrypted RBD disk, + +=item * + +the image specified by the C parameter has L, + +=item * + +the encrypted RBD disk is specified as a backing file at some level in +the qcow2 backing chain. + +=back + +This limitation is due to libvirt's (justified) separate handling of +disks vs. secrets. When the RBD username and secret are provided inside +a qcow2 backing file specification, libvirt does not construct an +ephemeral secret object from those, for Ceph authentication. Refer to +L. + =head3 FTP, HTTP AND TFTP Libguestfs can access remote disks over FTP, FTPS, HTTP, HTTPS