terraform-provider-libvirt icon indicating copy to clipboard operation
terraform-provider-libvirt copied to clipboard

error creating libvirt storage pool: operation failed: Storage source conflict with pool: 'default'

Open bjt-user opened this issue 1 year ago • 2 comments

System Information

Linux distribution

NAME="Arch Linux"

Terraform version

$ terraform version
Terraform v1.9.6
on linux_amd64
+ provider registry.terraform.io/dmacvicar/libvirt v0.8.0

Description of Issue/Question

Setup

$ cat *.tf
resource "libvirt_pool" "base" {
	name = "base"
	type = "dir"
	path = "/var/lib/libvirt/images"
}

resource "libvirt_volume" "alpine_iso" {
	name = "alpine_disk.qcow2"
	pool = libvirt_pool.base.name
	source = "https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/x86_64/alpine-virt-3.20.3-x86_64.iso"
}
provider "libvirt" {
	uri = "qemu:///system"
}
terraform {
	required_providers {
		libvirt = {
			source = "dmacvicar/libvirt"
		}
	}
}

Steps to Reproduce Issue

$ terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # libvirt_pool.base will be created
  + resource "libvirt_pool" "base" {
      + allocation = (known after apply)
      + available  = (known after apply)
      + capacity   = (known after apply)
      + id         = (known after apply)
      + name       = "base"
      + path       = "/var/lib/libvirt/images"
      + type       = "dir"
    }

  # libvirt_volume.alpine_iso will be created
  + resource "libvirt_volume" "alpine_iso" {
      + format = (known after apply)
      + id     = (known after apply)
      + name   = "alpine_disk.qcow2"
      + pool   = "base"
      + size   = (known after apply)
      + source = "https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/x86_64/alpine-virt-3.20.3-x86_64.iso"
    }

Plan: 2 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

libvirt_pool.base: Creating...
╷
│ Error: error creating libvirt storage pool: operation failed: Storage source conflict with pool: 'default'
│ 
│   with libvirt_pool.base,
│   on libvirt_pool.tf line 1, in resource "libvirt_pool" "base":
│    1: resource "libvirt_pool" "base" {
│ 
╵

There are already .qcow2 files in the specified path for the storage pool:

$ ls /var/lib/libvirt/images
alpine_x86_64.qcow2  archlinux.qcow2  freebsd-x86.qcow2

But the default pool has a different target path:

# pool-dumpxml default 
<pool type='dir'>
  <name>default</name>
  <uuid>c70b93dc-5b04-4958-83da-5654bd12a1da</uuid>
  <capacity unit='bytes'>125425360896</capacity>
  <allocation unit='bytes'>63068778496</allocation>
  <available unit='bytes'>62356582400</available>
  <source>
  </source>
  <target>
    <path>/home/myuser/.local/share/libvirt/images</path>
    <permissions>
      <mode>0711</mode>
      <owner>1000</owner>
      <group>998</group>
    </permissions>
  </target>
</pool>

So I don't understand the conflict here.
All other pools also do not have the specified path.


Additional information:

Do you have SELinux or Apparmor/Firewall enabled? Some special configuration?

$ sestatus
bash: sestatus: command not found
$ systemctl status firewalld
○ firewalld.service - firewalld - dynamic firewall daemon
     Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; preset: disabled)
     Active: inactive (dead)
       Docs: man:firewalld(1)

bjt-user avatar Oct 05 '24 10:10 bjt-user

Hi, I think there might be confusion about system and user libvirt sessions. It looks like from Terraform you are using system one but when you show XML for default storage pool, it looks like it might be user one.

scabala avatar Oct 23 '24 20:10 scabala

Be careful with operating mode system and session.
See docs:

  • https://libvirt.org/daemons.html#operating-modes
  • https://libvirt.org/uri.html#qemu-qemu-and-kvm-uris

Don't use /var/lib/libvirt/images as base path because when doing a terraform destroy, this dir can be deleted and it should not.

Suggestions for your case:

  • variables.tf
variable "libvirt_uri" {
  type    = string
  default = "qemu:///system"
}
  • providers.tf
provider "libvirt" {
  uri = var.libvirt_uri
}
  • main.tf
resource "libvirt_pool" "base" {
  name = "base"
  type = "dir"
  target {
    path = "/var/lib/libvirt/images/base"
  }
}

resource "libvirt_volume" "alpine_iso" {
  name = "alpine_disk.qcow2"
  pool = libvirt_pool.base.name
  source = "https://dl-cdn.alpinelinux.org/alpine/v3.20/releases/x86_64/alpine-virt-3.20.3-x86_64.iso"
}

dylanf9797 avatar Mar 15 '25 14:03 dylanf9797

ℹ️ ℹ️ ℹ️ ℹ️ ℹ️ ℹ️

This issue report is relevant to the legacy version of the provider, which is now in the v0.8 branch of this repository.

Future development is based on a new provider, which is not compatible with this one, nor does share code.

As the new provider solves many issues with the legacy, and to make development in my free time more enjoyable, I have decided to close all bugs for the legacy provider, and to ask to check if the bug would apply to the new one. This also to encourage trying the new version.

  • https://registry.terraform.io/providers/dmacvicar/libvirt/latest

and check the documentation:

  • https://github.com/dmacvicar/terraform-provider-libvirt/blob/main/README.md
  • https://registry.terraform.io/providers/dmacvicar/libvirt/latest/docs

You are free to reopen the bug for v0.8. It may encourage someone to fix it. My efforts will go into the new provider.

I ask you to check the new provider and re-evaluate this bug. 🙏

dmacvicar avatar Nov 08 '25 02:11 dmacvicar