Are SMBIOS settings exposed in VM resource of datasource?

[KittyKatt]

Hi there! I have some automation/IaC I'm cooking up and I've found I have a need to get the SMBIOS UUID of a created/imported VM. I'm creating a handful of Talos Linux nodes and they use the SMBIOS UUID as their own unique identifier. With Omni on top managing these Talos nodes, you can create and manage clusters via cluster templates. Machine resources that represent individual Kubernetes nodes are represented as this SMBIOS UUID. Scaling up or down these clusters would require knowing the UUIDs of the nodes/VMs I'm trying to remove/add to the cluster.

I'm actually trying my hand at creating a Terraform provider to interact with Omni and my current homelab uses this Proxmox provider to manage my Proxmox VMs (including the Talos nodes). I'm trying to write Terraform (and thus features into the Omni provider) that can take input of a UUID string from either a use or something else in Terraform. Since I'm already creating these VMs with Terraform and their information is stored in state, I'd like to be able to pull the SMBIOS UUID from a created VM, an imported VM, or a VM grabbed via a data source.

I see a bunch of references to SMBIOS settings (and even the UUID) across the VM-related resource/datasource files, but I can admit that I'm not a Golang pro and have having a hard time figuring out if this information is actually exported back to Terraform via the provider. Am I missing something? Is it just not exported (despite being known from a vmRead)? If not, I can open a new issue/feature request for this as it would MASSIVELY help to know this information.

Thanks!

[bpg]

Hi @KittyKatt 👋🏼

If I understand you correctly, you've created a VM using the providers, with SMBIOS settings as per https://registry.terraform.io/providers/bpg/proxmox/latest/docs/resources/virtual_environment_vm#smbios-1 (omitting UUID), and want to read back the generated UUID from the VM?

Could you share a stripped down version of your config to help me understand better what are you trying to achieve?

[bpg]

You're not doing anything wrong, there are just lots of edge cases around import and cloning in the provider that are hard to handle due to limitations of the legacy Terraform SDK (especially when dealing with defaults). I don't really want to go down the rabbit hole of fixing them, but would rather focus on #1231 to address the root cause of the bad behaviour.

Going back to your original question, I think adding smbios read to the VM datasource would probably be an easier fix.

[KittyKatt]

I see, that makes sense. I've been working with the Terraform Plugin Framework, but don't know the caveats of the legacy SDK.

I don't know if supporting it in the datasource would help my specific use case (I need to lookup with the datasource a resource that is not yet made at plan time), but I imagine it can only be useful to add it.

If possible, could you point me to the portion of the code that dictates "if you put a blank smbios block, you'll get smbios exportable attributes"? Maybe I can find out what's going on there if I know what's happening behind the scenes.

[KittyKatt]

Additional question for you: How much does Proxmox version matter? What version are you running your test against? I'm currently on 8.4.1.

[KittyKatt]

@bpg Not to bother, but just checking in if the Proxmox version actually matters. What version was your above test against? What version of the provider were you using, if you don't mind my asking? Anything else special you can think of that I should try changing about either my Proxmox hosts or the way I'm using the provider?

[bpg]

@KittyKatt I don't think the Proxmox version matters here. That part should work the same for 8.x and 9.x, though my last test was on 9.x.

... lots of edge cases around import and cloning

Leaving aside the clone/refresh case, since I don't expect it to work without fixes, the "create new VM from scratch" scenario should work. smbios.uuid is a computed attribute, so its value will be filled in by the provider when it reads the VM config back after creation.

But only if you're not cloning. The clone use case is complicated, because the provider has to "merge" attributes from multiple sources when deciding on the final value in the state. That logic is not straightforward and is prone to errors 😞. I see your "New Resources" scenario has dynamic "clone" {...}, so that's probably the reason.