WIP feat(kubevirt): Add VM management toolset #386

lyarwood · 2025-10-21T14:52:27Z

A very draft PR to start discussions about including a targeted KubeVirt toolset into the project focused on creating and troubleshooting VMs.

pkg/toolsets/kubevirt/vm/create/tool.go

pkg/toolsets/kubevirt/vm/create/plan.tmpl

pkg/toolsets/kubevirt/vm/create/tool.go

ksimon1 · 2025-11-04T08:08:29Z

pkg/toolsets/kubevirt/vm/create/tool.go

+}
+
+// extractDataSourceInfo extracts source information from a DataSource object
+func extractDataSourceInfo(obj *unstructured.Unstructured) string {


Would it make sense to import here the CDI package and use structures from there?

Only if we really need it tbh, I don't think anything requires it just yet.

pkg/toolsets/kubevirt/vm/troubleshoot/plan.tmpl

Introduces a new KubeVirt toolset providing virtual machine management capabilities through MCP tools. The vm_create tool generates comprehensive creation plans with pre-creation validation of instance types, preferences, and container disk images, enabling AI assistants to help users create VirtualMachines with appropriate resource configurations. The tool supports: - Workload specification via OS names or container disk URLs - Auto-selection of instance types based on size/performance hints - DataSource integration for common OS images - Comprehensive validation and planning before resource creation Assisted-By: Claude <[email protected]> Signed-off-by: Lee Yarwood <[email protected]>

…late Implements a new troubleshoot tool for VirtualMachines in the kubevirt toolset. The tool provides automated diagnostic plans based on VM status, conditions, and common issues, helping users identify and resolve VM problems efficiently. Adds: - Troubleshoot tool implementation with structured diagnostic output - Template-based diagnostic plan generation - Comprehensive test coverage for the troubleshoot functionality Assisted-By: Claude <[email protected]> Signed-off-by: Lee Yarwood <[email protected]>

The 'latest' tag for several containerdisk images was either missing or not the most appropriate tag to use. This change updates the image references to specific, valid tags to ensure reliability. - 'ubuntu' is updated from 'latest' to '24.04'. - 'centos-stream' is updated from 'latest' to '9-latest'. - 'opensuse-tumbleweed' is updated from 'latest' to '1.0.0'. - 'opensuse-leap' is updated from 'latest' to '15.6'. Assisted-By: Claude <[email protected]> Signed-off-by: Lee Yarwood <[email protected]>

Signed-off-by: Lee Yarwood <[email protected]>

Previously, the vm_create tool only searched for DataSources in the OpenShift-specific 'openshift-virtualization-os-images' namespace. This change extends the search to also include the 'kubevirt-os-images' namespace, which is commonly used in upstream KubeVirt deployments. The logic for querying a namespace has been refactored into a helper function to accommodate searching multiple well-known locations for boot images. Assisted-By: Claude <[email protected]> Signed-off-by: Lee Yarwood <[email protected]>

Signed-off-by: Lee Yarwood <[email protected]>

Break down the searchDataSources function into smaller, focused helper functions: - getDynamicClient: Handles dynamic client initialization - collectDataSources: Collects DataSources from well-known and all namespaces - deduplicateAndMergeDataSources: Merges and deduplicates DataSource results This improves code readability and maintainability by following the single responsibility principle. Assisted-By: Claude <[email protected]> Signed-off-by: Lee Yarwood <[email protected]>

Decompose the create function into smaller, focused helper functions: - parseCreateParameters: Parses and validates input parameters into a struct - matchDataSource: Matches workload input against available DataSources - resolvePreference: Resolves preference from DataSource defaults or cluster resources - resolveInstancetype: Resolves instancetype from DataSource defaults or size/performance hints - matchInstancetypeBySize: Matches instancetype based on size and performance criteria - filterInstancetypesBySize: Filters instancetypes by size hint - buildTemplateParams: Constructs vmParams from resolved resources - renderTemplate: Renders the VM creation plan template This refactoring improves code organization and readability by: - Following the single responsibility principle - Making the main create function a clear orchestrator - Reducing complexity and improving testability - Enhancing maintainability through focused, reusable functions Assisted-By: Claude <[email protected]> Signed-off-by: Lee Yarwood <[email protected]>

Extend the VM creation tool to search for both cluster-wide and namespaced resources: - Update searchPreferences to query: - VirtualMachineClusterPreference (cluster-wide) - VirtualMachinePreference (namespaced) - Update searchInstancetypes to query: - VirtualMachineClusterInstancetype (cluster-wide) - VirtualMachineInstancetype (namespaced) This allows the tool to discover and use namespaced preferences and instancetypes in addition to cluster-wide resources, providing more flexibility for VM creation in multi-tenant environments where resources may be scoped to specific namespaces. The namespace context is passed from the VM creation request, enabling the search to include resources from the target namespace where the VM will be created. Assisted-By: Claude <[email protected]> Signed-off-by: Lee Yarwood <[email protected]>

…uide Extend the DataVolume troubleshooting section (Step 3) to include: - Check underlying PersistentVolumeClaim (PVC) status - Verify PVC phase is "Bound" - Check storage class name and capacity - Common PVC issues and their meanings - Check StorageClass when PVC is pending - Verify storage class exists - Ensure provisioner is healthy This provides more comprehensive guidance for diagnosing storage-related issues, as PVC problems are often the root cause of DataVolume failures. The enhanced troubleshooting steps help users identify issues with: - Storage class availability - Provisioner health - Storage capacity - PVC binding problems Assisted-By: Claude <[email protected]> Signed-off-by: Lee Yarwood <[email protected]>

Introduce a comprehensive gevals testing framework to validate VM lifecycle operations including creation with various configurations (basic, Ubuntu, instancetypes, performance, sizing) and troubleshooting scenarios. This enables automated verification of the KubeVirt toolset's functionality and regression prevention. Assisted-By: Claude <[email protected]> Signed-off-by: Lee Yarwood <[email protected]>

…ed helpers Extract common verification patterns from VM test tasks into a shared helper library to improve code reuse, maintainability, and consistency. Changes: - Create shared verification helper library in tests/helpers/ - verify-vm.sh: 8 reusable verification functions with flexible matching - README.md: Comprehensive documentation with usage examples - Refactor all VM test tasks to use shared helpers: - create-vm-basic: 43 → 33 lines (~23% reduction) - create-vm-ubuntu: 43 → 33 lines (~23% reduction) - create-vm-with-size: 62 → 39 lines (~37% reduction) - create-vm-with-instancetype: 59 → 39 lines (~34% reduction) - create-vm-with-performance: 72 → 45 lines (~38% reduction) Helper Functions: - verify_vm_exists: Wait for VM creation - verify_container_disk: Verify OS container disk (checks all volumes) - verify_run_strategy: Check runStrategy (accepts spec or status) - verify_instancetype: Verify instancetype with optional exact match - verify_instancetype_contains: Check instancetype contains substring - verify_instancetype_prefix: Check instancetype starts with prefix - verify_no_direct_resources: Verify VM uses instancetype - verify_has_resources_or_instancetype: Verify either instancetype or resources Bug Fixes: - Fix volume name verification to check all volumes instead of specific names (handles different VM creation approaches) - Fix runStrategy verification to accept both spec.runStrategy and status.runStrategy (handles deprecated 'running' field) Benefits: - Eliminated ~150 lines of duplicated verification code - Single source of truth for verification logic - More maintainable and easier to extend - Consistent error messages and output formatting - Tests are more concise and readable Assisted-By: Claude <[email protected]> Signed-off-by: Lee Yarwood <[email protected]>

…eprecated running field Strengthen the VM creation guidance and add explicit test assertions to ensure the deprecated 'running' field is not used in VirtualMachine specs. Changes to VM Creation Template (plan.tmpl): - Add prominent warning section about deprecated 'running' field - Include side-by-side comparison showing incorrect vs. correct usage - Clear visual indicators (❌ INCORRECT vs. ✅ CORRECT) - Emphasize that 'runStrategy' must be used instead Changes to Test Helper Functions (verify-vm.sh): - Add new `verify_no_deprecated_running_field()` function - Explicitly checks that spec.running is not set - Returns failure if deprecated field is found - Provides clear error message directing users to use runStrategy Changes to Test Tasks (all 5 VM creation tests): - Add assertion in all test tasks to verify running field is not used - Tests now explicitly call `verify_no_deprecated_running_field()` - Ensures compliance with KubeVirt best practices - Tests fail if VMs are created with deprecated field Benefits: - Prevents use of deprecated KubeVirt API fields - Explicit test coverage for API field deprecation - Clear guidance for AI assistants creating VMs - Ensures forward compatibility with future KubeVirt versions - Enforces best practices through automated testing Assisted-By: Claude <[email protected]> Signed-off-by: Lee Yarwood <[email protected]>

lyarwood · 2025-11-05T09:45:05Z

Just dumping some test output using genmcp/gevals#24 to help visualise the results and ccusage to give an indication of usage. As this was my first use of claude today I've just used the daily report, it would be nice if gevals included /cost and /context data allowing us to assert against it potentially.

$ gevals eval pkg/toolsets/kubevirt/vm/tests/claude-code/eval.yaml
[..]
=== Overall Statistics ===
Total Tasks: 6
Tasks Passed: 6/6
Assertions Passed: 18/18
[..]
$ gevals view gevals-kubevirt-vm-operations-out.json
Task: create-basic-vm
  Path: /home/lyarwood/redhat/devel/src/k8s/kubernetes-mcp-server/pkg/toolsets/kubevirt/vm/tests/tasks/create-vm-basic/create-vm-basic.yaml
  Difficulty: easy
  Status: PASSED
  Prompt: Please create a Fedora virtual machine named test-vm in the vm-test namespace.
  Assertions: 3/3 passed
  Call history: tools=2 (kubernetes:2 ok)
    Tool output:
      • kubernetes::vm_create (ok)
        # VirtualMachine Creation Plan
        **IMPORTANT**: Always use `runStrategy` instead of the deprecated `running` field when creating
        VirtualMachines.
        Use the `resources_create_or_update` tool with the following YAML:
        ```yaml
        apiVersion: kubevirt.io/v1
        kind: VirtualMachine
        metadata:
          name: test-vm
          namespace: vm-test
        … (+59 lines)
      • kubernetes::resources_create_or_update (ok)
        # The following resources (YAML) have been created or updated successfully
        - apiVersion: kubevirt.io/v1
          kind: VirtualMachine
          metadata:
            creationTimestamp: "2025-11-05T09:25:51Z"
            generation: 1
            managedFields:
            - apiVersion: kubevirt.io/v1
              fieldsType: FieldsV1
              fieldsV1:
                f:spec:
                  f:preference:
        … (+44 lines)
  Timeline:
    - unparsed event: Perfect! I've successfully created a Fedora virtual machine named `test-vm` in the `vm-test` namesp…
    - unparsed event: The VM has been created with the following configuration:
    - unparsed event: - **Name**: test-vm
    - unparsed event: - **Namespace**: vm-test
    - unparsed event: - **OS**: Fedora (using the latest Fedora container disk from quay.io)
    - unparsed event: - **Memory**: 2 GiB
    - unparsed event: - **Run Strategy**: Always (the VM will start automatically and restart if it fails)
    - unparsed event: - **Preference**: Uses the fedora VirtualMachineClusterPreference for optimal Fedora settings
    - unparsed event: The VM is configured to start automatically. You can check its status with kubectl or virtctl comma…

Task: create-ubuntu-vm
  Path: /home/lyarwood/redhat/devel/src/k8s/kubernetes-mcp-server/pkg/toolsets/kubevirt/vm/tests/tasks/create-vm-ubuntu/create-vm-ubuntu.yaml
  Difficulty: easy
  Status: PASSED
  Prompt: Create an Ubuntu virtual machine named ubuntu-vm in the vm-test namespace.
  Assertions: 3/3 passed
  Call history: tools=2 (kubernetes:2 ok)
    Tool output:
      • kubernetes::vm_create (ok)
        # VirtualMachine Creation Plan
        **IMPORTANT**: Always use `runStrategy` instead of the deprecated `running` field when creating
        VirtualMachines.
        Use the `resources_create_or_update` tool with the following YAML:
        ```yaml
        apiVersion: kubevirt.io/v1
        kind: VirtualMachine
        metadata:
          name: ubuntu-vm
          namespace: vm-test
        … (+59 lines)
      • kubernetes::resources_create_or_update (ok)
        # The following resources (YAML) have been created or updated successfully
        - apiVersion: kubevirt.io/v1
          kind: VirtualMachine
          metadata:
            creationTimestamp: "2025-11-05T09:26:24Z"
            generation: 1
            managedFields:
            - apiVersion: kubevirt.io/v1
              fieldsType: FieldsV1
              fieldsV1:
                f:spec:
                  f:preference:
        … (+44 lines)
  Timeline:
    - unparsed event: Perfect! I've successfully created the Ubuntu virtual machine named **ubuntu-vm** in the **vm-test*…
    - unparsed event: The VM has been created with the following configuration:
    - unparsed event: - **Name**: ubuntu-vm
    - unparsed event: - **Namespace**: vm-test
    - unparsed event: - **OS**: Ubuntu 24.04 (using quay.io/containerdisks/ubuntu:24.04)
    - unparsed event: - **Memory**: 2Gi
    - unparsed event: - **runStrategy**: Halted (VM is currently stopped)
    - unparsed event: The VM is currently in a stopped state (`runStrategy: Halted`). To start the VM, you have a few opt…
    - unparsed event: 1. **Change to Always running**: Modify the VM to use `runStrategy: Always`
    - unparsed event: 2. **Manual control**: Change to `runStrategy: Manual` and use `virtctl start ubuntu-vm`
    - unparsed event: 3. **Run once**: Change to `runStrategy: Once` to run it once and stop when it terminates
    - unparsed event: Would you like me to start the VM by changing the runStrategy to `Always`?

Task: create-vm-with-instancetype
  Path: /home/lyarwood/redhat/devel/src/k8s/kubernetes-mcp-server/pkg/toolsets/kubevirt/vm/tests/tasks/create-vm-with-instancetype/create-vm-with-instancetype.yaml
  Difficulty: medium
  Status: PASSED
  Prompt: Create a Fedora virtual machine named test-vm-instancetype in the vm-test namespace with instancetype 'u1.medium'. Use the vm_create tool to generate the creation plan and then create the VirtualMachine resource.
  Assertions: 3/3 passed
  Call history: tools=2 (kubernetes:2 ok)
    Tool output:
      • kubernetes::vm_create (ok)
        # VirtualMachine Creation Plan
        **IMPORTANT**: Always use `runStrategy` instead of the deprecated `running` field when creating
        VirtualMachines.
        Use the `resources_create_or_update` tool with the following YAML:
        ```yaml
        apiVersion: kubevirt.io/v1
        kind: VirtualMachine
        metadata:
          name: test-vm-instancetype
          namespace: vm-test
        … (+60 lines)
      • kubernetes::resources_create_or_update (ok)
        # The following resources (YAML) have been created or updated successfully
        - apiVersion: kubevirt.io/v1
          kind: VirtualMachine
          metadata:
            creationTimestamp: "2025-11-05T09:26:49Z"
            generation: 1
            managedFields:
            - apiVersion: kubevirt.io/v1
              fieldsType: FieldsV1
              fieldsV1:
                f:spec:
                  f:instancetype:
        … (+46 lines)
  Timeline:
    - unparsed event: Perfect! I've successfully created the Fedora virtual machine named `test-vm-instancetype` in the `…
    - unparsed event: ## Summary
    - unparsed event: **VirtualMachine Details:**
    - unparsed event: - **Name**: test-vm-instancetype
    - unparsed event: - **Namespace**: vm-test
    - unparsed event: - **Instance Type**: u1.medium (VirtualMachineClusterInstancetype)
    - unparsed event: - **Preference**: fedora (VirtualMachineClusterPreference)
    - unparsed event: - **Container Disk**: quay.io/containerdisks/fedora:latest
    - unparsed event: - **Run Strategy**: Halted (VM is currently stopped)
    - unparsed event: The VM has been created successfully with the following characteristics:
    - unparsed event: - Architecture: amd64
    - unparsed event: - Machine type: q35
    - unparsed event: - Uses the Fedora preference for optimal Fedora guest configuration
    - unparsed event: ## Next Steps
    - unparsed event: Since the VM was created with `runStrategy: Halted`, it's currently stopped. To start the VM, you c…
    - unparsed event: 1. **Update the runStrategy to `Always`** to automatically start and keep the VM running
    - unparsed event: 2. **Use `runStrategy: Manual`** and control it with virtctl commands (`virtctl start test-vm-insta…
    - unparsed event: Would you like me to start the VM by updating its runStrategy, or would you prefer to keep it stopp…

Task: create-vm-with-performance
  Path: /home/lyarwood/redhat/devel/src/k8s/kubernetes-mcp-server/pkg/toolsets/kubevirt/vm/tests/tasks/create-vm-with-performance/create-vm-with-performance.yaml
  Difficulty: medium
  Status: PASSED
  Prompt: Create a Fedora virtual machine named test-vm-performance in the vm-test namespace with performance family 'compute-optimized' and size 'medium'. Use the vm_create tool to generate the creation plan and then create the VirtualMachine resource.
  Assertions: 3/3 passed
  Call history: tools=2 (kubernetes:2 ok)
    Tool output:
      • kubernetes::vm_create (ok)
        # VirtualMachine Creation Plan
        **IMPORTANT**: Always use `runStrategy` instead of the deprecated `running` field when creating
        VirtualMachines.
        Use the `resources_create_or_update` tool with the following YAML:
        ```yaml
        apiVersion: kubevirt.io/v1
        kind: VirtualMachine
        metadata:
          name: test-vm-performance
          namespace: vm-test
        … (+60 lines)
      • kubernetes::resources_create_or_update (ok)
        # The following resources (YAML) have been created or updated successfully
        - apiVersion: kubevirt.io/v1
          kind: VirtualMachine
          metadata:
            creationTimestamp: "2025-11-05T09:27:17Z"
            generation: 1
            managedFields:
            - apiVersion: kubevirt.io/v1
              fieldsType: FieldsV1
              fieldsV1:
                f:spec:
                  f:instancetype:
        … (+46 lines)
  Timeline:
    - unparsed event: Successfully created the VirtualMachine! Here's a summary:
    - unparsed event: **VM Details:**
    - unparsed event: - **Name**: test-vm-performance
    - unparsed event: - **Namespace**: vm-test
    - unparsed event: - **Workload**: Fedora (using `quay.io/containerdisks/fedora:latest`)
    - unparsed event: - **Instance Type**: cx1.medium (compute-optimized, medium size)
    - unparsed event: - **Preference**: fedora
    - unparsed event: - **Initial State**: Halted (stopped)
    - unparsed event: The VM has been created with compute-optimized performance settings as requested. Since it's create…
    - unparsed event: 1. **Always running**: Change `runStrategy: Halted` to `runStrategy: Always`
    - unparsed event: 2. **Manual control**: Change to `runStrategy: Manual` and use `virtctl start test-vm-performance`
    - unparsed event: 3. **Run once**: Change to `runStrategy: Once` to run the VM once until it terminates
    - unparsed event: The VM is configured with:
    - unparsed event: - Architecture: amd64
    - unparsed event: - Machine type: q35
    - unparsed event: - Firmware with unique UUID and serial number
    - unparsed event: - Root disk from the Fedora container disk image

Task: create-vm-with-size
  Path: /home/lyarwood/redhat/devel/src/k8s/kubernetes-mcp-server/pkg/toolsets/kubevirt/vm/tests/tasks/create-vm-with-size/create-vm-with-size.yaml
  Difficulty: medium
  Status: PASSED
  Prompt: Create a Fedora virtual machine named test-vm-size in the vm-test namespace with size 'large'. Use the vm_create tool to generate the creation plan and then create the VirtualMachine resource.
  Assertions: 3/3 passed
  Call history: tools=2 (kubernetes:2 ok)
    Tool output:
      • kubernetes::vm_create (ok)
        # VirtualMachine Creation Plan
        **IMPORTANT**: Always use `runStrategy` instead of the deprecated `running` field when creating
        VirtualMachines.
        Use the `resources_create_or_update` tool with the following YAML:
        ```yaml
        apiVersion: kubevirt.io/v1
        kind: VirtualMachine
        metadata:
          name: test-vm-size
          namespace: vm-test
        … (+60 lines)
      • kubernetes::resources_create_or_update (ok)
        # The following resources (YAML) have been created or updated successfully
        - apiVersion: kubevirt.io/v1
          kind: VirtualMachine
          metadata:
            creationTimestamp: "2025-11-05T09:27:48Z"
            generation: 1
            managedFields:
            - apiVersion: kubevirt.io/v1
              fieldsType: FieldsV1
              fieldsV1:
                f:spec:
                  f:instancetype:
        … (+46 lines)
  Timeline:
    - unparsed event: Perfect! I've successfully created the Fedora virtual machine named **test-vm-size** in the **vm-te…
    - unparsed event: ## Summary
    - unparsed event: The VM has been created with the following configuration:
    - unparsed event: - **Name**: test-vm-size
    - unparsed event: - **Namespace**: vm-test
    - unparsed event: - **Instance Type**: u1.2xlarge (automatically selected based on size 'large')
    - unparsed event: - **Preference**: fedora
    - unparsed event: - **Container Disk Image**: quay.io/containerdisks/fedora:latest
    - unparsed event: - **Run Strategy**: Halted (VM is created but not running)
    - unparsed event: The VM is currently in a **Halted** state. To start the VM, you can either:
    - unparsed event: 1. Change the `runStrategy` to `Always` to have it automatically start and restart
    - unparsed event: 2. Use `runStrategy: Manual` and start it with virtctl commands
    - unparsed event: The VM has been successfully created with UID `03d4116f-a958-4e58-8a5c-06e0c8fa6ce3`.

Task: troubleshoot-vm
  Path: /home/lyarwood/redhat/devel/src/k8s/kubernetes-mcp-server/pkg/toolsets/kubevirt/vm/tests/tasks/troubleshoot-vm/troubleshoot-vm.yaml
  Difficulty: easy
  Status: PASSED
  Prompt: A VirtualMachine named broken-vm in the vm-test namespace is having issues.
  Assertions: 3/3 passed
  Call history: tools=5 (kubernetes:5 ok)
    Tool output:
      • kubernetes::vm_troubleshoot (ok)
        # VirtualMachine Troubleshooting Guide
        ## VM: broken-vm (namespace: vm-test)
        Follow these steps to diagnose issues with the VirtualMachine:
        ---
        ## Step 1: Check VirtualMachine Status
        Use the `resources_get` tool to inspect the VirtualMachine:
        - **apiVersion**: `kubevirt.io/v1`
        … (+176 lines)
      • kubernetes::resources_get (ok)
        apiVersion: kubevirt.io/v1
        kind: VirtualMachine
        metadata:
          annotations:
            kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"kubevirt.io/v1","kind":"VirtualMachine","metadata":{"annotations":{},"name":"broken-vm","namespace":"vm-test"},"spec":{"runStrategy":"Halted","template":{"spec":{"domain":{"devices":{"disks":[{"disk":{"bus":"virtio"},"name":"containerdisk"}]},"resources":{"requests":{"memory":"1Gi"}}},"volumes":[{"containerDisk":{"image":"quay.io/containerdisks/fedora:latest"},"name":"containerdisk"}]}}}}
            kubevirt.io/latest-observed-api-version: v1
            kubevirt.io/storage-observed-api-version: v1
          creationTimestamp: "2025-11-05T09:28:03Z"
          finalizers:
          - kubevirt.io/virtualMachineControllerFinalize
          generation: 1
        … (+42 lines)
      • kubernetes::resources_get (ok)
        failed to get resource: virtualmachineinstances.kubevirt.io "broken-vm" not found
      • kubernetes::pods_list_in_namespace (ok)
      • kubernetes::events_list (ok)
        # No events found
  Timeline:
    - unparsed event: I've identified the issue with your VirtualMachine! Here's what I found:
    - unparsed event: ## Diagnosis Summary
    - unparsed event: **The VM is intentionally stopped** - not broken! The issue is with the `runStrategy` configuration.
    - unparsed event: ### Key Findings:
    - unparsed event: 1. **VM Status**: `printableStatus: Stopped`
    - unparsed event: 2. **Root Cause**: `spec.runStrategy: Halted`
    - unparsed event: 3. **Condition**: Ready = False with message "VMI does not exist"
    - unparsed event: 4. **No VMI**: The VirtualMachineInstance doesn't exist (expected when halted)
    - unparsed event: 5. **No virt-launcher pod**: No pod is running (expected when halted)
    - unparsed event: 6. **No events**: No error events in the namespace
    - unparsed event: ### What's Happening:
    - unparsed event: The VirtualMachine is configured with `runStrategy: Halted`, which means it's intentionally stopped…
    - unparsed event: ### Solution:
    - unparsed event: To start the VM, you need to change the `runStrategy` from `Halted` to `Always`. Would you like me…
    - unparsed event: 1. **Update the VM to start it** by changing `runStrategy` to `Always`?
    - unparsed event: 2. **Leave it as-is** if it's supposed to be stopped?
    - unparsed event: If you want me to start it, I can update the VirtualMachine resource for you.
$ npx ccusage -j | jq '.daily.[] | select(.date == "2025-11-05") | .'
{
  "date": "2025-11-05",
  "inputTokens": 162,
  "outputTokens": 2260,
  "cacheCreationTokens": 52362,
  "cacheReadTokens": 538484,
  "totalTokens": 593268,
  "totalCost": 0.37113954999999993,
  "modelsUsed": [
    "claude-sonnet-4-5-20250929",
    "claude-3-5-haiku-20241022"
  ],
  "modelBreakdowns": [
    {
      "modelName": "claude-sonnet-4-5-20250929",
      "inputTokens": 144,
      "outputTokens": 1280,
      "cacheCreationTokens": 49679,
      "cacheReadTokens": 525069,
      "cost": 0.36344895
    },
    {
      "modelName": "claude-3-5-haiku-20241022",
      "inputTokens": 18,
      "outputTokens": 980,
      "cacheCreationTokens": 2683,
      "cacheReadTokens": 13415,
      "cost": 0.0076906000000000006
    }
  ]
}

Cali0707 · 2025-11-05T14:43:24Z

it would be nice if gevals included /cost and /context data allowing us to assert against it potentially.

@lyarwood +1 from my side on that being nice, the reason we haven't been able to add it there is that we use claude code in the non-interactive setup in gevals, and we haven't been able to figure out how to get that information in the non interactive setup. If you have any ideas, let me know and/or open a PR!

codingben · 2025-11-05T14:54:40Z

pkg/toolsets/kubevirt/vm/create/tool.go

+	}
+}
+
+type vmParams struct {


nit: I'd vote to name it as VirtualMachineParams.

I was actually thinking of going the other way and reducing this to params as the package already highlights that this is for VMs.

codingben · 2025-11-05T15:06:45Z

pkg/toolsets/kubevirt/vm/create/tool.go

+}
+
+// createParameters holds parsed input parameters for VM creation
+type createParameters struct {


CreateVirtualMachineParams? Keep it consistent with Params or Parameters.

codingben · 2025-11-05T15:08:15Z

pkg/toolsets/kubevirt/vm/create/tool.go

+}
+
+// parseCreateParameters parses and validates input parameters
+func parseCreateParameters(params api.ToolHandlerParams) (*createParameters, error) {


I'd suggest naming it as parseCreateVirtualMachineParams. Even if it's a private function and not exposed.

As above, I think parseCreateParameters is enough given the package name context.

codingben · 2025-11-05T15:09:30Z

pkg/toolsets/kubevirt/vm/create/tool.go

+
+	workload := getOptionalString(params, "workload")
+	if workload == "" {
+		workload = "fedora" // Default to fedora if not specified


Why not returning an error as well? This is parameters validation, not a VM specification that can contain defaults.

It's optional, if anything getOptionalString should be extended to provide a default.

lyarwood force-pushed the kubevirt branch from ae988e2 to 98996ea Compare October 22, 2025 18:06

lyarwood force-pushed the kubevirt branch 2 times, most recently from 9aa2732 to 4eac816 Compare November 3, 2025 20:27