Terraform-provider-libvirt: with version 0.5.1+git.1550869862.4283c564-10.1 (from yesterday) can't boot a VM with a non-base image volume

Created on 13 Mar 2019  路  12Comments  路  Source: dmacvicar/terraform-provider-libvirt

System Information

Linux distribution

Debian testing

Terraform version

terraform -v

Terraform v0.11.13

Provider and libvirt versions

terraform-provider-libvirt -version

terraform-provider-libvirt 0.5.1
Compiled against library: libvirt 4.0.0
Using library: libvirt 5.0.0
Running hypervisor: QEMU 3.1.0
Running against daemon: 5.0.0

Description of Issue/Question

I have a simple setup with:

  • one base volume created from a local file image
  • one volume based on the previous one
  • one domain which disk is the previous one

When using version 0.5.1 it works like expected. Yesterday I installed 0.5.1+git.1550869862.4283c564-10.1 from binary, and now when applying terraform plan, there is no error but my domain can't boot on its disk with the error "could not read the boot disk".
Without changes in the tf files.

Setup

(Please provide the full _main.tf_ file for reproducing the issue (Be sure to remove sensitive information)

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

resource "libvirt_volume" "debian_stretch_image" {
  name = "debian_stretch_image"
  source = "/tmp/debian-stretch-qemu"
  format = "qcow2"
}

resource "libvirt_volume" "debian_stretch_volume-bastion" {
  name = "debian_stretch_volume-bastion"
  base_volume_id = "${libvirt_volume.debian_stretch_image.id}"
}

resource "libvirt_domain" "terraform_bastion" {
  name = "terraform_bastion"
  vcpu = 1
  memory = 1024
  autostart = true
  disk {
    volume_id = "${libvirt_volume.debian_stretch_volume-bastion.id}"
  }
  network_interface {
    network_name = "default"
    hostname = "bastion"
  }
  graphics {
    type = "vnc"
    listen_type = "address"
  }
}

Steps to Reproduce Issue

$ terraform apply

Then look at the state of the machine (I use virt-manager for that), I see in the console "Booting from Hard Disk... Boot failed: could not read the boot disk"

bug help wanted need investigation
Source
picture daks

All 12 comments

thx @daks yes this is a known issue we have in master. thx for reportng

MalloZup picture MalloZup on 13 Mar 2019

i will have a look at this once i have some time

MalloZup picture MalloZup on 13 Mar 2019

some updates.

with this conf we reproduce.

# instance the provider
provider "libvirt" {
  uri = "qemu:///system"
}

# adapt the build number
resource "libvirt_volume" "leap15" {
  name   = "leap15-qcow2"
  pool   = "default"
  source = "/tmp/leap15-qcow2"
  format = "qcow2"
}

resource "libvirt_volume" "back" {
  name = "back"
  base_volume_id = "${libvirt_volume.leap15.id}"
}

# Create the machine
resource "libvirt_domain" "domain-leap15" {
  name   = "leap15-terraform"
  memory = "512"
  vcpu   = 1

  disk {
    volume_id = "${libvirt_volume.back.id}"
  }

}

with this not.

# instance the provider
provider "libvirt" {
  uri = "qemu:///system"
}

# adapt the build number
resource "libvirt_volume" "leap15" {
  name   = "leap15"
  pool   = "default"
  source = "/tmp/leap15-qcow2"
  format = "qcow2"
}


# Create the machine
resource "libvirt_domain" "domain-leap15" {
  name   = "leap15-terraform"
  memory = "512"
  vcpu   = 1

  disk {
    volume_id = "${libvirt_volume.leap15.id}"
  }

}
MalloZup picture MalloZup on 14 Mar 2019

@daks could you try to remove 


resource "libvirt_volume" "debian_stretch_volume-bastion" {
  name = "debian_stretch_volume-bastion"
  base_volume_id = "${libvirt_volume.debian_stretch_image.id}"
}

from your conf and adapt it accordingly? i think it should work.

The bug is caused by the backingstore volume somehow, but we need more time to check what is causing the regression.

MalloZup picture MalloZup on 14 Mar 2019

When removing the part you mention, I can't apply my terraform plan, which is logical because my domain don't have a disk available

Error: resource 'libvirt_domain.terraform_bastion' config: unknown resource 'libvirt_volume.debian_stretch_volume-bastion' referenced in variable libvirt_volume.debian_stretch_volume-bastion.id

I can switch to not use a "base" disk volume, is this what you want me to do? It will work, but it's not the same functionality.

For the moment, I don't need to use the git version so I will revert back to release 0.5.1.

daks picture daks on 19 Mar 2019

@daks yep, i know it will not have some functionality. I will look into why we have the regression. at least i can reproduce it. Yes, revert back to release 0.5.1. this will work until we fix it.. THx! :sun_with_face:

MalloZup picture MalloZup on 19 Mar 2019

@MalloZup you're welcome, thank you for your work :)

daks picture daks on 19 Mar 2019
👍1

I think I know where to look.

If you look how we handle backing volumes, the main volume does not need to specify size, because we detect the size of the backing volume (or allow a size at least as small).

However, if I look at the created main volume in my local test, the size is 196k

$ sudo qemu-img info -U /var/
lib/libvirt/images/disk
image: /var/lib/libvirt/images/disk
file format: qcow2
virtual size: 1.0K (1024 bytes)
disk size: 196K
cluster_size: 65536
backing file: /var/lib/libvirt/images/leap15
backing file format: qcow2
Format specific information:
    compat: 0.10
    refcount bits: 16

Wile the backing volume is much bigger:

$ sudo qemu-img info -U /var/
lib/libvirt/images/leap15
image: /var/lib/libvirt/images/leap15
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 529M
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

If I set the size manually for the main volume, to be at least as big:


# adapt the build number
resource "libvirt_volume" "disk" {
  name   = "disk"
  size = 10737418240
  base_volume_id = "${libvirt_volume.leap15.id}"
}

# adapt the build number 
resource "libvirt_volume" "leap15" {
  name   = "leap15"
  pool   = "default"
  source = "https://download.opensuse.org/repositories/Cloud:/Images:/Leap_15.0/images/openSUSE-Leap-15.0-OpenStack.x86_64-0.0.4-Buildlp150.12.138.qcow2"
  format = "qcow2"
}

Then I can boot normally:

Screenshot_leap15-terraform_2019-03-31_13:34:24

Therefore I will look in the code that looks the backing store size.

dmacvicar picture dmacvicar on 31 Mar 2019
👍1 
2019-03-31T13:55:38.165+0200 [DEBUG] plugin.terraform-provider-libvirt: 2019/03/31 13:55:38 [DEBUG] Generated XML for libvirt volume:
2019-03-31T13:55:38.165+0200 [DEBUG] plugin.terraform-provider-libvirt:   <volume>
2019-03-31T13:55:38.165+0200 [DEBUG] plugin.terraform-provider-libvirt:       <name>disk</name>
2019-03-31T13:55:38.165+0200 [DEBUG] plugin.terraform-provider-libvirt:       <capacity unit="bytes">1</capacity>
2019-03-31T13:55:38.165+0200 [DEBUG] plugin.terraform-provider-libvirt:       <target>
2019-03-31T13:55:38.165+0200 [DEBUG] plugin.terraform-provider-libvirt:           <format type="qcow2"></format>
2019-03-31T13:55:38.165+0200 [DEBUG] plugin.terraform-provider-libvirt:           <permissions>
2019-03-31T13:55:38.165+0200 [DEBUG] plugin.terraform-provider-libvirt:               <mode>644</mode>
2019-03-31T13:55:38.165+0200 [DEBUG] plugin.terraform-provider-libvirt:           </permissions>
2019-03-31T13:55:38.165+0200 [DEBUG] plugin.terraform-provider-libvirt:       </target>
2019-03-31T13:55:38.165+0200 [DEBUG] plugin.terraform-provider-libvirt:       <backingStore>
2019-03-31T13:55:38.165+0200 [DEBUG] plugin.terraform-provider-libvirt:           <path>/var/lib/libvirt/images/leap15</path>
2019-03-31T13:55:38.165+0200 [DEBUG] plugin.terraform-provider-libvirt:           <format type="qcow2"></format>
2019-03-31T13:55:38.165+0200 [DEBUG] plugin.terraform-provider-libvirt:       </backingStore>
2019-03-31T13:55:38.165+0200 [DEBUG] plugin.terraform-provider-libvirt:   </volume>

Capacity=1

dmacvicar picture dmacvicar on 31 Mar 2019

I have an improved version of the testcase and a reworked version of the code that fixes the issue. I will do a PR later, as I still need to understand how the bug was introduced.

=== RUN   TestAccLibvirtVolume_BackingStoreTestByName
--- FAIL: TestAccLibvirtVolume_BackingStoreTestByName (20.11s)
    testing.go:538: Step 0 error: Check failed: Check 3/3 error: libvirt_volume.9adhdysj7t: Attribute 'size' expected "1073741824", got "1024"
FAIL
FAIL    github.com/dmacvicar/terraform-provider-libvirt/libvirt 20.145s
dmacvicar picture dmacvicar on 31 Mar 2019
👍1

Regression was introduced with f86539c365b5bd12374318070894c504a1636c4b
If I revert that, my enhanced test passes

dmacvicar picture dmacvicar on 31 Mar 2019

@daks feel free to try this out, we will merge this soonish, but you can try out the PR :rocket: . thx @dmacvicar https://github.com/dmacvicar/terraform-provider-libvirt/pull/573

MalloZup picture MalloZup on 1 Apr 2019
Was this page helpful?
0 / 5 - 0 ratings

Related issues

lifeofguenter picture lifeofguenter  路  5Comments
arunnalpet picture arunnalpet  路  3Comments
jdandrea picture jdandrea  路  4Comments
james-crowley picture james-crowley  路  6Comments
MalloZup picture MalloZup  路  6Comments