Create a Fedora CoreOS VM from an xz compressed cloud image

[webD97]

I'm currently using this provider (great work btw!) to set up a homelab k3s cluster. My nodes are running Fedora CoreOS and I'd like to bootstrap the VMs from the official qcow2 image.

I followed the Create a VM from a Cloud Image but unfortunately Proxmox does not seem to like the fact that CoreOS images are only available with xz compression (https://fedoraproject.org/coreos/download?stream=stable&arch=x86_64#baremetal), so this fails:

resource "proxmox_virtual_environment_download_file" "coreos_qcow2" {
  content_type = "iso"
  datastore_id = "local"
  node_name    = "pve"
  url          = "https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/39.20240322.3.1/x86_64/fedora-coreos-39.20240322.3.1-qemu.x86_64.qcow2.xz"
}

Could not download file 'fedora-coreos-39.20240322.3.1-qemu.x86_64.qcow2.xz', unexpected error: error download file by URL: received an HTTP 400 response - Reason: Parameter verification failed. (filename: wrong file extension)

I'm pretty sure this is a Proxmox limitation but maybe I am just missing something and someone has a better approach. My best idea so far is to create some local-exec magic that invokes coreos-downloader to create the uncompressed qcow2 locally, which is then used in a proxmox_virtual_environment_file, but that appears to be more a hack than a workaround.

Any ideas?

[bpg]

Hi @webD97 👋🏼

I don't think Proxmox can use xz-compressed qcow2 disk images for VMs. Your idea about the local-exec approach is probably the best we can do to automate this atm.

[webD97]

I really hoped that I missed some feature - but it is as it is (at least for now). Thank you for you input!

[aaronkyriesenbach]

Howdy! Sorry to revive a dead thread but I wanted to chime in with my experience getting this working, namely that Proxmox's ZST decompression is capable of decompressing XZ archives. I have not found documentation on this anywhere, but have gotten this working successfully for the exact use case described here. Here is a complete, minimal working example (with bonus logic to pull the latest CoreOS image):

locals {
  metadata = jsondecode(data.http.coreos_stable_metadata.response_body)

  coreos_qemu_stable = local.metadata.architectures.x86_64.artifacts.qemu.formats["qcow2.xz"].disk
  download_url       = local.coreos_qemu_stable.location
  download_sum    = local.coreos_qemu_stable.sha256
}

data "http" "coreos_stable_metadata" {
  url = "https://builds.coreos.fedoraproject.org/streams/stable.json"
}

resource "proxmox_virtual_environment_download_file" "coreos_img" {
  content_type  = "iso"
  datastore_id   = "local"
  node_name    = "pve"

  url             = local.download_url
  checksum = local.download_sum

  checksum_algorithm      = "sha256"
  decompression_algorithm = "zst"

  file_name = "coreos-qemu.qcow2.xz.img"
}

# This is my personal VM module I use in my lab. It does not apply any specific customizations, so I am omitting the full contents of the module.
module "coreos-testing" {
  source = "./modules/vm"

  id       = xxx
  name = "coreos-tf"

  disk = {
    size    = 16 # The qcow2 image is 10Gb when pulled as of writing, but is successfully sized up during provisioning
    file_id = proxmox_virtual_environment_download_file.coreos_img.id
  }

  # I found that having less memory would cause boot failures without explicit mention as to why.
  # It took a while to figure out that this was because of the lack of memory and not because the disk extraction was going wrong.
  memory = 2

  agent_enabled = false

  cloud_init = {
    enabled = false
  }
}

[agross]

Sure, I think this is the relevant part:

resource "proxmox_virtual_environment_download_file" "fcos_image" {
  # `import`, which is needed for `import_from`, would not support decompression.
  content_type = "iso"
  node_name    = var.pve_node_name
  datastore_id = var.pve_datastore_id

  url          = "https://builds.coreos.fedoraproject.org/prod/streams/${var.fcos_stream}/builds/${var.fcos_version}/x86_64/fedora-coreos-${var.fcos_version}-proxmoxve.x86_64.qcow2.xz"
  file_name    = "fedora-coreos-${var.fcos_version}-proxmoxve.x86_64.qcow2.xz.img"

  # https://github.com/bpg/terraform-provider-proxmox/discussions/1319#discussioncomment-14377866
  decompression_algorithm = "zst"
}

resource "proxmox_virtual_environment_vm" "vm" {
  node_name   = var.pve_node_name
  name        = var.hostname

  disk {
    datastore_id = var.vm_pve_datastore_id
    # Does not work with `import_from` because the file does not reside in the import dir.
    file_id      = resource.proxmox_virtual_environment_download_file.fcos_image.id
    size         = 10
    interface    = "scsi0"
  }

[bpg]

Yes, you're right in the comment, that's a Proxmox's limitation.
import_from requires an image to be uploaded with import content type -- PVE does image conversion in the background.
And the import content type supports only raw / qcow2 images, not archives 🤷🏼

[agross]

Thank you for confirming! What do you think, does it make sense to un-deprecate file_id then?

[bpg]

Well, it is not "officially" deprecated in the resource schema, just in the doc. We need better wording there. If you don't mind opening a quick PR to update it? 🙏🏼

[agross]

In order to improve wording I need to know the reason why you decided to "semi-deprecate" it in the first place. As a mere user of the module (i.e. no idea about the Proxmox APIs used) it does not really make sense to have >1 way to define the VM's base image.