Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Terraform VM Creation crashes plugin when adding ipv4 configuration to VM #1400

Open
micsport13 opened this issue Jun 17, 2024 · 3 comments
Open
Labels
🐛 bug Something isn't working

Comments

@micsport13
Copy link

Describe the bug
When adding an ipv4 configuration to a vm resource, it causes the plugin to crash

To Reproduce
Steps to reproduce the behavior:

  1. Create a VM resource
  2. Update the VM resource to have an IPv4 configuration block with a predefined address instead of dhcp
  3. Terraform Apply
  4. See Error

Please also provide a minimal Terraform configuration that reproduces the issue.

resource "proxmox_virtual_environment_vm" "TestArch" {
  acpi            = true
  bios            = "seabios"
  description     = null
  keyboard_layout = null
  kvm_arguments   = null
  mac_addresses   = ["3A:88:CC:4D:B3:A3"]
  machine         = null
  name            = "TestArch"
  node_name       = "server"
  protection      = false
  scsi_hardware   = "virtio-scsi-single"
  started         = false
  tablet_device   = true
  tags            = []
  template        = false
  vm_id           = 102

  initialization {
    ip_config {
      ipv4 {
        address = "10.0.0.102"
        gateway = "10.0.0.1"
      }
    }
  }
  cpu {
    affinity     = null
    architecture = "x86_64"
    cores        = 4
    flags        = []
    hotplugged   = 0
    limit        = 0
    numa         = false
    sockets      = 1
    type         = "qemu64"
    units        = 1024
  }

  cdrom {
    enabled   = true
    file_id   = "lvm:iso/archlinux-2023.03.01-x86_64.iso"
    interface = "ide2"
  }

  disk {
    aio               = "io_uring"
    backup            = true
    cache             = "none"
    datastore_id      = "Data_Pool"
    discard           = "ignore"
    file_format       = "raw"
    file_id           = null
    interface         = "scsi0"
    iothread          = true
    path_in_datastore = "vm-102-disk-0"
    replicate         = true
    serial            = null
    size              = 32
    ssd               = false
  }

  memory {
    dedicated      = 4096
    floating       = 0
    hugepages      = null
    keep_hugepages = false
    shared         = 0
  }

  network_device {
    bridge       = "vmbr0"
    disconnected = false
    enabled      = true
    firewall     = true
    mac_address  = "3A:88:CC:4D:B3:A3"
    model        = "virtio"
    mtu          = 0
    queues       = 0
    rate_limit   = 0
    trunks       = null
    vlan_id      = 0
  }

  operating_system {
    type = "l26"
  }

}

Expected behavior
Should apply the IP address settings

Additional context
Error Message:

╷
│ Error: Plugin did not respond
│
│ The plugin encountered an error, and failed to respond to the
│ plugin6.(*GRPCProvider).ApplyResourceChange call. The plugin logs may contain more details.
╵

Stack trace from the terraform-provider-proxmox_v0.60.0 plugin:

panic: runtime error: index out of range [0] with length 0

goroutine 35 [running]:
github.com/bpg/terraform-provider-proxmox/proxmoxtf/resource/vm.vmUpdate({0x114aee0, 0xc000355420}, 0xc0005ac000, {0xeedba0, 0xc0000d2d50})
        github.com/bpg/terraform-provider-proxmox/proxmoxtf/resource/vm/vm.go:5108 +0x5765
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).update(0xc000340000, {0x114ae38, 0xc000597320}, 0xc0005ac000, {0xeedba0, 0xc0000d2d50})
        github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource.go:840 +0x119
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).Apply(0xc000340000, {0x114ae38, 0xc000597320}, 0xc0004644e0, 0xc0005acd00, {0xeedba0, 0xc0000d2d50})
        github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/resource.go:947 +0x83a
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ApplyResourceChange(0xc00012fc20, {0x114ae38?, 0xc0005971a0?}, 0xc0000b0960)
        github.com/hashicorp/terraform-plugin-sdk/[email protected]/helper/schema/grpc_provider.go:1153 +0xd5c
github.com/hashicorp/terraform-plugin-mux/tf5to6server.v5tov6Server.ApplyResourceChange({{0x1156bf8?, 0xc00012fc20?}}, {0x114ae38, 0xc0005971a0}, 0x0?)
        github.com/hashicorp/[email protected]/tf5to6server/tf5to6server.go:38 +0x54
github.com/hashicorp/terraform-plugin-mux/tf6muxserver.(*muxServer).ApplyResourceChange(0xc000336d20, {0x114ae38?, 0xc000596ed0?}, 0xc0000b0910)
        github.com/hashicorp/[email protected]/tf6muxserver/mux_server_ApplyResourceChange.go:36 +0x193
github.com/hashicorp/terraform-plugin-go/tfprotov6/tf6server.(*server).ApplyResourceChange(0xc000328820, {0x114ae38?, 0xc000596330?}, 0xc000354000)
        github.com/hashicorp/[email protected]/tfprotov6/tf6server/server.go:865 +0x3d0
