Re: [PATCH docs 1/1] qm: clarify when the iothreads options takes into effect

[Abobakr Mohammed <a.mohammed@proxmox.com>]

LGTM.
Reviewed-by: Abobakr Mohammed <a.mohammed@proxmox.com>
On Wednesday, 08/19/2026, 10:32, Maximiliano Sandoval <m.sandoval@proxmox.com> wrote:

From : Maximiliano Sandoval <m.sandoval@proxmox.com>
Sent on : Wednesday, 08/19/2026, 10:32
To : pve-devel@lists.proxmox.com
Subject : [PATCH docs 1/1] qm: clarify when the iothreads options takes into effect
The main point addressed is that the "VirtIO Block" bus controller type was
referred as "VirtIO". This can be a source of confusion since the are multiple
controllers for different components provided by VirtIO.

VirtIO SCSI is listed before VirtIO Block as a soft-recommendation.

We use the same terms as the web UI, modulo capitalization for "Bus/Device" and
"SCSI Controller".

Signed-off-by: Maximiliano Sandoval <m.sandoval@proxmox.com>
---
 qm.adoc | 20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/qm.adoc b/qm.adoc
index 5b46cdc..51935ea 100644
--- a/qm.adoc
+++ b/qm.adoc
@@ -337,14 +337,18 @@ Note that SSD emulation is not supported on VirtIO Block drives.
 [[qm_hard_disk_iothread]]
 IO Thread
 ^^^^^^^^^
-The option IO Thread can only be used when using a disk with the VirtIO
-controller, or with the SCSI controller, when the emulated controller type is
-VirtIO SCSI single. With IO Thread enabled, QEMU creates one I/O thread per
-storage controller rather than handling all I/O in the main event loop or vCPU
-threads. One benefit is better work distribution and utilization of the
-underlying storage. Another benefit is reduced latency (hangs) in the guest for
-very I/O-intensive host workloads, since neither the main thread nor a vCPU
-thread can be blocked by disk I/O.
+The IO thread option can only be used when using a disk with one of the
+following bus/device controllers:
+
+ SCSI, if the emulated SCSI controller type is VirtIO SCSI single*, or
+ VirtIO Block*
+
+With IO thread enabled, QEMU creates one I/O thread per storage controller
+rather than handling all I/O in the main event loop or vCPU threads. One benefit
+is better work distribution and utilization of the underlying storage. Another
+benefit is reduced latency (hangs) in the guest for very I/O-intensive host
+workloads, since neither the main thread nor a vCPU thread can be blocked by
+disk I/O.
 
 [[qm_cpu]]
 CPU
-- 
2.47.3