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

VM disk.file_format is being overwritten by the actual file format found on storage #1035

Closed
RobinVanCauter opened this issue Feb 18, 2024 · 2 comments
Labels
🐛 bug Something isn't working

Comments

@RobinVanCauter
Copy link

Describe the bug
I'm trying to provision a VM with HomeAssistantOS in Proxmox using this plugin.
HAOS only provides a qcow2 file for their releases which is compatible with Proxmox.
After that, provisioning a VM with a disk that uses this image, you want to specify the file_format of the disk to "raw" (as it wouldn't work on local-lvm otherwise), even tho it is a qcow2 file under the hood. This works when done manually on the proxmox node.

When using this plugin however, I get the following error:

Error: error waiting for VM creation: task "UPID:deimos-1:00030AC5:00851987:65D26368:qmcreate:100:root@pam:" failed to complete with exit code: unable to create VM 100 - unsupported format 'qcow2' at /usr/share/perl5/PVE/Storage/LvmThinPlugin.pm line 87.

I had a very quick look inside the code for this plugin and I think it might have todo with this block of code:
https://github.com/bpg/terraform-provider-proxmox/blob/main/proxmoxtf/resource/vm.go#L4218

I think, regardless of what I provide as a file_format, it will overwrite the format with whatever proxmox detected on the filesystem.

To Reproduce

resource "proxmox_virtual_environment_vm" "hassio_vm" {
  name      = "hassio"
  node_name = "deimos-1"

  bios = "ovmf"
  machine = "q35"

  efi_disk {
    type = "4m"
  }

  cpu {
    cores   = 2
    sockets = 1
    type    = "host"
  }

  memory {
    dedicated = 4096
  }


  disk {
    datastore_id = "local-lvm"
    discard      = "on"
    file_format  = "raw"
    file_id      = proxmox_virtual_environment_file.haos_image.id
    interface    = "virtio0"
    iothread     = true
    size         = 32

  }

  operating_system {
    type    = "l26"
  }
}

resource "proxmox_virtual_environment_file" "haos_image" {
  content_type = "iso"
  datastore_id = "local"
  node_name    = "deimos-1"

  source_file {
    # HAOS does not provide a proxmox compatible img file, only qcow2, so we have to rename the extension
    path = "files/haos_ova-11.5.img"
  }
}

Expected behavior
When I provide a file_format I don't want it to be overridden by the info gathered from the image file in storage.

Additional context
Add any other context about the problem here.

  • Single or clustered Proxmox: clustered
  • Provider version (ideally it should be the latest version): latest version
  • Terraform version: latest version
  • OS (where you run Terraform from): MacOS
  • Debug logs (TF_LOG=DEBUG terraform apply):
@RobinVanCauter RobinVanCauter added the 🐛 bug Something isn't working label Feb 18, 2024
@bpg
Copy link
Owner

bpg commented Feb 19, 2024

Hi @T-Grave! 👋🏼

This use case seems to be very similar to one from examples
That template works fine and imports the qcow2 image as a raw disk at the end.

So I started playing with my test VM trying to reproduce your use case, and eventually realized that efi_disk block is what causing the issue.

Could you try

  efi_disk {
    type = "4m"
    file_format = "raw"
  }

and see if that works for you?

@bpg bpg added the ⌛ pending author's response Requested additional information from the reporter label Feb 19, 2024
@RobinVanCauter
Copy link
Author

Hi @bpg

That seems to work indeed!

@bpg bpg removed the ⌛ pending author's response Requested additional information from the reporter label Feb 20, 2024
@bpg bpg closed this as completed Feb 22, 2024
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