github.com/hashicorp/terraform-plugin-go/tfprotov6/internal/tfplugin6._Provider_ApplyResourceChange_Handler({0xf78900, 0xc000328820}, {0x114ae38, 0xc000596330}, 0xc0005ac000, 0x0)
        github.com/hashicorp/[email protected]/tfprotov6/internal/tfplugin6/tfplugin6_grpc.pb.go:518 +0x1a6
google.golang.org/grpc.(*Server).processUnaryRPC(0xc000191200, {0x114ae38, 0xc0005962a0}, {0x1151e60, 0xc0002da180}, 0xc000352000, 0xc0003e91a0, 0x17dafd8, 0x0)
        google.golang.org/[email protected]/server.go:1369 +0xdf8
google.golang.org/grpc.(*Server).handleStream(0xc000191200, {0x1151e60, 0xc0002da180}, 0xc000352000)
        google.golang.org/[email protected]/server.go:1780 +0xe8b
google.golang.org/grpc.(*Server).serveStreams.func2.1()
        google.golang.org/[email protected]/server.go:1019 +0x8b
created by google.golang.org/grpc.(*Server).serveStreams.func2 in goroutine 27
        google.golang.org/[email protected]/server.go:1030 +0x125

Error: The terraform-provider-proxmox_v0.60.0 plugin crashed!

This is always indicative of a bug within the plugin. It would be immensely
helpful if you could report the crash with the plugin's maintainers so that it
can be fixed. The output above should help diagnose the issue.
  • Single or clustered Proxmox: Single
  • Proxmox version: v8.2.2
  • Provider version (ideally it should be the latest version): 0.60.0
  • Terraform/OpenTofu version: v1.8.5
  • OS (where you run Terraform/OpenTofu from): Arch Linux
  • Debug logs (TF_LOG=DEBUG terraform apply):
    Potential extra information:
2024-06-16T22:57:08.683-0600 [WARN]  Provider "registry.terraform.io/bpg/proxmox" produced an invalid plan for proxmox_virtual_environment_vm.TestArch, but we are tolerating it because it is using the legacy plugin SDK.
    The following problems may be the cause of any confusing errors from downstream operations:
      - .on_boot: planned value cty.True for a non-computed attribute
      - .timeout_create: planned value cty.NumberIntVal(1800) for a non-computed attribute
      - .timeout_migrate: planned value cty.NumberIntVal(1800) for a non-computed attribute
      - .description: planned value cty.StringVal("") for a non-computed attribute
      - .timeout_shutdown_vm: planned value cty.NumberIntVal(1800) for a non-computed attribute
      - .timeout_clone: planned value cty.NumberIntVal(1800) for a non-computed attribute
      - .timeout_start_vm: planned value cty.NumberIntVal(1800) for a non-computed attribute
      - .timeout_move_disk: planned value cty.NumberIntVal(1800) for a non-computed attribute
      - .machine: planned value cty.StringVal("") for a non-computed attribute
      - .migrate: planned value cty.False for a non-computed attribute
      - .reboot: planned value cty.False for a non-computed attribute
      - .stop_on_destroy: planned value cty.False for a non-computed attribute
      - .timeout_reboot: planned value cty.NumberIntVal(1800) for a non-computed attribute
      - .timeout_stop_vm: planned value cty.NumberIntVal(300) for a non-computed attribute
      - .keyboard_layout: planned value cty.StringVal("en-us") for a non-computed attribute
      - .kvm_arguments: planned value cty.StringVal("") for a non-computed attribute
      - .cpu[0].affinity: planned value cty.StringVal("") for a non-computed attribute
      - .initialization[0].datastore_id: planned value cty.StringVal("local-lvm") for a non-computed attribute
      - .network_device[0].trunks: planned value cty.StringVal("") for a non-computed attribute
      - .memory[0].hugepages: planned value cty.StringVal("") for a non-computed attribute
      - .disk[0].serial: planned value cty.StringVal("") for a non-computed attribute
      - .disk[0].file_id: planned value cty.StringVal("") for a non-computed attribute
      ```

I'm not sure if it matters but I did import this resource.
@micsport13 micsport13 added the 🐛 bug Something isn't working label Jun 17, 2024
@bpg
Copy link
Owner

bpg commented Jun 18, 2024

Hey @micsport13 👋🏼

Just to confirm, you initially imported the resource without the initialization section, then added the initialization with the IP address? That's a bit unexpected...

If your intention is to add an IP to an existing, previously provisioned VM, this approach won't work. The initialization block allows you to configure cloud-init for the VM, which runs only at the first boot with blank disks.

EDIT: just saw your comment to another ticket. Yeah, that won't let you configure IP without re-provisioning the VM. But provider should't panic like this, and should display a proper error message.

@bpg bpg added ⌛ pending author's response Requested additional information from the reporter and removed ⌛ pending author's response Requested additional information from the reporter labels Jun 18, 2024
@micsport13
Copy link
Author

How does one set the IP address of an existing VM then? That's probably why it's failing though so is there no way to set the IP address after creating the VM in code?

@bpg
Copy link
Owner

bpg commented Jun 18, 2024

This is not something that the provider could do for the VM, as IP configuration is essentially a responsibility of OS, which is already installed in the VM at this point.

Ideally the VM should be pre-configured with DHCP, and also have qemu-agent installed and enabled, then it will be much easier to import and then manage with terraform.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants