"virt-customize" does not install qemu-guest-agent on qcow2 image

[gemini]

I cannot get qemu-guest-agent installed on the debian-12-generic-amd64.qcow2 image. I'm trying to follow the instructions from this tutorial and code.

Here are the steps I'm following and the outcome:

First, I get the image using this script:

./bin/import-cloud-image https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-generic-amd64.qcow2 debian-12-generic-amd64.qcow2

Next, since that Debian cloud image does not have qemu-guest-agent, I do this:
virt-customize -a /var/lib/vz/images/debian-12-generic-amd64.qcow2 --install qemu-guest-agent

Here's the output:

root@hoth:~# virt-customize -a /var/lib/vz/images/debian-12-generic-amd64.qcow2 --install qemu-guest-agent
[   0.0] Examining the guest ...
[   2.1] Setting a random seed
virt-customize: warning: random seed could not be set for this type of
guest
[   2.1] Installing packages: qemu-guest-agent
[   5.2] Finishing off

Then, after making sure Packer will be using a privileged token on the Proxmox node, I execute this from this documentation:

packer init main.pkr.hcl &&\
  packer validate -var-file="auto.pkrvars.hcl" . &&\
  packer build -var-file="auto.pkrvars.hcl" .

It successfully creates a VM, but it hangs on:

➜ packer init main.pkr.hcl &&\
  packer validate -var-file="auto.pkrvars.hcl" . &&\
  PACKER_LOG=1 packer build -var-file="auto.pkrvars.hcl" .
The configuration is valid.
proxmox-clone.base: output will be in this color.

==> proxmox-clone.base: Using existing SSH private key for the communicator...
==> proxmox-clone.base: Creating VM
==> proxmox-clone.base: Starting VM
...
2025/05/11 11:06:07 packer-plugin-proxmox_v1.2.2_x5.0_darwin_arm64 plugin: 2025/05/11 11:06:07 using token auth
2025/05/11 11:06:07 packer-plugin-proxmox_v1.2.2_x5.0_darwin_arm64 plugin: 2025/05/11 11:06:07 disk discovered on source vm at scsi0
2025/05/11 11:06:21 packer-plugin-proxmox_v1.2.2_x5.0_darwin_arm64 plugin: 2025/05/11 11:06:21 No boot command given, skipping
2025/05/11 11:06:24 packer-plugin-proxmox_v1.2.2_x5.0_darwin_arm64 plugin: 2025/05/11 11:06:24 [DEBUG] Unable to get address during connection step: 500 QEMU guest agent is not running
2025/05/11 11:06:24 packer-plugin-proxmox_v1.2.2_x5.0_darwin_arm64 plugin: 2025/05/11 11:06:24 [INFO] Waiting for SSH, up to timeout: 10m0s
2025/05/11 11:06:27 packer-plugin-proxmox_v1.2.2_x5.0_darwin_arm64 plugin: 2025/05/11 11:06:27 [DEBUG] Error getting SSH address: 500 QEMU guest agent is not running
2025/05/11 11:06:35 packer-plugin-proxmox_v1.2.2_x5.0_darwin_arm64 plugin: 2025/05/11 11:06:35 [DEBUG] Error getting SSH address: 500 QEMU guest agent is not running
2025/05/11 11:06:43 packer-plugin-proxmox_v1.2.2_x5.0_darwin_arm64 plugin: 2025/05/11 11:06:43 [DEBUG] Error getting SSH address: 500 QEMU guest agent is not running
2025/05/11 11:06:52 packer-plugin-proxmox_v1.2.2_x5.0_darwin_arm64 plugin: 2025/05/11 11:06:52 [DEBUG] Error getting SSH address: 500 QEMU guest agent is not running

That times out. Before it times out, I can use the SSH key provided in the variables to SSH into the VM from my client, but I get this output:

debian@nomad-base-debian12-2025-05-11:~$ sudo systemctl status qemu-guest-agent
Unit qemu-guest-agent.service could not be found.
debian@nomad-base-debian12-2025-05-11:~$ sudo systemctl list-units --type=service --all | grep qemu
debian@nomad-base-debian12-2025-05-11:~$

I do have cloud init enabled on the guest, as you can see with these input variables in the packer build:

  # Properties of the new VM
  vm_id                = var.vm_id
  vm_name              = local.vm_name
  template_description = local.template_desc
  qemu_agent              = true
  cloud_init              = true
  cloud_init_storage_pool = var.cloud_init_storage_pool

Also, I confirmed in the Proxmox WebUI after the VM is created that "QEMU Guest Agent" is Enabled.

What am I missing? And how did kencx get proxmox-clone to work with the code he provided here? The only thing that makes sense is that he wasn't using Debian, considering that the Debian cloud-init image does not have qemu-guest-agent installed. But still...why does virt-customize say it is installed and yet it is not?

