Skip to content

libvirt_volume examples fail to validate in v0.9.1 due to format parameter changes #1241

@hpst3r

Description

@hpst3r

The examples for libvirt_volume objects in the Terraform Registry docs (/latest/docs/resources/volume) fail to validate with v0.9.1 due to changes in the format parameter.

Fixed by adjusting examples to use target = { format = { type = "qcow2" } } instead of format = "qcow2", and adding a target = {} block to the overlay example's base disk (not the backing volume).

Here's the current HTTP URL upload example:

# Volume from HTTP URL upload
resource "libvirt_volume" "ubuntu_base" {
  name   = "ubuntu-22.04.qcow2"
  pool   = "default"
  format = "qcow2"

  create = {
    content = {
      url = "https://cloud-images.ubuntu.com/releases/22.04/release/ubuntu-22.04-server-cloudimg-amd64.img"
    }
  }
  # capacity is automatically computed from Content-Length header
}

On validate, it fails:

$ terraform validate
╷
│ Error: Unsupported argument
│ 
│   on main.tf line 20, in resource "libvirt_volume" "ubuntu_base":
│   20:   format = "qcow2"
│ 
│ An argument named "format" is not expected here.
╵

The format parameter for a libvirt_volume object has been replaced with:

target = { format = { type = "qcow2" } }

Updating the format = "qcow2" parameter to target = { format = { type = "qcow2 } } resolves this error.

This affects all the other examples on the page (basic volumes, overlay, local file, HTTP).

In addition, I needed to specify the target = { format = { type = "qcow2" } } for the overlay example volume (in addition to its backing disk), or it would be created as "raw" and cause an error on apply:

$ terraform apply
│ Error: Volume Creation Failed
│ 
│   with libvirt_volume.overlay,
│   on main.tf line 32, in resource "libvirt_volume" "overlay":
│   32: resource "libvirt_volume" "overlay" {
│ 
│ Failed to create storage volume: this function is not supported by the connection driver: backing
│ storage not supported for raw volumes
╵

I made the necessary adjustments to the format parameter(s) in the all the libvirt_volume examples in the registry docs and confirmed they validate, plan, and apply with the following minimal example:

terraform {
  required_providers {
    libvirt = {
      source = "dmacvicar/libvirt"
      version = "0.9.1"
    }
  }
}

provider "libvirt" {
  uri = "qemu+sshcmd://[email protected]/system"
}

# obtain the base GenericCloud image from AlmaLinux

# Basic volume
resource "libvirt_volume" "example" {
  name     = "example.qcow2"
  pool     = "default"
  capacity = 10737418240 # 10 GB
  target = { format = { type = "qcow2" } }
}

# Volume with backing store
resource "libvirt_volume" "base" {
  name     = "base.qcow2"
  pool     = "default"
  capacity = 10737418240
  target = { format = { type = "qcow2" } }
}

resource "libvirt_volume" "overlay" {
  name     = "overlay.qcow2"
  pool     = "default"
  capacity = 10737418240
  target = { format = { type = "qcow2" } }
  
  backing_store = {
    path   = libvirt_volume.base.path
    target = { format = { type = "qcow2" } }
  }
}

# Volume from HTTP URL upload
resource "libvirt_volume" "ubuntu_base" {
  name   = "ubuntu-22.04.qcow2"
  pool   = "default"
  target = { format = { type = "qcow2" } }

  create = {
    content = {
      url = "https://cloud-images.ubuntu.com/releases/22.04/release/ubuntu-22.04-server-cloudimg-amd64.img"
    }
  }
  # capacity is automatically computed from Content-Length header
}

# Volume from local file upload
resource "libvirt_volume" "from_local" {
  name   = "custom-image.qcow2"
  pool   = "default"
  target = { format = { type = "qcow2" } }

  create = {
    content = {
      url = "/path/to/local/image.qcow2"
      # or: url = "file:///path/to/local/image.qcow2"
    }
  }
  # capacity is automatically computed from file size
}

I would try to fix the documentation myself but I'm not sure exactly how to go about generating it - my apologies.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions