feat(kubevirt): add vm_create_from_template tool

[codingben]

Add MCP tool to create VirtualMachines from
VirtualMachineTemplates via the virt-template
process subresource API, with eval tasks
and tests.

[github-actions]

👋 Heads up — this pull request changes files owned by @ksimon1 @lyarwood.

You are listed as an owner of one or more of the changed areas in .github/CODEOWNERS. GitHub cannot auto-request review from owners without write access, so this comment is the notification instead. A review when you have a moment would be appreciated 🙏

[codingben]

/cc @lyarwood @ksimon1

[0xFelix]

You could perhaps use the types from virt-template-api package instead of unstructured

[ksimon1]

We currently do not have any kubevirt package imported in this project. Might be worth checking if virt-template package is easy to import in this PR

[codingben]

@lyarwood can drop your opinion about this?

[lyarwood]

Something for a follow up but I'd assume we want to stay unstructured for now.

[ksimon1]

Is this number correct? Since you added just a single tool

[codingben]

It's auto-generated by make update-readme-tools and represents the amount of KubeVirt eval scenarios and not the tools.

[ksimon1]

You should probably add similar test as is here: https://github.com/containers/kubernetes-mcp-server/blob/main/pkg/mcp/toolsets_test.go#L129

[lyarwood]

Thanks for this @codingben, a few pieces of feedback:

Rebase on #1308 and route through AccessControlRoundTripper

CreateVMFromTemplate in pkg/kubevirt/template.go creates its own REST client via rest.CopyConfig(restConfig), which means the request to subresources.template.kubevirt.io completely bypasses the AccessControlRoundTripper. This is the same pattern as the existing guest agent code in guestagent.go, but I think we should take the opportunity to fix this going forward.

#1308 adds AllowedAPIGroups support to the toolset API — toolsets can declare virtual API groups (like subresources.kubevirt.io) that should be allowed through the AccessControlRoundTripper even though they're not in standard API discovery. This PR would be a great second use case for that mechanism.

I'd suggest:

1. Rebase this PR on #1308
2. Add "subresources.template.kubevirt.io" to the kubevirt toolset's GetAllowedAPIGroups() return value
3. Rework CreateVMFromTemplate to go through the standard Kubernetes client (which has the AccessControlRoundTripper installed) rather than building its own rest.RESTClientFor

That way the request goes through the same access control path as everything else — denied_resources, confirmation rules, and any future validators would all apply. The AllowedAPIGroups mechanism lets it past the REST mapper check, and the API server still enforces RBAC on the user's credentials.

Evals in a separate commit

I'd like to see the eval tasks (the 5 task YAMLs + verify-vm.sh helpers) in their own commit, separate from the tool implementation. This way the evals demonstrate and justify the need for the new vm_create_from_template tool before the implementation commit adds it. It also makes it easier to review the evals and tool independently.

Note that only 2 of the 5 evals (create-vm-from-template, template-required-params) actually exercise the new tool — the other 3 (list-vm-templates, inspect-vm-template, create-template-from-vm) test the agent's ability to work with template CRDs via existing generic tools, which is fine for broader coverage but worth calling out.

[codingben]

@lyarwood I'd like to avoid rebasing this PR on yours, can we get the PR you opened merged faster instead? It seems not much changes, no reason to keep it open for longer.

[codingben]

@lyarwood Your PR is closed now. How we should proceed here?

[codingben]

This PR is now blocked by: #1361

[codingben]

PR rebased. @lyarwood PTAL