Update Windows VM templates with performance optimizations#1247
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ebattat The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
📝 WalkthroughWalkthroughThe PR updates Windows, WinFIO, and WinMSSQL KubeVirt VM templates and their golden manifests. It repositions the domain block, rewrites CPU/device/Hyper-V configuration, adds I/O thread settings, changes termination grace periods to 180, and raises Windows resource limits in the data template. ChangesBenchmark VM template updates
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Apply consistent configuration across windows, winfio, and winmssql: - autoattachMemBalloon: false (reduce memory overhead) - blockMultiQueue: true (multi-queue I/O) - bootOrder: 1 on root disk - Remove dedicatedIOThread: false - Add tablet input (virtio) - Move tpm to device level - Move networkInterfaceMultiqueue to device level - Add evmcs: enabled: true (Hyper-V optimization) - Remove reenlightenment and reset from hyperv - Add ioThreads (supplementalPoolThreadCount: 8) - Add ioThreadsPolicy: supplementalPool - Move firmware after features - Move evictionStrategy to spec level - terminationGracePeriodSeconds: 180 Assisted-by: Claude Code
ebattat
force-pushed
the
update-windows-vm-configuration
branch
from
8ea729f to
0c1368b
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
benchmark_runner/common/template_operations/templates/winfio/internal_data/winfio_vm_template.yaml (1)
105-108: 🚀 Performance & Scalability | 🔵 Trivial | 💤 Low value
resourcesdefines onlyrequests, nolimits.For VMs intended for live migration / guaranteed QoS, missing
limitsmeans the pod runs as Burstable rather than Guaranteed, which can affect scheduling and migration target selection. If this matches the data-template design for winfio (the windows template addedlimits), it can stay; otherwise consider aligning. Non-blocking.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@benchmark_runner/common/template_operations/templates/winfio/internal_data/winfio_vm_template.yaml` around lines 105 - 108, The winfio VM template currently sets only resource requests and not limits, which leaves the pod as Burstable instead of Guaranteed. Review the resource block in the winfio VM template and decide whether it should match the windows template’s Guaranteed QoS pattern; if so, add matching limits alongside the existing requests in the resources section. Use the existing resources block in the template to locate the change.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@benchmark_runner/common/template_operations/templates/windows/internal_data/windows_vm_template.yaml`:
- Line 47: The Windows VM template still disables block multiqueue, so update
the Windows VM template configuration by changing the blockMultiQueue setting in
the windows VM template to enabled and then regenerate the affected Windows VM
goldens. Use the windows VM template entry and its blockMultiQueue field to
locate the change, and make sure the generated artifacts reflect the new
default.
In
`@benchmark_runner/common/template_operations/templates/winfio/internal_data/winfio_vm_template.yaml`:
- Around line 46-47: The Windows VM template currently leaves blockMultiQueue
disabled even though ioThreadsPolicy is set to supplementalPool, so update the
VM template configuration to enable blockMultiQueue in the same section as
autoattachMemBalloon; use the existing winfio_vm_template settings as the
reference point and apply the same fix to the sibling Windows VM templates that
use supplementalPool.
In
`@tests/unittest/benchmark_runner/common/template_operations/golden_files/test_ci_windows_vm_ODF_PVC_True/windows_vm.yaml`:
- Line 33: The Windows VM template is configuring ioThreadsPolicy:
supplementalPool without enabling blockMultiQueue, so the supplemental IO thread
pool is not actually used. Update the Windows VM template identified by
windows_vm_template.yaml to set blockMultiQueue to true, then regenerate the
affected golden files; if single-queue I/O is intended instead, remove the
supplemental pool-related settings from the template and corresponding test
fixture.
---
Nitpick comments:
In
`@benchmark_runner/common/template_operations/templates/winfio/internal_data/winfio_vm_template.yaml`:
- Around line 105-108: The winfio VM template currently sets only resource
requests and not limits, which leaves the pod as Burstable instead of
Guaranteed. Review the resource block in the winfio VM template and decide
whether it should match the windows template’s Guaranteed QoS pattern; if so,
add matching limits alongside the existing requests in the resources section.
Use the existing resources block in the template to locate the change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 53d66df5-ae41-4ab8-afb1-173edc69dce8
📒 Files selected for processing (34)
benchmark_runner/common/template_operations/templates/windows/internal_data/windows_vm_template.yamlbenchmark_runner/common/template_operations/templates/windows/windows_data_template.yamlbenchmark_runner/common/template_operations/templates/winfio/internal_data/winfio_vm_template.yamlbenchmark_runner/common/template_operations/templates/winmssql/internal_data/winmssql_vm_template.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/chaos_ci_windows_vm_ODF_PVC_False/windows_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/chaos_ci_windows_vm_ODF_PVC_True/windows_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/chaos_ci_winfio_vm_ODF_PVC_False/winfio_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/chaos_ci_winfio_vm_ODF_PVC_True/winfio_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/chaos_ci_winmssql_vm_ODF_PVC_False/winmssql_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/chaos_ci_winmssql_vm_ODF_PVC_True/winmssql_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/func_ci_windows_vm_ODF_PVC_False/windows_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/func_ci_windows_vm_ODF_PVC_True/windows_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/func_ci_winfio_vm_ODF_PVC_False/winfio_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/func_ci_winfio_vm_ODF_PVC_True/winfio_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/func_ci_winmssql_vm_ODF_PVC_False/winmssql_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/func_ci_winmssql_vm_ODF_PVC_True/winmssql_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/perf_ci_windows_vm_ODF_PVC_False/windows_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/perf_ci_windows_vm_ODF_PVC_True/windows_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/perf_ci_winfio_vm_ODF_PVC_False/winfio_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/perf_ci_winfio_vm_ODF_PVC_True/winfio_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/perf_ci_winmssql_vm_ODF_PVC_False/winmssql_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/perf_ci_winmssql_vm_ODF_PVC_True/winmssql_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/release_windows_vm_ODF_PVC_False/windows_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/release_windows_vm_ODF_PVC_True/windows_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/release_winfio_vm_ODF_PVC_False/winfio_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/release_winfio_vm_ODF_PVC_True/winfio_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/release_winmssql_vm_ODF_PVC_False/winmssql_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/release_winmssql_vm_ODF_PVC_True/winmssql_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/test_ci_windows_vm_ODF_PVC_False/windows_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/test_ci_windows_vm_ODF_PVC_True/windows_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/test_ci_winfio_vm_ODF_PVC_False/winfio_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/test_ci_winfio_vm_ODF_PVC_True/winfio_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/test_ci_winmssql_vm_ODF_PVC_False/winmssql_vm.yamltests/unittest/benchmark_runner/common/template_operations/golden_files/test_ci_winmssql_vm_ODF_PVC_True/winmssql_vm.yaml
| threads: 1 | ||
| devices: | ||
| autoattachMemBalloon: false | ||
| blockMultiQueue: false |
There was a problem hiding this comment.
🚀 Performance & Scalability | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n 'blockMultiQueue|networkInterfaceMultiqueue' \
benchmark_runner/common/template_operations/templates/windows/internal_data/windows_vm_template.yaml \
tests/unittest/benchmark_runner/common/template_operations/golden_filesRepository: redhat-performance/benchmark-runner
Length of output: 20041
🌐 Web query:
KubeVirt VirtualMachineInstanceSpec devices blockMultiQueue true enables virtio block multiqueue
💡 Result:
Yes, setting blockMultiQueue: true under the devices section of a KubeVirt VirtualMachineInstanceSpec enables virtio block multiqueue [1][2]. Virtio block multiqueue is a framework for the Linux block layer that maps device I/O queries to multiple queues, which improves performance by splitting I/O processing across multiple threads and CPUs [1][2]. When this feature is enabled, KubeVirt configures the number of queues to match the number of CPUs allocated to the VirtualMachineInstance [1][2]. Key technical considerations include: 1. Resource Allocation: For optimal performance, libvirt recommends that the number of queues matches the number of allocated CPUs [1][2]. While earlier implementations of KubeVirt strictly required explicit CPU requests or limits to enable this feature to prevent over-allocation [1][3][2], subsequent updates improved how queues are calculated based on vCPUs [4]. 2. Configuration: It is specified within the domain devices block [1][2]: spec: domain: devices: blockMultiQueue: true disks: - disk: bus: virtio name: mydisk 3. Default Behavior: The blockMultiQueue setting defaults to false [5][6][7].
Citations:
- 1: https://kubevirt.io/user-guide/storage/disks_and_volumes/
- 2: https://www.bookstack.cn/read/kubevirt-1.5-en/94c05a54d611e17f.md
- 3: Introduce virtio multi-queue kubevirt/kubevirt#1562
- 4: Fix the calculation of queues for virtio interefaces and disks kubevirt/kubevirt#2783
- 5: kubevirt/kubevirt@a2f648a
- 6: https://kubevirt.io/api-reference/master/definitions.html
- 7: https://kubevirt.github.io/api-reference/master/definitions.html
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Find the referenced template and inspect the relevant area.
fd -a 'windows_vm_template.yaml' benchmark_runner/common/template_operations/templates
printf '\n---\n'
if [ -f benchmark_runner/common/template_operations/templates/windows/internal_data/windows_vm_template.yaml ]; then
nl -ba benchmark_runner/common/template_operations/templates/windows/internal_data/windows_vm_template.yaml | sed -n '1,140p'
fi
printf '\n---\n'
# Search for blockMultiQueue across the repo.
rg -n "blockMultiQueue|block multi|multiqueue" benchmark_runner tests -SRepository: redhat-performance/benchmark-runner
Length of output: 338
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE="benchmark_runner/common/template_operations/templates/windows/internal_data/windows_vm_template.yaml"
printf '--- file exists ---\n'
if [ -f "$FILE" ]; then
sed -n '1,180p' "$FILE" | cat -n
else
echo "missing: $FILE"
fi
printf '\n--- search ---\n'
rg -n "blockMultiQueue|multiqueue|BlockMultiQueue" benchmark_runner tests -SRepository: redhat-performance/benchmark-runner
Length of output: 264
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE="benchmark_runner/common/template_operations/templates/windows/internal_data/windows_vm_template.yaml"
echo "--- file exists ---"
if [ -f "$FILE" ]; then
sed -n '1,180p' "$FILE" | cat -n
else
echo "missing: $FILE"
fi
echo
echo "--- search ---"
rg -n "blockMultiQueue|multiqueue|BlockMultiQueue" benchmark_runner tests -SRepository: redhat-performance/benchmark-runner
Length of output: 10096
Enable block multiqueue in the Windows VM template
benchmark_runner/common/template_operations/templates/windows/internal_data/windows_vm_template.yaml:47 still has blockMultiQueue: false; switch it to true and regenerate the affected Windows VM goldens.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@benchmark_runner/common/template_operations/templates/windows/internal_data/windows_vm_template.yaml`
at line 47, The Windows VM template still disables block multiqueue, so update
the Windows VM template configuration by changing the blockMultiQueue setting in
the windows VM template to enabled and then regenerate the affected Windows VM
goldens. Use the windows VM template entry and its blockMultiQueue field to
locate the change, and make sure the generated artifacts reflect the new
default.
Source: Coding guidelines
There was a problem hiding this comment.
why switch to true blockMultiQueue ?
There was a problem hiding this comment.
@ebattat I was basing that suggestion on the PR’s stated goal of “enabling multiqueue I/O” across the Windows-family templates.
Specifically:
networkInterfaceMultiqueue: trueonly enables multiqueue for the NIC.blockMultiQueue: trueis the separate KubeVirt knob for virtio disk multiqueue.
So my read was: if the intent here is to enable multiqueue broadly and keep windows, winfio, and winmssql aligned, then leaving blockMultiQueue: false at Line 47 means storage multiqueue is still off in this template.
That said, if this template is intentionally only enabling NIC multiqueue, or if disk multiqueue was left off for Windows compatibility/stability reasons, then this comment doesn’t apply and I’m happy to drop it.
(•ㅅ•)🐇
🧠 Learnings used
Learnt from: ebattat
Repo: redhat-performance/benchmark-runner PR: 1226
File: benchmark_runner/common/template_operations/templates/fio/internal_data/fio_vm_template.yaml:13-15
Timestamp: 2026-05-19T14:25:39.153Z
Learning: In benchmark-runner VM template YAMLs (e.g., fio_vm_template.yaml and other *_vm_template.yaml files, including vdbench VM templates), the cloud-init configuration may intentionally hardcode `password: centos` together with `ssh_pwauth: true`. This is a known project convention for short-lived, network-isolated CI VMs where authentication is primarily handled via SSH key injection. During code review, do not treat this as an unintended security issue; only flag it if the template changes the intended authentication model or the “network-isolated short-lived CI VM” assumption no longer holds. A broader hardening pass is planned for all VM templates.
| autoattachMemBalloon: false | ||
| blockMultiQueue: false |
There was a problem hiding this comment.
🚀 Performance & Scalability | 🟡 Minor
🧩 Analysis chain
🌐 Web query:
KubeVirt supplementalPool ioThreads policy requires blockMultiQueue enabled for virtio queue mapping?
💡 Result:
Yes, using the KubeVirt supplementalPool ioThreads policy requires enabling blockMultiQueue for virtual machine disk devices [1][2]. The supplementalPool policy is designed to improve storage performance by utilizing multiple host-level IOThreads that are mapped to virtio disk queues [3][1]. Authoritative KubeVirt and OpenShift Virtualization documentation explicitly states that multiple IOThreads are supported and work correctly only when blockMultiQueue is enabled and the disk bus is set to virtio [2]. Enabling blockMultiQueue allows these host-level IOThreads to be automatically mapped to multiple queues inside the guest, ensuring that I/O workload is effectively distributed across vCPUs [1].
Citations:
- 1: https://developers.redhat.com/blog/2025/06/23/feature-introduction-multiple-iothreads-openshift-virtualization
- 2: https://docs.okd.io/4.19/virt/managing_vms/virt-edit-vms.html
- 3: SupplementPool iothread policy and make use of virtio-queue mapping kubevirt/kubevirt#13110
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the referenced template and related usages of supplementalPool/blockMultiQueue.
git ls-files benchmark_runner/common/template_operations/templates/winfio/internal_data/winfio_vm_template.yaml
echo '---'
cat -n benchmark_runner/common/template_operations/templates/winfio/internal_data/winfio_vm_template.yaml | sed -n '35,120p'
echo '--- SEARCH supplementalPool / blockMultiQueue ---'
rg -n "supplementalPool|blockMultiQueue|ioThreadsPolicy|supplementalPoolThreadCount" benchmark_runner -SRepository: redhat-performance/benchmark-runner
Length of output: 4577
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Look for repo-local guidance or prior discussion of blockMultiQueue and ioThreadsPolicy.
rg -n "blockMultiQueue|ioThreadsPolicy|supplementalPoolThreadCount|networkInterfaceMultiqueue" \
benchmark_runner tests docs README.md HOW_TO.md -S
echo '--- WINDOWS / WINMSSQL / WINFIO diffs context ---'
for f in \
benchmark_runner/common/template_operations/templates/windows/internal_data/windows_vm_template.yaml \
benchmark_runner/common/template_operations/templates/winmssql/internal_data/winmssql_vm_template.yaml \
benchmark_runner/common/template_operations/templates/winfio/internal_data/winfio_vm_template.yaml
do
echo "### $f"
cat -n "$f" | sed -n '40,110p'
echo
doneRepository: redhat-performance/benchmark-runner
Length of output: 39424
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Check whether the documented KubeVirt behavior ties supplementalPool to blockMultiQueue.
python3 - <<'PY'
from urllib.request import urlopen
urls = [
"https://docs.okd.io/4.19/virt/managing_vms/virt-edit-vms.html",
]
for u in urls:
print(f"URL: {u}")
with urlopen(u, timeout=15) as r:
text = r.read().decode("utf-8", "ignore")
for needle in ("supplementalPool", "blockMultiQueue", "ioThreadsPolicy", "multiqueue"):
idx = text.lower().find(needle.lower())
print(needle, idx)
print("--- snippet ---")
idx = text.lower().find("supplementalpool")
if idx != -1:
print(text[max(0, idx-300): idx+900])
PYRepository: redhat-performance/benchmark-runner
Length of output: 2822
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Gather exact local evidence from the docs page around the relevant terms.
python3 - <<'PY'
from urllib.request import urlopen
u = "https://docs.okd.io/4.19/virt/managing_vms/virt-edit-vms.html"
with urlopen(u, timeout=15) as r:
text = r.read().decode("utf-8", "ignore")
lower = text.lower()
for needle in ("supplementalpool", "blockmultiqueue", "iothreads", "virtio queue"):
idx = lower.find(needle.lower())
print(f"needle={needle!r} idx={idx}")
if idx != -1:
print(text[max(0, idx-250): idx+700])
print("\n---\n")
PYRepository: redhat-performance/benchmark-runner
Length of output: 2755
Enable blockMultiQueue with supplementalPool
ioThreadsPolicy: supplementalPool only improves disk parallelism when blockMultiQueue is enabled; with it set to false, the 8-thread pool won’t distribute virtio I/O as intended. The same pattern appears in the sibling Windows VM templates too.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@benchmark_runner/common/template_operations/templates/winfio/internal_data/winfio_vm_template.yaml`
around lines 46 - 47, The Windows VM template currently leaves blockMultiQueue
disabled even though ioThreadsPolicy is set to supplementalPool, so update the
VM template configuration to enable blockMultiQueue in the same section as
autoattachMemBalloon; use the existing winfio_vm_template settings as the
reference point and apply the same fix to the sibling Windows VM templates that
use supplementalPool.
| threads: 1 | ||
| devices: | ||
| autoattachMemBalloon: false | ||
| blockMultiQueue: false |
There was a problem hiding this comment.
🚀 Performance & Scalability | 🟡 Minor
🧩 Analysis chain
🌐 Web query:
Which KubeVirt version first supported ioThreadsPolicy supplementalPool and supplementalPoolThreadCount?
💡 Result:
The KubeVirt version that first introduced support for ioThreadsPolicy: supplementalPool and the associated supplementalPoolThreadCount setting is v1.6.0 [1][2]. While the functionality was initially developed under Pull Request #13110 [3], the explicit documentation and API description updates for these fields were finalized in PR #14405 [4], which was included in the v1.6.0 release [1][2]. Subsequent updates have continued to improve this feature, such as adding support for supplementalPoolThreadCount within the instancetype API in later releases [5][6]. { "top_results": [1][2][3][4] }
Citations:
- 1: https://kubevirt.io/2025/changelog-v1.6.0.html
- 2: https://github.com/kubevirt/kubevirt/releases/tag/v1.6.0
- 3: SupplementPool iothread policy and make use of virtio-queue mapping kubevirt/kubevirt#13110
- 4: Add supplementalPool to the description of the ioThreadsPolicy possible values kubevirt/kubevirt#14405
- 5: https://kubevirt.io/user-guide/release_notes/
- 6: instancetype: Add support for
IOThreadsto API kubevirt/kubevirt#15798
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Map the relevant files first
git ls-files 'tests/unittest/benchmark_runner/common/template_operations/golden_files/test_ci_windows_vm_ODF_PVC_True/windows_vm.yaml' \
'benchmark_runner/common/template_operations/templates/windows/internal_data/windows_vm_template.yaml' \
'benchmark_runner/common/template_operations/templates/windows/internal_data/*' \
'benchmark_runner/common/template_operations/templates/windows/*' \
'benchmark_runner/common/template_operations/templates/*' |
sed 's/^/FOUND: /'
echo
echo "--- outline windows_vm_template.yaml ---"
ast-grep outline benchmark_runner/common/template_operations/templates/windows/internal_data/windows_vm_template.yaml --view expanded
echo
echo "--- excerpt around ioThreadsPolicy / blockMultiQueue ---"
sed -n '60,90p' benchmark_runner/common/template_operations/templates/windows/internal_data/windows_vm_template.yaml
echo
echo "--- excerpt around same fields in golden file ---"
sed -n '60,90p' tests/unittest/benchmark_runner/common/template_operations/golden_files/test_ci_windows_vm_ODF_PVC_True/windows_vm.yamlRepository: redhat-performance/benchmark-runner
Length of output: 9743
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect surrounding usage of these fields in the repository.
rg -n "ioThreadsPolicy|supplementalPoolThreadCount|blockMultiQueue" benchmark_runner tests -g '!**/*.pyc'
echo
echo "--- locate the windows vm template source references ---"
rg -n "windows_vm_template\.yaml|windows_vm" benchmark_runner/common/template_operations/templates/windows -g '*.yaml' -g '*.py'Repository: redhat-performance/benchmark-runner
Length of output: 16132
🏁 Script executed:
#!/bin/bash
set -euo pipefail
python3 - <<'PY'
from pathlib import Path
p = Path('benchmark_runner/common/template_operations/templates/windows/internal_data/windows_vm_template.yaml')
text = p.read_text()
for needle in ['ioThreadsPolicy', 'supplementalPoolThreadCount', 'blockMultiQueue']:
idx = text.find(needle)
print(f'[{needle}] at', idx)
if idx != -1:
start = text.rfind('\n', 0, idx)
end = text.find('\n', idx)
print(text[max(0, start-200):min(len(text), end+200)])
print('---')
PYRepository: redhat-performance/benchmark-runner
Length of output: 1594
🌐 Web query:
KubeVirt ioThreadsPolicy supplementalPool blockMultiQueue semantics virtio queues
💡 Result:
In KubeVirt, the supplementalPool ioThreadsPolicy is designed to scale storage I/O performance by allowing a user-defined number of host-level IOThreads (specified via supplementalPoolThreadCount) to handle I/O requests [1][2]. This configuration is intended for high-performance workloads, such as those utilizing SSDs or NVMe, where a single I/O thread would otherwise become a bottleneck [3][2]. The semantics and key requirements are as follows: 1. blockMultiQueue Integration: Multiple IOThreads are supported only when blockMultiQueue is enabled (set to true) and the disk bus is configured as virtio [3]. Enabling blockMultiQueue allows the guest OS to utilize multiple virtio-blk queues, which facilitates the distribution of I/O workloads across multiple vCPUs [2]. 2. Virtio Queue Mapping: When both supplementalPool and blockMultiQueue are enabled, the host-level IOThreads are automatically mapped to the virtio queues within the guest [2]. This mapping allows I/O work to be effectively spread among both the host-level IOThreads and the guest vCPUs, preventing synchronization contention [2]. The number of virtio queues is automatically set to match the total number of vCPUs [2]. 3. Resource Allocation: The supplementalPoolThreadCount defines the number of host threads assigned to the I/O pool [1][2]. These threads are added to the pod's total CPU requirements [1][2]. If dedicatedCpuPlacement is set to true, each IOThread is pinned to a specific, additional physical CPU (pCPU) to prevent interference with vCPU threads [1][4]. 4. Configuration Constraints: - VM restart is required to apply changes to these settings [3]. - The supplementalPool policy cannot be used in conjunction with dedicatedCpuPlacement or isolateEmulatorThread [2]. - Ideal performance typically requires between 4-8 IOThreads, though the exact number depends on the specific workload [1][4]. This configuration improves I/O scalability by leveraging adaptive polling and avoiding the bottleneck of a single submission thread [2].
Citations:
- 1: https://kubevirt.io/user-guide/storage/disks_and_volumes/
- 2: https://developers.redhat.com/blog/2025/06/23/feature-introduction-multiple-iothreads-openshift-virtualization
- 3: https://docs.okd.io/4.19/virt/managing_vms/virt-edit-vms.html
- 4: SupplementPool iothread policy and make use of virtio-queue mapping kubevirt/kubevirt#13110
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Look for documentation or code comments describing the intended pairing.
rg -n "supplementalPool|blockMultiQueue|ioThreads" benchmark_runner tests DOCS README.md HOW_TO.md -g '*.md' -g '*.py' -g '*.yaml' -g '*.yml' -g '*.sh'
echo
echo "--- specific windows/winfio/winmssql template excerpts ---"
for f in \
benchmark_runner/common/template_operations/templates/windows/internal_data/windows_vm_template.yaml \
benchmark_runner/common/template_operations/templates/winfio/internal_data/winfio_vm_template.yaml \
benchmark_runner/common/template_operations/templates/winmssql/internal_data/winmssql_vm_template.yaml
do
echo "### $f"
sed -n '35,110p' "$f" | sed -n '/blockMultiQueue/,+20p;/ioThreads/,+10p'
echo
doneRepository: redhat-performance/benchmark-runner
Length of output: 20771
ioThreadsPolicy: supplementalPool should not be paired with blockMultiQueue: false.
KubeVirt only uses multiple IOThreads when blockMultiQueue is enabled, so the 8-thread supplemental pool here is ineffective as configured. Set blockMultiQueue: true in benchmark_runner/common/template_operations/templates/windows/internal_data/windows_vm_template.yaml (and regenerate the golden files), or drop the supplemental pool settings if single-queue I/O is intended.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@tests/unittest/benchmark_runner/common/template_operations/golden_files/test_ci_windows_vm_ODF_PVC_True/windows_vm.yaml`
at line 33, The Windows VM template is configuring ioThreadsPolicy:
supplementalPool without enabling blockMultiQueue, so the supplemental IO thread
pool is not actually used. Update the Windows VM template identified by
windows_vm_template.yaml to set blockMultiQueue to true, then regenerate the
affected golden files; if single-queue I/O is intended instead, remove the
supplemental pool-related settings from the template and corresponding test
fixture.
1 participant
Summary
Changes (applied to all 3 Windows VM templates)
autoattachMemBalloonfalsebootOrder1on root diskdedicatedIOThreadfalsetpmnetworkInterfaceMultiqueueevmcsenabled: truereenlightenmentresetioThreadssupplementalPoolThreadCount: 8ioThreadsPolicysupplementalPoolterminationGracePeriodSeconds0180evictionStrategyfirmwarepositionTest plan
🤖 Assisted-by: Claude Code
Summary by CodeRabbit
New Features
Bug Fixes