From 3e42ca74f497eb0c64e3dc0edfca8de0333e98f2 Mon Sep 17 00:00:00 2001 From: Melvin Hillsman Date: Mon, 1 Jun 2026 14:20:44 -0500 Subject: [PATCH 1/5] docs: fix architecture layers in virtwork-vs-kube-burner comparison Move audit to L1, add orchestrator to L4, add logging to L1. Add tps and chaos-* to L3 workload list. Signed-off-by: Melvin Hillsman --- docs/virtwork-vs-kube-burner.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/virtwork-vs-kube-burner.md b/docs/virtwork-vs-kube-burner.md index d4413f7..a2cd4fa 100644 --- a/docs/virtwork-vs-kube-burner.md +++ b/docs/virtwork-vs-kube-burner.md @@ -74,10 +74,10 @@ All workloads run as **systemd services** — they survive VM reboots and auto-r ```mermaid graph TD - L4["Layer 4 — Orchestration
cmd/virtwork · cleanup · audit"] - L3["Layer 3 — Workload Definitions
interface · cpu · memory · database · network · disk · registry"] + L4["Layer 4 — Orchestration
cmd/virtwork · orchestrator · cleanup"] + L3["Layer 3 — Workload Definitions
interface · cpu · memory · disk · database · network · tps · chaos-* · registry"] L2["Layer 2 — K8s Abstractions
vm · resources · wait"] - L1["Layer 1 — Infrastructure
config · cluster · cloudinit"] + L1["Layer 1 — Infrastructure
config · cluster · cloudinit · logging · audit"] L0["Layer 0 — Definitions
constants"] L4 --> L3 --> L2 --> L1 --> L0 From 5852d8a42b87d87b9eb7df944c8e3f988acb5d60 Mon Sep 17 00:00:00 2001 From: Melvin Hillsman Date: Mon, 1 Jun 2026 14:21:04 -0500 Subject: [PATCH 2/5] docs: add tps and chaos workloads to comparison workload table Add tps, chaos-disk, chaos-network, and chaos-process to the workload table (9 total, was 5). Extend the narrative to explain how chaos workloads strengthen the positioning by adding failure injection as a signal category. Signed-off-by: Melvin Hillsman --- docs/virtwork-vs-kube-burner.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/virtwork-vs-kube-burner.md b/docs/virtwork-vs-kube-burner.md index a2cd4fa..ea36a07 100644 --- a/docs/virtwork-vs-kube-burner.md +++ b/docs/virtwork-vs-kube-burner.md @@ -66,9 +66,13 @@ Workloads deployed inside VMs: | `memory` | `stress-ng --vm 1 --vm-bytes 80%` | Sustained memory pressure at 80% | | `database` | PostgreSQL + `pgbench -c 10 -j 2 -T 300` | Realistic OLTP database transactions | | `network` | `iperf3 --bidir` (server + client VM pairs) | Bidirectional throughput between VMs | +| `tps` | `netperf` + `curl` (server + client VM pairs) | Multi-port HTTP throughput with configurable file size, iterations, and duration | | `disk` | `fio` with mixed random + sequential profiles | Mixed I/O patterns on a dedicated data disk | +| `chaos-disk` | `fallocate`/`dd` fill-release loop | Sustained disk-pressure events on a data disk | +| `chaos-network` | `tc` + `netem` qdisc | Injected latency and packet loss on VM egress | +| `chaos-process` | shell + `ps`/`kill` | Random process termination inside the VM | -All workloads run as **systemd services** — they survive VM reboots and auto-restart on failure. They produce realistic CPU, memory, database, network, and disk I/O signals for monitoring systems to observe and validate. +All workloads run as **systemd services** — they survive VM reboots and auto-restart on failure. They produce realistic CPU, memory, database, network, and disk I/O signals for monitoring systems to observe and validate. The three chaos workloads extend this by injecting failures — disk pressure, network degradation, process kills — that exercise a partner product's alerting, recovery, and resilience handling. #### virtwork layered architecture From 135cb3341a8c58548d0650051fb74636dca5cdfe Mon Sep 17 00:00:00 2001 From: Melvin Hillsman Date: Mon, 1 Jun 2026 14:21:19 -0500 Subject: [PATCH 3/5] docs: drop stale maturity stats and fix GitHub URL in comparison doc Replace frozen commit/contributor counts with generic "Active development" to avoid future drift. Update GitHub URL from redhat-openshift-partner-labs/virtwork to opdev/virtwork to match go.mod module path. Signed-off-by: Melvin Hillsman --- docs/virtwork-vs-kube-burner.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/virtwork-vs-kube-burner.md b/docs/virtwork-vs-kube-burner.md index ea36a07..8db46ad 100644 --- a/docs/virtwork-vs-kube-burner.md +++ b/docs/virtwork-vs-kube-burner.md @@ -119,7 +119,7 @@ Strict layering: no cross-layer dependencies. Each layer only depends on the lay | **Monitoring role** | Scrapes cluster metrics, indexes to ES/OpenSearch/local | Produces metrics *for* external monitoring tools to scrape | | **SSH access** | Via `virtctl ssh` in virt-density tests | First-class: `--ssh-user`, `--ssh-key-file`; `virtctl ssh` or port-forward | | **Deployment** | Binary or container, runs externally to cluster | Binary or Kustomize-deployed pod running in-cluster | -| **Maturity** | Active, community-maintained, CNCF-adjacent | Beta (0 stars, 58 commits, 2 contributors as of Feb 2026) | +| **Maturity** | Active, community-maintained, CNCF-adjacent | Active development | --- @@ -336,7 +336,7 @@ Used together, the two tools cover the full picture: kube-burner establishes tha - [kube-burner Configuration Reference — KubeVirt](https://kube-burner.github.io/kube-burner/latest/reference/configuration/#kubevirt) - [kube-burner-ocp GitHub](https://github.com/kube-burner/kube-burner-ocp) - [kube-burner-ocp Virt Workloads Docs](https://kube-burner.github.io/kube-burner-ocp/latest/) -- [virtwork GitHub](https://github.com/redhat-openshift-partner-labs/virtwork) +- [virtwork GitHub](https://github.com/opdev/virtwork) - [OpenShift Partner Lab Overview](https://connect.redhat.com/en/blog/the-openshift-partner-lab) - [Red Hat Virt Density Blog — kube-burner usage](https://developers.redhat.com/blog/2025/11/17/high-scale-performance-testing-virt-density) - [Use kube-burner to measure OpenShift VM and storage deployment at scale](https://developers.redhat.com/articles/2024/09/04/use-kube-burner-measure-red-hat-openshift-vm-and-storage-deployment-scale) From 1e12fea8035ff548b3b3188f505fa23327d93c6d Mon Sep 17 00:00:00 2001 From: Melvin Hillsman Date: Mon, 1 Jun 2026 14:21:33 -0500 Subject: [PATCH 4/5] docs: update sequence diagram and YAML example with full workload set Simplify sequence diagram to bare 'virtwork run' (all 9 workloads are the default). Expand YAML config example to include tps, chaos-disk, chaos-network, and chaos-process alongside the original five. Signed-off-by: Melvin Hillsman --- docs/virtwork-vs-kube-burner.md | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/docs/virtwork-vs-kube-burner.md b/docs/virtwork-vs-kube-burner.md index 8db46ad..f58c882 100644 --- a/docs/virtwork-vs-kube-burner.md +++ b/docs/virtwork-vs-kube-burner.md @@ -245,7 +245,7 @@ sequenceDiagram Eng->>KB: virt-density run KB-->>Eng: ✓ Boot latency acceptable
✓ Cluster handles VM density - Eng->>VW: virtwork run --workloads cpu,memory,database,network,disk + Eng->>VW: virtwork run VW-->>Eng: ✓ VMs created
✓ systemd services started
✓ Run ID logged to SQLite Note over VW: virtwork exits — systemd
keeps workloads running @@ -302,15 +302,25 @@ workloads: vm_count: 2 cpu_cores: 4 memory: 4Gi + memory: + enabled: true + disk: + enabled: true database: enabled: true cpu_cores: 2 memory: 4Gi network: - enabled: true # creates N×2 VMs: server + client pairs - disk: + enabled: true # creates server + client VM pairs + tps: enabled: true - memory: + params: + file-size: "50M" + chaos-disk: + enabled: true + chaos-network: + enabled: true + chaos-process: enabled: true ``` From 0bc4bbeb6ca3e2758279af5e68815273438894b1 Mon Sep 17 00:00:00 2001 From: Melvin Hillsman Date: Mon, 1 Jun 2026 14:22:01 -0500 Subject: [PATCH 5/5] docs: add chaos and tps workloads to decision guide and partner validation Add chaos/resilience testing path and tps to the decision flowchart. Update partner product validation table to show how chaos workloads exercise alerting and recovery handling for storage, monitoring, and network products. Add netperf/curl to the network row for tps. Signed-off-by: Melvin Hillsman --- docs/virtwork-vs-kube-burner.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/docs/virtwork-vs-kube-burner.md b/docs/virtwork-vs-kube-burner.md index f58c882..bd88f20 100644 --- a/docs/virtwork-vs-kube-burner.md +++ b/docs/virtwork-vs-kube-burner.md @@ -175,9 +175,10 @@ flowchart TD Q2 -->|Storage — disk I/O| B1["virtwork
--workloads disk"] Q2 -->|Monitoring — CPU/memory metrics| B2["virtwork
--workloads cpu,memory"] - Q2 -->|Network — VM-to-VM throughput| B3["virtwork
--workloads network"] + Q2 -->|Network — VM-to-VM throughput| B3["virtwork
--workloads network,tps"] Q2 -->|Database — OLTP load| B4["virtwork
--workloads database"] - Q2 -->|All of the above on OPL bare metal| B5["virtwork
all workloads enabled by default"] + Q2 -->|Chaos / resilience testing| B5["virtwork
--workloads chaos-disk,chaos-network,chaos-process"] + Q2 -->|All of the above on OPL bare metal| B6["virtwork
all nine workloads enabled by default"] style A1 fill:#1a3a5c,stroke:#4a9eda,color:#eee style A2 fill:#1a3a5c,stroke:#4a9eda,color:#eee @@ -189,6 +190,7 @@ flowchart TD style B3 fill:#3a1a1a,stroke:#e94560,color:#eee style B4 fill:#3a1a1a,stroke:#e94560,color:#eee style B5 fill:#3a1a1a,stroke:#e94560,color:#eee + style B6 fill:#3a1a1a,stroke:#e94560,color:#eee style Start fill:#2a2a2a,stroke:#aaa,color:#fff style Q1 fill:#1e1e1e,stroke:#888,color:#eee style Q2 fill:#1e1e1e,stroke:#888,color:#eee @@ -222,9 +224,9 @@ In the OpenShift Partner Labs (OPL) context, a **partner product** is an ISV's t | Partner Product Type | What "handles" actually means | |---|---| -| **Storage** | Does your storage driver correctly serve VM disk I/O? Does it report IOPS and throughput accurately? Does it stay stable under `fio` mixed read/write load? | -| **Monitoring** | Does your monitoring agent correctly scrape CPU, memory, and disk metrics from inside VMs? Do your dashboards reflect what `stress-ng` and `fio` are actually doing? | -| **Network** | Does your CNI or network product correctly route `iperf3 --bidir` traffic between VMs? Does it report the right throughput? Does it hold up under sustained bidirectional load? | +| **Storage** | Does your storage driver correctly serve VM disk I/O? Does it report IOPS and throughput accurately? Does it stay stable under `fio` mixed read/write load? Does it alert correctly when `chaos-disk` fills the volume to 90%? | +| **Monitoring** | Does your monitoring agent correctly scrape CPU, memory, and disk metrics from inside VMs? Do your dashboards reflect what `stress-ng` and `fio` are actually doing? Do your alerts fire when `chaos-process` kills monitored processes? | +| **Network** | Does your CNI or network product correctly route `iperf3 --bidir` and `netperf`/`curl` traffic between VMs? Does it report the right throughput? Does it detect the latency and packet loss injected by `chaos-network`? | | **Database** | Does your product correctly observe or manage a PostgreSQL instance under `pgbench` OLTP load running inside a VM? | virtwork exists specifically to generate the signals each of these product categories needs to prove the answer is yes — on OpenShift Partner Labs (OPL) bare metal, against real KubeVirt VMs, with workloads that outlast the tool that created them.