[Workload]: windows

Inizia leggendo le interfacce esistenti BaseWorkload e Workload, quindi segui l’implementazione di CloudInitUserdata() e il modo in cui vengono registrati gli attuali workload Linux. Definisci l’approccio di WindowsBaseWorkload basato su cloudbase-init e Scheduled Tasks, utilizzando i requisiti indicati per diskspd e i contatori delle prestazioni. Il lavoro è completato quando un singolo workload Windows VM può essere eseguito continuamente con le risorse richieste e segnali nativi di Windows.

Workload Name

windows

Workload Description

Windows VM workload that runs sustained resource pressure using native Windows tools — diskspd for disk I/O, typeperf/logman for performance counter generation, and optionally IIS serving HTTP traffic with bombardier as a load generator. Produces Windows-native signals (Performance Monitor counters, Event Log entries, disk throughput via diskspd) from inside a Windows Server VM on OpenShift Virtualization.

OpenShift Virtualization explicitly supports Windows VMs — Windows Server 2019/2022 and Windows 10/11 guests run with VirtIO drivers, QEMU guest agent, and full lifecycle management (start, stop, migrate, snapshot). Several partner categories specifically need Windows VM validation: monitoring partners whose agents run on both Linux and Windows, backup/DR partners whose products protect Windows workloads, and enterprise customers migrating Windows VMs from VMware to OpenShift.

Every existing virtwork workload targets Linux VMs exclusively. This is the first workload to expand platform coverage to Windows, opening a significant new validation surface that mirrors real-world enterprise deployments where mixed Linux/Windows VM fleets are common.

Tooling and Packages

Disk I/O (primary workload):

