[PATCH 0/2] docs: two fixes

Please see individual patches. Peter Krempa (2): docs: formatdomain: Document few NVRAM config limitations docs: formatdomain: Mention that vhostuser interface with mode='server' waits for connection docs/formatdomain.rst | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) -- 2.48.1

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> --- docs/formatdomain.rst | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 381bf84f67..4a5241e610 100644 --- 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. -- 2.48.1

On a Thursday in 2025, Peter Krempa wrote:
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> --- docs/formatdomain.rst | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
Reviewed-by: Ján Tomko <jtomko@redhat.com> Jano

When starting a VM with a vhost-user interface in server mode qemu will wait for the incoming connection without running CPUs. This isn't really documented in our XML. Additionally when hotplugging the same interface the above will not happen. Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- docs/formatdomain.rst | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 4a5241e610..8ab6b7282d 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -6346,6 +6346,11 @@ two attributes ``enabled`` (which accepts ``yes`` and ``no``) and ``timeout`` which specifies the amount of seconds after which hypervisor tries to reconnect. +Note that when ``mode='server'`` is used, the hypervisor will wait for the +incomming connection to be established prior to actually running the VM. This is +not possible when hotplugging an interface the same config so the VM will +continue to run even when no connection is made. It's advised to use +``mode='client'`` instead. vhost-user connection with passt backend ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- 2.48.1

On a Thursday in 2025, Peter Krempa wrote:
When starting a VM with a vhost-user interface in server mode qemu will wait for the incoming connection without running CPUs. This isn't really documented in our XML. Additionally when hotplugging the same interface the above will not happen.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- docs/formatdomain.rst | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 4a5241e610..8ab6b7282d 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -6346,6 +6346,11 @@ two attributes ``enabled`` (which accepts ``yes`` and ``no``) and ``timeout`` which specifies the amount of seconds after which hypervisor tries to reconnect.
+Note that when ``mode='server'`` is used, the hypervisor will wait for the +incomming connection to be established prior to actually running the VM. This is
*incoming
+not possible when hotplugging an interface the same config so the VM will
I can't parse this sentence. an interface with the same config?
+continue to run even when no connection is made. It's advised to use +``mode='client'`` instead.
Reviewed-by: Ján Tomko <jtomko@redhat.com> Jano

On Thu, Feb 20, 2025 at 11:13:19 +0100, Ján Tomko wrote:
On a Thursday in 2025, Peter Krempa wrote:
When starting a VM with a vhost-user interface in server mode qemu will wait for the incoming connection without running CPUs. This isn't really documented in our XML. Additionally when hotplugging the same interface the above will not happen.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- docs/formatdomain.rst | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst index 4a5241e610..8ab6b7282d 100644 --- a/docs/formatdomain.rst +++ b/docs/formatdomain.rst @@ -6346,6 +6346,11 @@ two attributes ``enabled`` (which accepts ``yes`` and ``no``) and ``timeout`` which specifies the amount of seconds after which hypervisor tries to reconnect.
+Note that when ``mode='server'`` is used, the hypervisor will wait for the +incomming connection to be established prior to actually running the VM. This is
*incoming
+not possible when hotplugging an interface the same config so the VM will
I can't parse this sentence.
an interface with the same config?
I've changed it to: This is not possible when hotplugging an interface with such config ...
+continue to run even when no connection is made. It's advised to use +``mode='client'`` instead.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jano
participants (2)
-
Ján Tomko
-
Peter Krempa