[itayherzberg]

Depends on #25 (it builds on getRunningVMI, processorFields and Oem.KubeVirt.Processors). Until #25 merges, this diff also shows #25's 8 commits: only the last commit, a90e725, is this PR. I will rebase it as soon as #25 is in.

It is independent of #41 (the ComputerSystem identity fields): either can merge first, and the second gets a small server.go rebase.

Problem

An inventory that holds both the VMs behind this API and the nodes they run on cannot link the two: nothing in the ComputerSystem says where the VM runs. A client that wants the physical CPU, rack or health of the host behind a VM has to query the Kubernetes API with credentials of its own, which a Redfish client usually does not have.

KubeVirt's own answer to "which CPU does this VM get" does not help. domain.cpu.model is often a mode (host-model), not a model, and the node's host-model-cpu.node.kubevirt.io/<family> label gives only a family. Under software emulation that family is wrong: an Intel Xeon node was labelled EPYC.

Fix

GET /redfish/v1/Systems/{id}, and the response to a boot-device PATCH, carry Oem.KubeVirt.NodeName: the running VMI's status.nodeName.

• It is omitted when the VM is not running: no VMI, or a VMI in a final phase, the same rule getRunningVMI applies everywhere else.
• It is also omitted when the VMI cannot be read, logged as an error; the System still answers 200.
• Redfish has no standard property for the host of a virtual ComputerSystem (Links covers chassis, managers and composition), so it sits next to the existing Oem.KubeVirt.Processors.

Oem.KubeVirt.Processors becomes a pointer (OemProcessors), so an Oem that carries only the node name does not report a 0x0x0 vCPU layout. Its JSON is unchanged whenever the topology is read.

Example, running VM:

"Oem": {
  "KubeVirt": {
    "Processors": { "Sockets": 1, "CoresPerSocket": 2, "ThreadsPerCore": 1 },
    "NodeName": "worker-3"
  }
}

Things to know

• Who can see it: every Redfish user who can see the VM's chassis. It is a Kubernetes node name, not an address or a credential.
• It changes: a live migration changes it, and a client polling it sees the node at the time of the request.
• Cost: none extra; it reuses the VMI read processorFields and the other sub-resources already make.

Tests

TestSystemNodeName in pkg/server/system_devices_test.go:

• a running VMI reports its node next to the vCPU layout;
• a stopped VM has no NodeName but keeps the layout;
• a Succeeded VMI reports none;
• an unreadable VMI leaves it out and still answers 200.

Branch system-node-name (a90e725) is one commit on #25's head 05be86f. go vet ./... and go test ./... pass. go test -race fails only in connection_pool.go, memory_monitor.go and job_scheduler.go, exactly as on main; TestSystemNodeName is clean under -race.

Verification on a cluster

OpenShift Virtualization 4.20.27, three cirros VMs (two running, one Halted), the controller built from a branch that carries this change on top of #25 and #29-#39. NodeName equalled oc get vmi -o jsonpath='{.status.nodeName}' for both running VMs (ip-10-0-28-121.us-east-2.compute.internal) and was absent for the halted one.

[kubevirt-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign marsik for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kubevirt-prow]

Hi @itayherzberg. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.