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 <lersek@redhat.com>
Message-Id: <20220518083014.9890-1-lersek@redhat.com>
Acked-by: Richard W.M. Jones <rjones@redhat.com>
(cherry picked from commit 544bb0ff50)

lib/guestfs.pod

@@ -679,6 +679,39 @@ servers.  The server string is documented in
 L</guestfs_add_drive_opts>. The C<username> and C<secret> parameters are
 also optional, and if not given, then no authentication will be used.
 
+An encrypted RBD disk -- I<directly> opening which would require the
+C<username> and C<secret> parameters -- cannot be accessed if the
+following conditions all hold:
+
+=over 4
+
+=item *
+
+the L<backend|/BACKEND> is libvirt,
+
+=item *
+
+the image specified by the C<filename> parameter is different from the
+encrypted RBD disk,
+
+=item *
+
+the image specified by the C<filename> parameter has L<qcow2
+format|/COMMON VIRTUAL DISK IMAGE FORMATS>,
+
+=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<https://bugzilla.redhat.com/2033247>.
+
 =head3 FTP, HTTP AND TFTP
 
 Libguestfs can access remote disks over FTP, FTPS, HTTP, HTTPS