Snapshot fails on images that enable the QEMU guest agent

Troubleshooting · Updated Jun 2026

Coming from another cloud?

▸AWS·EC2 Instances

EC2 Instanceshigh

Uses EC2 RunInstances API instead of Nova servers.create.
Requires predefined instance type selection.
Supports per-second On-Demand billing and Spot/Reserved options.
Includes hibernation state not standard in OpenStack.

AWS docs ↗

▸Azure·Virtual Machines

Virtual Machineshigh

Uses Azure Resource Manager (ARM) REST API at /providers/Microsoft.Compute/virtualMachines instead of OpenStack Nova API at /v2.1/servers.
Tightly integrated with Azure services like Azure Active Directory for authentication, unlike OpenStack's Keystone.
VM creation requires specifying size from predefined series with hardware-specific features (e.g., AMD/Intel/ARM), not custom flavor configs.
Billed per second with complex pricing tiers based on series/reservation options, vs OpenStack's typically hourly or usage-based.

Azure docs ↗

▸DigitalOcean·Droplets

Dropletshigh

API surface is DigitalOcean’s proprietary REST/CLI/Terraform tooling rather than OpenStack Nova/Neutron/Glance APIs (Droplets are managed via DigitalOcean UI/CLI/API/Terraform).
Billing is usage-based with per-second billing (60-second minimum and monthly cap) rather than the typical per-hour, quota-based charge model users often see in OpenStack-based clouds.
Droplets include a bundled outbound transfer allowance with each plan (starting at 500 GiB/month) rather than a separate bandwidth quota/metering model users often encounter in OpenStack deployments.
Droplets are described as Linux-based VMs on virtualized hardware with local SSD storage, whereas OpenStack deployments commonly expose distinct block storage (Cinder) and image services (Glance) and may not bundle bandwidth/monitoring/firewalls into the instance offering.

DigitalOcean docs ↗

▸Google Cloud·VM instances

VM instanceshigh

Uses REST API 'instances.insert' instead of Nova 'servers.create' with different auth via service accounts vs Keystone.
Supports bare metal instances (no hypervisor), not in standard OpenStack Nova.
Network interfaces tied to VPC subnets; differs from Neutron ports/floating IPs.

Google Cloud docs ↗

▸Hetzner·Cloud Servers

Cloud Servershigh

Servers provisioned individually via Hetzner API (hcloud), not OpenStack Nova flavors; fixed instance types like CX11 (1 vCPU, 2GB RAM, 20GB NVMe).
No flavor customization; choose from predefined shared/dedicated vCPU series.
Billing hourly with monthly cap per server (e.g., €3.29/mo cap for CX11), charged even when powered off until deleted, unlike typical OpenStack stop-to-pause billing.
Custom REST API at api.hetzner.cloud/v1/servers instead of OpenStack Nova /v2.1/servers (different auth, payloads, response formats).

Hetzner docs ↗

Snapshot fails on images that enable the QEMU guest agent

The default Ubuntu-22.04 shared image snapshots without any extra steps, because it ships with the property hw_qemu_guest_agent='no'. This page covers a narrower case: custom or user-uploaded images that set hw_qemu_guest_agent='yes' but do not run the agent inside the instance.

Issue#

When an image sets hw_qemu_guest_agent='yes', Nova asks the QEMU guest agent inside the instance to quiesce the filesystem before it captures a snapshot. If the agent is missing or stopped, the snapshot fails.

In the Quake AI console, Create Snapshot reports that the operation failed. Select Click to show detail to see the error:

libvirt cannot connect to the qemu-guest-agent inside the instance

The default Ubuntu-22.04 image sets hw_qemu_guest_agent='no', so a default instance does not reach this path.

Confirm whether your image is affected#

Read the image property before you change anything. The error applies only when the property is set to yes:

bash

openstack image show YOUR_IMAGE_NAME -c properties

Look for hw_qemu_guest_agent='yes' in the output. If the value is no or absent, the snapshot does not depend on the guest agent, and this workaround does not apply.

Workaround#

If your image sets hw_qemu_guest_agent='yes' and the snapshot fails with the error above, install and start the agent inside the instance.

Connect to the instance over SSH:

bash

ssh ubuntu@YOUR_INSTANCE_IP

Install the agent and start it:

bash

sudo apt-get update
sudo apt-get install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent

Close the SSH session:

bash

exit

From the Quake AI console, go to Compute > Instances and find the instance.
Select More > Instance Status > Soft Reboot, then wait for the instance to return to the active state.
Select More > Backup & Snapshots > Create Snapshot and provide a name for the snapshot.

The snapshot now completes, because the guest agent answers the quiesce request from Nova.

Usage Guidelines

The sample code, software libraries, command line tools, proofs of concept, templates, and other related technology on this page (including any of the foregoing that is provided by Quake AI personnel) is provided to you as Quake AI Content under the Quake AI Customer Agreement, or the relevant written agreement between you and Quake AI (whichever applies). Do not use this Quake AI Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the Quake AI Content (such as sample code) as appropriate for production grade use based on your specific quality control practices and standards. Deploying Quake AI Content may incur Quake AI charges for creating or using Quake AI chargeable resources, such as running Compute instances or storing data in Object Storage. Your use is also subject to the Acceptable Use Policy.

For the full policy, see Usage Guidelines.

Last validated: 19.06.2026

Was this page helpful?

Snapshot fails on images that enable the QEMU guest agent

Snapshot fails on images that enable the QEMU guest agent

Issue#

Confirm whether your image is affected#

Workaround#

Usage Guidelines

Quick answers

See Also