Trouble rebooting VMs at the OS layer after upgrading to Incus 7.0?

inflatador · May 15, 2026, 6:51pm

Hello everyone,

I am running Incus 7.0-debian13-202605061505 using the Zabbly package on Debian Trixie. Since upgrading, it seems that about half the time when I issue sudo reboot or something similar from my VMs, they are stopped instead of rebooted and I have to run incus start ${vm} manually.

The VMs are running my own custom image of Fedora 43 and do not have the incus agent running.

I don’t remember this being a problem before the 7.0 upgrade-but that could be a coincidence as well. If anyone has suggestions on how best to troubleshoot, please let me know. I don’t mind installing the incus agent if y’all think it will help matters.

stgraber · May 17, 2026, 12:53pm

We had some fixes around that logic in Incus 7.0 so it’s certainly possible that we’ve regressed something. Can you file a bug at Sign in to GitHub · GitHub?

inflatador · May 23, 2026, 3:27pm

Thanks, I’m working on a reproducer now and will file a bug report when I have better info.

hexa · October 1, 2026, 9:33am

I think we’re seeing the same bug, and it happens every few weeks at most here. It feels like a race condition, because I can’t reproduce it easily. First time this happend was June 22nd (Incus 7.1.0) and last time this happend was yesterday (Incus 7.5.1).

I haven’t found any bug report, so I guess I’ll file one based on these details.

inflatador · October 3, 2026, 9:55pm

@hexa Good luck! I could never find a reproducer. It still happens, but not as often. My Incus environment is severely overprovisioned, so I figured it was related to high resource consumption on the host at the time of the reboot. Sorry I don’t have any better info for you.

stappers · October 5, 2026, 11:07am

I wonder which boot device is being used and which boot priority it has.

stappers · October 5, 2026, 11:09am

Please share a link to the filed bug report.

hexa · October 5, 2026, 9:08pm

github.com/lxc/incus

Guest reset can lead to host-qmp-quit

opened 09:46AM - 05 Oct 26 UTC

mweinelt