• Tool: diskspd (Microsoft's storage performance tool — spiritual successor to SQLIO)
• Installation: download from GitHub releases (single .exe, no installer)
• Command: diskspd -c1G -d0 -r -w30 -t4 -o8 -b64K -Sh -L C:\virtwork\testfile.dat
  • -c1G: 1 GiB test file
  • -d0: run indefinitely (0 = no duration limit)
  • -r: random I/O
  • -w30: 30% writes, 70% reads
  • -t4: 4 threads
  • -o8: 8 outstanding I/O operations
  • -b64K: 64 KiB block size
  • -Sh: disable software and hardware caching
  • -L: capture latency statistics

HTTP traffic (optional, requires IIS):

• Tool: IIS (Internet Information Services) + bombardier (HTTP benchmark)
• IIS: installed via Install-WindowsFeature Web-Server
• bombardier: single .exe download, generates sustained HTTP load

Performance counters:

• Tool: typeperf or logman (built into Windows)
• Captures: Processor(%), Memory(Available MBytes), PhysicalDisk(Disk Bytes/sec), Network Interface(Bytes Total/sec)

VM Count Model

Single VM (like cpu, memory, disk)

For the IIS variant, a VM pair (server + client) is possible, but the initial implementation should keep it simple: single Windows VM running diskspd + performance counter collection. HTTP testing can run against localhost (IIS + bombardier on the same VM).

Required Resources

• Persistent storage (DataVolume)
• Kubernetes Service (for inter-VM communication)
• Kubernetes Secret (for credentials or config)
• Additional CPU/memory beyond defaults
• GPU or special device passthrough

Windows VMs require more resources than Linux VMs: 4 GiB memory minimum (8 GiB recommended), 2+ CPU cores, and a 40+ GiB system disk. The data disk for diskspd testing should be a separate DataVolume (20+ GiB).

A Windows container disk image with VirtIO drivers pre-installed is required. Red Hat provides these via registry.redhat.io or they can be built using the Windows VM creation workflow documented in the OpenShift Virtualization docs.

Cloud-Init Details

Windows VMs use cloudbase-init (the Windows equivalent of cloud-init), not cloud-init. The configuration format is different:

# cloudbase-init userdata (PowerShell)
#ps1_sysnative
$ErrorActionPreference = "Stop"

# Create working directory
New-Item -ItemType Directory -Force -Path C:\virtwork

# Download diskspd
$diskspdUrl = "https://github.com/microsoft/diskspd/releases/download/v2.1/DiskSpd.ZIP"
Invoke-WebRequest -Uri $diskspdUrl -OutFile C:\virtwork\DiskSpd.zip
Expand-Archive -Path C:\virtwork\DiskSpd.zip -DestinationPath C:\virtwork\diskspd -Force

# Create diskspd scheduled task (Windows equivalent of systemd service)
$action = New-ScheduledTaskAction `
  -Execute "C:\virtwork\diskspd\amd64\diskspd.exe" `
  -Argument "-c1G -d0 -r -w30 -t4 -o8 -b64K -Sh -L D:\testfile.dat" `
  -WorkingDirectory "C:\virtwork"
$trigger = New-ScheduledTaskTrigger -AtStartup
$settings = New-ScheduledTaskSettingsSet `
  -RestartCount 999 `
  -RestartInterval (New-TimeSpan -Minutes 1) `
  -ExecutionTimeLimit (New-TimeSpan -Days 365)
$principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -RunLevel Highest
Register-ScheduledTask `
  -TaskName "VirtworkDiskWorkload" `
  -Action $action `
  -Trigger $trigger `
  -Settings $settings `
  -Principal $principal

# Create performance counter collection task
$counterAction = New-ScheduledTaskAction `
  -Execute "typeperf" `
  -Argument '"\Processor(_Total)\% Processor Time" "\Memory\Available MBytes" "\PhysicalDisk(_Total)\Disk Bytes/sec" "\Network Interface(*)\Bytes Total/sec" -si 10 -o C:\virtwork\perfcounters.csv'
$counterTrigger = New-ScheduledTaskTrigger -AtStartup
Register-ScheduledTask `
  -TaskName "VirtworkPerfCounters" `
  -Action $counterAction `
  -Trigger $counterTrigger `
  -Settings $settings `
  -Principal $principal

# Start tasks immediately
Start-ScheduledTask -TaskName "VirtworkDiskWorkload"
Start-ScheduledTask -TaskName "VirtworkPerfCounters"

# Enable WinRM for remote management (optional)
Enable-PSRemoting -Force -SkipNetworkProfileCheck

Use Case

• Monitoring partners (Datadog, Dynatrace, Sysdig, Zabbix): Every major monitoring product supports both Linux and Windows agents. Partners need Windows VMs producing real workload signals (CPU, disk I/O, memory pressure, Performance Monitor counters) to validate that their Windows agent works correctly in a KubeVirt VM — device discovery, metric collection, event forwarding. A monitoring partner that only validates on Linux VMs cannot claim full KubeVirt support.
• Backup/DR partners (Velero, Commvault, Veeam, Cohesity): Windows VM backup is the largest enterprise use case for backup products on OpenShift Virtualization. Partners need a Windows VM with active disk writes (diskspd) to validate VSS (Volume Shadow Copy Service) integration, application-consistent snapshots, and incremental backup correctness. The backup-churn workload covers Linux; this covers Windows.
• VMware-to-OpenShift migration partners (MTV, consulting): The #1 migration scenario is moving Windows Server VMs from VMware to OpenShift Virtualization. Partners need a reproducible Windows workload to validate post-migration performance equivalence. diskspd on Windows is the standard benchmark for this comparison — many migration reports already include diskspd results on VMware, and partners need the equivalent measurement on KubeVirt.
• Security/Compliance partners (CrowdStrike, Carbon Black, Microsoft Defender): Windows endpoint security products need a Windows VM with active processes, disk I/O, and network activity to validate that their agents detect and report correctly in a KubeVirt environment. Performance counters and Event Log entries are the telemetry sources these products consume.
• Enterprise customers: Mixed Linux/Windows VM fleets are the norm in enterprise environments. Customers evaluating OpenShift Virtualization need confidence that both OS families work under load. Having virtwork cover both Linux and Windows signals means a single tool validates the entire VM fleet.

Additional Context

• Significant engineering lift: This is the most complex workload to implement because it differs from every existing workload at multiple levels:
  1. Cloud-init → cloudbase-init: Different configuration format (PowerShell scripts vs YAML). The CloudInitUserdata() method must generate cloudbase-init-compatible userdata.
  2. systemd → Scheduled Tasks: Windows uses Scheduled Tasks for persistent, auto-restarting services. The pattern is Register-ScheduledTask with -AtStartup trigger and restart settings.
  3. Package management → direct download: No dnf install — tools are downloaded as .exe/.zip from GitHub releases or installed via Windows Features (Install-WindowsFeature).
  4. Base image: Requires a Windows container disk with VirtIO drivers and cloudbase-init pre-installed. Red Hat provides guidance but this is a heavier prerequisite than Linux images.
• Implementation approach: Consider a new WindowsBaseWorkload embedding type (parallel to BaseWorkload) that generates cloudbase-init PowerShell userdata instead of cloud-init YAML. This keeps the Workload interface unchanged while abstracting the OS-specific configuration generation.
• VirtIO drivers: Windows VMs require VirtIO drivers for disk, network, and balloon devices. These must be pre-installed in the container disk image or installed via the VirtIO driver ISO attached during first boot. The container disk approach is strongly recommended.
• QEMU Guest Agent: The QEMU guest agent for Windows (qemu-ga-x86_64.msi) should be pre-installed in the container disk image. It enables virtctl commands (freeze/thaw for snapshots, IP reporting, graceful shutdown) that partners rely on.
• Licensing: Windows Server evaluation licenses are valid for 180 days — sufficient for validation runs. Production deployments require customer-provided licenses. Document this clearly.
• diskspd is the standard: Microsoft's own storage performance tool, used by Azure, VMware, and Hyper-V validation workflows. Using the same tool means partners can directly compare KubeVirt results against other platforms.
• Resource requirements: Windows Server 2022 needs 4 GiB RAM minimum to run comfortably with diskspd active. The VM spec should set higher defaults than Linux workloads: 4 CPU cores, 8 GiB memory, 40 GiB system disk + 20 GiB data disk.