SetVGPUConfig silently falls back to a suffix-stripped type name: the sanitize loop in pkg/vgpu/config.go tries stripVGPUConfigSuffix(key) when the requested name is not supported on the target GPU, and applies the stripped name if that one is supported.
The code comment explains what this was written for: on RTX Pro 6000 Blackwell the MIG-backed types only exist on MIG instances created with the GFX attribute, while the mdev type names never carry the GFX suffix, so stripping is the only correct resolution there.
The same path also strips ME, NOME and MEALL, and an ME variant is a distinct type with different capabilities (media engines). Both spellings exist as valid type names. So when a config asks for an ME variant on a GPU that only supports the plain one, it gets the plain type: no log line, no error, and the devices come up without the media engines the config asked for.
Numbers from examples/config-example.yaml on current main: 710 type names, 56 collide with their own stripped form. 30 of those are the GFX class, 26 are ME, e.g. A100-1-5CME -> A100-1-5C.
I think the substitution should at least be logged. Better: restrict the fallback to the GFX case it was introduced for and fail on an unsupported ME variant like on any other unsupported type, since the stripped result is a different device. Found this while working on the sanitize path for #195. I can send a patch once there is a direction call.
SetVGPUConfigsilently falls back to a suffix-stripped type name: the sanitize loop inpkg/vgpu/config.gotriesstripVGPUConfigSuffix(key)when the requested name is not supported on the target GPU, and applies the stripped name if that one is supported.The code comment explains what this was written for: on RTX Pro 6000 Blackwell the MIG-backed types only exist on MIG instances created with the GFX attribute, while the mdev type names never carry the GFX suffix, so stripping is the only correct resolution there.
The same path also strips
ME,NOMEandMEALL, and anMEvariant is a distinct type with different capabilities (media engines). Both spellings exist as valid type names. So when a config asks for anMEvariant on a GPU that only supports the plain one, it gets the plain type: no log line, no error, and the devices come up without the media engines the config asked for.Numbers from
examples/config-example.yamlon current main: 710 type names, 56 collide with their own stripped form. 30 of those are the GFX class, 26 areME, e.g.A100-1-5CME->A100-1-5C.I think the substitution should at least be logged. Better: restrict the fallback to the GFX case it was introduced for and fail on an unsupported
MEvariant like on any other unsupported type, since the stripped result is a different device. Found this while working on the sanitize path for #195. I can send a patch once there is a direction call.