The whole idea eventually is to automatic this process in my self-hosted GitLab CE instance with a GitLab CI/CD runner. Does anyone have another solution that may work in order to automate the following?

1. Download the latest Debian qcow2 image.
2. Create a VM template from it.
3. Use Packer's proxmox-clone to create a new custom VM template from that default template but with my own shell provisioners.
4. Proceed to then automate the deployment of a new VM from that template using Terraform or whatever (I'm very familiar with Terraform/Packer since I use them at work as an SRE engineer to build AWS AMIs for EC2 launch templates).

 

[bbgeek17]

Next, since that Debian cloud image does not have qemu-guest-agent, I do this:
virt-customize -a /var/lib/vz/images/debian-12-generic-amd64.qcow2 --install qemu-guest-agent

Hi @gemini,

Your query falls well outside the scope of this forum, which is intended for discussions around Proxmox VE: Installation and Configuration. You're working with a third-party image, manipulating it using external tools (like virt-*) that are not part of PVE by default. At this point, you're essentially configuring a non-Proxmox environment with non-Proxmox tools.

You've confirmed that the package you thought you installed, using said tools on a third-party image, is not actually installed. What exactly do you expect the PVE hypervisor to do about that?

A very simplified approach would be:

a) Download the image
b) Boot a VM from this image
c) Install the agent
d) Confirm the agent is installed (i.e., check for the package and running service)
e) Start the service
f) Test the agent communication

Once you have a known-good, working setup, you can then work backward and troubleshoot why your process isn't producing the same result.

Cheers

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[gemini]

Pardon me if this is the incorrect forum for this question. I actually decided to post here only after finding a similar thread in this same forum regarding the QEMU guest agent in this thread. And the OP in that thread referenced another thread on this forum related to their issue.

I did not know that virt-customize was not a Proxmox tool because I had only come across it for this specific scenario involving a tutorial where the command was executed on a Proxmox box in order to utilize a tool (Packer proxmox-clone builder) specifically made to interact with the PVE API.

But if the core issue is not PVE but actually virt-customize failing to install within the qcow2, then I guess it’s a third party tool issue.

Does that mean this thread should be closed or does the following question fall under the topic of PVE Configuration?

Q: How do other people configuring their PVE nodes/clusters perform the process of “wget”-ing a qcow2 image, booting a VM from the image, installing the agent, and then creating a template from that image automatically?

The way I would normally solve this issue is hunting down tutorials or tools to do this, but I haven’t yet found anything besides the Packer builder example I found for being an “automated create VM template in PVE tool” and then provisioning software on that image. Is this just a rare enough scenario that everyone builds their own tool/script because the majority of Linux distro cloud images have qemu-guest-agent baked into the qcow2 they provide, thus eliminating that step?

Is there a different qcow2 image that would be better suited to this task, one that is more widely used for this exact scenario, as it has the qemu-guest-agent service running by default in the distro-provided image when PVE has the “Qemu Guest Agent” option enabled?

 

[bbgeek17]

Does that mean this thread should be closed

The idea is not make you close the thread but to set the right expectations.

I did not know that virt-customize was not a Proxmox tool

Build a fresh installation of virtual PVE and you will find that virt* tools are not part of it. You must have pulled them in as you installed packer or some other tool directly on PVE.
If you are building a system for production use you should treat your PVE installation as an appliance. Use a workstation or a VM for image management.

Q: How do other people configuring their PVE nodes/clusters perform the process of “wget”-ing a qcow2 image, booting a VM from the image, installing the agent, and then creating a template from that image automatically?

Personally, I use wget, place the image into a correct location, create a VM, import a disk, and make VM a template.
Agent is not required for day to day operations. Frankly, I didn't realize it is absent on Debian cloud image. You can use CloudInit to install the agent, you can use ansible, or, as you already started, build your own custom image.

Is there a different qcow2 image that would be better suited to this task, one that is more widely used for this exact scenario, as it has the qemu-guest-agent service running by default in the distro-provided image when PVE has the “Qemu Guest Agent” option enabled?

Generally, one would pick an image/OS/distribution that suites their business needs rather based on how Qemu Agent is integrated. Define your business needs and pick the Distribution that matches.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[gemini]

The idea is not make you close the thread but to set the right expectations.

Build a fresh installation of virtual PVE and you will find that virt* tools are not part of it. You must have pulled them in as you installed packer or some other tool directly on PVE.
If you are building a system for production use you should treat your PVE installation as an appliance. Use a workstation or a VM for image management.


Personally, I use wget, place the image into a correct location, create a VM, import a disk, and make VM a template.
Agent is not required for day to day operations. Frankly, I didn't realize it is absent on Debian cloud image. You can use CloudInit to install the agent, you can use ansible, or, as you already started, build your own custom image.

Generally, one would pick an image/OS/distribution that suites their business needs rather based on how Qemu Agent is integrated. Define your business needs and pick the Distribution that matches.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

I appreciate the input. Thank you for your clarifying remarks in this thread.