docs: formatdomain: Document few NVRAM config limitations

Note that 'block' backed NVRAM may need to use 'qcow2' images to work
properly and that populating from template may not support format
conversion.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>

diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 381bf84f67edc592a8667b178a30b91ffc3b4d5b..4a5241e6102d4f2e6958e6c5e224fb069970bcc7 100644 (file)
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -283,13 +283,19 @@ harddisk, cdrom, network) determining where to obtain/find the boot image.
    :since:`Since 8.5.0`,  it's possible for the element to have ``type`` attribute
    (accepts values ``file``, ``block`` and ``network``) in that case the NVRAM
    storage is described by a ``<source>`` sub-element with the same syntax as
-   ``disk``'s source. See `Hard drives, floppy disks, CDROMs`_.
+   ``disk``'s source. See `Hard drives, floppy disks, CDROMs`_. For ``block``
+   backed NVRAM images it may be necessary to ensure that the block device
+   has the correct guest visible size based on hypervisor expectations. This
+   may require use of non ``raw`` format image that allows arbitrary disk
+   size.
 
    **Note:** ``network`` backed NVRAM the variables are not instantiated from
    the ``template`` and it's user's responsibility to provide a valid NVRAM image.
 
    This element supports a ``format`` attribute, which specifies the format
-   of the NVRAM image. :since:`Since 9.2.0 (QEMU only)`
+   of the NVRAM image. :since:`Since 9.2.0 (QEMU only)` Note that hypervisors
+   may not support automatic population of the nvram if ``format`` differs from
+   ``templateFormat`` or may support only a specific ``format``.
 
    It is not valid to provide this element if the loader is marked as
    stateless.