Skip to content

docs, host-devices: Fix lspci example and T4 resource name - #1045

Open
fjvbn2003 wants to merge 1 commit into
kubevirt:mainfrom
fjvbn2003:host-devices-gpu-names
Open

fjvbn2003 wants to merge 1 commit into
kubevirt:mainfrom
fjvbn2003:host-devices-gpu-names

Conversation

@fjvbn2003

@fjvbn2003 fjvbn2003 commented Oct 25, 2026 •

Copy link
Copy Markdown
Contributor

Two small corrections in docs/compute/host-devices.md.

lspci example. The command is lspci -DD, but the sample output shows the class code [0302] and the
[10de:1eb8] vendor:device pair, which only -nn prints. The sample also has 0000.65:00.0 where the domain
separator is :. On one of my nodes (pciutils 3.14.0):

$ lspci -DD | grep -i nvidia
0000:01:00.0 VGA compatible controller: NVIDIA Corporation GA106M [GeForce RTX 3060 Mobile / Max-Q] (rev a1)
$ lspci -Dnn | grep -i nvidia
0000:01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA106M [GeForce RTX 3060 Mobile / Max-Q] [10de:2560] (rev a1)

T4 resource name. The T4 entry in the permittedHostDevices example sets externalResourceProvider: true, so
the GPU is advertised by an external device plugin and resourceName / deviceName must be the name that plugin
uses. The NVIDIA KubeVirt GPU device plugin upper-cases the name it builds from pci.ids
(strings.ToUpper in pkg/device_plugin/device_plugin.go), so the T4 is advertised as nvidia.com/TU104GL_TESLA_T4.
Extended resource names are case sensitive, so a VMI copied from the example asks for nvidia.com/TU104GL_Tesla_T4,
which no node advertises. The same mismatch is in the plugin's own examples (NVIDIA/kubevirt-gpu-device-plugin#89,
fix proposed in NVIDIA/kubevirt-gpu-device-plugin#222).

KubeVirt's own device plugin (without externalResourceProvider) registers resourceName exactly as written, so
the other examples are fine. On my cluster resourceName: "nvidia.com/GA106M_GeForce_RTX_3060_Mobile" without
externalResourceProvider shows up in the node's allocatable with that exact casing.

Changes:

  • lspci -DD|grep NVIDIA → lspci -Dnn | grep NVIDIA, and 0000.65:00.0 → 0000:65:00.0 in the sample output.
  • nvidia.com/TU104GL_Tesla_T4 → nvidia.com/TU104GL_TESLA_T4 in the KubeVirt CR and the VMI examples.
  • Under "External providers": the name must match what the external plugin advertises, an example for the NVIDIA
    plugin, and how to list the names on a node.

I used Claude (Anthropic) to help with the research and wording, including the checks on my nodes above. The commit carries
an Assisted-by trailer.

The lspci example uses -DD, which prints neither the class code nor
the [vendor:device] pair shown in the sample output; -nn does. The
sample output also had a '.' where the PCI domain separator is ':'.

The T4 entry sets externalResourceProvider: true, so its resourceName
has to match the name the external device plugin advertises. The
NVIDIA KubeVirt GPU device plugin upper-cases the name it derives from
pci.ids (TU104GL_TESLA_T4), and resource names are case sensitive, so
the mixed-case name in the example never matches. Use the upper-case
name and say how to look up the advertised names on a node.

Assisted-by: Claude <[email protected]>
Signed-off-by: YoungjuKim <[email protected]>
@kubevirt-prow kubevirt-prow Bot added the dco-signoff: yes Indicates the PR's author has DCO signed all their commits. label Oct 25, 2026
@kubevirt-prow
kubevirt-prow Bot requested review from fabiand and mhenriks October 25, 2026 02:23
@kubevirt-prow

kubevirt-prow Bot commented Oct 25, 2026

Copy link
Copy Markdown

[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 jean-edouard 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:

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

@kubevirt-prow kubevirt-prow Bot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Oct 25, 2026
@kubevirt-prow

kubevirt-prow Bot commented Oct 25, 2026

Copy link
Copy Markdown

Hi @fjvbn2003. Thanks for your PR.

I'm waiting for a kubevirt member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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.

@kubevirt-prow kubevirt-prow Bot added the size/S label Oct 25, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dco-signoff: yes Indicates the PR's author has DCO signed all their commits. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. size/S

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant