Open lethargosapatheia opened 2 years ago
On Archlinux I'm experiencing the same issue on packer-1.8.1-1-x86_64
and on packer 1.8.2-1-x86_64.
The issue is not present with packer-1.8.0-2-x86_64
.
Packer plugin does not seem to influence the triggering of the bug.
The culprit seems to be here:
Error creating VM: error creating VM: unable to create VM 80000 - unsupported format 'qcow2' at /usr/share/perl5/PVE/Storage/LvmThinPlugin.pm line 87.
84 sub alloc_image {
85 my ($class, $storeid, $scfg, $vmid, $fmt, $name, $size) = @_;
86
87 die "unsupported format '$fmt'" if $fmt ne 'raw';
88
89 die "illegal name '$name' - should be 'vm-$vmid-*'\n"
90 if $name && $name !~ m/^vm-$vmid-/;
91
92 my $vgs = PVE::Storage::LVMPlugin::lvm_vgs();
93
94 my $vg = $scfg->{vgname};
95
96 die "no such volume group '$vg'\n" if !defined ($vgs->{$vg});
97
98 $name = $class->find_free_diskname($storeid, $scfg, $vmid)
99 if !$name;
100
101 my $cmd = ['/sbin/lvcreate', '-aly', '-V', "${size}k", '--name', $name,
102 '--thinpool', "$vg/$scfg->{thinpool}" ];
103
104 run_command($cmd, errmsg => "lvcreate '$vg/$name' error");
105
106 return $name;
107 }
As you can see from the path, this file lives on the Proxmox Server, so it didn't change between packer versions. Which means that for some reason the non-bugged packer versions were not calling that method.
Thanks for reaching out. We will take a look at what might be happening here before the next release.
Any updates on this issue? On version 1.8.3 I get the same error.
Is qcow2 actually supposed to be supported?
I see https://github.com/hashicorp/packer-plugin-proxmox/issues/28 which mentions it is not supported, and https://github.com/hashicorp/packer-plugin-proxmox/issues/29 which is asking for support. Then there is https://github.com/hashicorp/packer-plugin-proxmox/issues/23 and this issue that make it sound like qcow2 support is expected. Plus, the docs list it as an option.
In any case, I need thin provisioning for my use case. And qcow2 is not working with Packer 1.8.3 and Proxmox Community 7.2-11. 1.0.6 or greater is the version of this plugin I'm on.
Anyone have any workarounds?
Well, it's worked wthout any issues until this came up in this version, so in this sense it was definitely supported. And yes, given that it's an official option, you infer that it's also officially supported.
The only workaround for me was to keep pin the version to 1.8.0, which probably won't change anything as far as proxmox is concerned. I'm sure no one is hurrying to bring new features for it :) The focus is going to be the cloud, vsphere etc.
Well I figured out my issue. I was not using a storage pool on Proxmox that supported vm images. Once I configured a "Directory" type, my builds started working. Both the old version of Packer, and the current 1.8.3 version.
You can also change the disk format to "raw". I don't know if this is a bad decision but it works.
I have to say, the state of automatisation in proxmox and collaboration with the proxmox developers is deplorable. There's so much you just have to accept if you want to self-host things and use open source software. It is what it is.
I'm using Packer 1.8.5 same issue with qcow2. Switched to "raw" as mentioned by @53845714nF
I switch to raw and then I get
==> proxmox-iso.windows: Starting VM 2023/09/23 02:01:27 packer-plugin-proxmox_v1.1.3_x5.0_linux_amd64 plugin: 2023/09/23 02:01:27 No boot command given, skipping 2023/09/23 02:01:30 packer-plugin-proxmox_v1.1.3_x5.0_linux_amd64 plugin: 2023/09/23 02:01:30 [DEBUG] Unable to get address during connection step: 500 QEMU guest agent is not running 2023/09/23 02:01:30 packer-plugin-proxmox_v1.1.3_x5.0_linux_amd64 plugin: 2023/09/23 02:01:30 Waiting for WinRM, up to timeout: 30m0s ==> proxmox-iso.windows: Waiting for WinRM to become available... 2023/09/23 02:01:33 packer-plugin-proxmox_v1.1.3_x5.0_linux_amd64 plugin: 2023/09/23 02:01:33 [DEBUG] Error getting WinRM host: 500 QEMU guest agent is not running
Could this be related to QEMU raw settings not allowing QEMU guest agent to to run? I boot the host up manually after it creates the VM and then I get the callback error.
In my opinion, this has nothing to do with the file system format. See if you need to install qemu agent with packer or just turn it on. I have a qemu_agent = true
in my setting. Maybe it has to be already installed in the ISO.
Here is my config as an example:
source "proxmox-iso" "debian12" {
# proxmox settings
proxmox_url = "${var.proxmox_url}"
node = "${var.node}"
username = "${var.username}"
token = "${var.token}"
insecure_skip_tls_verify = true
# VM General Settings
vm_id = "${var.vm_id}"
vm_name = "debian12-template"
template_description = "Debian 12 Server Image"
iso_file = "${var.proxmox_iso_pool}/${var.debian_image}"
unmount_iso = true
qemu_agent = true
I figured it out the VM takes a long while to callback to the provisioner WinRM. When the WinRM provisioning host, dial tcp takes place it was not able to connect bc of the networking I had setup. The route to the host was not setup, so this was not an issue so far with changing format = "qcow2" to "raw". @53845714nF Thank you for helping me understand how the qemu agent is called in the script this made me go read through the config files more.
Changing qemu_agent to true doesn't change anything in my case. This is saw disappointing, it's beyond words. They've actually updated packer and haven't checked if the disk format directive actually does what it's supposed to be doing.
Overview of the Issue
Hello,
It seems that packer errors out when trying to deploy a template and it complains about qcow2 being unsupported. So I thought I would start here rather than on the hashicorp forum, as I'm not really sure where the problem lies.
Reproduction Steps
Running packer build on a proxmox server generates this error. This isn't happening with packer
1.8.0
.Plugin and Packer version
v.18.1
Simplified Packer Buildfile
Operating system and Environment details
Running packer on Ubuntu 20.04.4
Log Fragments and crash.log files
I've tested this on both proxmox 6.4-14 and 7.2-4.