[itayherzberg]

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

Related: #42 reports the node a running VM is scheduled on (Oem.KubeVirt.NodeName), also on top of #25 and independent of this one.

Problem

A Redfish client that inventories machines tells one machine from another by SerialNumber and UUID, and shows Manufacturer and Model. A KubeVirt ComputerSystem has none of the four, so the only stable handle a client gets is the System Id. That handle changes when the VM is renamed or system_id_convention changes, and under legacy two chassis can serve VMs with the same Id.

Fix

GET /redfish/v1/Systems/{id}, and the response to a boot-device PATCH, now carry:

Property	Source, first non-empty wins
Manufacturer	always "KubeVirt" (not read from the cluster)
SerialNumber	running VMI spec.domain.firmware.serial, then the VM template's
UUID	running VMI spec.domain.firmware.uuid, then the VM template's, then the VM's metadata.uid
Model	running VMI spec.domain.machine.type (the QEMU machine type), then the VM template's

The read is GetVMIdentity in pkg/kubevirt/devices.go, built like GetVMCPUTopology: GetVM, then getRunningVMI and effectiveSpec.

If the VM or the VMI cannot be read, the three read properties are left out (omitempty) and the System still answers 200. A VMI read error does not fall back to the template, for the same reason as in #25: the staged spec may not be what is running.

The two ComputerSystem literals in server.go (GET and the boot PATCH response) are replaced by one buildComputerSystem, so the two cannot drift.

What a cluster reports

On OpenShift Virtualization 4.22.12 and 4.20.27, KubeVirt writes a random firmware.serial, a random firmware.uuid and the default machine type (pc-q35-rhel9.x) into the VM template within seconds of creation. That includes a Halted VM that declared none, so every VM has all four, and they survive restarts. A VM deleted and recreated from the same manifest gets a new serial and UUID. The metadata.uid fallback is for a template without firmware.uuid.

Tests

TestSystemIdentity in pkg/server/system_devices_test.go:

• declared values are reported;
• a running VMI wins over the template;
• a field the VMI leaves unset falls back to the template;
• with no firmware block, UUID is metadata.uid and there is no SerialNumber key;
• an unreadable VMI leaves the keys out and still answers 200;
• the boot PATCH response carries them too.

go vet ./... and go test ./... pass.

Base

Branch system-identity-fields (3cd0695) is one commit on #25's head 05be86f, which is rebased onto main (2e38e46, after #34). gofmt, go mod tidy, go vet and go test ./... pass. go test -race fails in connection_pool.go, memory_monitor.go and job_scheduler.go exactly as it does on main; TestSystemIdentity and TestSystemDevices are clean under -race.

[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.