### Is there an existing issue for this? - [x] There is no existing issue for t…his bug ### Is this happening on an up to date version of Incus? - [x] This is happening on a supported version of Incus ### Incus system details ```yaml config: cluster.https_address: incus1.example.com:8443 core.https_address: :8443 core.metrics_authentication: "false" core.remote_token_expiry: 1y instances.placement.scriptlet: | def instance_placement(request, candidate_members): config = request.config group = config.get("user.ha_group") if group == None: log_info("Using default placement strategy.") return log_info( "Determining placement of instance '{}' for high-availability group '{}'".format( request.name, group ) ) # Get all instances in the same project instances = get_instances(location="", project=request.project) # Track which cluster members already host a group instance unavailable_member_names = [] for instance in instances: if instance.status != "Running": continue if instance.config.get("user.ha_group") == group: unavailable_member_names.append(instance.location) log_info( "Cluster members hosting resources in high-availability group '{}': {}".format( group, ", ".join(unavailable_member_names) ) ) available_members = [member.server_name for member in candidate_members if member.server_name not in unavailable_member_names] if not available_members: log_warn( "No available cluster members for high-availability group '{}' criteria. Falling back to default placement strategy.".format( group ) ) return log_info( "Available cluster members for high-availability group '{}': {}".format(group, ", ".join(available_members)) ) # Choose the eligible member with the fewest instances def instance_count(name): return get_instances_count(location=name, project=request.project, pending=True) target_member = min(available_members, key=instance_count) set_target(target_member) log_info( "Placing instance '{instance}' on '{member}, because it has the lowest number of running resources.".format( instance=request.name, member=target_member ) ) logging.loki.lifecycle.types: instance logging.loki.target.address: https://loki.example.com logging.loki.target.type: loki logging.loki.types: lifecycle,network-acl api_extensions_count: 562 api_status: stable api_version: "1.0" auth: trusted public: false auth_methods: - tls auth_user_name: root auth_user_method: unix environment: addresses: - 82.195.93.133:8443 - '[2001:41b8:41:41:c6cb:e1ff:fecb:4714]:8443' - 82.195.92.225:8443 - '[2001:41b8:41:44:ac11:3fff:feab:d414]:8443' architectures: - x86_64 - i686 certificate: "" certificate_fingerprint: d0bfc66991c5b7614857d80635807e24909b494b8c7bd22b8521ecc0204eb1a6 driver: qemu | lxc driver_version: 11.1.2 | 7.0.0 firewall: nftables kernel: Linux kernel_architecture: x86_64 kernel_features: {} kernel_version: 6.12.111+deb13-amd64 lxc_features: {} os_name: Debian GNU/Linux os_version: "13" project: default server: incus server_clustered: true server_event_mode: full-mesh server_name: incus1.example.com server_pid: 1201690 server_version: 7.5.1 storage: zfs storage_version: 2.3.9-0+deb13u1 storage_supported_drivers: - name: zfs version: 2.3.9-0+deb13u1 remote: false - name: truenas version: 0.7.7 remote: true - name: dir version: "1" remote: false - name: lvm version: 2.03.31(2) (2025-02-27) / 1.02.205 (2025-02-27) / 4.48.0 remote: false ``` ### Instance details ```yaml architecture: x86_64 config: image.architecture: amd64 image.description: Debian trixie amd64 (20251126_05:24) image.os: Debian image.release: trixie image.serial: '20251126_05:24' image.type: disk-kvm.img image.variant: default volatile.base_image: a45641b6fbf0593f8e2aa080c924ff938d289d856c5dfdeeaba9694052ea9db6 volatile.cloud-init.instance-id: d71fd51c-08e9-43ca-8450-beff9db7438f volatile.enp5s0.host_name: tap15f26462 volatile.enp5s0.hwaddr: 10:66:6a:17:7e:0b volatile.last_state.agent: STARTED volatile.last_state.agent.once: "true" volatile.last_state.power: RUNNING volatile.uuid: d37cff6d-6b8f-4eb0-859c-c9f0c8d6d574 volatile.uuid.generation: d37cff6d-6b8f-4eb0-859c-c9f0c8d6d574 volatile.vm.boot_state: '{"version":1,"cpu_type":"kvm64,hv_relaxed,hv_vpindex,hv_runtime,hv_time,hv_synic,hv_stimer,hv_tlbflush,hv_ipi,hv_frequencies,hv_stimer_direct,hv_xmm_input,hv_tlbflush_ext,rdpid,avx512bw,svm,ht,sse4_1,topoext,nrip_save,fsrm,aes,cmp_legacy,ssbd,avx2,monitor,avx512ifma,arat,vmcb_clean,ibpb,abm,svm_lock,xsaveerptr,flushbyasid,ssse3,movbe,3dnowprefetch,clzero,xsaveopt,rdrand,perfctr_core,avic,gfni,misalignsse,osvw,ibs,avx512vl,wbnoinvd,clwb,vnmi,pdpe1gb,fsgsbase,erms,adx,vgif,smep,bmi2,avx512dq,decodeassists,pclmulqdq,fma,avx512cd,xsaves,avx512f,f16c,umip,pfthreshold,pcid,sse4_2,lbrv,mmxext,clflushopt,xgetbv1,succor,wdt,npt,sse4a,tce,avx,rdtscp,skinit,stibp,bmi1,avx512vbmi,pku,la57,popcnt,extapic,invpcid,vpclmulqdq,fxsr_opt,ibrs,rdseed,tsc_scale,xsave,lahf_lm,xsavec,vaes,smap,perfctr_nb","cpu_topology":{"sockets":1,"cores":2,"threads":1,"explicit":false},"max_cpus":64,"machine_type":"pc-q35-11.1","memory_topology":{"base":2147483648,"max":274877906944,"extra":null}}' volatile.vm.needs_reset: "true" volatile.vm.rtc_adjustment: "0" volatile.vm.rtc_offset: "0" volatile.vsock_id: "1578608988" devices: enp5s0: network: vlan522 type: nic ephemeral: false profiles: - vm - cpu2 - ram2 - disk32 stateful: false description: "" ``` ### Instance log _No response_ ### Current behavior We regularly reboot machines for kernel updates. Every once in a while the machine stops instead of completing a reboot. ``` [2026-09-30T09:15:37+02:00] QUERY: {"execute":"query-status","id":43} [2026-09-30T09:15:37+02:00] REPLY: {"return": {"status": "running", "running": true}, "id": 43} [2026-09-30T09:16:41+02:00] Event: {"timestamp": {"seconds": 1790752601, "microseconds": 94038}, "event": "RESET", "data": {"guest": true, "reason": "guest-reset"}} [2026-09-30T09:16:41+02:00] QUERY: {"execute":"quit","id":72} [2026-09-30T09:16:41+02:00] Event: {"timestamp": {"seconds": 1790752601, "microseconds": 115898}, "event": "SHUTDOWN", "data": {"guest": false, "reason": "host-qmp-quit"}} [2026-09-30T09:16:41+02:00] REPLY: {"return": {}, "id": 72} ``` ### Expected behavior When rebooting, don't stop the guest and complete the reboot. ### Steps to reproduce 1. Call `systemctl reboot` 2. ??? We have no clear reproducer. This was first seen around Incus 7.1.0 and last seen on 7.1.5.