Allow fetching a vm configuration for fast feedback

[henningphan]

I dont know the correct terminology but I do hope my intention comes across.

Is your feature request related to a problem? Please describe.
The first vm you create with infrastructure as code, IAC, is frustrating because you might not know what values are available.

Describe the solution you'd like
Given that you have one or more manually created vms, it would be lovely if one could fetch one and output its arguments to copy to the code as an argument. This will allow one to create a vm manually, and then easily translate the manual vm to IAC.

I been told that this would be a place to add the the output
https://github.com/bpg/terraform-provider-proxmox/blob/main/proxmoxtf/datasource/vm.go#L29

# pseudo code
existing_vm = get_vm(vm_id=100)
print(existing_vm) # vm_config(bios="seabios", memory=1024,...)
# Now you know that a valid value for bios is "seabios" which you can use when creating your next vm.
create_vm(bios="seabios")

[ratiborusx]

If you're talking about data source "data.proxmox_virtual_environment_vm" then i agree its a bit lacking as of now - i too was expecting to see full VM config returned. The same thing with "data.proxmox_virtual_environment_vms" which returns info about all vms based on tags specified, but in this case not returning full config may be ok because output could be giant.
For now if i need to see configured arguments and their values of a vm i just ask state about that:

terraform state show proxmox_virtual_environment_vm.example

But obviously you will need said resource to be created by provider already or import it beforehand, so not sure if it'll work for you at all.

[bpg]

Hi @henningphan 👋🏼

The VM datasource support is very rudimentary, you won't get much except vm_id, and adding all missing attributes is quite a lot of work, taking in account how much configuration and state we have in a VM.

Would import work for your use case as suggested by @ratiborusx? You can define a placeholder resource, then import exiting VM into TF state under this resource, then you can reference its attributes everywhere else in the TF plan. Kind of manual process, but is better than re-defining everything from scratch.

You even can reconstruct the resource using experimental generating configuration feature.
See example in #656. After running terraform plan -generate-config-out="./generated.tf" I've got this generated.tf:

# __generated__ by Terraform
# Please review these resources and move them into your main configuration files.

# __generated__ by Terraform from "pve/1000"
resource "proxmox_virtual_environment_vm" "test" {
  acpi                = true
  bios                = "seabios"
  boot_order          = null
  description         = null
  keyboard_layout     = "en-us"
  kvm_arguments       = null
  machine             = null
  migrate             = null
  name                = "test"
  node_name           = "pve"
  on_boot             = null
  pool_id             = null
  reboot              = null
  scsi_hardware       = "virtio-scsi-pci"
  started             = true
  tablet_device       = true
  tags                = []
  template            = false
  timeout_clone       = null
  timeout_create      = null
  timeout_migrate     = null
  timeout_move_disk   = null
  timeout_reboot      = null
  timeout_shutdown_vm = null
  timeout_start_vm    = null
  timeout_stop_vm     = null
  vm_id               = null
  agent {
    enabled = true
    timeout = "15m"
    trim    = false
    type    = "virtio"
  }
  cpu {
    architecture = null
    cores        = 2
    flags        = []
    hotplugged   = 0
    numa         = false
    sockets      = 1
    type         = "qemu64"
    units        = 1024
  }
  initialization {
    datastore_id         = "local-lvm"
    interface            = "ide2"
    meta_data_file_id    = null
    network_data_file_id = null
    type                 = null
    user_data_file_id    = "local:snippets/cloud-config.yaml"
    vendor_data_file_id  = null
    ip_config {
      ipv4 {
        address = "dhcp"
        gateway = null
      }
    }
  }
  memory {
    dedicated = 2048
    floating  = 0
    shared    = 0
  }
  network_device {
    bridge      = "vmbr0"
    enabled     = true
    firewall    = false
    mac_address = "2A:8B:E4:B4:1B:13"
    model       = "virtio"
    mtu         = 0
    queues      = 0
    rate_limit  = 0
    vlan_id     = 0
  }
  operating_system {
    type = "l26"
  }
}

[henningphan]

@bpg It does seem to do what Im requesting, but to be honest my real motive was to be able to achieve this in pulumi. I dont know terraform, and I cant say I know pulumi either. My goal (which isnt mentioned) was to have a pulumi centric solution and I dont know what is needed, and maybe that isnt even of interest of this terraform project.

[henningphan]

@muhlba91 Hope im not rude adding you here. @ratiborusx mentioned importing, and quick google shows that pulumi also have such capabilities but the https://github.com/muhlba91/pulumi-proxmoxve I think doesnt provide it, would it be possible to have it there? Is pulumi capable of taking advantage of the terraform import?

[muhlba91]

since the pulumi provider is based on this one, importing works once it was implemented here.

the corresponding issue and comment in the pulumi provider is this one: muhlba91/pulumi-proxmoxve#26 (comment)
you can find an example configuration used for importing a VM. you can import it by running pulumi import -f import.json where import.json contains the configuration posted in the referenced issue.

take care that after importing, the VM is in your pulumi state, and you probably want to define the VM in your pulumi code.
so in contrast to the datasource it will be kept in sync with your specification in your pulumi code.
you could try using ignoreChanges: ["*"] to ignore any chances to be synchronized but i never tried using such a wildcard there as the general concept would be to use a datasource in such cases.

[henningphan]

I will test what you guys proposed when I get time.

Just to repeat with my own words to show my understanding @muhlba91 , I would have to use terraform to export a vm, then use pulumi to import it, then I would have to translate it to pulumi code too?

That sounds fairly reasonable solution to me. In my perfect world I want to do all that from pulumi to not have to involve another tool, but im not that entitled.

[muhlba91]

you just have to import the already existing VM in pulumi by calling pulumi import …. but before you run e.g. pulumi up you need to make sure you have that VM in code defined as otherwise it will most likely try to delete your VM.

[bpg]

@henningphan I hope the proposed workaround works for you.
I'll keep this ticket open to track the (future) VM datasource work.

[henningphan]

I feel empowered and am satisfied with the solution, thank you both for providing something wonderful

[bpg-autobot]

Marking this issue as stale due to inactivity in the past 180 days. This helps us focus on the active issues. If this issue is reproducible with the latest version of the provider, please comment. If this issue receives no comments in the next 30 days it will automatically be closed. If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[bpg]

See also #1231

[bpg-autobot]

Marking this issue as stale due to inactivity in the past 180 days. This helps us focus on the active issues. If this issue is reproducible with the latest version of the provider, please comment. If this issue receives no comments in the next 30 days it will automatically be closed. If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!